Signaling Architecture and Protocols for the Next Generation Network

Signaling Architecture and for the Next Generation Network Hyeong Ho Lee Electronics and Telecommunications Research Institute (ETRI), Korea holee@etri.re.kr Abstract ITU-T (International Telecommunication Union, Telecommunication Standardization Sector) made remarkable achievement in international standardization of the Next Generation Network (NGN) during the last Study Period (2005~2008). This paper gives a brief overview and functional architecture of ITU-T NGN, and presents signaling architecture and protocols for the ITU-T NGN. Keywords NGN, Signaling, Protocol, ITU-T. 1. Introduction During the last study period (2005~2008) of ITU-T, ITU-T made remarkable achievement in international standardization of the Next Generation Network (NGN). The NGN defined by ITU-T is a packet-based network able to provide Telecommunication Services to users and able to make use of multiple broadband, QoS-enabled transport technologies and in which service-related functions are independent of the underlying transport-related technologies. It enables unfettered access for users to networks and to competing service providers and services of their choice. It supports generalized mobility which will allow consistent and ubiquitous provision of services to users [1]. NGN services include multimedia services, such as conversational services, and content delivery services, such as video streaming and broadcasting. The aim of NGN is to support PSTN/ISDN replacement. Therefore, the NGN provides support for PSTN/ISDN emulation as well as PSTN/ISDN simulation. NGN Release 1 assumes the implementation of session-based communication. Release 2 aims for the provision of IPTV (Internet protocol television) and implementation of true mobility. ITU-T formed NGN-related joint Study Group (SG) system that included Study Groups such as SG13 (Next Generation Network), SG11 (signaling protocols), SG19 (mobile networks), and SG17 (security issues), and has been holding regular meeting called the NGN Global Standards Initiative (NGN-GSI) since 2006. As a result, ITU-T produced Recommendations related to the NGN such as ITU-T Rec. Y.2000-series, Q.1700-series, and Q.3000-series. Following this introduction, we explain overview and functional architecture of the NGN in Section 2, and signaling architecture and protocols for the NGN in Section 3, and then finally describe concept of the NGN Protocol Set, future work, and conclusion. 2. NGN Architecture NGN shall provide the capabilities (infrastructure, protocols, etc.) to make the creation, deployment and management of all kinds of services (known or not yet known) possible. This comprises of services using different kinds of media (audio, visual, audiovisual), with all kinds of encoding schemes and data services, conversational, unicast, multicast and broadcast, messaging, simple data transfer services, real-time and non-real-time, delay-sensitive and delay-tolerant services. NGN should be comprised of service related APIs (Application Programming Interfaces) in order to support the creation, provisioning and management of services. One of the main characteristics of NGN is the decoupling of services and transport, allowing them to be offered separately and to evolve independently. Therefore in the NGN architectures, there shall be a clear separation between the functions for the services and the functions for the transport. NGN allows the provisioning of both existing and new services independently of the network and the access type used. In NGN the functional entities controlling policy, sessions, media, resources, service delivery, security, etc., may be distributed over the infrastructure, including both existing and new networks. When they are physically distributed, they communicate over open interfaces. Consequently, the identification of reference points is an important aspect of NGN. need to be standardized to provide the communication between communicating functional entities. Interworking between NGNs of different operators and between NGN and existing networks such as PSTN (Public Switched Telephone Network), ISDN (Integrated Services Digital Network) and GSM (Global System for Mobile communications) is provided by means of gateways. NGN will support both existing and "NGN aware" end terminal devices. Hence terminals connected to NGN will include analogue telephone sets, fax machines, ISBN 978-89-5519-139-4-1691- Feb. 15-18, 2009 ICACT 2009

