INTERNATIONAL TELECOMMUNICATION UNION STUDY ... · Member States of ITU, by ITU-T Sector Members and Associates, and their respective staff and collaborators in their ITU related

Contact: Seok J. Koh KNU KOREA

Tel: +82-53-950-7356 Fax: +82-53-950-6369 Email: [email protected]

Contact: Qin Wu Huawei Technologies CHINA

Tel: +86-025-84565054 Fax: +86-025-84565070 Email: [email protected]

Attention: This is not a publication made available to the public, but an internal ITU-T Document intended only for use by the Member States of ITU, by ITU-T Sector Members and Associates, and their respective staff and collaborators in their ITU related work. It shall not be made available to, and used by, any other persons or entities without the prior written consent of ITU-T.

INTERNATIONAL TELECOMMUNICATION UNION STUDY GROUP 13

TD 12 (WP 3/13)TELECOMMUNICATION STANDARDIZATION SECTOR STUDY PERIOD 2009-2012 English only

Original: EnglishQuestion(s): 8/13 Geneva, 12-23 January 2009

TEMPORARY DOCUMENT

Source: Editors

Title: Draft Recommendation Y.SMF v0.4

This is the output document of draft Recommendation Y.SMF version 0.4, which was produced during the Q.8/13 meeting in January 2009.

Y.SMF has been progressed as indicated by the following version history:

Version Date Meeting

0.1 May 2008 NGN-GSI Meeting 0.2 July 2008 Q.2/19 & Q.6/13 Joint E-meeting 0.3 September 2008 SG13 & SG19 Meeting 0.4 January 2009 SG13 Meeting

- 2 - TD 12 (WP3/13)

ITU-T Draft New Recommendation Y.SMF

Framework of Mobility Management in Service Stratum for NGN

Summary TBD

Keywords Mobility Management, Framework, Service Stratum, Multimedia Services, NGN

Introduction This Recommendation describes the framework of MM in Service Stratum for NGN. This work has been motivated from the observation that the mobility management is an essential functionality to provide seamless mobility for the NGN users and services. This Recommendation is a part of the MM framework for NGN, which has been addressed with the following Recommendations: Q.1707, Q.LMF, Q.HCF, and Q.SMF. Based on the generic framework of Q.1707, Q.LMF and Q.HCF address the MM schemes in the NGN Transport Stratum (network layer), and this Q.SMF deals with the MM schemes in the NGN Service Stratum (in the application/session layers).

- 3 - TD 12 (WP3/13)

TABLE OF CONTENTS

1 Scope ............................................................................................................................4

2 References.....................................................................................................................4

3 Definitions ....................................................................................................................4

4 Abbreviations and Acronyms .......................................................................................4

5 Design Considerations ..................................................................................................6

5.1 Mapping between IMS and MMCF in Service Stratum.................................6

5.2 Classification of MM Schemes in Service Stratum........................................7

6 Functional Architecture for MM in Service Stratum....................................................8

6.1 Architectural Model........................................................................................8

6.2 Functional Entities..........................................................................................9

6.3 MM Functionality...........................................................................................12

7 Information Flows for Location Management..............................................................13

7.1 IMS-based Location Management .................................................................13

7.2 Non-IMS based Location Management..........................................................16

8 Information Flows for Handover Control.....................................................................17

8.1 IMS-based Handover......................................................................................17

8.2 Non-IMS based Handover..............................................................................20

8.3 End-to-end Handover .....................................................................................20

8.4 Handover Optimization ..................................................................................20

Appendix A. SIP-based MM Scenarios ...................................................................................21

Appendix B. SCTP-based Handover Scenarios.......................................................................35

Appendix C. Multimedia Services Scenarios ..........................................................................40

Appendix D. Network Architecture of VCC with MIH...........................................................42

Appendix E. Bibliography .......................................................................................................47

- 4 - TD 12 (WP3/13)

1 Scope

This Recommendation describes the framework of mobility management (MM) in Service Stratum for NGN, which deals with the MM schemes in the NGN Service Stratum. This Recommendation addresses the issues on IP mobility in the application/session layers. MM issues considered in this Recommendation include IMS-based MM as well as non-IMS based MM, together with the consideration of QoS support. MM protocols considered in this Recommendation include SIP in the application layer and SCTP in the session layer. With this purpose, this Recommendation identifies the functional architecture of MM in the NGN Service Stratum, and specifies the procedural information flows for location (IP address of users) management and handover control based on the identified functional architecture.

Editor’s Note: The Scope may need to be further refined. Relevant contributions are invited.

2 References

[Y.2012] ITU-T Recommendation Y.2012 (2006), Functional requirements and architecture of the NGN.

[Y.2091] ITU-T Recommendation Y.2091 (2007), Terms and definitions for Next Generation Networks.

[Q.1706/Y.2801] ITU-T Recommendation Q.1706/Y.2801 (2006), Mobility management requirements for next generation networks.

[Q.1707/Y.2804] ITU-T Recommendation Q.1707/Y.2804 (2008), Generic framework of mobility management for next generation networks.

[Q/Y.LMF] ITU-T Draft New Recommendation Q/Y.LMF (working in progress), Framework of location management for next generation networks.

[Q/Y.HCF] ITU-T Draft New Recommendation Q/Y.HCF (working in progress), Framework of handover control for next generation networks.

[RFC3261] TBD

3 Definitions

Editor’s Note: Some definitions will be added, if necessary. Relevant contributions are invited.

TBD

4 Abbreviations and Acronyms

Editor’s Note: Some more terms need to be added. Relevant contributions are invited.

NGN Next Generation Networks

- 5 - TD 12 (WP3/13)

IMS IP Multimedia Subsystem

SCF Service Control Function

ASF Application Support Function

SSF Services Support Function

CSC-FE Call Session Control Functional Entity

SIP Session Initiation Protocol

SCTP Stream Control Transport Protocol

TCP Transmission Control Protocol

UDP User Datagram Protocol

IP Internet Protocol

MIH Media Independent Handover

UE User Equipment

- 6 - TD 12 (WP3/13)

5 Design Considerations

Editor’s Note: This section will describe some general principles or observations to be considered for design of the MM framework in the NGN Service Stratum. Relevant contributions are invited.

This Recommendation considers IP mobility in the application/session layers. In the NGN, a user or a UE (User Equipment) changes its IP address by movement and thus the user may experience service disruption and session discontinuity. This Recommendation deals with the MM schemes or protocols that can be used to provide seamless services and session continuity against the movement of users. To provide seamless mobility, the link-layer information on the concerned access links might be used in the MM schemes, as shown in the IEEE 802.21 MIH. In this fashion, the so-called cross-layer design or optimization needs to be taken to provide seamless mobility. However, the details of a specific access technology are outside the scope of this Recommendation.

In general, the MM schemes for mobility support in NGN can be classified into the network-layer MM (in Transport Stratum) and application/session-layer MM (in Service Stratum). The MM issues in the network-layer and Transport Stratum are addressed in the Recommendations Q.LMF and Q.HCF. This Recommendation focuses on the MM issues in the higher layer and Service Stratum. In the application layer, the SIP-based IMS platform will be considered and enhanced to provide seamless mobility. This Recommendation will also consider the non-IMS MM schemes and the end-to-end MM schemes which may be associated with a variety of protocols rather than SIP. In the session layer, SCTP can be investigated as a handover scheme that supports the multi-homing in the transport layer. The MM mechanisms need to consider the QoS support. In addition, the other MM protocols or schemes can be considered to provide seamless mobility in the NGN Service Stratum. Some MM schemes may be performed in the end-to-end fashion without the help of the network, whereas the others may exploit a function or functional entity that is pre-configured in the NGN Service Stratum.

This Recommendation describes the framework of MM in the NGN Service Stratum. The MM functional architecture based on IMS as well as non-IMS platform will be identified by considering some promising/candidate MM schemes. In the functional architecture, the NGN SCF, SSF and ASF functions will be examined and enhanced to support seamless mobility. Based on the identified functional architecture, the procedural information flows will be described for location management (IP address of a UE) and handover control.

5.1 Mapping between IMS and MMCF in Service Stratum

It is noted that IMS registration could be used only for LMF among MMCF functions in service stratum which is defined in Q.1707, rather than whole MMCF functions in service stratum because it does not support handover control. A example usage scenario on how existing IMS functions could be used for MMCF functions in service stratum is considered as follows:

