- Twitter 19Oct
RT @rglucks1: Vous ne m’impressionnez pas @AmbassadeChine Et vous ne pouvez donner d’ordre, ici, à un représentant du peuple. J’ai ...
- Twitter 15Oct
Which #OEMs are currently active in #connectedvehicle payments industry? Take a look at our #CVP Global Study ➡️ https://t.co/Ai101SZKN1 #connected #mobillity ...
- Twitter 14Oct
Did you know that during the COVID-19 we have seen an increase in use of #cashlesspayment? Has this catalysed the ...
112 mobile emergency location is still 10 years behind 911
EENA (European Emergency Number Association) has been working for years on promoting and regimenting the way emergency calls are located. Now that more than 60% of emergency calls are made through mobile phones, the old ways of finding an emergency (account holder address) are not sustainable. As a result, in one year in the UK alone, 36K emergency calls took more than 30 minutes to be reached.
The recent EENA meeting in Bucharest gave us the opportunity to find out the status of emergency callers location and it is fair to say there is still a long way to go.
Today, if people are calling from a mobile phone, (often in stressful situations), the “best available” location technology used to locate them defaults to Cell-ID, with accuracy ranging from 100 meters to a few square kilometers. Improvements will not come from the regulator, the representative from the European Commission made it very clear that it is not legally in a position to mandate location accuracy, only the member states can do that at a national level. This lack of top down approach has lead to a bottom up reaction from local authorities all creating their local 112 APP using the handset location technology – typically with a few square meters accuracy.
There are several issues with this approach:
No standards or regulations means each app starts as a regional solution having to compete with other apps in the same country. For example, Alpify in Spain and Andorra, 112 WhereAREu in Lombardi, Italy or P.A.N.I.C in the UK. However, some applications such as FlagMii provide international service depending on the users settings.
Each App works differently. Data, additional services, information format, and access to information by the Public safety answering Point (PSAPs) differ from app to app. For example with the FlagMii app, the PSAP is required to enter the phone number manually into the system to obtain the phones location. But in the case of “Where are U”, an other Italian 112 app, the data package is sent by SMS. Additionally, there are several emergency numbers in Italy and applications present all of them to the customer but in different formats. The phone’s platform also has an incidence: the Android platform allows developers to link the dialing to 112 on the phone’s keypad with the triggering of emergency call data services. Apple does not allow for that and is generally seen as a major stumbling block in the progress for 112 calls to be located in an efficient manner.
Apps include a variety of services and additional information to differentiate themselves. For example, Alpify has a 24hr tracking functions which is very useful at ski resorts. It also communicates the phones remaining battery power to the PSAPs. “112 Where Are U” has a silent calls option in case the person cannot speak and a “witness” function to let PSAPs know that the caller is not directly involved in the accident.
The value chain to consider when understanding the path of an emergency caller’s location is in fact very complex and needs to include Computer Aided Dispatch (CAD) providers, apps provider but also the triage functions from PSAPs as well as local PSAP that only reroute.
Each PSAP requires to integrate independently with each app. Emergency applications are not interoperable, nor can they be easily used alongside each other on a single CAD system. In fact these apps are generally provided by CAD systems vendor as a “nice to have” extra with cost varying around €500 per year. Yet very often, the operational element has not been researched properly. In order to reduce the cost of integration charged by competing CAD providers, adding emergency callers location functions by the PSAP is done through off-board, web-based service requiring yet another screen. This is not scalable.
Location accuracy and the technology providing it is not well understood and not contextualized. Today the precision information sent to the PSAP is only a reflection of what technology is used. If the message is sent with GNSS, the accuracy is labeled as “50 meter”, if it comes from Wi-Fi, it is labeled as “60 meter” despite the fact that indoor Wi-Fi location can be accurate to the meter.
Additionally, emergency call answering procedures are different from country to country: for example, in the UK all emergency calls are directed to one main PSAP, while in Germany there are about 300 PSAPs; in Italy, the Cell-ID information is still under control of the carabinieri (Police), not the wireless operators and is difficult to access.
As a result, while penetration rate of smartphones exceed 50% in Europe, 112 apps are used by a maximum of 5% of the population they cover.
One approach that could solve the penetration issue – but in turn complicates the landscape even further – is to use Advanced Mobile Location (AML). The AML concept is based on the suggestion that the emergency call and data transfer process is made using technology that is built in the phone, and not by an application. Spearheaded by the emergency center at BT and the EE network, tests have already been done with HTC and Sony phones. While a 112 call is made, independently from the caller, an AML-enabled smartphone automatically activates its location service (GPS or Wi-Fi) and sends its position by text message to the relevant PSAP, on average within 18 seconds. The text message is not visible on the phone and is not charged for. The message is also automatically matched to the voice call and compared to the network’s cell-based information to ensure it is valid. An example of AML SMS format is shown below.
The location data is deleted within 30 minutes from the server on which it is stored, the same as landline data. The solution is simple and scalable but it requires a large number of key stakeholders to get on board, not least the phone manufacturers.
As we can see, there are various technological solutions to deliver location data to PSAP. The main problem of caller location delivery to PSAP seems to be regulations and emergency service structures, which differs from country to country. Jordi Borell from Alpify agrees: “It is something we should have a common ground in: integrate the app, so it can work anywhere you go; apps must have a common structure, especially certification. The user must feel comfortable with the app they use, it must be reliable and secure. User must feel safe with the app and understand that it is really going to save their life or help in an emergency”.
There is however a set of requirements from EENA towards next generation (NG) 112 strategies, which is focused on interoperability solutions, location delivery and the possibility to obtain additional data.
The NG112 main requirements are:
· Calls must be interoperable with data and information shared between different PSAPs and follow open standard approaches (IP network based standard for all forms of communication). NG112 must have emergency service access to the Internet and at the same time be secure against various attacks.
· Providing of additional data, such as location and health. Calls must be located and the location must be verified by accurate GIS systems.
· Possibility to make calls using VoIP, text messaging, real-time text, pictures and videos. Therefore, all calls that are entering Emergency Services IP Network must be SIP (session initiation protocol) based.
These requirements will be able to solve most of the problems, especially interoperability. But implementation of these requirements and governmental regulations are still not clear. Therefore, one of the key priorities for European Emergency Number Association (EENA) is to first shape a 112 app strategy with the following objectives:
· Delivering a unified architecture: how the application should be built
· Deliver a set of requirements and deployment guidelines: information type and format
· Developing a certification and authentication program to solve interoperability problems and bring applications to a single implementation platform. EENA’s App Strategy main document can be downloaded here
Today the regulations in place are hindering efforts in locating emergency calls. As Richard from Creativity Software suggested; too many regulations in Europe slow down new technology implementation processes. “In most other countries they have better solutions than in Europe because there are no legislation. We need to pressure the governments to only give a definition of accuracy and let the service providers define the means to obtain it efficiently and in a scalable way.”
Since the regional and national governments are not interested in leading any efforts in unifying and standardizing the process of finding people in danger, the industry is left alone to decide the path to follow and agree on technology and methodology.
This entry was written in partnership with Anna Kolomijeca as part of the Multi-POS project ﬁnancially supported by EU FP7 Marie Curie Initial Training Network MULTI-POS (Multi-technology Positioning Professionals) under grant nr. 316528.