ISDN sets, cellular mobile phones, GPRS (General Packet Radio Service) terminal devices, SIP [2] (Session Initiation Protocol) terminals, Ethernet phones through PCs (Personal Computers), digital set top boxes, cable modems, etc. Overview of the NGN architecture Figure 1 shows an overview of the NGN functional architecture that allows the support of the Release 1 services [3], [4], [5]. The NGN functions are divided into service stratum functions and transport stratum functions. An NGN communication service is implemented by integrating these two functions. The service stratum provides a variety of functions as communication services such as user authentication and registration, party discovery, and call condition negotiation as well as supplementary services to support and enhance those services. The transport stratum provides IP connectivity services to NGN users under the control of transport control functions. It transmits IP packets on an end-to-end basis while maintaining QoS and providing security. The connection points specified between the NGN and the outside world are the User-Network Interface (UNI) for terminal connections, the Network-Network Interface (NNI) for connection with other NGN networks, and the Application-Network Interface Management Functions End-User Functions UNI Service stratum Network Attachment Control Functions Transport stratum Transport Control Functions (ANI) for connection to applications. Control Management Figure 1. NGN Architecture Overview The service stratum provides Service Control Functions (SCF) to achieve basic communication services. For this purpose, the ITU-T Recommendation allows the implementation of call-server models as well as the IP Multimedia Subsystem (IMS) using session initiation protocol (SIP). The transport stratum provides Network Attachment Control Functions (NACF) and Resource Admission Control Function (RACF). NACF performs functions such as IP-address assignment, authentication, and registration of user and terminal. RACF decides, based on network availability, whether each session setup request to be accepted and, ANI Application Support Functions & Service Support Functions Service User Profiles Transport User Profiles Applications Service Control Functions Resource and Admission Control Functions Transport Functions NNI Other Networks if accepted, guarantees a stable level of communication quality until the session ends. Generalized NGN functional architecture The generalized NGN functional architecture shown in Figure 2 [3] is based on the NGN architecture overview. In this functional architecture, some Functional Entities (s) include functions relating to the NGN service stratum and the NGN transport stratum. The transport stratum covers transport functions and associated control functions up to the IP layer, and the service stratum includes functions that handle the layers above the IP layer. There are relationships between end-user functions and the transport stratum such as IP-based relationships, PSTN/ISDN relationships related to media transport, and some signaling relationships. The relationships between the end-user functions and service functions represent service protocol layer relationships. The relationships to the application functions represent application layer protocol relationships. 3. NGN Signaling Architecture and Based on the NGN functional architecture, ITU-T SG11 has been studying the NGN signaling system, focusing on NGN signaling requirements and architecture and protocols at internal and external interfaces of the NGN system. The major achievement is the completion and publication of some twenty Recommendations that constitute the NGN Protocol Set 1. They constitute a fundamental basis for initial implementations of first release of NGN. Principles of Mapping Considerations of scalability and domain independence that motivated the development of the functional architecture have been accepted for the realization of NGN signaling system. As a result, each Functional Entity () of the functional architecture is mapped to a separate type of Physical Entity (PE) [6]. Furthermore, each reference point is assumed to map to a separate interface. At a particular interface, one protocol from a set of recommended protocols may be used. Because the mapping between reference points and interfaces is one-to-one, each interface is named after the reference point to which it corresponds (e.g., Rs interface corresponding to the Rs reference point). Depending on the technology involved, some of the physical entities may be combined. In such a case, each combined entity will support the combined set of external interfaces of its component elements, and interfaces that would lie between the component elements if they were separate are absorbed into the interior of the combined entity Signaling Architecture for NGN SCF ISBN 978-89-5519-139-4-1692- Feb. 15-18, 2009 ICACT 2009

The signaling architecture for the NGN Service Control Entity (SCE) is based on the SCF of which generic functional architecture is shown in Figure 3 [3]. Management functions * Service control S-11: User Signaling Interworking NACF T-15: Home GateWay Configuration T-12: T. User Profile S-5: S. User Profile S-4: Subscription Locator S-2: Proxy Call Session T-13: T. Location management S-8: Access GW S-14: Resource Broker RACF Applications Application Support Functions & Service Support Functions (may include own Authentication, Authorization and Accounting) S-15: General Services T-16: Policy Decision T-17: Transport Resource S-6: S. Authentication & Authorization S-3: Interrogating Call Session S-1: Serving Call Session S-13: Resource RACF T-16: Policy Decision S-12: Network Signaling Interworking S-7: Interconnection Border S-10: Breakout Control S-9: GW T-17: Transport Resource Application ANI Other NGN IP Multimedia Networks NGN End-User UNI Function Legacy Terminal RGW Customer Network NGN Terminal Legacy Terminal T-1: Access T-11: T. Authentication &Authorization T-4: Access Relay T-2: Access Node T-10: Network Access Configuration T-14: Access Management Access transport T-3: Edge Node Access Packet Transport Functions Scope of NGN T-5: Access Border Core transport T-8: Resource Processing Core Packet Transport Functions Figure 2. Generalized Functional Architecture of NGN T-9: Signalling T-6: Interconnection Border T-7: Trunking PSTN/ISDN Application Support Functions & Service Support Functions A-S1 A-S2 A-S3 A-S4 A-S5 A-S6 S-U1 S-U2 Service Control S-11: User Signaling Interworking S-14: Resource Broker S-15 General Services S-2: Proxy Call Session S-6: Service Authentication & Authorization S-1: Serving Call Session S-5: Service User Profile S-4: Subscription Locator S-3: Interrogating Call Session S-12 Network Signaling Interworking S-7: Interconnection Border S-ON1 S-ON2 S-13: Resource S-8: Access Control S-10 Breakout Control S-9: S-ON3 S-TC1 S-TC2 S-T1 S-TC3 S-T2 S-TC4 S-T3 S-T4 S-TC5 S-T5 Figure 3. Generic Functional Architecture for Service Control in NGN ISBN 978-89-5519-139-4-1693- Feb. 15-18, 2009 ICACT 2009

