Does your Monitoring Facility have the ability to receive alarms by SMS?

In my never ending struggle to find ways of getting alarm signals into alarm monitoring centers other than via IP, I'm just wondering how many companies out there would have GSM modems setup to receive incoming signals via SMS text messages. The automation software would have to interface with the GSM modem, grab the incoming message and parse the text for an alarm signal - probably in an agreed format like Contact ID.

A mobile security advisor was first to respond

I have been sending SOS signals to GSM modems for a while. It works as you have postulated but with some caveats. Parsing is straight forward. SMS operate at speeds significantly slower than ip. They can concatenate if sent in order and if the network is busy. GSM modems can be ganged to increase throughput on a single line but there are practical limits. So scaling the application can be a problem if adding lines becomes prohibitive. Using an aggregator service if available will eliminate this throughput and most of the other issues addressed. Depending upon the amount of data sent to the modem, it can be more expensive. But it is very robust and is a very useful failover strategy if gprs is unavailable.

The manager of a control room in Sydney commented

We have a number of duress-type pendants that send an sms to the control room with the contact id format signals coming to our main grid screen. I'm a bit anxious about such a mission critical event using a form of transmission that doesn't necessarily appreciate the priority nature of the message. You'd hate to have a duress sms come through on Christmas Eve or Christmas Day - you'd be lucky to receive it before the New Year!! The duress pendants also send an email to the control room, which all operators receive, giving us some degree of redundancy. Still not completely comfortable about this one.

A Group member from the Middle East added:

Looking at the congestion and delay problems associated with SMS messaging as it exists today, I am wondering if anybody out there has tried talking to the Telecom operators to create a controlled environment within the GSM network for security applications. I am no expert on GSM but I say this because I was able to get our telecom operator in one of the middle east countries to setup a dedicated APN for video over GPRS. Maybe they have similar possibilities for SMS messaging.

Steve Nutt, the discussion starter continued:

Since I started this thread we have developed a new device that decodes Contact ID signals, kisses off the panel and then transmits the signals within the body of an SMS. As far as Down Under goes, my technology partner down there advised me that his automation system supports GSM Modem integration and there are a couple of different formats to choose from. So, not a problem any more. I would be grateful if you could provide me with the protocols required to communicate with your automation system as I am aware that the market for IP is very advanced in the Netherlands and it would help our plan if we had SMS backup available to us.

An Alarm Receiving Center manager from Romainia joined the discussion:

4 -5 years ago I used to work in an ARC where we used SMS alarm signaling. A GSM modem on site emulates the phone line for the alarm panel (the panel is set for Contact ID transmission), kisses off the panel, and then sends a SMS to the ARC. The hardware involved is not so expensive but in Romania almost every alarm company is now using GPRS / IP transmission due to the much lower cost. The transmission speed for a SMS signalling system is about 8 sec., but the SMS cost is much higher than GPRS or IP.

For supervision purposes, we were using a software that was calling all the modules (voice call using a cell phone hooked to the computer). If the line rings, then the software skips to the next module. If the line is busy or out of service, the software generates a report for the operator. I know it`s not perfect, but it was the only solution we could think of at that moment. That way we could detect the SIM`s that were out of service, and send a technical team on site. In Romania GPRS is indeed affordable, but the link is not very stable, so there are still companies that use SMS signaling or even GSM communicators that emulate a classic PSTN line (standard GSM voice SIM).

Steve Nutt continued with his observations:

The cost comparison between using a "regular" GSM SIM and a GPRS enabled SIM is an interesting one. What I am finding is that GPRS is very affordable in some countries, but not in others. The UK and Australia are two countries that spring to mind for cheap GPRS, but I deal with people in countries where GPRS is either not available, or is so expensive that it is not an option. I spoke to a Monitoring Company in Alaska (USA) last week who advised that GPRS is very expensive there. As long as supervision is not required, I think that SMS remains an affordable option in some places.

The manager of a UK based ARC commented:

I think the main issue you would have using SMS / Email messaging for delivering alarms is how would the transmission system know the signal has been received? With traditional system there is normally some form of protocol or handshake to acknowledge the signal has been received and accepted, if this handshake is not received then the system retries and is logged at the control equipment. Another solution for you could be to utilise a 3G dongle and suitable router along with the IP, this should give you a relatively cost effective dual path system.

Steve Nutt, who developed the AlarmCloud alarm receiving platform pointed out that:

My interest in SMS for this particular thread is not in using the technology for signalling alarms from the alarm panel to the receiving centre. I think everyone agrees that SMS would only be used like that in special circumstances. I run a Cloud based alarm receiving platform that receives signals via IP. Our job is to forward signals onto the relevant monitoring company. If their IP connectivity is OK, then we forward via IP and that's the end of it. That's not always the case and we need to support alternative methods of signal forwarding.

We encourage our Customers to have a GSM modem, or even a mobile phone permanently switched on in their operations room. If they experience a total IP failure, then SMS is a very convenient way to get signals to them. We support "two-way" SMS so when we receive a reply to an SMS, we know it arrived. I know this would be unacceptable to our European members, but I deal with monitoring companies of all shapes and sizes from all parts of the globe and have learned not to judge technologies or methodologies on any particular set of standards. SMS is a good fit in many circumstances.

The UK ARC manager replied:

For this like message handling then I can see no issues at all and my organisation also uses SMS / Email for these low risk sort of applications. It is highly unlikely that it would be used in the UK as a solution within the regulated market to pass signals between the alarm panel and the ARC or to pass messages between ARC's as there are no guarantees when the message would be delivered. In the unregulated market I believe this technology is already out there and being used.

A Consultant from New York offered a solution:

