Emergency lift phones can use many different protocols to perform the mandatory 3-day test calls, however the P100 is the most popular open-source protocol. In this post we explain what protocols are and how they work.
What do protocols do?
In order for an emergency phone to communicate successfully with the recipient of the call (be it an alarm call, a scheduled test call, or an ad-hoc technical fault/event reporting call), it needs to know in what format that call should be placed – this is defined by selecting from one of the available call protocols on the device, and the chosen protocol must match whatever the recipient is expecting to receive.
The most basic of the protocols are voice-only, which allow them to be used with recipients answering the calls on a standard phone handset, but which don’t then permit the transfer of much information from the emergency phone.
As the protocols increase in complexity, they gain the ability to transfer data in one or both directions during certain points in the call and, depending on the type of call will then also have the ability to switch into voice mode.
Types of protocols
ContactID originated in the security industry as a lightweight data protocol used by intruder and fire alarm control panels for sending system status updates to a remote monitoring centre, and due to the ease of implementation (and compatibility with existing call centres, at least for data-only call types) it’s also been adopted by other types of system including emergency phones.
P100 originated within the emergency phone industry and is now considered something of a “standard” protocol for emergency phones which can be found supported by phones and receivers from many different manufacturers. It’s slightly more complex than ContactID, allowing for more data to be sent from the phone to the receiver, but as with ContactID it’s designed only for sending data to the receiver.
MEMCO is the AVIRE proprietary protocol, which provides full bidirectional data transfer capabilities between a Memcom phone and the call centre.
All these protocols rely on the use of audible tones (DTMF or similar) to transfer their data, as they all originated in the days when emergency phones were expected to be connected directly to a landline.
What information is transmitted?
During a call, the emergency phone will almost always need to transmit at least some amount of information to the call recipient.
For an EN81-28 compliant alarm call, the phone needs to send something that can be used to identify where the call is coming from.
During a technical fault call, there will also need to be some additional information indicating the type of fault (usually these will be the status of the battery, the speaker, and/or the microphone).
For the “voice-only” guided protocol, all of this information is sent to the recipient using pre-recorded audio messages – phone identification uses the location message which the installer should have recorded during the system setup, event/fault types use factory-preset recordings to build up a fault/event type code message (e.g., “fault code zero-two-six”).
For the “voice+data” protocols (Memcom uses ContactID, P100 and the proprietary MEMCO protocols), this information is sent as data using DTMF tones at the start of the call which the call centre system can easily decode/log, and if it’s an alarm call then the phone switches into live voice mode for the two-way conversation part of the call, whereas for test and tech event calls there’s no need to enter voice mode and so the call ends once all the information has been exchanged. With these protocols, additional information may then also be sent during the data part of the call to enhance the call handling process.
On Memcom there are no “data-only” protocols – every protocol can handle every type of call. The type of call is what determines whether the phone needs to send only information or both information and voice. The choice of protocol merely then determines how the information part of the call is transmitted.
In the event of a MEMCO alarm call, in addition to the phone identification information, information about the health of the phone, as well as which alarm push was activated to place the call is also sent.
What are test (P100) calls and how do they work?
The European Standard EN81-28 specifies that an emergency phone call must call out every 3 days to place a test call to verify it’s in working order, and that test call has to be placed to a receiver software that will log the results.
Most manufacturers of emergency phones have developed receiver software that can receive and record the outcome of the test calls.
The first thing a receiver will check is whether the call was placed – if not, it will register that there is a problem with the hardware or the communication link to the phone (e.g., the telephone line).
If the call does go through correctly, it will then check each step of the call handling protocol that emergency telephones follow:
- call the receiver
- telephone identifies itself
- register any fault codes (usually these will be the status of the battery, the speaker, and/or the microphone)
Each autodialler manufacturer uses its own protocol so the average call centre can end up handling multiple protocols and therefore require multiple receivers. This can be a problem as the record of the calls can then be split amongst several receivers, and in some cases, additional dedicated hardware may be necessary (i.e., a dedicated modem, mini server, etc.) which makes the average install base more expensive and difficult to monitor.
New challenges to P100
The emergency telephone uses the voice channel to broadcast DTMF on order to send information. This works well over copper telephone lines, which were designed for analogue signalling, though there is an expense to the owner of the autodialler as each call is charged as a voice call.
As we move into a fibre line network (aka the Digital Switch) that is built to transmit voice and data, rather than only voice, DTMF audio transmissions will face new challenges as fibre networks may not support DTMF at all!
The most common option installers will choose is to install a GSM so the emergency telephone can work over the mobile network.
However, it’s not as simple as just plugging in any GSM as the following issues of P100 DTMF transmission over a fibre line may still occur:
- compression of the tones over mobile network: the DTMF tone is compressed to transfer it as data, and there is a risk that when it reaches the other end and is decompressed, it may have been modified; making it unreadable by the receiver
- clipping of the tone: when converted into data, there may be a loss of the top and bottom of the DTMF signal which changes the frequency, again, making it unreadable
In other words: if you push DTMF signals into a mobile network it may present problems and trying to solve this with any 2G gateway may still present a drop in the performance of the calls.
Luckily not all GSMs were born the same.
The digital solution – signal transmission
Currently, not all lift phones are set up to transmit digital data, but this can be easily solved by adding a Digital Communication Platform (DCP) to the emergency communication chain.
As most European manufacturers support P100 as an option for their emergency phones, the DCP (aside from supporting both the MEMCO and MK proprietary protocols) can act as an interpreter for any emergency telephone that uses the P100 protocol and will then be able to transmit either analogue audio or digital data (via a SIM card).
To explain the analogue compatibility feature of the DCP based on P100: the DCP intercepts DTMF tones generated by the emergency telephone, reads, and converts them into data. In this way, the smaller, local loop (the connection between phone and GSM), remains analogue whilst the bulk of the communication is transformed into data, increasing its reliability.
DTMF to data conversion is a feature unique to MEMCO’s DCP. The average GSM doesn’t offer this capability.
The digital solution – monitoring and reporting
An additional benefit of using the DCP is that the 3-day test calls are then recorded in the AVIRE Hub monitoring software and can send real-time alerts and notifications if any part of the process is malfunctioning. The reliability of the DCP means that immediate corrective measures can be taken to ensure passenger safety and compliance is in place.
Any autodialler that supports P100 can report into the AVIRE HUB meaning that you can monitor all those brands of phones from one centralised platform.
Any third-party device that can send P100 communication can be translated by the DCP.
By transferring test information as data, there’s also the added benefit of not consuming voice minutes which offers reduced costs by staying within the data allowance.
Once you have connected the DCP to the emergency lift phone, you will additionally have access to enhanced connectivity so you can remotely monitor other data-based equipment on your lift in real-time.
As an added feature, the DCP can futureproof an emergency lift phone setup as it not only works as a converter of a DTMF signal but can transmit data directly over the mobile network when used with a digital audio unit or DAU (DTMF is not involved in this type of communication), offering the most secure and reliable signal.
In conclusion, to benefit from the best of both analogue and digital, the recommended solution is to integrate a DCP into the emergency lift phone setup:
- the DCP understands DTMF tones and can convert them into data locally
- test call monitoring (from any P100 compatible autodialler) can be done in one place via the AVIRE HUB
- the bulk of the transmission between the lift installation and AVIRE HUB is done via data, which is currently the cleanest and safest way to send information
To find out more about emergency communication systems for lifts, contact our team.