figure 2.doc

UG_STF_SC_05r2European Telecommunications Standards InstituteUSER-STF Steering Group Meeting12th – 13th January 2009, Sophia Antipolis - France

Contents1 NGN Context..........................................................................................................................31.1 User centric......................................................................................................................................41.2 Heterogeneous environment............................................................................................................51.3 General mobility..............................................................................................................................61.4 Conclusion.......................................................................................................................................9

2 User Case..............................................................................................................................10

3 Requirement for QoS continuity...........................................................................................12

4 Conclusion............................................................................................................................13

5 Discussion and next steps.....................................................................................................155.1 Control plane solution: QoS signalling..........................................................................................165.2 Management plane solution: QoS interworking............................................................................175.3 Converging solution: QoS continuity............................................................................................175.4 QoS informational structure...........................................................................................................17

Annex A: Current work for QoS.................................................................................................17

A.1. SLA.......................................................................................................................................18A.1.1 SLA definition...............................................................................................................................18A.1.2 SLA Life Cycle..............................................................................................................................18A.1.3 SLA Function.................................................................................................................................19A.1.4 Conclusion.....................................................................................................................................19

A.2. Mobility in homogenous network user-unaware..................................................................19

A.3. Heterogeneous environment and QoS..................................................................................21A.3.1 IMS Architecture (3GPP)..............................................................................................................22A.3.2 TISPAN NGN architecture............................................................................................................26A.3.3 QoS issue in the IMS--- Policy control management....................................................................28A.3.4 Diameter........................................................................................................................................31A.3.4.1 Policy Charging Convergence............................................................................................31A.3.4.2 Messages and AVPs...........................................................................................................32A.3.5 Conclusion.....................................................................................................................................35

A.4. E2E QoS signalling (among the same type of access network):..........................................36A.4.1 SIP..................................................................................................................................................36A.4.1.1 SIP basic functionalities...........................................................................................................37A.4.1.2 SIP entities...............................................................................................................................37A.4.1.3 SIP messages and procedure....................................................................................................38A.4.1.4 SDP..........................................................................................................................................39A.4.2 NSIS...............................................................................................................................................40A.4.2.1 Logic model and protocol messages [17].................................................................................41A.4.2.2 QoS Specifications and QoS Models.......................................................................................44

ETSI User Group;STF360;

Analysis of current E2E QoS standardization state

ETSI/USER-STF Steering Group Meeting UG_STF_SC_05r2Sophia Antipolis, 12 January 2009 page 2 of 68

A.4.2.3 Conclusion................................................................................................................................45

A.5. User interface to the heterogeneous network for QoS..........................................................45A.5.1 Customer Premises Network to TISPAN NGN.............................................................................46A.5.2 Service scenarios description.........................................................................................................48A.5.3 CPN architecture model interacting with the NGN/IMS networks...............................................49A.5.4 Conclusion.....................................................................................................................................51

A.6. QoS Interworking (Mobility in the heterogeneous environment):.......................................51A.6.1 MIH................................................................................................................................................52A.6.1.1 Media Independent Handover Scope.......................................................................................52A.6.1.2 Media Independent Handover Function...................................................................................53A.6.1.3 Conclusion................................................................................................................................57A.6.2 Mobile IPv6...................................................................................................................................57A.6.2.1 Mobile IPv6 architecture..........................................................................................................57A.6.2.2 Mobile IPv6 smooth handover process....................................................................................59A.6.2.3 Mobile IPv6 and QoS...............................................................................................................60A.6.2.4 Conclusion................................................................................................................................60A.6.3 Y.1541 and Y.1541-QOSM...........................................................................................................60A.6.3.1 Y. 1541 Class...........................................................................................................................60A.6.3.2 Y.1541-QOSM.........................................................................................................................61A.6.3.3 Conclusion................................................................................................................................62

Annex B: Standard & Bibliographical References.........................................................................63


1 NGN ContextThe successor of the 3G network is a single All-IP infrastructure which is referred to as

NGN (Next Generation Network). A major characteristic of the Next Generation Network is

its ability to handle heterogeneous and mobile environments for users and service providers.

One can consider four different types of mobility: User mobility, Terminal mobility,

Network mobility and Service mobility. Moreover, heterogeneity exists in user’s terminals,

access networks, core networks as well as in services.

The ability to provide seamless mobility and adaptive quality of service in such a

heterogeneous environment is THE key to the success of Next-Generation Networks.

Our analysis of the context led us to highlight innovative properties (§ 1.1).

Users wish to have a continuous multimedia service in a single session whether they are

moving (terminal mobility) or changing terminal (user mobility). This service session is user-

centric, meaning that a user should have a continuity of service based on customization. Next

service generation should have the self-management ability to dynamically accommodate user

requests by adding or changing service components in a single service session.

Figure 1 : NGN context

In this chapter, a basic introduction on the three main characteristics of NGN: is

provided: the User Centric conception (§ 1.1), the heterogeneous environment (§ 1.2), and the

general mobility in NGN (§ 1.3). A conclusion is then proposed at the end of this chapter


(§ 1.4)

1.1 User centric

Telecommunication evolved from system centric (user must comply with various

treatments) to network centric (user must comply with various connections), and now to User

centric. User information, QoS requirements and preferences are defined in the user’s profile

(Figure 2). In this new context, a common understanding about services, priorities,

responsibilities, etc, is needed between the service provider and the user. This is expected to

lead in the case of business users, to a formal SLA (Service Level Agreement) or in the case

of the general public to QoS commitments of the provider included in the service contract

according to the relevant regulation.

Figure 2: User centric


User centric means that users can access services, in a customized way with a single

authentication and “always in a unique user session”. This conception contains four essential

requirements, each explained below:

Adaptable accessibility to services regardless the terminal used

End users may have several user equipments (UE) in a Seamless Userware vision, for

instance a computer, a PDA, a mobile telephone etc, all trying to reach the same service. Each

of these equipments has its specific context and conditions of use, and each user has his

preferences.

In such situation, one key question is how to adapt services to a chosen terminal,

complying to user’s preferences.

Unique user session for multimedia services (Continuity of service)

During an on-going session, a user can enjoy different services from different providers.

For example, during a telephone call, a user can add a Videophone service, or a movie