• Use of P-CSCF as A-MMCF (or A-LMF) in service stratum

P-CSCF is the first contact point in the IMS so it could be used for A-MMCF in service stratum which is defined in Q.1707. Note that A-MMCF should support MM2 (Inter-AN) and MM3 (Inter-AN) but conventional P-CSCF supports only call forwarding function. Therefore in this case, new function to support mobility management including MM2 and MM3 should be added to conventional P-CSCF or cooperate with other functions (or functional entities) in transport/service stratum.

- 7 - TD 12 (WP3/13)

Also, in many implementation scenarios of IMS, a P-CSCF (or more) is assumed to be responsible for one access network. Accordingly, the fact supports that the P-CSCF could be naturally mapped into A-MMCF.

• Use of S-CSCF/HSS as C-MMCF in service stratum

S-CSCF is likely to be located in core network and is responsible for accepting registration request. Also it makes the registration information available through the location server (i.e. HSS). Therefore S-CSCF could be mapped into C-MMCF in service stratum along with HSS, which provides location information. Even though, however, S-CSCF provides basic functions for mobility management, it may not sufficient to support full function of C-MMCF, which should support MM1, MM2, and MM3. Therefore in this case, some functions to support mobility management including MM2 and MM3 should be added to conventional P-CSCF or cooperate with other functions (or functional entities) in transport/service stratum.

• Use of I-CSCF

I-CSCF is used only for the assignment of S-CSCF in IMS and does not maintain any information related to registration. Therefore it does not seem to have direct relationship with MMCF in service stratum. However I-CSCF may be used for MM1 using its interworking supporting function.

Editor’s Note: This section needs to describe the HC-related functional entities in terms of IMS.

5.2 Classification of MM Schemes in Service Stratum

Editor’s Note: This section will describe the definitions and comparisons of the IMS-based MM versus non-IMS based MM, and Network-assisted (based) MM versus end-to-end MM, etc.

Relevant contributions are invited.

- 8 - TD 12 (WP3/13)

6 Functional Architecture for MM in Service Stratum

6.1 Architectural Model

Editor’s Note: This section describes the generic architectural model of MM-related function in terms of the NGN-FRA. For this purpose, we can consider the following figure as a baseline material. This figure needs to be modified or extended by including the MM-related functions appropriately. Some new functions can be defined, if necessary.

Relevant contributions are invited.

<Figure1> MM Architecture in Service Stratum

The MM architecture is structured according to a service layer and an transport layer (see figure 1).

The service layer comprises the following components:

Call Session Control Function

Service Authentication Authorization Function

MF

MF MF

MF

MFMF

MF

MF MF

MN

MN

Transport Plane

CN

HCHC

HC

Service Control Plane

Home Network

Visited Network

SAA-FESUP-FE SL-FE

P/S-CSC-FE

- 9 - TD 12 (WP3/13)

Subscription Locator Function

Handover Control Function

In service layer, Mobility Control Functions are broken down into location management functionality and handover control functionality. Call Session Control Functions are defined as a set of functions to provide location management, e g., receive and response location registration, location update and location query from UE or network agent on behalf of UE and maintain location information for each UE while Handover Control Functions (HCF) are defined as a set of control functions that are used to provide the seamless mobility for NGN users and pass the commands from location management to mobility forwarding function as required to set up, modify, and take down bearer paths to achieve handover.

In transport layer, Mobility forwarding functions (MFF) are defined as a set of functions to provide handover enforcement in the transport nodes and encapsulate, decapsulate and forward packets based on bearer path under the control of HCF. Mobility forwarding functions are logical functions that can be instantiated by the current defined transport functions such as EN-FE, ABG-FE and IBG-FE.

Mobility Control function instances and Mobility Forwarding Function instances can be classified into multiple administration domains according to network providers. Each mobility control function instance can control all or a sub-set of mobility forwarding function instances belonging to the same administration domain. Multiple mobility control function instance in the different domain can be interconnected with each other.

6.2 Functional Entities

Editor’s Note: This section will describe the specific functional entities associated with the MM (location management and handover control). For this purpose, the figure below gives the list of the existing FEs in the SCF as a baseline material for information. We need to modify or enhance the figure by including the MM-related FEs. Some new FEs may be added for MM, if necessary. Transport (Control) Function may need to be included in the figure, if some interworking with the function is needed. Relevant contributions are invited.

- 10 - TD 12 (WP3/13)

S-U1S-ON2

S-TC5S-TC1 S-T3

S-12 Network Signaling

Interworking FES-ON1

S-4: Subscription Locator FE

S-5: Service User Profile FE

S-TC2

S-ON3

S-U2S-11: User Signaling

Interworking FE

S-T5

Service Control

S-1: Serving Call Session Control FE

S-T2S-TC3S-T1 S-TC4 S-T4

A-S1 A-S3 A-S4 A-S5 A-S6

Application Support Functions & Service Support Functions

S-15 General Services Control FE

S-14: Media Resource Broker FE

S-6: Service Authentication

& Authorization FE

A-S2

S-3: Interrogating Call Session Control FE

S-8: Access Gateway Control

FE

S-7: Interconnection Border Gateway

Control FE

S-2: Proxy Call Session Control FE

S-13: Media Resource

Control FE

S-10 Breakout Gateway Control

FE

S-9: Media GatewayControl FE

<Figure 2> MM Functional Entities in NGN

.

Editor’s Note: The following subsections will give the detailed functional description of the MM-related FEs that are in the figure above. Some more FEs may be added to the list. The functionality of each FE will be described in the MM point of view. We may need to consider the FEs in the Transport Stratum for MM, if necessary. Relevant contributions are invited.

6.2.1 S-CSC-FE (S1)

The serving call session control functional entity (S-CSC-FE) handles functionality related to session control, e.g., registration, origination of sessions (session setup, modification, and teardown), and routing of session messages. It performs the registration functions for location management

It can learn that a particular user and/or terminal identifier is currently in service and can interact with the SUP-FE (possibly via the SL-FE) to obtain relevant service profile and address information which will act as an input to the service triggering and routing functions of the S-CSC-FE.

6.2.2 P-CSC-FE (S2)

The proxy call session control functional entity (P-CSC-FE) acts as the contact point to the user terminal for session-based services. Its address is discovered by terminals using mechanisms such as static provisioning, an NACF, or other access-specific techniques. The P-CSC-FE has the capability to accept requests and services them internally or forward them on. It shall have the capability to terminate and independently generate session control messages. However, as the key function of the P-CSC-FE is to proxy session control requests, this capability will likely only be used under abnormal conditions.

P-CSC-FE shall have the capability to forward session control requests related to registration to an appropriate I-CSC-FE.

P-CSC-FE-FE shall have the capability to forward session control requests received from the terminal to the S-CSC-FE.

- 11 - TD 12 (WP3/13)

6.2.3 I-CSC-FE (S3)

The interrogating call session control functional entity (I-CSC-FE) is the contact point within an operator's network for all service connections destined to a user of that network operator. The functions performed by the I-CSC-FE are as follows:

Registration

- Assigning an S-CSC-FE to a user.

Session-related and session-unrelated flows

- Obtaining from the SUP-FE the address of the currently assigned S-CSC-FE.

- Forwarding a session control request or response to the S-CSC-FE determined by the above step for incoming sessions.

6.2.4 Subscription Locator FE (S4)

The subscription locator functional entity (SL-FE) may be queried by the S-CSC-FE, I-CSC-FE, or AS-FE to obtain the address of the SUP-FE for the required subscriber. The SL-FE is used to find the address of the physical entity that holds the subscriber data for a given user identifier when multiple, separately addressable SUP-FEs have been deployed by the network operator. This resolution mechanism is not required in networks that utilize a single logical SUP-FE element.

6.2.5 Service User Profile FE (S5)

The service user profile functional entity (SUP-FE) is responsible for storing user profiles, subscriber-related location data, and presence status data in the Service stratum.

1) The SUP-FE performs basic data management and maintenance functions.

• User profile management functions

These functions require access to certain data, either "user subscription data" or "network data" (e.g., the current network access point and network location). The storage and update of this data are handled by the user profile management functions.

A user profile shall be provided in support of:

