idnits 2.17.1 draft-ietf-seamoby-mobility-terminology-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2460 (ref. '3') (Obsoleted by RFC 8200) -- No information found for draft-ietf-mobileip-fast-mipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. '5') == Outdated reference: A later version (-03) exists of draft-kempf-cdma-appl-00 -- Possible downref: Normative reference to a draft: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 3374 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-cardiscovery-issues (ref. '10') == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-21 ** Obsolete normative reference: RFC 3344 (ref. '12') (Obsoleted by RFC 5944) == Outdated reference: A later version (-05) exists of draft-ietf-mobileip-rfc3012bis-04 == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-aaa-key-11 -- Possible downref: Normative reference to a draft: ref. '14' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Manner (ed.) 3 Internet-Draft M. Kojo (ed.) 4 Expires: October, 2003 University of elsinki 5 April, 2003 7 Mobility Related Terminology 8 10 Status of this Memo 12 This document is a working group document of the Seamoby Working 13 Group. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire in October, 2003. 36 Copyright Notice 38 Copyright (C) The Internet Society (2000). All Rights Reserved. 40 Abstract 42 There is a need for common definitions of terminology in the work to 43 be done around IP mobility. This memo defines terms for mobility 44 related terminology. It is intended as a living document for use by 45 the Seamoby Working Group in Seamoby drafts and in WG discussions, 46 but not limited in scope to the terms needed by the Seamoby Working 47 Group. Other working groups dealing with mobility may take advantage 48 of this terminology. 50 Changes from -02 51 - Updated the terminology related to mobile networks 53 Changes from -01 54 - Added security terminology 55 - Miscellaneous small refinements of definitions 57 Changes from -00 58 - Added definition for Routing Proxy 59 - Added basic terminology about mobile networks 60 - Added Link-Layer Trigger from FMIPv6 61 - Edited the CAR terminology section 62 - Added definitions for MPR, CoA, BU 63 - Changed the definition of Home Address 64 - Added a mobile network into Figure 1 65 - Edited the Network Components section 67 Table of Contents 69 1 Introduction ................................................. 2 70 2 General Terms ................................................ 3 71 3 Mobile Access Networks and Mobile Networks ................... 8 72 4 Handover Terminology ......................................... 13 73 4.1 Scope of Handover .......................................... 14 74 4.2 Handover Control ........................................... 15 75 4.3 Simultaneous connectivity to Access Routers ................ 16 76 4.4 Performance and Functional Aspects ......................... 17 77 4.5 Micro Diversity, Macro Diversity, and IP Diversity ......... 18 78 4.6 Paging, and Mobile Node States and Modes ................... 18 79 4.7 Context Transfer ........................................... 20 80 4.8 Candidate Access Router Discovery .......................... 21 81 4.9 User, Personal and Host Mobility ........................... 21 82 5 Specific Terminology for Mobile Ad-Hoc Networking ............ 23 83 6 Security-related Terminology ................................. 24 84 7 Security Considerations ...................................... 25 85 8 Contributors ................................................. 25 86 9 Acknowledgement .............................................. 25 87 10 References .................................................. 26 88 11 Author's Addresses .......................................... 27 89 12 Appendix A - Examples ....................................... 29 90 13 Appendix B - Index of Terms ................................. 31 92 1. Introduction 94 This document presents terminology to be used for documents and 95 discussions within the Seamoby Working Group. Other mobility related 96 working groups could like take advantage of this terminology, in 97 order to create a common terminology for the area of mobility in IP 98 networks. These groups would include MIP, MANET, ROHC and NEMO. 100 Some terms and their definitions that are not directly related to the 101 IP world are included for the purpose of harmonizing the terminology, 102 for example, 'Access Point' and 'base station' refer to the same 103 component, from the point of view of IP, but 'Access Router' has a 104 very different meaning. The presented terminology may also, it is 105 hoped, be adequate to cover mobile ad-hoc networks. 107 The proposed terminology is not meant to assert any new terminology. 108 Rather the authors would welcome discussion on more exact definitions 109 as well as missing or unnecessary terms. This work is a 110 collaborative enterprise between people from many different 111 engineering backgrounds and so already presents a first step in 112 harmonizing the terminology. 114 The terminology in this draft is divided into several sections. 115 First, there is a list of terms for general use and mobile access 116 networks followed by terms related to handovers, and finally some 117 terms used within the MANET and NEMO working group. 119 2. General Terms 121 Bandwidth 123 The total capacity of a link to carry information (typically 124 bits). 126 Bandwidth Utilization 128 The actual amount of information delivered over a link, expressed 129 as a percent of the available bandwidth on that link. 131 Beacon 133 A control message broadcast by a node (especially, a base 134 station) informing all the other nodes in its neighborhood of the 135 continuing presence of the broadcasting node, possibly along with 136 additional status or configuration information. 138 Binding update (BU) 140 A message indicating a mobile node's current mobility binding, 141 and in particular its care-of address. 143 Care-of Address (CoA) 145 An IP address associated with a mobile node while visiting a 146 foreign link; the subnet prefix of this IP address is a foreign 147 subnet prefix. Among the multiple care-of addresses that a 148 mobile node may have at any given time (e.g., with different 149 subnet prefixes), the one registered with the mobile node's home 150 agent is called its "primary" care-of address [11]. 152 Channel 154 A subdivision of the physical medium allowing possibly shared 155 independent uses of the medium. Channels may be made available 156 by subdividing the medium into distinct time slots, or distinct 157 spectral bands, or decorrelated coding sequences. 159 Channel Access Protocol 161 A protocol for mediating access to, and possibly allocation of, 162 the various channels available within the physical communications 163 medium. Nodes participating in the channel access protocol can 164 communicate only when they have uncontested access to the medium, 165 so that there will be no interference. 167 Control Message 169 Information passed between two or more network nodes for 170 maintaining protocol state, which may be unrelated to any 171 specific application. 173 Distance Vector 175 A style of routing protocol in which, for each desired 176 destination, a node maintains information about the distance to 177 that destination, and a vector (next hop) towards that 178 destination. 180 Fairness 182 A property of channel access protocols whereby a medium is made 183 fairly equal to all eligible nodes on the link. Fairness does 184 not strictly imply equality, especially in cases where nodes are 185 given link access according to unequal priority or 186 classification. 188 Flooding 190 The process of delivering data or control messages to every node 191 within the network under consideration. 193 Foreign subnet prefix 195 A bit string that consists of some number of initial bits of an 196 IP address which identifies a node's foreign link within the 197 Internet topology. 199 Forwarding node 201 A node which performs the function of forwarding datagrams from 202 one of its neighbors to another. 204 Home Address 206 An IP address assigned to a mobile node, used as the permanent 207 address of the mobile node. This address is within the mobile 208 node's home link. Standard IP routing mechanisms will deliver 209 packets destined for a mobile node's home address to its home 210 link [11]. 212 Home subnet prefix 214 A bit string that consists of some number of initial bits of an 215 IP address which identifies a node's home link within the 216 Internet topology (i.e. the IP subnet prefix corresponding to the 217 mobile node's home address, as defined in [11]). 219 Interface 221 A node's attachment to a link. 223 IP access address 224 An IP address (often dynamically allocated) which a node uses to 225 designate its current point of attachment to the local network. 226 The IP access address is typically to be distinguished from the 227 mobile node's home address; in fact, while visiting a foreign 228 network the former may be considered unsuitable for use as an 229 end-point address by any but the most short-lived applications. 230 Instead, the IP access address is typically used as the care-of 231 address of the node. 233 Link 235 A communication facility or physical medium that can sustain data 236 communications between multiple network nodes, such as an 237 Ethernet (simple or bridged). A link is the layer immediately 238 below IP. 240 Asymmetric Link 242 A link with transmission characteristics which are different 243 depending upon the relative position or design characteristics of 244 the transmitter and the receiver of data on the link. For 245 instance, the range of one transmitter may be much higher than 246 the range of another transmitter on the same medium. 248 Link Establishment 250 The process of establishing a link between the mobile node and 251 the local network. This may involve allocating a channel, or 252 other local wireless resources, possibly including a minimum 253 level of service or bandwidth. 255 Link-layer Trigger (L2 Trigger) 257 Information from L2 that informs L3 of the detailed events 258 involved in handover sequencing at L2. L2 triggers are not 259 specific to any particular L2, but rather represent 260 generalizations of L2 information available from a wide variety 261 of L2 protocols [4]. 263 Link State 264 A style of routing protocol in which every node within the 265 network is expected to maintain information about every link 266 within the network topology. 268 Link-level Acknowledgement 270 A protocol strategy, typically employed over wireless media, 271 requiring neighbors to acknowledge receipt of packets (typically 272 unicast only) from the transmitter. Such strategies aim to avoid 273 packet loss or delay resulting from lack of, or unwanted 274 characteristics of, higher level protocols. 276 Link-layer acknowledgements are often used as part of ARQ 277 algorithms for increasing link reliability. 279 Local Broadcast 281 The delivery of data to every node within range of the 282 transmitter. 284 Loop-free 286 A property of routing protocols whereby the path taken by a data 287 packet from source to destination never transits the same 288 intermediate node twice before arrival at the destination. 290 Medium-Access Protocol (MAC) 292 A protocol for mediating access to, and possibly allocation of, 293 the physical communications medium. Nodes participating in the 294 medium access protocol can communicate only when they have 295 uncontested access to the medium, so that there will be no 296 interference. When the physical medium is a radio channel, the 297 MAC is the same as the Channel Access Protocol. 299 Mobile Network Prefix 301 A bit string that consists of some number of initial bits of an 302 IP address which identifies the entire mobile network within the 303 Internet topology. All nodes in a mobile network necessarily have 304 an address named after this prefix. 306 Mobility Factor 308 The relative frequency of node movement, compared to the 309 frequency of application initiation. 311 Multipoint relay (MPR) 313 A node which is selected by its one-hop neighbor to re-transmit 314 all broadcast messages that it receives. The message must be new 315 and the time-to-live field of the message must be greater than 316 one. Multipoint relaying is a technique to reduce the number of 317 redundant re-transmissions while diffusing a broadcast message in 318 the network. 320 Neighbor 322 A "neighbor" is any other node to which data may be propagated 323 directly over the communications medium without relying the 324 assistance of any other forwarding node 326 Neighborhood 328 All the nodes which can receive data on the same link from one 329 node whenever it transmits data. 331 Next Hop 333 A neighbor which has been selected to forward packets along the 334 way to a particular destination. 336 Payload 338 The actual data within a packet, not including network protocol 339 headers which were not inserted by an application. Note, that 340 payloads are different between layers: user data is the payload 341 of TCP, which are the payload of IP, which three are the payload 342 of link layer protocols etc. Thus, it is important to identify 343 the scope when talking about payloads. 345 Prefix 347 A bit string that consists of some number of initial bits of an 348 address. 350 Route Table 352 The table where forwarding nodes keep information (including next 353 hop) for various destinations. 355 Route Entry 357 An entry for a specific destination (unicast or multicast) in the 358 route table. 360 Route Establishment 362 The process of determining a route between a source and a 363 destination. 365 Route Activation 367 The process of putting a route into use after it has been 368 determined. 370 Routing Proxy 371 A node that routes packets by overlays, eg. by tunneling, between 372 communicating partners. The Home Agent and Foreign Agent are 373 examples of routing proxies, in that they receive packets 374 destined for the mobile node and tunnel them to the current 375 address of the mobile node. 377 Signal Strength 379 The detectable power of the signal carrying the data bits, as 380 seen by the receiver of the signal. 382 Source Route 384 A source route from node A to node B is an ordered list of IP 385 addresses, starting with the IP address of node A and ending with 386 the IP address of the node B. Between A and B, the source route 387 includes an ordered list of all the intermediate hops between A 388 and B, as well as the interface index of the interface through 389 which the packet should be transmitted to reach the next hop. 391 Spatial re-use 393 Simultaneous use of channels with identical or close physical 394 characteristics, but located spatially far enough apart to avoid 395 interference (i.e., co-channel interference) 397 System-wide Broadcast 399 Same as flooding, but used in contrast to local broadcast. 401 Topology 403 A network can be viewed abstractly as a "graph" whose "topology" 404 at any point in time is defined by set of "points" connected by 405 (possibly directed) "edges." 407 Triggered Update 409 An unsolicited route update transmitted by an router along a path 410 to a destination. 412 3. Mobile Access Networks and Mobile Networks 414 In order to support host mobility a set of nodes towards the network 415 edge may need to have specific functions. Such a set of nodes form a 416 mobile access network that may or may not be part of the global 417 Internet. The Figure 1 presents two examples of such access network 418 topologies. The figure depicts a reference architecture which 419 illustrates an IP network with components defined in this section. 421 We intend to define the concept of the Access Network (AN) which may 422 also support enhanced mobility. It is possible that to support 423 routing and QoS for mobile nodes, existing routing protocols (i.e., 424 OSPF or other standard IGPs) may not be appropriate to maintain 425 forwarding information for these mobile nodes as they change their 426 points of attachment to the Access Network. These new functions are 427 implemented in routers with additional capability. We can distinguish 428 three types of Access Network components: Access Routers (AR) which 429 handle the last hop to the mobile, typically over a wireless link; 430 Access Network Gateways (ANG) which form the boundary on the fixed 431 network side and shield the fixed network from the specialized 432 routing protocols; and (optionally) other internal Access Network 433 Routers which may also be needed in some cases to support the 434 protocols. The Access Network consists of the equipment needed to 435 support this specialized routing, i.e. AR/ANG/ANR. AR and ANG may be 436 the same physical nodes. 438 In addition, we present a few basic terms on mobile networks, that 439 is, mobile network, mobile router (MR), and mobile network node 440 (MNN). A more thorough discussion on mobile networks can be found in 441 the working group documents of the NEMO Working Group. 443 Note: this reference architecture is not well suited for people 444 dealing with MANETs. 446 --- ------ ------- | 447 --- | <--> | | -------| AR | -------------------| | | 448 | |--[] --- /------ \ /| ANG |--| 449 --- AP / \ / | | | 450 MH / \ / ------- | 451 (+wireless ___ / ------- | 452 device) | |---- | ANR | | 453 --- ------- | 454 AP / \ | 455 / \ ------- | 456 --- ------ / \| | | 457 | |-------| AR |---------------------| ANG |--| 458 --- ------ | | | 459 AP ------- | 460 | 461 Access Network (AN) 1 | 462 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| 463 Access Network (AN) 2 | 464 | 465 | 466 --- ------ ------- | 467 --- | <--> | | -------| AR | -------------------| | | 468 | |--[] --- /------ /| ANG |--| 469 --- AP / / | | | 470 MH / / ------- | 471 (+wireless ___ / / | 472 device) | |---- / | 473 --- / | 474 AP / | 475 / | 476 | ------ --- ------ ------- | 477 --- |- i MR e <->| |-------| AR |---------| ANR | | 478 | |--| ------ --- \ ------ ------- | 479 --- | AP \ / | 480 MNN | \ / | 481 | --- \ ------ / | 482 --- | | |-------| AR |------- | 483 | |--| --- ------ | 484 --- | AP | 485 MNN 'i': MR ingress interface 486 'e': MR egress interface 488 Figure 1: Reference Network Architecture 490 Mobile Node (MN) 492 An IP node capable of changing its point of attachment to the 493 network. A Mobile Node may or may not have forwarding 494 functionality. 496 Mobile Host (MH) 498 A mobile node that is an end host and not a router. A Mobile host 499 is capable of sending and receiving packets, that is, being a 500 source or destination of traffic, but not a forwarder of it. 502 Fixed Node (FN) 504 A node, either a host or a router, unable to change its point of 505 attachment to the network and its IP address without breaking 506 open sessions. 508 Mobile Network 510 An entire network, moving as a unit, which dynamically changes 511 its point of attachment to the Internet and thus its reachability 512 in the topology. The mobile network is composed by one or more 513 IP-subnets and is connected to the global Internet via one or 514 more Mobile Routers (MR). The internal configuration of the 515 mobile network is assumed to be relatively stable with respect to 516 the MR. 518 Mobile Router (MR) 520 A router capable of changing its point of attachment to the 521 network, moving from one link to another link. The MR is capable 522 of forwarding packets between two or more interfaces, and 523 possibly running a dynamic routing protocol modifying the state 524 by which to do packet forwarding. 526 The interface of a MR attached to a link inside the mobile 527 network is called the ingress interface. The interface of a MR 528 attached to the home link if the MR is at home, or attached to a 529 foreign link if the MR is in a foreign network is called the 530 egress interface. 532 A MR acting as a gateway between an entire mobile network and the 533 rest of the Internet has one or more egress interface(s) and one 534 or more ingress interface(s). Packets forwarded upstream to the 535 rest of the Internet are transmitted through one of the MR's 536 egress interface; packets forwarded downstream to the mobile 537 network are transmitted through one of the MR's ingress 538 interface. 540 Mobile Network Node (MNN) 542 Any node (host or router) located within a mobile network, either 543 permanently or temporarily. A Mobile Network Node may either be a 544 mobile node or a fixed node. 546 Access Link (AL) 548 A last-hop link between a Mobile Node and an Access Router. That 549 is, a facility or medium over which an Access Point and the 550 Mobile Node can communicate at the link layer, i.e., the layer 551 immediately below IP. 553 Access Point (AP) 555 An Access Point is a layer 2 device which is connected to one or 556 more Access Routers and offers the wireless link connection to 557 the Mobile Node. Access Points are sometimes called base 558 stations or access point transceivers. An Access Point may be a 559 separate entity or co-located with an Access Router. 561 Radio Cell 563 The geographical area within which an Access Point provides radio 564 coverage, i.e. where radio communication between a Mobile Node 565 and the specific Access Point is possible. 567 Access Network Router (ANR) 569 An IP router in the Access Network. An Access Network Router may 570 include Access Network specific functionalities, for example, 571 related to mobility and/or QoS. This is to distinguish between 572 ordinary routers and routers that have Access Network-related 573 special functionality. 575 Access Router (AR) 577 An Access Network Router residing on the edge of an Access 578 Network and connected to one or more Access Points. The Access 579 Points may be of different technology. An Access Router offers 580 IP connectivity to Mobile Nodes, acting as a default router to 581 the Mobile Nodes it is currently serving. The Access Router may 582 include intelligence beyond a simple forwarding service offered 583 by ordinary IP routers. 585 Access Network Gateway (ANG) 587 An Access Network Router that separates an Access Network from 588 other IP networks, much in the same way as an ordinary gateway 589 router. The Access Network Gateway looks to the other IP networks 590 like a standard IP router. 592 Access Network (AN) 594 An IP network which includes one or more Access Network Routers. 596 Administrative Domain (AD) 598 A collection of networks under the same administrative control 599 and grouped together for administrative purposes [5]. 601 Serving Access Router (SAR) 603 The Access Router currently offering the connectivity to the 604 Mobile Host. This is usually the point of departure for the 605 Mobile Node as it makes its way towards a new Access Router (then 606 Serving Access Router takes the role of the Old Access Router). 608 There may be several Serving Access Routers serving the Mobile 609 Node at the same time. 611 Old Access Router (OAR) 613 An Access Router that offered connectivity to the Mobile Node 614 prior to a handover. This is the Serving Access Router that will 615 cease or has ceased to offer connectivity to the Mobile Node. 617 New Access Router (NAR) 619 The Access Router that offers connectivity to the Mobile Node 620 after a handover. 622 Previous Access Router (PAR) 624 An Access Router that offered connectivity to the Mobile Node 625 prior to a handover. This is the Serving Access Router that will 626 cease or has ceased to offer connectivity to the Mobile Node. 627 Same as OAR. 629 Candidate Access Router (CAR) 631 An Access Router to which the Mobile Node may do a handoff. 633 4. Handover Terminology 635 These terms refer to different perspectives and approaches to 636 supporting different aspects of mobility. Distinctions can be made 637 according to the scope, range overlap, performance characteristics, 638 diversity characteristics, state transitions, mobility types, and 639 control modes of handover techniques. 641 Roaming 643 An operator-based term involving formal agreements between 644 operators that allows a mobile to get connectivity from a foreign 645 network. Roaming (a particular aspect of user mobility) 646 includes, for example, the functionality by which users can 647 communicate their identity to the local AN so that inter-AN 648 agreements can be activated and service and applications in the 649 MN's home network can be made available to the user locally. 651 Handover 653 (also known as handoff) the process by which an active MN (in the 654 Active State, see section 4.6) changes its point of attachment to 655 the network, or when such a change is attempted. The access 656 network may provide features to minimize the interruption to 657 sessions in progress. 659 There are different types of handover classified according to 660 different aspects involved in the handover. Some of this 661 terminology follows the description of [4]. 663 4.1. Scope of Handover 665 Note: the definitions of horizontal and vertical handover are 666 different than the ones commonly used today. These definitions try to 667 look at the handover from the IP layer's point of view; the IP layer 668 works with network interfaces, rather than specific technologies used 669 by those interfaces. 671 Layer 2 Handover 673 When a MN changes APs (or some other aspect of the radio channel) 674 connected to the same AR's interface then a layer 2 handover 675 occurs. This type of handover is transparent to the routing at 676 the IP layer (or it appears simply as a link layer 677 reconfiguration without any mobility implications). 679 Intra-AR Handover 681 A handover which changes the AR's network interface to the 682 mobile. That is, the Serving AR remains the same but routing 683 changes internal to the AR take place. 685 Intra-AN Handover 687 When the MN changes ARs inside the same AN then this handover 688 occurs. Such a handover is not necessarily visible outside the 689 AN. In case the ANG serving the MN changes, this handover is seen 690 outside the AN due to a change in the routing paths. Note that 691 the ANG may change for only some of the MN's data flows. 693 Inter-AN Handover 695 When the MN moves to a new AN then this handover occurs. This 696 requires some sort of host mobility across ANs, which typically 697 is be provided by the external IP core. Note that this would 698 have to involve the assignment of a new IP access address (e.g., 699 a new care-of address [9]) to the MN. 701 Intra-technology Handover 703 A handover between equipment of the same technology. 705 Inter-technology Handover 707 A handover between equipment of different technologies. 709 Horizontal Handover 711 A handover in which the mobile node's network interface does not 712 change (from the IP point of view); the MN communicates with the 713 access router via the same network interface before and after the 714 handover. A horizontal handover is typically also an intra- 715 technology handover but it can be an inter-technology handover if 716 the MN can do a layer 2 handover between two different 717 technologies without changing the network interface seen by the 718 IP layer. 720 Vertical Handover 722 In a vertical handover the mobile node's network interface to the 723 access network changes. A vertical handover is typically an 724 inter-technology handover but it may also be an intra- technology 725 handover if the MN has several network interfaces of the same 726 type. That is, after the handover, the IP layer communicates with 727 the access network through a different network interface. 729 The different handover types defined in this section and in section 730 4.1 have no direct relationship. In particular, a MN can do an 731 intra-AN handover of any of the types defined above. 733 Note that the horizontal and vertical handovers are not tied to a 734 change in the link layer technology. They define whether, after a 735 handover, the IP packet flow goes through the same (horizontal 736 handover) or a different (vertical handover) network interface. 737 These two handovers do not define whether the AR changes as a result 738 of a handover. 740 4.2. Handover Control 742 A handover must be one of the following two types (a): 744 Mobile-initiated Handover 746 the MN is the one that makes the initial decision to initiate the 747 handover. 749 Network-initiated Handover 751 the network makes the initial decision to initiate the handover. 753 A handover is also one of the following two types (b): 755 Mobile-controlled Handover (MCHO) 757 the MN has the primary control over the handover process. 759 Network-controlled Handover (NCHO) 761 the network has the primary control over the handover process. 763 A handover may also be either of these three types (c): 765 Mobile-assisted handover 767 information and measurement from the MN are used by the AR to 768 decide on the execution of a handover. 770 Network-assisted handover 772 a handover where the AN collects information that can be used by 773 the MN in a handover decision. 775 Unassisted handover 777 a handover where no assistance is provided by the MN or the AR to 778 each other. 780 A handover is also one of the following two types (d): 782 Backward handover 784 a handover either initiated by the OAR, or where the MN initiates 785 a handover via the OAR. 787 Forward handover 789 a handover either initiated by the NAR, or where the MN initiates 790 a handover via the NAR. 792 The handover is also either proactive or reactive (e): 794 Planned handover 796 a proactive (expected) handover where some signalling can be done 797 in advance of the MN getting connected to the new AR, e.g. 798 building a temporary tunnel from the old AR to the new AR. 800 Unplanned handover 802 a reactive (unexpected) handover, where no signalling is done in 803 advance of the MN's move of the OAR to the new AR. 805 The five handover types (a-e) are mostly independent, and every 806 handover should be classiable according to each of these types. 808 4.3. Simultaneous connectivity to Access Routers 810 Make-before-break (MBB) 812 During a MBB handover the MN can communicate simultaneously with 813 the old and new AR. This should not be confused with "soft 814 handover" which relies on macro diversity. 816 Break-before-make (BBM) 817 During a BBM handover the MN cannot communicate simultaneously 818 with the old and the new AR. 820 4.4. Performance and Functional Aspects 822 Handover Latency 824 Handover latency is the time difference between when a MN is last 825 able to send and/or receive an IP packet by way of the OAR, until 826 when the MN is able to send and/or receive an IP packet through 827 the NAR. Adapted from [4]. 829 Smooth handover 831 A handover that aims primarily to minimize packet loss, with no 832 explicit concern for additional delays in packet forwarding. 834 Fast handover 836 A handover that aims primarily to minimize delay, with no 837 explicit interest in packet loss. 839 Seamless handover 841 A handover in which there is no change in service capability, 842 security, or quality. In practice, some degradation in service 843 is to be expected. The definition of a seamless handover in the 844 practical case should be that other protocols, applications, or 845 end users do not detect any change in service capability, 846 security or quality, which would have a bearing on their (normal) 847 operation. See [7] for more discussion on the topic. 849 Throughput 851 The amount of data from a source to a destination processed by 852 the protocol for which throughput is to be measured for instance, 853 IP, TCP, or the MAC protocol. The throughput differs between 854 protocol layers. 856 Goodput 858 The total bandwidth used, less the volume of control messages and 859 protocol overhead from the data packets. 861 Pathloss 863 A reduction in signal strength caused by traversing the physical 864 medium constituting the link. 866 Hidden-terminal problem 868 The problem whereby a transmitting node can fail in its attempt 869 to transmit data because of destructive interference which is 870 only detectable at the receiving node, not the transmitting node. 872 Exposed terminal problem 874 The problem whereby a transmitting node prevents another node 875 from transmitting although it could have safely transmitted to 876 anyone else but that node. 878 4.5. Micro Diversity, Macro Diversity, and IP Diversity 880 Certain air interfaces (e.g. UTRAN FDD mode) require or at least 881 support macro diversity combining. Essentially, this refers to the 882 fact that a single MN is able to send and receive over two 883 independent radio channels ('diversity branches') at the same time; 884 the information received over different branches is compared and that 885 from the better branch passed to the upper layers. This can be used 886 both to improve overall performance, and to provide a seamless type 887 of handover at layer 2, since a new branch can be added before the 888 old is deleted. See also [6]. 890 It is necessary to differentiate between combining/diversity that 891 occurs at the physical and radio link layers, where the relevant unit 892 of data is the radio frame, and that which occurs at layer 3, the 893 network layer, where what is considered is the IP packet itself. 895 In the following definitions micro- and macro diversity refer to 896 protocol layers below the network layer, and IP diversity refers to 897 the network layer. 899 Micro diversity 901 for example, two antennas on the same transmitter send the same 902 signal to a receiver over a slightly different path to overcome 903 fading. 905 Macro diversity 907 Duplicating or combining actions taking place over multiple APs, 908 possibly attached to different ARs. This may require support 909 from the network layer to move the radio frames between the base 910 stations and a central combining point. 912 IP diversity 914 the splitting and combining of packets at the IP level. 916 4.6. Paging, and Mobile Node States and Modes 918 Mobile systems may employ the use of MN states in order to operate 919 more efficiently without degrading the performance of the system. The 920 term 921 A MN is always in one of the following three states: 923 Active State 925 when the AN knows the MN's SAR and the MN can send and receive IP 926 packets. The AL may not be active, but the radio layer is able 927 to establish one without assistance from the network layer. The 928 MN has an IP address assigned. 930 Dormant State 932 A state in which the mobile restricts its ability to receive 933 normal IP traffic by reducing its monitoring of radio channels. 934 The AN knows the MH's Paging Area, but the MH has no SAR and so 935 packets cannot be delivered to the MH without the AN initiating 936 paging. 938 Time-slotted Dormant Mode 940 A dormant mode implementation in which the mobile alternates 941 between periods of not listening for any radio traffic and 942 listening for traffic. Time-slotted dormant mode 943 implementations are typically synchronized with the network so 944 the network can deliver traffic to the mobile during listening 945 periods. 947 Inactive State 949 the MH is in neither the Active nor Dormant State. The host is no 950 longer listening for any packets, not even periodically, and not 951 sending packets. The host may be in a powered off state, it may 952 have shut down all interfaces to drastically conserve power, or 953 it may be out of range of a radio access point. The MN does not 954 necessarily have an IP access address from the AN. 956 Note: in fact, as well as the MN being in one of these three states, 957 the AN also stores which state it believes the MN is in. Normally 958 these are consistent; the definitions above assume so. 960 Here are some additional definitions for paging, taking into account 961 the above state definitions. 963 Paging 965 a procedure initiated by the Access Network to move an Idle MN 966 into the Active State. As a result of paging, the MN establishes 967 a SAR and the IP routes are set up. 969 Location updating 971 a procedure initiated by the MN, by which it informs the AN that 972 it has moved into a new paging area. 974 Paging Area 976 A part of the Access Network, typically containing a number of 977 ARs/APs, which corresponds to some geographical area. The AN 978 keeps and updates a list of all the Idle MNs present in the area. 979 If the MN is within the radio coverage of the area it will be 980 able to receive paging messages sent within that Paging Area. 982 Paging Area Registrations 984 Signaling from a dormant mode mobile node to the network, by 985 which it establishes its presence in a new paging area. Paging 986 Area Registrations thus enable the network to maintain a rough 987 idea of where the mobile is located. 989 Paging Channel 991 A radio channel dedicated to signaling dormant mode mobiles for 992 paging purposes. By current practice, the protocol used on a 993 paging channel is usually dictated by the radio link protocol, 994 although some paging protocols have provision for carrying 995 arbitrary traffic (and thus could potentially be used to carry 996 IP). 998 Traffic Channel 1000 The radio channel on which IP traffic to an active mobile is 1001 typically sent. This channel is used by a mobile that is 1002 actively sending and receiving IP traffic, and is not 1003 continuously active in a dormant mode mobile. For some radio 1004 link protocols, this may be the only channel available. 1006 4.7. Context Transfer 1008 Context 1010 The information on the current state of a routing-related service 1011 required to re-establish the routing-related service on a new 1012 subnet without having to perform the entire protocol exchange 1013 with the mobile host from scratch. 1015 Feature context 1017 The collection of information representing the context for a 1018 given feature. The full context associated with a mobile host is 1019 the collection of one or more feature contexts. 1021 Context transfer 1023 The movement of context from one router or other network entity 1024 to another as a means of re-establishing routing related services 1025 on a new subnet or collection of subnets. 1027 Routing-related service 1029 A modification to the default routing treatment of packets to and 1030 from the mobile host. Initially establishing routing-related 1031 services usually requires a protocol exchange with the mobile 1032 host. An example of a routing-related service is header 1033 compression. The service may also be indirectly related to 1034 routing, for example, security. Security may not affect the 1035 forwarding decision of all intermediate routers, but a packet may 1036 be dropped if it fails a security check (can't be encrypted, 1037 authentication failed, etc.). Dropping the packet is basically a 1038 routing decision. 1040 4.8. Candidate Access Router Discovery 1042 Capability of AR 1044 A characteristic of the service offered by an AR that may be of 1045 interest to an MN when the AR is being considered as a handoff 1046 candidate. 1048 Candidate AR (CAR) 1050 An AR to which MN has a choice of performing IP-level handoff. 1051 This means that MN has the right radio interface to connect to an 1052 AP that is served by this AR, as well as the coverage of this AR 1053 overlaps with that of the AR to which MN is currently attached 1054 to. 1056 Target AR (TAR) 1058 An AR with which the procedures for the MN's IP-level handoff are 1059 initiated. TAR is selected after running a TAR Selection 1060 Algorithm that takes into account the capabilities of CARs, 1061 preferences of MN and any local policies. 1063 4.9. User, Personal and Host Mobility 1065 Different sorts of mobility management may be required of a mobile 1066 system. We can differentiate between user, personal and host 1067 mobility. 1069 User mobility 1071 refers to the ability of a user to access services from different 1072 physical hosts. This usually means, the user has an account on 1073 these different hosts or that a host does not restrict users from 1074 using the host to access services. 1076 Personal mobility 1078 complements user mobility with the ability to track the user's 1079 location and provide the user's current location to allow 1080 sessions to be initiated by and towards the user by anyone on any 1081 other network. Personal mobility is also concerned with enabling 1082 associated security, billing and service subscription 1083 authorization made between administrative domains. 1085 Host mobility 1087 refers to the function of allowing a mobile host to change its 1088 point of attachment to the network, without interrupting IP 1089 packet delivery to/from that host. There may be different sub- 1090 functions depending on what the current level of service is being 1091 provided; in particular, support for host mobility usually 1092 implies active and idle modes of operation, depending on whether 1093 the host has any current sessions or not. Access Network 1094 procedures are required to keep track of the current point of 1095 attachment of all the MNs or establish it at will. Accurate 1096 location and routing procedures are required in order to maintain 1097 the integrity of the communication. Host mobility is often 1098 called 'terminal mobility'. 1100 Two subcategories of "Host mobility" can be identified: 1102 Global mobility 1104 Same as Macro mobility. 1106 Local mobility 1108 Same as Micro mobility. 1110 Macro mobility 1112 Mobility over a large area. This includes mobility support and 1113 associated address registration procedures that are needed when a 1114 mobile host moves between IP domains. Inter-AN handovers 1115 typically involve macro-mobility protocols. Mobile-IP can be 1116 seen as a means to provide macro mobility. 1118 Micro mobility 1120 Mobility over a small area. Usually this means mobility within 1121 an IP domain with an emphasis on support for active mode using 1122 handover, although it may include idle mode procedures also. 1123 Micro-mobility protocols exploit the locality of movement by 1124 confining movement related changes and signalling to the access 1125 network. 1127 Network mobility 1129 Network mobility occurs when an entire network changes its point 1130 of attachment to the Internet and, thus, its reachability in the 1131 topology, which is referred to as a mobile network. 1133 Local Mobility Management 1135 Local Mobility Management (LMM) is a generic term for protocols 1136 dealing with IP mobility management confined within the access 1137 network. LMM messages itself are not routed outside the access 1138 network, although, a handover may trigger Mobile IP messages to 1139 be sent to correspondent nodes and home agents. 1141 5. Specific Terminology for Mobile Ad-Hoc Networking 1143 Cluster 1145 A group of nodes located within close physical proximity, 1146 typically all within range of one another, which can be grouped 1147 together for the purpose of limiting the production and 1148 propogation of routing information. 1150 Cluster head 1152 A cluster head is a node (often elected in the cluster formation 1153 process) that has complete knowledge about group membership and 1154 link state information in the cluster. Each cluster should have 1155 one and only one cluster head. 1157 Cluster member 1159 All nodes within a cluster EXCEPT the cluster head are called 1160 members of that cluster. 1162 Convergence 1164 The process of approaching a state of equilibrium in which all 1165 nodes in the network agree on a consistent collection of state 1166 about the topology of the network, and in which no further 1167 control messages are needed to establish the consistency of the 1168 network topology. 1170 Convergence time 1172 The time which is required for a network to reach convergence 1173 after an event (typically, the movement of a mobile node) which 1174 changes the network topology. 1176 Laydown 1178 The relative physical location of the nodes within the ad hoc 1179 network. 1181 Pathloss matrix 1183 A matrix of coefficients describing the pathloss between any two 1184 nodes in an ad hoc network. When the links are asymmetric, the 1185 matrix is also asymmetric. 1187 Scenario 1189 The tuple 1190 characterizing a class of ad hoc networks. 1192 6. Security-related Terminology 1194 This section includes terminology commonly used around mobile and 1195 wireless networking. Only a mobility-related subset of the entire 1196 security terminology is presented. 1198 Authorization-enabling extension 1200 An authentication which makes a (registration) message acceptable 1201 to the ultimate recipient of the registration message. An 1202 authorization-enabling extension must contain an SPI [12]. 1204 Mobility Security Association 1206 A collection of security contexts, between a pair of nodes, which 1207 may be applied to mobility-related protocol messages exchanged 1208 between them. In Mobile IP, each context indicates an 1209 authentication algorithm and mode, a secret (a shared key, or 1210 appropriate public/private key pair), and a style of replay 1211 protection in use. Mobility security associations may be stored 1212 separately from the node's IPsec Security Policy Database (SPD) 1213 [12]. 1215 Registration Key 1217 A key used as the basis of a Mobility Security Association 1218 between a mobile node and a foreign agent. A registration key is 1219 typically only used once or a very few times, and only for the 1220 purposes of verifying a small volume of Authentication data [14]. 1222 Security Context 1224 A security context between two routers defines the manner in 1225 which two routers choose to mutually authentication each other, 1226 and indicates an authentication algorithm and mode. 1228 Security Parameter Index (SPI) 1230 An index identifying a security context between a pair of routers 1231 among the contexts possible in the mobility security association. 1233 Stale challenge 1235 Any challenge that has been used by the mobile node in a 1236 Registration Request message and processed by the Foreign Agent 1237 by relaying or generating The Foreign Agent may not be able to 1238 keep records for all previously used challenges [13]. 1240 Unknown challenge 1242 Any challenge from a particular mobile node that the foreign 1243 agent has no record of having put either into one of its recent 1244 Agent Advertisements or into a registration reply message to that 1245 mobile node [13]. 1247 Unused challenge 1249 A challenge that has not been already accepted by the Foreign 1250 Agent challenge in a corresponding Registration Reply message -- 1251 i.e., a challenge that is neither unknown nor previously used 1252 [13]. 1254 The Mobile IPv6 specification includes more security terminology 1255 related to MIPv6 bindings [11]. 1257 7. Security Considerations 1259 This document presents only terminology. There are no security issues 1260 in this document. 1262 8. Contributors 1264 This draft was initially based on the work of 1266 o Tapio Suihko, VTT Information Technology, Finland 1267 o Phil Eardley and Dave Wisely, BT, UK 1268 o Robert Hancock, Siemens/Roke Manor Research, UK, 1269 o Nikos Georganopoulos, King's College London 1270 o Markku Kojo and Jukka Manner, University of Helsinki, Finland. 1272 Since revision -02 of the document draft-manner-seamoby-terms-02.txt, 1273 Charles Perkins has given as input terminology related to ad-hoc 1274 networks. 1276 Thierry Ernst has provided the terminology for discussing mobile 1277 networks. 1279 9. Acknowledgement 1281 This work has been partially performed in the framework of the IST 1282 project IST-2000-28584 MIND, which is partly funded by the European 1283 Union. The authors would like to acknowledge the help of their 1284 colleagues in preparing this document. 1286 Some definitions of terminology have been adapted from [1], [7], [3], 1287 [2], [4], [9], [10], [11] and [12]. 1289 10. References 1291 [1] D. Blair, A. Tweedly, M. Thomas, J. Trostle, and 1292 M. Ramalho. Realtime Mobile IPv6 Framework (work in 1293 progress). Internet Draft, Internet Engineering Task Force. 1294 draft-blair-rt-mobileipv6-seamoby-00.txt, November 2000. 1296 [2] P. Calhoun, G. Montenegro, and C. Perkins. Mobile IP 1297 Regionalized Tunnel Management (work in progress). Internet 1298 Draft, Internet Engineering Task Force, November 1998. 1300 [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1301 Specification. Request for Comments 2460, Internet Engineering 1302 Task Force, December 1998. 1304 [4] G. Dommety (ed.). Fast Handovers for Mobile IPv6 (work 1305 in progress). draft-ietf-mobileip-fast-mipv6-06.txt, 1306 March, 2003. 1308 [5] Yavatkar et al. A Framework for Policy-based Admission 1309 Control. Request for Comments 2753, Internet Engineering Task 1310 Force, January 2000. 1312 [6] J. Kempf, P. McCann, and P. Roberts. IP Mobility and the CDMA 1313 Radio Access Network: Applicability Statement for Soft Handoff 1314 (work in progress). Internet Draft, 1315 draft-kempf-cdma-appl-00.txt, July 2000. 1317 [7] J. Kempf (ed.). Problem Description: Reasons For Doing 1318 Context Transfers Between Nodes in an IP Access Network. 1319 RFC 3374, Internet Engineering Task Force, September, 2002. 1321 [8] R. Pandya. Emerging Mobile and Personal Communication Systems. 1322 IEEE Communications Magazine, 33:44--52, June 1995. 1324 [9] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, and 1325 L. Salgarelli. IP micro-mobility support using HAWAII (work in 1326 progress). Internet Draft, Internet Engineering Task Force, 1327 June 1999. 1329 [10] D. Trossen, G. Krishnamurthi, H. Chaskar, J. Kempf, "Issues in 1330 candidate access router discovery for seamless IP-level 1331 handoffs. Internet Draft (work in progress), 1332 draft-ietf-seamoby-cardiscovery-issues-04.txt, October 2002. 1334 [11] David B. Johnson, Charles E. Perkins, Jari Arkko, "Mobility 1335 Support in IPv6". Internet Draft, 1336 draft-ietf-mobileip-ipv6-21.txt (work in progress), February 1337 2003. 1339 [12] Charles Perkins (ed.), "IP Mobility Support for IPv4". Request 1340 for Comments 3344, August 2002. 1342 [13] Charles Perkins, Pat Calhoun, Jayshree Bharatia, "Mobile 1343 IPv4 Challenge/Response Extensions (revised)". Internet Draft, 1344 December, 2002 (draft-ietf-mobileip-rfc3012bis-04.txt). 1346 [14] Charles Perkins, Pat Calhoun, "AAA Registration Keys for Mobile 1347 IP". Internet Draft, March 2003, 1348 (draft-ietf-mobileip-aaa-key-11.txt). 1350 11. Author's Addresses 1352 Questions about this document may be directed to: 1354 Jukka Manner 1355 Department of Computer Science 1356 University of Helsinki 1357 P.O. Box 26 (Teollisuuskatu 23) 1358 FIN-00014 HELSINKI 1359 Finland 1361 Voice: +358-9-191-44210 1362 Fax: +358-9-191-44441 1363 E-Mail: jmanner@cs.helsinki.fi 1365 Markku Kojo 1366 Department of Computer Science 1367 University of Helsinki 1368 P.O. Box 26 (Teollisuuskatu 23) 1369 FIN-00014 HELSINKI 1370 Finland 1372 Voice: +358-9-191-44179 1373 Fax: +358-9-191-44441 1374 E-Mail: kojo@cs.helsinki.fi 1376 Charles E. Perkins 1377 Communications Systems Lab 1378 Nokia Research Center 1379 313 Fairchild Drive 1380 Mountain View, California 94043 1381 USA 1382 Phone: +1-650 625-2986 1383 E-Mail: charliep@iprg.nokia.com 1384 Fax: +1 650 625-2502 1386 Tapio Suihko 1387 VTT Information Technology 1388 P.O. Box 1203 1389 FIN-02044 VTT 1390 Finland 1392 Voice: +358-9-456-6078 1393 Fax: +358-9-456-7028 1394 E-Mail: tapio.suihko@vtt.fi 1395 Phil Eardley 1396 BTexaCT 1397 Adastral Park 1398 Martlesham 1399 Ipswich IP5 3RE 1400 United Kingdom 1402 Voice: +44-1473-645938 1403 Fax: +44-1473-646885 1404 E-Mail: philip.eardley@bt.com 1406 Dave Wisely 1407 BTexaCT 1408 Adastral Park 1409 Martlesham 1410 Ipswich IP5 3RE 1411 United Kingdom 1413 Voice: +44-1473-643848 1414 Fax: +44-1473-646885 1415 E-Mail: dave.wisely@bt.com 1417 Robert Hancock 1418 Roke Manor Research Ltd 1419 Romsey, Hants, SO51 0ZN 1420 United Kingdom 1422 Voice: +44-1794-833601 1423 Fax: +44-1794-833434 1424 E-Mail: robert.hancock@roke.co.uk 1426 Nikos Georganopoulos 1427 King's College London 1428 Strand 1429 London WC2R 2LS 1430 United Kingdom 1432 Voice: +44-20-78482889 1433 Fax: +44-20-78482664 1434 E-Mail: nikolaos.georganopoulos@kcl.ac.uk) 1436 12. Appendix A - Examples 1438 This appendix provides examples for the terminology presented. 1440 A.1. Mobility 1442 Host mobility is logically independent of user mobility, although in 1443 real networks, at least the address management functions are often 1444 required to initially attach the host to the network. In addition, 1445 if the network wishes to determine whether access is authorized (and 1446 if so, who to charge for it), then this may be tied to the identity 1447 of the user of the terminal. 1449 An example of user mobility would be a campus network, where a 1450 student can log into the campus network from several workstations and 1451 still retrieve files, emails, and other services automatically. 1453 Personal mobility support typically amounts to the maintenance and 1454 update of some sort of address mapping database, such as a SIP server 1455 or DNS server; it is also possible for the personal mobility support 1456 function to take a part in forwarding control messages between end 1457 user and correspondent rather than simply acting as a database. SIP 1458 is a protocol for session initiation in IP networks. It includes 1459 registration procedures which partially support personal mobility 1460 (namely, the ability for the network to route a session towards a 1461 user at a local IP address). 1463 Personal mobility has been defined in [8] as "the ability of end 1464 users to originate and receive calls and access subscribed 1465 telecommunication services on any terminal in any location, and the 1466 ability of the network to identify end users as they move. Personal 1467 mobility is based on the use of a unique personal identity (i.e., 1468 personal number)." 1470 Roaming, in its original (GSM) sense, is the ability of a user to 1471 connect to the networks owned by operators other than the one having 1472 a direct formal relationship with the user. More recently (e.g., in 1473 data networks and UMTS) it also refers providing user-customized 1474 services in foreign networks (e.g., QoS profiles for specific 1475 applications). 1477 HAWAII, Cellular IP, Regional Registration and EMA are examples of 1478 micro mobility schemes, with the assumption that Mobile IP is used 1479 for macro mobility. 1481 WLAN technologies such as IEEE 802.11 typically support aspects of 1482 user and host mobility in a minimal way. User mobility procedures 1483 (for access control and so on) are defined only over the air 1484 interface (and the way these are handled within the network is not 1485 further defined). 1487 PLMNs (GSM/UMTS) typically have extensive support for both user and 1488 host mobility. Complete sets of protocols (both over the air and on 1489 the network side) are provided for user mobility, including 1490 customized service provision. Handover for host mobility is also 1491 supported, both within access networks, and also within the GSM/UMTS 1492 core network for mobility between access networks of the same 1493 operator. 1495 A.2. Handovers 1497 A hard handover is required where a MN is not able to receive or send 1498 traffic from/to two APs simultaneously. In order to move the traffic 1499 channel from the old to the new access point the MN abruptly changes 1500 the frequency/timeslot/code on which it is transmitting and listening 1501 to new values associated with a new access point. Thus, the handover 1502 is a break-before-make handover. 1504 A good example of hard handover is GSM where the mobile listens for 1505 new base stations, reports back to the network the signal strength 1506 and identity of the new base station(s) heard. When the old base 1507 station decides that a handover is required it instructs the new base 1508 station to set up resources and, when confirmed, instructs the mobile 1509 to switch to a new frequency and time slot. This sort of hand over 1510 is called hard, mobile assisted, network initiated and backward 1511 (meaning that the old base station is responsible for handling the 1512 change-over). 1514 In a TDMA system, such as GSM, the hard hand over is delayed until 1515 the mobile has moved well within the coverage of the new base 1516 station. If the handover threshold was set to the point where the 1517 new base station signal exceeded the old then there would be a very 1518 large number of handovers as the mobile moved through the region 1519 between the cells and radio signals fluctuated, this would create a 1520 large signalling traffic. To avoid this a large hysteresis is set, 1521 i.e. the new base station must be (say) 10dB stronger for handover 1522 to occur. If the same was done in W-CDMA then the mobile would be 1523 transmitting a powerful signal to the old base station and creating 1524 interference for other users, since in CDMA everyone else's 1525 transmissions are seen as noise, thus reducing capacity. To avoid 1526 this soft handover is used, giving an estimated doubling in capacity. 1527 Support for soft handover (in a single mode terminal) is 1528 characteristic of radio interfaces which also require macro diversity 1529 for interference limitation but the two concepts are logically 1530 independent. 1532 A good example of soft handover is the UTRAN FDD mode. W-CDMA is 1533 particularly suited to soft handover because of the design of the 1534 receivers and transmitters: typically a rake receiver will be used 1535 to overcome the multi-path fading of the wide-band channel. Rake 1536 receivers have a number of so-called fingers, each effectively 1537 separate detectors, that are tuned to the same signal (e.g. 1538 spreading code) but delayed by different times. When the delay times 1539 are correctly adjusted and the various components properly combined 1540 (this is micro diversity combining) the effect of multi-path fading 1541 is removed. The rake receiver can also be used to detect signals 1542 from different transmitters by tuning the fingers to different 1543 spreading codes. Soft handover is used in UTRAN FDD mode to also 1544 increase capacity. 1546 Every handover can be seen as a context-aware Handover. In PLMNs the 1547 context to be fulfilled is that the new AP can accommodate the new 1548 mobile, for example, the new GSM cell can serve the incoming phone. 1549 Lately, the notion of Context-aware Handovers has been enlarged by, 1550 for example, QoS-aware handovers, meaning that the handover is 1551 governed by the need to support the QoS-context of the moving mobile 1552 in order to keep the service level assured to the user of the MN. 1554 A.3. Diversity combining 1556 In the case of UMTS it is radio frames that are duplicated at some 1557 point in the network (the serving RNC) and sent to a number of 1558 basestations and, possibly via other (drift) RNCs. The combining 1559 that takes place at the serving RNC in the uplink direction is 1560 typically based on some simple quality comparison of the various 1561 received frames, which implies that the various copies of these 1562 frames must contain identical upper layer information. The serving 1563 RNC also has to do buffering data frames to take account of the 1564 differing time of flight from each basestation to the RNC. 1566 A.4. Miscellaneous 1568 In a GPRS/UMTS system the Access Network Gateway node could be the 1569 GGSN component. The ANG can provide support for mobility of hosts, 1570 admission control, policy enforcement, and Foreign Agent 1571 functionality [9]. 1573 When presenting a mobile network topology, APs and ARs are usually 1574 pictured as separate components (see Figure 1. This is the case with 1575 GSM/GPRS/UMTS presentations, for example. From the IP point of view 1576 APs are not directly visible. An AP should only be seen from the 1577 MN's or AR's IP layer as a link (interface) connecting MNs to the AR. 1579 When the mobile moves through the network, depending on the mobility 1580 mechanism, the OAR will forward packets destined to the old MNs 1581 address to the SAR which currently serves the MN. At the same time 1582 the handover mechanism may be studying CARs to find the best NAR 1583 where the MN will be handed next. 1585 13. Appendix B - Index of Terms 1587 1589 Full Copyright Statement 1591 Copyright (C) The Internet Society (2001). All Rights Reserved. 1593 This document and translations of it may be copied and furnished to 1594 others, and derivative works that comment on or otherwise explain it 1595 or assist in its implementation may be prepared, copied, published 1596 and distributed, in whole or in part, without restriction of any 1597 kind, provided that the above copyright notice and this paragraph are 1598 included on all such copies and derivative works. However, this 1599 document itself may not be modified in any way, such as by removing 1600 the copyright notice or references to the Internet Society or other 1601 Internet organizations, except as needed for the purpose of 1602 developing Internet standards in which case the procedures for 1603 copyrights defined in the Internet Standards process must be 1604 followed, or as required to translate it into languages other than 1605 English. 1607 The limited permissions granted above are perpetual and will not be 1608 revoked by the Internet Society or its successors or assigns. 1610 This document and the information contained herein is provided on an 1611 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1612 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1613 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1614 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1615 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.