ATIS-0x0000x
ATIS-0x0000x
ATIS Standard on
Next Generation Interconnection Interoperability Forum (NGIIF)
NGN Reference Document
NGN Convergence
Secretariat
Alliance for Telecommunications Industry Solutions
Approved Month DD, YYYY
Abstract
This document is XXX.
Foreword
The Alliance for Telecommunication Industry Solutions (ATIS) serves the public through improved understanding between carriers, customers, and manufacturers. The Next Generation Interconnection Interoperability Forum (NGIIF) addresses next-generation network interconnection and interoperability issues associated with emerging technologies. Specifically, it develops operational procedures which involve the network aspects of architecture, disaster preparedness, installation, maintenance, management, reliability, routing, security, and testing between network operators. In addition, the NGIIF addresses issues which impact the interconnection of existing and next generation networks and facilitate the transition to emerging technologies.
Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, Next Generation Interconnection Interoperability Forum (NGIIF) Secretariat, 1200 G Street NW, Suite 500, Washington, DC 20005.
At the time of initiation/issuance this document, Next Generation Interconnection Interoperability Forum (NGIIF), which was responsible for its development, had the following roster:
[COMMITTEE LIST]
Working Document Revision History
Note: This section is being used to track the revisions made to this working document prior to publication, as changes are being made to the working document through several issues. As the document nears completion, this revision history will be cleared and will be used according to the ATIS documentation structure template.
Date / Version / Description / Author /08/02/10 / This document was accepted as a generic framework template on August 2, 2010. This document contained basic headers with a suggestion that participants submit contributions to populate the text. / AT&T & ATIS
04/29/11 / Text added to describe the effects of transition to NGN on NS/EP priority services / NCS
10/03/11 / Contribution related to closure of issue 8 hop counters new and existing text placed in section 6 below, we may want to discuss placing this in section 4 as a better fit. / AT&T
Table of Contents
[INSERT]
Table of Figures
[INSERT]
Table of Tables
[INSERT]
5
ATIS-0x0000x
1 Scope, Purpose, & Application
1.1 Scope
xxx
1.2 Purpose
xxx
1.3 Application
xxx
2 Normative References
The following standards contain provisions which, through reference in this text, constitute provisions of this American National Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this American National Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below.
T1.xxx-YYYY, Title.[1]
3 Definitions, Acronyms, & Abbreviations
3.1 Definitions
3.1.1 Aaaa: xxxx
3.1.2 Bbbb: xxxx
3.2 Acronyms & Abbreviations
ATIS / Alliance for Telecommunications Industry Solutions4 NCS GETS and WPS Transition to NGN Priority Services
As the telecommunications industry consolidates facilities in its transition from circuit to packet switching technology, the National Communications System (NCS) managed Government Emergency Telecommunications (GETS) and its wireless counterpart, Wireless Priority Service (WPS), will transition to Next Generation Network (NGN) Priority Services. NGN will include voice, video, and data priority services. Some of the areas associated with priority services that will need to be considered during industry consolidation and transition activities include the following:
NGN Priority Services are expected to operate under a broad range of circumstances, from widespread damage to the network resulting from natural or man-made disasters up to and including nuclear war. NGN Priority Services should be implemented so they are at least as survivable or endurable as the networks upon which they are implemented.
The technologies used for facilities consolidation will impact what NGN Priority Services will need to be implemented. To achieve priority for a connection-oriented service in an IP network, the signaling protocol used for setting up the connection (e.g., SIP) should use its priority parameters (e.g., SIP Resource Priority Header) to assign priority to both signaling and transport packets. That is to say, the signaling protocol should mark the Differentiated Services (DiffServ) Code Point (DSCP) in the IP packet header and/or assign priority-reserved routes in a multiprotocol label-switched (MPLS) implementation. Facilities consolidation activities present the potential of adversely affecting the number of available diverse priority-reserved routes that can be assigned.
In a fiber network, QoS capabilities will likely be used to provide priority to NGN Priority Service connections. In these networks, the policy server will be an “NGN Priority Services-aware” device and it will need to set the appropriate priority flows using existing QoS capabilities. Similarly, to achieve priority within carrier Ethernet technology solutions, the policy server will need to transmit policy to the appropriate Ethernet switches and gateways. These elements will need to be able to identify the NGN Priority Services traffic, assign the appropriate class of service (COS) or DSCP to the traffic, and handle the traffic with priority. Facilities consolidation activities will need to account for these policy functions and allow for sufficient diversity and robustness of the effected network elements (e.g., the policy servers) to meet the NGN Priority Services’ needs.
Across all technologies, NGN Priority Service connections should be provided exemption from overload controls and given priority queuing for resources. Consolidation notwithstanding, sufficient resources need to be provided to allow for the proper functioning of NGN Priority Services without extensive and extended queuing.
Carrier interconnection/interoperability will need to support NGN Priority Services. For example, carriers will need to establish trust relationships with interconnected peer carriers to ensure NGN Priority Services calls maintain priority across networks. As the barriers to entry decline and the number of interconnected carriers increase, establishing and maintaining trust relationships with an ever-increasing number of peer networks will become a serious challenge. Additionally, NGN Priority Services-compliant carriers will be required to test the interoperability of service features and priority parameters (e.g., SIP RPH) with peer networks, and to ensure NGN Priority Services connections are exempt from procedures that throttle inter-network messaging (e.g., to control overload).
Current circuit-based priority telecommunications features and services will gradually disappear as industry phases out segments of the networks. NGN Priority Services’ efforts will focus first on migrating GETS and WPS voice telephony features into the new infrastructure. Future efforts, however, will take advantage of the high bandwidths offered by the NGN to define additional priority telecommunications services such as video teleconferencing, and support data services such as Internet access and e-mail. During the transition, a hybrid circuit-switched/packet-switched communications environment will require the interoperation of legacy GETS and WPS with the new NGN Priority Services, permitting NS/EP users to use these services interchangeably and transparently. In the long-term, legacy services might eventually be replaced completely by the new NGN Priority Services capabilities.
The NCS strategy for migrating GETS and WPS to NGN Priority Services will be impacted by the pace of development and deployment of NGN Priority Services-capable network elements, the build-up of new transmission facilities (IP, fiber, Ethernet), and the availability of operations support systems to support the new infrastructure. The NCS will monitor these key areas and coordinate with industry during the migration to the rich capabilities offered by the NGN.
4 TDM to IP to TDM
xxx
4.1 Subclause title
xxx
4.1.1 Subsubclause title
xxx
5 IP to TDM to IP
xxx
5.1 Subclause title
xxx
5.1.1 Subsubclause title
xxx
6 SS7 to IP Mapping
xxx
This section might also be appropriate or more appropriate for section 4 above.
6.1 Hop Counters, Max Forwards, Redirection Information (RI), History Information
New Text:
VERY Rough (just initial words/ideas):
There are SS7 parameters that will or won’t map over to the IP networks. Some of the SS7 parameters that do map over to the IP networks may not transition back to the SS7 network. During the transition from TDM to IP many of the existing SS7 parameters are still valid and necessary. Complications may arise during convergence with parameters which don’t transition between networks, especially when transitioning between technologies/networks more than once.
Noted below are some of the existing SS7 parameters and agreements which are still valid, identification/discussion of a few IP parameters, recognition of some identified issues between networks and interim recommendations.
Existing text from ATIS-0300011, Section 5, Trunk Responsibilities, B. Conversion of Multi-Frequency Trunks to SS7:
Interconnecting parties should exchange the initial value of the Hop Counter at the time of negotiation for interconnection and as changes are anticipated/made in signaling between the two networks.
If no hop counter is received with the incoming IAM, then if the hop counter capability is active, a non forwarding transit exchange should include the hop counter parameter in the outgoing Initial Address Message. For technologies where the hop counter can not be set on a per call type basis and for non-ETS calls, the network operator should set the initial count value within a range between 15 and 20. In addition, if the initial count value can be set by the network operator on a per-call type basis, then the initial count value for ETS calls should be the maximum value allowed in the exchange.
The value received should be accepted as a valid value, and the recipient switch should not reinitialize the Hop Counter. For SIP-I, the I-IWU acting as an independent exchange should perform the normal BICC/ISUP Hop Counter procedure using the Hop Counter taken from the encapsulated IAM.
Proposed text from Issue 008 closure
The NGIIF has looked at customer call forwarding/call looping issues and the related network parameters (such as the HOP counters, max forwards in an IP network, redirection information [RI], history information) which are available in either the TDM or IP networks. The current state of the implementation in the industry will not support a full resolution of problems induced by customer call forwarding using these capabilities; therefore, the NGIIF offers the following recommendations in addition to the recommendations listed in ATIS-0300011, Part III, Installation and Maintenance Responsibilities for SS7 Links and Trunks:
· Network providers should review the use of simultaneous call forwarding restrictions that limits the number of times calls can be forwarded through a single line.
· Service providers should review their services to determine whether they easily allow configurations that can generate call looping. For example, it might be desirable to design restrictions so that a customer can’t simultaneously forward their mobile calls to their land line at that same time their land line is forwarding calls to their mobile line.
May want note to refer back to ATIS-0300011 to keep future updates in alignment.
6.12 Treatment Codes/Recorded Announcements
xxx
6.12.1 Subsubclause title
xxx
7 Wireless
xxx
7.1 Subclause Title
xxx
7.1.1 Subsubclause title
xxx
5
[1] This document is available from the Alliance for Telecommunications Industry Solutions, 1200 G Street N.W.,
Suite 500, Washington, DC 20005. <http://www.atis.org