idnits 2.17.1 draft-ietf-seamoby-mobility-terminology-04.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.) 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) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '3') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. '12') (Obsoleted by RFC 5944) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 Helsinki 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 Table of Contents 52 1 Introduction ................................................. 2 53 2 General Terms ................................................ 3 54 3 Mobile Access Networks and Mobile Networks ................... 8 55 4 Handover Terminology ......................................... 12 56 4.1 Scope of Handover .......................................... 13 57 4.2 Handover Control ........................................... 14 58 4.3 Simultaneous connectivity to Access Routers ................ 16 59 4.4 Performance and Functional Aspects ......................... 16 60 4.5 Micro Diversity, Macro Diversity, and IP Diversity ......... 17 61 4.6 Paging, and Mobile Node States and Modes ................... 18 62 4.7 Context Transfer ........................................... 19 63 4.8 Candidate Access Router Discovery .......................... 20 64 4.9 User, Personal and Host Mobility ........................... 20 65 5 Specific Terminology for Mobile Ad-Hoc Networking ............ 22 66 6 Security-related Terminology ................................. 23 67 7 Security Considerations ...................................... 24 68 8 Contributors ................................................. 24 69 9 Change log ................................................... 25 70 10 Acknowledgement ............................................. 25 71 11 Informative References ...................................... 25 72 12 Author's Addresses .......................................... 26 73 13 Appendix A - Examples ....................................... 29 74 14 Appendix B - Index of Terms ................................. 31 76 1. Introduction 78 This document presents terminology to be used for documents and 79 discussions within the Seamoby Working Group. Other mobility related 80 working groups could take advantage of this terminology, in order to 81 create a common terminology for the area of mobility in IP networks. 82 These groups would include MIP, MANET, ROHC and NEMO. 84 Some terms and their definitions that are not directly related to the 85 IP world are included for the purpose of harmonizing the terminology. 86 For example, 'Access Point' and 'base station' refer to the same 87 component, from the point of view of IP, but 'Access Router' has a 88 very different meaning. The presented terminology may also, it is 89 hoped, be adequate to cover mobile ad-hoc networks. 91 The proposed terminology is not meant to assert any new terminology. 92 Rather the authors would welcome discussion on more exact definitions 93 as well as missing or unnecessary terms. This work is a 94 collaborative enterprise between people from many different 95 engineering backgrounds and so already presents a first step in 96 harmonizing the terminology. 98 The terminology in this draft is divided into several sections. 99 First, there is a list of terms for general use and mobile access 100 networks followed by terms related to handovers, and finally some 101 terms used within the MANET and NEMO working group. 103 2. General Terms 105 Bandwidth 107 The total capacity of a link to carry information (typically 108 bits) per unit time. 110 Bandwidth Utilization 112 The actual rate of information transfer achieved over a link, 113 expressed as a percent of the available bandwidth on that link. 115 Beacon 117 A control message broadcast by a node (especially, a base 118 station) informing all the other nodes in its neighborhood of the 119 continuing presence of the broadcasting node, possibly along with 120 additional status or configuration information. 122 Binding update (BU) 124 A message indicating a mobile node's current mobility binding, 125 and in particular its care-of address. 127 Care-of Address (CoA) 129 An IP address associated with a mobile node while visiting a 130 foreign link; the subnet prefix of this IP address is a foreign 131 subnet prefix. Among the multiple care-of addresses that a 132 mobile node may have at any given time (e.g., with different 133 subnet prefixes), the one registered with the mobile node's home 134 agent is called its "primary" care-of address [11]. 136 Channel 138 A subdivision of the physical medium allowing possibly shared 139 independent uses of the medium. Channels may be made available 140 by subdividing the medium into distinct time slots, or distinct 141 spectral bands, or decorrelated coding sequences. 143 Channel Access Protocol 145 A protocol for mediating access to, and possibly allocation of, 146 the various channels available within the physical communications 147 medium. Nodes participating in the channel access protocol agree 148 to communicate only when they have uncontested access to one of 149 the channels, so that there will be no interference. 151 Control Message 153 Information passed between two or more network nodes for 154 maintaining protocol state, which may be unrelated to any 155 specific application. 157 Distance Vector 159 A style of routing protocol in which, for each desired 160 destination, a node maintains information about the distance to 161 that destination, and a vector (next hop) towards that 162 destination. 164 Fairness 166 A property of channel access protocols whereby a medium is made 167 fairly available to all eligible nodes on the link. Fairness 168 does not strictly imply equality, especially in cases where nodes 169 are given link access according to unequal priority or 170 classification. 172 Flooding 174 The process of delivering data or control messages to every node 175 within the network under consideration. 177 Foreign subnet prefix 179 A bit string that consists of some number of initial bits of an 180 IP address which identifies a node's foreign link within the 181 Internet topology. 183 Forwarding node 185 A node which performs the function of forwarding datagrams from 186 one of its neighbors to another. 188 Home Address 190 An IP address assigned to a mobile node, used as the permanent 191 address of the mobile node. This address is within the mobile 192 node's home link. Standard IP routing mechanisms will deliver 193 packets destined for a mobile node's home address to its home 194 link [11]. 196 Home subnet prefix 198 A bit string that consists of some number of initial bits of an 199 IP address which identifies a node's home link within the 200 Internet topology (i.e. the IP subnet prefix corresponding to the 201 mobile node's home address, as defined in [11]). 203 Interface 205 A node's attachment to a link. 207 IP access address 208 An IP address (often dynamically allocated) which a node uses to 209 designate its current point of attachment to the local network. 210 The IP access address is typically to be distinguished from the 211 mobile node's home address; in fact, while visiting a foreign 212 network the former may be considered unsuitable for use as an 213 end-point address by any but the most short-lived applications. 214 Instead, the IP access address is typically used as the care-of 215 address of the node. 217 Link 219 A communication facility or physical medium that can sustain data 220 communications between multiple network nodes, such as an 221 Ethernet (simple or bridged). A link is the layer immediately 222 below IP. 224 Asymmetric Link 226 A link with transmission characteristics which are different 227 depending upon the relative position or design characteristics of 228 the transmitter and the receiver of data on the link. For 229 instance, the range of one transmitter may be much higher than 230 the range of another transmitter on the same medium. 232 Link Establishment 234 The process of establishing a link between the mobile node and 235 the local network. This may involve allocating a channel, or 236 other local wireless resources, possibly including a minimum 237 level of service or bandwidth. 239 Link-layer Trigger (L2 Trigger) 241 Information from L2 that informs L3 of the detailed events 242 involved in handover sequencing at L2. L2 triggers are not 243 specific to any particular L2, but rather represent 244 generalizations of L2 information available from a wide variety 245 of L2 protocols [4]. 247 Link State 249 A style of routing protocol in which every node within the 250 network is expected to maintain information about every link 251 within the network topology. 253 Link-level Acknowledgement 255 A protocol strategy, typically employed over wireless media, 256 requiring neighbors to acknowledge receipt of packets (typically 257 unicast only) from the transmitter. Such strategies aim to avoid 258 packet loss or delay resulting from lack of, or unwanted 259 characteristics of, higher level protocols. 261 Link-layer acknowledgements are often used as part of ARQ 262 algorithms for increasing link reliability. 264 Local Broadcast 265 The delivery of data to every node within range of the 266 transmitter. 268 Loop-free 270 A property of routing protocols whereby the path taken by a data 271 packet from source to destination never transits the same 272 intermediate node twice before arrival at the destination. 274 Medium-Access Protocol (MAC) 276 A protocol for mediating access to, and possibly allocation of, 277 the physical communications medium. Nodes participating in the 278 medium access protocol can communicate only when they have 279 uncontested access to the medium, so that there will be no 280 interference. When the physical medium is a radio channel, the 281 MAC is the same as the Channel Access Protocol. 283 Mobile Network Prefix 285 A bit string that consists of some number of initial bits of an 286 IP address which identifies the entire mobile network within the 287 Internet topology. All nodes in a mobile network necessarily have 288 an address named after this prefix. 290 Mobility Factor 292 The relative frequency of node movement, compared to the 293 frequency of application initiation. 295 Multipoint relay (MPR) 297 A node which is selected by its one-hop neighbor to re-transmit 298 all broadcast messages that it receives. The message must be new 299 and the time-to-live field of the message must be greater than 300 one. Multipoint relaying is a technique to reduce the number of 301 redundant re-transmissions while diffusing a broadcast message in 302 the network. 304 Neighbor 306 A "neighbor" is any other node to which data may be propagated 307 directly over the communications medium without relying the 308 assistance of any other forwarding node. 310 Neighborhood 312 All the nodes which can receive data on the same link from one 313 node whenever it transmits data. 315 Next Hop 317 A neighbor which has been selected to forward packets along the 318 way to a particular destination. 320 Payload 322 The actual data within a packet, not including network protocol 323 headers which were not inserted by an application. Note that 324 payloads are different between layers: user data is the payload 325 of TCP, which are the payload of IP, which three are the payload 326 of link layer protocols etc. Thus, it is important to identify 327 the scope when talking about payloads. 329 Prefix 331 A bit string that consists of some number of initial bits of an 332 address. 334 Route Table 336 The table where forwarding nodes keep information (including next 337 hop) for various destinations. 339 Route Entry 341 An entry for a specific destination (unicast or multicast) in the 342 route table. 344 Route Establishment 346 The process of determining a route between a source and a 347 destination. 349 Route Activation 351 The process of putting a route into use after it has been 352 determined. 354 Routing Proxy 356 A node that routes packets by overlays, eg. by tunneling, between 357 communicating partners. The Home Agent and Foreign Agent are 358 examples of routing proxies, in that they receive packets 359 destined for the mobile node and tunnel them to the current 360 address of the mobile node. 362 Signal Strength 364 The detectable power of the signal carrying the data bits, as 365 seen by the receiver of the signal. 367 Source Route 369 A source route from node A to node B is an ordered list of IP 370 addresses, starting with the IP address of node A and ending with 371 the IP address of the node B. Between A and B, the source route 372 includes an ordered list of all the intermediate hops between A 373 and B, as well as the interface index of the interface through 374 which the packet should be transmitted to reach the next hop. 376 Spatial re-use 378 Simultaneous use of channels with identical or close physical 379 characteristics, but located spatially far enough apart to avoid 380 interference (i.e., co-channel interference) 382 System-wide Broadcast 384 Same as flooding, but used in contrast to local broadcast. 386 Topology 388 A network can be viewed abstractly as a "graph" whose "topology" 389 at any point in time is defined by set of "points" connected by 390 (possibly directed) "edges." 392 Triggered Update 394 An unsolicited route update transmitted by an router along a path 395 to a destination. 397 3. Mobile Access Networks and Mobile Networks 399 In order to support host mobility a set of nodes towards the network 400 edge may need to have specific functions. Such a set of nodes forms a 401 mobile access network that may or may not be part of the global 402 Internet. Figure 1 presents two examples of such access network 403 topologies. The figure depicts a reference architecture which 404 illustrates an IP network with components defined in this section. 406 We intend to define the concept of the Access Network (AN) which may 407 also support enhanced mobility. It is possible that to support 408 routing and QoS for mobile nodes, existing routing protocols (e.g., 409 OSPF or other standard IGPs) may not be appropriate to maintain 410 forwarding information for these mobile nodes as they change their 411 points of attachment to the Access Network. These new functions are 412 implemented in routers with additional capability. We can distinguish 413 three types of Access Network components: Access Routers (AR) which 414 handle the last hop to the mobile, typically over a wireless link; 415 Access Network Gateways (ANG) which form the boundary on the fixed 416 network side and shield the fixed network from the specialized 417 routing protocols; and (optionally) other internal Access Network 418 Routers which may also be needed in some cases to support the 419 protocols. The Access Network consists of the equipment needed to 420 support this specialized routing, i.e. AR or ANG. AR and ANG may be 421 the same physical nodes. 423 In addition, we present a few basic terms on mobile networks, that 424 is, mobile network, mobile router (MR), and mobile network node 425 (MNN). More terminology for discussing mobile networks can be found 426 in [15]. A more thorough discussion on mobile networks can be found 427 in the working group documents of the NEMO Working Group. 429 Note: this reference architecture is not well suited for people 430 dealing with MANETs. 432 --- ------ ------- | 433 --- | <--> | | -------| AR | -------------------| | | 434 | |--[] --- /------ \ /| ANG |--| 435 --- AP / \ / | | | 436 MH / \ / ------- | 437 (+wireless ___ / ------- | 438 device) | |---- | ANR | | 439 --- ------- | 440 AP / \ | 441 / \ ------- | 442 --- ------ / \| | | 443 | |-------| AR |---------------------| ANG |--| 444 --- ------ | | | 445 AP ------- | 446 | 447 Access Network (AN) 1 | 448 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| 449 Access Network (AN) 2 | 450 | 451 | 452 --- ------ ------- | 453 --- | <--> | | -------| AR | -------------------| | | 454 | |--[] --- /------ /| ANG |--| 455 --- AP / / | | | 456 MH / / ------- | 457 (+wireless ___ / / | 458 device) | |---- / | 459 --- / | 460 AP / | 461 / | 462 | ------ --- ------ ------- | 463 --- |- i MR e <->| |-------| AR |---------| ANR | | 464 | |--| ------ --- \ ------ ------- | 465 --- | AP \ / | 466 MNN | \ / | 467 | --- \ ------ / | 468 --- | | |-------| AR |------- | 469 | |--| --- ------ | 470 --- | AP | 471 MNN 'i': MR ingress interface 472 'e': MR egress interface 474 Figure 1: Reference Network Architecture 476 Mobile Node (MN) 478 An IP node capable of changing its point of attachment to the 479 network. A Mobile Node may or may not have forwarding 480 functionality. 482 Mobile Host (MH) 484 A mobile node that is an end host and not a router. A Mobile host 485 is capable of sending and receiving packets, that is, being a 486 source or destination of traffic, but not a forwarder of it. 488 Fixed Node (FN) 490 A node, either a host or a router, unable to change its point of 491 attachment to the network and its IP address without breaking 492 open sessions. 494 Mobile Network 496 An entire network, moving as a unit, which dynamically changes 497 its point of attachment to the Internet and thus its reachability 498 in the topology. The mobile network is composed by one or more 499 IP-subnets and is connected to the global Internet via one or 500 more Mobile Routers (MR). The internal configuration of the 501 mobile network is assumed to be relatively stable with respect to 502 the MR. 504 Mobile Router (MR) 506 A router capable of changing its point of attachment to the 507 network, moving from one link to another link. The MR is capable 508 of forwarding packets between two or more interfaces, and 509 possibly running a dynamic routing protocol modifying the state 510 by which to do packet forwarding. 512 The interface of a MR attached to a link inside the mobile 513 network is called the ingress interface. The interface of a MR 514 attached to the home link if the MR is at home, or attached to a 515 foreign link if the MR is in a foreign network is called the 516 egress interface. 518 A MR acting as a gateway between an entire mobile network and the 519 rest of the Internet has one or more egress interface(s) and one 520 or more ingress interface(s). Packets forwarded upstream to the 521 rest of the Internet are transmitted through one of the MR's 522 egress interface; packets forwarded downstream to the mobile 523 network are transmitted through one of the MR's ingress 524 interface. 526 Mobile Network Node (MNN) 528 Any node (host or router) located within a mobile network, either 529 permanently or temporarily. A Mobile Network Node may either be a 530 mobile node or a fixed node. 532 Access Link (AL) 534 A last-hop link between a Mobile Node and an Access Router. That 535 is, a facility or medium over which an Access Point and the 536 Mobile Node can communicate at the link layer, i.e., the layer 537 immediately below IP. 539 Access Point (AP) 541 An Access Point is a layer 2 device which is connected to one or 542 more Access Routers and offers the wireless link connection to 543 the Mobile Node. Access Points are sometimes called base 544 stations or access point transceivers. An Access Point may be a 545 separate entity or co-located with an Access Router. 547 Radio Cell 549 The geographical area within which an Access Point provides radio 550 coverage, i.e. where radio communication between a Mobile Node 551 and the specific Access Point is possible. 553 Access Network Router (ANR) 555 An IP router in the Access Network. An Access Network Router may 556 include Access Network specific functionalities, for example, 557 related to mobility and/or QoS. This is to distinguish between 558 ordinary routers and routers that have Access Network-related 559 special functionality. 561 Access Router (AR) 563 An Access Network Router residing on the edge of an Access 564 Network and connected to one or more Access Points. The Access 565 Points may be of different technology. An Access Router offers 566 IP connectivity to Mobile Nodes, acting as a default router to 567 the Mobile Nodes it is currently serving. The Access Router may 568 include intelligence beyond a simple forwarding service offered 569 by ordinary IP routers. 571 Access Network Gateway (ANG) 573 An Access Network Router that separates an Access Network from 574 other IP networks, much in the same way as an ordinary gateway 575 router. The Access Network Gateway looks to the other IP networks 576 like a standard IP router. 578 Access Network (AN) 580 An IP network which includes one or more Access Network Routers. 582 Administrative Domain (AD) 583 A collection of networks under the same administrative control 584 and grouped together for administrative purposes [5]. 586 Serving Access Router (SAR) 588 The Access Router currently offering the connectivity to the 589 Mobile Host. This is usually the point of departure for the 590 Mobile Node as it makes its way towards a new Access Router (then 591 Serving Access Router takes the role of the Old Access Router). 592 There may be several Serving Access Routers serving the Mobile 593 Node at the same time. 595 Old Access Router (OAR) 597 An Access Router that offered connectivity to the Mobile Node 598 prior to a handover. This is the Serving Access Router that will 599 cease or has ceased to offer connectivity to the Mobile Node. 601 New Access Router (NAR) 603 The Access Router that offers connectivity to the Mobile Node 604 after a handover. 606 Previous Access Router (PAR) 608 An Access Router that offered connectivity to the Mobile Node 609 prior to a handover. This is the Serving Access Router that will 610 cease or has ceased to offer connectivity to the Mobile Node. 611 Same as OAR. 613 Candidate Access Router (CAR) 615 An Access Router to which the Mobile Node may do a handoff. 617 4. Handover Terminology 619 These terms refer to different perspectives and approaches to 620 supporting different aspects of mobility. Distinctions can be made 621 according to the scope, range overlap, performance characteristics, 622 diversity characteristics, state transitions, mobility types, and 623 control modes of handover techniques. 625 Roaming 627 An operator-based term involving formal agreements between 628 operators that allows a mobile to get connectivity from a foreign 629 network. Roaming (a particular aspect of user mobility) 630 includes, for example, the functionality by which users can 631 communicate their identity to the local AN so that inter-AN 632 agreements can be activated and service and applications in the 633 MN's home network can be made available to the user locally. 635 Handover 637 (also known as handoff) the process by which an active MN (in the 638 Active State, see section 4.6) changes its point of attachment to 639 the network, or when such a change is attempted. The access 640 network may provide features to minimize the interruption to 641 sessions in progress. 643 There are different types of handover classified according to 644 different aspects involved in the handover. Some of this 645 terminology follows the description of [4]. 647 4.1. Scope of Handover 649 Note that the definitions of horizontal and vertical handover are 650 different than the ones commonly used today. These definitions try to 651 look at the handover from the IP layer's point of view; the IP layer 652 works with network interfaces, rather than specific technologies used 653 by those interfaces. 655 Layer 2 Handover 657 When a MN changes APs (or some other aspect of the radio channel) 658 connected to the same AR's interface then a layer 2 handover 659 occurs. This type of handover is transparent to the routing at 660 the IP layer (or it appears simply as a link layer 661 reconfiguration without any mobility implications). 663 Intra-AR Handover 665 A handover which changes the AR's network interface to the 666 mobile. That is, the Serving AR remains the same but routing 667 changes internal to the AR take place. 669 Intra-AN Handover 671 When the MN changes ARs inside the same AN then this handover 672 occurs. Such a handover is not necessarily visible outside the 673 AN. In case the ANG serving the MN changes, this handover is seen 674 outside the AN due to a change in the routing paths. Note that 675 the ANG may change for only some of the MN's data flows. 677 Inter-AN Handover 679 When the MN moves to a new AN then this handover occurs. This 680 requires some sort of host mobility across ANs, which typically 681 is be provided by the external IP core. Note that this would 682 have to involve the assignment of a new IP access address (e.g., 683 a new care-of address [9]) to the MN. 685 Intra-technology Handover 687 A handover between equipment of the same technology. 689 Inter-technology Handover 691 A handover between equipment of different technologies. 693 Horizontal Handover 695 A handover in which the mobile node's network interface does not 696 change (from the IP point of view); the MN communicates with the 697 access router via the same network interface before and after the 698 handover. A horizontal handover is typically also an intra- 699 technology handover but it can be an inter-technology handover if 700 the MN can do a layer 2 handover between two different 701 technologies without changing the network interface seen by the 702 IP layer. 704 Vertical Handover 706 In a vertical handover the mobile node's network interface to the 707 access network changes. A vertical handover is typically an 708 inter-technology handover but it may also be an intra- technology 709 handover if the MN has several network interfaces of the same 710 type. That is, after the handover, the IP layer communicates with 711 the access network through a different network interface. 713 The different handover types defined in this section and in section 714 4.1 have no direct relationship. In particular, a MN can do an 715 intra-AN handover of any of the types defined above. 717 Note that the horizontal and vertical handovers are not tied to a 718 change in the link layer technology. They define whether, after a 719 handover, the IP packet flow goes through the same (horizontal 720 handover) or a different (vertical handover) network interface. 721 These two handovers do not define whether the AR changes as a result 722 of a handover. 724 4.2. Handover Control 726 A handover must be one of the following two types (a): 728 Mobile-initiated Handover 730 the MN is the one that makes the initial decision to initiate the 731 handover. 733 Network-initiated Handover 735 the network makes the initial decision to initiate the handover. 737 A handover is also one of the following two types (b): 739 Mobile-controlled Handover (MCHO) 740 the MN has the primary control over the handover process. 742 Network-controlled Handover (NCHO) 744 the network has the primary control over the handover process. 746 A handover is also either of these three types (c): 748 Mobile-assisted handover 750 information and measurement from the MN are used by the AR to 751 decide on the execution of a handover. 753 Network-assisted handover 755 a handover where the AN collects information that can be used by 756 the MN in a handover decision. 758 Unassisted handover 760 a handover where no assistance is provided by the MN or the AR to 761 each other. 763 Note that it is possible that the MN and the AR both do 764 measurements and decide on the handover. 766 A handover is also one of the following two types (d): 768 Backward handover 770 a handover either initiated by the OAR, or where the MN initiates 771 a handover via the OAR. 773 Forward handover 775 a handover either initiated by the NAR, or where the MN initiates 776 a handover via the NAR. 778 The handover is also either proactive or reactive (e): 780 Planned handover 782 a proactive (expected) handover where some signalling can be done 783 in advance of the MN getting connected to the new AR, e.g. 784 building a temporary tunnel from the old AR to the new AR. 786 Unplanned handover 788 a reactive (unexpected) handover, where no signalling is done in 789 advance of the MN's move of the OAR to the new AR. 791 The five handover types (a-e) are mostly independent, and every 792 handover should be classiable according to each of these types. 794 4.3. Simultaneous connectivity to Access Routers 796 Make-before-break (MBB) 798 During a MBB handover the MN can communicate simultaneously with 799 the old and new AR. This should not be confused with "soft 800 handover" which relies on macro diversity. 802 Break-before-make (BBM) 804 During a BBM handover the MN cannot communicate simultaneously 805 with the old and the new AR. 807 4.4. Performance and Functional Aspects 809 Handover Latency 811 Handover latency is the time difference between when a MN is last 812 able to send and/or receive an IP packet by way of the OAR, until 813 when the MN is able to send and/or receive an IP packet through 814 the NAR. Adapted from [4]. 816 Smooth handover 818 A handover that aims primarily to minimize packet loss, with no 819 explicit concern for additional delays in packet forwarding. 821 Fast handover 823 A handover that aims primarily to minimize delay, with no 824 explicit interest in packet loss. 826 Seamless handover 828 A handover in which there is no change in service capability, 829 security, or quality. In practice, some degradation in service 830 is to be expected. The definition of a seamless handover in the 831 practical case should be that other protocols, applications, or 832 end users do not detect any change in service capability, 833 security or quality, which would have a bearing on their (normal) 834 operation. See [7] for more discussion on the topic. 836 Throughput 838 The amount of data from a source to a destination processed by 839 the protocol for which throughput is to be measured for instance, 840 IP, TCP, or the MAC protocol. The throughput differs between 841 protocol layers. 843 Goodput 845 The total bandwidth used, less the volume of control messages, 846 protocol overhead from the data packets, and packets dropped due 847 to CRC errors. 849 Pathloss 851 A reduction in signal strength caused by traversing the physical 852 medium constituting the link. 854 Hidden-terminal problem 856 The problem whereby a transmitting node can fail in its attempt 857 to transmit data because of destructive interference which is 858 only detectable at the receiving node, not the transmitting node. 860 Exposed terminal problem 862 The problem whereby a transmitting node prevents another node 863 from transmitting although it could have safely transmitted to 864 anyone else but that node. 866 4.5. Micro Diversity, Macro Diversity, and IP Diversity 868 Certain air interfaces (e.g. the Universal Mobile Telephone System 869 (UMTS) Terrestial Radio Access Network (UTRAN) running in Frequency 870 Division Duplex (FDD) mode) require or at least support macro 871 diversity combining. Essentially, this refers to the fact that a 872 single MN is able to send and receive over two independent radio 873 channels ('diversity branches') at the same time; the information 874 received over different branches is compared and that from the better 875 branch passed to the upper layers. This can be used both to improve 876 overall performance, and to provide a seamless type of handover at 877 layer 2, since a new branch can be added before the old is deleted. 878 See also [6]. 880 It is necessary to differentiate between combining/diversity that 881 occurs at the physical and radio link layers, where the relevant unit 882 of data is the radio frame, and that which occurs at layer 3, the 883 network layer, where what is considered is the IP packet itself. 885 In the following definitions micro- and macro diversity refer to 886 protocol layers below the network layer, and IP diversity refers to 887 the network layer. 889 Micro diversity 891 for example, two antennas on the same transmitter send the same 892 signal to a receiver over a slightly different path to overcome 893 fading. 895 Macro diversity 897 Duplicating or combining actions taking place over multiple APs, 898 possibly attached to different ARs. This may require support 899 from the network layer to move the radio frames between the base 900 stations and a central combining point. 902 IP diversity 904 The splitting and combining of packets at the IP level. 906 4.6. Paging, and Mobile Node States and Modes 908 Mobile systems may employ the use of MN states in order to operate 909 more efficiently without degrading the performance of the system. The 910 term 'mode' is also common and means the same as 'state'. 912 A MN is always in one of the following three states: 914 Active State 916 When the AN knows the MN's SAR and the MN can send and receive IP 917 packets. The AL may not be active, but the radio layer is able 918 to establish one without assistance from the network layer. The 919 MN has an IP address assigned. 921 Dormant State 923 A state in which the mobile restricts its ability to receive 924 normal IP traffic by reducing its monitoring of radio channels. 925 The AN knows the MH's Paging Area, but the MH has no SAR and so 926 packets cannot be delivered to the MH without the AN initiating 927 paging. 929 Time-slotted Dormant Mode 931 A dormant mode implementation in which the mobile alternates 932 between periods of not listening for any radio traffic and 933 listening for traffic. Time-slotted dormant mode implementations 934 are typically synchronized with the network so the network can 935 deliver traffic to the mobile during listening periods. 937 Inactive State 939 the MH is in neither the Active nor Dormant State. The host is no 940 longer listening for any packets, not even periodically, and not 941 sending packets. The host may be in a powered off state, it may 942 have shut down all interfaces to drastically conserve power, or 943 it may be out of range of a radio access point. The MN does not 944 necessarily have an IP access address from the AN. 946 Note: in fact, as well as the MN being in one of these three states, 947 the AN also stores which state it believes the MN is in. Normally 948 these are consistent; the definitions above assume so. 950 Here are some additional definitions for paging, taking into account 951 the above state definitions. 953 Paging 955 A procedure initiated by the Access Network to move an Idle MN 956 into the Active State. As a result of paging, the MN establishes 957 a SAR and the IP routes are set up. 959 Location updating 961 A procedure initiated by the MN, by which it informs the AN that 962 it has moved into a new paging area. 964 Paging Area 966 A part of the Access Network, typically containing a number of 967 ARs/APs, which corresponds to some geographical area. The AN 968 keeps and updates a list of all the Idle MNs present in the area. 969 If the MN is within the radio coverage of the area it will be 970 able to receive paging messages sent within that Paging Area. 972 Paging Area Registrations 974 Signaling from a dormant mode mobile node to the network, by 975 which it establishes its presence in a new paging area. Paging 976 Area Registrations thus enable the network to maintain a rough 977 idea of where the mobile is located. 979 Paging Channel 981 A radio channel dedicated to signaling dormant mode mobiles for 982 paging purposes. By current practice, the protocol used on a 983 paging channel is usually dictated by the radio link protocol, 984 although some paging protocols have provision for carrying 985 arbitrary traffic (and thus could potentially be used to carry 986 IP). 988 Traffic Channel 990 The radio channel on which IP traffic to an active mobile is 991 typically sent. This channel is used by a mobile that is 992 actively sending and receiving IP traffic, and is not 993 continuously active in a dormant mode mobile. For some radio 994 link protocols, this may be the only channel available. 996 4.7. Context Transfer 998 Context 1000 The information on the current state of a routing-related service 1001 required to re-establish the routing-related service on a new 1002 subnet without having to perform the entire protocol exchange 1003 with the mobile host from scratch. 1005 Feature context 1006 The collection of information representing the context for a 1007 given feature. The full context associated with a mobile host is 1008 the collection of one or more feature contexts. 1010 Context transfer 1012 The movement of context from one router or other network entity 1013 to another as a means of re-establishing routing related services 1014 on a new subnet or collection of subnets. 1016 Routing-related service 1018 A modification to the default routing treatment of packets to and 1019 from the mobile host. Initially establishing routing-related 1020 services usually requires a protocol exchange with the mobile 1021 host. An example of a routing-related service is header 1022 compression. The service may also be indirectly related to 1023 routing, for example, security. Security may not affect the 1024 forwarding decision of all intermediate routers, but a packet may 1025 be dropped if it fails a security check (can't be encrypted, 1026 authentication failed, etc.). Dropping the packet is basically a 1027 routing decision. 1029 4.8. Candidate Access Router Discovery 1031 Capability of AR 1033 A characteristic of the service offered by an AR that may be of 1034 interest to an MN when the AR is being considered as a handoff 1035 candidate. 1037 Candidate AR (CAR) 1039 An AR to which MN has a choice of performing IP-level handoff. 1040 This means that MN has the right radio interface to connect to an 1041 AP that is served by this AR, as well as the coverage of this AR 1042 overlaps with that of the AR to which MN is currently attached. 1044 Target AR (TAR) 1046 An AR with which the procedures for the MN's IP-level handoff are 1047 initiated. TAR is selected after running a TAR Selection 1048 Algorithm that takes into account the capabilities of CARs, 1049 preferences of MN and any local policies. 1051 4.9. User, Personal and Host Mobility 1053 Different sorts of mobility management may be required of a mobile 1054 system. We can differentiate between user, personal, host and 1055 network mobility. 1057 User mobility 1058 refers to the ability of a user to access services from different 1059 physical hosts. This usually means the user has an account on 1060 these different hosts or that a host does not restrict users from 1061 using the host to access services. 1063 Personal mobility 1065 complements user mobility with the ability to track the user's 1066 location and provide the user's current location to allow 1067 sessions to be initiated by and towards the user by anyone on any 1068 other network. Personal mobility is also concerned with enabling 1069 associated security, billing and service subscription 1070 authorization made between administrative domains. 1072 Host mobility 1074 refers to the function of allowing a mobile host to change its 1075 point of attachment to the network, without interrupting IP 1076 packet delivery to/from that host. There may be different sub- 1077 functions depending on what the current level of service is being 1078 provided; in particular, support for host mobility usually 1079 implies active and idle modes of operation, depending on whether 1080 the host has any current sessions or not. Access Network 1081 procedures are required to keep track of the current point of 1082 attachment of all the MNs or establish it at will. Accurate 1083 location and routing procedures are required in order to maintain 1084 the integrity of the communication. Host mobility is often 1085 called 'terminal mobility'. 1087 Network mobility 1089 Network mobility occurs when an entire network changes its point 1090 of attachment to the Internet and, thus, its reachability in the 1091 topology, which is referred to as a mobile network. 1093 Two subcategories of mobility can be identified withing either host 1094 mobility and network mobility: 1096 Global mobility 1098 Same as Macro mobility. 1100 Local mobility 1102 Same as Micro mobility. 1104 Macro mobility 1106 Mobility over a large area. This includes mobility support and 1107 associated address registration procedures that are needed when a 1108 mobile host moves between IP domains. Inter-AN handovers 1109 typically involve macro-mobility protocols. Mobile-IP can be 1110 seen as a means to provide macro mobility. 1112 Micro mobility 1114 Mobility over a small area. Usually this means mobility within 1115 an IP domain with an emphasis on support for active mode using 1116 handover, although it may include idle mode procedures also. 1117 Micro-mobility protocols exploit the locality of movement by 1118 confining movement related changes and signalling to the access 1119 network. 1121 Local Mobility Management 1123 Local Mobility Management (LMM) is a generic term for protocols 1124 dealing with IP mobility management confined within the access 1125 network. LMM messages are not routed outside the access network, 1126 although a handover may trigger Mobile IP messages to be sent to 1127 correspondent nodes and home agents. 1129 5. Specific Terminology for Mobile Ad-Hoc Networking 1131 Cluster 1133 A group of nodes located within close physical proximity, 1134 typically all within range of one another, which can be grouped 1135 together for the purpose of limiting the production and 1136 propogation of routing information. 1138 Cluster head 1140 A cluster head is a node (often elected in the cluster formation 1141 process) that has complete knowledge about group membership and 1142 link state information in the cluster. Each cluster should have 1143 one and only one cluster head. 1145 Cluster member 1147 All nodes within a cluster EXCEPT the cluster head are called 1148 members of that cluster. 1150 Convergence 1152 The process of approaching a state of equilibrium in which all 1153 nodes in the network agree on a consistent collection of state 1154 about the topology of the network, and in which no further 1155 control messages are needed to establish the consistency of the 1156 network topology. 1158 Convergence time 1160 The time which is required for a network to reach convergence 1161 after an event (typically, the movement of a mobile node) which 1162 changes the network topology. 1164 Laydown 1165 The relative physical location of the nodes within the ad hoc 1166 network. 1168 Pathloss matrix 1170 A matrix of coefficients describing the pathloss between any two 1171 nodes in an ad hoc network. When the links are asymmetric, the 1172 matrix is also asymmetric. 1174 Scenario 1176 The tuple 1177 characterizing a class of ad hoc networks. 1179 6. Security-related Terminology 1181 This section includes terminology commonly used around mobile and 1182 wireless networking. Only a mobility-related subset of the entire 1183 security terminology is presented. 1185 Authorization-enabling extension 1187 An authentication which makes a (registration) message acceptable 1188 to the ultimate recipient of the registration message. An 1189 authorization-enabling extension must contain an SPI [12]. 1191 Mobility Security Association 1193 A collection of security contexts, between a pair of nodes, which 1194 may be applied to mobility-related protocol messages exchanged 1195 between them. In Mobile IP, each context indicates an 1196 authentication algorithm and mode, a secret (a shared key, or 1197 appropriate public/private key pair), and a style of replay 1198 protection in use. Mobility security associations may be stored 1199 separately from the node's IPsec Security Policy Database (SPD) 1200 [12]. 1202 Registration Key 1204 A key used as the basis of a Mobility Security Association 1205 between a mobile node and a foreign agent. A registration key is 1206 typically only used once or a very few times, and only for the 1207 purposes of verifying a small volume of Authentication data [14]. 1209 Security Context 1211 A security context between two routers defines the manner in 1212 which two routers choose to mutually authentication each other, 1213 and indicates an authentication algorithm and mode. 1215 Security Parameter Index (SPI) 1217 An index identifying a security context between a pair of routers 1218 among the contexts possible in the mobility security association. 1220 Stale challenge 1222 Any challenge that has been used by the mobile node in a 1223 Registration Request message and processed by the Foreign Agent 1224 by relaying or generating The Foreign Agent may not be able to 1225 keep records for all previously used challenges [13]. 1227 Unknown challenge 1229 Any challenge from a particular mobile node that the foreign 1230 agent has no record of having put either into one of its recent 1231 Agent Advertisements or into a registration reply message to that 1232 mobile node [13]. 1234 Unused challenge 1236 A challenge that has not been already accepted by the Foreign 1237 Agent challenge in a corresponding Registration Reply message -- 1238 i.e., a challenge that is neither unknown nor previously used 1239 [13]. 1241 The Mobile IPv6 specification includes more security terminology 1242 related to MIPv6 bindings [11]. 1244 7. Security Considerations 1246 This document presents only terminology. There are no security issues 1247 in this document. 1249 8. Contributors 1251 This draft was initially based on the work of 1253 o Tapio Suihko, VTT Information Technology, Finland 1254 o Phil Eardley and Dave Wisely, BT, UK 1255 o Robert Hancock, Siemens/Roke Manor Research, UK, 1256 o Nikos Georganopoulos, King's College London 1257 o Markku Kojo and Jukka Manner, University of Helsinki, Finland. 1259 Since revision -02 of the document draft-manner-seamoby-terms-02.txt, 1260 Charles Perkins has given as input terminology related to ad-hoc 1261 networks. 1263 Thierry Ernst has provided the terminology for discussing mobile 1264 networks. 1266 9. Change log 1268 Changes from -03 1269 - Added comments from Randy Presuhn and Thierry Ernst 1271 Changes from -02 1272 - Updated the terminology related to mobile networks 1274 Changes from -01 1275 - Added security terminology 1276 - Miscellaneous small refinements of definitions 1278 Changes from -00 1279 - Added definition for Routing Proxy 1280 - Added basic terminology about mobile networks 1281 - Added Link-Layer Trigger from FMIPv6 1282 - Edited the CAR terminology section 1283 - Added definitions for MPR, CoA, BU 1284 - Changed the definition of Home Address 1285 - Added a mobile network into Figure 1 1286 - Edited the Network Components section 1288 10. Acknowledgement 1290 This work has been partially performed in the framework of the IST 1291 project IST-2000-28584 MIND, which is partly funded by the European 1292 Union. Some of the authors would like to acknowledge the help of 1293 their colleagues in preparing this document. 1295 Randy Presuhn did a very thorough and helpful review of the -02 1296 version of the terminology. 1298 Some definitions of terminology have been adapted from [1], [7], [3], 1299 [2], [4], [9], [10], [11] and [12]. 1301 11. Informative References 1303 [1] Blair, D., Tweedly, A., Thomas, M., Trostle, J. and 1304 Ramalho, M., "Realtime Mobile IPv6 Framework", Work in 1305 Progress. 1307 [2] Calhoun, P., Montenegro, G. and Perkins, C., "Mobile IP 1308 Regionalized Tunnel Management", Work in Progress. 1310 [3] Deering, S. and Hinden, R., "Internet Protocol, Version 6 1311 (IPv6) Specification". RFC 2460, December 1998. 1313 [4] Dommety, G. (ed.), "Fast Handovers for Mobile IPv6", Work in 1314 Progress. 1316 [5] Yavatkar, R., Pendarakis, D. and Guerin, R., "A Framework for 1317 Policy-based Admission Control". RFC 2753, January 2000. 1319 [6] Kempf, J., McCann, P. and Roberts, P., "IP Mobility and the 1320 CDMA Radio Access Network: Applicability Statement for Soft 1321 Handoff", Work in Progress. 1323 [7] Kempf, J. (ed.), "Problem Description: Reasons For Doing 1324 Context Transfers Between Nodes in an IP Access Network". 1325 RFC 3374, September 2002. 1327 [8] Pandya, R., "Emerging Mobile and Personal Communication 1328 Systems". IEEE Communications Magazine, 33:44--52, June 1995. 1330 [9] Ramjee, R., La Porta, T., Thuel, S., Varadhan, K. and 1331 Salgarelli, L., "IP micro-mobility support using HAWAII", Work 1332 in Progress. 1334 [10] Trossen, D., Krishnamurthi, G., Chaskar, H. and Kempf, J., 1335 "Issues in candidate access router discovery for seamless 1336 IP-level handoffs", Work in Progress. 1338 [11] Johnson, D., Perkins, D. and Arkko, J., "Mobility 1339 Support in IPv6", Work in Progress. 1341 [12] Perkins, C. (ed.), "IP Mobility Support for IPv4". RFC 3344, 1342 August 2002. 1344 [13] Perkins, C., Calhoun, P. and Bharatia, J., "Mobile 1345 IPv4 Challenge/Response Extensions (revised)", Work in 1346 Progress. 1348 [14] Perkins, C. and Calhoun, P., "AAA Registration Keys for Mobile 1349 IP", Work in Progress. 1351 [15] Ernst, T. and Lach, H., "Network Mobility Support 1352 Terminology", Work in Progress. 1354 12. Author's Addresses 1356 Questions about this document may be directed to: 1358 Jukka Manner 1359 Department of Computer Science 1360 University of Helsinki 1361 P.O. Box 26 (Teollisuuskatu 23) 1362 FIN-00014 HELSINKI 1363 Finland 1365 Voice: +358-9-191-44210 1366 Fax: +358-9-191-44441 1367 E-Mail: jmanner@cs.helsinki.fi 1368 Markku Kojo 1369 Department of Computer Science 1370 University of Helsinki 1371 P.O. Box 26 (Teollisuuskatu 23) 1372 FIN-00014 HELSINKI 1373 Finland 1375 Voice: +358-9-191-44179 1376 Fax: +358-9-191-44441 1377 E-Mail: kojo@cs.helsinki.fi 1379 Charles E. Perkins 1380 Communications Systems Lab 1381 Nokia Research Center 1382 313 Fairchild Drive 1383 Mountain View, California 94043 1384 USA 1385 Phone: +1-650 625-2986 1386 E-Mail: charliep@iprg.nokia.com 1387 Fax: +1 650 625-2502 1389 Tapio Suihko 1390 VTT Information Technology 1391 P.O. Box 1203 1392 FIN-02044 VTT 1393 Finland 1395 Voice: +358-9-456-6078 1396 Fax: +358-9-456-7028 1397 E-Mail: tapio.suihko@vtt.fi 1399 Phil Eardley 1400 BTexaCT 1401 Adastral Park 1402 Martlesham 1403 Ipswich IP5 3RE 1404 United Kingdom 1406 Voice: +44-1473-645938 1407 Fax: +44-1473-646885 1408 E-Mail: philip.eardley@bt.com 1410 Dave Wisely 1411 BTexaCT 1412 Adastral Park 1413 Martlesham 1414 Ipswich IP5 3RE 1415 United Kingdom 1417 Voice: +44-1473-643848 1418 Fax: +44-1473-646885 1419 E-Mail: dave.wisely@bt.com 1420 Robert Hancock 1421 Roke Manor Research Ltd 1422 Romsey, Hants, SO51 0ZN 1423 United Kingdom 1425 Voice: +44-1794-833601 1426 Fax: +44-1794-833434 1427 E-Mail: robert.hancock@roke.co.uk 1429 Nikos Georganopoulos 1430 King's College London 1431 Strand 1432 London WC2R 2LS 1433 United Kingdom 1435 Voice: +44-20-78482889 1436 Fax: +44-20-78482664 1437 E-Mail: nikolaos.georganopoulos@kcl.ac.uk 1439 13. Appendix A - Examples 1441 This appendix provides examples for the terminology presented. 1443 A.1. Mobility 1445 Host mobility is logically independent of user mobility, although in 1446 real networks, at least the address management functions are often 1447 required to initially attach the host to the network. In addition, 1448 if the network wishes to determine whether access is authorized (and 1449 if so, who to charge for it), then this may be tied to the identity 1450 of the user of the terminal. 1452 An example of user mobility would be a campus network, where a 1453 student can log into the campus network from several workstations and 1454 still retrieve files, emails, and other services automatically. 1456 Personal mobility support typically amounts to the maintenance and 1457 update of some sort of address mapping database, such as a SIP server 1458 or DNS server; it is also possible for the personal mobility support 1459 function to take a part in forwarding control messages between end 1460 user and correspondent rather than simply acting as a database. SIP 1461 is a protocol for session initiation in IP networks. It includes 1462 registration procedures which partially support personal mobility 1463 (namely, the ability for the network to route a session towards a 1464 user at a local IP address). 1466 Personal mobility has been defined in [8] as "the ability of end 1467 users to originate and receive calls and access subscribed 1468 telecommunication services on any terminal in any location, and the 1469 ability of the network to identify end users as they move. Personal 1470 mobility is based on the use of a unique personal identity (i.e., 1471 personal number)." 1473 Roaming, in its original (GSM) sense, is the ability of a user to 1474 connect to the networks owned by operators other than the one having 1475 a direct formal relationship with the user. More recently (e.g., in 1476 data networks and UMTS) it also refers providing user-customized 1477 services in foreign networks (e.g., QoS profiles for specific 1478 applications). 1480 HAWAII, Cellular IP, Regional Registration and Edge Mobility 1481 Architecture (EMA) are examples of micro mobility schemes, with the 1482 assumption that Mobile IP is used for macro mobility. 1484 Wireless LAN technologies such as IEEE 802.11 typically support 1485 aspects of user and host mobility in a minimal way. User mobility 1486 procedures (for access control and so on) are defined only over the 1487 air interface (and the way these are handled within the network is 1488 not further defined). 1490 Public Land Mobile Networks (GSM/UMTS) typically have extensive 1491 support for both user and host mobility. Complete sets of protocols 1492 (both over the air and on the network side) are provided for user 1493 mobility, including customized service provision. Handover for host 1494 mobility is also supported, both within access networks, and also 1495 within the GSM/UMTS core network for mobility between access networks 1496 of the same operator. 1498 A.2. Handovers 1500 A hard handover is required where a MN is not able to receive or send 1501 traffic from/to two APs simultaneously. In order to move the traffic 1502 channel from the old to the new access point the MN abruptly changes 1503 the frequency/timeslot/code on which it is transmitting and listening 1504 to new values associated with a new access point. Thus, the handover 1505 is a break-before-make handover. 1507 A good example of hard handover is GSM where the mobile listens for 1508 new base stations, reports back to the network the signal strength 1509 and identity of the new base station(s) heard. When the old base 1510 station decides that a handover is required it instructs the new base 1511 station to set up resources and, when confirmed, instructs the mobile 1512 to switch to a new frequency and time slot. This sort of hand over 1513 is called hard, mobile assisted, network initiated and backward 1514 (meaning that the old base station is responsible for handling the 1515 change-over). 1517 In a Time-Division Multiple Access (TDMA) system, such as GSM, the 1518 hard hand over is delayed until the mobile has moved well within the 1519 coverage of the new base station. If the handover threshold was set 1520 to the point where the new base station signal exceeded the old then 1521 there would be a very large number of handovers as the mobile moved 1522 through the region between the cells and radio signals fluctuated, 1523 this would create a large signalling traffic. To avoid this a large 1524 hysteresis is set, i.e. the new base station must be (say) 10dB 1525 stronger for handover to occur. If the same was done in Wideband 1526 Carrier Division Multiple Access (W-CDMA) then the mobile would be 1527 transmitting a powerful signal to the old base station and creating 1528 interference for other users, since in CDMA everyone else's 1529 transmissions are seen as noise, thus reducing capacity. To avoid 1530 this soft handover is used, giving an estimated doubling in capacity. 1531 Support for soft handover (in a single mode terminal) is 1532 characteristic of radio interfaces which also require macro diversity 1533 for interference limitation but the two concepts are logically 1534 independent. 1536 A good example of soft handover is the UTRAN FDD mode. W-CDMA is 1537 particularly suited to soft handover because of the design of the 1538 receivers and transmitters: typically a rake receiver will be used 1539 to overcome the multi-path fading of the wide-band channel. Rake 1540 receivers have a number of so-called fingers, each effectively 1541 separate detectors, that are tuned to the same signal (e.g. 1542 spreading code) but delayed by different times. When the delay times 1543 are correctly adjusted and the various components properly combined 1544 (this is micro diversity combining) the effect of multi-path fading 1545 is removed. The rake receiver can also be used to detect signals 1546 from different transmitters by tuning the fingers to different 1547 spreading codes. Soft handover is used in UTRAN FDD mode to also 1548 increase capacity. 1550 Every handover can be seen as a context-aware Handover. In PLMNs the 1551 context to be fulfilled is that the new AP can accommodate the new 1552 mobile, for example, the new GSM cell can serve the incoming phone. 1553 Lately, the notion of Context-aware Handovers has been enlarged by, 1554 for example, QoS-aware handovers, meaning that the handover is 1555 governed by the need to support the QoS-context of the moving mobile 1556 in order to keep the service level assured to the user of the MN. 1558 A.3. Diversity combining 1560 In the case of UMTS it is radio frames that are duplicated at some 1561 point in the network, at the serving Radio Network Controller (RNC), 1562 and sent to a number of basestations and, possibly via other (drift) 1563 RNCs. The combining that takes place at the serving RNC in the uplink 1564 direction is typically based on some simple quality comparison of the 1565 various received frames, which implies that the various copies of 1566 these frames must contain identical upper layer information. The 1567 serving RNC also has to do buffering data frames to take account of 1568 the differing time of flight from each basestation to the RNC. 1570 A.4. Miscellaneous 1572 In a GPRS/UMTS system the Access Network Gateway node could be the 1573 GGSN component. The ANG can provide support for mobility of hosts, 1574 admission control, policy enforcement, and Foreign Agent 1575 functionality [9]. 1577 When presenting a mobile network topology, APs and ARs are usually 1578 pictured as separate components (see Figure 1). This is the case 1579 with GSM/GPRS/UMTS presentations, for example. From the IP point of 1580 view APs are not directly visible. An AP should only be seen from 1581 the MN's or AR's IP layer as a link (interface) connecting MNs to the 1582 AR. 1584 When the mobile moves through the network, depending on the mobility 1585 mechanism, the OAR will forward packets destined to the old MNs 1586 address to the SAR which currently serves the MN. At the same time 1587 the handover mechanism may be studying CARs to find the best NAR 1588 where the MN will be handed next. 1590 14. Appendix B - Index of Terms 1592 1594 Full Copyright Statement 1596 Copyright (C) The Internet Society (2001). All Rights Reserved. 1598 This document and translations of it may be copied and furnished to 1599 others, and derivative works that comment on or otherwise explain it 1600 or assist in its implementation may be prepared, copied, published 1601 and distributed, in whole or in part, without restriction of any 1602 kind, provided that the above copyright notice and this paragraph are 1603 included on all such copies and derivative works. However, this 1604 document itself may not be modified in any way, such as by removing 1605 the copyright notice or references to the Internet Society or other 1606 Internet organizations, except as needed for the purpose of 1607 developing Internet standards in which case the procedures for 1608 copyrights defined in the Internet Standards process must be 1609 followed, or as required to translate it into languages other than 1610 English. 1612 The limited permissions granted above are perpetual and will not be 1613 revoked by the Internet Society or its successors or assigns. 1615 This document and the information contained herein is provided on an 1616 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1617 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1618 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1619 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1620 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.