program provided by SP1 (Service Provider #1) which may be transferred to a PDA game

program provided by SP2. Users expect such service continuity be provided via a unique user

session.

Customization of service

The NGS (Next Generation Service) concept considers services as a flexible composition

of autonomous service components customizable according to user’s preferences and the user

profile. Thus, user’s preference should be taken into consideration while managing service

composition across heterogeneous networks.

Better selection of connectivity with QoS

Today’s the technology allows a terminal to be able to access services through different

access networks (WiFi, GSM, UMTS, etc). This means that a user can switch from one access

mode to another one in a dynamic manner according to user’s preferences (QoS, location,

availability, etc.).

1.2 Heterogeneous environment

With the continuous evolution of services and technologies, the world of

telecommunication becomes more and more heterogeneous. Modern telecommunication

networks consist of mobile network (such as GSM/GPRS/UMTS), fixed network (such as

Public Switched Telephone Network/ISDN), satellite network and wireless access networks


(such as wireless LAN (WiFi, WiMax) and Bluetooth networks), etc. The user devices are

also becoming more diversified: PDAs, laptops, cell phones, etc which are now commonly

used by the general public.

The growing number of a variety of services and multimedia applications in converging

fixed and mobile IP networks (called Next Generation Networks (NGN)) led to the definition

of a Service Delivery Platform architecture known as an IMS (IP Multimedia Subsystem)

(with associated protocols: SIP, Diameter and Policy control protocols). IMS was originally

specified by 3GPP as part of the vision for evolving mobile networks beyond GSM and

extended later for support of other networks such as fixed line, WLAN, etc. by a number of

standardization organizations, such as the ITU-T and ETSI TC TISPAN; meanwhile the

number of service providers and operators is growing. Figure 3 highlights the NGN

heterogeneous environment.

Figure 3 : NGN heterogeneous environment

These heterogeneities have increased the complexity of the overall infrastructure.

Problems of interoperability between the various systems and handover/roaming between

different accesses and providers should be solved according to the QoS commitments.

1.3 General mobility

Mobility gives users ability to connect from anywhere, anytime to any service with any

type of terminal. In the NGN context, mobility allows users to communicate regardless of

location, device, access mode and network across multiple spatial domains. The existing


solutions for mobility include horizontal handover (HHO) and vertical handover (VHO). The

horizontal handover is provided via mode L3 through the technology "Mobile IP". Media

Independent Handover (MIH) is intended to manage seamless connectivity with different

wireless networks in MAC and PHY layers.

Four kinds of mobility exist in such a NGN context:

Terminal Mobility refers to the ability of a terminal, while in motion, to access

telecommunication services from the same different networks, and the capability of the

commercial networks to identify and locate that terminal [1].

Figure 4 a: Mobility classifications according to network service quality. Source from [ITU-T Q.1706/Y.2801]

Figure 4 b: Terminal Mobility


User Mobility refers to the ability for the user to move to different physical locations and

be able to use one or more devices connected to one or more access networks to gain

access to their services without interruption [1].

Figure 5 : User Mobility

Network mobility refers to the ability of networks, where a set of fixed or mobile nodes

are networked to each other, to change, as a unit, its point of attachment to the

corresponding network upon the network’s movement itself. (this kind of mobility is out

of our scope of research), ex. Ad-hoc network, military network.

Service Mobility refers to the ability of services to be accessible and deliverable

independently of network, terminal or geographical location attributes [1]. It includes the

ability of the service level to consistently provide customized services to the user, with

the expected QoS, regardless of the user’s location. This allows users to maintain access

to their services even while moving or changing of devices or network service providers.


Figure 6 : Service mobilityThe key issue to achieve seamless mobility is for Service Providers to comply with the

QoS contract.

1.4 Conclusion

As networks become more and more complex and as new services emerge continuously,

the requirement for an end to end QoS management offering a transparent experience to the

end user is growing.

These new services (e.g. data services, multimedia services) can be used by different

users in different manners. Users are no longer satisfied with a simple phone call service but

are interested to have as many services available as possible included in a customized service

composition. These requirements imply not only the possibility to always have these services

accessible in a unique session when the user is moving in an heterogeneous environment but

also to have the QoS guaranteed for different types of applications simultaneously.

To maintain E2E QoS continuity for users, as expected, the means to provide

cooperation between the different networks are needed.


2 User Case

Figure 7 : User case

Figure 7 shows a typical user case.

In the heterogeneous and generic mobile environment, user enjoys different types of

media in one session with E2E QoS continuity according to his preference.

Table 1 below presents the user case description and the pertinent capabilities.


User case description Capability1. At home, Bob uses the home network

made up of customer network gateway (CNG) and customer network devices (CND) to access the service.

2. At 8:30h, user launches a session on his desktop for web service provided by SP1 according to his preferences (AS12: the first number after AS identifies function, second number identifies the QoS level defined by the provider).

3. According to Bob’s preference, when he leaves home for work, he uses his PDA to continue surfing internet in the same service session.

4. The PDA accesses to the service through another type of access network.

5. On the way to work, user calls his business partner confirming the video conference and discusses some issues, so the data flow and voice flow is loaded in the same session. The service broker in SCIM manages the interaction of AS12 (Web service) and AS33 (Voice service) provided by SP1 according to the user profile configured in the Home Subscriber Server (HSS).

6. When Bob arrives at his office, his PDA accesses through another access point of the same access network, while web service and voice service continue.

7. According to user’s preference, Bob continues his work on the laptop at his office while continuing to talk with his partner.

8. Within his office, his laptop accesses another access point. To maintain E2E QoS according to user’s preference, the system changes the AS 12 and AS 33 to AS 11 and AS 31 which are provided by SP2.

9. For the user, all the treatments are transparent.

① Home Network Environment

② One session from 8:30h to 11h

③ User mobility

④ Vertical handover

⑤ Terminal mobility ⑥ Service composition

⑦ Horizontal handover

③ User mobility

⑧ Service mobility


Table 1 : User case description

Conclusion: Our objective is to achieve E2E QoS continuity for a customer in one unique user

multimedia session. This user case illustrates terminal mobility, user mobility and service

mobility with QoS continuity while the user moves across heterogeneous networks according

to his preferences. Moreover, E2E is considered from the user equipment everywhere (even in

his Home Network Environment) up to the service layer with QoS mapping, according to the

user’s preference.

That is, in an "E2E user-centric session" vision, a user could have an E2E QoS continuity

of global multimedia services in a customized way.

3 Requirement for QoS continuity

Figure 8 : From existences to concerned problem

The following numbers are referring to the ones in the domains in the above circles.

1. User requirements and preferences: In terms of continuity of multimedia services

and all personal information (usage, SLA, security etc.).

2. Mobility, which refers to terminal mobility, user mobility, service mobility and

network mobility

3. Heterogeneity, which represents the heterogeneity of networks and terminals, as

well as the heterogeneity of services which contribute to the heterogeneity of

QoS mechanisms.


QoS issues are then analyzed between each two sub fields:

4. A proper E2E QoS signalling which insures user continuous services within a

mobile environment.

5. The user connectivity to heterogeneous networks which is expected to always

comply with the SLA where the user preferences are defined.

6. An inter-working QoS to enable terminal mobility across heterogeneous

networks.

7. QoS continuity taking into consideration the mobility across heterogeneous

environments. The advanced management information covers the mobility

management information (User mobility, terminal mobility, service mobility,

network mobility and session mobility), QoS information and AAA information

(Authentication, Authorization, and Accounting).

4 ConclusionEvolution of networks and services requires to consider end to end flow while offering

transparency of information to the end users..

Users and services are interconnected by several networks which may be trans-

organizations.

In order to achieve the expected behaviour, means are needed to provide cooperation

between different networks in order to achieve end to end QoS.

There are already some works aiming to solve QoS problems in one or several aspects of

the context. They are SLA, Policy control, QoS classification, MIPv6, SIP, NSIS, IMS, MIH

and Diameter. (Detailed descriptions are in Annex A).


Figure 9 : Related work for QoS

1. SLA implementation is a mechanism of QoS in the management plane and in the

informational dimension. The QoS contract between the provider and the user is static. When

dealing with the complexity of the NGN context which contains mobility and heterogeneity, a

dynamic contract will most probably become the trend.

2. IMS provides a standardized, well-structured way of delivering services, legacy inter-

working and fixed–mobile convergence. TISPAN uses IMS to cater, for fixed network

operators, E2E multimedia services. In the TISPAN NGN architecture, not only core

networks but also access networks or even terminals on the user side have QoS related control

and management functions. In IMS architecture, it uses Diameter to carry the information of

authorization, charging etc. The QoS related information can also be mapped to Diameter

AVP.

IMS is classified as an architectural dimension solution for QoS issue of NGN. It

implements the QoS mechanisms in management and control planes, i.e. policy control in the

management plane and admission control in the control plane.

3. SIP has been designed in conformance with the Internet model. It is an end-to-end

oriented signalling protocol. Moreover, the SIP can filter (select) according to the User Profile

to implement application servers before establishment of a session but cannot re-select


services during a session SIP is a signalling protocol which is classified into the control plane.

For QoS, although the SDP describes the session and negotiates with the QoS requested, it

must nevertheless integrate QoS signalling protocol to achieve QoS guarantee for the session.

4. The attributes of Y.1541 QoS Classes encompass major IP application categories; they

are able to support QoS negotiation among systems.

5. For the service and network providers, the CPN speeds up broadband deployment and

multi-service implementation. More importantly, the QoS related entities in the CPN gives the

possibility to deal with the QoS issue on the user side in an End-to-End session with QoS

continuity.

6. IEEE 802.21 helps Handover Initiation, Network Selection and Interface Activation

during Vertical Handovers for next generation wireless All-IP networks. The 802.21 enables

Co-operative Handover decision making between Clients and Network. But how to solve the

vertical handover in the wireless and fixed network is not covered in the scope of MIH.

7. Mobile IPv6 allows easier configuration, better security and optimization; it

minimizes the control traffic needed to effect mobility. But Mobile IP is not a complete

mobility solution; it needs to cooperate with other mobility management protocol.

8. NSIS assumes a scalable architecture signalling in two layers and reuses the existing

transport and security. It uses a session ID which is independent of the flow identifier for the

state management. The Session ID (SID) used in NSIS signalling enables the separation of the

signalling state and the IP addresses of the communicating hosts. This makes it possible to

directly update a signalling state in the network due to mobility without being forced to first

remove the old state and then re-establish a new one. It works on both control and

management planes in a protocol dimension. In the NGN context, the change of route or IP

addresses in mobile environments is typically much faster and more frequent than traditional

route changes caused by node or link failure. The question is whether NSIS is sufficient for

the self-management and self-adaptation to whatever change in the user-centric session?

5 Discussion and next stepsDifferent solutions could be considered to achieve the E2E QoS:

To achieve the E2E QoS we can consider (Figure 10) a signalling based solution (such as

SIP/SDP, NSIS) or a management based solution (such as DIAMETER or Policy Control) but

for a dynamic management as shown in the Figure 11, the convergence of these two solutions

should be studied.


Figure 10 : QoS related work in three planes

Figure 11 : Dynamic management

5.1 Control plane solution: QoS signalling

- User QoS requirements information- Identification of InterWorking unit (IWU)- QoS and user-centric E2E session (User case)

- SIP- NSIS

- Interaction on user system- User E2E Measurement

Lifecycle of QoS management

ConceptionE2E QoS Provisioning Transfer Management

Dynamic Management

MonitoringInstrumentation


5.2 Management plane solution: QoS interworking

- QoS parameters mapping for the demanded QoS of the end user’s preference. - From static SLA to dynamic/proactive SLA (Diameter).- Checking achievement of required QoS inter-working among the different

administrate domains which have different releases or types of QoS contract.

5.3 Converging solution: QoS continuity

- Trigger parameters for QoS decision- Terminal mobility- User mobility- Service mobility

- User E2E Measurement

5.4 QoS informational structure

- User profile information details- Environment profile information details

Annex A:Current work for QoS

Figure 12: Respective current work in three aspectsNote: 1’, 2’, 3’ mean the zone not overlaid

In the first chapter, we have introduced the three main characteristics of NGN (User,

Mobility and Heterogeneity) which are relevant to our frame of work.

In this chapter, we will report on the work currently done on each of these three

characteristics. In order to clearly show the related work done on QoS along with the


increasing complexity of the context, we will begin by considering the zones which do not

overlay (numbers 1’, 2’ and 3’ as shown in Figure 12, before considering the zones which

overlay (the numbers 4, 5, 6 and 7 as shown in Figure 12).

In this chapter, we will also introduce the QoS mechanism in User aspect: SLA (§ 1),

and then present the horizontal handover solution when mobility occurs in the homogeneity

network (§ 2). Finally, the IMS architecture will be explained as the architectural dimension

of the QoS solution for the convergence of the heterogeneity environment (§ 3)

A.1. SLASLA (Service Level Agreement) is an abbreviation often used in the context of contract

between business users and their providers. In this document, the meaning of SLA has been

extended to cover as well the case of the QoS commitments implied in the provision of

telecommunication services to the general public.

A.1.1 SLA definition

The TeleManagement Forum [2] defines a SLA as “a formal negotiated agreement

between two parties, sometimes called a service level guarantee. It is a contract (or part of

one) that exists between the service provider and its customer, to create a common

understanding about services, priorities, responsibilities, etc...”

A.1.2 SLA Life Cycle

Figure 13 below shows the SLA life cycle:

Figure 13: SLA Life Cycle


1. SLA Development: In this phase the SLA templates are developed.

2. Negotiation and Sales: In this phase the SLA is negotiated and the contracts are

notified.

3. Implementation: where the SLA is generated.

4. Execution: The SLA is executed, monitored, and maintained.

5. Assessment: Evaluation of the SLA performance. In this phase, a re-evaluation of the

initial SLA template might be done.

A.1.3 SLA Function

First of all, an implementation of a SLA can help service providers (including third-party

service providers) and service users to clarify some of the services responsibilities regarding

the expected quality. QoS (Quality of Services) indicators should avoid any ambiguity in

understanding the quality of service.

In addition, in the process of SLA, there is a commitment to quantify the quality of

service (QoS indicators), and meanwhile, to perform regular statistics, analysis, reporting and

management. Then, the system provides customers with real value added service as well as

regular report of the initiative "SLA illegal" regularly. These initiatives can guide the

customer to explore the potential consumer demand, to achieve maximum “user benefit”.

A.1.4 Conclusion

SLA implementation is a mechanism of QoS in the management plane and in the

informational dimension. This contract between the provider and the user is static. When

dealing with the more complex context of NGN which encompasses mobility and

heterogeneity, the trend will be to get a dynamic contract.

A.2. Mobility in homogenous network user-unawareQoS is mostly a Connection Admission Control and Scheduling problem, while mobility

is a routing problem. In a mobility environment, QoS is rather a problem of how QoS state is

re-established in different kinds of mobility?

As shown in Figure 12, zone 2’ highlights the mobility in an homogenous network user-

unaware. The solution in an homogeneous network is a horizontal handover (HHO).

Horizontal handover is defined as handover within same access networks. Generally it is

referred to as the Intra-AN handover. Relatively, vertical handover (VHO) is defined as


handover across heterogeneous access networks. Generally, it is referred to as the Inter-AN

handover Error: Reference source not found. Figure 14 shows the difference between HHO

and VHO.

Figure 14: Horizontal handover and Vertical handover

Horizontal Handover (HHO)

The solution for mobility in an homogenous network is an horizontal handover.

It refers to a terminal whose location changes i.e. that moves among various access points in

one network or moves among different network access points, while maintaining access to

one set of services. Such mobility should allow the relocation of the terminal without any

break. The change in the point of attachment sometimes temporary disconnects the mobile

terminal and disrupts the communications in progress while the objective is to ensure

seamless communications.

The procedure for horizontal handover is handled mostly in layer 2. A layer 2

handover occurs when a mobile host’s connection changes from one access point to another.

The procedure of this type of handover involves releasing the connection from the former

access point, establishing a connection to the new access point (though not necessarily in this

order), and updating the binding between a mobile host’s IP address and its temporary layer 2

identifier (e.g. a MAC address) on the sub-network at the access router. Two types of

procedures are proposed [4]:

Break-before-make handover: the former connection is released before the new

connection is established; data reception is interrupted for a short period of time.

The service disruption can be avoided.

Make-before-break handover: if the mobile host is capable of establishing


connections to multiple access points simultaneously, can connect to the new

access point before breaking its connection from the former access point

Broadly speaking, the handover will be conducted by analyzing the signal received

from the two related cells frame by frame involved and the best frame will be accepted.

Several handover definitions have been proposed. For instance, in UMTS (Universal Mobile

Telecommunications System) [5], three different handovers have been defined: hard

handover, soft handover, and softer handover.

Hard handover

It means that all the old radio links in the UE are removed before the new radio links

are established. Hard handover can be seamless or non-seamless. Seamless hard handover

means that the handover is not perceptible to the user. In practice a handover that requires a

change of carrier frequency (inter-frequency handover) is always performed as hard handover.

Soft Handover

It means that the radio links are added and removed in a way that the UE always keeps

at least one radio link to the UTRAN. Soft handover is performed by means of macro

diversity, which refers to the condition that several radio links are active at the same time.

Normally soft handover can be used when cells operated on the same frequency are changed.

Softer Handover

Softer handover is a special case of soft handover where the radio links that are added

and removed belong to the same Node B. In softer handover, macro diversity with maximum

ratio combining can be performed in the Node B, whereas generally in soft handover on the

downlink, macro diversity with selection combination is applied.

A.3. Heterogeneous environment and QoSThe QoS problem in an heterogeneous environment is how to interoperate the QoS state.

The policy could be used to adapt QoS according to particular goals in heterogeneous

networks. Such policy could be used for:

optimal access network selection in case of handover, routing and connection

redirection

resource and service adaptation in heterogeneous network environment

management of the interactions between heterogeneous networks for QoS

provisioning


IP Multimedia Subsystem (IMS) has emerged as an overlay service provisioning

platform that operates on a heterogeneous network environment. The IMS is defined by the

3rd Generation Partnership Projects (3GPP and 3GPP2) and is an overlay service architecture

that enables the efficient provision of an open set of highly integrated multimedia services,

combining web browsing, e-mail, instant messaging, VoIP, video conferencing, telephony,

multimedia content delivery, etc. Figure 15 below highlights the topology of the IMS:

Figure 15: IMS topology

A.3.1 IMS Architecture (3GPP)

IMS decomposes the networking infrastructure into separate functions with standardized

interfaces. Each interface is specified as a “reference point”, which defines the protocol over

the interface and the functions between which it operates. The standards do not mandate

which functions should be co-located, as this depends on the scale of the application, and a

single device may contain several functions. The 3GPP architecture is split into three planes

(Figure 16), each of which is described by a number of equivalent names: Service or

Application Layer, Control or Signalling Layer, and User or Connectivity Layer [6].


Figure 16: IMS architecture

The service layer consists of application and content servers to execute value-added

services for the user. Generic service enablers as defined in the IMS standard (such as

presence and group list management) are implemented as services in a SIP Application

Server.

configuration storage, identity management, user status (such as presence and location),

which is held by the Home Subscriber Server (HSS)

Billing services, provided by a Charging Gateway Function (CGF) (not shown)

Control of voice and video calls and messaging, provided by the control plane.

The control layer consists of network control servers for managing call or session set-up,

modification and release. The most important of these is the CSCF (Call Session Control

Function), also known as a SIP server. This layer also contains a full suite of support

functions, such as provisioning, charging and operation & management (O&M). Inter-

working with other operators’ networks and or other types of networks is handled by border

gateways.

At the core of this plane is the Call Session Control Function (CSCF), which consists

of the following functions:

The Proxy-CSCF (P-CSCF) is the first point of contact for users with the IMS. The

P-CSCF is responsible for security of the messages between the network and the

user and allocating resources for the media flows.


The Interrogating-CSCF (I-CSCF) is the first point of contact from peered networks.

The I-CSCF is responsible for querying the HSS to determine the S-CSCF for a user

and may also hide the operator’s topology from peer networks (Topology Hiding

Inter-network Gateway, or THIG).

The Serving-CSCF (S-CSCF) is the central brain. The S-CSCF is responsible for

processing registrations to record the location of each user, user authentication, and

call processing (including routing). The operation of the S-CSCF is controlled by

policy stored in the HSS.

Figure 17 below shows the signalling flow path for establishing a call session:

Figure 17: Signalling flow path for establishing a call session

The call signalling flows from the caller pass through the P-CSCF in the home network

to his S-CSCF. The signalling then passes onto the called party via his S-CSCF.

Home Subscriber Server: The HSS contains a subscription database for the IMS,

including subscription-related information to support the network entities that actually handle

calls or sessions. It supports IMS-level authentication and authorization and holds the IMS

subscriber profiles. The HSS also stores the currently assigned S-CSCF.

Breakout Gateway Control Function: A breakout gateway control function receives

session requests forwarded by an S-CSCF or another BGCF, and it selects the network in

which PSTN breakout is to occur. It selects a local MGCF or peer BGCF in another network.

This ability to select a BGCF in another network provides the capability to optimize routing

from the visited network to the PSTN, where desired and supported by the operators involved.

Media Resource Function Controller: The MRFC controls the media stream resources

of the MRFP. It interprets information from an AS or SIP endpoint and controls the MRFP


accordingly to support media services such as trans-coding and conferencing. The MRFC

may be collocated with an AS to provide specialized AS services.

Media Resource Function Processor: The MRFP provides resources under the control

of the MRFC for media processing. It supports media stream mixing, tone and announcement

generation, trans-coding, media analysis, and other functions.

Subscription Locator Function: The SLF serves as a front-end for distributed HSS

systems. It may be queried by an I-CSCF during registration and session setup to get the name

of the HSS containing the required subscriber-specific data. The SLF may also be queried by

the S-CSCF during registration, or by the AS in conjunction with the Sh interface. The SLF is

not required in a single-HSS environment, or in certain other HSS environments such as

server-farm architecture. It is also not required when an AS is configured and managed to use

a predefined HSS.

The connectivity layer comprises routers and switches, both for the backbone and the

access network. This infrastructure is designed to provide a wide range of IP multimedia

server-based and P2P services.

IMS reference points [7]:

Cx reference point: Supports information transfer between CSCF and HSS.

Gm reference point: Supports communication between the MT and the IMS.

Mn reference point: Communication interface between the MGCF and IMS-MGW.

Equivalent to the Mc interface in the CS domain.

Mg reference point: Allows the MGCF to forward incoming session signalling (from the

PSTN) to the CSCF for the purpose of inter-working with PSTN networks. Uses SIP for

signalling.

Mr reference point: Supports information transfer between CSCF and MRFC. Uses SIP

for signalling.

Mp reference point: Allows an MRFC to control media stream resources provided by an

MRF. Similar to the Mc interface in the CS domain.

Mw reference point: Allows the communication and forwarding of SIP signalling

messaging between CSCFs.

Go reference point: Allows the Policy Decision Function (PDF) to apply policy

decisions to bearer usage in the GGSN. The Policy Decision Function (PDF) is a logical

entity in the P-CSCF.

Mi reference point: Allows the Serving CSCF to forward the session signalling to the


BGCF for the purpose of inter-working with PSTN networks. Uses SIP for signalling.

Mj reference point: Allows the BGCF to forward session signalling to the MGCF for the

purpose of inter-working with PSTN networks. Uses SIP for signalling.

Mk reference point: Allows the BGCF to forward session signalling to another BGCF.

Uses SIP for signalling.

Dx reference point: The CSCF and SLF interface is used to retrieve the address of the

HSS which holds the subscription date for a given user. Not required in a single HSS

environment.

Mb reference point: Used to access IPv6 network services for user data transport.

ISC reference point: The interface between the CSCF and application servers for access

to IMS services.

Sh reference point: Used for communication from the SIP or OSA application server to

the HSS.

Si reference point: Used for communication from the CAMEL application server to the

HSS.

A.3.2 TISPAN NGN architecture

TISPAN uses IMS specified by 3GPP to cater for fixed network operators to provide end

to end IP based multimedia services. Figure 18 is the overview of TISPAN NGN functional

architecture.

The TISPAN NGN functional architecture can be divided into two layers [8]:

1. Service layer, consisting of Application Servers (AS).

2. Transport layer, consisting of the user equipment (UE), Access Network, Next

Generation Network (NGN) core. TISPAN adds the transport control sub-layer for

registration/ initialization of user equipment (NASS: Network Attachment Subsystem) [34] and

reservation the resources from access network (RACS: Resource and Admission Control

Subsystem) [35].


Figure 18: TISPAN NGN ArchitectureThe service layer is composed of the following components:

The IP Multimedia subsystem core components. IMS Functional Architecture is

specified in [36]

The PSTN/ISDN Emulation Subsystem (PES) Error: Reference source not found.

Other multimedia subsystems (e.g. IPTV [38], etc.) and applications. It should be

noted that the ETSI TC TISPAN also specified another option for the IPTV ar-

chitecture than that one defined in Error: Reference source not found. It is based

on the support of the IPTV functions by the IMS subsystem [39].

Common components used by several subsystems such as those required for ac-

cessing applications, charging functions, user profile management, security man-

agement, routing databases etc.

In the transport layer:

The NASS provides the following functionalities [34]:

Dynamic provision of IP addresses and other terminal configuration parameters;

Authentication taking place at the IP layer, prior or during the address allocation

procedure;

Authorization of network access based on user profiles;


Access network configuration based on user profiles;

Location management taking place at the IP layer.

RACS [35] is the TISPAN NGN subsystem responsible for the implementation of

procedures and mechanisms handling policy-based resource reservation and admission control

for both unicast and multicast traffic in access networks and core networks.

Besides acting as a resource control framework, RACS also includes support for

controlling Network Address Translation (NAT) at the edge of networks and assisting in

remote NAT traversal. Furthermore, RACS also covers aspects related to the setting and

modification of traffic policies, end to end quality of service and transport-level charging.

In core network, there are two main types of Border Gateway Function (BGF):

The Core BGF (C-BGF) that sits at the boundary between an access network and

a core network, at the core network side;

The Interconnection BGF (I-BGF) that sits at the boundary between two core net-

works.

On the user side, the User Equipment (UE) consists of one or more user controlled

devices allowing a user to access services delivered by NGN networks. Different components

of the customer equipment may be involved depending on the subsystem they interact with.

As for the Custom Network Gateway (CNG), we will introduce it on detail in § 5.1.

A.3.3 QoS issue in the IMS--- Policy control management

In the IMS, the procedure of reserving resources for the purpose of QoS provisioning

starts with the application indicating its requirements and ends with the resources being

committed over the radio channel and into the core network. The IMS must implements

resource policy control in the management plane, admission control in the control plane, and

makes sure that proper policy enforcement is available in the network for the QoS guaranteed

issue. By these network functions, it is ensure that IMS sessions can only be established when

enough resources are available.

The 3GPP has taken approach to the QoS matter by defining four separate traffic (QoS)

classes that will be handled according to the operator’s requirements on each of the traffic

classes. The 3G traffic classes are shown in Table 2 below:


Table 2: 3G traffic classes defined in the 3GPP

Using these classes, the packets can receive different treatment with respect to various

QoS aspects such as flow priority or packet drop precedence. In addition, policy can be used

to specify the packet forwarding based on various classification criteria. The policy controls

the set of configuration parameters and forwarding for each class or admission conditions for

flow reservations depending on the QoS scheme used e.g. RSVP, DiffServ. Once the policies

for a domain are specified, all new sessions should enforce the QoS policies on the routers

before the User Equipment is registred in the IMS. Figure 19 shows the policy-based control

in IMS [9] and the Figure 20 shows the message flow in the process of one policy-based

session’s establishment with the QoS guarantee [10].

Figure 19: Go interface architecture model (3GPP TS 29.207 R6)


Interface Function Protocol

Go Provides information to support:- Control of service-based policy "gating" function in GGSN- UMTS bearer authorization- Charging correlation related function

COPS

Gq Transports policy set-up information between the application function(P-CSCF) and the PDF

Diameter

Table 3: Policy based control in the IMS

Figure 20: Message flows for guaranteed QoS provisioning

(1) The P-CSCF receives the SDP (Session Description Protocol) parameters defined by

the User Equipment within an SDP offer in SIP signalling.

(2) The P-CSCF identifies the connection information needed (IP address of the down

link IP flow(s), port numbers to be used, etc.).

(3) The P-CSCF forwards the SDP offer in SIP signalling.

(4) The P-CSCF gets the negotiated SDP parameters from the terminating side through

SIP signalling interaction.

(5) The P-CSCF identifies the connection information needed (IP address of the up-link

media IP flow(s), port numbers to be used, etc.).

(6) The P-CSCF forwards the derived session information to the PDF and requests an


authorization token by sending a request for authorization (using Gq Interface).

(7) The PDF authorizes every component negotiated for the session. An authorization

token is generated by the PDF.

(8) The PDF sends the authorization token to the P-CSCF (using Gq Interface).

(9) Upon successful authorization of the session the SDP parameters and the

authorization token are passed to the UE in SIP signalling.

(10) The UE sends an Activate PDP (Packet Data Protocol) Context request to receive

the authorization token.

(11) Using the Go Interface the Policy Enforcement Point, sends a COPS request to the

PDF.

(12) The PDF sends the configuration parameters to be enforced by the PEP through the

Go Interface.

(13) The PEP enforces the policies and sends an activate PDP context response to the

UE.

(14) The session with guaranteed QoS parameters begins.

A.3.4 Diameter

A.3.4.1 Policy Charging Convergence

In the IMS R7, the policy control function (SBLP) and the flow based charging function

(FBC) are combined as an entity Policy and Charging Control function (PCC).

The PDF and CRF are integrated into one entity which is called the PCRF. The Policy

Enforcement Function (PEF) and Traffic Plane Function (TPF) are enforced in the PCEF. The

Gq interface and the Rx interface are integrated as the Rx+ interface, and the Go interface and

Gx interface are integrated as the Gx+ interface.


Figure 21 : Evolution of IMS R7

The effect of such convergence goes beyond the simple addition of the two functions.

Indeed, by the fusion of the two functions, a charging coherent with the strategic decision and

tactic will be possible. For example, we would have a rule, indicating the charging change on

real-time when any QoS change occurs.

A.3.4.2 Messages and AVPs

Convergence of policy decision and charging (PCRF and PCEF) entities in the Rel-7

makes it possible to transfer the QoS and charging information with homogenous AVPs

(Attribute-Value-Pairs) at the same time. The related charging protocols and interfaces are

Diameter-based reference point Rx+, Gx+, Gy and Ro. The Gy and Ro interfaces are used for

the online charging. We will explain in the following the messages and the AVPs used in the

corresponding interfaces.

Messages and AVPs in the Rx+ Interface

Reference point Rx+ [11] is between the entities P-CSCF (AF) and PCRF. It enables the

transport of application level session information from AF to PCRF, i.e. IP filter information

to identify the service data flow for policy control, differentiated charging and

media/application bandwidth requirements for QoS control.

Four pairs of messages are used in this interface: AA-Request/Answer is used to transfer

the session information; Re-Auth-Request/Answer is used to indicate specific re-authorization

actions; Session Termination-Request/Answer is used to indicate a session should be


terminated. And Abort-Session-Request/Answer is used to indicate that the bearer of the

established session is unavailable.

As mentioned before, the interface Rx and interface Gq are integrated into the interface

Rx+. The former interfaces Rx and Gq are both diameter-based. Therefore, most of AVPs’

definitions in Rx+ are based on Rel-6 with some possible modifications applied to the Rel-7.

Figure 22: AVPs in Rx+ Messages and AVPs in the Gx+ Interface

Reference point Gx [12] is located between the PCEF and the PCRF. It enables a PCRF

to have dynamic policy and charging control over the PCC behavior at a PCEF.

Two pairs of messages are used in this interface are: Credit-Control-Request/Answer is

used to indicate bearer or PCC rule related events or the termination of the IP CAN bearer,

etc. Re-Auth-Request/Answer is used to do the PCC rules provisioning and event triggers for

the session, etc.

Gx and Go interfaces are integrated into interface Gx+. Go and Gx use different

protocols. Go is COPS-based and Gx is diameter-based. Thus the messages used in the Go

should be changed into the Gx diameter-based messages. Furthermore, the Gx+ application

has its own specific Diameter application (Diameter Credit Control session for an IP-CAN

session).


Figure 23: AVPs in Gx+ Messages and AVPs in the Gy and Ro Interface

The Gy reference point resides between the OCS and the PCEF. The Ro reference point

is used between the OCS and CTF (IMS-GW, MRFC, AS). The two reference points allow

online credit control for service data flow based charging [13].

There are six pairs of messages in Ro interface:

Credit-Control-Request/Answer;

Re-Auth-Request/Answer;

Capabilities-Exchange-Request/Answer;

Device-Watchdog-Request/Answer;

Disconnect-Peer-Request/Answer;

Abort-Session-Request/Answer.


Credit Control AVPs

Figure 24 : Credit control AVPFigure 24 shows all of the Diameter AVPs defined in the credit-control application.

These AVPs could be used in the Credit-Control messages, i.e. CCR/CCA. We are interested

in the four AVPs related to user equipment and multiple service which are circled in red:

Multiple-Service-Credit-Control; Multiple-Service-Indicator; Requested-Action and User-

Equipment-Info.

A.3.5 Conclusion

The IMS is a standardized NGN architecture for an Internet media-services capability

defined by the European Telecommunications Standards Institute (ETSI) and the 3rd

Generation Partnership Project (3GPP).

The IMS standard is being adopted by a growing number of companies of the telecom

community. IMS provides a standardized, well-structured way of delivering services, legacy

inter-working and fixed–mobile convergence. TISPAN uses IMS to cater for fixed network

operators for E2E multimedia service for fixed network operators. In the TISPAN NGN

architecture, not only core network but also access network and even terminal from the user

side have QoS related control and management functions. In IMS architecture, it uses

Diameter to carry the information of authorization, charging etc. The QoS related information

can also be mapped to Diameter AVP.

IMS is classified as an architectural dimension solution for QoS issue of NGN. It

implements the QoS mechanisms in management and control planes, i.e. policy control in the


management plane and admission control in the control plane.

A.4. E2E QoS signalling (among the same type of access network):

How to make a mobility solution User aware with QoS, in other words, how to design

personalized service ensuring seamless QoS when the users and the terminals move? A

session based E2E QoS signalling is a solution. IETF has proposed SIP (Session Initiation

Protocol) and NSIS (Next Steps in Signalling) as the signalling protocols for session-based

service which have their own way to transfer the QoS parameters.

In this chapter, we will first introduce SIP protocol (§ 4.1), and then NSIS protocol is

presented (§ 4.2)

A.4.1 SIP

SIP is an application-layer control protocol to create, modify and terminate sessions with

one or more participants. It has been designed and developed within the IETF.

The specification is available through several RFCs, the most important one being

RFC3261 [14] which contains the core protocol specification. It should be noted that 3GPP

specified a call control protocol for use in the IP Multimedia (IM) Core Network (CN)

subsystem based on the Session Initiation Protocol (SIP), and the associated Session

Description Protocol (SDP) [41]. This specification has been endorsed by the ETSI TC

TISPAN [42]. Here, the necessary modifications to [41] are provided with respect to the use

of SIP/SDP in the NGN.

By sessions we understand a set of senders and receivers that communicate and the state

of which is kept in during the communication. Examples of a session can include Internet

telephone calls, distribution of multimedia, multimedia conferences, distributed computer

games, etc.

SIP can also invite participants to already existing sessions, such as multicast

conferences. Media can be added to (and removed from) an existing session. SIP

transparently supports name mapping and redirection services, which supports personal

mobility - users can maintain a single externally visible identifier regardless of their network

location.


A.4.1.1 SIP basic functionalities

SIP supports five facets of establishing and terminating multimedia communications:

User location: determination of the end system to be used for communication;

User availability: determination of the willingness of the called party to engage in

communications;

User capabilities: determination of the media and media parameters to be used;

Session setup: "ringing", establishment of session parameters at both called and call-

ing party;

Session management: including transfer and termination of sessions, modifying ses-

sion parameters, and invoking services.

A.4.1.2 SIP entities

SIP uses server/client architecture, the entities in the establishment of a SIP session can

be classified into two categories: user agents (terminal) and intermediate servers.

Agents (User Agents---UA): These agents usually reside on end-user equipment in form

of an application, but can be also user’s terminal, such as phones, PDAs and so on.

Intermediate servers: These intermediaries are logical entities through which pass SIP

messages to reach the destination. They are used to route and redirect these messages. These

servers include:

Register Server (RS) is a database that contains location information of a UAs

area.

Proxy Server (PS) is the link between the UA and the RS. It decides next hop and

forwards request, relays call signalling, operates in a transactional manner, saves

no session state.

Redirect Server that enables proxy server to redirect queries to recipients who are

in different domains.

Figure 25 shows the relation of each SIP entities:


SIP User Agent A (Client)

SIP Proxy Server A

SIP Proxy Server B

SIP Proxy Server B

SIP Registar Server A

SIP RegistarServer B

SIP User Agent B (Server)

Operator’s Network

SIP RedirectServer

11

22

33

44

55

6677

88

99

1010

Figure 25 : SIP entities

A.4.1.3 SIP messages and procedure

Figure 26 : Session establishment procedure

SIP provisioning messages are exchanged for the establishment of the session. During

this procedure of initialization (application resources reservation), the negotiation of

application types, parameters of the session and capacity of the two interlocutors (end-users)


is done (F1 to F12 shown in Figure 26). At the end of the reservation procedure of application

resources that starts the transmission of media data.

Two protocols that are most often used with SIP are RTP and SDP. RTP protocol is used

to carry the real-time multimedia data (including audio, video, and text) and makes it possible

to encode and split the data into packets and transport such packets over the Internet.

A.4.1.4 SDP

Another important protocol is SDP, which is used to describe and encode capabilities of

session participants. Such a description is then used to negotiate the characteristics of the

session so that all the devices can participate (that includes, for example, negotiation of codec

used to encode media so that all participants will be able to decode it, to negotiate the

transport protocol used and so on).

The purpose of SDP is to convey information about media streams in multimedia

sessions to allow the recipients of a session description to participate in the session. SDP is

primarily intended for use in an internetwork, although it is sufficiently general that it can

describe conferences in other network environments.

Thus SDP includes:

Session name and purpose

Time(s) the session is active

The media comprising the session

Information to receive those media (addresses, ports, formats and so on)

As resources necessary to participate in a session may be limited, some additional

information may also be useful:

Information about the bandwidth to be used by the service

Contact information for the person responsible for the session

In general, SDP must convey sufficient information to be able to join a session (with the

possible exception of encryption keys) and to announce the resources to be used to non-

participants that may need to know.

4.1.5 Conclusion

SIP has been designed in conformance with the Internet model. It is an end-to-end

oriented signalling protocol which means, that all the logic is stored in the end devices (except

routing of SIP messages).


For QoS, although the SDP describes the session and negotiates with the QOS requested,

it must nevertheless integrate QoS signalling protocol to achieve QoS guarantee for the

session.

Moreover, the SIP can filter (select) according to User Profile to implement application

servers before establishment of the session but can not re-select services during a call.

A.4.2 NSIS

To fulfill the needs of signalling over IP-based networks, the Internet Engineering Task

Force (IETF) developed the Resource Reservation Protocol (RSVP) which is designed and

applied to resource reservation for both integrated services (IntServ) and later differentiated

services (Diff-Serv), rather than more general signalling services. In 2001, the IETF formed a

new working group---Next Steps in Signalling (NSIS), to search for a flexible IP signalling

architecture and protocols.

As a result, an extensible IP signalling architecture [16] was developed also referred to as

NSIS. It consists of two layers: the lower layer provides a generic transport service for

different signalling applications (QoS NSLP, NAT/Firewall NSLP, Metering NSLP), which

reside in the upper layer. This kind of Two-layer model is used to separate the transport

signalling from the application signalling. This allows more flexibility, such as the ability to

use standard transport layer and security protocols.

In transport layer of NSIS---NTLP (NSIS Transport Layer Protocol), the main

composition is known as GIST (General Internet Signalling Transport Protocol). It ensures

the transport of signalling messages. The GIST runs on standard protocols for transportation

and security. Examples of such transport protocols are UDP, TCP, SCTP (Stream Control

Transmission Protocol), and DCCP (Datagram Congestion Control Protocol). In signalling

layer of NSIS (NSLPs: NSIS Signalling Layer Protocols), the protocols execute the

application-specific signalling. For instance QoS NSLP for reserving resource, NAT / firewall

NSLP for configuring middle box and etc. Figure 27 below shows the organisation of NSIS:


Figure 27 : Organisation of NSIS

A.4.2.1 Logic model and protocol messages [17]

Logic model

The figure below presents a logical model for the operation of the QoS NSLP and

associated provisioning mechanisms within a single node.


Figure 28 : Logic model for the operation

Incoming messages are captured during input packet processing and handled by GIST.

Only messages related to QoS are passed on to the QoS NSLP. GIST may also generate

triggers to the QoS NSLP (e.g. indications that a route change has occurred). The QoS

request is handled by the RMF (Resource Management Function), which coordinates the

activities required to grant and configure the resource. It also handles policy-specific aspects

of QoS signalling.

The grant processing involves two local decision modules: policy control and admission

control. Policy control determines whether the user is authorized to make the reservation.

Admission control determines whether the network of the node has sufficient available

resources to supply the requested QoS. If both checks succeed, parameters are set in the

packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the

desired QoS. Error notifications are passed on back to the request originator.

Admission control, packet scheduling, and any part of policy control beyond simple

authorization have to be implemented using specific definitions for types and levels of QoS.

A key assumption is made that the QoS NSLP is independent of the QoS parameters. These

are captured in a QoS Model and interpreted only by the resource management and associated

functions, and are opaque to the QoS NSLP itself.

The final stage of processing for a resource request is to indicate to the QoS NSLP

protocol processing that the required resources have been configured. The QoS NSLP may


generate an acknowledgment message in one direction, and may forward the resource request

in the other.

Protocol messages

The QoS NSLP uses four message types:

RESERVE: The RESERVE message is the only message that manipulates QoS NSLP

reservation state. It is used to create, refresh, modify and remove such state. The result of a

RESERVE message is the same whether a message is received once or many times.

QUERY: A QUERY message is used to request information about the data path without

making a reservation. This functionality can be used for reservations or for the support of

certain QoS models.

RESPONSE: The RESPONSE message is used to provide information about the result

of a previous QoS NSLP message. This includes explicit confirmation of the state

manipulation signaled in the RESERVE message, the response to a QUERY message or an

error code if the QNE or QNR is unable to provide the requested information or if the

response is negative. The RESPONSE message does not cause any reservation state to be

installed or modified.

NOTIFY: NOTIFY messages are used to convey information to a QNE. They differ

from RESPONSE messages in that they are sent asynchronously and need not refer to any

particular state or previously received message. The information conveyed by a NOTIFY

message is typically related to error conditions. Examples would be notification to an

upstream peer about state being torn down or to indicate when a reservation has been pre-

empted.

QoS NSLP messages are sent peer-to-peer. This means that a QNE considers its

adjacent upstream or downstream peer to be the source of each message.

QoS NSLP messages contain three types of objects:

Control Information: Control information objects carry general information for the

QoS NSLP processing, such as sequence numbers or whether a response is required.

QoS specifications (QSPECs): QSPEC objects describe the actual resources that are

required and depend on the QoS model being used. Besides any resource description

they may also contain other control information used by the RMF's processing.

Policy objects: Policy objects contain data used to authorize the reservation of re-

sources.


A.4.2.2 QoS Specifications and QoS Models

The QoS NSLP provides flexibility over the exact patterns of signalling messages that

are exchanged. Various QoS models can be designed, and these do not affect the

specification of the QoS NSLP protocol. Only the RMF specific to a given QoS model will

need to interpret the QSPEC. A QoS Model defines the behaviour of the RMF, including

inputs and outputs, and how QSPEC information is used to describe resources available,

resources required, traffic descriptions, and control information required by the RMF. A QoS

Model also describes the minimum set of parameters QNEs should use in the QSPEC when

signalling about this QoS Model.

The QSPEC carries a collection of objects that can describe QoS specifications in a

number of different ways. A generic template is defined in [18] and contains object formats

for generally useful elements of the QoS description, which is designed to ensure

interoperability when using the basic set of objects.

All QSPECs should follow the design of the QSPEC template. Figure 28 below

illustrates how the QSPEC is composed of up to four QSPEC objects, namely QoS Desired,

QoS Available, QoS Reserved and Minimum QoS.

Figure 29 : QSPEC Template

QoS Available: it contains parameters describing the available resources. They are

used to collect information along a reservation path.

QoS Desired: it contains parameters describing the desired QoS for which the sender

requests reservation.

QoS Minimum: it allows the QNI to define a range of acceptable QoS levels by in-

cluding both the desired QoS value and the minimum acceptable QoS in the same

message.


QoS Reserved: it contains parameters describing the reserved resources and related

QoS parameters.

At each QNE, the content of the QSPEC is interpreted by the Resource Management

Function and the Policy Control Function for the purposes of traffic and policy control

(including admission control and configuration of the packet classifier and scheduler).

A.4.2.3 Conclusion

NSIS assumes a scalable architecture signalling in two layers and reuses the existing

transport and security. It uses session ID independent of the flow identifier for the state

management. The Session ID (SID) used in NSIS signalling enables the separation of the

signalling state and the IP addresses of the communicating hosts. This makes it possible to

directly update a signalling state in the network due to mobility without being forced to first

remove the old state and then re-establish a new one.

In the NGN context, the change of route or IP addresses in mobile environments is

typically much faster and more frequent than traditional route changes caused by node or link

failure. Is NSIS sufficient for the self-management and self-adaptation to whatever change in

the user-centric session?

A.5. User interface to the heterogeneous network for QoS

In the NGN context chapter, we have mentioned the user-centric requirements for the

Next Generation Service. We should extend QoS research from core to edge. In such End-to-

End session, the user connectivity to heterogeneous network for the service with QoS is

considered as an important part of resolving the E2E QoS in the NGN. TISPAN has proposed

the Home Networking conception which contains Customer Network Device (CND) and

Customer Network Gateway (CNG), to interact with TISPAN NGN for variety of services in

the home environment.

TISPAN began to cover home devices and home networking issues from 2006 and a

specific working group (WG5) was created in TISPAN to develop service requirements,

functional architectures and protocols for the entities involved in the home network

environment.

In this section, we will provide an overview of service scenarios in Home Networking

(also named customer premises network or CPN in TISPAN) (§ 5.1.1), the way it interacts


with the NGN-IMS networks which is described in the ETSI TISPAN Release 1 standards [8]

(§ 5.1.2) and the QoS related blocks in the CPN architecture (§ 5.1.3).

A.5.1 Customer Premises Network to TISPAN NGN

The use cases can be grouped in the following categories [19]:

1) Broadband connection

The user wants to access the Internet from a number of PCs at home, and may also

decide to subscribe to new services (e.g. parental control, online audio streaming, etc.) offered

by his ISP (Internet Service Provider) or an ASP (Application Service Provider), via email or

online.

From the service provider point of view, the service must be remotely activated via auto-

provisioning, the necessary connectivity to deliver the service, including QoS should be

guaranteed and there should be the possibility of remotely debug the customer problems.

2) Communication