authentication authorization service subscription information subscriber mobility location presence (e.g., online/offline status) charging

2) The SUP-FE is responsible for responses to queries for user profiles.

a) It provides access to user data.

Other network functions require some user data in order to be appropriately customized. This data can be either "user subscription data" or "network data". This function provides filtered access to the user data, which may be restricted to certain interrogating entities (i.e., restricted rights to access user data), in order to guarantee user data privacy.

b) It may also be used for support of commonly used AAA and security schemes

- 12 - TD 12 (WP3/13)

6.2.6 Service AA-FE (S6)

The service authentication and authorization functional entity (SAA-FE) provides authentication and authorization in the service stratum.

1) It ensures that the end-user has valid utilization rights for the requested service.

2) It performs policy control at the service level by using policy rules contained in a user profile database.

3) It works as the first step in the mobility management process and is used for authentication, authorization, and accounting of users/terminals.

4) The result of the authorization function is a yes/no response to a user connection request

6.3 MM Functionality

Editor’s Note: This section will give the brief description of the MM-related functionality (location management and handover control) that should be provided for seamless mobility, as an introductory statement for the succeeding sections on information flows. Relevant contributions are invited.

Editor’s Note: This section will focus on the enhancements of IMS to support mobility management, as regarding the difference between common IMS and enhanced IMS, relevant contributions are invited to clarify this issue in this section.

6.3.1 Location Registration and Re-registration

- IMS based location management

IMS provides the location registration and update functionality. P-CSC-FE, S-CSC-FE, I-CSC-FE, SUP-FE is involved in this function. When an UE attached into new network region, it registers its current location to S-CSCF via P-CSC-FE, I-CSC-FE.

6.3.2 Location Query

Editor Notes: The text in this section is not enough to address location query mechanism and Further contribution is invited to clarify location query mechanism in Q.1707 and develop other location query scheme in service stratum.

- IMS based location management

IMS also provides the location query functionality for call/session establishment using the I-CSC-FE. I-CSC-FE shall query the SUP-FE for current location and SUP-FE response the address of the current S-CSC-FE for the terminating user.

6.3.3 Handover Control

- 13 - TD 12 (WP3/13)

7 Information Flows for Location Management

Editor’s Note: This section describes the detailed procedural information flows for location management. An abstract ToC is given below just for information. The structure of this ToC can be modified and extended. Relevant contributions are invited.

7.1 IMS-based Location Management

7.1.1 Location Registration and Location Re-registration

[Editor Notes] Further contribution is invited to clarify difference between step3,4 in section 7.1.1 and step 3,4 in section 7.1.2.1 and identify the relationship between location management and session setup.

P-CSC-FE SUP-FEI-CSC-FE

1. Register2. Register

3. Cx- Query/Cx- Select-Pull

UE

Visited Network Home Network

4. Cx- Query Resp/Cx- Select- Pull Resp

7. Cx-Put Resp/Cx-Pull Resp

5 . Register

9 . 200 OK10 . 200 OK

11 . 200 OK

6. Cx-put/Cx-Pull

S- CSCF

8 . Service Control

<Figure 3> Location Registration and location re-registration

1. After the UE has obtained IP connectivity, it can perform the IM registration. To do so, the UE sends the Register information flow to the proxy (Public User Identity, Private User Identity, home network domain name, UE IP address, Instance Identifier, GRUU Support Indication).

2. Upon receipt of the register information flow, the P-CSC-FE shall examine the "home domain name" to discover the entry point to the home network (i.e. the I-CSC-FE). The proxy shall send the Register information flow to the I-CSC-FE (P-CSC-FE address/name, Public User Identity, Private User Identity, P-CSC-FE network identifier, UE IP address). A name-address resolution mechanism is utilised in order to determine the address of

- 14 - TD 12 (WP3/13)

the home network from the home domain name. The P-CSC-FE network identifier is a string that identifies at the home network, the network where the P-CSC-FE is located (e.g., the P-CSC-FE network identifier may be the domain name of the P-CSC-FE network).

3. The I-CSC-FE shall send the Cx-Query/Cx-Select-Pull information flow to the SUP-FE (Public User Identity, Private User Identity, P-CSC-FE network identifier).

The SUP-FE shall check whether the user is registered already. The SUP-FE shall indicate whether the user is allowed to register in that P-CSC-FE network (identified by the P-CSC-FE network identifier) according to the User subscription and operator limitations/restrictions if any.

4. Cx-Query Resp/Cx-Select-Pull Resp is sent from the SUP-FE to the I-CSC-FE. It shall contain the S-CSC-FE name, if it is known by the SUP-FE, or the S-CSC-FE capabilities, if it is necessary to select a new S-CSC-FE. When capabilities are returned the I-CSC-FE shall perform the new S-CSC-FE selection function based on the capabilities returned. If the checking in SUP-FE was not successful the Cx-Query Resp shall reject the registration attempt. It is noted that for location re-registration, step 3 and step 4 is not necessary, since

5. The I-CSC-FE, using the name of the S-CSC-FE, shall determine the address of the S-CSC-FE through a name-address resolution mechanism. The I-CSC-FE also determines the name of a suitable home network contact point, possibly based on information received from the SUP-FE. I-CSC-FE shall then send the register information flow (P-CSC-FE address/name, Public User Identity, Private User Identity, P-CSC-FE network identifier, UE IP address to the selected S-CSC-FE. The home network contact point will be used by the P-CSC-FE to forward session initiation signalling to the home network.

The S-CSC-FE shall store the P-CSC-FE address/name, as supplied by the visited network. This represents the address/name that the home network forwards the subsequent terminating session signalling to the UE. The S-CSC-FE shall store the P-CSC-FE Network ID information.

6. The S-CSC-FE shall send Cx-Put/Cx-Pull (Public User Identity, Private User Identity, S-CSC-FE name) to the SUP-FE.

7. The SUP-FE shall store the S-CSC-FE name for that user and return the information flow Cx-Put Resp/Cx-Pull Resp (user information) to the S-CSC-FE. The user information passed from the SUP-FE to the S-CSC-FE shall include one or more names/addresses information which can be used to access the platform(s) used for service control while the user is registered at this S-CSC-FE. The S-CSC-FE shall store the information for the indicated user. In addition to the names/addresses information, security information may also be sent for use within the S-CSC-FE.

8. Based on the filter criteria, the S-CSC-FE shall send register information to the service control platform and perform whatever service control procedures are appropriate.

9. The S-CSC-FE shall return the 200 OK information flow (home network contact information, a GRUU set) to the I-CSC-FE.

10. The I-CSC-FE shall send information flow 200 OK (home network contact information, a GRUU set) to the P-CSC-FE. The I-CSC-FE shall release all registration information after sending information flow 200 OK.

11. The P-CSC-FE shall store the home network contact information, and shall send information flow 200 OK (a GRUU set) to the UE. The P-CSC-FE may subscribe at the RACF to notifications of the status of the IMS Signalling connectivity.

7.1.2 Location Query

7.1.2.1 Location Query with Call/Session Setup Signaling

- 15 - TD 12 (WP3/13)

S-CSC-FE#1 I-CSC-FEF#2 SUP-FE

1. Inv ite (Initial SDP Offer)


5. Response


9. Off er Response

13. Response Conf (Opt SDP)

17. Conf Ack (Opt SDP)

14. Response Conf (Opt SDP) 15. Response Conf (Opt SDP)

18. Conf Ack (Opt SDP)19. Conf Ack (Opt SDP)

25. Reserv ation Conf

22. Reserv ation Conf 23. Reserv ation Conf

26. Reserv ation Conf27. Reserv ation Conf


29. R inging

S-CSC-FE#2

Originating Home Network Terminating Home NetworkOriginating Network

TerminatingNetwork

4. Location Query


10. Off er Response11. Off er Response

12. Off er Response

16. Response Conf (Opt SDP)

20. Conf Ack (Opt SDP)



33. 200 OK

39. ACK

37. ACK 38. ACK

34. 200 OK35. 200 OK

36. 200 OK

30. R inging31. R inging

32. Ringing

40. ACK

2. Serv ice Control

7. Serv ice Control

<Figure 4> Location query with session setup signalling 1. The SIP INVITE request is sent from the UE to S-CSC-FE#1 by the procedures of the originating flow. This

message should contain the initial media description offer in the SDP.

2. S-CSC-FE#1 invokes whatever service logic is appropriate for this session setup attempt

3. S-CSC-FE#1 performs an analysis of the destination address, and determines the network operator to whom the subscriber belongs. Since it is local, the request is passed to a local I-CSC-FE.

4. I-CSC-FE shall query the SUP-FE for current location information.

5. SUP-FE responds with the address of the current S-CSC-FE for the terminating user.

- 16 - TD 12 (WP3/13)

6. I-CSC-FE forwards the INVITE request to the S-CSC-FE (S-CSC-FE#2) that will handle the session termination.

7. S-CSC-FE#2 invokes whatever service logic is appropriate for this session setup attempt

8. The sequence continues with the message flows determined by the termination procedure.

9-12. The terminating end point responds with an answer to the offered SDP and this message is passed along the established session path.

13-16. The originator decides on the offered set of media streams, confirms receipt of the Offer Response with a Response Confirmation, and forwards this information to S-CSC-FE#1 by the origination procedures. This message is forwarded via the established session path to the terminating end point. The Response Confirmation may also contain SDP. This may be the same SDP as in the Offer Response received in Step 12 or a subset.

17-20. Terminating end point responds to the offered SDP and the response if forwarded to the originating end point via the established session path.

21-24. Originating end point sends successful resource reservation information towards the terminating end point via the established session path.

25-28. Terminating end point sends successful resource reservation acknowledgement towards the originating end point via the established session path

29-32. Terminating end point sends ringing message toward the originating end point via the established session path.

33-36. The SIP final response, 200-OK, is sent by the terminating endpoint over the signalling path. This is typically generated when the user has accepted the incoming session setup attempt. The message is sent to S-CSC-FE#2 per the termination procedure.

37-40. The originating endpoint sends the final acknowledgement to S-CSC-FE#1 by the origination procedures and it is then sent over the signalling path to the terminating end point.

7.1.2.2 Location Query without Call/Session Setup Signaling

Editor Notes: Further contribution is invited to deal with location query without Call/Session Setup signaling support.

7.2 Non-IMS based Location Management

7.2.1 Location Registration and Location Update

7.2.2 Location Query with Call/Session Setup Signaling

7.2.3 Location Query without Call/Session Setup Signaling

- 17 - TD 12 (WP3/13)

8 Information Flows for Handover Control

Editor’s Note: This section describes the detailed procedural information flows for handover management. An abstract ToC is given below. The structure of this ToC can be modified and extended. Relevant contributions are invited

8.1 IMS-based Handover

8.1.1 IMS-based handover by interaction between P-CSCF and S-CSCF

In this handover control scheme, UE is originating a voice call with correspondent UE in the home network. When UE attaches to the new visited network and performs location re-registers with the S-CSCF through new P-CSCF in the visited network. The new P-CSCF and the S-CSCF will notify the new BGF in the visited network and the BGF in the home network to install the new tunnel entry points through the new HCF in the visited network and the C-HCF respectively. After that, the S-CSCF will interact with the old P-CSCF to notify the old BGF to release tunnel resource through the P-HCF in the visited network and the C-HCF in the home network. The detailed signalling flows are described as follows:

a) Before handover

Before handover, the datagram from the corresponding host will be intercepted by the BGF in the home network and then encapsulate and tunnel to the BGF in the previous visited network.

b) During handover