Based on the principles of mapping, it identifies the Physical Entities (PEs), interfaces, and protocols that are required to model the SCE of the NGN [7]. This service control architecture supports SIP-based sessions and is independent of services. Table 1 shows the interfaces of service control entity and candidate protocols potentially for use in these interfaces. For example, Recommendations ITU-T Q.3401 and Amendment 1 to Q.3401 define the NGN NNI signaling profile (SIP/SDP and RTP profile) for the SCF at the NNI interface, between two NGN network operators, for voiceband, video, and data services. Recommendation ITU-T Q.3402 defines the NGN UNI signaling profile (SIP/SDP and RTP profile) for use between users and networks for voice, video and data services. mapping, it identifies the Physical Entities (PEs), interfaces, and protocols that are required to model the RACE of the NGN [6]. Table 2 provides mapping between the interfaces and the protocol specifications which realize these interfaces. Recommendations ITU-T Q.3300-series specify signaling and protocols at the interfaces for RACF. Table 1. Interfaces and of SCE Interfaces A-S1 (S-14 MRB- ASF/SSF) SIP, SOAP, HTTP A-S3 (S-13 MRC- ASF/SSF) SIP A-S4 (S-1 S-CSC- ASF/SSF) SIP A-S5 (S-6 SAA- ASF/SSF) A-S6 (S-4 SL- ASF/SSF) A-S6 (S-5 SUP- ASF/SSF) S-1 S-3, S-1 S-2, S-2 S-3, S-1 S-7, S-2 SIP S-7, S-3 S-7, S-7 S-10, S-1 S-10, S-3 S-10, S-2 S-10, S-1 S-9, S-3 S-9, S-1 S-13, S-2 S-13, S-7 S-13, S-9 S-10, S-2 S-11, S-7 S-12, S-10 S-10, S-1 S-8, S-3 S-8, S-9 S-13, S-13 S-10 S-1 S-5, S-1 S-6, S-3 S-5, S-3 S-6, S-1 S-4, S-3 S-4 S-9 T-7, S-13 T-8, S-7 T-6, S-8 T-1 H.248 S-2 T-16, S-7 T-16, S-8 T-16, S-2 T-13 S-9 T-9 SS7 over IP S-9 End user function SIP S-11 End user function - S-7, S-10 other NGN/IP multimedia SIP Networks S-12 other NGN/IP multimedia Networks - NOTES: SIP: Session Initiation Protocol [IETF RFC 3261] [2] SOAP: Simple Object Access Protocol [W3C Rec. (2007)] [8] HTTP: Hypertext Transfer Protocol [IETF RFC 2616] [9] : Base Protocol [IETF RFC 3588] [10] H.248: Control Protocol: Version 3 [ITU-T Rec. H.248 (09/2005)] [11] SS7: Signaling System No.7 [ITU-T Rec. Q.700 (03/1993)] [12] Signaling Architecture for NGN RACF The signaling architecture for the NGN Resource and Admission Control Entity (RACE) is based on the RACF of which generic functional architecture is shown in Figure 4 [13], [14]. Based on the principles of Figure 4. Generic Functional architecture for resource and admission control in NGN Table 2. Interfaces and of RACE Interfaces Rs, Rt, Rd, Ri Rp Rw Rc Rn RCIP COPS-PR H.248 COPS-PR SNMP Interface is for further study NOTES: : Base Protocol [IETF RFC 3588] [10] RCIP: Resource Connection Initiation Protocol [ITU-T Rec. Q.3302.1 (03/2007)] [15] COPS-PR: Common Open Policy Service Policy Provisioning [IETF RFCs 2748, 3084] [16], [17] SNMP: Simple Network Management Protocol [IETF RFC 3410 and many others] [18] Signaling Architecture for NGN NACF The signaling architecture for the NGN Network Access Control (NACE) is based on the NACF of which generic functional architecture is shown in Figure 5 [19]. Based on the principles of mapping, it identifies the Physical Entities (PEs), interfaces, and protocols that are required to model the NACE of the NGN. Table 3 shows the interfaces of NACE and candidate protocols potentially for use in these interfaces. Recommendations ITU-T Q.3200-series specify signaling and protocols at the interfaces for NACF. ISBN 978-89-5519-139-4-1694- Feb. 15-18, 2009 ICACT 2009