Communication services can be divided at least in three categories:

1. Person-to-Person communication (P2P)

P2P communication is intended as voice or voice/video communication and it could be

performed in five different ways:

• Voice / VoIP with IP phone

• Voice over IP with legacy analogue phone.

• Video Communication

• Text communication with legacy text telephone

• Computer-originated text communication to PSTN

The service provider must guarantee the necessary connectivity to deliver the voice,

voice/video, or text service, as well as the necessary quality of service.

2. Person-to-Machine communication (P2M)

A typical P2M communication use case is, for example to remotely access a device to

access the home media server and upload or download one's photos.

3. Machine-to-Machine communication (M2M)


One of the typical use cases for M2M communication from the customer network and

NGN standpoints is the automatic electricity meter reading business. With this approach,

network operators can reuse the NGN security functions in CNG (Customer Network

Gateway) and electricity charging server to deliver secure data service between customers'

electricity meters and electricity companies' charging servers.

3) Home worker

In this use case various members of a family simultaneously use the broadband

infrastructure. In particular, parents are connected to their respective corporate intranets over

a secure link and perform a number of actions, including upload and download of documents,

placing VoIP calls for work. They expect to have a simple mechanism by which they can

easily switch from private to corporate calls (billing will be different). While the parents are

working, children must be able to watch video streaming, or browse the Internet. All these

