ANSI ATIS 1000059-2017 Emergency Telecommunications Service Wireline Access Requirements.pdf

1、 AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-1000059.2017 Emergency Telecommunications Service Wireline Access Requirements As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (ATIS) brings together the top global ICT comp

2、anies to advance the industrys most pressing business priorities. ATIS nearly 200 member companies are currently working to address the All-IP transition, 5G, network functions virtualization, big data analytics, cloud services, device solutions, emergency services, M2M, cyber security, network evol

3、ution, quality of service, billing support, operations, and much more. These priorities follow a fast-track development lifecycle from design and innovation through standards, specifications, requirements, business use cases, software toolkits, open source solutions, and interoperability testing. AT

4、IS is accredited by the American National Standards Institute (ANSI). The organization is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of the oneM2M global initiative, a member of the International Telecommunication Union (ITU), as w

5、ell as a member of the Inter-American Telecommunication Commission (CITEL). For more information, visit www.atis.org. AMERICAN NATIONAL STANDARD Approval of an American National Standard requires review by ANSI that the requirements for due process, consensus, and other criteria for approval have be

6、en met by the standards developer. Consensus is established when, in the judgment of the ANSI Board of Standards Review, substantial agreement has been reached by directly and materially affected interests. Substantial agreement means much more than a simple majority, but not necessarily unanimity.

7、Consensus requires that all views and objections be considered, and that a concerted effort be made towards their resolution. The use of American National Standards is completely voluntary; their existence does not in any respect preclude anyone, whether he has approved the standards or not, from ma

8、nufacturing, marketing, purchasing, or using products, processes, or procedures not conforming to the standards. The American National Standards Institute does not develop standards and will in no circumstances give an interpretation of any American National Standard. Moreover, no person shall have

9、the right or authority to issue an interpretation of an American National Standard in the name of the American National Standards Institute. Requests for interpretations should be addressed to the secretariat or sponsor whose name appears on the title page of this standard. CAUTION NOTICE: This Amer

10、ican National Standard may be revised or withdrawn at any time. The procedures of the American National Standards Institute require that action be taken periodically to reaffirm, revise, or withdraw this standard. Purchasers of American National Standards may receive current information on all stand

11、ards by calling or writing the American National Standards Institute. Notice of Disclaimer Resource and Admission Control: DIAMETER protocol for session based policy set-up information exchange between the Application Function (AF) and the Service Policy Decision Function (SPDF); Protocol specificat

12、ion, March 2006. 2.3.2 CableLabs4CM-SP-MULPIv3.0-I08-080522 CM-SP-MULPIv3.0-I08-080522, Data-Over-Cable Service Interface Specification, DOCSIS 3.0, MAC and Upper Layer Protocols Interface Specification, May 2008. PKT-SP-MM-I04-080522 PKT-SP-MM-I04-080522, PacketCableTM Specification, Multimedia Spe

13、cification, May 2008. PKT-SP-MM-WS-I02-080522 PKT-SP-MM-WS-I02-080522, PacketCable Multimedia Specification, PacketCable Multimedia Web Service Interface Specification, May 2008. PKT-SP-QOS-I02-080425 PKT-SP-QOS-I02-080425, PacketCableTM 2.0 Quality of Service Specification, April 2008. PKT-TR-ARCH-

14、FRM-V04-071106 PKT-TR-ARCH-FRM-V04-071106, PacketCableTM 2.0 Architecture Framework Technical Report, November 2007. 2.3.3 Broadband Forum5TR-058 TR-058, Multi-Service Architecture and Framework Requirements, September 2003. TR-059 TR-059, DSL Evolution Architecture Requirements for the Support of Q

15、oS Enabled IP Services, September 2003. TR-101 TR-101, Migration to Ethernet-Based DSL Aggregation, April 2006. 2These documents are available from the International Telecommunications Union (ITU) at: . 3These documents are available from the European Telecommunications Standards Institute (ETSI) at

16、: . 4These documents are available from CableLabs at: . 5These documents are available from the Broadband Forum at: . ATIS-1000059.2017 3 TR-156 TR-156, Using GPON Access in the Context of TR-101, December 2008. TR-134 TR-134, Broadband Policy Control Framework, July 2012. 2.3.4 Metro Ethernet Forum

17、6MEF 4 Technical Specification MEF 4, Metro Ethernet Network Architecture Framework Part 1: Generic Framework, May 2004. MEF 7 Technical Specification MEF 7, EMS-NMS Information Model, October 2004. MEF 15 Technical Specification MEF 15, Requirements for Management of Metro Ethernet Phase 1 Network