TE CPE TC-Ux HGW T-U1 TC-T1 HGWC- TUP- Ni Nb Nc TAA- Service Control Functions Na AR- NACF Nk AM- Nx S-TC1 TLM- Ne NAC- Nd Ng Ru RACF PD- PE- Transport Functions Figure 5. Generic Functional Architecture for Network Attachment Control in NGN Table 3. Interfaces and of NACE Interfaces Ng, Ru, S-TC1 Ni Nd, Ne, Na, Nc, Nk, Nx, Nb, TU1, TC-T1, TC-Ux RADIUS or To be selected Interface is for further study NOTES: : Base Protocol [IETF RFC 3588] [10] RADIUS: Remote Authentication Dial In User Service [IETF RFC 2865] [20] 4. Concept of NGN Protocol Set NGN Release and Capability Set In the last Study Period (2005~2008), ITU-T SG13 had adopted a release-based approach for the production of NGN Recommendations, with the scope of each release clearly defined and target deadlines for completion specified. Considering a priority of a market, ITU-T SG13 has adopted the concept of Capability Set that breaks down the release concept because necessary functional groups exist prior to a target completion date of Release. Capability Set includes requirements, architecture, and signaling aspects necessary to provide specific services. Release concept determines the scope of standardization in ITU and Capability Set specifies related Recommendations necessary for specific services [21]. ITU-T SG13 produced Recommendation Y.2006 (Description of capability set 1 of NGN release 1), and is now developing a new draft Recommendation Y.NGN-cap2 (Description of NGN capability set 2). NGN Capability Set 1 is mainly focused on basic telecommunication services. Since Capability Set 1 is a basic set of telecommunication, all the items that are covered in Capability Set 1 should be included in Capability Set 2. In addition, NGN Capability Set 2 Other NGNs should include the items that are necessary to provide IPTV service. A given specification of a given NGN Release can be categorized using three stages: service aspects (Stage 1), functional network aspects (Stage 2) and network implementation aspects (Stage 3). Whilst in principle, all services and capabilities defined in a given capability set of the NGN Release are to be specified to the Stage 3 level to ensure that the release is fully implementable, exceptions can be accepted. NGN Protocol Set In the last Study Period, the NGN Protocol Set 1 was a generic term referring to the set of NGN protocol recommendations produced by ITU-T SG11, without formal description of the relationship among the NGN Protocol Set, the NGN Release, and the NGN Capability Set. However, an overview recommendation is needed to ensure that the meaning and relationship of the NGN Protocol Set with the NGN Capability Set is clearly understood both inside and outside the ITU. Such a document would be useful for industry and would provide a guide to the scope and context of the NGN protocol recommendations. To define the concept of NGN Protocol Set, this paper proposes to map NGN Capability Sets to NGN Protocol Sets simply with a one-to-one correspondence because the NGN Capability Set 1 was already defined in ITU-T Rec. Y.2006 and Draft Recommendation of NGN Capability Set 2 is now available. In this context, NGN Protocol Set 1 includes all protocols for the support of NGN Capability Set 1, and the scope of NGN Protocol Set 1 is determined by the scope of NGN Capability Set 1. Similarly, NGN Protocol Set 2 covers all protocols to support NGN Capability Set 2, and the scope of NGN Protocol Set 2 is determined by the scope of NGN Capability Set 2. Therefore, ITU-T NGN-Protocol Set 1 includes protocols for the support of NNI and UNI session control, Resource Control Interfaces, and Network Attachment Interfaces. NGN Protocol Set 2 will cover all the protocols in NGN Protocol Set 1 and additionally all other protocols necessary to provide IPTV service. 5. Future Work on NGN Signaling After successful development of the initial version of the NGN Protocol Set 1 during the last Study Period (2005~2008), ITU-T SG11 will continue to develop NGN protocols during the present Study Period (2009~2012) to consolidate the initial versions on the basis of feedback from first NGN release implementations and new requirements. SG11 will address various additional features and consider initiating work in the scope of NGN Protocol Set 2. ISBN 978-89-5519-139-4-1695- Feb. 15-18, 2009 ICACT 2009