simultaneous applications have to live up to the experiential expectations of the user. Hence

the necessary priorities have to be taken into account within the customer network

environment.

4) Home Management and Security

Two different sub cases are proposed for this category: The first one is related to the

access/parental control. The user wants to make sure that he has an overview on the children

communication and entertainment activities and be able to control the access to these

activities. An access control service can be built up with the following capabilities: Content

check, Cost check, Usage check, Time check. The user must have the capability to check the

configuration of the access control service via a terminal (e.g. a PC) and to change the

parental control configurations by himself as administrator. From the service provider point of

view, a number of mechanisms for service activation, billing and web based consumer

support in case of problems must be ensured.

The second sub case is to the personal monitoring. In this use case the user must be able

to access images coming from a camera installed at home, via an Internet browser on a remote

PC or/and via a mobile Internet connection.

5) Provisioning and Service configuration

A set of parameters shall be configured on UE (device that contains the SIP UA) to

access to IMS network. These parameters should be provisioned on UE in order to the user to

make seamlessly the UE registration to IMS. There are four kinds of configurations:

First Provisioning (Manual)


First Provisioning (Automatic)

Manual Re-Configuration

Self Re-Configuration Service

6) Entertainment and information

Three specific use case scenarios are proposed for this category. The first one is related

to the broadcast IPTV service usage inside the house, the second one to the access the

