idnits 2.17.1 draft-ietf-seamoby-mobility-terminology-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC3xxx' on line 1201 -- 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' ** Obsolete normative reference: RFC 3344 (ref. '14') (Obsoleted by RFC 5944) == Outdated reference: A later version (-05) exists of draft-ietf-mobileip-rfc3012bis-04 == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-aaa-key-10 -- Possible downref: Normative reference to a draft: ref. '16' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 12 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: September, 2003 University of Helsinki 5 March, 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 September, 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 -01 51 - Added security terminology 52 - Miscellaneous small refinements of definitions 54 Changes from -00 55 - Added definition for Routing Proxy 56 - Added basic terminology about mobile networks 57 - Added Link-Layer Trigger from FMIPv6 58 - Edited the CAR terminology section 59 - Added definitions for MPR, CoA, BU 60 - Changed the definition of Home Address 61 - Added a mobile network into Figure 1 62 - Edited the Network Components section 64 Table of Contents 66 1 Introduction ................................................. 2 67 2 General Terms ................................................ 3 68 3 Mobile Access Networks and Mobile Networks ................... 8 69 4 Handover Terminology ......................................... 12 70 4.1 Scope of Handover .......................................... 12 71 4.2 Handover Control ........................................... 14 72 4.3 Simultaneous connectivity to Access Routers ................ 15 73 4.4 Performance and Functional Aspects ......................... 15 74 4.5 Micro Diversity, Macro Diversity, and IP Diversity ......... 16 75 4.6 Paging, and Mobile Node States and Modes ................... 17 76 4.7 Context Transfer ........................................... 19 77 4.8 Candidate Access Router Discovery .......................... 19 78 4.9 User, Personal and Host Mobility ........................... 20 79 5 Specific Terminology for Mobile Ad-Hoc Networking ............ 21 80 6 Security-related Terminology ................................. 22 81 7 Security Considerations ...................................... 23 82 8 Contributors ................................................. 23 83 9 Acknowledgement .............................................. 24 84 10 References .................................................. 24 85 11 Author's Addresses .......................................... 26 86 12 Appendix A - Examples ....................................... 28 87 13 Appendix B - Index of Terms ................................. 30 89 1. Introduction 91 This document presents terminology to be used for documents and 92 discussions within the Seamoby Working Group. Other mobility related 93 working groups could like take advantage of this terminology, in 94 order to create a common terminology for the area of mobility in IP 95 networks. These groups would include MIP, MANET, ROHC and NEMO. 97 Some terms and their definitions that are not directly related to the 98 IP world are included for the purpose of harmonizing the terminology, 99 for example, 'Access Point' and 'base station' refer to the same 100 component, from the point of view of IP, but 'Access Router' has a 101 very different meaning. The presented terminology may also, it is 102 hoped, be adequate to cover mobile ad-hoc networks. 104 The proposed terminology is not meant to assert any new terminology. 105 Rather the authors would welcome discussion on more exact definitions 106 as well as missing or unnecessary terms. This work is a 107 collaborative enterprise between people from many different 108 engineering backgrounds and so already presents a first step in 109 harmonizing the terminology. 111 The terminology in this draft is divided into several sections. 112 First, there is a list of terms for general use and mobile access 113 networks followed by terms related to handovers, and finally some 114 terms used within the MANET and NEMO working group. 116 2. General Terms 118 Bandwidth 120 The total capacity of a link to carry information (typically 121 bits). 123 Bandwidth Utilization 125 The actual amount of information delivered over a link, expressed 126 as a percent of the available bandwidth on that link. 128 Beacon 130 A control message broadcast by a node (especially, a base 131 station) informing all the other nodes in its neighborhood of the 132 continuing presence of the broadcasting node, possibly along with 133 additional status or configuration information. 135 Binding update (BU) 137 A message indicating a mobile node's current mobility binding, 138 and in particular its care-of address. 140 Care-of Address (CoA) 142 An IP address associated with a mobile node while visiting a 143 foreign link; the subnet prefix of this IP address is a foreign 144 subnet prefix. Among the multiple care-of addresses that a 145 mobile node may have at any given time (e.g., with different 146 subnet prefixes), the one registered with the mobile node's home 147 agent is called its "primary" care-of address [12]. 149 Channel 151 A subdivision of the physical medium allowing possibly shared 152 independent uses of the medium. Channels may be made available 153 by subdividing the medium into distinct time slots, or distinct 154 spectral bands, or decorrelated coding sequences. 156 Channel Access Protocol 157 A protocol for mediating access to, and possibly allocation of, 158 the various channels available within the physical communications 159 medium. Nodes participating in the channel access protocol can 160 communicate only when they have uncontested access to the medium, 161 so that there will be no interference. 163 Control Message 165 Information passed between two or more network nodes for 166 maintaining protocol state, which may be unrelated to any 167 specific application. 169 Distance Vector 171 A style of routing protocol in which, for each desired 172 destination, a node maintains information about the distance to 173 that destination, and a vector (next hop) towards that 174 destination. 176 Fairness 178 A property of channel access protocols whereby a medium is made 179 fairly equal to all eligible nodes on the link. Fairness does 180 not strictly imply equality, especially in cases where nodes are 181 given link access according to unequal priority or 182 classification. 184 Flooding 186 The process of delivering data or control messages to every node 187 within the network under consideration. 189 Forwarding node 191 A node which performs the function of forwarding datagrams from 192 one of its neighbors to another. 194 Home Address 196 An IP address assigned to a mobile node, used as the permanent 197 address of the mobile node. This address is within the mobile 198 node's home link. Standard IP routing mechanisms will deliver 199 packets destined for a mobile node's home address to its home 200 link [12]. 202 Interface 204 A node's attachment to a link. 206 IP access address 207 An IP address (often dynamically allocated) which a node uses to 208 designate its current point of attachment to the local network. 209 The IP access address is typically to be distinguished from the 210 mobile node's home address; in fact, while visiting a foreign 211 network the former may be considered unsuitable for use as an 212 end-point address by any but the most short-lived applications. 213 Instead, the IP access address is typically used as the care-of 214 address of the node. 216 Link 218 A communication facility or physical medium that can sustain data 219 communications between multiple network nodes, such as an 220 Ethernet (simple or bridged). A link is the layer immediately 221 below IP. 223 Asymmetric Link 225 A link with transmission characteristics which are different 226 depending upon the relative position or design characteristics of 227 the transmitter and the receiver of data on the link. For 228 instance, the range of one transmitter may be much higher than 229 the range of another transmitter on the same medium. 231 Link Establishment 233 The process of establishing a link between the mobile node and 234 the local network. This may involve allocating a channel, or 235 other local wireless resources, possibly including a minimum 236 level of service or bandwidth. 238 Link-layer Trigger (L2 Trigger) 240 Information from L2 that informs L3 of the detailed events 241 involved in handover sequencing at L2. L2 triggers are not 242 specific to any particular L2, but rather represent 243 generalizations of L2 information available from a wide variety 244 of L2 protocols [4]. 246 Link State 248 A style of routing protocol in which every node within the 249 network is expected to maintain information about every link 250 within the network topology. 252 Link-level Acknowledgement 254 A protocol strategy, typically employed over wireless media, 255 requiring neighbors to acknowledge receipt of packets (typically 256 unicast only) from the transmitter. Such strategies aim to avoid 257 packet loss or delay resulting from lack of, or unwanted 258 characteristics of, higher level protocols. 260 Link-layer acknowledgements are often used as part of ARQ 261 algorithms for increasing link reliability. 263 Local Broadcast 264 The delivery of data to every node within range of the 265 transmitter. 267 Loop-free 269 A property of routing protocols whereby the path taken by a data 270 packet from source to destination never transits the same 271 intermediate node twice before arrival at the destination. 273 Medium-Access Protocol (MAC) 275 A protocol for mediating access to, and possibly allocation of, 276 the physical communications medium. Nodes participating in the 277 medium access protocol can communicate only when they have 278 uncontested access to the medium, so that there will be no 279 interference. When the physical medium is a radio channel, the 280 MAC is the same as the Channel Access Protocol. 282 Mobility Factor 284 The relative frequency of node movement, compared to the 285 frequency of application initiation. 287 Multipoint relay (MPR) 289 A node which is selected by its one-hop neighbor to re-transmit 290 all broadcast messages that it receives. The message must be new 291 and the time-to-live field of the message must be greater than 292 one. Multipoint relaying is a technique to reduce the number of 293 redundant re-transmissions while diffusing a broadcast message in 294 the network. 296 Neighbor 298 A "neighbor" is any other node to which data may be propagated 299 directly over the communications medium without relying the 300 assistance of any other forwarding node 302 Neighborhood 304 All the nodes which can receive data on the same link from one 305 node whenever it transmits data. 307 Next Hop 309 A neighbor which has been selected to forward packets along the 310 way to a particular destination. 312 Payload 314 The actual data within a packet, not including network protocol 315 headers which were not inserted by an application. Note, that 316 payloads are different between layers: user data is the payload 317 of TCP, which are the payload of IP, which three are the payload 318 of link layer protocols etc. Thus, it is important to identify 319 the scope when talking about payloads. 321 Prefix 323 A bit string that consists of some number of initial bits of an 324 address. 326 Route Table 328 The table where forwarding nodes keep information (including next 329 hop) for various destinations. 331 Route Entry 333 An entry for a specific destination (unicast or multicast) in the 334 route table. 336 Route Establishment 338 The process of determining a route between a source and a 339 destination. 341 Route Activation 343 The process of putting a route into use after it has been 344 determined. 346 Routing Proxy 348 A node that routes packets by overlays, eg. by tunneling, between 349 communicating partners. The Home Agent and Foreign Agent are 350 examples of routing proxies, in that they receive packets 351 destined for the mobile node and tunnel them to the current 352 address of the mobile node. 354 Signal Strength 356 The detectable power of the signal carrying the data bits, as 357 seen by the receiver of the signal. 359 Source Route 361 A source route from node A to node B is an ordered list of IP 362 addresses, starting with the IP address of node A and ending with 363 the IP address of the node B. Between A and B, the source route 364 includes an ordered list of all the intermediate hops between A 365 and B, as well as the interface index of the interface through 366 which the packet should be transmitted to reach the next hop. 368 Spatial re-use 370 Simultaneous use of channels with identical or close physical 371 characteristics, but located spatially far enough apart to avoid 372 interference (i.e., co-channel interference) 374 System-wide Broadcast 376 Same as flooding, but used in contrast to local broadcast. 378 Topology 380 A network can be viewed abstractly as a "graph" whose "topology" 381 at any point in time is defined by set of "points" connected by 382 (possibly directed) "edges." 384 Triggered Update 386 An unsolicited route update transmitted by an router along a path 387 to a destination. 389 3. Mobile Access Networks and Mobile Networks 391 In order to support host mobility a set of nodes towards the network 392 edge may need to have specific functions. Such a set of nodes form a 393 mobile access network that may or may not be part of the global 394 Internet. The Figure 1 presents two examples of such access network 395 topologies. The figure depicts a reference architecture which 396 illustrates an IP network with components defined in this section. 398 We intend to define the concept of the Access Network (AN) which may 399 also support enhanced mobility. It is possible that to support 400 routing and QoS for mobile nodes, existing routing protocols (i.e., 401 OSPF or other standard IGPs) may not be appropriate to maintain 402 forwarding information for these mobile nodes as they change their 403 points of attachment to the Access Network. These new functions are 404 implemented in routers with additional capability. We can distinguish 405 three types of Access Network components: Access Routers (AR) which 406 handle the last hop to the mobile, typically over a wireless link; 407 Access Network Gateways (ANG) which form the boundary on the fixed 408 network side and shield the fixed network from the specialized 409 routing protocols; and (optionally) other internal Access Network 410 Routers which may also be needed in some cases to support the 411 protocols. The Access Network consists of the equipment needed to 412 support this specialized routing, i.e. AR/ANG/ANR. AR and ANG may be 413 the same physical nodes. 415 In addition, we present a few basic terms on mobile networks, that 416 is, mobile network, mobile router (MR), and mobile network node 417 (MNN). A more thorough discussion on mobile networks can be found in 418 the working group documents of the NEMO Working Group [13]. 420 Note: this reference architecture is not well suited for people 421 dealing with MANETs. 423 --- ------ ------- | 424 --- | <--> | | -------| AR | -------------------| | | 425 | |--[] --- /------ \ /| ANG |--| 426 --- AP / \ / | | | 427 MH / \ / ------- | 428 (+wireless ___ / ------- | 429 device) | |---- | ANR | | 430 --- ------- | 431 AP / \ | 432 / \ ------- | 433 --- ------ / \| | | 434 | |-------| AR |---------------------| ANG |--| 435 --- ------ | | | 436 AP ------- | 437 | 438 Access Network (AN) 1 | 439 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| 440 Access Network (AN) 2 | 441 | 442 | 443 --- ------ ------- | 444 --- |<--> | | -------| AR | -------------------| | | 445 | |--[] --- /------ /| ANG |--| 446 --- AP / / | | | 447 MH / / ------- | 448 (+wireless ___ / / | 449 device) | |---- / | 450 --- / | 451 AP / | 452 / | 453 --- ------ ------- | 454 --- | I<--> | |-------| AR |---------| ANR | | 455 | |--| ------ --- \ ------ ------- | 456 --- |--| MR | AP \ / | 457 MNN | ------ \ / | 458 | --- \ ------ / | 459 --- | | |-------| AR |------- | 460 | |--| --- ------ | 461 --- | AP | 462 MNN 464 Figure 1: Reference Network Architecture 466 Mobile Node (MN) 468 An IP node capable of changing its point of attachment to the 469 network. A Mobile Node may or may not have forwarding 470 functionality. 472 Mobile Host (MH) 474 A mobile node that is an end host and not a router. A Mobile host 475 is capable of sending and receiving packets, that is, being a 476 source or destination of traffic, but not a forwarder of it. 478 Mobile Network 480 An entire network, moving as a unit, which dynamically changes 481 its point of attachment to the Internet and thus its reachability 482 in the topology. The mobile network is connected to the global 483 Internet via one or more mobile router(s). The internal 484 configuration of the mobile network is assumed to be relatively 485 stable with respect to the MR and is not a matter of concern. 487 Mobile Router (MR) 489 A router which is capable of changing its point of attachment to 490 IP networks, moving from one link to another link. A mobile 491 router is capable of forwarding packets between two or more 492 interfaces, and possibly running a dynamic routing protocol 493 modifying the state by which to do packet forwarding. 495 Mobile Network Node (MNN) 497 Any node (host or router) located within a mobile network, either 498 permanently or temporarily. A Mobile Network Node may be a Mobile 499 Router. 501 Access Link (AL) 503 A last-hop link between a Mobile Node and an Access Router. That 504 is, a facility or medium over which an Access Point and the 505 Mobile Node can communicate at the link layer, i.e., the layer 506 immediately below IP. 508 Access Point (AP) 510 An Access Point is a layer 2 device which is connected to one or 511 more Access Routers and offers the wireless link connection to 512 the Mobile Node. Access Points are sometimes called base 513 stations or access point transceivers. An Access Point may be a 514 separate entity or co-located with an Access Router. 516 Radio Cell 518 The geographical area within which an Access Point provides radio 519 coverage, i.e. where radio communication between a Mobile Node 520 and the specific Access Point is possible. 522 Access Network Router (ANR) 524 An IP router in the Access Network. An Access Network Router may 525 include Access Network specific functionalities, for example, 526 related to mobility and/or QoS. This is to distinguish between 527 ordinary routers and routers that have Access Network-related 528 special functionality. 530 Access Router (AR) 532 An Access Network Router residing on the edge of an Access 533 Network and connected to one or more Access Points. The Access 534 Points may be of different technology. An Access Router offers 535 IP connectivity to Mobile Nodes, acting as a default router to 536 the Mobile Nodes it is currently serving. The Access Router may 537 include intelligence beyond a simple forwarding service offered 538 by ordinary IP routers. 540 Access Network Gateway (ANG) 542 An Access Network Router that separates an Access Network from 543 other IP networks, much in the same way as an ordinary gateway 544 router. The Access Network Gateway looks to the other IP networks 545 like a standard IP router. 547 Access Network (AN) 549 An IP network which includes one or more Access Network Routers. 551 Administrative Domain (AD) 553 A collection of networks under the same administrative control 554 and grouped together for administrative purposes. [5] 556 Serving Access Router (SAR) 558 The Access Router currently offering the connectivity to the 559 Mobile Host. This is usually the point of departure for the 560 Mobile Node as it makes its way towards a new Access Router (then 561 Serving Access Router takes the role of the Old Access Router). 562 There may be several Serving Access Routers serving the Mobile 563 Node at the same time. 565 Old Access Router (OAR) 567 An Access Router that offered connectivity to the Mobile Node 568 prior to a handover. This is the Serving Access Router that will 569 cease or has ceased to offer connectivity to the Mobile Node. 571 New Access Router (NAR) 573 The Access Router that offers connectivity to the Mobile Node 574 after a handover. 576 Previous Access Router (PAR) 578 An Access Router that offered connectivity to the Mobile Node 579 prior to a handover. This is the Serving Access Router that will 580 cease or has ceased to offer connectivity to the Mobile Node. 581 Same as OAR. 583 Candidate Access Router (CAR) 584 An Access Router to which the Mobile Node may do a handoff. 586 4. Handover Terminology 588 These terms refer to different perspectives and approaches to 589 supporting different aspects of mobility. Distinctions can be made 590 according to the scope, range overlap, performance characteristics, 591 diversity characteristics, state transitions, mobility types, and 592 control modes of handover techniques. 594 Roaming 596 An operator-based term involving formal agreements between 597 operators that allows a mobile to get connectivity from a foreign 598 network. Roaming (a particular aspect of user mobility) 599 includes, for example, the functionality by which users can 600 communicate their identity to the local AN so that inter-AN 601 agreements can be activated and service and applications in the 602 MN's home network can be made available to the user locally. 604 Handover 606 (also known as handoff) the process by which an active MN (in the 607 Active State, see section 4.6) changes its point of attachment to 608 the network, or when such a change is attempted. The access 609 network may provide features to minimize the interruption to 610 sessions in progress. 612 There are different types of handover classified according to 613 different aspects involved in the handover. Some of this 614 terminology follows the description of [4]. 616 4.1. Scope of Handover 618 Note: the definitions of horizontal and vertical handover are 619 different than the ones commonly used today. These definitions try to 620 look at the handover from the IP layer's point of view; the IP layer 621 works with network interfaces, rather than specific technologies used 622 by those interfaces. 624 Layer 2 Handover 626 When a MN changes APs (or some other aspect of the radio channel) 627 connected to the same AR's interface then a layer 2 handover 628 occurs. This type of handover is transparent to the routing at 629 the IP layer (or it appears simply as a link layer 630 reconfiguration without any mobility implications). 632 Intra-AR Handover 634 A handover which changes the AR's network interface to the 635 mobile. That is, the Serving AR remains the same but routing 636 changes internal to the AR take place. 638 Intra-AN Handover 640 When the MN changes ARs inside the same AN then this handover 641 occurs. Such a handover is not necessarily visible outside the 642 AN. In case the ANG serving the MN changes, this handover is seen 643 outside the AN due to a change in the routing paths. Note that 644 the ANG may change for only some of the MN's data flows. 646 Inter-AN Handover 648 When the MN moves to a new AN then this handover occurs. This 649 requires some sort of host mobility across ANs, which typically 650 is be provided by the external IP core. Note that this would 651 have to involve the assignment of a new IP access address (e.g., 652 a new care-of address [9]) to the MN. 654 Intra-technology Handover 656 A handover between equipment of the same technology. 658 Inter-technology Handover 660 A handover between equipment of different technologies. 662 Horizontal Handover 664 A handover in which the mobile node's network interface does not 665 change (from the IP point of view); the MN communicates with the 666 access router via the same network interface before and after the 667 handover. A horizontal handover is typically also an intra- 668 technology handover but it can be an inter-technology handover if 669 the MN can do a layer 2 handover between two different 670 technologies without changing the network interface seen by the 671 IP layer. 673 Vertical Handover 675 In a vertical handover the mobile node's network interface to the 676 access network changes. A vertical handover is typically an 677 inter-technology handover but it may also be an intra- technology 678 handover if the MN has several network interfaces of the same 679 type. That is, after the handover, the IP layer communicates with 680 the access network through a different network interface. 682 The different handover types defined in this section and in section 683 4.1 have no direct relationship. In particular, a MN can do an 684 intra-AN handover of any of the types defined above. 686 Note that the horizontal and vertical handovers are not tied to a 687 change in the link layer technology. They define whether, after a 688 handover, the IP packet flow goes through the same (horizontal 689 handover) or a different (vertical handover) network interface. 690 These two handovers do not define whether the AR changes as a result 691 of a handover. 693 4.2. Handover Control 695 A handover must be one of the following two types (a): 697 Mobile-initiated Handover 699 the MN is the one that makes the initial decision to initiate the 700 handover. 702 Network-initiated Handover 704 the network makes the initial decision to initiate the handover. 706 A handover is also one of the following two types (b): 708 Mobile-controlled Handover (MCHO) 710 the MN has the primary control over the handover process. 712 Network-controlled Handover (NCHO) 714 the network has the primary control over the handover process. 716 A handover may also be either of these three types (c): 718 Mobile-assisted handover 720 information and measurement from the MN are used by the AR to 721 decide on the execution of a handover. 723 Network-assisted handover 725 a handover where the AN collects information that can be used by 726 the MN in a handover decision. 728 Unassisted handover 730 a handover where no assistance is provided by the MN or the AR to 731 each other. 733 A handover is also one of the following two types (d): 735 Backward handover 737 a handover either initiated by the OAR, or where the MN initiates 738 a handover via the OAR. 740 Forward handover 741 a handover either initiated by the NAR, or where the MN initiates 742 a handover via the NAR. 744 The handover is also either proactive or reactive (e): 746 Planned handover 748 a proactive (expected) handover where some signalling can be done 749 in advance of the MN getting connected to the new AR, e.g. 750 building a temporary tunnel from the old AR to the new AR. 752 Unplanned handover 754 a reactive (unexpected) handover, where no signalling is done in 755 advance of the MN's move of the OAR to the new AR. 757 The five handover types (a-e) are mostly independent, and every 758 handover should be classiable according to each of these types. 760 4.3. Simultaneous connectivity to Access Routers 762 Make-before-break (MBB) 764 During a MBB handover the MN can communicate simultaneously with 765 the old and new AR. This should not be confused with "soft 766 handover" which relies on macro diversity. 768 Break-before-make (BBM) 770 During a BBM handover the MN cannot communicate simultaneously 771 with the old and the new AR. 773 4.4. Performance and Functional Aspects 775 Handover Latency 777 Handover latency is the time difference between when a MN is last 778 able to send and/or receive an IP packet by way of the OAR, until 779 when the MN is able to send and/or receive an IP packet through 780 the NAR. Adapted from [4]. 782 Smooth handover 784 A handover that aims primarily to minimize packet loss, with no 785 explicit concern for additional delays in packet forwarding. 787 Fast handover 789 A handover that aims primarily to minimize delay, with no 790 explicit interest in packet loss. 792 Seamless handover 793 A handover in which there is no change in service capability, 794 security, or quality. In practice, some degradation in service 795 is to be expected. The definition of a seamless handover in the 796 practical case should be that other protocols, applications, or 797 end users do not detect any change in service capability, 798 security or quality, which would have a bearing on their (normal) 799 operation. See [7] for more discussion on the topic. 801 Throughput 803 The amount of data from a source to a destination processed by 804 the protocol for which throughput is to be measured for instance, 805 IP, TCP, or the MAC protocol. The throughput differs between 806 protocol layers. 808 Goodput 810 The total bandwidth used, less the volume of control messages and 811 protocol overhead from the data packets. 813 Pathloss 815 A reduction in signal strength caused by traversing the physical 816 medium constituting the link. 818 Hidden-terminal problem 820 The problem whereby a transmitting node can fail in its attempt 821 to transmit data because of destructive interference which is 822 only detectable at the receiving node, not the transmitting node. 824 Exposed terminal problem 826 The problem whereby a transmitting node prevents another node 827 from transmitting although it could have safely transmitted to 828 anyone else but that node. 830 4.5. Micro Diversity, Macro Diversity, and IP Diversity 832 Certain air interfaces (e.g. UTRAN FDD mode) require or at least 833 support macro diversity combining. Essentially, this refers to the 834 fact that a single MN is able to send and receive over two 835 independent radio channels ('diversity branches') at the same time; 836 the information received over different branches is compared and that 837 from the better branch passed to the upper layers. This can be used 838 both to improve overall performance, and to provide a seamless type 839 of handover at layer 2, since a new branch can be added before the 840 old is deleted. See also [6]. 842 It is necessary to differentiate between combining/diversity that 843 occurs at the physical and radio link layers, where the relevant unit 844 of data is the radio frame, and that which occurs at layer 3, the 845 network layer, where what is considered is the IP packet itself. 847 In the following definitions micro- and macro diversity refer to 848 protocol layers below the network layer, and IP diversity refers to 849 the network layer. 851 Micro diversity 853 for example, two antennas on the same transmitter send the same 854 signal to a receiver over a slightly different path to overcome 855 fading. 857 Macro diversity 859 Duplicating or combining actions taking place over multiple APs, 860 possibly attached to different ARs. This may require support 861 from the network layer to move the radio frames between the base 862 stations and a central combining point. 864 IP diversity 866 the splitting and combining of packets at the IP level. 868 4.6. Paging, and Mobile Node States and Modes 870 Mobile systems may employ the use of MN states in order to operate 871 more efficiently without degrading the performance of the system. The 872 term 874 A MN is always in one of the following three states: 876 Active State 878 when the AN knows the MN's SAR and the MN can send and receive IP 879 packets. The AL may not be active, but the radio layer is able 880 to establish one without assistance from the network layer. The 881 MN has an IP address assigned. 883 Dormant State 885 A state in which the mobile restricts its ability to receive 886 normal IP traffic by reducing its monitoring of radio channels. 887 The AN knows the MH's Paging Area, but the MH has no SAR and so 888 packets cannot be delivered to the MH without the AN initiating 889 paging. 891 Time-slotted Dormant Mode 893 A dormant mode implementation in which the mobile alternates 894 between periods of not listening for any radio traffic and 895 listening for traffic. Time-slotted dormant mode 896 implementations are typically synchronized with the network so 897 the network can deliver traffic to the mobile during listening 898 periods. 900 Inactive State 902 the MH is in neither the Active nor Dormant State. The host is no 903 longer listening for any packets, not even periodically, and not 904 sending packets. The host may be in a powered off state, it may 905 have shut down all interfaces to drastically conserve power, or 906 it may be out of range of a radio access point. The MN does not 907 necessarily have an IP access address from the AN. 909 Note: in fact, as well as the MN being in one of these three states, 910 the AN also stores which state it believes the MN is in. Normally 911 these are consistent; the definitions above assume so. 913 Here are some additional definitions for paging, taking into account 914 the above state definitions. 916 Paging 918 a procedure initiated by the Access Network to move an Idle MN 919 into the Active State. As a result of paging, the MN establishes 920 a SAR and the IP routes are set up. 922 Location updating 924 a procedure initiated by the MN, by which it informs the AN that 925 it has moved into a new paging area. 927 Paging Area 929 A part of the Access Network, typically containing a number of 930 ARs/APs, which corresponds to some geographical area. The AN 931 keeps and updates a list of all the Idle MNs present in the area. 932 If the MN is within the radio coverage of the area it will be 933 able to receive paging messages sent within that Paging Area. 935 Paging Area Registrations 937 Signaling from a dormant mode mobile node to the network, by 938 which it establishes its presence in a new paging area. Paging 939 Area Registrations thus enable the network to maintain a rough 940 idea of where the mobile is located. 942 Paging Channel 944 A radio channel dedicated to signaling dormant mode mobiles for 945 paging purposes. By current practice, the protocol used on a 946 paging channel is usually dictated by the radio link protocol, 947 although some paging protocols have provision for carrying 948 arbitrary traffic (and thus could potentially be used to carry 949 IP). 951 Traffic Channel 952 The radio channel on which IP traffic to an active mobile is 953 typically sent. This channel is used by a mobile that is 954 actively sending and receiving IP traffic, and is not 955 continuously active in a dormant mode mobile. For some radio 956 link protocols, this may be the only channel available. 958 4.7. Context Transfer 960 Context 962 The information on the current state of a routing-related service 963 required to re-establish the routing-related service on a new 964 subnet without having to perform the entire protocol exchange 965 with the mobile host from scratch. 967 Feature context 969 The collection of information representing the context for a 970 given feature. The full context associated with a mobile host is 971 the collection of one or more feature contexts. 973 Context transfer 975 The movement of context from one router or other network entity 976 to another as a means of re-establishing routing related services 977 on a new subnet or collection of subnets. 979 Routing-related service 981 A modification to the default routing treatment of packets to and 982 from the mobile host. Initially establishing routing-related 983 services usually requires a protocol exchange with the mobile 984 host. An example of a routing-related service is header 985 compression. The service may also be indirectly related to 986 routing, for example, security. Security may not affect the 987 forwarding decision of all intermediate routers, but a packet may 988 be dropped if it fails a security check (can't be encrypted, 989 authentication failed, etc.). Dropping the packet is basically a 990 routing decision. 992 4.8. Candidate Access Router Discovery 994 Capability of AR 996 A characteristic of the service offered by an AR that may be of 997 interest to an MN when the AR is being considered as a handoff 998 candidate. 1000 Candidate AR (CAR) 1002 An AR to which MN has a choice of performing IP-level handoff. 1003 This means that MN has the right radio interface to connect to an 1004 AP that is served by this AR, as well as the coverage of this AR 1005 overlaps with that of the AR to which MN is currently attached 1006 to. 1008 Target AR (TAR) 1010 An AR with which the procedures for the MN's IP-level handoff are 1011 initiated. TAR is selected after running a TAR Selection 1012 Algorithm that takes into account the capabilities of CARs, 1013 preferences of MN and any local policies. 1015 4.9. User, Personal and Host Mobility 1017 Different sorts of mobility management may be required of a mobile 1018 system. We can differentiate between user, personal and host 1019 mobility. 1021 User mobility 1023 refers to the ability of a user to access services from different 1024 physical hosts. This usually means, the user has an account on 1025 these different hosts or that a host does not restrict users from 1026 using the host to access services. 1028 Personal mobility 1030 complements user mobility with the ability to track the user's 1031 location and provide the user's current location to allow 1032 sessions to be initiated by and towards the user by anyone on any 1033 other network. Personal mobility is also concerned with enabling 1034 associated security, billing and service subscription 1035 authorization made between administrative domains. 1037 Host mobility 1039 refers to the function of allowing a mobile host to change its 1040 point of attachment to the network, without interrupting IP 1041 packet delivery to/from that host. There may be different sub- 1042 functions depending on what the current level of service is being 1043 provided; in particular, support for host mobility usually 1044 implies active and idle modes of operation, depending on whether 1045 the host has any current sessions or not. Access Network 1046 procedures are required to keep track of the current point of 1047 attachment of all the MNs or establish it at will. Accurate 1048 location and routing procedures are required in order to maintain 1049 the integrity of the communication. Host mobility is often 1050 called 'terminal mobility'. 1052 Two subcategories of "Host mobility" can be identified: 1054 Global mobility 1056 Same as Macro mobility. 1058 Local mobility 1060 Same as Micro mobility. 1062 Macro mobility 1064 Mobility over a large area. This includes mobility support and 1065 associated address registration procedures that are needed when a 1066 mobile host moves between IP domains. Inter-AN handovers 1067 typically involve macro-mobility protocols. Mobile-IP can be 1068 seen as a means to provide macro mobility. 1070 Micro mobility 1072 Mobility over a small area. Usually this means mobility within 1073 an IP domain with an emphasis on support for active mode using 1074 handover, although it may include idle mode procedures also. 1075 Micro-mobility protocols exploit the locality of movement by 1076 confining movement related changes and signalling to the access 1077 network. 1079 Local Mobility Management 1081 Local Mobility Management (LMM) is a generic term for protocols 1082 dealing with IP mobility management confined within the access 1083 network. LMM messages itself are not routed outside the access 1084 network, although, a handover may trigger Mobile IP messages to 1085 be sent to correspondent nodes and home agents. 1087 5. Specific Terminology for Mobile Ad-Hoc Networking 1089 Cluster 1091 A group of nodes located within close physical proximity, 1092 typically all within range of one another, which can be grouped 1093 together for the purpose of limiting the production and 1094 propogation of routing information. 1096 Cluster head 1098 A cluster head is a node (often elected in the cluster formation 1099 process) that has complete knowledge about group membership and 1100 link state information in the cluster. Each cluster should have 1101 one and only one cluster head. 1103 Cluster member 1105 All nodes within a cluster EXCEPT the cluster head are called 1106 members of that cluster. 1108 Convergence 1110 The process of approaching a state of equilibrium in which all 1111 nodes in the network agree on a consistent collection of state 1112 about the topology of the network, and in which no further 1113 control messages are needed to establish the consistency of the 1114 network topology. 1116 Convergence time 1118 The time which is required for a network to reach convergence 1119 after an event (typically, the movement of a mobile node) which 1120 changes the network topology. 1122 Laydown 1124 The relative physical location of the nodes within the ad hoc 1125 network. 1127 Pathloss matrix 1129 A matrix of coefficients describing the pathloss between any two 1130 nodes in an ad hoc network. When the links are asymmetric, the 1131 matrix is also asymmetric. 1133 Scenario 1135 The tuple 1136 characterizing a class of ad hoc networks. 1138 6. Security-related Terminology 1140 This section includes terminology commonly used around mobile and 1141 wireless networking. Only a mobility-related subset of the entire 1142 security terminology is presented. 1144 Authorization-enabling extension 1146 An authentication which makes a (registration) message acceptable 1147 to the ultimate recipient of the registration message. An 1148 authorization-enabling extension must contain an SPI [14]. 1150 Mobility Security Association 1152 A collection of security contexts, between a pair of nodes, which 1153 may be applied to mobility-related protocol messages exchanged 1154 between them. In Mobile IP, each context indicates an 1155 authentication algorithm and mode, a secret (a shared key, or 1156 appropriate public/private key pair), and a style of replay 1157 protection in use. Mobility security associations may be stored 1158 separately from the node's IPsec Security Policy Database (SPD) 1159 [14]. 1161 Registration Key 1163 A key used as the basis of a Mobility Security Association 1164 between a mobile node and a foreign agent. A registration key is 1165 typically only used once or a very few times, and only for the 1166 purposes of verifying a small volume of Authentication data [16]. 1168 Security Context 1170 A security context between two routers defines the manner in 1171 which two routers choose to mutually authentication each other, 1172 and indicates an authentication algorithm and mode. 1174 Security Parameter Index (SPI) 1176 An index identifying a security context between a pair of routers 1177 among the contexts possible in the mobility security association. 1179 Stale challenge 1181 Any challenge that has been used by the mobile node in a 1182 Registration Request message and processed by the Foreign Agent 1183 by relaying or generating The Foreign Agent may not be able to 1184 keep records for all previously used challenges [15]. 1186 Unknown challenge 1188 Any challenge from a particular mobile node that the foreign 1189 agent has no record of having put either into one of its recent 1190 Agent Advertisements or into a registration reply message to that 1191 mobile node [15]. 1193 Unused challenge 1195 A challenge that has not been already accepted by the Foreign 1196 Agent challenge in a corresponding Registration Reply message -- 1197 i.e., a challenge that is neither unknown nor previously used 1198 [15]. 1200 The Mobile IPv6 specification includes more security terminology 1201 related to MIPv6 bindings [RFC3xxx]. 1203 7. Security Considerations 1205 This document presents only terminology. There are no security issues 1206 in this document. 1208 8. Contributors 1210 This draft was initially based on the work of 1212 o Tapio Suihko, VTT Information Technology, Finland 1213 o Phil Eardley and Dave Wisely, BT, UK 1214 o Robert Hancock, Siemens/Roke Manor Research, UK, 1215 o Nikos Georganopoulos, King's College London 1216 o Markku Kojo and Jukka Manner, University of Helsinki, Finland. 1218 Since revision -02 of the document draft-manner-seamoby-terms-02.txt, 1219 Charles Perkins has given as input terminology related to ad-hoc 1220 networks. 1222 9. Acknowledgement 1224 This work has been partially performed in the framework of the IST 1225 project IST-2000-28584 MIND, which is partly funded by the European 1226 Union. The authors would like to acknowledge the help of their 1227 colleagues in preparing this document. 1229 Some definitions of terminology have been adapted from [1], [7], [3], 1230 [2], [4], [9], [10], [11], [12] and [13]. 1232 10. References 1234 [1] D. Blair, A. Tweedly, M. Thomas, J. Trostle, and 1235 M. Ramalho. Realtime Mobile IPv6 Framework (work in 1236 progress). Internet Draft, Internet Engineering Task Force. 1237 draft-blair-rt-mobileipv6-seamoby-00.txt, November 2000. 1239 [2] P. Calhoun, G. Montenegro, and C. Perkins. Mobile IP 1240 Regionalized Tunnel Management (work in progress). Internet 1241 Draft, Internet Engineering Task Force, November 1998. 1243 [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1244 Specification. Request for Comments (Draft Standard) 2460, 1245 Internet Engineering Task Force, December 1998. 1247 [4] G. Dommety (ed.). Fast Handovers for Mobile IPv6 (work 1248 in progress). draft-ietf-mobileip-fast-mipv6-05.txt, 1249 September, 2002. 1251 [5] Yavatkar et al. A Framework for Policy-based Admission 1252 Control. Request for Comments 2753, Internet Engineering Task 1253 Force, January 2000. 1255 [6] J. Kempf, P. McCann, and P. Roberts. IP Mobility and the CDMA 1256 Radio Access Network: Applicability Statement for Soft Handoff 1257 (work in progress). Internet Draft, 1258 draft-kempf-cdma-appl-00.txt, July 2000. 1260 [7] J. Kempf (ed.). Problem Description: Reasons For Doing 1261 Context Transfers Between Nodes in an IP Access Network. 1262 RFC 3374, Internet Engineering Task Force, September, 2002. 1264 [8] R. Pandya. Emerging Mobile and Personal Communication Systems. 1265 IEEE Communications Magazine, 33:44--52, June 1995. 1267 [9] C. Perkins. IP Mobility Support. Request for Comments 1268 (Proposed Standard) 2002, Internet Engineering Task Force, 1269 October 1996. 1271 [10] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, and 1272 L. Salgarelli. IP micro-mobility support using HAWAII (work in 1273 progress). Internet Draft, Internet Engineering Task Force, 1274 June 1999. 1276 [11] D. Trossen, G. Krishnamurthi, H. Chaskar, J. Kempf, "Issues in 1277 candidate access router discovery for seamless IP-level 1278 handoffs. Internet Draft (work in progress), 1279 draft-ietf-seamoby-cardiscovery-issues-04.txt, October 2002. 1281 [12] David B. Johnson, Charles E. Perkins, Jari Arkko, "Mobility 1282 Support in IPv6". Internet Draft, 1283 draft-ietf-mobileip-ipv6-18.txt (work in progress), June 2002. 1285 [13] Thierry Ernst and Hong-Yon Lach, "Network Mobility Support 1286 Terminology". Internet Draft, 1287 draft-ernst-monet-terminology-01.txt (work in progress), July 1288 2002. 1289 [14] Charles Perkins (ed.), "IP Mobility Support for IPv4". Request 1290 for Comments 3344, August 2002. 1292 [15] Charles Perkins, Pat Calhoun, Jayshree Bharatia, "Mobile 1293 IPv4 Challenge/Response Extensions (revised)". Internet Draft, 1294 December, 2002 (draft-ietf-mobileip-rfc3012bis-04.txt). 1296 [16] Charles Perkins, Pat Calhoun, "AAA Registration Keys for Mobile 1297 IP". Internet Draft, October 2002, 1298 (draft-ietf-mobileip-aaa-key-10.txt). 1300 11. Author's Addresses 1302 Questions about this document may be directed to: 1304 Jukka Manner 1305 Department of Computer Science 1306 University of Helsinki 1307 P.O. Box 26 (Teollisuuskatu 23) 1308 FIN-00014 HELSINKI 1309 Finland 1311 Voice: +358-9-191-44210 1312 Fax: +358-9-191-44441 1313 E-Mail: jmanner@cs.helsinki.fi 1315 Markku Kojo 1316 Department of Computer Science 1317 University of Helsinki 1318 P.O. Box 26 (Teollisuuskatu 23) 1319 FIN-00014 HELSINKI 1320 Finland 1322 Voice: +358-9-191-44179 1323 Fax: +358-9-191-44441 1324 E-Mail: kojo@cs.helsinki.fi 1326 Charles E. Perkins 1327 Communications Systems Lab 1328 Nokia Research Center 1329 313 Fairchild Drive 1330 Mountain View, California 94043 1331 USA 1332 Phone: +1-650 625-2986 1333 E-Mail: charliep@iprg.nokia.com 1334 Fax: +1 650 625-2502 1336 Tapio Suihko 1337 VTT Information Technology 1338 P.O. Box 1203 1339 FIN-02044 VTT 1340 Finland 1342 Voice: +358-9-456-6078 1343 Fax: +358-9-456-7028 1344 E-Mail: tapio.suihko@vtt.fi 1345 Phil Eardley 1346 BTexaCT 1347 Adastral Park 1348 Martlesham 1349 Ipswich IP5 3RE 1350 United Kingdom 1352 Voice: +44-1473-645938 1353 Fax: +44-1473-646885 1354 E-Mail: philip.eardley@bt.com 1356 Dave Wisely 1357 BTexaCT 1358 Adastral Park 1359 Martlesham 1360 Ipswich IP5 3RE 1361 United Kingdom 1363 Voice: +44-1473-643848 1364 Fax: +44-1473-646885 1365 E-Mail: dave.wisely@bt.com 1367 Robert Hancock 1368 Roke Manor Research Ltd 1369 Romsey, Hants, SO51 0ZN 1370 United Kingdom 1372 Voice: +44-1794-833601 1373 Fax: +44-1794-833434 1374 E-Mail: robert.hancock@roke.co.uk 1376 Nikos Georganopoulos 1377 King's College London 1378 Strand 1379 London WC2R 2LS 1380 United Kingdom 1382 Voice: +44-20-78482889 1383 Fax: +44-20-78482664 1384 E-Mail: nikolaos.georganopoulos@kcl.ac.uk) 1386 12. Appendix A - Examples 1388 This appendix provides examples for the terminology presented. 1390 A.1. Mobility 1392 Host mobility is logically independent of user mobility, although in 1393 real networks, at least the address management functions are often 1394 required to initially attach the host to the network. In addition, 1395 if the network wishes to determine whether access is authorized (and 1396 if so, who to charge for it), then this may be tied to the identity 1397 of the user of the terminal. 1399 An example of user mobility would be a campus network, where a 1400 student can log into the campus network from several workstations and 1401 still retrieve files, emails, and other services automatically. 1403 Personal mobility support typically amounts to the maintenance and 1404 update of some sort of address mapping database, such as a SIP server 1405 or DNS server; it is also possible for the personal mobility support 1406 function to take a part in forwarding control messages between end 1407 user and correspondent rather than simply acting as a database. SIP 1408 is a protocol for session initiation in IP networks. It includes 1409 registration procedures which partially support personal mobility 1410 (namely, the ability for the network to route a session towards a 1411 user at a local IP address). 1413 Personal mobility has been defined in [8] as "the ability of end 1414 users to originate and receive calls and access subscribed 1415 telecommunication services on any terminal in any location, and the 1416 ability of the network to identify end users as they move. Personal 1417 mobility is based on the use of a unique personal identity (i.e., 1418 personal number)." 1420 Roaming, in its original (GSM) sense, is the ability of a user to 1421 connect to the networks owned by operators other than the one having 1422 a direct formal relationship with the user. More recently (e.g., in 1423 data networks and UMTS) it also refers providing user-customized 1424 services in foreign networks (e.g., QoS profiles for specific 1425 applications). 1427 HAWAII, Cellular IP, Regional Registration and EMA are examples of 1428 micro mobility schemes, with the assumption that Mobile IP is used 1429 for macro mobility. 1431 WLAN technologies such as IEEE 802.11 typically support aspects of 1432 user and host mobility in a minimal way. User mobility procedures 1433 (for access control and so on) are defined only over the air 1434 interface (and the way these are handled within the network is not 1435 further defined). 1437 PLMNs (GSM/UMTS) typically have extensive support for both user and 1438 host mobility. Complete sets of protocols (both over the air and on 1439 the network side) are provided for user mobility, including 1440 customized service provision. Handover for host mobility is also 1441 supported, both within access networks, and also within the GSM/UMTS 1442 core network for mobility between access networks of the same 1443 operator. 1445 A.2. Handovers 1447 A hard handover is required where a MN is not able to receive or send 1448 traffic from/to two APs simultaneously. In order to move the traffic 1449 channel from the old to the new access point the MN abruptly changes 1450 the frequency/timeslot/code on which it is transmitting and listening 1451 to new values associated with a new access point. Thus, the handover 1452 is a break-before-make handover. 1454 A good example of hard handover is GSM where the mobile listens for 1455 new base stations, reports back to the network the signal strength 1456 and identity of the new base station(s) heard. When the old base 1457 station decides that a handover is required it instructs the new base 1458 station to set up resources and, when confirmed, instructs the mobile 1459 to switch to a new frequency and time slot. This sort of hand over 1460 is called hard, mobile assisted, network initiated and backward 1461 (meaning that the old base station is responsible for handling the 1462 change-over). 1464 In a TDMA system, such as GSM, the hard hand over is delayed until 1465 the mobile has moved well within the coverage of the new base 1466 station. If the handover threshold was set to the point where the 1467 new base station signal exceeded the old then there would be a very 1468 large number of handovers as the mobile moved through the region 1469 between the cells and radio signals fluctuated, this would create a 1470 large signalling traffic. To avoid this a large hysteresis is set, 1471 i.e. the new base station must be (say) 10dB stronger for handover 1472 to occur. If the same was done in W-CDMA then the mobile would be 1473 transmitting a powerful signal to the old base station and creating 1474 interference for other users, since in CDMA everyone else's 1475 transmissions are seen as noise, thus reducing capacity. To avoid 1476 this soft handover is used, giving an estimated doubling in capacity. 1477 Support for soft handover (in a single mode terminal) is 1478 characteristic of radio interfaces which also require macro diversity 1479 for interference limitation but the two concepts are logically 1480 independent. 1482 A good example of soft handover is the UTRAN FDD mode. W-CDMA is 1483 particularly suited to soft handover because of the design of the 1484 receivers and transmitters: typically a rake receiver will be used 1485 to overcome the multi-path fading of the wide-band channel. Rake 1486 receivers have a number of so-called fingers, each effectively 1487 separate detectors, that are tuned to the same signal (e.g. 1488 spreading code) but delayed by different times. When the delay times 1489 are correctly adjusted and the various components properly combined 1490 (this is micro diversity combining) the effect of multi-path fading 1491 is removed. The rake receiver can also be used to detect signals 1492 from different transmitters by tuning the fingers to different 1493 spreading codes. Soft handover is used in UTRAN FDD mode to also 1494 increase capacity. 1496 Every handover can be seen as a context-aware Handover. In PLMNs the 1497 context to be fulfilled is that the new AP can accommodate the new 1498 mobile, for example, the new GSM cell can serve the incoming phone. 1499 Lately, the notion of Context-aware Handovers has been enlarged by, 1500 for example, QoS-aware handovers, meaning that the handover is 1501 governed by the need to support the QoS-context of the moving mobile 1502 in order to keep the service level assured to the user of the MN. 1504 A.3. Diversity combining 1506 In the case of UMTS it is radio frames that are duplicated at some 1507 point in the network (the serving RNC) and sent to a number of 1508 basestations and, possibly via other (drift) RNCs. The combining 1509 that takes place at the serving RNC in the uplink direction is 1510 typically based on some simple quality comparison of the various 1511 received frames, which implies that the various copies of these 1512 frames must contain identical upper layer information. The serving 1513 RNC also has to do buffering data frames to take account of the 1514 differing time of flight from each basestation to the RNC. 1516 A.4. Miscellaneous 1518 In a GPRS/UMTS system the Access Network Gateway node could be the 1519 GGSN component. The ANG can provide support for mobility of hosts, 1520 admission control, policy enforcement, and Foreign Agent 1521 functionality [9]. 1523 When presenting a mobile network topology, APs and ARs are usually 1524 pictured as separate components (see Figure 1. This is the case with 1525 GSM/GPRS/UMTS presentations, for example. From the IP point of view 1526 APs are not directly visible. An AP should only be seen from the 1527 MN's or AR's IP layer as a link (interface) connecting MNs to the AR. 1529 When the mobile moves through the network, depending on the mobility 1530 mechanism, the OAR will forward packets destined to the old MNs 1531 address to the SAR which currently serves the MN. At the same time 1532 the handover mechanism may be studying CARs to find the best NAR 1533 where the MN will be handed next. 1535 13. Appendix B - Index of Terms 1537 1539 Full Copyright Statement 1541 Copyright (C) The Internet Society (2001). All Rights Reserved. 1543 This document and translations of it may be copied and furnished to 1544 others, and derivative works that comment on or otherwise explain it 1545 or assist in its implementation may be prepared, copied, published 1546 and distributed, in whole or in part, without restriction of any 1547 kind, provided that the above copyright notice and this paragraph are 1548 included on all such copies and derivative works. However, this 1549 document itself may not be modified in any way, such as by removing 1550 the copyright notice or references to the Internet Society or other 1551 Internet organizations, except as needed for the purpose of 1552 developing Internet standards in which case the procedures for 1553 copyrights defined in the Internet Standards process must be 1554 followed, or as required to translate it into languages other than 1555 English. 1557 The limited permissions granted above are perpetual and will not be 1558 revoked by the Internet Society or its successors or assigns. 1560 This document and the information contained herein is provided on an 1561 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1562 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1563 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1564 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1565 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.