IEEE P802.23ā/D0.04 May 02, 2011 This draft expires May 13, 2011 Draft Standard for Local and Metropolitan Area Networks- Emergency Services for Internet Protocol (IP) Based Citizen to Authority Communications Sponsor LAN/MAN Committee of the IEEE Society Approved IEEE-SA Standards Board Copyright Ā© 2011 by the Institute of Electrical and Electronics Engineers, Inc. Three Park Avenue New York, New York 10016-5997, USA All rights reserved. This document is an unapproved draft of a proposed IEEE Standard. As such, this document is subject to change. USE AT YOUR OWN RISK! Because this is an unapproved draft, this document must not be utilized for any conformance/compliance purposes. Permission is hereby granted for IEEE Standards Committee participants to reproduce this document for purposes of international standardization consideration. Prior to adoption of this document, in whole or in part, by another standards development organization, permission must first be obtained from the IEEE Standards Activities Department (stds.ipr@ieee.org). Other entities seeking permission to reproduce this document, in whole or in part, must also obtain permission from the IEEE Standards Activities Department. IEEE Standards Activities Department 445 Hoes Lane Piscataway, NJ 08854, USA Contents Add (Table of) Contents> Draft Standard for Local and Metropolitan Area Networks- Emergency Services for Internet Protocol (IP) Based Citizen to Authority Communications IMPORTANT NOTICE: This standard is not intended to ensure safety, security, health, or environmental protection. Implementers of the standard are responsible for determining appropriate safety, security, environmental, and health practices or regulatory requirements. This IEEE document is made available for use subject to important notices and legal disclaimers. These notices and disclaimers appear in all publications containing this document and may be found under the heading ā€œImportant Noticeā€ or ā€œImportant Notices and Disclaimers Concerning IEEE Documents.ā€ They can also be obtained on request from IEEE or viewed at http://standards.ieee.org/IPR/disclaimers.html. 1. Overview 1.1 Scope This standard defines a media independent framework within IEEE 802 to provide consistent access and data that facilitate compliance to applicable civil authority requirements for communications systems that include IEEE 802 networks. This includes a data link layer interface for a consistent view of IEEE 802 networks by IP (Internet Protocol) based citizen-to-authority emergency services capabilities from the Internet Engineering Task Force (IETF) Emergency Context Resolution with Internet Technologies (ECRIT). This standard specifies a layer 2 entity and associated behaviors with a uniform structure of management information for transferring data required by an emergency services request. 1.2 Purpose The purpose of this standard is to support compliance to civil authority requirements complementary to IETF ECRIT specifications for citizen to authority emergency services functionality. This standard intends to encompass voice, data and multi-media requests across IEEE 802 using a new Layer 2 entity and associated behaviors and provide a uniform Structure of Management Information (SMI) for transferring required data for emergency services requests. (Editor's Note to be removed when action is complete: The purpose as stated here (i.e. on the PAR) will not be included in the standard. Working group to determine purpose text to be insterted in the draft.) 2. Normative references The following referenced documents are indispensable for the application of this document (i.e., they must be understood and used, so each referenced document is cited in text and its relationship to this document is explained). For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments or corrigenda) applies. - NENA i3, Detailed Functional and Interface Specification for the NENA i3 Solution ā€“ Stage 3, Sept. 30, 2010. - RFC 3693, GeoPriv Requirements - draft-ietf-ecrit-phonebcp-13 ECRIT Req'ts - (US) FCC 05-116 - (Korea) TBD - IEEE 802.11u draft 13.0 - IEEE Std 802.16n ā€“ 200n - ietf-draft-rosen-ecrit-additional-data - ietf-draft-schulzrinne-ecrit-psap-callback - ietf-draft-schulzrinne-ecrit-unauthenticated-access - draft-ietf-geopriv-held-measurements (Editor's note to be removed when action is complete: The list is not necessarily complete at this point in terms of items and each item has to be expanded to a full reference in line with the style guide.) 3. Definitions For the purposes of this document, the following terms and definitions apply. The IEEE Standards Dictionary: Glossary of Terms & Definitions should be consulted for terms not defined in this clause. Authorized service: The voice (or other ES applicable) service where the EUT has access to all network services (L1/L2, and higher level IP services) needed to support an ES call. Emergency Services: (Editor's Note to be removed when action is complete: To be supplied) End User Terminal: The host device to the IP application (e.g. VoIP) which places the ES call. ESInet: (Editor's Note to be removed when action is complete: To be supplied) Internet Protocol: (Editor's Note to be removed when action is complete: To be supplied) Layer 1/Layer 2: Within Layer 1 and Layer 2 relative to the ISO 7 Layer model Unauthorized service: Voice (or other ES applicable) service where the EUT does not have access to network services (L1/L2, and higher level IP services) needed to support an ES call. This may involve lack of security access to the L1/L2 network or lack of access for whatever reason (other than bandwidth) to an interconnected voice service at the higher layers. 4. Abbreviations and acronyms ES: Emergency Services ESInet: Emergency Services IP Network EUT: End User Terminal IP: Internet Protocol(s) L1/L2: Layer 1/Layer 2 5. General description Emergency services in general are Citizen-to-Authority emergency calls (e.g. "dialing" 211, 911 and most other country equivalents) that are required to provide location information upon initiation. While other sources of location information may be available to the EUT, it is desirable to provide location from the adjacent network infrastructure (especially fixed infrastructure). This information is expected to be supplied up through the management plane of the EUT. The EUT will in turn transmit this data within an IP transaction across the 802 network to the first L2/L3 interface encountered away from the EUT. At that point the data transaction exits the 802 scope and domain. A Voice over Internet Protocols (VoIP) system normally operates transparently and independently with respect to the Layer 1/Layer 2 system hosting it (in this case, an IEEE 802 network). This transparency does not satisfy the requirements on originating VoIP calls imposed in the case of citizen-to-authority calls of an emergency nature (112/E911 calls). This standard is intended to provide L1/L2 information to upper layer implementations of VoIP, especially those as specified by the Internet Engineering Task Force (IETF). The primary interface for defining these requirements will be the Emergency Context Resolution with Internet Technologies (ECRIT) working group. Potential areas where the 802 family of standards may need to supply additional facilities and information to the upper layers is highly dependent on whether a EUT has a previously established relationship and/or connection with both the 802 network and any higher layer VoIP service. For the purposes of this standard the requirements will be divided into two major areas, those required to support ā€œauthorized serviceā€ (i.e. the EUT has an already established service relationship) and those required to support ā€œunauthorized serviceā€. How 802.23 relates to other standards bodies (in other layers) How 802.23 relates to the rest of 802 5.1 Overview of Emergency Services The overall scope of emergency services and emergency services standards is generally divided into four sub-areas. These are: - Citizen to Authority calls - Authority to Citizen alerts - Authority to Authority communications - Citizen to Citizen communications The scope of this standard is limited to Citizen to Authority calls, that is calls or communications that a ordinary citizen makes to contact and communicate with the emergency services dispatch center that serves the present location of the citizen. Such a dispatch center is known as a PSAP (Public Safety Answering Point), a call center that is responsible for answering calls to police, firefighting, and ambulance services. 5.2 Citizen to Authority Emergency Services Description of C-2-A Emergency Services with context in the Legacy PSTN environment. The movement to establish a uniform system for citizen to authority emergency calls for the public switched telephone network (PSTN) for the USA started in the late 1960s in what was largely a single vendor environment for an entirely wireline network. It was based on (a) a uniform number for accessing emergency services (911 for North America) and (b) providing the PSAP with the calling number (ANI, Automatic Number Identification). Location information was obtained by doing a reverse directory look-up of the provided phone number in the customer database owned by the local phone company (note that this was relatively static for wireline service). In general, at that time there was a fairly good match between the service area of a PSAP and each area of administration of the phone company. The underlying design assumprtions of the legacy system described above deteriorated badly as several factors came into play over time, such as: - Deregulation and breakup of telephone provider exclusive franchises - The introduction and widespread deplyment of cellular telephones - The conversion of voice services from circuit switched to packet switched technology - The rise of VoIP (Voice over Internet Protocols) - The migration of voice from single purpose dedicated devices (i.e. telephones) to softwared based devices (e.g. PCs, laptops, PDAs) - The desire to add non-voice communications to the emergency services calling system (e.g. text and images) - Broad area centralization/consolidation of PSAP service areas. 5.3 Citizen to Authority Emergency Services in an 802/IP environment The major challenge in meeting the above changes to the public communications system has been centered around the change from a single communications vendor environment with fixed customer locations to an environemnt that encompasses multiple vendors, a high percentage of mobile users, no correlation between phone number and location. These were all challenges that were largely encountered during deregulation and the rise of cellular telephony. The core challenge of this transition was moving the source of and the responsibility for location information from a single database in the core of the PSTN to somewhere in the network very close to the calling device. This was a major architectural change and involves the addition to the capabilities to new networks, capabilities that are not inherent to their architecture and involve the addition of significant additional hardware and software. In a multi-vendor packet switched (e.g. IEEE 802) environment there is no centralized registration of the location of the Physical Layer (L1) address nor are there any restrictions against it being moved arbitrarily. While cellular networks tend to have a fairly high degree of vertical integration, that is not the general case for 802 and IP networks. In the latter case (for example) while the lowest level IP device in the core network may be well-known and located, there may be an attached pure L1/L2 802 network that is (at least partially) ad hoc in its configuration, hetrogeneous in its nature and physically large (multiple kilometers) in diameter. Such a network may well have multiple owners with equipment from many vendors. It is therefore essential that standards be in place to convey location information to the EUT as well as in support of any path tracing functions. Additionally, there may well be regulatory requirements to support unauthorized access to the L1/L2 network in an emergency call scenario. This standard supports an optional capability in support of this, should it be required. 5.3.1 End User Terminal (EUT) upper layers in an emergency call situation The specific details of the EUT upper layers in an emergency call situation are beyond the scope of this standard. However, there are some functional elements that must interoperate properly with the lower layer facilities provided by this (and other) 802 standard(s). 5.3.1.1 EUT upper layer location function It is the responsibility of the EUT upper layers to provide location information when initiating an emergency call (Ref: ECRIT (Editor's note: specify to a finer level, i.e. RFC, chapter and verse). Where the EUT upper layers chose to source the location information to satisfy this requirement (e.g. GPS information or via LDDP from the next node on the network) is outside the scope of this standard, but such a choice must be made and acted upon by the EUT. It is a conformance requirement of this standard for the attached network device to make relevant location information available to the EUT according to the specifications herein. 5.3.1.2 upper layer EUT unauthorized access function If it is desired to place an emergency call using the unauthorized access function of an 802 network and the attachment point and 802 network support this feature then special additions must be made to each outgoing packet associated with the emergency call. They will be called out in the detailed specification. 5.3.2 EUT L1/L2 in an emergency call situation To support this standard the L1/L2 portions of the communications stack in to EUT must support LLDP to retrieve location information from the network attachment device. All other functionality is normal given that the Unauthorized Service Virtual Local Area Network (UA-VLAN) transmit encap takes place above L1/L2 and the receive stream UA-VLAN decap takes place in the network attachment device. 5.3.3 802 Backhaul infrastructure in an emergency call situation Each 802 network relay device (802.3 Repeaters and 802.1 MAC Relay devices excepted) should carry standarized location information locally in their managment information base (MIB) and support the appropriate L2 protocol (Editor's Note to be removed when action is complete: The editor has not yet determined the protocol. Is LLDP sufficient for this or is something required in addition to LLDP?) Such that the path between the EUT can be determined and, in a worst case scenario, the location data for each device in the path can be examined remotely and at the application level (with appropriate security controls). 5.3.4 802 Backhaul interface to point of netwark attachment router The network attachement router is assumed for purposes of this standard to be the sole gateway from the originating L1/L2 network and the IP Internet and the implicit or explicit "Emergency Services IP Network" (ESInet) (REF: NENA i3). This port may be implemented either as a real and physically separate hardware port (RJ-45 10/100/1000BASE-T with Autonegotiation reccommended) whose service is policy limited to ES traffic only or it may be implemented as a VLAN port within a larger traffic flow. If the VLAN port implementation method is chosen then it is the responsibility of the gateway routing device to assure that the VLAN is restricted to ES traffic only. The filter restrictions necessary to implement this are called out in clause 6. 6 Detailed Specification 6.1 Location This location requirement is drawn from NENA i3 (858 et seq). Location in NG9-1-1 is represented by validated content in the PIDF-LO2 (RFC4119, updated by RFC5139 and RFC5491) with field use for the United States as documented in the NENA Civic Location Exchange Format [111]. Fields in the PIDF-LO must be used as defined; no local variation is permitted. A service (PIDFLOtoMSAG) is provided in this document for translating PIDF-LO to a NENA standard MSAG representation for backwards compatibility. All geodetic data in i3 uses WGS84 as the datum. 6.2 Unauthorized Access For those instances where it is required to provide a service path across an IEEE 802 L1/L2 network to provide L1/L2 access for a user that does not have authorized access to the L1/L2 network, this standard provides such a path. This path is the ES VLAN. Its purpose is to provide a single destination VLAN to unauthorized EUT. The single destination is a restricted port (real or virtual) on the edge router that provides upper layer services and as a gateway to emergency VoIP services. In the simplest conceptual model, the edge router port is the equivalent to an RJ-45 on that router that is the plug-in point for an emergency "red-phone". The ES VLAN acts as an "virtual extension cord" for that port. 6.3 Priority Recommendations 6.4 External Interfaces ======PAGE BREAK================== Annex A (informative) Bibliography International "911" and Emergency Numbers http://www.sccfd.org/travel.html ======PAGE BREAK================== Annex B (informative) Supporting functional requirements in the EUT (Editor's note to be removed when action is complete: WG Decision needed. Is this Annex necessary or is the functional description in clause 5 sufficient?) ======PAGE BREAK================== Annex C (informative) Supporting functional requirements in the PONA (Editor's note to be removed when action is complete: WG Decision needed. Is this Annex necessary or is the functional description in clause 5 sufficient?) ======PAGE BREAK================== Annex D (informative) Supporting functional requirements in IEEE Std 802.1 ======PAGE BREAK================== Annex E (informative) Supporting functional requirements in IEEE Std 802.11 ======PAGE BREAK================== Annex F (informative) Supporting functional requirements in other IEEE 802 standards