The followings are future works to be done for the NGN protocol development: Development of the signaling architecture and requirements to support the NGN Release 2 architecture and IPTV. Session control requiring further work on SIP-based profiles to improve interoperability at UNI and at NNI, as well as for supporting more simulated services and even more NGN-native services and applications. Bearer control for support of IPTV and multicast data delivery services, for support of more efficient transfer capabilities such as flow state aware transfer capability. Resource control for developing additional interface protocols fitting with the RACF enhanced architecture. Development of signaling requirements and protocols to support NGN network attachment, user identification, number portability, and mobility procedures to both service and transport stratum. Development of signaling protocols to support Emergency Telecommunications Service (ETS), Telecommunications Disaster Relief (TDR), and early warning systems as well as NGN testing and security Development of test specifications for protocols, services, and QoS of the NGN to ensure the compatibilities of equipment, services, and signaling and protocols. Development of test specifications for Network aspects of Identification systems including RFID (NID) and Ubiquitous Sensor Network (USN). [9] IETF RFC 2616 (1999), Hypertext Transfer Protocol HTTP/1.1. [10] IETF RFC 3588 (2003), Base Protocol. [11] ITU-T Recommendation H.248.1 (09/2005), Control Protocol: Version 3. [12] ITU-T Recommendation Q.700, (03/1993), Introduction to CCITT Signalling System No.7. [13] ITU-T Recommendation Y.2111 (11/2008), Resource and admission control functions in Next Generation Networks. [14] O. Kamatani, K. Kawakami, and S. Yamamoto, Standardization Activities for Resource and Admission Control Functions in Next Generation Networks, NTT Technical Review, Vol. 6, No. 12, 2008. [15] ITU-T Recommendation Q.3302.1 (03/2007), Resource control protocol No.2 Protocol at the Rp interface between transport resource control physical entities. [16] IETF RFC 2748 (2000), The COPS (Common Open Policy Service) Protocol. [17] IETF RFC 3084 (2001), COPS Usage for Policy Provisioning (COPS-PR). [18] IETF RFC 3410 (2002), Introduction and Applicability Statements for Internet Standard Management Framework. [19] ITU-T Recommendation Y.2014 (05/2008), Network attachment control functions in Next Generation Networks. [20] IETF RFC 2865 (2000), Remote Authentication Dial In User Service (RADIUS). [21] ITU-T Recommendation Y.2006 (02/2008), Description of capability set 1 of NGN release 1. 6. Conclusion In this paper, we introduced overview and functional architecture of ITU-T NGN, and presented signaling architecture and protocols for the ITU-T NGN. In addition, we discussed the concepts of NGN Release, NGN Capability Set, and NGN Protocol Set, and listed future work items for the NGN protocol development. RERENCES [1] ITU-T Recommendation Y.2001 (12/2004), General overview of NGN. [2] IETF RFC 3261 (2002), SIP: Session Initiation Protocol. [3] ITU-T Recommendation Y.2012 (09/2006), Functional requirements and architecture of the NGN release 1. [4] N. Morita, H. Imanaka, O. Kamatani, T. Oba, and K. Tanida, Overview and Status of NGN Standardization Activities at ITU-T, NTT Technical Review, Vol. 5, No. 11, 2007. [5] N. Morita and H. Imanaka, ITU-T NGN Release 1 Ready, NTT Technical Review, Vol. 6, No. 11, 2008. [6] ITU-T Recommendation Q.3300 (01/2008), Architectural framework for the Q.33xx series of Recommendations. [7] ITU-T Recommendation Q.3030 (02/2008), Signalling architecture for the NGN service control plane. [8] W3C Recommendation (2007), Simple Object Access Protocol Version 1.2. ISBN 978-89-5519-139-4-1696- Feb. 15-18, 2009 ICACT 2009