1 / 8

Support for un-authenticated Emergency Services

Support for un-authenticated Emergency Services. Date: 2008-01-11. Authors:. Un-authenticated emergency service support in TGu. From annex T.1:

chaim
Download Presentation

Support for un-authenticated Emergency Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Support for un-authenticated Emergency Services Date: 2008-01-11 Authors: Gabor Bajko, Nokia

  2. Un-authenticated emergency service support in TGu • From annex T.1: • Emergency Services define the IEEE 802.11 functionality to support an Emergency Call (e.g. E911) service as part of an overall, multi-layer solution, specifically capability advertisement and authentication issues. “Multi-layer” indicates that Emergency Services will be provided by protocols developed in part by other standards bodies. • There are no links/references to the other standard bodies nor it is described how the TGu details fit into the big picture Gabor Bajko, Nokia

  3. Architectures supporting Unauthenticated Emergency Services • 3GPP/3GPP2 defined IMS architecture • The extended architecture for IETF Ecrit described in http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-unauthenticated-access-01.txt Gabor Bajko, Nokia

  4. Proposal 1 • Add references to the documents which describe the big picture where the TGu piece fits: • Extended ECRIT architecture supporting unauthenticated emergency services: http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-unauthenticated-access-01.txt • 3GPP IMS emergency sessions architecture: 3GPP TS 23.167 • 3GPP2 IMS emergency sessions architecture: Gabor Bajko, Nokia

  5. Extended ECRIT architecture supporting un-authenticated Emergency Services Gabor Bajko, Nokia

  6. Boundary of PSAP2 Boundary of PSAP1 ESRP3 ESRP1 ESRP2 ESRP4 PSAP1 PSAP2 AN6 AN8 AN4 AN3 AN5 AN1 AN7 AN2 Mobility during emergency service call in the extended Ecrit architecture esrp= Emergency Services Routing Proxy Gabor Bajko, Nokia

  7. What can TGu further define? • Procedures to help the STA handover to an AN which is connected to the same ESRP • Make the address of the ESRP accessible for download using GAS Native query • This involves: • Adding a new application ID for DHCP • ESRP discovery is using RFC3263 • Deployment guidelines: ANs within the same ESS should have the same ESRP • ESSs should not cross PSAP boundaries • IETF will further define SIP procedures to handle cases which do not fall into the above (and requires heavy SIP procedures to maintain session continuity) Gabor Bajko, Nokia

  8. Proposal 2 • Define a new Advertisement Protocol ID (value=4 ) for transporting DHCP messages and options • DHCP server has similarities with a 802.21 IS server, it can be used to bootstrap lots of useful information before or without associating to the AP. Beneficial in case there is no 802.21 IS server in the backend, but there is DHCP server • Example of existing DHCP options: • Access network name, timezone, geo and civic location, DNS, SIP proxy, ESRP, etc. Gabor Bajko, Nokia

More Related