18、Elements, November 2005. MEF 16 Technical Specification MEF 16, Ethernet Local Management Interface, January 2006. MEF 17 Technical Specification MEF 17, Service OAM Requirements that is, to optimize the number of signaling messages successfully processed when overload prevents processing all signal

19、ing messages (e.g., after all permitted non-signaling load has been shed and the FE is still in an overload condition). This typically involves shedding signaling load during extreme overload. Usually, there is some level of differentiation in which incoming messages/packets are shed, not just blind

20、ly shedding a certain percentage. Machine congestion itself occurs at the machine (Network Equipment) level, e.g., when real-time processing utilization reaches 96%, rather than at the FE level. However, one machine may host multiple FEs. As a result, the congestion control (e.g., blocking or sheddi

21、ng packets or messages) is often FE or protocol specific. The same Network Equipment may use different methods for filtering different messages, or it may use different methods on different interfaces or ports, corresponding to different functions. Therefore, the MCC requirements are specified in te

22、rms of FEs, even though the requirements will be satisfied by Network Equipment implementations. If an FE that is ETS-aware implements machine-congestion-based overload controls, then the FE shall recognize arriving ETS traffic and shall exempt ETS traffic from machine-congestion-based overload cont

23、rols (e.g., exemption from load shedding) up to the point where further exemption would cause machine instability. FE specifics, in terms of the method of recognition (either directly or indirectly), and the point at which it must be recognized, are not addressed as common requirements. The priority

24、 treatment given by an FE to ATIS-1000059.2017 11 ETS traffic in respect to machine-congestion-based overload controls ensures that normal traffic is shed before ETS traffic, and ETS traffic is only shed when the FE is in danger of total failure. Recognition and shedding should be provided before si

25、gnificant resources are consumed for packets or signaling messages. 6.1.2 CPE Access Gateway The CPE Access Gateway is outside the scope of this clause. However, enterprise locations may wish to provision their CPE Access Gateways to support ETS. 6.1.3 DSL Access Network FE-Specific Requirements 6.1

26、.3.1 NID, MDF, & DSLAM There is no impact to the NID, MDF, and DSLAM when ETS services are invoked in the network. 6.1.3.2 Ethernet Aggregation The Ethernet Aggregation FE shall be engineered to be non-blocking for all traffic transmitted between the attached DSLAMs and BNGs. 6.1.3.3 Broadband Netwo

27、rk Gateway (BNG) This sub-clause specifies requirements associated with the BNG processing. Only ETS-specific requirements are included, reflecting incremental requirements that extend beyond basic BNG functionality as defined in Broadband Forum specifications. The BNG is key to providing ETS priori

28、ty in the DSL Access Network. There are two areas that need to be addressed. The BNG needs to give priority to ETS requests for assignment of DSL access resources and it needs to give priority to transmission of ETS traffic. When the BNG receives a request from the Policy Server/PDP to create or act

29、ivate service flows, it needs to recognize the ETS-related requests and process them with priority. 6.1.3.3.1 General Requirements The Priority-Level AVP (as part of the Allocation-Retention-Priority ARP AVP) provides the priority level for an ETS call/session. Values 1 to 8 are assigned for service

30、s that are authorized to receive prioritized treatment within an operator domain. If the Priority-Level AVP is included in a Diameter message and populated with a value that is associated with an ETS call/session, then the message receives priority processing at the FE. NOTE 1: Values 2 (highest) to

31、 6 (lowest) of the Priority-Level AVP are used for an ETS call/session. NOTE 2 The Pre-emption-Capability AVP and Pre-emption-Vulnerability AVP (if received as part of the ARP AVP) are not applicable. The use of these AVPs in non-3GPP specified networks is for further study. NOTE 3 The use of the QC

32、I AVP in non-3GPP specified networks is for further study. The BNG shall support the Priority-Level AVP as specified in Q.3303.3 for ETS call/session processing. 6.1.3.3.2 Priority Treatment Requirements ATIS-1000059.2017 12 Priority treatment for an ETS call/session applies to (a) call/session proc

33、essing, (b) processing and transport of Diameter and SIP signaling messages related to the call/session, and (c) processing and transport of media packets related to the call/session. Priority treatment for ETS call/session processing includes (1) exemption of ETS calls/sessions and related signalin

