1 3rd Emergency Services Workshop, Brussels, 2007 Tutorial on Location and Emergency Services...
-
Upload
gregory-hunter -
Category
Documents
-
view
214 -
download
0
Transcript of 1 3rd Emergency Services Workshop, Brussels, 2007 Tutorial on Location and Emergency Services...
1 3rd Emergency Services Workshop, Brussels, 2007
Tutorial onLocation and Emergency Services
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <[email protected]> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <[email protected]>.
Date: 2008-09-10
Name Company Address Phone email Gabor Bajko Nokia Mountain
View, CA +1 972 894 5000
Author:
2 3rd Emergency Services Workshop, Brussels, 2007
Tutorial onLocation and Emergency Services
Gabor Bajko, IEEE meeting, Hawaii 2008
some of the slides from:Hannes Tschofenig
3 3rd Emergency Services Workshop, Brussels, 2007
Authority to Citizen
• Example: Cell broadcast for Tsunami warning
Authority to Authority
• Example: Communication between emergency personnel
Citizen to Authority
Emergency Services Categories
Note that some SDOs use the term “individuals” instead of “citizen”.
4 3rd Emergency Services Workshop, Brussels, 2007
LocationEmergency
Call
Determine correct PSAP
IdentifyEmergencyCalls
Building Blocks for Citizen to Authority type of Emergency Calls
5 3rd Emergency Services Workshop, Brussels, 2007
How is location information encoded?
• Two formats exist for location information encoding:▪ Binary Format
▪ XML-based Format
• For bandwidth constraint environments a functionality-reduced binary encoding is used (e.g., link layer protocols or DHCP) and for application protocols the XML encoding is used.
• The XML encoding is based on the Presence Information Data Format (PIDF) for Location Objects (LO) as defined in the Geopriv Working Group of IETF (simply PIDF-LO)
• PIDF-LO uses the Geography Markup Language (GML) developed by OGC for describing geodetic information.
6 3rd Emergency Services Workshop, Brussels, 2007
Location Determination
Very limited scope or unused: •TDOA (cellular networks)•LLDP•DHCP•HELD (http-based)•Applic. using PIDF-LO, etc.What is really used (especially in mobile devices): GPS
– Requires GPS signal from at least 4 satellites (at least 3 in case of A-GPS)– 3rd dimension (altitude) calculation is difficult and inaccurate. Consumer GPS
devices only work with longitude/latitude– Extremely slow: takes 2 min or more to calculate the coordinates – DOES NOT WORK INDOOR
▪ This is why GPS will not monopolize the location determination
There is a tendency for having almost-full indoor coverage using low range network boxes (802.11 AP, 3G femto-cells, etc.)• Boxes/APs have a fixed location• Devices ‘seeing’ them are in their proximity (limited coverage)• Make use of the boxes’ location
7 3rd Emergency Services Workshop, Brussels, 2007
Location in IEEE
LLDP developed in 802.1AB• Suitable mainly for wired environment
802.11k: Location Measurements• Download of AP location by the non-AP STA (where are you?)• Measurement of location accuracy (where am I relative to you?)• It does not specify how the measurements are done
802.11v: Presence• Extends 802.11k with Presence functionality• Subscribe/notify mechanism to notify non-AP STA about location changes
(duplicates the SIP Presence functionality)• 3rd LB failed
802.11u: download AP location without association and/or authentication to the AP•AP location capability indication in the beacon•If bit set to 1, non-AP STA can request the location of the AP without association/authentication•Provides almost instantaneous location configuration
8 3rd Emergency Services Workshop, Brussels, 2007
Location in IETF (RFCs)
RFC3825: DHCP Option for Geodetic location– Features altitude specification in both ‘above sea level’ and floor #– The binary encoding used in the RFC is copy pasted to 802.11k as Location
Configuration Information Report element (extended to include azimuth information)
RFC4776: DHCP Option for Civic Location– Defines Civic Address types (CAtype)– There is no equivalent binary encoding available in 802.11– Question: should there be one??
RFC4119 ( partially revised by RFC5139): extension of PIDF to carry location (PIDF-LO)
– XML- based– Focuses too much on privacy while in many cases location is an application
enabler, rarely is exchanged between clients and thus orthogonal to privacy▪ The ‘usage rules’ element is mandatory▪ When APs make their location available to anyone unconditionally, privacy is not
relevant– Geodetic location: It imports a GML schema, where altitude is a geodetic
variable, means ‘above sea level’
10 3rd Emergency Services Workshop, Brussels, 2007
XML encoding of location: PIDF-LO (RFC 4119)
• Presence Information Data Format (PIDF) is an XML-based format for presence (RFC 3863)
• PIDF document contains identity information (as part of the entity attribute).
• Extends PIDF to accommodate new elements:– <location-info> Element
▪ Encapsulates location information▪ GML 3.0 <feature.xsd> schema (mandatory-to-implement)▪ Supports civic location format (optional-to-implement)
– <usage-rules> Element▪ Used to indicate privacy preferences
– <method> Element▪ Describes the way location information was derived or discovered. ▪ Example: <method>gps</method>▪ Registry available at: http://www.iana.org/assignments/method-tokens
– <provided-by> Element▪ Entity or organization that supplied this location information
11 3rd Emergency Services Workshop, Brussels, 2007
Example: PIDF-LO with geodetic information <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="http://www.opengis.net/gml" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" entity="pres:[email protected]"> <dm:device id="mikepc"> <status> <gp:geopriv> <gp:location-info> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>-43.5723 153.21760</gml:pos> </gml:Point> </gp:location-info> <method>802.11</method> <provided-by>www.example.com</provided-by> <gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry> <ruleset-reference>https://www.example.com/myrules</ruleset-reference> <note-well>These are my privacy rules</note-well> <gp:usage-rules/> </gp:geopriv> </status> <timestamp>2007-06-22T20:57:29Z</timestamp> <dm:deviceID>mac:8asd7d7d70cf</dm:deviceID> </dm:device> </presence>
12 3rd Emergency Services Workshop, Brussels, 2007
Example: PIDF-LO with civic information <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="http://www.opengis.net/gml“ xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" entity="pres:[email protected]"> <dm:device id="mikepc"> <status> <gp:geopriv> <gp:location-info>
<cl:civicAddress> <cl:country>US</cl:country> <cl:A1>New York</cl:A1> <cl:A3>New York</cl:A3> <cl:A6>Broadway</cl:A6> <cl:HNO>123</cl:HNO> <cl:LOC>Suite 75</cl:LOC> <cl:PC>10027-0401</cl:PC> </cl:civicAddress> </gp:location-info> <gp:usage-rules/>
</gp:geopriv> </status> <timestamp>2007-06-22T20:57:29Z</timestamp> <dm:deviceID>mac:8asd7d7d70cf</dm:deviceID> </dm:device> </presence>
13 3rd Emergency Services Workshop, Brussels, 2007
What civic information can I express?
• Initially civic location was specified for DHCP in RFC 4776* (http://www.ietf.org/rfc/rfc4776.txt)
• This format is a binary format.
• With RFC 4119* (PIDF-LO) for some of the RFC 4776 civic elements an XML encoding was specified.
*: Note that the content of RFC 4776 was developed before the work on PIDF-LO (RFC 4119). It was, however, faster to finish the standardizationwork on PIDF-LO.
14 3rd Emergency Services Workshop, Brussels, 2007
RFC 4119 Civic Location Information - I
Label Description Example
country The country is identified by the two-letter ISO 3166 code
US
A1 national subdivisions (state, region, province, prefecture)
New York
A2 county, parish, gun (JP), district (IN) King's County
A3 city, township, shi (JP) New York
A4 city division, borough, city district, ward, chou (JP)
Manhattan
A5 Neighbourhood, block Morningside Heights
A6 Street Broadway
PRD Leading street direction N, W
POD Trailing street suffix SW
15 3rd Emergency Services Workshop, Brussels, 2007
RFC 4119 Civic Location Information –II (contd.)
Label Description Example
STS Street suffix Avenue, platz, Street
HNO House number, numeric part only 123
HNS House number suffix A, ½
LMK Landmark or vanity address Low Library
LOC Additional location information Room 543
FLR Floor 5
NAM Name (residence, business or office occupant )
Joe’s Barbershop
PC Postal code 10027-0401
16 3rd Emergency Services Workshop, Brussels, 2007
Constantly providing a Target with it’s current location is not efficient. What can I do?
Solution: Location by Reference (LbyR) Concept
Instead of retrieving location information per value a reference is obtained. This reference can be resolved to a location object several times and provides up-to-date location information. Access control can also be enforced.
The reference plays the role of an generalized identifier.
17 3rd Emergency Services Workshop, Brussels, 2007
Architecture
SIP, HTTP, etc.
+ Location Reference Location Recipient
Location Reference
End Host
Location Information Server
Request
Location ReferenceLocation Information
Examples of a Location Reference
• sips:[email protected]
• https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
18 3rd Emergency Services Workshop, Brussels, 2007
Determine Location
Emergency Call
Determine correct PSAP
IdentifyEmergencyCalls
Building Blocks
19 3rd Emergency Services Workshop, Brussels, 2007
Identifying an Emergency Call
Emergency NumbersSee http://www.sccfd.org/travel.html
20 3rd Emergency Services Workshop, Brussels, 2007
Emergency numbers vary in countries
• Example: 911 for North America, 112 for Europe
• some countries use separate numbers for ambulance/police/fire; others don’t
Required to support both home and visited emergency number
• e.g., for an American traveler who is visiting Europe, both 911 and 112 should be recognized as emergency
Configuration of emergency numbers and dial strings important
• Home Emergency Number: User can learn this number through LoST or device configuration
http://tools.ietf.org/html/draft-ietf-sipping-config-framework
• Visited Emergency Number: Obtained dynamically via LoST
Emergency Numbers
21 3rd Emergency Services Workshop, Brussels, 2007
Identifying an Emergency Call
• Emergency numbers are entered into the user interface
• On the protocol level an emergency number independent scheme used to mark a call as an emergency call. Service URNs
• Why?– To mark call as emergency call and thereby to request special call
handling
– For Mapping Protocol: To resolve to PSAP URI
• Service URN registry established in RFC5031
• Example: urn:service:sos; urn:service:sos.ambulance, urn:service:sos.police, etc.
22 3rd Emergency Services Workshop, Brussels, 2007
Determine Location
Emergency Call
Determine correct PSAP
IdentifyEmergencyCalls
Building Blocks
23 3rd Emergency Services Workshop, Brussels, 2007
Service URN
Location Information
How to find the closest PSAP?
+
(PSAP) URI
Service URN
Service Boundary
+
+
Emergency Number
+
Location-to-Service Translation (LoST) is a simple XML-based query and response protocol running on top of HTTP.
24 3rd Emergency Services Workshop, Brussels, 2007
Features
•Protocol specification available in http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-lost/ •Satisfies the requirements for mapping protocols:
– http://tools.ietf.org/html/draft-ietf-ecrit-requirements• Supports extensible location profiles. Currently 2 profiles are available:
– geodetic-2d (offers Point, Polygon, Circle, Ellipse, ArcBand) and civic (based on http://tools.ietf.org/html/draft-ietf-geopriv-revised-civic-lo )
• Provides civic address validation– Returns XML tag names of components (classified into <valid>, <invalid> and
<unchecked>)• Offers recursive and iterative query resolution• Returns PSAP URI, emergency dial string, service boundary information and supplementary information• Service boundary may be returned via reference or by value.• Functionality for listing services and listing services per location. • LoST server discovery procedure
– via DNS (defined in http://tools.ietf.org/html/draft-ietf-ecrit-lost )– Via DHCP (defined in http://tools.ietf.org/html/draft-ietf-ecrit-dhc-lost-discovery)
25 3rd Emergency Services Workshop, Brussels, 2007
LoST Example<findService> Query with geodetic location info
<?xml version="1.0" encoding="UTF-8"?><findService xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml" serviceBoundary="value" recursive="true">
<location id="6020688f1ce1896d" profile="geodetic-2d"> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326"> <p2:pos>37.775 -122.422</p2:pos> </p2:Point> </location> <service>urn:service:sos.police</service>
</findService>
26 3rd Emergency Services Workshop, Brussels, 2007
LoST Example<findService> Response<?xml version="1.0" encoding="UTF-8"?> <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml"> <mapping expires="2007-01-01T01:44:33Z" lastUpdated="2006-11-01T01:00:00Z" source="authoritative.example" sourceId="7e3f40b098c711dbb6060800200c9a66"> <displayName xml:lang="en"> New York City Police Department </displayName> <service>urn:service:sos.police</service> <serviceBoundary profile="geodetic-2d"> <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <p2:exterior> <p2:LinearRing> <p2:pos>37.775 -122.4194</p2:pos> … <p2:pos>37.775 -122.4194</p2:pos> </p2:LinearRing> </p2:exterior> </p2:Polygon> </serviceBoundary> <uri>sip:[email protected]</uri> <uri>xmpp:[email protected]</uri> <serviceNumber>911</serviceNumber> </mapping> <path> <via source="resolver.example"/> <via source="authoritative.example"/> </path> <locationUsed id="6020688f1ce1896d"/> </findServiceResponse>
27 3rd Emergency Services Workshop, Brussels, 2007
Example:listServices and listServicesResponse<?xml version="1.0" encoding="UTF-8"?><listServices xmlns="urn:ietf:params:xml:ns:lost1"> <service>urn:service:sos</service></listServices>
<?xml version="1.0" encoding="UTF-8"?> <listServicesResponse xmlns="urn:ietf:params:xml:ns:lost1"> <serviceList> urn:service:sos.ambulance urn:service:sos.animal-control urn:service:sos.fire urn:service:sos.gas urn:service:sos.mountain urn:service:sos.marine urn:service:sos.physician urn:service:sos.poison urn:service:sos.police urn:service:sos.suicide </serviceList></listServicesResponse>
Request
Response
<listServicesByLocation> is a variation of <listServices> that includes location in the query.
28 3rd Emergency Services Workshop, Brussels, 2007
Determine Location
Emergency Call
Determine correct PSAP
IdentifyEmergencyCalls
Building Blocks
The emergency call itself is shown in the context of the architecture. It makes use of the Service URN and SIP Location Conveyancehttp://tools.ietf.org/wg/sip/draft-ietf-sip-location-conveyance/ as protocol mechanisms.
29 3rd Emergency Services Workshop, Brussels, 2007
How do I carry location information or references between the Target/Proxy and an Location Recipient/Application Server?
• The GEOPRIV WG calls this a using protocol.• SIP is such a using protocol relevant in this context, as defined in
http://tools.ietf.org/html/draft-ietf-sip-location-conveyance• Defines the Geolocation header:
– Points to location per value (using a cid:) or contains a reference (e.g., sips:)• Geolocation header may contain additional parameters:
– inserted-by parameter: Indicates which entry added location to the message ("endpoint" or "server“)
– used-for-routing parameter: Used when location was used for routing– recipient parameter: Indicates intended recipient ("endpoint“, "routing-entity“ or "both“)
• New geolocation option tag: To indicate support for the this extension by UAs in Require, Supported and Unsupported headers (RFC 3261)
• New error message (424 Bad Location Information) – Contains addition error value – Node identification of the entity that experienced the location-based error– Human readable error text pre-defined in the draft
• Defines sip/sips/pres as a dereference scheme
30 3rd Emergency Services Workshop, Brussels, 2007
Alice
Example: SIP Invite with Location by Value (1)Bob
Example shows location added by value. cid: points to location in the body.
INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/TCP pc33.atlanta.example.com ;branch=z9hG4bK77i832k9Max-Forwards: 70To: Bob <sip:[email protected]>From: Alice <sip:[email protected]>; tag=1928301774Call-ID: [email protected] Geolocation: cid:[email protected];[email protected];
recipient=endpoint Supported: geolocation CSeq: 314159 INVITEContact: <sip:[email protected]>Accept: application/sdp, application/pidf-xmlContent-Type: multipart/mixed; boundary=0a0Content-Length: 543
INVITE
geolocation (if as a message body)
sdp
31 3rd Emergency Services Workshop, Brussels, 2007
--0a0Content-Type: application/pidf+xmlContent-ID: cid:[email protected] ….. <gml:location> <gml:coordinates>36.132N 115.151W </gml:coordinates> </gml:location> ….. <method>802.11</method> <provided-by>www.example.com</provided-by/> …..--0a0--
Alice
Example: SIP Invite with Location by Value (2)
Bob
INVITE
XML fragment of multipart MIME body
Example geodetic location
32 3rd Emergency Services Workshop, Brussels, 2007
Alice
Example: SIP Invite with Location by Value (3)
Bob
INVITE
--0a0Content-Type: application/pidf+xmlContent-ID: cid:[email protected]
... <gp:geopriv> <gp:location-info> <cl:civilAddress> <cl:country>US</cl:country> <cl:A1>Nevada</cl:A1> <cl:A3>Las Vegas</cl:A3> <cl:HNO>399</cl:HNO> <cl:A6>Convention Center</cl:A6> <cl:STS>Drive</cl:STS> <cl:PC>89109</cl:PC> <cl:LMK>LVCC</cl:LMK> <cl:RM>110</cl:RM> <cl:civilAddress> <gp:location-info> ...--0a0--
XML fragment of multipart MIME body
Example civic location
33 3rd Emergency Services Workshop, Brussels, 2007
Alice
Example: SIP Invite with Location by Reference (1)
Bob
INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/TCP pc33.atlanta.example.com ;branch=z9hG4bK77i832k9Max-Forwards: 70To: Bob <sip:[email protected]>From: Alice <sip:[email protected]>; tag=1928301774Call-ID: [email protected] Geolocation: sips:[email protected];[email protected]; Recipient=endpointSupported: geolocation CSeq: 314159 INVITEContact: <sip:[email protected]>Accept: application/sdp, application/pidf-xmlContent-Type: application/sdpContent-Length: 243
INVITE
Example shows location added by value.
sips:[email protected] represents the location by reference
34 3rd Emergency Services Workshop, Brussels, 2007
Alice Bob
200 OK
200 OK may contain either form of location delivery (message body or URI)• Since Request had appropriate
Accept header
SIP/2.0 200 OKVia: SIP/2.0/TCP sip:[email protected] ;branch=z9hG4bK77i832k9To: Bob <sip:[email protected]>; tag=a6c85e3From: Alice <sip:[email protected]>;tag=1928301774Call-ID: [email protected] Geolocation: sips:[email protected] Supported: geolocation CSeq: 314159 INVITEAccept: application/sdp, application/pidf-xmlContent-Type: application/sdpContent-Length: 142
(…Bob’s SDP here…)
INVITE
Example: SIP Invite with Location by Reference (2)
35 3rd Emergency Services Workshop, Brussels, 2007
Architectural Models
•An emergency call is treated like any other call– Reduces interoperability problems
• Two major architectural models based on today’s communication models:
– End Host Based Model: Location information is provided to End Host. Emergency dial strings and PSAP URIs are determined by End Host
– Proxy Based Model: Location information is attached by a Proxy
• A couple of variations possible.
• See also where a strong focus is given on the description of model 1:
http://tools.ietf.org/html/draft-tschofenig-ecrit-architecture-overview-00
36 3rd Emergency Services Workshop, Brussels, 2007
End Host Based Model
Location Information is provided by the LIS.End host uses LoST to determine PSAP URIThe INVITE might be sent to the PSAP directly but will typically travel via the outbound SIP proxy
LoST Server
SIP proxy PSAP
(1) Location
Location + Service Identifier
(2)
PSAP URI + service number
(3)
(4)(5)
dial dialstringSOS caller
Location Information Server
(0) Request
INVITERequest URI: urn:service:sosTo: urn:service:sos
Route Header: PSAP URI <PIDF-LO>
INVITERequest URI: urn:service:sosTo: urn:service:sos
Route Header: PSAP URI <PIDF-LO>
37 3rd Emergency Services Workshop, Brussels, 2007
PSAP / Call Taker
LoST Server
SIP proxySOS caller
(2) Location
Location + Service Identifier
(3)
PSAP URI
(4)
(1) (5)
dial dialstring
Proxy Based Model
Assumes that SIP proxy is able to determine the end hosts location information. This assumes a close relationship between the IAP/ISP and the SIP proxy
Location Information Server
INVITERequest URI: urn:service:sosTo: urn:service:sos
INVITERequest URI: urn:service:sosTo: urn:service:sos
Route Header: PSAP URI < Reference to PIDF-LO>
38 3rd Emergency Services Workshop, Brussels, 2007
End Host obtains Location InformationProxy runs (also) LoST
SIP proxy PSAP
(1) Location
INVITERequest URI: urn:service:sosTo: urn:service:sos
<PIDF-LO>
(2)
INVITERequest URI: urn:service:sosTo: urn:service:sos
Route Header: PSAP URI < PIDF-LO>
(5)dial dialstring
SOS caller
Location Information Server
(0) Request Location + Service Identifier
(3) (4)
LoST Server
PSAP URI
39 3rd Emergency Services Workshop, Brussels, 2007
PSAP / Call Taker
Mapping Server
SIP proxySOS caller
(2) Location
Location + Service Identifier
(3)
PSAP URI
(4)
INVITE Request URI: 911 To: 911
(1)
(5)
dial 9-1-1
Legacy Equipment
Location Information Server
Dial string recognition, location determination, route determination done by SIP proxyReally only useful for restricted environments.
INVITERequest URI: urn:service:sosTo: 911
Route Header: PSAP URI < Reference to PIDF-LO>
40 3rd Emergency Services Workshop, Brussels, 2007
Legacy EquipmentDisadvantages
• When the emergency call is not recognized by the User Agent then the following features cannot be disabled:
– Call Waiting– Call Transfer– Three Way Call– Flash hold– Outbound Call Blocking
• Callbacks from the PSAP may be blocked.– Call Waiting, Do Not Disturb, Call Forward should be disabled.
• Privacy settings might prevent disclosure of identity and location information might not be added to the call.
• Other call features may not be supported, such as REFER (for conference call and transfer to secondary PSAP) or GRUU.
• May violate other parts of the phone BCP document.• Updating the end points to support emergency services is very important.
41 3rd Emergency Services Workshop, Brussels, 2007
Notes on Media Traffic
•RTP based media traffic RFC 3550 mandatory •Minimum requirements for interoperability:
– Audio codec: G.711 Silence suppression not used.
– IM: RFC 3428 or RFC 3920– Real-time text: RFC 4103 – Video: H.264 RFC 3984
• Better features can be negotiated via SIP offer/answer RFC 3264.
• Testing: INVITE requests to a service urn with a urn parameter of "test" indicates a request for an automated test.
– Example: "urn:service.sos.fire;test“– Response may include a text body (text/plain) with PSAP identity, the
requested service, and the location reported with the call.
42 3rd Emergency Services Workshop, Brussels, 2007
Unauthenticated Emergency Services
• Reference http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-unauthenticated-access
• Cases:
– The emergency caller does not have credentials for access to the network but it may have credentials for his VoIP provider.
– The emergency caller has credentials for network access but does not have credentials for a VoIP provider.
– The emergency caller has credentials (for either network access or it's VoIP provider) but they are not authorization to make a call.
• Work assumes lower-layer procedures for omitting network access authentication.
• High-level Impact:– End host has to implement a specific VoIP profile
– SIP proxy has to be located in the access network.
43 3rd Emergency Services Workshop, Brussels, 2007
What information may be needed in unauthenticated state?
•Local emergency dialstring
•PSAP URI corresponding to the desired emergency type and at the specific location
•802.11u allows to use LoST in state-1, which allows to obtain these information. If the network type is ‘emergency’, then a SIP call to the PSAP can also be placed.
44 3rd Emergency Services Workshop, Brussels, 2007
Unauthenticated Emergency Services in IEEE(802.11u)
Support for Unauthenticated Emergency Services
• Case1: ES only open network• Open SSID limited for ES usage
• Case2: Public credentials• Download credentials to authenticate then able to use the network for ES only
QoS features:
• Expedited bandwidth request
It’s not a complete solution, needs a backend system behind
Currently no regulation, it is done for the help of the mankind
45 3rd Emergency Services Workshop, Brussels, 2007
Authority to Citizen type of Emergency Calls
Example services:
•Emergency Alert Systems
•Public Warning Systems (PWS)
•Earthquake and Tsunami Warning Systems (ETWS)
•Commercial Mobile Alert Service (CMAS)
Support for it in IEEE (802.11u):
• a bit in the beacon indicating the existence of an alert, detectable at scanning phase
• Alert can be fetched without authenticating to the AP
• Uses CAP inside the .11 frames