When the mobile host moves to the new visited network, it acquires a new address prior to receiving datagram from corresponding host and performs location re-registers (i.e., join service) with S-CSCF in the home network via P-CSCF in the new visited network. Upon the request of service join from mobile host, the proxy registrar and home registrar will send handover indication request to trigger P-HCF in the new visited network and C-HCF in the home network to perform tunnel entry point installation on BGF in the new visited network. When new tunnel is setup between new BGF in the visited network and BGF in the home network, S-CSCF will interact with old P-CSCF to make old P-HCF and C-HCF release tunnel resource in the old BGF and BGF in the home network.

c) After handover

After handover, the datagram from the corresponding host will be intercepted by the BGF in the home network and then encapsulate and tunnel to the BGF in the new visited network.

- 18 - TD 12 (WP3/13)

8.2.2 IMS based handover control by interaction between two neighboring P-CSCFs

In this handover control scheme, UE is originating a voice call with the correspondent UE in the home network. When UE attaches to the new visited network and performs location re-registers with the S-CSCF through the P-CSCF in the new visited network. The S-CSCF will notify the new P-CSCF about the location of the old P-CSCF. Here we assume two adjacent P-CSCFs in the visited network are allowed to communicate with each other. And then the new P-CSCF will interact with the old P-CSCF to make the P-HCF install tunnel entry point on the old BGF and the new BGF in two adjacent visited networks. When voice call session is terminated, the S-CSCF will notify all the P-CSCFs in the path from the first visited networks to the last visited network to initiate the tunnel resource release. The detailed signalling flows are described as follows:

MN CN BGF1 P-HCF1 P-CSCF1 BGF2 P-HCF2 P-CSCF2 BGF C-HCF S-CSCF

Data Packets Data Packets Data Packets

1. Service Join Request 2. Service Join Request

12. Service Leave Response

9.HC_Ind_Req

11.HC_Ind_Rsp

6. Service Join Response 7. Service Join Response

Data Packets Data Packets

Data Packets

Previous Visited Network New Visited Network Home Network

Before Handover

During Handover

After Handover

3. HC_Ind_ Req

8. Service Leave Request

5. HC_Ind_Rsp

4.TEP install_Req /Rsp

10.TEP_Uninstall_Req/RR_Rs

3

5

4

10

9

11

- 19 - TD 12 (WP3/13)

a) Before handover

Before handover, the datagram from the corresponding host will be intercepted by the BGF in the home network and then tunnelled to the BGF in the previous visited network.

b) During handover

When the mobile host moves to the new visited network, it acquires a new address prior to receiving datagram from the corresponding host and perform location re-registers (i.e., service join) with the S-CSCF in the home network via the P-CSCF in the visited network. Upon receiving service request from UE, the S-CSCF will notify the new P-CSCF about the location of the old P-CSCF by sending service response message. And then the new P-CSCF will interact with the old P-CSCF to make the new P-HCF and the old P-HCF install tunnel entry point in the old BGF and the new BGF in the visited network respectively.

c) After handover

MN CN BGF1 P-HCF1 P-CSCF1 BGF2 P-HCF2 P-CSCF2 BGF C-HCF S-CSCF


1.Service Request 2.Service Request

3.Service Response

9.Service Response


Data Packets


Before Handover

During Handover

After Handover

4.Handover Request

8.Handover Response

5.HC_Ind_Req

7.HC_Ind_Rsp

6.TEP_Install_Req/Rsp

5 6

7

Data Packets

- 20 - TD 12 (WP3/13)

After handover, the datagram from the corresponding host will be firstly intercepted by the BGF in the home network and tunnelled to the BGF in the previous network, upon the BGF in the previous visited network receives the datagram, it will forwarded it to the UE through BGF in the new visited network.

8.2 Non-IMS based Handover

8.3 End-to-end Handover

8.4 Handover Optimization

- 21 - TD 12 (WP3/13)

Appendix A. SIP-based MM Scenarios

Editor’s Note: This Appendix gives some examples of MM schemes in the NGN Service Stratum for information. All of the texts and figures need to be reviewed and refined, in particular, based on the identified MM functional architecture. Some more examples can be added. While the work is progressing, a part of this Appendix may be moved into the main body of This Recommendation. Relevant contributions are invited.

The Session Initiation Protocol (SIP) has been specified in the IETF for supporting the control of IP-based multimedia sessions as a signaling protocol. The SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions. The SIP functional entities include UA, Proxy Server, Redirect Server, Registrar and the location DB. More details on SIP are given in IETF RFC 3261.

On the other hand, the SIP may be used to support handover using the SIP Re-INVITE message.

Caller MT AR1 Called MTAR2 AR3

Data Packets (over location ID1)

MT movesto AR2Handover signaling (SIP Re-INVITE for locatio ID2)

MT movesto AR3



Handover signaling (SIP Re-INVITE for locatio ID3)

<Figure A.1> SIP-based Handover Control