34、g messages from Machine Congestion Control (MCC) and (2) priority Call Admission Control (CAC) for ETS calls/sessions. In addition, priority treatment for ETS service includes enhanced call/session routing capabilities beyond those provided for normal calls/sessions. A BNG shall apply the procedures

35、 of Q.3303.3 for the processing of the Priority-Level AVP in a received Diameter Re-Auth-Request (RAR) message. Based on the presence of a Priority-Level AVP value that is associated with ETS in the Diameter RAR message, a BNG shall mark the call/session accordingly, and apply the priority treatment

36、 specified in through for an ETS call/session. When applies (i.e., when a Priority-Level AVP value that is associated with ETS is received in the Diameter RAR message), the BNG stores the policy information received from the Policy Server/PDP, and applies the policy to subsequent packets related to

37、the selected call/session. The BNG responds to the Policy Server/PDP with a Diameter Re-Auth-Answer (RAA). A BNG is configured with an IP header DiffServ Code Point (DSCP) value to be used for the IP packets it generates to carry SIP and Diameter signaling messages related to an ETS call/session. It

38、 should be noted that the Policy Server/PDP is the FE authenticating the ETS call/session and notifying the BNG through a Diameter RAR message that a given signaling flow is to be provided with the DSCP value. A BNG shall set the IP header DSCP value to the provisioned DSCP value for the IP packets

39、it generates to carry Diameter and SIP messages that are related to an authenticated ETS call/session. A BNG is configured with an IP header DSCP value to be used, based on the Priority-Level AVP, and policy received from the Policy Server/PDP, for the IP packets it generates to carry RTP and data p

40、ayload related to an ETS call/session. It should be noted that the Policy Server/PDP is the FE authenticating the ETS call/session and notifying the BNG through a Diameter RAR message that a given media or data flow is to be provided with the DSCP value. A BNG FE shall set the IP header DSCP value t

41、o the provisioned DSCP value for the IP packets it generates to carry RTP media packets that are related to an authenticated ETS call/session. For an Ethernet interface with Class Of Service (COS) capabilities, the following requirement applies for an ETS call/session. In this case, the BNG is confi

42、gured with an Ethernet Frame Header COS parameter value (the “ETS” COS value) to be used for an ETS call/session. For the Ethernet COS capabilities on the BNG, the BNG shall set the Ethernet Frame Header COS parameter on the Ethernet interface to the provisioned “ETS” COS value for an authenticated

43、ETS call/session. ensures that the Ethernet Frame Header COS parameter is set to the “ETS” COS value for the Ethernet frames containing signaling, RTP payload and data related to an ETS call/session. allows priority treatment to be provided to these frames through the Ethernet. It is expected that t

44、he “ETS” COS value provides the highest priority treatment appropriate for user signaling and bearer on the interface. The BNG provides ingress priority treatment and egress priority treatment (e.g., priority outgoing queuing and scheduling) for Ethernet frames with the “ETS” COS value. When the BNG

45、 receives IP packets destined toward the UE, the BNG passes the packets without changing the DSCP value. If the Virtual Channel to the UE has already been established, no ETS-specific handling is required. If the Virtual Channel has not already been established and the incoming packet is marked with

46、 a DSCP value associated with ETS, the BNG should provide priority treatment in establishing the Virtual Channel, since the ETS nature of the call/session has already been authenticated. ATIS-1000059.2017 13 When the BNG receives IP packets destined toward the Core Network, the BNG does one of the f

47、ollowing, based on whether it has received a Priority-Level AVP value that is associated with ETS from the Policy Server/PDP for the call/session: Pass the packets with the DSCP value unchanged, because it has not received a Priority-Level AVP value that is associated with ETS from the Policy Server

48、/PDP for the call/session and the received DSCP value does not indicate this is an ETS call/session. Modify the packets to be marked with the provisioned default DSCP value for the traffic type (e.g., BE or Expedited Forwarding EF), if the received DSCP value indicates this is an ETS call/session, b

49、ut no Priority-Level AVP value that is associated with ETS has been received from the Policy Server/PDP for the call/session. Modify the packets to be marked with the appropriate DSCP value if it has received a Priority-Level AVP value that is associated with ETS from the Policy Server/PDP for the call/session. A BNG receiving IP packets directed toward the Core Network shall set the IP header DSCP value based on the classification rules received from the Policy Server/PDP. The BNG shall: Pass the packets with the DSCP value unchanged