contents stored in a media gateway, the third one to gaming.

7) Remote Access

When a user is away from its customer network, it is in many situations valuable to be

able to access services on the customer network. Remote access can be divided into two

categories: access of devices and access of services. An example of the first category is

uploading the latest vacation pictures or films to a storage server on the customer network or

when a user sends a message to his home to turn on/off a device. An example of the second

category includes accessing a surveillance camera service to check that everything is in order.

A.5.2 Service scenarios description

In this sub-section, we detail the TISPAN Architectural Model for the CPN and

interactions with NGN-IMS entities. The CPN is composed with Customer Network Gateway

(CNG) and Customer Network Device (CND) entities. Examples of Customer Network

Devices may be connected to the CNG:

a) Analog phones connected through the CNG to the NGN network.

b) IMS Customer Network Devices connected through a CNG to the NGN network.

c) Non IMS SIP IETF Customer Network Devices.

d) ISDN Customer Network Devices through the CNG to the NGN network.

Different types of Customer Network Devices may be involved in Intra CPN

communication through a CNG. The list of Customer Network Devices which are likely to be

connected to the CNG is provided by the [20].

The CNG functional entities which are used to interact with TISPAN NGN network are

shown in Figure 30 below, as well as the reference points between each function.


Figure 30 : IMS Customer Network Device connected to the NGN-IMS network through a CNG