As shown in the figure below, each time a UE moves to a new network (AR2, AR3) during a session, it will send a RE-INVITE message to the corresponding UE. The RE-INVITE message must include a new location ID (IP address) of the UE. After the processing of the RE-INVITE messages, those two UEs can communicate over the new location ID.

It is noted that the SIP-based handover cannot provide seamless mobility, since the on-going TCP/UDP session will be terminated and re-established when the UE changes its IP address.

A.1 Seamless Mobility for IMS using 802.21 and SIP

Building up after the previous scenario using 802.21 in combination with a MIP to improve seamless mobility, a new model is considered in this Clause by having IEEE 802.21 as an application server (AS) to improve IMS seamless mobility; i.e., IEEE 802.21 is used with SIP to

- 22 - TD 12 (WP3/13)

provide seamless mobility across different access networks. Due to the fact that IMS will provide the majority of IP services in the near future and that the current IMS architecture and associated SIP protocol do not provide seamless mobility for packet-based sessions, this model considers IEEE 802.21 to be used as the enabler for seamless mobility for IMS.

Figure A.2 depicts a simplified IMS network, while Figure A.3 shows the migration of 802.21 as an AS in the context of IMS.

AS

HSSSLF

P-CSCF

I-CSCF

Access Network 1

e.g. Cellular

Access Network n and

n+1:WiFi (802.11) or WiMax (802.16)Access Point

IMS EnabledMulti-modal

Device

Internet S-CSCF

IMS Core Network

Node B

<Figure A.2> Simplified IMS Network

The IMS network relies on high level security, reliable QoS, and a standardized framework for easy AS’es service deployment.

The migration of 802.21 to an IMS platform requires that the 801.21 MIH be an IMS client application in the terminal and the inclusion of 802.21 as an IMS application server. This solution also brings the advantages of having minimal HO interruption time, and there is no user involvement in the HO process, thus it provides enhanced user experience.

- 23 - TD 12 (WP3/13)

<Figure A.3> Migration of 802.21 to an IMS Platform

AS

HSSSLF

P-CSCF

I-CSCF

Access Network 1

e.g . Cel lular

Access Network ne.g. WLANAccess Point

IMS EnabledMulti-modal

Device

Internet S-CSCF

IMS Core Network

Node B

802.21 Application

Server

IP

802.21 Application Server

S IP

Mobility Controller

M edia Independent Handover Func tion

(MIHF)

Interworking Function

802.21 FunctionalitySIP

M IHF

Mobil ity Pol ic y

WLAN I/F

Cellular I/F

IP

VoIP Appl ication

802 .21 Appl ication

IMS Applications

Internet

IMS Core

Network

<Figure A.4> High-level description of 802.21 for IMS Model

Figure A-3 shows a high-level description of the IEEE 802.21-IMS model. The left box describes the related components within the terminal, while the right box shows the 802.21 AS functionality.

- 24 - TD 12 (WP3/13)

The bi-directional flow arrows through the IMS core platform and the IP network illustrate the message exchange, as described below.

In the IEEE 802.21-IMS model, the terminal uses standardized 802.21 support to trigger SIP functionality. SIP messages are used to set up an 802.21 session, as shown in the lowest flow between the terminal, the IMS core network, and the 802.21 AS’s SIP function. Directly after session setup, 802.21 messages are exchanged over IP between the terminal’s MIHF function and the 802.21 AS’s 802.21 functionality, as shown in the upper flow. The 802.21 Functionality in the AS triggers the SIP module to send requests during the HO process.

In Figure A-4, the HSS in the IMS Core Network provides the 802.21 Application Server with user preferences and subscription information to perform intersystem handovers optimized decisions. The following flow diagrams explain these interactions in more detail.

In Figures A-5, A-6 and A-7, the VoIP application case is used to show in detail the message flows for:

• IMS registration

• Session setup in the control/signalling plane

• MIH registration

• VoIP session setup

• VoIP session data exchange

• Handover initiation

• Inter-system handover and standardized 802.21 commands to control links

• Handover execution

• Handover completion to resume the on-going VoIP session

- 25 - TD 12 (WP3/13)

Figure A-5: VoIP Session Setup with 802.21 Application Server: IMS registration, SIP session setup, and MIH registration

- 26 - TD 12 (WP3/13)

Figure A-6: Handover initiation by 802.21 Application Server: VoIP session setup, VoIP session data exchange, Standard 802.21 link events for inter-system HO, Commands to control links, and

HO execution

- 27 - TD 12 (WP3/13)

Figure A-7: Handover Completion: 802.21 triggers SIP Messaging

The mobility controller, depicted in the flow diagrams decides whether to switch the subscriber to WLAN, or any other radio access technology (RAT). It requires the user subscription profile and user preferences stored in the HSS. The IMS Sh interface is used to transfer information between the 802.21 AS, using the Mobility Controller, and the HSS.

In Figure A-5, after receiving the MIH_Register Request message from the IMS device enabled UE, the Mobility Controller starts the standardized Sh-Pull procedure with the HSS. It sends the User Identity and requests data related to the specific user. The HSS answers to the Mobility Controller with the Sh-Pull Response message containing User Data; including Networks Ids – with whom the home network has agreements, and/or the user has subscribed to, and therefore roaming is allowed. The Networks Ids may provide to the 802.21 AS user preferences to decide upon handover execution based on current characteristics, as network connection costs, network speed, etc.

In Figure A-7, the UE sends REFER request to the 802.21 AS to trigger the SIP functionality, in turn the Mobility Controller starts the Sh-Update procedure to which the HSS responds with a Sh-Update Response message. The 802.21 AS thus informs the HSS about the IP address change, and the VoIP session resumes.

- 28 - TD 12 (WP3/13)

A.2 Application-layer handover control with mobile agent support

The handover control scheme can be performed with support of agents in the network. The following figure shows the overview of handover control scheme in the session or application layer, within this handover control scheme, P-CSCF and C-CSCF play the role of location management and handover control. RACF acts as arbitrator between IMS component (e.g. CSCF) and transport function (e.g., BGF). On the request of service join from mobile host, RACF in the visited network is triggered by proxy registrar (i.e., P-CSCF) to perform resource admission control on the corresponding transport functions in the visited network. Also the BGFs in the visited network and home network interacts with proxy registrar and home registrar to establish relationship between BGFs. Thereby the datagram from corresponding host could be redirected to the BGF in the current visited network from BGF in the previous visited network or BGF in the home network gracefully. In this way, mobility continuity and transport independent from handover control can be achieved. The only difficult part is the detection ability is required at the application layer to identify when the IP address has changed. The ability to have applications subscriber to be notified of such changes would be preferable.

RACF

MN

CN

BGFBGF

BGFBGF

Movement

Core Network Area

P-CSCF C-CSCF

AF HSS

P-CSCF

BGFBGF

RACF

RACF

Transport Func

SIP Register

SIP Register

SIP Mobility Signaling

Resource Control Signaling

Media Stream for soft handover

Home Network

Previous Visited Network

New Visited Network

BGFBGF

RACF

C-CSCF

AF HSS

Transport Func

Transport Func

Media Stream for hard handover

Figure A-8: Application-layer handover control with mobile agent support

- 29 - TD 12 (WP3/13)

A.2.1 The signalling flows of handover control scheme

According to the association/binding between BGFs during handover, the new BGF in the new visited network may setup association/binding with the BGF in the previous visited network or the BGF in the home network. This sub-clause will describe detailed signalling flows on both approaches.

A.2.2 Soft Handover control in application layer

In soft handover control, the new BGF in the new visited network should setup association/binding with the BGF in the previous visited network. In this way, the datagram from the previous visited network could be delivered to the new BGF in the new visited network gracefully. The detailed signalling flows are described as follows:

d) Before handover

Before handover, the datagram from corresponding host is intercepted by the BGF in the home network and then is redirected to the BGF in the previous visited network.

e) During handover

When the mobile host moves to the new visited network, it acquires a new address prior to receiving datagram from corresponding host and re-registers (i.e., join service) with its home registrar (e.g. collocated with C-CSCF in the home network) via proxy registrar (e.g., collocated with P-CSCF) .Upon the request of service join from mobile host, the proxy registrar will send service request to trigger RACF to perform resource admission control on BGF in the new visited network. During admission control process, BGF location will be notified to proxy registrar by RACF and included in the service request for home registrar. Upon receiving the service request, home registrar will notify proxy registrar in the previous visited network to release QoS resource in the transport function and record the new BGF location in the previous BGF in the previous visited network. Also home registrar should record the location of new proxy registrar each time handover happens. In case of service unregistration, home registrar should notify all the proxy registrars concerned in each visited network during UE moving to release associated QoS resource.

