Signaling Architecture and Protocols for the Next Generation Network

8/10/2019 Signaling Architecture and Protocols for the Next Generation Network

1/6

Signaling Architecture and Protocols for the Next

Generation Network

Hyeong Ho Lee

Electronics and Telecommunications Research Institute (ETRI), [email protected]

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 internationalstandardization 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, andsignaling 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 ofservices. 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. Protocols need to

be standardized to provide the communication between

communicating functional entities. Interworkingbetween 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


2/6

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 functionalarchitecture 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 ascommunication services such as user authenticationand 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 whilemaintaining QoS and providing security. Theconnection points specified between the NGN and theoutside world are the User-Network Interface (UNI)for terminal connections, the Network-NetworkInterface (NNI) for connection with other NGNnetworks, and the Application-Network Interface

(ANI) for connection to applications.

Figure 1 NGN Architecture Overview

The service stratum provides Service ControlFunctions (SCF) to achieve basic communication

services. For this purpose, the ITU-T Recommendationallows the implementation of call-server models as well

as the IP Multimedia Subsystem (IMS) using session

initiation protocol (SIP). The transport stratumprovides Network Attachment Control Functions(NACF) and Resource Admission Control Function(RACF). NACF performs functions such as IP-addressassignment, authentication, and registration of user andterminal. RACF decides, based onnetwork availability,

whether each session setup request to be accepted and,

if accepted, guarantees a stable level of communication

quality until the session ends.

Generalized NGN functional architectureThe generalized NGN functional architecture shown in

Figure 2 [3] is based on the NGN architecture overview.

In this functional architecture, some Functional Entities

(FEs) include functions relating to the NGN servicestratum 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 andProtocols

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 MappingConsiderations 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 (FE) 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

Transport stratum

Service stratum

Control

Media

ManagementFunctions

Management

ANI

Transport Control Functions

Resource andAdmission

Control Functions

Network AttachmentControl Functions

Network AttachmentControl Functions

NNIUNI

Application Support Functions & Service Support Functions

Applications

Transport Functions

End-User

FunctionsOther

Networks

Service Control

FunctionsService User

ProfilesService User

Profiles

Transport UserProfiles

Transport UserProfiles

ISBN 978-89-5519-139-4 -1692- Feb. 15-18, 2009 ICACT 2009


3/6


4/6

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.

Table 1. Interfaces and Protocols of SCE

Interfaces Protocols

A-S1 (S-14 MRB-FEASF/SSF) SIP, SOAP,HTTP

A-S3 (S-13 MRC-FEASF/SSF) SIP

A-S4 (S-1 S-CSC-FEASF/SSF) SIP

A-S5 (S-6 SAA-FEASF/SSF) Diameter

A-S6 (S-4 SL-FEASF/SSF) Diameter

A-S6 (S-5 SUP-FEASF/SSF) Diameter

S-1 S-3, S-1 S-2, S-2 S-3, S-1 S-7, S-2

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

SIP

S-1 S-5, S-1 S-6, S-3 S-5, S-3 S-6, S-1

S-4, S-3 S-4

Diameter

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

Diameter

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 multimediaNetworks

SIP

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]

Diameter: Diameter Base Protocol [IETF RFC 3588] [10]H.248: Gateway 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 RACFThe 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

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.

Figure 4. Generic Functional architecture for resource

and admission control in NGN

Table 2. Interfaces and Protocols of RACE


Rs, Rt, Rd, Ri Diameter

Rp RCIP

RwCOPS-PR

H.248

Diameter

Rc COPS-PR

SNMP

Rn Interface is for further

study

NOTES:

Diameter: Diameter 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 NACFThe 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


5/6

Transport Functions

OtherNGNs

PD-FE

AR-FE

CPE

HGWC-FE

TUP-FE

AM-FE

NAC-FE

TC-Ux

TC-T1

Na Nd

Nk

NeNc

Nb

Nx

Service Control Functions

S-TC1

TAA-FE

Ni

TLM-FE

Ng

T-U1

TE HGW

RACFNACF

PE-FE

Ru

Figure 5. Generic Functional Architecture for Network

Attachment Control in NGN

Table 3. Interfaces and Protocols of NACE


Ng, Ru, S-TC1 Diameter

NiRADIUS or DiameterTo be selected

Nd, Ne, Na, Nc, Nk, Nx,Nb, TU1, TC-T1, TC-Ux

Interface is for furtherstudy

NOTES:

Diameter: Diameter 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 SetIn 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 completionspecified. 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 RecommendationY.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

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 SetIn 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 ofthe 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 theNGN 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, NGNProtocol 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 NGNCapability 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 provideIPTV 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


6/6

The followings are future works to be done for the NGN

protocol development:

Development of the signaling architecture andrequirements to support the NGN Release 2

architecture and IPTV.

Session control requiring further work on SIP-basedprofiles 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 transfercapability.

Resource control for developing additional interfaceprotocols fitting with the RACF enhanced

architecture.

Development of signaling requirements andprotocols to support NGN network attachment, user

identification, number portability, and mobility

procedures to both service and transport stratum.

Development of signaling protocols to supportEmergency Telecommunications Service (ETS),

Telecommunications Disaster Relief (TDR), andearly 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 signalingand protocols.

Development of test specifications for Network

aspects of Identification systems including RFID

(NID) and Ubiquitous Sensor Network (USN).

6. Conclusion

In this paper, we introduced overview and functional

architecture of ITU-T NGN, and presented signalingarchitecture 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.

REFERENCES

[1] ITU-T Recommendation Y.2001 (12/2004), General overview ofNGN.

[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 atITU-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 ProtocolVersion 1.2.

[9] IETF RFC 2616 (1999), Hypertext Transfer Protocol HTTP/1.1.

[10]IETF RFC 3588 (2003), Diameter Base Protocol.[11]ITU-T Recommendation H.248.1 (09/2005), Gateway Control

Protocol: Version 3.

[12]ITU-T Recommendation Q.700, (03/1993), Introduction toCCITT Signalling System No.7.

[13]ITU-T Recommendation Y.2111 (11/2008), Resource andadmission 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 controlprotocol 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 ApplicabilityStatements for Internet Standard Management Framework.

[19]ITU-T Recommendation Y.2014 (05/2008), Network attachmentcontrol 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.

ISBN 978-89-5519-139-4 -1696- Feb. 15-18, 2009 ICACT 2009

Documents

Signaling Architecture and Protocols for the Next Generation Network