IETF Seamoby Working Group H.Y. Lach Internet Draft M. Catalyna Document: draft-lach-nac-00.txt Motorola Labs June 2003 Network Access Co-ordination to Complement IP Mobility Protocols Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." ! The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft addresses the need to complement the IP mobility protocols with respect to the co-ordination of a mobile node's network access. The concept of Network Access Agent (NAA) is introduced as a functional entity in the network to assist the mobile node's IP handoff strategy. The Network Access Co-ordination Protocol (NACP) is proposed as an interaction mechanism between the NAA and the mobile node, so that the NAA can provide valuable information and recommendations to the mobile node to consider in IP handoff. The NACP is conceived so that it is completely independent of the Mobile IP protocols. Table of Contents 1. Introduction 2. Terminology 2.1. General Terms 2.2. Specifi! c terms 3. Network access co-ordination 4. Overview of t he Network Access Co-ordination Protocol (NACP) 4.1. Service Contract Information Requests And Replies 4.2. Service Requests and Replies lach Expires December 2003 [Page 1] Internet Draft Network Access Co-ordination June 2003 to Complement IP Mobility Protocols 4.3. Quality Report Requests and Replies 4.4. Handover Required Notification 4.5. Candidate network selection 5. References 6. Acknowledgments 7. Author's Addresses 1. Introduction As a result of increasing popularity of wireless access networks such as cellular systems, wireless LANs (WLANs) and broadband wireless systems, it is envisaged that user systems will be increasingly mobile, changing their points of attachment to the network as they move. Mobile IP [MIP4] [MIP6] protocols specify how to maintain the connection of the mobile node to! internet as it changes topologically its point of attachment to the network. It is the mobile node that initiates the IP handoff. However, it is envisaged that the mobile node along cannot always make the best decision on when to make an IP handoff and to which available access network. One source of information to aid the mobile node to make intelligent network selection is from the network, represented by one or more Network Access Agents (NAAs). The NAA is assumed to be able to obtain relevant network information, depending on the system deployment, such as network load in the access networks, operator policies of network use, movement trajectory of the mobile node, etc. One could imagine that the NAA could be used by the network operator to ensure most cost-efficient use of network resources. This draft propose the Network Access Co-ordination Protocol (NACP) that allows the mobile node to interact with the NA! A to effectively co-ordinate the network access by the mobile node . The protocol is complementary to and independent of the Mobile IP protocols. Via this protocol, the mobile node will gain valuable recommendations from the NAA about the choice of access network to use. However, the mobile node is not obliged to follow solely the NAA's recommendation; it depends on the desired operational behaviour in the system deployment. 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. lach Expires December 2003 [Page 2] Internet Draft Network Access Co-ordination June 2003 to Complement IP Mobility Protocols 2.1. General Terms General terms are as defined in [TERM]. Those of particular importance in this document are recalled hereunder: Mobile Node (MN) An IP nod! e capable of changing its point of attachment to the network. 2.2. Specific Terms Network access co-ordination It refers to the co-ordination needed to determine a desired behaviour of network access by a mobile node. Such co-ordination is the function of the network access agent, which interacts with the mobile nodes under its scope of influence to recommend them the choice of access networks to use. Network Access Agent (NAA) It is the functional entity that co-ordinates the network access behaviours of the mobile nodes under its scope of influence. It could reside in any convenient node in the network infrastructure. Network Access Co-ordination Protocol (NACP) It is the protocol between a NAA and its MNs to achieve the network access co-ordination. 3. Network access co-ordination Mobile IP specifies a mechanism for a mobile node to initiate an IP handover. However, the process ! of network discovery and selection could best take advantage of the knowledge in the mobile node and the network. This allows different handover strategies to be adopted, taking into account of various desired criteria and policies. A mechanism is thus needed for the mobile node and the network to interact to jointly support selection, and re-selection, of the most appropriate access network for use by the terminal in a heterogeneous network. This document introduces a Network Access Agent (NAA) in the network. It is responsible for collectively managing the network access behaviours of the mobile nodes under its scope of influence. The mobile node and the NAA exchange information towards beneficially combining the terminal's "local view" (e.g. radio conditions in the area, services requested/received over the mobile node, etc.) and the lach Expires December 2003 [Page 3] Internet Draft Network Access Co-ordination June 2003 to! Complement IP Mobility Protocols "global view" of the network (e.g. traffic load over the various segments, the need to avoid congestion towards preserving QoS, etc). The desired MN-NAA interaction mechanism is expected to have the following technical requirements: * The mobile nodes are allowed to: o Notify the network about the candidate access networks in the area the terminal is in. o Report to the network status parameters relating to the quality with which services are received over the mobile node; status values at the radio-, IP-, and (for enhanced services) application-level may be reported. o Ask from the network the engagement of new or additional services (at specific QoS levels, when these are available). o Notify the network about service termination. * The network access agent is enabled to: o Advise a mobile node about the access networks that should be ! selected (among the candidates) in decreasing order of appro priateness (determined by network load and the services received over the terminal). A list of all alternative networks allows a terminal to switch to the next network in the list, should the previous choice become suddenly unavailable. o Ask from mobile nodes to send status reports (as described above) whenever required for assessing the conditions in specific radio segments. o Instruct mobile nodes to switch to a different access network (either to preserve QoS in individual terminals, or for the purpose of load balancing among different network segments). * The message protocol governing the interaction mechanism should not depend on the high-level IP means used for its implementation. In particular, the implementation should not assume that the order of messages sent from any communication end is preserved. Given the signalling nature of the protocol, low-overhead implementat! ions requiring few packet exchanges may be preferable, but should not imposed by the protocol's structure. * The message protocol should be independent of the specific radio access technologies integrated into the composite network. lach Expires December 2003 [Page 4] Internet Draft Network Access Co-ordination June 2003 to Complement IP Mobility Protocols As an example, this MN-NAA interaction mechanism could be used in a scenario in which: * The user of a terminal wants to engage a new service. The mobile node issues to NAA a request and the reply message indicates the access network that should be used (or deny the request). The mobile node switches to the indicated network. * Quality degradation is experienced at a mobile node. This is reported to NAA, which triggers an exchange of messages, so that the mobile node switches to a d! ifferent access network, overcoming the problems. * In order to overcome problems in some network segment, or for load balancing purposes, the NAA determines that some terminals should change the access network they currently use. NAA triggers an exchange of messages with each of these terminals that leads to the appropriate network re-selections. 4. Overview of the Network Access Co-ordination Protocol (NACP) The messages of the signalling protocol between mobile nodes and the Network Access Agent fall in the following categories: * Initial mobile node registration/initialisation to the heterogeneous network; * A core pair of messages (a Service Request/Reply pair) used from a mobile node (the request) when asking for new services and/or when reporting a change in the currently running services (e.g., a stopped service) or in the candidate access networks, and from the NAA when replying with the appropriate network to be selected. * Messages for reporting quality! status information from mobile nodes to the Network Access Agent. * A message from NAA to a MN for triggering a message exchange (a Service Request/Reply sequence) leading to reselection of the network segment used by the terminal. The messages of the protocol are further described by category in the following subsections. The final subsection illustrates the joint employment of protocol message exchanges and Mobile IP registration messages for effecting candidate network selection. lach Expires December 2003 [Page 5] Internet Draft Network Access Co-ordination June 2003 to Complement IP Mobility Protocols 4.1. Service Contract Information Requests And Replies The "initialisation" messages are a Service Contract Information Request/Reply pair. The terminal's TSMS uses the Service Contract Information Request at startup to acquire Service Contract I! nformation from the NSMS. The Service Contract specifies the set of services (and the specific QoS level(s) for each service) a user is registered to. The information for each such service is contained within a (so called) Service Definition. All messages in the protocol (both in this and other subsections) refer to a particular service/QoS combination in an abstract way, through encoding numbers called Service Identifiers (SID). This arrangement allows the incorporation of new services or additional QoS levels without affecting the structure of information fields in the messages of the protocol. Figure 1 shows an example of a Service Contract Information Request/Reply exchange. Network Mobile Access Node Agent ... ... | | 1. Service Contract | | Information Request |----------->| ! | | |<-----------| 2. Service Contract | | Information Reply | | (Service Def. SD1; | | Service Def. SD2; | | ...) | | ... ... Figure 1. Service Contract Information Request/Reply example When the mobile node is turned on and connects to the network for the first time, it sends a Service Contract Information Request (message 1) to acquire the Service Definitions for the Services the user has subscribed to. The NAA replies with the list of Service Definitions for the specific terminal/user (message 2). 4.2. Service Requests and Replies The Service Request/Reply pair of messages constitute the core of the protocol. ! In brief, the mobile node uses the Service Request to tell the Net work Access Agent its current configuration, that is, the list lach Expires December 2003 [Page 6] Internet Draft Network Access Co-ordination June 2003 to Complement IP Mobility Protocols of available networks at this moment, and the services that the user is running. Correspondingly, the NAA uses the Service Reply to tell the mobile node which network to choose and accept or deny the execution of the user services. During startup, after the Service Contract Information has been obtained, the mobile node sends a Service Request to the NAA with the list of available networks and the network it has chosen. It must also tell the NAA that no services are being run at this moment. The NAA notes that the indicated terminal is running and takes it into account in its calculations. It must tell the mobile node the network it should choose. This is indicated through! a list of preferred networks. The mobile node should switch to the first network on the list. If this fails for any reason, or the network becomes suddenly unavailable, the mobile node should switch to the next one on the list. When the user requests a service, the mobile node must send a new Service Request with the ID of the requested service. Every Service Request contains a list of the IDs of all the services currently running in the terminal. To notify that a service has stopped, the mobile node would simply send a Service Request in which the ID of the stopped service is not listed. Service Reply always contains a list with all the services that were present in the Service Request, and explicitly accepts or rejects each of them. If a service that had been accepted in a previous Service Request is now rejected, the mobile node must stop it. The NAA can use this to explicitly request the mobile node to stop a servic! e. lach Expires December 2003 [Page 7] Internet Draft Network Access Co-ordination June 2003 to Complement IP Mobility Protocols Figure 2 shows an example of Service Requests/Replies exchanges. Network Mobile Access Node Agent ... ... | | 1. Service Request | | (av. networks=GPRS(1), | | WLAN X(2), DVB-T(3); | | Services=none; | | Current network=1) |----------->| | | |<-----------| 2. Service Reply | | (Services=none; | | Pref. networks=2,1,3) | | ... ... ! Figure 2a. Service Request/Reply example: mobile node startup. Network Mobile Access Node Agent ... ... | | 3. Service Request | | (av. networks=GPRS(1), | | WLAN X(2), DVB-T(3); | | Services=video-hi; | | Current network=2) |----------->| | | |<-----------| 4. Service Reply | | (Services=(video-hi, | | accept); | | Pref. networks=3,2,1) | | ... ... Figure 2b. Service Request/Reply example: the mobile node requests a ! service. lach Expires December 2003 [Page 8] Internet Draft Network Access Co-ordination June 2003 to Complement IP Mobility Protocols Network Mobile Access Node Agent ... ... | | 5. Service Request | | (av. networks=GPRS(1), | | DVB-T(3); | | Services=video-hi; | | Current network=3) |----------->| | | |<-----------| 6. Service Reply | | (Services=(video-hi, | | accept); | | Pref. networks=3,1) | | ! ... ... Figure 2c. Service Request/Reply example: an access network becomes unavailable in the mobile node. In the first example, in Figure 2a, when the mobile node is turned on and connects to the network for the first time it sends a Service Request with its current configuration (message 1). The mobile node has detected a GPRS network, with ID 1, a WLAN network whose ESSID is X with ID 2 and a DVB-T network with ID 3. The user is not running any service and the current active network is GPRS (ID 1). The NAA replies with the preferred network list for the current network configuration (message 2). When the mobile node receives this message it must switch to the WLAN network with ESSID X (ID 2). The next example, in Figure 2b, shows the message exchange when the user requests a new service. The mobile node sends a Service Request with the service ID. The NAA accepts the service and selects the ! DVB-T network for it. The MN must switch to the DVB-T network when it receives the Service Reply. The Service Reply also tells the MN which network to use as the return path for unidirectional networks, such as the DVB-T network. Note that the application software running over the terminal will not start the new service until the confirmation from NAA has arrived. In messages 5 and 6, in Figure 2c, the MN notifies the NAA that the WLAN network X is no longer available. The NAA just replies to accept the new situation. lach Expires December 2003 [Page 9] Internet Draft Network Access Co-ordination June 2003 to Complement IP Mobility Protocols 4.3. Quality Report Requests and Replies In order to keep the service provision at a satisfactory quality level, the mobile node reports back to the Network Access Agent, whenever required. In emergency situations, such as overall network degradation, the NAA can request a report fro! m the MN, via the Quality Report Request message. The MN issues a corresponding report towards the NAA, providing measurements that reflect the quality level at which each service is provided to the particular terminal. This report is encapsulated in the appropriate Quality Report Reply message. The information that should be contained in such a Quality Report Reply message consists of a set of parameters monitored by the mobile node. Figure 3 displays an example of a Quality Report Request/Reply exchange. Network Mobile Access Node Agent ... ... | | | | 1. Quality Report Request |<-----------| | | 2. Quality Report Reply |----------->| ! (WLAN id=3, | | bit rate=5 Mbps, | | signal=150 dbm, | | noise=20 dbm) | | | | ... ... Figure 3. Quality Report Request/Reply example The NAA identifies a new environment condition (e.g. traffic load alteration) and requires information from some mobile nodes. In order to obtain this information, the NAA issues a Quality Report Request towards these MNs. Each of the addressed MNs provides the required information by forming a corresponding Quality Report Reply message. First the NAA decides the terminals from which quality of service related information should be required. A Quality Report Request is sent to each MN (message 1). When the terminal receives the request it sends a Quality Report Reply (message 2). lach Expires December 2003 [Page 10] Internet Draft Network Access Co-ordina! tion June 2003 to Complement IP Mobility Protocols 4.4. Handover Required Notification If the network conditions change, the NAA may decide to switch one or more users to a different network. The NAA must send a message to the MN to tell it the new network. With Service Request/Reply messages this can only be done in Service Replies, but Service Replies can only be sent on response to Service Requests, thus the NAA cannot send an unsolicited Service Reply to the MN to make it switch networks. And this is where the Handover Required Notification comes in. The protocol specifies that when the MN receives a Handover Required Notification it must send a Service Request. Thus, the NAA uses the Handover Required message to force a new Service Request/Reply cycle. Note that the Handover Required Notification itself does not inform the MN of the new network selection. This is done on the Service Reply.! Figure 4 shows how the Handover Required Notification works. Fir st the NAA detects that the terminal should be switched to a different network, so it sends a Handover Required Notification (message 1). When the terminal receives the notification it sends a Service Request (message 2). The corresponding Service Reply (message 3) from the NAA specifies the new network that the terminal should use. The MN must switch networks when it receives the reply. Network Mobile Access Node Agent ... ... | | |<-----------| 1. Handover Required 2. Service Request | | Notification (av. networks=GPRS(1), | | WLAN X(2), DVB-T(3); | | Services=video-hi; | | Current network=3) |----------->| | | ! |<-----------| 3. Service Reply | | (Services=(video-hi, | | accept); | | Pref. networks=2,3,1) | | ... ... Figure 4. Handover Required Notification example lach Expires December 2003 [Page 11] Internet Draft Network Access Co-ordination June 2003 to Complement IP Mobility Protocols It is envisaged that NSMS will periodically check if the network selection obtained from its optimisation algorithms and the current active network reported in the Service Request are different. In this case it sends a Handover Required Notification to force it to reconfigure. 4.5. Candidate network selection Figure 5 illustrates the joint employment of! protocol message exchanges and Mobile IP registration messages for effecting candidate network selection. In the figure's example, the terminal starts by using the GPRS network. At a later time, the user decides to start a new service; in reflection of this, the MN sends a Service Request message to the NAA, containing the list of available networks and the list of running services. The NAA sends a reply telling the MN to switch to the WLAN network. Once a candidate network has been selected, the MN starts the Mobile IP registration process with the home agent. When the Mobile IP registration completes, data is transferred over the selected network. Note that a stationary MN, that is, a MN that is not moving, uses the same mechanism to perform handover, since the IP addresses are assigned independently to the GPRS and WLAN interfaces. The notion of movement in the Mobile IP context refers just to a change of care-of address. Since the WLAN and GPRS interfaces always have different care-o! f addresses, a vertical handover is considered as movement from the Mobile IP point of view. lach Expires December 2003 [Page 12] Internet Draft Network Access Co-ordination June 2003 to Complement IP Mobility Protocols Home Correspondent Mobile Node Agent NAA Node GPRS WLAN | | | interface interface | | | | | | | | | /-------------------------------------------------\ | |< APPLICATION DATA >| | \-------------------------------------------------/ | | | | | | | | | | | | NACP Service Request | ! | | |---------------------------------- ---->| | | | | | | | NACP Service Reply | | | |<--------------------------------------| | | | | | | | | MIP Binding | | | | | Update | | | | |------------->| | | | | | | | | | MIP Binding | | | | | Ack. | | | | |<-------------| | | | | | | | | | /--------------------------------------\ | | |< APPLICATION DATA >| | | \--------------------------------------/ | ! | | | | | Figure 5. Protocol message exchange effecting Candidate Network Selection 5. References [MIP4] "IP Mobility Support for IPv4", C. Perkins (Editor), RFC 3344, August 2003. [MIP6] "Mobility Support in IPv6", D. Johnson, C. Perkins, and Jari Arkko, draft-ietf-mobileip-ipv6-21.txt, work in progress, February 2003. [TERM] "Mobility Related Terminology", J. Manner, M. Kojo, draft- ietf-seamoby-mobility-terminology-01.txt, work in progress, November 2002. lach Expires December 2003 [Page 13] Internet Draft Network Access Co-ordination June 2003 to Complement IP Mobility Protocols 6. Acknowledgments We would like to acknowledge the CREDO European project, in which This work is performed. 7. Author's Addresses Hong-Yon Lach Motorola Lab! s, Paris Parc Les Algorithmes - Saint Aubin 91193 Gif-sur-Yvette Cedex FRANCE Email: hong-yon.lach@motorola.com Miguel Catalina-Gallego Motorola Labs, Paris Parc Les Algorithmes - Saint Aubin 91193 Gif-sur-Yvette Cedex FRANCE Email: miguel.catalina@motorola.com lach Expires December 2003 [Page 14]