FYI we have written an application that allows SMS messages to be be recieved and transfered to automation without an issue. The program looks like a standard receiver to the automation program. We can use different templates to decode different formats sent from different devices. I do agree however that there can be significant delays in the reception of SMS messges. Even knowing this I have a client that is manufacturing a stand alone smoke detector with sends its alarm and status messages by SMS and another doing the same with a self contained motion detector. So there is development going on.

The specialty software applications are available to any central station though Systems Support Specialists. I have a library of applications that many automation suppliers fail to address. If a central station needs something special we can generally create an application very quickly and at reasonable cost. In most cases the software emulates a standard alarm receiver so setup on the automation side is easy.

An industry veteran from Tonga joined the conversation:

SMS signaling from alarm systems is an economical option in many countries, and the methodology is inbuilt in many panels. The alarm system production output from China for example to resellers/end users worldwide is significant, the conversion of previously self monitored systems, or DIY installations, to CMS monitoring offers commercial incentive to provide SMS monitoring ability if the reliability of SMS transmissions can be established. Given the quality of current gsm network equipment, the question of whether SMS is any more or any less reliable than say a PSTN dialer is an interesting one.

Mark mentions a client developing a smoke detector using SMS, Rik and Neil use SMS for Duress signals; SMS signaling is a reality, how comfortable we feel in handling those signals is the important issue. I think most people will agree that the main problem has centered around delivery, whether delayed or not received. (be it peak time or otherwise) There is a way around the delivery/signal audit issue - don't use modems in the CMS, convert the signal at the telco end.

The answer (in brief) for any CMS wishing to support competent SMS signal monitoring is to use a gateway provider with direct SS7 connectivity and convert the message to either an API or email at the providers end. Most CMS software products can integrate this type of data. A side benefit using such a gateway is outgoing client alerts such as Stijn mentioned, the connection can handle many more outgoing alerts per minute than a single modem. The gateway use also provides a full audit trail of delivery or non delivery issues, etc.

The owner of a well known IT Consultancy firm in the US re-ignited the discussion:

I am kind of late to this, but we have been providing SMS modems to our centers since maybe say the mid 90's. I just dated myself.. ;) We have taken in many signals from devices, which have been things like remote oil rig alarms, elevator signal, remote valves etc... Recently we have had clients request SMS gateway interaction and have done this as well to receive alarms. In one case the SMS alarm was for a device that was a two way PERS call and separately sent into our voice gateway the call to route with the signal. So you should have no issues doing this.

However, given the latency with SMS at times, you might want to look at a IP connection that your device can be connected with an automation system and have a continual "I am here" type communication. We have some of these type devices as well. Some of the health safety devices work this way and it allows us to see when they are out of coverage.

Steve replied:

I have found that the view taken by Monitoring Company decision makers is that they simply do not want to run IP receivers - physical or virtual. Period. That leaves me with two options of forwarding signals from our alarm receiving platform into their monitoring software:

1. HTTP API from the automation software vendor (or custom written API)
2. SMS

Obviously we prefer Centrals to provide us with both options, but we will readily accept ANY path into a Monitoring Center as we know from experience how difficult a task it is to get them to implement anything. The ideal scenario is for us to forward signals to their primary URL, if that fails, try the backup URL and if that fails send them via SMS until their IP network(s) recovers.

The IT Consultant offered further advice:

By the way you can use a HTTP post as we have a XML engine. eLink is the older web product but works with this as well. Our newer sites use Matrix which has a built in developer product so that you could just build your own processes to pull and push anything to DICE as the entire system is open and not restricted to an API and what the developer of the API wanted you to do.

Now on the SMS, you can basically create what ever you wish and send it to us. All we do is basically click and drag the fields and their sizes to our signal processing engine and bang it functions. Also indicate if you want a keep alive type signal as well or a check by us because DICE is a two way street. We can send to you, and you can send to us. If you want you can even send data entry requests in both directions (if they fit).

Also, DICE doesn't require a separate SMS Gateway etc. as the SMS processing is included for free. We have charged in the past to setup equipment or gateways, or build custom work. Keep in mind that pretty much all DICE clients have eLink or Matrix so you can XML as your primary route to any of them, which is what I would recommend. Lastly, a great percentage of the DICE clients have our voice gateways, which also allows you to SIP PERS calls or provide inbound voice calls that the automation software automatically ties to the alarms we are speaking of. Great to be on these groups, looks like you have a lot going on.

Steve Nutt was grateful for the advice and continued:

As always after conversing with you, I fall back down to earth with a bang as I realize how clever you and your guys are at DICE. "click and drag the fields and their sizes to our signal processing engine and bang it functions"...... I don't even use drag and drop for moving files around in Windows because it scares me!

Anyway, there's something that is confusing me a little. Some guys told me they had to have you "turn on the HTTP service". Also in your last post about SMS, you said "create what ever you wish and send it to us". Does that mean that you run some kind of data center and process everything on behalf of DICE customers? Do they run dumb terminals?

Also, you mentioned tying 2-way voice alarms into automation. Now that's a subject on it's own and one at the forefront of my mind. Check out the thread I have going over in our Medical Alert Monitoring Group - I'd love to discuss this topic with you further and how DICE might make this a little easier.

The topic ended for the Xmas and New Year break, but will no doubt be revisited again soon:

I love talking about technology and learning new things. We do run a data center and host many things for startup companies, but my remarks regarding just letting us know what you want for the SMS stream is that we would just move the input around for them. Some of our clients use our developer engine and have staff on site who "click and drag" lol, the fields for the inbound processes, but in this case we would just make it happen for them. Remember, something about DICE, most people think we are an automation supplier, but in reality we are an outsourced IT department that specializes in IT for the security industry. Having said that, you asked for something to be done with a IT client, and with their permission, we would just take care of it for them and yourself, since their is a security and network consideration involved at each site depending on the company and what your goals are.