1、 AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-1000023.2013 ETS NETWORK ELEMENT REQUIREMENTS FOR NGN IMS-BASED DEPLOYMENTS As a leading technology and solutions development organization, ATIS brings together the top global ICT companies to advance the industrys most-pressing business priori
2、ties. Through ATIS committees and forums, nearly 200 companies address cloud services, device solutions, emergency services, M2M communications, cyber security, ehealth, network evolution, quality of service, billing support, operations, and more. These priorities follow a fast-track development lif
3、ecycle from design and innovation through solutions that include standards, specifications, requirements, business use cases, software toolkits, and interoperability testing. ATIS is accredited by the American National Standards Institute (ANSI). ATIS is the North American Organizational Partner for
4、 the 3rd Generation Partnership Project (3GPP), a founding Partner of oneM2M, a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications sectors, and a member of the Inter-American Telecommunication Commission (CITEL). For more information, vi
5、sit . 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 been met by the standards developer. Consensus is established when, in the judgment of the ANSI Board of Standards
6、 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. Consensus requires that all views and objections be considered, and that a concerted effort be made towards thei
7、r 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 manufacturing, marketing, purchasing, or using products, processes, or procedures not conforming to the standards.
8、 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 the right or authority to issue an interpretation of an American National Standard in the name of the American N
9、ational 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 American National Standard may be revised or withdrawn at any time. The procedures of the American National Standard
10、s 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 standards by calling or writing the American National Standards Institute. Notice of Disclaimer Technical Specificati
11、on Group Services and System Aspects; Priority service guide; (Release 6).99This document is available from the Third Generation Partnership Project (3GPP) at . ATIS-1000023.2013 6 ANSI TIA-917, Wireless Priority Service Enhancements for CDMA Systems. 104 Network Architecture Model The ATIS NGN Arch
12、itecture Technical Report ATIS-1000018 defines a detailed functional architecture, based on the IMS architecture for the NGN, including definitions of the functional entities as shown in Figure 1. This architecture is independent of the services and access technologies being supported and can be ins
13、tantiated in customized architectures designed in the context of specific services offered and the technologies used. OtherIPNetworksASP-MwMwMxMrMiDxSh/SiRf/RoPSTN/ISDNMiUEMgMjGmISCCxDhIcRf/RoCxIbIwIdPSTNMGCFI-CSCFHSSS-CSCFMRFCMwSLFCharging FunctionSGFIWFI-BGFASIBCFMRFP T-MGFCSCFMSA-BGFPSTNGWBGCFSIP
14、H.248DIAMETEROtherMRB*PDFGqGqSB*S/I-CSCF* Specialized AS* Also known as a SCIMNote: PDF interfaces between two interconnecting networks are not shown.MpGoMnRf/RoRf/RoRf/RoMxDxInter-connectSBCAccessSBCA2A13rdPartyApplicationsANIFigure 1 NGN Reference Architecture 10This document is available from the
15、 Telecommunications Industry Association (TIA). ATIS-1000023.2013 7 The architecture as shown in Figure 1 bundles logical functions into network elements. The requirements in this document are for the following Network Elements: Network Element Functions PSTN Gateway MGCF, T-MGF, and SGF, and option
16、al BGCF IPBE (Access SBC) P-CSCF or If the calling users priority level is available, both ets.x and wps.y namespaces are created in the RPH, where y is set to the calling users priority level and x is based on policy. The value for the ets namespace may be provisioned to be either a default value,
17、or the value associated with the wps namespace. The default of the provisionable value for the ets namespace is 0. “DF” refers to the provisioned default value. WPS authentication This type of authentication is invoked when the calling user dials a WPS-FC+DN. i. If the call/session is authenticated
18、in the TDM domain, after the call is authenticated: The CPC parameter in the IAM is set to “NS/EP Call”. If the calling users priority level is available, the Precedence parameter is included in the IAM and the Precedence level (in the Precedence parameter) indicates the user priority level (precede
19、nce level 0 4 corresponding to user priorities 1 5). WPS authentication in the IP domain (e.g., for UMTS phones) is not addressed in this document. Successful ETS authentication may result in changing the values in the ets or wps namespaces. 2. The ets namespace indicates an ETS (including a WPS) ca
20、ll/session. i. For a call traversing from a circuit-switched network to an IP network, the Ingress IP Gateway (IIP-GW) creates the SIP RPH ets namespace based on the presence of ETS-DN in the Called Party Number parameter or the Calling Partys Category parameter coded as “NS/EP Call” in the received
21、 IAM. The IIP-GW assigns the ets priority level. It is mandatory for the IIP-GW to support a provisionable default value for the ets priority level. The default value for the ets priority level is determined by policy. If no ISUP Precedence parameter is received, the default value is used to populat
22、e the ets priority level. If a Precedence parameter is received, then, based on policy, either the default value or the precedence level in the Precedence parameter is used to populate the ets priority level. 11Policy is defined by DHS/NCS. ATIS-1000023.2013 9 An ETS Authentication Application Serve
23、r (AS) may modify the value of the received ets priority level based on a successful Authentication Verification Processing. An ETS Authentication Application Server (AS) rejects the call/session request if authentication or authorization is denied. If the call cannot be authenticated (e.g., due to
24、an inability to access the authorization database in a timely manner), the Authentication AS treats the call/session request as authorized, and logs the request for subsequent analysis. If an ETS-compliant entity cannot access the ETS Authentication AS for call/session authorization (e.g., due to a
25、network failure), it treats the call/session request as authorized, and logs the request for subsequent analysis. 3. A successfully authenticated WPS call/session includes the RPH with the ets namespace. In addition to the ets.x, the RPH for a successfully authenticated WPS call/session contains the
26、 “wps.y” namespace with the priority level (y) associated with the calling WPS user. For a WPS call/session traversing from a circuit-switched network to an IP network, the IIP-GW maps the precedence level in the received Precedence parameter, containing an approved WPS MLPP Service Domain, to the p
27、riority value in the wps namespace. The precedence level is determined during authentication of the WPS user. The presence of the ets namespace indicates an ETS or a WPS call/session and triggers priority treatment. However, the priority value (x) in the “ets.x” may be used for priority treatment on
28、ly in the IP domain and is not used for priority treatment on the wireless access. The wps namespace value (y) is used for priority treatment on the wireless access. 4. The wps.y namespace is transported through the IP domain to facilitate priority treatment on the wireless egress access. i. An ETS
29、Authentication Application Server (AS) may modify a received wps priority level or, if a wps namespace is not received, create a wps namespace based on Authentication Verification Processing. ii. For a call/session traversing from an IP network to a circuit-switched network, the Egress IP Gateway (E
30、IP-GW) shall use the priority level in the wps namespace, if present, to populate the precedence level and MLPP Service Domain of the Precedence parameter in the outgoing ISUP IAM. iii. For a call/session traversing from an IP network to a circuit-switched network, if the ets namespace is present bu
31、t the wps.y namespace is not present, the EIP-GW shall not send the Precedence parameter in the outgoing ISUP IAM. 5. Processing of ETS calls/sessions, including the associated signaling and media, are provided priority treatment over non-ETS calls based on the presence of ets.x. 6. The ets.x RPH pr
32、iority value may be used for priority treatment of ETS traffic at certain interfaces, such as IP access-to-core and IP network-to-network interfaces, where connection admission control may be applied. 7. The ets.x RPH priority value may be used by SIP proxies and Back-to-Back User Agents (B2BUAs) to
33、 make routing decisions, particularly on IP access. 8. Based on policy, the Session Border Control function (CCFE and BFE) facing a user may modify a received RPH ets priority level by replacing the received level with the provisioned default value. i. The SBC function may reject a call with an ets
34、RPH if the interface is not provisioned to accept call requests with an ets RPH. ETS calls using an ETS destination number are permitted across such interfaces. 9. All packets associated with an ETS call/session shall receive priority handling: i. In network element queues; ii. For access to the IP
35、backbone; and iii. Within the IP backbone. This priority handling is based on the presence of an ets namespace in an RPH. ATIS-1000023.2013 10 10. A secure mechanism that validates the identity of the far end sending network is required in order to support priority handling of packets on an IP-NNI.
36、11. The interaction between NEs in the processing of errored ets namespace RPHs was based on identifying errors during testing and normal operation by terminating the session request. This approach was seen as allowing the problem NE to be identified and fixed before an NS/EP event occurred. Removin
37、g the ets and wps namespaces and using the default ets namespace value are also specified as configuration options for errored headers. Selection of the appropriate configuration option shall be via contractual arrangement between the NCS and the service provider. 6 Network Element Protocol Requirem
38、ents 6.1 General Requirements All SIP capable VoIP elements support the following SIP RPH general requirements. These requirements address the general handling of SIP with RPH headers. The SIP RPH capability shall be configurable as either enabled or disabled. The default is disabled. An enabled SIP
39、 RPH capable VoIP NE (RPH VoIP NE) shall receive and act upon the SIP RPH header as specified in the NE specific requirements for that NE. If a VoIP NE does not understand or process (e.g., the SIP RPH capability is disabled) the RPH field in a request or response, the VoIP NE shall ignore that head
40、er field, continue processing the message, and propagate the RPH unchanged. An enabled SIP RPH capable VoIP NE shall format the Resource Priority Header field as follows: Resource-Priority: namespace1.value1, namespace2.value2, or Resource-Priority: namespace1.value1 Resource-Priority: namespace2.va
41、lue2 or Resource-Priority: namespace1.value1, namespace3.value3 Resource-Priority: namespace2.value2, . . ATIS-1000023.2013 11 A particular namespace shall not appear more than once in the same SIP message. For the ETS service, an ets namespace shall be present, with or without a wps namespace. The
42、presence of a wps namespace without an ets namespace shall be processed as an error. An enabled SIP RPH capable VoIP NE shall be able to generate the Accept-Resource-Priority header. The Accept-Resource-Priority field shall have the form: Accept-Resource-Priority: namspace1.value1, namespace1.value2
43、, NOTE: The “Accept-Resource-Priority” response header field enumerates the resource values (r-values) a SIP user agent server is willing to process. For recognized ETS calls, an enabled SIP RPH capable VoIP NE shall insert the RPH into the following SIP messages: INVITE, ACK, BYE, CANCEL, INFO, PRA
44、CK, REFER, UPDATE. For recognized ETS calls, an enabled SIP RPH capable VoIP NE shall insert the RPH in 1xx, 2xx, 3xx, 4xx, 5xx, and 6xx responses it sends, with the exception of 100 (“trying”) responses and a 403 (“forbidden”) message as specified in . For messages associated with error conditions
45、(e.g., 400 error messages with a 417 reason code, 417 messages, and 420 messages), the RPH shall carry only the ets.x. The RPH shall be inserted even if the received response from an upstream network element may not include an RPH. An enabled SIP RPH capable VoIP NE shall send the “Supported” header
46、 field with the “resource-priority” option tag in an initial SIP request with the ets namespace. NOTE: Due to potential interoperability problems, it is not recommended to send the “Required” header field with the “resource-priority” option tag. ATIS-1000023.2013 12 A VoIP NE shall be able to receiv
47、e a 182 (Queued) response from a VoIP NE that is currently at capacity, but that has put the original request into a queue. When an enabled SIP RPH capable VoIP NE receives a 417 (Unknown Resource Priority) response or a 420 (Bad Extension) response with an “Unsupported: resource-priority” to the in
48、itial SIP request with the “Require” header field (including the “resource-priority” option tag) and the ets namespace, the enabled SIP RPH capable VoIP NE shall: 1. Log the request and response as an error condition; 2. Attempt to send the request to the next VoIP NE in the route list; and 3. If al
49、l attempts receive a 417 response, the enabled SIP RPH capable VoIP NE shall resend the request without the “Require” header field, but with a “Supported” header field with the “resource-priority” option tag. For an enabled SIP RPH capable VoIP NE, use of the “resource-priority” option tag with the “Require” header field shall be configurable (i.e., enabled or disabled), with a default setting of disabled. NOTE: According to RFC 3261, if a 420 (Bad Extension) response is received, the sending NE may retry the request, omitting any extens