The entities and interfaces in red are network attachment functions, admission control

function, policy control function, authentication function, and location function etc. The

entities and interfaces in green are for the transport of the service media. The entities and

interfaces in pink are dedicated to the service layer functions. Meanwhile, in the CNG, there

are interfaces among the three level entities to allow for exchanges of pieces of information.

A.5.3 CPN architecture model interacting with the NGN/IMS networks

In the CNG, it has defined some QoS related entities, for instance:

1. CNG-PCF: CNG-Policy Control Function

The CNG-PCF may integrate a database containing the access profile. This includes

bandwidth and QoS parameters for the CNG Customer Network Device side applications and

terminals, which could be configured by a user. For instance, congestion issues within the

CPN may be solved defining resources for several SSID.

2. CNG-ACF: CNG-Admission Control Function

The CNG-ACF should receive and send QoS messages from/to the CNG-SIP proxy

B2BUA Function. In particular it should:


a) Check resources availability on each link/device involved in the communication

requesting a QoS reservation/allocation, through an internal database ;

b) Perform the appropriate resources reservation, through the CNG-PCF.

Thus, the CNG-ACF should manage session limitations for instance or the priority of

media streams. This applies to upstream flows but there may also be an opportunity to do so

for downstream flows. The module is considered as optional (as Gm' and Gm interfaces

related to the SIP proxy).