f) After handover

After handover, the datagram from corresponding host is firstly intercepted by the BGF in the home network and redirected to the BGF in the previous network, and then this datagram is intercepted by the BGF in the previous visited network and redirected to the BGF in the new visited network.

- 30 - TD 12 (WP3/13)

MN CN BGF1 RACF1 P-CSCF1 BGF2 RACF2 P-CSCF2 BGF RACF C-CSCF


1. Service Request

5. Service Request

10. Handover Control Response

7.AC Request

9.AC Response

11. Service Response 12. Service Response


Data Packets

Data Packets


Before Handover

During Handover

After Handover

2. AC Request

6. Handover Control Request

4. AC Response

3a.RR_Req

3b.RR_Rsp

8.RR_Req/RR_Rsp

- 31 - TD 12 (WP3/13)

A.2.3 Hard handover control in application layer

In hard handover control, the new BGF in the new visited network should setup association/binding with the BGF in the home network. In this way, the datagram from the home network could be delivered to the new BGF in the new visited network. The detailed signalling flows are described as follows:

a)d) Before handover

Before handover, the datagram from corresponding host is intercepted by the BGF in the home network and then is redirected to the BGF in the previous visited network.

b)e) During handover

When the mobile host moves to the new visited network, it acquires a new address prior to receiving datagram from corresponding host and re-registers (i.e., join service) with its home registrar (e.g. collocated with C-CSCF in the home network) via proxy registrar (e.g., collocated

MN CN BGF1 RACF1 P-CSCF1 BGF2 RACF2 P-CSCF2 BGF RACF C-CSCF


1.Service Request

4.AC Request

6.AC Response

5a.RR_Req

5b.RR_Rsp

2.Service Request

3.Service Response

7.Service Response

Data Packets

Data Packets

Data Packets


Before Handover

During Handover

After Handover

- 32 - TD 12 (WP3/13)

with P-CSCF) .Upon the request of service join from mobile host, the proxy registrar will send service request to trigger RACF to perform resource admission control on BGF in the new visited network.

c)f) After handover

After handover, the datagram from corresponding host is firstly intercepted by the BGF in the home network and redirected to the new BGF in the new visited network, and then the new BGF deliver this datagram is to mobile host.

A.3 SIP with Bicasting for Soft Handover

This Appendix gives an example of SIP handover using bicasting for soft handover. The SIP can be extended to support soft handover with bicasting. In the scheme of SIP handover with bicasting, the soft handover is achieved by bicasting to the mobile node in the handover region. For this purpose, a new ‘handover’ header is defined in the SIP re-INVITE message.

A.3.1 Introduction

In the SIP handover, a mobile node (MN) performs IP handover by sending another INVITE (called re-INVITE) method to the correspondent node (CN) after getting a new IP address. This SIP handover tends to give a large handover latency associated with movement detection and IP address configuration. This is mainly because the SIP handover cannot effectively support the ‘vertical’ handover.

This Appendix proposes an extension of SIP to support the soft handover with ‘bicasting.’ In this handover scheme, an MN will communicate with the CN using bicasting in the handover region.

A.3.2 Normal SIP Handover

The normal SIP handover, based on IETF RFC 3261, can be depicted in Figure 1.

Handover La

tency

Fig. 1. Information flow of the existing SIP handover

- 33 - TD 12 (WP3/13)

In the AR_A region, MN is communicating with CN by using IP address A. As it moves into AR_B region, the media channel with IP address A will be disconnected. MN then begins movement detection and address configuration. After getting a new IP address, MN sends an SIP re-INVITE method, which contains the new IP address, and receives the SIP 200 OK from CN. During this handover period, MN cannot receive the media stream from CN, which induces the concerned handover latency and packet loss. In the figure the SIP ACK method is not shown, since it does not affect the handover latency.

A.3.3 A New Header for SIP Handover with Bicasting

The SIP handover with bicasting is designed to support ‘bicasting’ of media streams from CN to MN during handover. For this purpose, we define a new SIP ‘handover’ header, as follows:

Handover: add | del; ip=a.b.c.d

This new header will be inserted into SIP re-INVITE method. This header instructs CN to add or delete the IP address indicated (a.b.c.d) to or from the associated tables used for SIP signaling and media streams.

In particular, the ‘add’ flag will inform CN to start bicasting to MN (with IP address indicated), in which CN will duplicate and transmits the identical media streams to MN. On the other hand, the ‘del’ flag instructs the CN to stop bicasting (i.e., transmission over the old IP address).

For backward compatibility with the current SIP protocol, the re-INVITE message may include the ‘require’ header in the form of “Require: handover.” If the CN cannot support the mSIP handover (i.e., handover header), it will respond to MN with “420(Bad Extension)”. In this case, MN may try to perform the exiting SIP handover, as described earlier.

It is noted in the SIP handover with bicasting that the re-INVITE message also contains the associated Session Description Protocol (SDP) information in the message body so as to describe the characteristics of the media channels associated with handover, as specified in the RFC 3261.

A.3.4 Operations of SIP Handover with Bicasting

In the SIP handover with bicasting, an MN is assumed to exploit the link-layer triggers such as Link-Up and Link-Down. That is, when the MN goes into the handover region, it will initiate the SIP handover operations with the help of link-layer triggers. On the other hand, it is noted that the existing SIP handover does not use such link-layer information, since the SIP cannot support the soft handover with bicasting.

The procedures of SIP handover with bicasting are illustrated in Figure 2.

In the figure, MN initially uses IP address A (IP_A). When it moves into AR_B region, it will detect a Link-Up for AR_B. It then performs movement detection and obtains a new IP address (IP_B) via DHCP or IPv6 address auto-configuration.

After getting a new IP address, the MN sends an SIP re-INVITE method which contains the information on IP_B and handover header, as specified in the figure. The CN will respond with SIP

- 34 - TD 12 (WP3/13)

OK message to MN. Since then, CN can transmit an identical media stream to MN over both IP_A and IP_B. That is, CN starts bicasting to MN. In this period, MN transmits its own media stream to CN using either IP_A or IP_B.

As the MN further moves into the AR_B region, it will detect the Link-Down event for AR_A. The MN then sends an SIP re-INVITE message to CN, as specified in the figure, so as to stop bicasting (i.e., transmission over IP address A). After the corresponding OK message is received, MN and CN use only the IP_B address.

If AR_A or AR_B can provide different access links to MN at the same time and allocate IP address for MN based on different access technologies, MN could bicast media stream to and from CN. In this scenarios, MN are under control of the same AR, i.e., AR_A could be AR_B.

Bicastin

g

Fig. 2. Information flow of SIP handover with bicasting

A.3.5 Implementation Considerations

In the application point of view, MN will receive the duplicated media streams from CN in the bicasting period. In this case, MN’s application shall select only one of the received two media streams and then discard the other stream. For example, an MN may prefer the media data delivered received from the new IP address to the one received from the old IP address.

In the viewpoint of SIP signaling path, the re-INVITE message with add flag is transmitted over the old IP address, whereas the re-INVITE message with del flag may be delivered over the new IP address. Accordingly, when the CN receives the re-INVITE with add flag, it shall bind its SIP signaling channel to the new IP address as well as the old IP address. After the re-INVITE message with del flag is received, the CN can release the old IP address from its SIP signaling channel.

- 35 - TD 12 (WP3/13)

Appendix B. SCTP-based Handover Scenarios

Editor’s Note: This Appendix gives some examples of MM schemes in the NGN Service Stratum for information. All of the texts and figures need to be reviewed and refined, in particular, based on the identified MM functional architecture. Some more examples can be added. While the work is progressing, a part of this Appendix may be included into the main body of This Recommendation. Relevant contributions are invited.

B.1 Overview of SCTP

The Stream Control Transmission Protocol (SCTP), as defined in IETF RFC 2960, is the third transport layer protocol following TCP and UDP. The SCTP is featured multi-streaming and multi-homing, differently from TCP. It is noted that the multi-homing feature of SCTP enables the SCTP to support the IP mobility.

