idnits 2.17.1 draft-ietf-seamoby-mobility-terminology-01.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1152: '... MAY be stored separately from t...' 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' ** Obsolete normative reference: RFC 2002 (ref. '9') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-cardiscovery-issues (ref. '11') == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-18 -- Possible downref: Normative reference to a draft: ref. '13' Summary: 10 errors (**), 0 flaws (~~), 4 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: May, 2003 University of Helsinki 5 November, 2002 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 May, 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 -00 51 - Added definition for Routing Proxy 52 - Added basic terminology about mobile networks 53 - Added Link-Layer Trigger from FMIPv6 54 - Edited the CAR terminology section 55 - Added definitions for MPR, CoA, BU 56 - Changed the definition of Home Address 57 - Added a mobile network into Figure 1 58 - Edited the Network Components section 60 TODO's 61 The draft-irtf-mm-taxonomy-00.txt (expired) includes several good 62 additional candidate definitions, eg.: 63 o Mobility identities 64 o Transports 65 o Others? 66 We also need someone to write the Security Terminology section. 68 Table of Contents 70 1 Introduction ................................................. 2 71 2 General Terms ................................................ 3 72 3 Mobile Access Network Components ............................. 8 73 4 Handover Terminology ......................................... 11 74 4.1 Scope of Handover .......................................... 12 75 4.2 Handover Control ........................................... 13 76 4.3 Simultaneous connectivity to Access Routers ................ 14 77 4.4 Performance and Functional Aspects ......................... 15 78 4.5 Micro Diversity, Macro Diversity, and IP Diversity ......... 16 79 4.6 Paging, and Mobile Node States and Modes ................... 17 80 4.7 Context Transfer ........................................... 18 81 4.8 Candidate Access Router Discovery .......................... 19 82 4.9 User, Personal and Host Mobility ........................... 19 83 5 Specific Terminology for Mobile Ad-Hoc Networking ............ 21 84 6 Mobile Networks .............................................. 22 85 7 Security-related Terminology ................................. 22 86 8 Security Considerations ...................................... 23 87 9 Contributors ................................................. 23 88 10 Acknowledgement ............................................. 23 89 11 References .................................................. 23 90 12 Author's Addresses .......................................... 25 91 13 Appendix A - Examples ....................................... 27 92 14 Appendix B - Index of Terms ................................. 29 94 1. Introduction 96 This document presents terminology to be used for documents and 97 discussions within the Seamoby Working Group. Other mobility related 98 working groups could like take advantage of this terminology, in 99 order to create a common terminology for the area of mobility in IP 100 networks. These groups would include MIP, MANET, ROHC and NEMO. 102 Some terms and their definitions that are not directly related to the 103 IP world are included for the purpose of harmonizing the terminology, 104 for example, 'Access Point' and 'base station' refer to the same 105 component, from the point of view of IP, but 'Access Router' has a 106 very different meaning. The presented terminology may also, it is 107 hoped, be adequate to cover mobile ad-hoc networks. 109 The proposed terminology is not meant to assert any new terminology. 110 Rather the authors would welcome discussion on more exact definitions 111 as well as missing or unnecessary terms. This work is a 112 collaborative enterprise between people from many different 113 engineering backgrounds and so already presents a first step in 114 harmonizing the terminology. 116 The terminology in this draft is divided into several sections. 117 First, there is a list of terms for general use and mobile access 118 networks followed by terms related to handovers, and finally some 119 terms used within the MANET and NEMO working group. 121 2. General Terms 123 Bandwidth 125 The total capacity of a link to carry information (typically 126 bits). 128 Bandwidth Utilization 130 The actual amount of information delivered over a link, expressed 131 as a percent of the available bandwidth on that link. 133 Beacon 135 A control message broadcast by a node (especially, a base 136 station) informing all the other nodes in its neighborhood of the 137 continuing presence of the broadcasting node, possibly along with 138 additional status or configuration information. 140 Binding update (BU) 142 A message indicating a mobile node's current mobility binding, 143 and in particular its care-of address. 145 Care-of Address (CoA) 147 An IP address associated with a mobile node while visiting a 148 foreign link; the subnet prefix of this IP address is a foreign 149 subnet prefix. Among the multiple care-of addresses that a 150 mobile node may have at any given time (e.g., with different 151 subnet prefixes), the one registered with the mobile node's home 152 agent is called its "primary" care-of address [12]. 154 Channel 155 A subdivision of the physical medium allowing possibly shared 156 independent uses of the medium. Channels may be made available 157 by subdividing the medium into distinct time slots, or distinct 158 spectral bands, or decorrelated coding sequences. 160 Channel Access Protocol 162 A protocol for mediating access to, and possibly allocation of, 163 the various channels available within the physical communications 164 medium. Nodes participating in the channel access protocol can 165 communicate only when they have uncontested access to the medium, 166 so that there will be no interference. 168 Control Message 170 Information passed between two or more network nodes for 171 maintaining protocol state, which may be unrelated to any 172 specific application. 174 Distance Vector 176 A style of routing protocol in which, for each desired 177 destination, a node maintains information about the distance to 178 that destination, and a vector (next hop) towards that 179 destination. 181 Fairness 183 A property of channel access protocols whereby a medium is made 184 fairly equal to all eligible nodes on the link. Fairness does 185 not strictly imply equality, especially in cases where nodes are 186 given link access according to unequal priority or 187 classification. 189 Flooding 191 The process of delivering data or control messages to every node 192 within the network under consideration. 194 Forwarding node 196 A node which performs the function of forwarding datagrams from 197 one of its neighbors to another. 199 Home Address 201 An IP address assigned to a mobile node, used as the permanent 202 address of the mobile node. This address is within the mobile 203 node's home link. Standard IP routing mechanisms will deliver 204 packets destined for a mobile node's home address to its home 205 link [12]. 207 Interface 208 A node's attachment to a link. 210 IP access address 212 An IP address (often dynamically allocated) which a node uses to 213 designate its current point of attachment to the access network. 214 The IP access address is typically to be distinguished from the 215 mobile node's home address; in fact, the former may be considered 216 unsuitable for use by any but the most short-lived applications. 218 Link 220 A communication facility or physical medium that can sustain data 221 communications between multiple network nodes, such as an 222 Ethernet (simple or bridged). A link is the layer immediately 223 below IP. 225 Asymmetric Link 227 A link with transmission characteristics which are different 228 depending upon the relative position or design characteristics of 229 the transmitter and the receiver of data on the link. For 230 instance, the range of one transmitter may be much higher than 231 the range of another transmitter on the same medium. 233 Link Establishment 235 The process of establishing a link between the mobile node and 236 the access network. This may involve allocating a channel, or 237 other local wireless resources, possibly including a minimum 238 level of service or bandwidth. 240 Link-layer Trigger (L2 Trigger) 242 Information from L2 that informs L3 of the detailed events 243 involved in handover sequencing at L2. L2 triggers are not 244 specific to any particular L2, but rather represent 245 generalizations of L2 information available from a wide variety 246 of L2 protocols [4]. 248 Link State 250 A style of routing protocol in which every node within the 251 network is expected to maintain information about every link 252 within the network topology. 254 Link-level Acknowledgement 256 A protocol strategy, typically employed over wireless media, 257 requiring neighbors to acknowledge receipt of packets (typically 258 unicast only) from the transmitter. Such strategies aim to avoid 259 packet loss or delay resulting from lack of, or unwanted 260 characteristics of, higher level protocols. 262 Link-layer acknowledgements are often used as part of ARQ 263 algorithms for increasing link reliability. 265 Local Broadcast 267 The delivery of data to every node within range of the 268 transmitter. 270 Loop-free 272 A property of routing protocols whereby the path taken by a data 273 packet from source to destination never transits the same 274 intermediate node twice before arrival at the destination. 276 Medium-Access Protocol (MAC) 278 A protocol for mediating access to, and possibly allocation of, 279 the physical communications medium. Nodes participating in the 280 medium access protocol can communicate only when they have 281 uncontested access to the medium, so that there will be no 282 interference. When the physical medium is a radio channel, the 283 MAC is the same as the Channel Access Protocol. 285 Mobility Factor 287 The relative frequency of node movement, compared to the 288 frequency of application initiation. 290 Multipoint relay (MPR) 292 A node which is selected by its one-hop neighbor to re-transmit 293 all broadcast messages that it receives. The message must be new 294 and the time-to-live field of the message must be greater than 295 one. Multipoint relaying is a technique to reduce the number of 296 redundant re-transmissions while diffusing a broadcast message in 297 the network. 299 Neighbor 301 A "neighbor" is any other node to which data may be propagated 302 directly over the communications medium without relying the 303 assistance of any other forwarding node 305 Neighborhood 307 All the nodes which can receive data on the same link from one 308 node whenever it transmits data. 310 Next Hop 312 A neighbor which has been selected to forward packets along the 313 way to a particular destination. 315 Payload 316 The actual data within a packet, not including network protocol 317 headers which were not inserted by an application. Note, that 318 payloads are different between layers: user data is the payload 319 of TCP, which are the payload of IP, which three are the payload 320 of link layer protocols etc. Thus, it is important to identify 321 the scope when talking about payloads. 323 Prefix 325 A bit string that consists of some number of initial bits of an 326 address. 328 Route Table 330 The table where forwarding nodes keep information (including next 331 hop) for various destinations. 333 Route Entry 335 An entry for a specific destination (unicast or multicast) in the 336 route table. 338 Route Establishment 340 The process of determining a route between a source and a 341 destination. 343 Route Activation 345 The process of putting a route into use after it has been 346 determined. 348 Routing Proxy 350 A node that routes packets by overlays, eg. by tunneling, between 351 communicating partners. The Home Agent and Foreign Agent are 352 examples of routing proxies, in that they receive packets 353 destined for the mobile node and tunnel them to the current 354 address of the mobile node. 356 Signal Strength 358 The detectable power of the signal carrying the data bits, as 359 seen by the receiver of the signal. 361 Source Route 363 A source route from node A to node B is an ordered list of IP 364 addresses, starting with the IP address of node A and ending with 365 the IP address of the node B. Between A and B, the source route 366 includes an ordered list of all the intermediate hops between A 367 and B, as well as the interface index of the interface through 368 which the packet should be transmitted to reach the next hop. 370 Spatial re-use 372 Simultaneous use of channels with identical or close physical 373 characteristics, but located spatially far enough apart to avoid 374 interference (i.e., co-channel interference) 376 System-wide Broadcast 378 Same as flooding, but used in contrast to local broadcast. 380 Topology 382 A network can be viewed abstractly as a "graph" whose "topology" 383 at any point in time is defined by set of "points" connected by 384 (possibly directed) "edges." 386 Triggered Update 388 An unsolicited route update transmitted by an router along a path 389 to a destination. 391 3. Mobile Access Network Components 393 In order to support host mobility a set of nodes towards the network 394 edge often need to have specific functions. Such a set of nodes form 395 a mobile access network that may or may not be part of the global 396 Internet. The Figure 1 presents two examples of such access network 397 (AN) topologies. The figure depicts a reference architecture which 398 illustrates an IP network with components defined in this section. 400 We intend to define the concept of the Access Network (AN) which may 401 also support enhanced mobility. It is possible that to support 402 routing and QoS for mobile nodes, existing routing protocols (i.e., 403 OSPF or other standard IGPs) may not be appropriate to maintain 404 forwarding information for these mobile nodes as they change their 405 points of attachment to the Access Network. These new functions are 406 implemented in routers with additional capability. We can 407 distinguish three types of Access Network components: Access Routers 408 (AR) which handle the last hop to the mobile, typically over a 409 wireless link; Access Network Gateways (ANG) which form the boundary 410 on the fixed network side and shield the fixed network from the 411 specialized routing protocols; and (optionally) other internal Access 412 Network Routers which may also be needed in some cases to support the 413 protocols. The Access Network consists of the equipment needed to 414 support this specialized routing, i.e. AR/ANG/ANR. AR and ANG may be 415 the same physical nodes. 417 Note: this reference architecture is not well suited for people 418 dealing with MANETs. 420 --- ------ ------- | 421 --- | <--> | | -------| AR | -------------------| | | 422 | |--[] --- /------ \ /| ANG |--| 423 --- AP / \ / | | | 424 MN / \ / ------- | 425 (+wireless ___ / ------- | 426 device) | |---- | ANR | | 427 --- ------- | 428 AP / \ | 429 / \ ------- | 430 --- ------ / \| | | 431 | |-------| AR |---------------------| ANG |--| 432 --- ------ | | | 433 AP ------- | 434 | 435 Access Network (AN) 1 | 436 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| 437 Access Network (AN) 2 | 438 | 439 | 440 --- ------ ------- | 441 --- |<--> | | -------| AR | -------------------| | | 442 | |--[] --- /------ /| ANG |--| 443 --- AP / / | | | 444 MN / / ------- | 445 (+wireless ___ / / | 446 device) | |---- / | 447 --- / | 448 AP / | 449 / | 450 --- ------ ------- | 451 --- | I<--> | |-------| AR |---------| ANR | | 452 | |--| ------ --- \ ------ ------- | 453 --- |--| MR | AP \ / | 454 MNN | ------ \ / | 455 | --- \ ------ / | 456 --- | | |-------| AR |------- | 457 | |--| --- ------ | 458 --- | AP | 459 MNN 461 Figure 1: Reference Network Architecture 463 Mobile Node (MN) 465 An IP node capable of changing its point of attachment to the 466 network. A Mobile Node may have routing functionality. 468 Mobile Host (MH) 470 A mobile node that is an end host and not a router. 472 Access Link (AL) 474 A last-hop link between a Mobile Node and an Access Router. That 475 is, a facility or medium over which an Access Point and the 476 Mobile Node can communicate at the link layer, i.e., the layer 477 immediately below IP. 479 Access Point (AP) 481 An Access Point is a layer 2 device which is connected to one or 482 more Access Routers and offers the wireless link connection to 483 the Mobile Node. Access Points are sometimes called base 484 stations or access point transceivers. An Access Point may be a 485 separate entity or co-located with an Access Router. 487 Radio Cell 489 The geographical area within which an Access Point provides radio 490 coverage, i.e. where radio communication between a Mobile Node 491 and the specific Access Point is possible. 493 Access Network Router (ANR) 495 An IP router in the Access Network. An Access Network Router may 496 include Access Network specific functionalities, for example, 497 related to mobility and/or QoS. This is to distinguish between 498 ordinary routers and routers that have Access Network-related 499 special functionality. 501 Access Router (AR) 503 An Access Network Router residing on the edge of an Access 504 Network and connected to one or more Access Points. The Access 505 Points may be of different technology. An Access Router offers 506 IP connectivity to Mobile Nodes, acting as a default router to 507 the Mobile Nodes it is currently serving. The Access Router may 508 include intelligence beyond a simple forwarding service offered 509 by ordinary IP routers. 511 Access Network Gateway (ANG) 513 An Access Network Router that separates an Access Network from 514 other IP networks, much in the same way as an ordinary gateway 515 router. The Access Network Gateway looks to the other IP networks 516 like a standard IP router. 518 Access Network (AN) 520 An IP network which includes one or more Access Network Routers. 522 Administrative Domain (AD) 524 A collection of networks under the same administrative control 525 and grouped together for administrative purposes. [5] 527 Serving Access Router (SAR) 529 The Access Router currently offering the connectivity to the 530 Mobile Host. This is usually the point of departure for the 531 Mobile Node as it makes its way towards a new Access Router (then 532 Serving Access Router takes the role of the Old Access Router). 533 There may be several Serving Access Routers serving the Mobile 534 Node at the same time. 536 Old Access Router (OAR) 538 An Access Router that offered connectivity to the Mobile Node 539 prior to a handover. This is the Serving Access Router that will 540 cease or has ceased to offer connectivity to the Mobile Node. 542 New Access Router (NAR) 544 The Access Router that offers connectivity to the Mobile Node 545 after a handover. 547 Previous Access Router (PAR) 549 An Access Router that offered connectivity to the Mobile Node 550 prior to a handover. This is the Serving Access Router that will 551 cease or has ceased to offer connectivity to the Mobile Node. 552 Same as OAR. 554 Candidate Access Router (CAR) 556 An Access Router to which the Mobile Node may do a handoff. 558 4. Handover Terminology 560 These terms refer to different perspectives and approaches to 561 supporting different aspects of mobility. Distinctions can be made 562 according to the scope, range overlap, performance characteristics, 563 diversity characteristics, state transitions, mobility types, and 564 control modes of handover techniques. 566 Roaming 568 An operator-based term involving formal agreements between 569 operators that allows a mobile to get connectivity from a foreign 570 network. Roaming (a particular aspect of user mobility) 571 includes, for example, the functionality by which users can 572 communicate their identity to the local AN so that inter-AN 573 agreements can be activated and service and applications in the 574 MN's home network can be made available to the user locally. 576 Handover 578 (also known as handoff) the process by which an active MN (in the 579 Active State, see section 4.6) changes its point of attachment to 580 the network, or when such a change is attempted. The access 581 network may provide features to minimize the interruption to 582 sessions in progress. 584 There are different types of handover classified according to 585 different aspects involved in the handover. Some of this 586 terminology follows the description of [4]. 588 4.1. Scope of Handover 590 Note: the definitions of horizontal and vertical handover are 591 different than the ones commonly used today. These definitions try to 592 look at the handover from the IP layer's point of view; the IP layer 593 works with network interfaces, rather than specific technologies used 594 by those interfaces. 596 Layer 2 Handover 598 When a MN changes APs (or some other aspect of the radio channel) 599 connected to the same AR's interface then a layer 2 handover 600 occurs. This type of handover is transparent to the routing at 601 the IP layer (or it appears simply as a link layer 602 reconfiguration without any mobility implications). 604 Intra-AR Handover 606 A handover which changes the AR's network interface to the 607 mobile. That is, the Serving AR remains the same but routing 608 changes internal to the AR take place. 610 Intra-AN Handover 612 When the MN changes ARs inside the same AN then this handover 613 occurs. Such a handover is not necessarily visible outside the 614 AN. In case the ANG serving the MN changes, this handover is seen 615 outside the AN due to a change in the routing paths. Note that 616 the ANG may change for only some of the MN's data flows. 618 Inter-AN Handover 620 When the MN moves to a new AN then this handover occurs. This 621 requires some sort of host mobility across ANs, which typically 622 is be provided by the external IP core. Note that this would 623 have to involve the assignment of a new IP access address (e.g., 624 a new care-of address [9]) to the MN. 626 Intra-technology Handover 628 A handover between equipment of the same technology. 630 Inter-technology Handover 632 A handover between equipment of different technologies. 634 Horizontal Handover 636 A handover in which the mobile node's network interface does not 637 change (from the IP point of view); the MN communicates with the 638 access network via the same network interface before and after 639 the handover. A horizontal handover is typically also an intra- 640 technology handover but it can be an inter-technology handover if 641 the MN can do a layer 2 handover between two different 642 technologies without changing the network interface seen by the 643 IP layer. 645 Vertical Handover 647 In a vertical handover the mobile node's network interface to the 648 Access Network changes. A vertical handover is typically an 649 inter-technology handover but it may also be an intra- technology 650 handover if the MN has several network interfaces of the same 651 type. That is, after the handover, the IP layer communicates with 652 the Access Network through a different network interface. 654 The different handover types defined in this section and in section 655 4.1 have no direct relationship. In particular, a MN can do an 656 intra-AN handover of any of the types defined above. 658 Note that the horizontal and vertical handovers are not tied to a 659 change in the link layer technology. They define whether, after a 660 handover, the IP packet flow goes through the same (horizontal 661 handover) or a different (vertical handover) network interface. 662 These two handovers do not define whether the AR changes as a result 663 of a handover. 665 4.2. Handover Control 667 A handover must be one of the following two types (a): 669 Mobile-initiated Handover 671 the MN is the one that makes the initial decision to initiate the 672 handover. 674 Network-initiated Handover 676 the network makes the initial decision to initiate the handover. 678 A handover is also one of the following two types (b): 680 Mobile-controlled Handover (MCHO) 682 the MN has the primary control over the handover process. 684 Network-controlled Handover (NCHO) 685 the network has the primary control over the handover process. 687 A handover may also be either of these three types (c): 689 Mobile-assisted handover 691 information and measurement from the MN are used by the AR to 692 decide on the execution of a handover. 694 Network-assisted handover 696 a handover where the AN collects information that can be used by 697 the MN in a handover decision. 699 Unassisted handover 701 a handover where no assistance is provided by the MN or the AR to 702 each other. 704 A handover is also one of the following two types (d): 706 Backward handover 708 a handover either initiated by the OAR, or where the MN initiates 709 a handover via the OAR. 711 Forward handover 713 a handover either initiated by the NAR, or where the MN initiates 714 a handover via the NAR. 716 The handover is also either proactive or reactive (e): 718 Planned handover 720 a proactive (expected) handover where some signalling can be done 721 in advance of the MN getting connected to the new AR, e.g. 722 building a temporary tunnel from the old AR to the new AR. 724 Unplanned handover 726 a reactive (unexpected) handover, where no signalling is done in 727 advance of the MN's move of the OAR to the new AR. 729 The five handover types (a-e) are mostly independent, and every 730 handover should be classiable according to each of these types. 732 4.3. Simultaneous connectivity to Access Routers 734 Make-before-break (MBB) 736 During a MBB handover the MN can communicate simultaneously with 737 the old and new AR. This should not be confused with "soft 738 handover" which relies on macro diversity. 740 Break-before-make (BBM) 742 During a BBM handover the MN cannot communicate simultaneously 743 with the old and the new AR. 745 4.4. Performance and Functional Aspects 747 Handover Latency 749 Handover latency is the time difference between when a MN is last 750 able to send and/or receive an IP packet by way of the OAR, until 751 when the MN is able to send and/or receive an IP packet through 752 the NAR. Adapted from [4]. 754 Smooth handover 756 A handover that aims primarily to minimize packet loss, with no 757 explicit concern for additional delays in packet forwarding. 759 Fast handover 761 A handover that aims primarily to minimize delay, with no 762 explicit interest in packet loss. 764 Seamless handover 766 A handover in which there is no change in service capability, 767 security, or quality. In practice, some degradation in service 768 is to be expected. The definition of a seamless handover in the 769 practical case should be that other protocols, applications, or 770 end users do not detect any change in service capability, 771 security or quality, which would have a bearing on their (normal) 772 operation. See [7] for more discussion on the topic. 774 Throughput 776 The amount of data from a source to a destination processed by 777 the protocol for which throughput is to be measured for instance, 778 IP, TCP, or the MAC protocol. The throughput differs between 779 protocol layers. 781 Goodput 783 The total bandwidth used, less the volume of control messages and 784 protocol overhead from the data packets. 786 Pathloss 788 A reduction in signal strength caused by traversing the physical 789 medium constituting the link. 791 Hidden-terminal problem 793 The problem whereby a transmitting node can fail in its attempt 794 to transmit data because of destructive interference which is 795 only detectable at the receiving node, not the transmitting node. 797 Exposed terminal problem 799 The problem whereby a transmitting node prevents another node 800 from transmitting although it could have safely transmitted to 801 anyone else but that node. 803 4.5. Micro Diversity, Macro Diversity, and IP Diversity 805 Certain air interfaces (e.g. UTRAN FDD mode) require or at least 806 support macro diversity combining. Essentially, this refers to the 807 fact that a single MN is able to send and receive over two 808 independent radio channels ('diversity branches') at the same time; 809 the information received over different branches is compared and that 810 from the better branch passed to the upper layers. This can be used 811 both to improve overall performance, and to provide a seamless type 812 of handover at layer 2, since a new branch can be added before the 813 old is deleted. See also [6]. 815 It is necessary to differentiate between combining/diversity that 816 occurs at the physical and radio link layers, where the relevant unit 817 of data is the radio frame, and that which occurs at layer 3, the 818 network layer, where what is considered is the IP packet itself. 820 In the following definitions micro- and macro diversity refer to 821 protocol layers below the network layer, and IP diversity refers to 822 the network layer. 824 Micro diversity 826 for example, two antennas on the same transmitter send the same 827 signal to a receiver over a slightly different path to overcome 828 fading. 830 Macro diversity 832 Duplicating or combining actions taking place over multiple APs, 833 possibly attached to different ARs. This may require support 834 from the network layer to move the radio frames between the base 835 stations and a central combining point. 837 IP diversity 839 the splitting and combining of packets at the IP level. 841 4.6. Paging, and Mobile Node States and Modes 843 Mobile systems may employ the use of MN states in order to operate 844 more efficiently without degrading the performance of the system. The 845 term 847 A MN is always in one of the following three states: 849 Active State 851 when the AN knows the MN's SAR and the MN can send and receive IP 852 packets. The AL may not be active, but the radio layer is able 853 to establish one without assistance from the network layer. The 854 MN has an IP address assigned. 856 Dormant State 858 A state in which the mobile restricts its ability to receive 859 normal IP traffic by reducing its monitoring of radio channels. 860 The AN knows the MH's Paging Area, but the MH has no SAR and so 861 packets cannot be delivered to the MH without the AN initiating 862 paging. 864 Time-slotted Dormant Mode 866 A dormant mode implementation in which the mobile alternates 867 between periods of not listening for any radio traffic and 868 listening for traffic. Time-slotted dormant mode 869 implementations are typically synchronized with the network so 870 the network can deliver traffic to the mobile during listening 871 periods. 873 Inactive State 875 the MH is in neither the Active nor Dormant State. The host is no 876 longer listening for any packets, not even periodically, and not 877 sending packets. The host may be in a powered off state, it may 878 have shut down all interfaces to drastically conserve power, or 879 it may be out of range of a radio access point. The MN does not 880 necessarily have an IP access address from the AN. 882 Note: in fact, as well as the MN being in one of these three states, 883 the AN also stores which state it believes the MN is in. Normally 884 these are consistent; the definitions above assume so. 886 Here are some additional definitions for paging, taking into account 887 the above state definitions. 889 Paging 891 a procedure initiated by the Access Network to move an Idle MN 892 into the Active State. As a result of paging, the MN establishes 893 a SAR and the IP routes are set up. 895 Location updating 897 a procedure initiated by the MN, by which it informs the AN that 898 it has moved into a new paging area. 900 Paging Area 902 A part of the Access Network, typically containing a number of 903 ARs/APs, which corresponds to some geographical area. The AN 904 keeps and updates a list of all the Idle MNs present in the area. 905 If the MN is within the radio coverage of the area it will be 906 able to receive paging messages sent within that Paging Area. 908 Paging Area Registrations 910 Signaling from a dormant mode mobile node to the network, by 911 which it establishes its presence in a new paging area. Paging 912 Area Registrations thus enable the network to maintain a rough 913 idea of where the mobile is located. 915 Paging Channel 917 A radio channel dedicated to signaling dormant mode mobiles for 918 paging purposes. By current practice, the protocol used on a 919 paging channel is usually dictated by the radio link protocol, 920 although some paging protocols have provision for carrying 921 arbitrary traffic (and thus could potentially be used to carry 922 IP). 924 Traffic Channel 926 The radio channel on which IP traffic to an active mobile is 927 typically sent. This channel is used by a mobile that is 928 actively sending and receiving IP traffic, and is not 929 continuously active in a dormant mode mobile. For some radio 930 link protocols, this may be the only channel available. 932 4.7. Context Transfer 934 Context 936 The information on the current state of a routing-related service 937 required to re-establish the routing-related service on a new 938 subnet without having to perform the entire protocol exchange 939 with the mobile host from scratch. 941 Feature context 943 The collection of information representing the context for a 944 given feature. The full context associated with a mobile host is 945 the collection of one or more feature contexts. 947 Context transfer 948 The movement of context from one router or other network entity 949 to another as a means of re-establishing routing related services 950 on a new subnet or collection of subnets. 952 Routing-related service 954 A modification to the default routing treatment of packets to and 955 from the mobile host. Initially establishing routing-related 956 services usually requires a protocol exchange with the mobile 957 host. An example of a routing-related service is header 958 compression. The service may also be indirectly related to 959 routing, for example, security. Security may not affect the 960 forwarding decision of all intermediate routers, but a packet may 961 be dropped if it fails a security check (can't be encrypted, 962 authentication failed, etc.). Dropping the packet is basically a 963 routing decision. 965 4.8. Candidate Access Router Discovery 967 Capability of AR 969 A characteristic of the service offered by an AR that may be of 970 interest to an MN when the AR is being considered as a handoff 971 candidate. 973 Candidate AR (CAR) 975 An AR to which MN has a choice of performing IP-level handoff. 976 This means that MN has the right radio interface to connect to an 977 AP that is served by this AR, as well as the coverage of this AR 978 overlaps with that of the AR to which MN is currently attached 979 to. 981 Target AR (TAR) 983 An AR with which the procedures for the MN's IP-level handoff are 984 initiated. TAR is selected after running a TAR Selection 985 Algorithm that takes into account the capabilities of CARs, 986 preferences of MN and any local policies. 988 4.9. User, Personal and Host Mobility 990 Different sorts of mobility management may be required of a mobile 991 system. We can differentiate between user, personal and host 992 mobility. 994 User mobility 996 refers to the ability of a user to access services from different 997 physical hosts. This usually means, the user has an account on 998 these different hosts or that a host does not restrict users from 999 using the host to access services. 1001 Personal mobility 1003 complements user mobility with the ability to track the user's 1004 location and provide the user's current location to allow 1005 sessions to be initiated by and towards the user by anyone on any 1006 other network. Personal mobility is also concerned with enabling 1007 associated security, billing and service subscription 1008 authorization made between administrative domains. 1010 Host mobility 1012 refers to the function of allowing a mobile host to change its 1013 point of attachment to the network, without interrupting IP 1014 packet delivery to/from that host. There may be different sub- 1015 functions depending on what the current level of service is being 1016 provided; in particular, support for host mobility usually 1017 implies active and idle modes of operation, depending on whether 1018 the host has any current sessions or not. Access Network 1019 procedures are required to keep track of the current point of 1020 attachment of all the MNs or establish it at will. Accurate 1021 location and routing procedures are required in order to maintain 1022 the integrity of the communication. Host mobility is often 1023 called 'terminal mobility'. 1025 Two subcategories of "Host mobility" can be identified: 1027 Global mobility 1029 Same as Macro mobility. 1031 Local mobility 1033 Same as Micro mobility. 1035 Macro mobility 1037 Mobility over a large area. This includes mobility support and 1038 associated address registration procedures that are needed when a 1039 mobile host moves between IP domains. Inter-AN handovers 1040 typically involve macro-mobility protocols. Mobile-IP can be 1041 seen as a means to provide macro mobility. 1043 Micro mobility 1045 Mobility over a small area. Usually this means mobility within 1046 an IP domain with an emphasis on support for active mode using 1047 handover, although it may include idle mode procedures also. 1048 Micro-mobility protocols exploit the locality of movement by 1049 confining movement related changes and signalling to the access 1050 network. 1052 Local Mobility Management 1054 Local Mobility Management (LMM) is a generic term for protocols 1055 dealing with IP mobility management confined within the access 1056 network. LMM messages itself are not routed outside the access 1057 network, although, a handover may trigger Mobile IP messages to 1058 be sent to correspondent nodes and home agents. 1060 5. Specific Terminology for Mobile Ad-Hoc Networking 1062 Cluster 1064 A group of nodes located within close physical proximity, 1065 typically all within range of one another, which can be grouped 1066 together for the purpose of limiting the production and 1067 propogation of routing information. 1069 Cluster head 1071 A cluster head is a node (often elected in the cluster formation 1072 process) that has complete knowledge about group membership and 1073 link state information in the cluster. Each cluster should have 1074 one and only one cluster head. 1076 Cluster member 1078 All nodes within a cluster EXCEPT the cluster head are called 1079 members of that cluster. 1081 Convergence 1083 The process of approaching a state of equilibrium in which all 1084 nodes in the network agree on a consistent collection of state 1085 about the topology of the network, and in which no further 1086 control messages are needed to establish the consistency of the 1087 network topology. 1089 Convergence time 1091 The time which is required for a network to reach convergence 1092 after an event (typically, the movement of a mobile node) which 1093 changes the network topology. 1095 Laydown 1097 The relative physical location of the nodes within the ad hoc 1098 network. 1100 Pathloss matrix 1102 A matrix of coefficients describing the pathloss between any two 1103 nodes in an ad hoc network. When the links are asymmetric, the 1104 matrix is also asymmetric. 1106 Scenario 1107 The tuple 1108 characterizing a class of ad hoc networks. 1110 6. Mobile Networks 1112 This section presents a few basic terms about mobile networks. A more 1113 thorough discussion on mobile networks can be found in the working 1114 group documents of the NEMO Working Group [13]. 1116 Mobile Network 1118 An entire network, moving as a unit, which dynamically changes 1119 its point of attachment to the Internet and thus its reachability 1120 in the topology. The mobile network is connected to the global 1121 Internet via one or more mobile router(s). The internal 1122 configuration of the mobile network is assumed to be relatively 1123 stable with respect to the MR and is not a matter of concern. 1125 Mobile Router (MR) 1127 A router which is capable of changing its point of attachment to 1128 IP networks, moving from one link to another link. A mobile 1129 router is capable of forwarding packets between two or more 1130 interfaces, and possibly running a dynamic routing protocol 1131 modifying the state by which to do packet forwarding. 1133 Mobile Network Node (MNN) 1135 Any host or router located within the mobile network, either 1136 permanently or temporarily. A Mobile Network Node may be a Mobile 1137 Router. 1139 7. Security-related Terminology 1141 1145 The following were in the previous versions of this document: 1147 Mobility Security Association 1149 A collection of security contexts, between a pair IP nodes, each 1150 of which is configured to be applied to mobility-related protocol 1151 messages exchanged between them. Mobility security associations 1152 MAY be stored separately from the node's IPsec Security Policy 1153 Database (SPD). 1155 Security Context 1157 A security context between two routers defines the manner in 1158 which two routers choose to mutually authentication each other, 1159 and indicates an authentication algorithm and mode. 1161 Security Parameter Index (SPI) 1163 An index identifying a security context between a pair of routers 1164 among the contexts possible in the mobility security association. 1166 8. Security Considerations 1168 There are no security issues in this document. 1170 9. Contributors 1172 This draft was initially based on the work of 1174 o Tapio Suihko, VTT Information Technology, Finland 1176 o Phil Eardley and Dave Wisely, BT, UK 1178 o Robert Hancock, Siemens/Roke Manor Research, UK, 1180 o Nikos Georganopoulos, King's College London 1182 o Markku Kojo and Jukka Manner, University of Helsinki, Finland. 1184 Since revision -02 of the document draft-manner-seamoby-terms-02.txt, 1185 Charles Perkins has given as input terminology related to ad-hoc 1186 networks. 1188 10. Acknowledgement 1190 This work has been partially performed in the framework of the IST 1191 project IST-2000-28584 MIND, which is partly funded by the European 1192 Union. The authors would like to acknowledge the help of their 1193 colleagues in preparing this document. 1195 Some definitions of terminology have been adapted from [1], [7], [3], 1196 [2], [4], [9], [10], [11], [12] and [13]. 1198 11. References 1200 [1] D. Blair, A. Tweedly, M. Thomas, J. Trostle, and 1201 M. Ramalho. Realtime Mobile IPv6 Framework (work in 1202 progress). Internet Draft, Internet Engineering Task Force. 1203 draft-blair-rt-mobileipv6-seamoby-00.txt, November 2000. 1205 [2] P. Calhoun, G. Montenegro, and C. Perkins. Mobile IP 1206 Regionalized Tunnel Management (work in progress). Internet 1207 Draft, Internet Engineering Task Force, November 1998. 1209 [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1210 Specification. Request for Comments (Draft Standard) 2460, 1211 Internet Engineering Task Force, December 1998. 1213 [4] G. Dommety (ed.). Fast Handovers for Mobile IPv6 (work 1214 in progress). draft-ietf-mobileip-fast-mipv6-05.txt, 1215 September, 2002. 1217 [5] Yavatkar et al. A Framework for Policy-based Admission 1218 Control. Request for Comments 2753, Internet Engineering Task 1219 Force, January 2000. 1221 [6] J. Kempf, P. McCann, and P. Roberts. IP Mobility and the CDMA 1222 Radio Access Network: Applicability Statement for Soft Handoff 1223 (work in progress). Internet Draft, 1224 draft-kempf-cdma-appl-00.txt, July 2000. 1226 [7] J. Kempf (ed.). Problem Description: Reasons For Doing 1227 Context Transfers Between Nodes in an IP Access Network. 1228 RFC 3374, Internet Engineering Task Force, September, 2002. 1230 [8] R. Pandya. Emerging Mobile and Personal Communication Systems. 1231 IEEE Communications Magazine, 33:44--52, June 1995. 1233 [9] C. Perkins. IP Mobility Support. Request for Comments 1234 (Proposed Standard) 2002, Internet Engineering Task Force, 1235 October 1996. 1237 [10] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, and 1238 L. Salgarelli. IP micro-mobility support using HAWAII (work in 1239 progress). Internet Draft, Internet Engineering Task Force, 1240 June 1999. 1242 [11] D. Trossen, G. Krishnamurthi, H. Chaskar, J. Kempf, "Issues in 1243 candidate access router discovery for seamless IP-level 1244 handoffs. Internet Draft (work in progress), 1245 draft-ietf-seamoby-cardiscovery-issues-04.txt, October 2002. 1247 [12] David B. Johnson, Charles E. Perkins, Jari Arkko, "Mobility 1248 Support in IPv6". Internet Draft, 1249 draft-ietf-mobileip-ipv6-18.txt (work in progress), June 2002. 1251 [13] Thierry Ernst and Hong-Yon Lach, "Network Mobility Support 1252 Terminology". Internet Draft, 1253 draft-ernst-monet-terminology-01.txt (work in progress), July 1254 2002. 1256 12. Author's Addresses 1258 Questions about this document may be directed to: 1260 Jukka Manner 1261 Department of Computer Science 1262 University of Helsinki 1263 P.O. Box 26 (Teollisuuskatu 23) 1264 FIN-00014 HELSINKI 1265 Finland 1267 Voice: +358-9-191-44210 1268 Fax: +358-9-191-44441 1269 E-Mail: jmanner@cs.helsinki.fi 1271 Markku Kojo 1272 Department of Computer Science 1273 University of Helsinki 1274 P.O. Box 26 (Teollisuuskatu 23) 1275 FIN-00014 HELSINKI 1276 Finland 1278 Voice: +358-9-191-44179 1279 Fax: +358-9-191-44441 1280 E-Mail: kojo@cs.helsinki.fi 1282 Charles E. Perkins 1283 Communications Systems Lab 1284 Nokia Research Center 1285 313 Fairchild Drive 1286 Mountain View, California 94043 1287 USA 1288 Phone: +1-650 625-2986 1289 E-Mail: charliep@iprg.nokia.com 1290 Fax: +1 650 625-2502 1292 Tapio Suihko 1293 VTT Information Technology 1294 P.O. Box 1203 1295 FIN-02044 VTT 1296 Finland 1298 Voice: +358-9-456-6078 1299 Fax: +358-9-456-7028 1300 E-Mail: tapio.suihko@vtt.fi 1301 Phil Eardley 1302 BTexaCT 1303 Adastral Park 1304 Martlesham 1305 Ipswich IP5 3RE 1306 United Kingdom 1308 Voice: +44-1473-645938 1309 Fax: +44-1473-646885 1310 E-Mail: philip.eardley@bt.com 1312 Dave Wisely 1313 BTexaCT 1314 Adastral Park 1315 Martlesham 1316 Ipswich IP5 3RE 1317 United Kingdom 1319 Voice: +44-1473-643848 1320 Fax: +44-1473-646885 1321 E-Mail: dave.wisely@bt.com 1323 Robert Hancock 1324 Roke Manor Research Ltd 1325 Romsey, Hants, SO51 0ZN 1326 United Kingdom 1328 Voice: +44-1794-833601 1329 Fax: +44-1794-833434 1330 E-Mail: robert.hancock@roke.co.uk 1332 Nikos Georganopoulos 1333 King's College London 1334 Strand 1335 London WC2R 2LS 1336 United Kingdom 1338 Voice: +44-20-78482889 1339 Fax: +44-20-78482664 1340 E-Mail: nikolaos.georganopoulos@kcl.ac.uk) 1342 13. Appendix A - Examples 1344 This appendix provides examples for the terminology presented. 1346 A.1. Mobility 1348 Host mobility is logically independent of user mobility, although in 1349 real networks, at least the address management functions are often 1350 required to initially attach the host to the network. In addition, 1351 if the network wishes to determine whether access is authorized (and 1352 if so, who to charge for it), then this may be tied to the identity 1353 of the user of the terminal. 1355 An example of user mobility would be a campus network, where a 1356 student can log into the campus network from several workstations and 1357 still retrieve files, emails, and other services automatically. 1359 Personal mobility support typically amounts to the maintenance and 1360 update of some sort of address mapping database, such as a SIP server 1361 or DNS server; it is also possible for the personal mobility support 1362 function to take a part in forwarding control messages between end 1363 user and correspondent rather than simply acting as a database. SIP 1364 is a protocol for session initiation in IP networks. It includes 1365 registration procedures which partially support personal mobility 1366 (namely, the ability for the network to route a session towards a 1367 user at a local IP address). 1369 Personal mobility has been defined in [8] as "the ability of end 1370 users to originate and receive calls and access subscribed 1371 telecommunication services on any terminal in any location, and the 1372 ability of the network to identify end users as they move. Personal 1373 mobility is based on the use of a unique personal identity (i.e., 1374 personal number)." 1376 Roaming, in its original (GSM) sense, is the ability of a user to 1377 connect to the networks owned by operators other than the one having 1378 a direct formal relationship with the user. More recently (e.g., in 1379 data networks and UMTS) it also refers providing user-customized 1380 services in foreign networks (e.g., QoS profiles for specific 1381 applications). 1383 HAWAII, Cellular IP, Regional Registration and EMA are examples of 1384 micro mobility schemes, with the assumption that Mobile IP is used 1385 for macro mobility. 1387 WLAN technologies such as IEEE 802.11 typically support aspects of 1388 user and host mobility in a minimal way. User mobility procedures 1389 (for access control and so on) are defined only over the air 1390 interface (and the way these are handled within the network is not 1391 further defined). 1393 PLMNs (GSM/UMTS) typically have extensive support for both user and 1394 host mobility. Complete sets of protocols (both over the air and on 1395 the network side) are provided for user mobility, including 1396 customized service provision. Handover for host mobility is also 1397 supported, both within access networks, and also within the GSM/UMTS 1398 core network for mobility between access networks of the same 1399 operator. 1401 A.2. Handovers 1403 A hard handover is required where a MN is not able to receive or send 1404 traffic from/to two APs simultaneously. In order to move the traffic 1405 channel from the old to the new access point the MN abruptly changes 1406 the frequency/timeslot/code on which it is transmitting and listening 1407 to new values associated with a new access point. Thus, the handover 1408 is a break-before-make handover. 1410 A good example of hard handover is GSM where the mobile listens for 1411 new base stations, reports back to the network the signal strength 1412 and identity of the new base station(s) heard. When the old base 1413 station decides that a handover is required it instructs the new base 1414 station to set up resources and, when confirmed, instructs the mobile 1415 to switch to a new frequency and time slot. This sort of hand over 1416 is called hard, mobile assisted, network initiated and backward 1417 (meaning that the old base station is responsible for handling the 1418 change-over). 1420 In a TDMA system, such as GSM, the hard hand over is delayed until 1421 the mobile has moved well within the coverage of the new base 1422 station. If the handover threshold was set to the point where the 1423 new base station signal exceeded the old then there would be a very 1424 large number of handovers as the mobile moved through the region 1425 between the cells and radio signals fluctuated, this would create a 1426 large signalling traffic. To avoid this a large hysteresis is set, 1427 i.e. the new base station must be (say) 10dB stronger for handover 1428 to occur. If the same was done in W-CDMA then the mobile would be 1429 transmitting a powerful signal to the old base station and creating 1430 interference for other users, since in CDMA everyone else's 1431 transmissions are seen as noise, thus reducing capacity. To avoid 1432 this soft handover is used, giving an estimated doubling in capacity. 1433 Support for soft handover (in a single mode terminal) is 1434 characteristic of radio interfaces which also require macro diversity 1435 for interference limitation but the two concepts are logically 1436 independent. 1438 A good example of soft handover is the UTRAN FDD mode. W-CDMA is 1439 particularly suited to soft handover because of the design of the 1440 receivers and transmitters: typically a rake receiver will be used 1441 to overcome the multi-path fading of the wide-band channel. Rake 1442 receivers have a number of so-called fingers, each effectively 1443 separate detectors, that are tuned to the same signal (e.g. 1444 spreading code) but delayed by different times. When the delay times 1445 are correctly adjusted and the various components properly combined 1446 (this is micro diversity combining) the effect of multi-path fading 1447 is removed. The rake receiver can also be used to detect signals 1448 from different transmitters by tuning the fingers to different 1449 spreading codes. Soft handover is used in UTRAN FDD mode to also 1450 increase capacity. 1452 Every handover can be seen as a context-aware Handover. In PLMNs the 1453 context to be fulfilled is that the new AP can accommodate the new 1454 mobile, for example, the new GSM cell can serve the incoming phone. 1455 Lately, the notion of Context-aware Handovers has been enlarged by, 1456 for example, QoS-aware handovers, meaning that the handover is 1457 governed by the need to support the QoS-context of the moving mobile 1458 in order to keep the service level assured to the user of the MN. 1460 A.3. Diversity combining 1462 In the case of UMTS it is radio frames that are duplicated at some 1463 point in the network (the serving RNC) and sent to a number of 1464 basestations and, possibly via other (drift) RNCs. The combining 1465 that takes place at the serving RNC in the uplink direction is 1466 typically based on some simple quality comparison of the various 1467 received frames, which implies that the various copies of these 1468 frames must contain identical upper layer information. The serving 1469 RNC also has to do buffering data frames to take account of the 1470 differing time of flight from each basestation to the RNC. 1472 A.4. Miscellaneous 1474 In a GPRS/UMTS system the Access Network Gateway node could be the 1475 GGSN component. The ANG can provide support for mobility of hosts, 1476 admission control, policy enforcement, and Foreign Agent 1477 functionality [9]. 1479 When presenting a mobile network topology, APs and ARs are usually 1480 pictured as separate components (see Figure 1. This is the case with 1481 GSM/GPRS/UMTS presentations, for example. From the IP point of view 1482 APs are not directly visible. An AP should only be seen from the 1483 MN's or AR's IP layer as a link (interface) connecting MNs to the AR. 1485 When the mobile moves through the network, depending on the mobility 1486 mechanism, the OAR will forward packets destined to the old MNs 1487 address to the SAR which currently serves the MN. At the same time 1488 the handover mechanism may be studying CARs to find the best NAR 1489 where the MN will be handed next. 1491 14. Appendix B - Index of Terms 1493 1495 Full Copyright Statement 1497 Copyright (C) The Internet Society (2001). All Rights Reserved. 1499 This document and translations of it may be copied and furnished to 1500 others, and derivative works that comment on or otherwise explain it 1501 or assist in its implementation may be prepared, copied, published 1502 and distributed, in whole or in part, without restriction of any 1503 kind, provided that the above copyright notice and this paragraph are 1504 included on all such copies and derivative works. However, this 1505 document itself may not be modified in any way, such as by removing 1506 the copyright notice or references to the Internet Society or other 1507 Internet organizations, except as needed for the purpose of 1508 developing Internet standards in which case the procedures for 1509 copyrights defined in the Internet Standards process must be 1510 followed, or as required to translate it into languages other than 1511 English. 1513 The limited permissions granted above are perpetual and will not be 1514 revoked by the Internet Society or its successors or assigns. 1516 This document and the information contained herein is provided on an 1517 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1518 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1519 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1520 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1521 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.