The objective is to guaranty the quality of service for each new session and existing

sessions previously established. The B2BUA extracts from SIP messages the SDP offer and

announced capabilities (codec audio, video, etc.). It asks to the CNG-ACF if announced

capabilities are compliant with the available resources.

The CNG-ACF module returns 3 responses:

a) OK:

a) The resource is available for all announced codecs.

b) The initial SIP message is forwarded without any change on SDP part.

b) OK with restriction:

a) The initial SIP message is modified (incompatible codecs are suppressed from

SDP part) and then forwarded.

b) The session can be established with an acceptable codec for network resource.

c) Not OK:

a) The B2BUA rejects the session establishment.

Figure 31 below shows the procedure of admission control in CNG:

Figure 31 : Admission control within the CNG


3. CNG-UIF: CNG-User Interface Function

The CNG-UIF entity should allow the user to configure many CNG parameters for the

transport layer:

a) Firewall rules, possibly defined for each user (e.g. parental control);

b) CNDs authorized within the CPN, with possible bandwidth restrictions.

The operator shall be able to prevent a user from modifying a specific subset of CPN

parameters. Thus this entity may have reference points with the CNG-AuF and the CNG-NFF

of the CNG.

A.5.4 Conclusion

For the service and network providers, the CPN speeds up broadband deployment and

multi-service implementation. More important, the QoS related entities in the CPN give the

possibility to deal with the QoS issue on the user side in an End-to-End session with QoS

continuity. Therefore, we should take it into account in our STF 360 work.

A.6. QoS Interworking (Mobility in the heterogeneous environment):

In the heterogeneous networks, network technologies differ in the bandwidth, latency,

cost and QoS classification used. Mobility occurs between these access networks to maintain

minimum QoS contracts for different applications. Supporting this seamless mobility, or

interconnection and interoperation across the heterogeneous networks (QoS interworking) is

seen as one of the key issues in the management of heterogeneous networks.

There is already some work done related to this issue, for example, SIP, which we

have presented in the precedent chapter and which is proposed as the session based signalling

protocol working on application layer to support session mobility. The purpose of the Media

Independent Handover is to manage the seamless connectivity with different wireless

networks (§ 6.1). Mobile IPv6 is a protocol working on network layer to support not only

horizontal but also vertical handover (§ 6.2). The three protocols work on respective layer of

OSI, shown in Figure 32.


Figure 32 : Related work in mobility management in OSI architecureMoreover, QoS class definition which could be interpreted by different network

technologies is a key point for QoS interworking. Therefore, Y. 1541 class will be introduced

in § 6.3.

A.6.1 MIH

IEEE 802.21 [21] introduces the concept of MIH (to carry out the handover between

heterogeneous technologies). This standard is under development. Its main purpose is to

manage seamless connectivity with different wireless networks. This standard is managing the

handover between cellular networks, WiFi and Bluetooth etc.

A.6.1.1 Media Independent Handover Scope

In our context of heterogeneous networks, we must consider the vertical handover

because it allows adaptation between different network technologies in a flexible manner.

Mobility management is primarily concerned with handover initiation and network selection.

Admission control is an inherent part of the handover execution stage and governs access to

the chosen network. The MIH is in the scope of the first two steps: handover initiation and

handover preparation, as shown in Figure 33. The IEEE 802.21 standard defines the

framework that is needed to exchange information between handover participants to provide

mobility. It also defines functional components taking handover decision.


Figure 33 : 802.21 scope

A.6.1.2 Media Independent Handover Function

The IEEE 802.21 framework offers the method and procedure for handover between

heterogeneous networks. This handover procedure uses the information from both mobile

terminal and network infrastructures. The IEEE 802.21 framework informs the available

network nearby of the mobile terminal and helps the mobile terminal to detect and select the

network. This information includes link layer information.

Figure 34 : 802.21 Functional Components


The core of 802.21 lies in MIHF (Media Independent Handover Function) which plays

the role of intermediate operation between layer 2 and layer 3. It presents homogeneous

interfaces independent from access technologies. This interface charges the communication

between the upper layer and the lower layer. Figure 34 shows the media independent

handover functional components. MIHF provides three services: MIES (Media Independent

Event Service), MICS (Media Independent Command Service), and MIIS (Media

Independent Information Service).

MIES

MIES proffers the local or remote event to the upper layer. The MIES supports the

transfer, filtering and classification of dynamic changes on the link layer. It may transfer the

link level event to the proper application or process and then pass on to the higher layers. The

events are generated locally or by a remote peer MIHF entity. Figure 35 shows the framework

for both local and remote event exchange.

Figure 35 : Media Independent Event ServiceLink Events are classified into four categories:

o State change event, for example, MAC and Physic state change event ( Link_up or

Link_down) and Link parameter events which are generated due to change in link

parameters (Link Parameter Change)

o Predictive events, which provide the likelihood of change in the link properties in

future based on present and past conditions (Link Going Down)

o Link Synchronous events which provide information about actual link layer activit-

ies, like handover decision at the link layer


o Link transmission events which indicate the status of the transmission of higher

layer PDUs by the link layer

Example link events which are proposed in 802.21 are shown in the following Table 4

Table 4 : Proposed link events in 802.21

MICS

The MICS offers the functions to control and manage the link layer. If the MIH

application wants handover and mobility, it can control the MAC layer by using MICS to

configure, control and get information. Commands flow from higher to lower layers. Figure

36 shows the MICS function framework. MIH users use MIH commands to determine the

status of a link. This service enables users to implement an optimal handover policy.


Figure 36: Media Independent Command Service

MIIS

Figure 37 : Media Independent Information ServiceThe MIIS offers information that is needed to perform the handover. Information is

maintained in Information Server in the network (Figure 37). This information includes the

name of network and operator, supported QoS, address of point of attachments, available

applications and nearby available access networks etc. Information Service can help with

Network Discovery and Selection for specific QoS leading to more effective Handover

decisions. Table 5 shows the information elements defined in MIIS.


Table 5 : Information elements

The information is represented in a common form across different networks using

TLV (Type, Length, and Value). Figure 38 shows an example of a MIIS message.

Figure 38 : MIIS Message

A.6.1.3 Conclusion

IEEE 802.21 helps with Handover Initiation, Network Selection and Interface

Activation during Vertical Handovers for next generation wireless All-IP networks. The

802.21 enables Co-operative Handover decision making between Clients and Network. But

how to solve the vertical handover in the wireless and fix network is not covered in the scope

of MIH.

A.6.2 Mobile IPv6

Mobile IPv6 allows a mobile node to move from one link to another without changing

the mobile node's "home address". Packets may be routed to the mobile node using this


address regardless of the mobile node's current point of attachment to the Internet. The

mobile node may also continue to communicate with other nodes (stationary or mobile) after

moving to a new link. The movement of a mobile node away from its home link is thus

transparent to transport and higher-layer protocols and applications.

One can think of the Mobile IPv6 protocol as solving the network-layer mobility

management problem. Some mobility management applications -- for example, handover

among wireless transceivers, each of which covers only a very small geographic area -- have

been solved using link-layer techniques.

A.6.2.1 Mobile IPv6 architecture

There are some general design requirements for Mobile IP [23]:

1. Detection: the mobile node must detect it has moved

2. Address Configuration: the mobile node must discover or configure its care-of-

address

3. Binding Update: the mobile node must inform the home agent about its new care-

of address

4. Tunnelling: the home agent must forward packets from the home network to the

mobile node’s care-of address

Figure 39 shows the architecture of Mobile IPv6


Figure 39 : Mobile IPv6 Architecture

Home Agent (HA)

A router on the home network which represents the MN while it’s not attached with

the home network

Home Address (HoA)

A (static) IP address out of the mobile nodes home network

Mobile Node (MN)

Could change its point of attachment while still being reachable via HoA

Foreign Agent (FA)

A router in the foreign network which represents the MN while it’s attached with the

foreign network

Unlike in Mobile IPv4, in Mobile IPv6 there are not foreign agents in the foreign

network, just the IPv6 router.

Care of Address (CoA)

The physical IP address of a MN while visiting a foreign network

Correspondent Node (CN)

A peer node with which a MN is communicating, the CN may be either mobile or

stationary


Binding

Association of the home address with the Care-of address of a MN

A.6.2.2 Mobile IPv6 smooth handover process

Figure 40 : Mobile IPv6 smooth handover processMobile IPv6 has four new destination options [23]:

Binding Update

Used by an MN to inform its HA or any other CN about its current care-of

address

Binding Acknowledgement

Used to acknowledge the receipt of a Binding Update

Binding Request