More specifically, the SCTP with the dynamic ‘Address Configuration (ASCONF)’ extension, which is called ‘mobile SCTP (mSCTP)’, can be used to provide seamless handover for mobile hosts that are moving into different IP network regions during the active session.

The mSCTP may be used as an alternative scheme against the handover schemes based on Mobile IP (Mobile IPv4/Mobile IPv6). Differently from the Mobile IP-based handover schemes, which rely on the support of network routers for tunnelling between access routers, the mobile SCTP provides the handover control at the transport layer without help of routers.

The mSCTP can be used to provide seamless handover for mobile hosts that are moving in to different IP networks. In other words, the mSCTP is targeted for the client-server services, in which the mobile client initiates an SCTP session with the fixed server. For supporting the peer-to-peer services, in which a session is terminated at the mobile host, the mSCTP must be used along with an additional location management scheme such as Mobile IP, Session Initiation Protocol (SIP).

In the NGN environments, the network consists of an IP-based core network and a variety of access networks using heterogeneous access technologies. If each access network use different access technologies and different IP protocol version, network layer handover control may have some problems. If one access network supports IPv4/Mobile IPv4 and the other network supports IPv6/Mobile IPv6, network layer handover control must handle the interconnection between Mobile IPv4 and Mobile IPv6. Although the interconnection between Mobile IPv4 and Mobile IPv6 are studied in IETF, it seems that this job is not easy. But transport layer handover control can solve the problem irrespective of IP protocol version of each access network. Especially, if the IPv6-based NGN networks are used, the characteristic of IPv6 multi-homing and the multi-homing feature of SCTP can be combined.

B.2 Handover Control using SCTP

The SCTP intrinsically provides the multi-homing feature, in which a mobile node is allowed to simultaneously bind multiple IP addresses to its network interface. The recent works on the SCTP

- 36 - TD 12 (WP3/13)

include the ASCONF extension. The ASCONF extension enables the SCTP to add, delete and change the IP addresses during active SCTP association.

The SCTP implementation with the ASCONF extension is called the mobile SCTP (mSCTP). The mSCTP can be used for seamless handover while the mobile node is moving into different IP network regions over the session.

Sessions considered in mobile communications can be classified into the following two types:

a. Session originated from mobile host toward fixed host

b. Session originated from fixed host toward mobile host

The mobile sessions in (a) seem to be a natural extension of the client-server model, in which the mobile host originating the session can be viewed as a client, while the counter endpoint will function as a server. On the other hand, the case (b) requires the additional location management functionality for the session originator to find the current location of the mobile host and to keep track of the location changes, which has so far been addressed by MIP.

The mSCTP, in the present form, is targeted for seamless handover of mobile session associated with the case (a). To support the session type of the case (b), the mSCTP must be used along with an additional location management scheme such as SIP or MIP.

In this section, we consider a mobile client (MC) that initiates an SCTP association with a fixed server (FS). After initiation of an SCTP association, the MC moves from Location A (Access Router A) to Location B (Access Router B), as shown in Figure B.1. The figure illustrates an example of the use of mobile SCTP for seamless handover in IPv6 networks. With this figure, we describe the detailed handover procedures in the subsequent sections.

Access Router A

Access Router B

IPv6 address 2

IPv6 address 3

Fixed Server (FS)IPv6 address 1

Overlap Region

Mobile Client (MC)

Internet

Mobile Client (MC)

Access Router A

Access Router B

IPv6 address 2

IPv6 address 3

Fixed Server (FS)IPv6 address 1

Overlap Region

Mobile Client (MC)

Internet

Mobile Client (MC)

<Figure B.1> mSCTP for Seamless Handover

1) Session initiation by Mobile Client (MC)

- 37 - TD 12 (WP3/13)

We assume that an MC initiates an SCTP association with an FS. The resulting SCTP association has the set of IPv6 addresses with IPv6 address 2 for MC and IPv6 address 1 for FS. It is also assumed that the MC gets an IPv6 address from Access Router (AR) A, with help of IPv6 stateless address auto-configuration or DHCPv6.

Note in this phase that the FS is in the single homing with IPv6 address 1. The MC is also single homing in the initial state, in which the IPv6 address 2 is set to its primary IPv6 address in the SCTP initiation process.

2) Obtaining an IPv6 address for a new location

Let us assume that the MC moves from AR A to AR B and thus it is now in the overlapping region. In this phase, we also need to assume that the MC can obtain a new IPv6 address 3 from the AR B by using DHCPv6 or IPv6 stateless address auto-configuration.

By SCTP implementations, the newly obtained IPv6 address 3 must be signalled or informed to the SCTP in the transport layer, and then the SCTP will bind the new IPv6 address to its address list managed by the SCTP association.

3) Adding the new IPv6 address to the SCTP association

After obtaining a new IPv6 address, the MC’s SCTP informs MC that it will use a new IPv6 address. This is done by sending SCTP Address Configuration (ASCONF) Chunk to the FS. The MC may receive the responding ASCONF-ACK Chunk from the FS.

The MC is now in the dual homing state. The old IPv6 address (IPv6 address 2) is still used as the primary address, until the new IPv6 address 3 will be set to be “Primary Address” by the MC. Before the primary address is newly set, IPv6 address 3 will be used as a backup path.

4) Changing the primary IPv6 address

While the MC further continues to move toward AR B, it needs to change the new IPv6 address into its primary IP address according at an appropriate rule. Actually, the configuration of a specific rule to trigger this “primary address change” is a challenging issue of the mSCTP.

Examples of the rules for triggering the primary IPv6 address change are described below:

(a) As soon as a new IPv6 address is detected

When a new IPv6 address is detected, the MC may trigger the primary IPv6 address change by sending the ASCONF Chunk containing the “Set Primary Address” parameter.

This choice is the simplest way to implement in SCTP. In fact, it is the only scheme to apply for Wireless LAN, since in WLAN the multi-homing is not support in the link layer (i.e., Access Points allow only one wireless channel at a time).

(b) By using a threshold for the data loss experienced

This rule can be applied when the SCTP of MC has a pre-configured threshold for data loss. For example, if the number of the lost data chunks is greater than the pre-configured threshold, then it may trigger the primary address change toward the FS. The selection of an

- 38 - TD 12 (WP3/13)

appropriate threshold value is for further study, and may depend on implementations and the mobility behaviour considered.

This scheme is preferred in the viewpoint that it can operate without support of the underlying network and link layers. However, it is required that SCTP implementation should be extended so as to handle the threshold scheme.

(c) By using an explicit indication from the underlying layer

If the underlying wireless link layer can detect and compare the signal strength of the physical media, and if it can also inform the SCTP about a certain indication (i.e., by using an up-call), then the MC may trigger the primary address change according to such an indication.

This rule is a more preferred choice, if possible, in terms of handover efficiency. It however depends on the capability of the underlying wireless systems.

If once the primary address is changed, the FS will send the incoming data over the new primary IP address, whereas the backup (old) address may be used to recover the lost data chunks.

5) Deleting the old IPv6 address from the SCTP association

As the MC progresses to move toward AR B, if the old IPv6 address gets inactive, the MC must delete it from the address list. The rule for determining if the IPv6 address is inactive may also be implemented by using additional information from the underlying network or physical layer.

6) Repeating the handover procedures

The procedural steps for seamless handover described above will be repeated whenever the MC moves to a new location, until the SCTP association will be released.

B.3 Considerations for mSCTP Handover

1) Requirement for mSCTP

The only requirement for providing the seamless handover based on SCTP is that the MC and FS hosts are equipped with the mSCTP implementations, (i.e., SCTP with ASCONF extension.)

2) Number of IP addresses used by Fixed Server

In this document, we assume that the FS is in the single homing, i.e. the FS and MC are in a 1-to-2 asymmetric multi-homing configuration. In a certain case, we may need to consider the multi-homed FS. It is noted that there are still many further issues on how to handle the mSCTP handover or which is better in the performance aspect for each of the single-homed and multi-homed FS cases.

3) Dynamic IP address configuration

- 39 - TD 12 (WP3/13)

The basic assumption for seamless handover to a new IP subnet region is that the MC is able to obtain a new IP address from the new location. Typically, this will be implemented by using the DHCPv6 or Stateless address auto-configuration in IPv6 networks.