Used by any node to request an MN to send a Binding Update with the

current care-of address

Home Address

Used in a packet sent by a mobile node to inform the receiver of this packet

about the mobile node’s home address

Figure 40 presents the process of handover when the MN moves between different

access networks:

(1) MN sends a Binding Update to an HA on previous network

(2) HA returns a Binding Acknowledgement


(3) HA tunnels packets to MN

(4) MN sends a Binding Update to CN

A.6.2.3 Mobile IPv6 and QoS

In the IPv6 header, it has two QoS-related fields. They are:

20-bit Flow Label

Used by a source to label sequences of packets for which it requests special handling

by the IPv6 routers Geared to IntServ and RSVP

8-bit Traffic Class Indicator

Used by originating nodes and/or forwarding routers to identify and distinguish

between different classes or priorities of IPv6 packets Geared to DiffServ

Moreover, Mobile IPv6 has a new IPv6 option: QoS Object. QoS Object describes

QoS requirement, traffic volume and packet classification parameters for MN's packet stream

Included as a Destination Option in IPv6 packets carrying Binding Update and Biding

Acknowledgment messages

A.6.2.4 Conclusion

Mobile IPv6 allows easier configuration, better security and optimization; it minimizes

the control traffic needed to effect mobility. But Mobile IP is not a complete mobility

solution; it needs to cooperate with other mobility management protocol.

A.6.3 Y.1541 and Y.1541-QOSM

A.6.3.1 Y. 1541 Class

Y.1541 QoS classes quantify user application needs in terms of IP network

performance. ITU-T Y.1541 QoS classes are defined based on metrics defined in ITU-T

Y.1540. Y. 1540 defines four criteria:

IP Packet Transfer Delay (IPTD): upper bound on the mean end-to-end delay.

IP Packet Delay Variation (IPDV): upper bound on the 1-10-3 on the IPTD minus the

minimum IPTD.

IP Packet Loss Ratio (IPLR): upper bound on the packet loss probability.

IP Packet Errored Ratio (IPER): upper bound on the number of corrupted packets per

total packets sent.

Figure 41 presents the detail information of 8 QoS classes of Y.1541 [24]:


Figure 41 : Y.1541 IP QoS Class Definitions and Network Performance Objectives

These classes enable SLAs to be defined between customers and network service

providers with respect to QoS requirements. The service provider then needs to ensure that

the requirements are recognized and receive appropriate treatment across network layers.

A.6.3.2 Y.1541-QOSM

QoS model (QOSM) for NSIS QoS signalling layer protocol (QoS-NSLP) application

is based on ITU-T Y.1541 Network QoS Classes and related signalling requirements [25].

Y.1541 currently specifies 8 classes of Network Performance objectives, and the Y.1541-

QOSM extensions include additional QSPEC parameters and QOSM processing guidelines.

Figure 42 shows the translation considerations of QoS Model to Y. 1541 and Y. 1541-QOSM,

also the specific parameters in other standards (802. 16, 802.20)


Figure 42 : Translation of QoS Metrics to other specific parameters

A.6.3.3 Conclusion

The attributes of Y.1541 QoS Classes encompass major IP application categories,

relate to IP network QoS mechanisms, and are able to support QoS negotiation among

systems. Therefore, Y.1541 QoS class meet the need for QoS interworking.


Annex B:Standard & Bibliographical References

[1] ETSI EG 202 132 V1.0.0 (2004-08): Human Factors (HF); User Interfaces;

Guidelines for generic user interface elements for mobile terminals and

services

[2] TeleManagement Forum, http://www.tmforum.org

[3] ITU-T Recommendation Q.1706/Y.2801 (2006), Mobility management re-

quirements for NGN

[4] J.Manner, M.Kojo et al. RFC 3753: Mobility Related Terminology, June

2004

[5] 3GPP TR 25.832 V4.0.0 (2001-03): "3rd Generation Partnership Project;

Technical Specification Group Radio Access Network; Manifestations of

Handover and SRNS Relocation (Release 4)"

[6] Grilles Bertrand, “The IP Multimedia Subsystem(IMS)-An overview”

[7] ETSI TS 123 228 V8.6.0 (2008-10): "Digital cellular telecommunications

system (Phase 2+); Universal Mobile Telecommunications System

(UMTS); LTE;IP Multimedia Subsystem (IMS); Stage 2(3GPP TS

23.228 version 8.6.0 Release 8)"

[8] ETSI ES 282 001 V2.0.0 (2008-03) NGN Functional Architecture

[9] ETSI TS 129 208 V6.7.0 (2007-06): Digital cellular telecommunications


(UMTS); End-to-end Quality of Service (QoS) signalling flows (3GPP

TS 29.208 version 6.7.0 Release 6)"

http://www.tmforum.org/


[10] Th. Magedanz Senior Member IEEE, F.C. de Gouveia, “IMS-the IP

Multimedia System as NGN Service Delivery Platform”, Bektrotechnik &

Informationstechnik (2006), pp. 271-276

[11] ETSI TS 129 214 V8.2.0 (2008-10): "Universal Mobile Telecommunica-

tions System (UMTS);Policy and charging control over Rx reference

point (3GPP TS 29.214 version 8.2.0 Release 8)"

[12] ETSI TS 129 212 V8.1.0 (2008-10): "Universal Mobile Telecommunica-

tions System (UMTS);Policy and charging control over Gx reference

point (3GPP TS 29.212 version 8.1.0 Release 8)"

[13] RFC 4006: Diameter Credit-Control Application (2005-08)

[14] RFC 3261: SIP(Session Initiation Protocol) (2002-06)

[15] RFC 2327: SDP(Session Description Protocol) (1998-04)

[16] RFC 4080: NSIS Framework, June 2005

[17] NLSP for QoS : http://www.ietf.org/html.charters/nsis-charter.html

[18] QoS NSLP QSPEC Template : http://www.ietf.org/html.charters/nsis-

charter.html

[19] ETSI TS 185 005 V2.0.0 (2007-07): "Telecommunications and Internet

converged Services and Protocols for Advanced Networking (TISPAN);

Services requirements and capabilities for customer networks connec-

ted to TISPAN NGN".



Customer Devices architecture and Reference Points"

[21] IEEE 802.21: Media Independent Handover; QOS Framework and

parameters, February 17, 2006

http://www.ietf.org/html.charters/nsis-charter.html%20


http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-21.txt



[22] RFC 3344: Mobility Support in IPv4, (2002-08)

[23] RFC 3775: Mobility Support in IPv6, (2004-06)

[24] ITU-T Y.1541: Network Performance objectives for IP-based services,

(2006-02)

[25] IETF Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541

QoS Classes, (2008-02) http://tools.ietf.org/html/draft-ash-nsis-y1541-

qosm-00

[26] ETSI TS 129 213 V8.1.1 (2008-11) "Digital cellular telecommunications


(UMTS); Policy and charging control signalling flows and Quality of Ser-

vice (QoS) parameter mapping (current version: 3GPP TS 29.213 ver-

sion 8.1.1 Release 8)"

[27] ETSI TS 123 234 V7.7.0 (2008-06): Universal Mobile Telecommunica-

tions System (UMTS); 3GPP system to Wireless Local Area Network

(WLAN) interworking; System description (current version: 3GPP TS

23.234 version 7.7.0 Release 7)



(UMTS); End-to-end Quality of Service (QoS) concept and architecture

(current version: 3GPP TS 23.207 version 7.0.0 Release 7)



(UMTS);End-to-end Quality of Service (QoS) signalling flows (current

version: 3GPP TS 29.208 version 6.7.0 Release 6)

http://tools.ietf.org/html/draft-ash-nsis-y1541-qosm-00

http://tools.ietf.org/html/draft-ash-nsis-y1541-qosm-00


[30] RFC 2748: “The COPS (Common Open Policy Service) Protocol,” IETF,

Tech. Rep., 2000.

[31] ITU-T Y.1251 General architectural model for interworking, 08/2002

[32] ITU-T H.360: An architecture for end-to-end QoS control and signalling,

03/2004

[33] RFC 4094: Analysis of Existing Quality-of-Service Signalling Protocols

may 2005

[34] ETSI ES 282 004 V2.0.0 (2008-02): “Telecommunications and Internet


NGN Functional Architecture; Network Attachment Sub System

(NASS).”

[35] ETSI ES 282 003 V2.0.0 (2008-05): “Telecommunications and Internet


Resource and Admission Control Sub-system (RACS); Functional Ar-

chitecture”

[36] ETSI ES 282 007 V2.1.1 (2008-11): “TISPAN: IP Multimedia Subsystem

(IMS): Functional Architecture.”

[37] ETSI ES 282 002 V1.1.1 (2006-03): "Telecommunications and Internet


PSTN/ISDN Emulation Sub-system (PES); Functional architecture" (see

also TS 182 012)



IPTV Architecture; Dedicated subsystem for IPTV functions"




IPTV Architecture; IPTV functions supported by the IMS subsystem"

[40] 3GPP TS 24 229 V2.0.0 (2002-02): "3rd Generation Partnership Pro-

ject; Technical Specification Group Core Network; IP Multimedia Call

Control Protocol based on Session Initiation Protocol (SIP) and Session

Description Protocol (SDP) Stage 3 (Release 5)"

[41] ETSI ES 283 003 V1.1.1 (2006-07): Telecommunications and Internet


IP Multimedia Call Control Protocol based on Session Initiation Protocol

(SIP) and Session Description Protocol (SDP) Stage 3 [3GPP TS

24.229 (Release 7), modified]

[42] ITU-T Y.1540 (11/2007): Internet protocol data communication service –

IP packet transfer and availability performance parameters.

figure 2.doc

Documents

qos continuity

qos interworking

qos issue

e2e qos signalling

qos informational structure

sip messages

user centric

user case