The handover latency incurred for obtaining the new IP address via DHCPv6 or IPv6 needs to be examined by experiments. The concerned handover latency also includes the delay required for the handover delay between the wireless links.

4) AAA functionality

It is envisioned that the deployment of mSCTP will be done along with the appropriate AAA server in the respective access network domains. The AAA server is used to authenticate and the MC in the locations, and also to authorize the new IP address configuration via DHCPv6 and IPv6 stateless configuration.

5) Link layer support for multi-homing

To support the multi-homing capability for MC, we need to consider the characteristics of the wireless links such as WLAN and Cellular systems. It is noted that Cellular systems are expected to easily support the link-level multi-homing features, whereas the WLAN system case is for further study.

The multi-homing feature enables the mSCTP to support seamless handover by simultaneous binding of two different addresses while staying the overlapping region. Time interval for an MC to stay in the overlapping region will give impact on the performance of the handover procedures.

It is also noted that the handover based on mSCTP depends on the support of the underlying physical and link layers to measure the wireless signal strength. The measured signal strength information can helpfully used for the SCTP to trigger the addition and deletion of IP addresses, and the change of the primary address. The handover performance will depend on such capability in terms of data loss and delay during handover.

- 40 - TD 12 (WP3/13)

Appendix C. Multimedia Services Scenarios

Editor’s Note: This Appendix is purposed to give some examples of multimedia services scenarios that are helpful to identify the MM functional architecture. The texts and figures given below are subject to change, and some more examples can be added. Relevant Contributions are invited

Regarding the multimedia service architecture ITU-T Recommendation F.700 gives a generic model description. Hereby multimedia services are built up by combining “communication tasks” and organizing their interaction. A communication task is considered as a functional entity of a multimedia service, which performs its communication features. Each communication task handles a set of media components in a synchronized way, in order to convey and control information types such as audio or video. Media components are individual (monomedia) components, which handle functions related to each independent medium such as capture, coding and presentation. With regard to Communication tasks the ITU-T F.700 series mentions “conversing”, “conferencing”, “distributing”, “sending”, “receiving” and “collecting”. It shall be noted that this list of Communications tasks is not exhaustive but can be extended by new tasks or by the refinement of given tasks. On the level of media components “audio”, “video”, “text”, “graphics”, “Pictures “(pixel based) and “data” are identified.

<Figure C.1> Reference Model Generic Multimedia Service

Figure C.1 shows the relationship between multimedia service, communication task and media component.

The communication tasks and the media components form the basic set of communication capabilities from which a specific multimedia service can be built up. As an example for the multimedia conversational service Figure y shows the relationships between services, communication tasks and media components according to ITU-T Recommendation F.703.

- 41 - TD 12 (WP3/13)

<Figure C.2> Example of multimedia conversational service

According to the used media components multimedia conversational services can be further divided into

• Videophone service, with audio and moving pictures and optionally various types of data

• Voice and data services, with audio and various types of data

• Text telephony, with real time text, optionally combined with audio

• Total Conversation service, with moving pictures, real time text and audio

• Collaborative Document Handling Service (CDH), with real time text, data and possibly graphics (see also F.702)

In addition to the modular elements on the different levels control and processing functions are required to operate the service.

- 42 - TD 12 (WP3/13)

Appendix D. Network Architecture of VCC with MIH

Editor’s Note: This section may be addressed as a new work item in the MM group. The texts and figures need to be further revised. Relevant contributions are invited.

D.1 Network Architectures for VCC with and without Support of 802.21

[Editor Notes]: Q.SMF covers only aspects that are specific to mobility management in service stratum. More contributions are invited to describe the detailed information flows of VCC mechanisms with 802.21 support in service stratum. Also new work item is suggested to be developed to cover all specific VCC issue in the Next NGN GSI meeting. If then, VCC relevant material are subject to be removed.

D.1.1 Overview

VCC is a mechanism to perform handover of voice calls between circuit switched calls and the IMS packet switched domain. It complements mobility by supporting seamless handover between circuit switched and packet switched domains.

D.1.2 Network Architecture for VCC support without 802.21

Figures A.x-1 and A.x-2 show the VCC architecture in the network and the UE without support of 802.21.

- 43 - TD 12 (WP3/13)

Figure A.x-1 Network Architecture for VCC Support- without 802.21

Figure A.x-1 shows VCC architecture with a VCC Application Server, AAA, MIP HA, DHCP/DNS, and gateway elements in the Core Network or IMS platform. The CN and Common IMS platform have also connectivity to UMTS packet domain, WiMAX, and Wi-Fi packet access; and UMTS circuit switched domain. The accesses allow the multimodal UE with VCC capability to handoff between the packet and the circuit switched domains.

Figure A.x-2 Client Architecture with VCC Capability - without 802.21

Figure A.x-2 shows a UE with VCC client support, including W-CDMA Non-Access Stratum, IMS Framework, VCC handover policy, and WiMAX, Cellular 3GPP/3GPP2, and Wi-Fi interfaces.

A.x.3 Network Architecture for VCC with support of 802.21

Voice Call Continuity may be enhanced and improved by using 802.21. One possible scenario is to include the 802.21 as an Application Server (AS) in the IMS platform, as already proposed in this recommendation. However, the combination of the VCC and the 802.21 as Application Servers on top of the IMS infrastructure is not mandatory.

VCC supports handovers based on specific non-standard solutions, 3GPP does not specify a specific mechanism to trigger handover, see 3GPP TS 23.206, “Voice Call Continuity between Circuit

- 44 - TD 12 (WP3/13)

Switched and IP Multimedia Subsystem”. Thus, radio monitoring and controlling are implementation dependent. If 802.21 supports VCC, the standardized 802.21 events and commands are used to monitor radio conditions and to control the interfaces. The Media Independent Handover Function (MIHF) provides then a list of available packet switched access modes and event reporting to the MIH Application Server.

Additionally, without 802.21 support for VCC, the handover is mobile controlled and therefore the decision to perform handover is left to local policy in the UE. On the other hand, if 802.21 supports VCC, the handovers may be controlled by the MIH Application Server in the network, therefore enforcing operators’ policies.

Figures A.x-3, A.x-4, and A.x-5 show the logical reference model, the network architecture, and the client architecture respectively for VCC with support of 802.21.

Figure A.x-3 Logical Reference Model for VCC supported by 802.21

- 45 - TD 12 (WP3/13)

Figure A.x-4 Network Architecture for VCC Support - with 802.21

- 46 - TD 12 (WP3/13)

Figure A.x-5 Client Architecture with VCC Capability - with 802.21

- 47 - TD 12 (WP3/13)

Appendix E. Bibliography The following references are useful to understand this Recommendation:

Editor’s Note: Some more informative references will be added (e.g., IETF RFCs). Relevant Contributions are invited.

[1] ITU-T Technical Report on Service Mobility for Multimedia Service Architecture (1.0), Working Draft, TD 551 (GEN/19), TD 407 (WP 2/13)

[2] 3GPP TS 29.198-06 V5.2.0 Open Service Access (OSA) Application Program Interface (API); Part I; Overview

[3] 3GPP TS 23.198 version 6.0.0 Release 6 Open Service Access (OSA) Stage 2

[4] 3GPP TS 29.198-15 V6.2.0 Release 6 Open Service Access (OSA); Application Programming Interface (API); Part 15: Multi-media Messaging (MM) Service Capability Feature (SCF)

[5] ITU-T F.700; Framework Recommendation for multimedia services; 11/2000

[6] ITU-T F.702; Multimedia conference services;

[7] ITU-T F.703; Multimedia conversational services; 11/2000

[8] ITU-T FG NGN TR-TERM - Terminological Framework for NGN

[9] ITU-T H.501 Protocol for mobility management and intra/inter-domain communication in multimedia systems

[10] ITU-T H.510 Mobility for H.323 multimedia systems and services

[11] IETF RFC 3261, Session Initiation Protocol [12] ETSI TS 123 228 V6.11.0, IP Multimedia Subsystem (IMS), Stage 2

Documents

INTERNATIONAL TELECOMMUNICATION UNION STUDY ... · Member States of ITU, by ITU-T Sector Members and Associates, and their respective staff and collaborators in their ITU related