idnits 2.17.1 draft-westberg-rmd-cellular-issues-00.txt: ** The Abstract section seems to be numbered 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 2 instances of lines with non-ascii characters in the document. == 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 a Security Considerations section. ** 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. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 470 has weird spacing: '... cannot be pe...' == Line 1151 has weird spacing: '...ansport net...' == Line 1154 has weird spacing: '...andover perfo...' == Line 1158 has weird spacing: '...onality in e...' -- 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.) -- The document date (June 2001) is 8351 days in the past. Is this intentional? 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: Non-RFC (?) normative reference: ref. 'AhBe99' -- Possible downref: Non-RFC (?) normative reference: ref. 'BaIt00' -- Possible downref: Non-RFC (?) normative reference: ref. 'KeMc00' -- Possible downref: Non-RFC (?) normative reference: ref. 'WeLi99' ** Downref: Normative reference to an Informational RFC: RFC 2998 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Cellular RAN Resource Issues June 2001 4 Internet Engineering Task Force D. Partain (ed) 5 INTERNET-DRAFT G. Karagiannis 6 Expires December 2001 P. Wallentin 7 L. Westberg 8 Ericsson 9 June 2001 11 Resource Reservation Issues in Cellular Radio Access Networks 12 draft-westberg-rmd-cellular-issues-00.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 1. Abstract 37 The rapidly growing popularity of IP and its flexibility make it a 38 good candidate to be used for transmission in cellular networks. 40 Using IP-based transport on the wired transmission links in the 41 cellular networks gives operators an opportunity to upgrade their 42 transport network to a packet-based one. When compared with a 43 traditional STM-based system, the gain is seen in the statistical 44 aggregation of traffic that can be done. This results in increased 45 transmission efficiency and reduced leasing cost for the operator. 47 A radio access network (RAN) provides the radio access (e.g., GSM, 48 CDMA, or WCDMA) to mobile stations in a cellular network. To 49 accomplish this, radio frames are transported on the wired links 50 between different cellular-specific nodes in the RAN. The majority of 51 the traffic (up to 100%) is delay-sensitive traffic. 53 The cellular user is unaware of the IP-based transport network 54 underneath, and the service must work the same way as the user has 55 come to expect the cellular services to work in an STM-based 56 transport network. In addition to this requirement, the situation is 57 further complicated by the fact that the RAN is large in terms of its 58 geographic size, the number of inter-connected nodes, and the 59 proportion of real-time traffic. 61 To satisfy the above requirements, it is absolutely critical that we 62 have a simple and scalable bandwidth resource management scheme for 63 real-time traffic in this type of network. 65 In order for real-time services to function satisfactorily in an IP- 66 based RAN, we need to ensure that there are adequate transport 67 resources on the links available in the RAN to handle this particular 68 instance of the service (e.g., a phone call). Note that, in rest of 69 this draft, whenever the term "resources" is used, it refers to 70 bandwidth on the links. 72 If the RAN is bandwidth-limited and does not use any mechanism to 73 limit the usage of the network resources, congestion might occur and 74 degrade the network performance. For example, speech quality might 75 degrade due to packet losses. Note that this memo is a successor of 76 the draft "draft-partain-wireless-issues-00.txt". 78 2. Terminology 80 The following terminology is used in this memo: 82 * BSC: Base Station Controller 84 * RNC: Radio Network Controller 86 * MSC: Mobile Services Switching Center 88 * GGSN: Gateway GPRS Support Node 90 * SGSN: Serving GPRS Support Node 92 * GPRS: General Packet Radio Service, the packet-switched access 93 scheme and service provided in GSM. 95 * GSM: Global System for Mobile Communications 97 * UMTS: Universal Mobile Telecommunications System, the third 98 generation (3G) mobile system based on WCDMA and GSM, 99 specified by 3GPP (third generation partnership project). 101 * radio frame: a short data segment coded/decoded and 102 transmitted/received by the radio base station. 103 It originates from a mobile station or the BSC/RNC. 105 * WCDMA: Wideband Code Division Multiple Access, the 106 radio transmission technology used in UMTS 108 3. Background and motivation 110 The context of the issues described in this document is the cellular 111 radio access network (RAN). This section briefly discusses two 112 examples of radio access networks (for GSM - Global System for Mobile 113 Communication - and for WCDMA - Wideband Code Division Multiple 114 Access) and then outlines the motivation for this memo. Note that 115 this memo is a successor of the draft "draft-partain-wireless- 116 issues-00.txt". 118 3.1. IP transport in radio access networks 120 This section introduces the radio access network and its use of IP 121 transport. A radio access network (RAN) provides the radio access 122 (e.g., GSM, CDMA, or WCDMA) to mobile stations for a cellular system. 123 The boundaries for a RAN are the radio transmission and reception 124 access points (terminated by base stations) at one end and, at the 125 other end, the interfaces to the gateways (e.g., MSC and SGSN/GGSN), 126 which in turn provide connections to the fixed public network. 128 The radio access network consists of a number of nodes as shown in 129 the Figure 1 below. 131 IP IP 132 <---> <---> 134 |---------| |---------| |---------| 135 Mobile v | Base | | | | MSC/ | Fixed 136 stations |--| station |-----| BSC/RNC |-----| SGSN/ |--- public 137 ^ | | ^ | | ^ | GGSN | network 138 | |---------| | |---------| | |---------| 139 | | | 140 Wireless Wired Wired 141 interface interface interface 143 Radio access network 144 <-------------------------------> 146 Figure 1: Typical radio access network and its boundaries 148 The base station provides the radio channel coding/decoding and 149 transmission/reception function to and from mobile stations in its 150 coverage area, which is called a cell. 152 The BSC/RNC controls a number of base stations including the radio 153 channels and the connections to mobile stations. For a WCDMA radio 154 access network, the BSC/RNC provides soft handover combining and 155 splitting between streams from different base stations belonging to 156 the same mobile station. Furthermore, the BSC/RNC is also 157 responsible for the allocation of transport resources within the 158 radio access network. The transport is either between the base 159 station and the BSC/RNC, between multiple BSC/RNCs, or between the 160 BSC/RNC and the MSC/SGSN. 162 The MSC provides, among others things, support for circuit-switched 163 services towards mobile stations including mobility management, 164 access control and call control as well as interworking with external 165 circuit-switched networks such as the public switched telephony 166 network (PSTN). The SGSN/GGSN provide, amongst other things, support 167 for packet switched services towards mobile stations, including 168 mobility management, access control and control of packet data 169 protocol contexts. In addition, the GGSN provides interworking with 170 external packet-switched networks such as the public Internet. 172 The radio access network consists of potentially thousands of base 173 stations and a significant number of BSCs/RNCs. The traffic volume, 174 in terms of voice-traffic, generated by these nodes can vary from a 175 few up to fifty voice calls per base station, and up to several 176 thousand simultaneous calls (Erlang) per BSC/RNC site. Therefore, a 177 router in the network has to handle many thousands of simultaneous 178 flows. 180 The transmission between base stations and the BSC/RNC is usually on 181 leased lines, and this part (due to the wide area coverage of the 182 cellular network) is usually extremely expensive when compared to the 183 cost of transmission in the backbone. Due the number of base 184 stations, the cost for these leased lines can be quite significant. 185 Dimensioning using over-provisioning might therefore be prohibitively 186 expensive, and it is unlikely that the network will be dimensioned 187 without using the statistical properties of traffic aggregation 188 (e.g., Erlang trunking). 190 |--------| 191 | Upper |<--------------------------------------------> towards the 192 | layers | MSC/SGSN/GGSN 193 |--------| |---------|--------| 194 | Radio | | Radio | | 195 | Link |<----------------------------------->| Link | | 196 | Layer | | Layer | | 197 |--------| |---------| | 198 | | |Radio | |<- 199 | | |Physical | Frame | 200 | | |Layer | transp.| 201 | | |-------|--------| |---------| layer | 202 | | | | Frame |<-------------->| Frame | | 203 | | | | transp.| | transp. | | 204 |Radio | | Radio |--------| |---------|--------| 205 |Physical| | Phys. | UDP |<-------------->| UDP | UDP | 206 |Layer |<->| Layer |--------| |--------| |---------|--------| 207 | | | | IP |<->| IP |<->| IP | IP | 208 | | | |--------| |--------| |---------|--------| 209 | | | | Link | | Link |<->| Link | Link | 210 | | | | Layer |<->| Layer | | Layer | Layer | 211 | | | |--------| |--------| |---------|--------| 212 | | | |Physical| |Physical| |Physical |Physical| 213 | | | | Layer |<->| Layer |<->| Layer | Layer | 214 |--------| |-------|--------| |--------| |------------------| 215 Mobile Base station Router BSC/RNC 216 Station ^ ^ ^ 217 | | | 218 Wireless Wired Wired 219 interface interface interface 221 Radio access network 222 <-----------------------------------------------------> 224 Figure 2: Example of a protocol stack in the 225 radio access network (simplified) 227 Figure 2 shows a simplified example of protocol layering when using 228 IP transport in the radio access network. 230 The radio physical layer performs radio transmission and reception 231 functions, including soft handover splitting and combining in case of 232 WCDMA. 234 The frame transport layer is used to transmit radio frames between 235 the base station and the BSC/RNC. A radio frame is a short data 236 segment coded/decoded and transmitted/received by the radio base 237 station at a given point in time. The radio frames must be delivered 238 in a timely fashion with limited delay. Otherwise, the frames are 239 discarded by the base station or RNC/BSC. The traffic is therefore 240 very sensitive to delays. 242 The radio link layer performs segmentation/re-assembly, 243 retransmission and multiplexing/scheduling functions as well as radio 244 resource control. The adaptation of user data performed by the radio 245 link layer depends on the type of radio channel and the type of 246 service. In one case, that very small radio frames might be 247 transferred, while in other cases the packets are significantly 248 larger. 250 Introducing IP in the radio access network implies that an IP QoS- 251 capable domain, e.g. a Differentiated Services domain, will have to 252 be introduced and managed in the radio access network. This domain 253 consists of edge and interior nodes, where the edge nodes are the 254 nodes located at the boundary of the domain. All the nodes which are 255 part of this QoS-capable domain and are not edge nodes are defined as 256 interior nodes. 258 An edge node can be defined as an ingress node, or a node that 259 handles the traffic as it enters the QoS-capable domain. 260 Alternatively, an edge node might be an egress node, or a node that 261 handles the traffic as it leaves the QoS-capable domain. In this 262 memo, an edge node (ingress or egress) is denoted as the first hop 263 router that the base station or BSC/RNC is connected to. The first 264 hop router might be a part of the base station or BSC/RNC. 266 Furthermore, the base station and BSC/RNC must be able to handle 267 algorithms used for purposes other than edge node functionality that 268 are many times more complex than the algorithms required for handling 269 the edge node functionality. Therefore, the edge node functionality 270 will only have minimal impact on the complexity of the base station 271 or BSC/RNC. 273 3.2. Motivation for this memo 275 The issues described in this document concern only the cellular radio 276 access network (RAN). 278 The architecture of the RAN and the nature of the transported data 279 mean that the RAN has different characteristics when compared with 280 other IP-based networks. However, those differences, which are the 281 motivation for this memo, are limited to the domain of the RAN and do 282 not extend into the backbone of the IP network. 284 In order for the transport within the RAN to function satisfactorily, 285 even if the transport network is IP-based, we need to ensure that 286 there are adequate resources in the transport network to meet the 287 needs of the data flows between the nodes within the RAN. 289 Based upon the characteristics of the RAN (described in Section 4 290 below), the current strategies for resource management do not meet 291 the requirements for an appropriate resource management strategy 292 within a RAN. This document seeks to initiate a dialog on how to 293 correct that situation. 295 4. Network characteristics of cellular access networks today 297 Cellular RANs today have a unique set of characteristics compared to 298 other kinds of IP networks. These characteristics result in a set of 299 requirements on any resource reservation scheme that might be used in 300 the RAN. 302 4.1. General aspects of the network structure 304 The network structure for cellular radio access networks can be 305 described as having the following characteristics: 307 * Operator relationship 309 The RAN is typically controlled by a single cellular operator 310 with full control over the network. The IP network used to 311 transport radio frames might be leased from another operator 312 or be built by the same cellular operator. This network 313 could be thought of as an "intranet". 315 * Size of network 317 RANs can be very large routed networks. Networks including 318 thousands of nodes are certainly within reason. 320 * Traffic volume 322 The traffic from a large number of radio base stations 323 needs to be supported by the same transport network. Even 324 if a single radio base station generates a modest volume of 325 traffic, the total number of flows for radio frame transport 326 in the radio access network is very large. 328 * Transmission sharing 330 The network between the BSC/RNC and the base stations is 331 built to support transmission sharing between different 332 nodes even if they are geographically distributed. 333 One transmission link (possibly with redundancy) can 334 support more than one base station. In other words, one 335 piece of hardware can serve more than one base station and 336 therefore can support more cells in one location, such as 337 a three sector site. This means that the cells that are 338 located at the same location will have to compete for the 339 same transmission resources. 341 * Unicast transport of radio frames 343 The transport of radio frames in the radio access network is 344 point-to-point transport. Even if the soft handover splitting 345 in the BSC/RNC is multicast of radio frames in some sense, 346 this is handled above the IP layer by the frame transport 347 protocol. For each radio channel in each base station the 348 frame transport protocol needs a separate flow. Therefore, 349 the frame transport protocol requires unicast transmission 350 from the IP layer. 352 4.2. High cost for transmission 354 The transmission between base stations and the BSC/RNC is usually on 355 leased lines, and this part (due to the wide area coverage of the 356 cellular network) is usually extremely expensive when compared to the 357 cost of transmission in the backbone. Due to the number of base 358 stations, the cost for these leased lines can be quite significant. 359 Even if the cost for the leased line decreases over the years, the 360 "last mile" to the base station is likely to be expensive due to the 361 location of the base station. 363 Cellular RANs are built over a very wide geographic area. There are, 364 of course, many different networks that cover a wide geographic area 365 (e.g., across USA, and the world), but the dispersion of nodes over 366 the area in the RAN case is different. Due to the fact that the base 367 stations are positioned based on a radio network perspective, i.e., 368 radio coverage, and not based on a transmission perspective, a large 369 proportion of nodes are distributed throughout rural and urban areas, 370 not close to installed high-capacity transmission hubs. Even worse, 371 the the base stations could be positioned far out in the countryside. 373 The peak bitrate of the multirate radio channels is selected on- 374 demand. To utilize the bandwidth of the expensive transmission links 375 used for radio frame transport efficiently, dimensioning using over- 376 provisioning might therefore be prohibitively expensive, and it is 377 unlikely that the network will be dimensioned for peak allocation. 378 Dynamic allocation and optimization to reduce the cost are therefore 379 a fundamental requirement. Resource reservations make it possible to 380 have high utilization of the network for real-time sensitive traffic 381 as well as avoiding congestion in the network. 383 4.3. Transportation of radio frames 385 The traffic in cellular access networks is dramatically different 386 from the Internet in general. The Internet primarily supports best- 387 effort traffic today, while the traffic on a RAN is (at least today) 388 largely real-time traffic. The network from the base station to the 389 BSC/RNC is the part of the network that has the highest volume of 390 real-time traffic and where delay must be minimized as much as 391 possible. The reasons for the this are: 393 * End-to-end delay for speech traffic consists of delays in the 394 mobile stations, the RAN and in the MSC (see Figure 1 in 395 Section 3.1). The major portion of delay in the RAN is caused 396 by the radio-related functionality (e.g., interleaving and 397 coding in the base station and adaptation in the BSC/RNC). 398 Therefore, the combined delay in all parts (MSC, radio 399 network, and mobile stations) must be minimized as much 400 as possible to give the end user proper speech quality. 402 * Handover is a major issue. For GSM, with typically multiple 403 handovers per call, excessive delay in the control, e.g. 404 radio network control traffic, of the radio network will 405 cause a longer handover interruption period. The majority 406 of handovers are also made within the radio network. 408 * The transport of radio frames is very delay-sensitive. In 409 the direction from the BSC/RNC to the base station, a radio 410 frame is a short segment of data (payload) to be coded and 411 transmitted on a given radio channel by the base station at a 412 given point in time. In the direction from the base station 413 to the BSC/RNC, a radio frame is a short segment of data 414 (payload) that was received and decoded by the base station 415 at a given point in time and potentially needs to be combined 416 in the BSC/RNC with radio frames received by other base 417 stations at the same point in time as this particular frame. 418 Note that the data segment in a radio frame may contain user 419 data but also control signalling information and the same 420 type of synchronized frame transport is needed for almost 421 all kinds of radio channels and is generally not coupled 422 to the type of service. Therefore, even if an end to end 423 application is best effort, the transport of the radio frames 424 originating from this application might be treated as real-time 425 within the radio access network. 427 The real-time traffic on the RANs is today almost exclusively voice 428 (up to 90% with 10% signalling), but the cellular systems are 429 evolving to provide capabilities for other kinds of real-time traffic 430 (e.g., video). Nonetheless, voice continues to be one of the most 431 important sources of revenue in most cellular environments today. The 432 transport resources are today allocated when the call is accepted, 433 and the radio frame transport over an IP network has to provide the 434 same guarantees. If real-time traffic cannot be engineered to work 435 correctly, the primary revenue stream will disappear. 437 Some of the sources, such as video-based services and gaming, will be 438 able to send data at a variable bitrate at higher rates. For radio, 439 the rates of the radio channels are selected on-demand. In reality, 440 the radio network can support a wide range of partitioning of the 441 radio resources among the different radio channels. A rather large 442 portion of the transmission resources between the base station and 443 BSC/RNC will have to be allocated for such services. To be able to 444 utilize the bandwidth used for radio frame transport efficiently, the 445 same flexibility is required in assignment of the transport resources 446 as in the air-interface. Therefore, statically-assigned resources 447 will induce a cost which is too high for the operator. 449 4.4. Mobility aspect of radio frame transport 451 The mobility of the mobile stations imposes strong requirements on 452 managing the transmission resources available in the RAN, 453 Furthermore, this also implies that there are strong requirements on 454 the RAN's internal signaling and not only on transferring of packets 455 sent by the mobile station. 457 Hard handover is one of the issues. For GSM, with typically multiple 458 handovers per call, excessive delay in the control of the radio 459 network will cause a longer handover interruption period. Typically, 460 most of the handovers will be made between base stations controlled 461 by the same BSC and therefore extensive delay between base station 462 and BSC will degrade more than delays in the MSC and SGSN/GGSN 463 network. 465 Moreover, for maximal utilization of radio spectrum in WCDMA (and 466 also in CDMA), fast and frequent (soft) handover operations between 467 radio channels and radio base stations are required. The frequency of 468 handover events is therefore typically higher in WCDMA radio access 469 networks than in GSM and means even higher performance requirements 470 on the transport solution. If the soft handover cannot be performed 471 fast enough, spectrum cannot be utilized efficiently, which will 472 cause degradation of the radio network capacity. At each handover 473 event, resource reservation is needed, and therefore resource 474 reservation needs to be fast and will be used very frequently. 476 The impact of mobility in the radio access network has therefore two 477 major differences compared to the fixed network: 478 (1) High volume of resource reservation events 479 (2) Requirement on short response time for reservations 481 5. Requirements on a Resource Reservation Scheme 483 This section outlines what we believe are the fundamental 484 requirements placed on any resource reservation scheme in a cellular 485 radio access network. Later sections will outline how current schemes 486 match these requirements. 488 5.1. Main requirement on resource reservation scheme 490 One of the primary requirements that real-time applications impose on 491 any resource reservation scheme is the provisioning of good QoS 492 (delay and packet loss) guarantees. This can only be achieved if the 493 network can be utilized while avoiding congestion and without having 494 too high packet losses. The level of utilization depends on network 495 topology, traffic mix, scheduling discipline, delay and packet loss 496 requirements. The utilization is given by network dimensioning but 497 should be as high as possible. 499 The resource reservation scheme must be able to keep the real-time 500 traffic under a certain pre-defined network utilization in order to 501 bound congestion. Otherwise, it is impossible to guarantee percentile 502 bounds on the QOS requirements for real-time traffic. 504 5.2. IP must provide same service behavior as the transport networks 505 used today 507 Today's commercial IP networks are mainly optimized to carry best- 508 effort traffic. As explained above and also discussed in [WeLi99], 509 the transport of radio frames in the radio access network puts real- 510 time requirements on the underlying transport network. All of these 511 characteristics are fulfilled by the connection-oriented transport 512 networks (STM and ATM) used by cellular networks today. By, at a 513 minimum, meeting these same requirements, the IP networks will be 514 capable of providing the same behavior as the transport networks that 515 are currently used by cellular systems while gaining the advantages 516 of IP networking. It should be noted that IP networks will be able to 517 meet these requirements only if the following two constraints are 518 met: 520 (1) that service guarantees are percentiles, see Section 5.1 521 (2) strictly limited to a given operator's IP network, see 522 Section 5.9. 524 5.3. Efficient network utilization 526 Due to the high cost of the leased transmission, we must utilize the 527 network to the highest degree possible, and this must be facilitated 528 by the resource reservation scheme. 530 However, in considering a resource reservation scheme, its impact 531 upon the performance and scalability of the network as a whole must 532 also be taken into account. For example, the performance and 533 scalability impact on the edge and internal routers is a very 534 important consideration. 536 5.4. Handover performance requirements on resource reservation scheme 538 Whatever reservation scheme is used must be highly performant for at 539 least the following reasons: 541 * Handover rates 543 In the GSM case, mobility usually generates an average 544 of one to two handovers per call. For third generation 545 networks (such as WCDMA and cdma2000), where it is 546 necessary to keep radio links to several cells 547 simultaneously (macro-diversity), the handover rate is 548 significantly higher (see for example [KeMc00]). 549 Therefore, the admission control process has to cope 550 with far more admission requests than call setups alone 551 would generate. 553 * Fast reservations 555 Handover can also cause packet losses. If the processing 556 of an admission request causes a delayed handover to the 557 new base station, some packets might be discarded, and 558 the overall speech quality might be degraded 559 significantly. 561 Furthermore, a delay in handover may cause degradation 562 for other users. This is especially true for radio access 563 technologies using macro-diversity, such as WCDMA and CDMA, 564 where a handover delay will cause interference for other 565 users in the same cell. Furthermore, in the worst case 566 scenario, a delay in handover may cause the connection 567 to be dropped if the handover occurred due to bad radio 568 link quality. 570 Therefore, it is critical that an admission control 571 request for handover be carried out very quickly. Since 572 the processing of an admission control request is only 573 one of many tasks performed during handover, the time to 574 perform admission control should be a fraction of the 575 time available for handover. 576 Furthermore, in the situation that the transport network 577 in the RAN is over-utilised it is preferable to keep 578 the reservation on already established flows while new 579 requests might be blocked. Therefore, the handover 580 requests for resource reservation should be treated 581 with a higher priority than the new requests for 582 resource reservation. 584 5.5. Edge-to-edge reservations, not end-to-end 586 Real-time applications require a high level of quality of service 587 (QoS) from the underlying transmission network. This can only be 588 achieved by accomplishing the QoS management on an end-to-end basis 589 (i.e., end user to end user), from application to application, 590 potentially across many domains. 592 However, this does not mean that the resource reservation protocol 593 must be applied end-to-end. The end-to-end QoS management 594 architecture may consist of many interoperable edge-to-edge QoS 595 management architectures where each of them might use a different 596 edge-to-edge resource reservation protocol. In fact, this is far 597 more likely to be the case than that a global signaling structure 598 will be available across all different domains in an end-to-end 599 perspective. This will increase the flexibility and the openness of 600 the transmission network since various access networks that are using 601 the same transmission network and different edge-to-edge QoS 602 management architectures will be able to interoperate. 604 It is critical that the appropriate mechanisms for providing the 605 service guarantees needed in the radio access network be put in place 606 independently of solving the more difficult problem of end-to-end 607 QoS. 609 In our case, the access network is simply an intranet in which we 610 need to solve a local QoS problem. This implies that a general 611 solution which handles the end-to-end QoS problem is unnecessarily 612 complicated for solving the intranet problem in the cellular access 613 network. 615 5.6. Reservation functionality in edge nodes versus interior routers 617 In our network, it is important that the reservation mechanism be as 618 simple as possible to implement in the interior nodes since in most 619 cases there might be more interior routers (<= 10 depending on 620 network structure) in the path than there are edge nodes. 622 Typically, in a RAN there are two edge nodes located in a 623 communication path. Moreover, the average number of interior nodes in 624 a communication path within a RAN depends on the chosen network 625 topology by the RAN operator. As such, the scheme must be optimized 626 for the interior nodes and not for the edge nodes, thus reducing the 627 requirements placed on the functionality of the interior routers. 628 This means that we can have complicated mapping of traffic parameters 629 at the edges and a simplified model in the interior nodes, and that 630 the necessary set of parameters required for setting up reservations 631 shall be based upon their effect on interior nodes and not on edge 632 nodes. 634 The edge routers typically have to perform per-session 635 management/control, and hence complex per flow handling is not a 636 significant burden. 638 However, interior nodes do not need to have per flow 639 responsibilities. We must therefore optimize for simple QoS 640 mechanisms on these interior devices, and use more complex mechanisms 641 in the edge devices. 643 In our case, edge device functionality is implemented in the first 644 hop router that the base station or BSC/RNC is connected to (see 645 Section 3.1). In this way we optimize for simple QoS mechanisms on 646 the interior devices, while the more complex mechanisms are applied 647 on the edge devices, e.g., base station, BSC/RNC. 649 This emphasis on simplicity is due to performance requirements listed 650 above. We need to make sure that we understand the minimal level of 651 functionality required in the reservation scheme in order to 652 guarantee the performance of real-time traffic. 654 5.7. On-demand and dynamic allocation of resources 656 Real-time services require that a portion of network resources is 657 available to them. These resources can be reserved on a static or 658 dynamic basis, or potentially based on some kind of measurement of 659 network load. 661 In the first situation, this may result in an poorly utilized 662 network. This is mainly due to the fact that the network resources 663 are typically reserved for peak real-time traffic values. Mobility 664 in the network makes static configuration even less desirable as the 665 resources will be used even less effectively. 667 If using dynamic allocation, this problem will be avoided since the 668 resources are reserved on demand. However, the load from resource 669 reservation will be much higher than if static allocation of 670 resources is used. If the dynamic allocation of the resources is 671 done on a micro-flow basis, the resulting network load from resource 672 reservation might be quite high. 674 We might use other methods, such as measurement-based admission 675 control, to simplify the reservation protocol, as long as these 676 methods can fulfill the requirements (now or in the future). 678 What is important is that all of these mechanisms can be used for 679 solving part of the network utilization problem, and, as such, any 680 reservation scheme must have the flexibility to provide both on- 681 demand reservations as well as measurement-based admission control. 683 As high bitrate and variable bitrate applications enter the cellular 684 space, the need for on-demand reservations of resources will become 685 even more acute. 687 5.8. Unicast and not multicast 689 The majority of the traffic in the RAN is point-to-point unicast 690 transport of radio frames between the base station and the BSC/RNC. 691 As such, the resource reservation scheme need not to be optimized for 692 multicast. 694 5.9. A single operator in the RAN 696 It is realistic to assume that end-to-end communication in IP 697 networks as well as the end-to-end QoS management architectures will 698 be managed by more than one operator. 700 Furthermore, it also realistic to assume that an edge-to-edge 701 resource reservation protocol can be managed by one single operator. 702 As such, it is reasonable to limit reservation scheme to a single 703 operator domain. This will ensure that each operator can optimize the 704 edge-to-edge QoS management architecture for their needs. Moreover, 705 this limitation (a single operator domain) means that the reservation 706 scheme does not need to handle the issues inherent in a multi- 707 operator domain, thus simplifying the scheme. 709 5.10. Minimal impact on router performance 711 The performance of each network node that is used in an end-to-end 712 communication path has a significant impact on the end-to-end 713 performance of this communication path. Therefore, the end-to-end 714 performance of the communication path can be optimized by optimizing 715 the router performance. It is absolutely critical that the 716 introduction of QoS mechanisms and signaling does not overly impact 717 the performance of the infrastructure. Obviously, you cannot 718 introduce new things that need to be done by networking 719 infrastructure without impacting its performance, but that impact 720 must be minimized to the greatest extent possible. 722 One of the factors that can contribute to this optimization is the 723 minimization of the resource reservation signaling protocol load on 724 each router. When the dynamic allocation of the resources is on a per 725 micro-flow basis, the resource reservation signaling protocol could 726 easily overload a router located in a core network, causing severe 727 router performance degradation. Furthermore, any mechanisms defined 728 must be such that it is reasonable to implement them in hardware 729 which will increase the scalability of the solution. 731 5.11. Scalably Manageable 733 Any strategy for resource management in a RAN must be done in such a 734 way that it is easily manageable in a very large network. This 735 implies as little "laying on of hands" as possible and as much 736 automation as possible. In networks made up of many thousands of 737 routers, changing of even a single parameter in all routers may be 738 prohibitively difficult. Minimizing the involvement of the operator 739 (or the operator's management tools) is therefore an important 740 requirement. 742 5.12. Bi-directional reservations 744 In current RANs, the BSC/RNC is responsible for initiation of 745 reservation of resources in the transport plane. Therefore, via the 746 resource reservation signaling protocol, the BSC/RNC has to support 747 the initiation and management of the resource reservations for both 748 directions, both to and from the base station, simultaneously. In 749 this way a simpler edge-proxy resource reservation functionality will 750 be implemented in the base station, decreasing its complexity. 752 6. Evaluation of existing strategies 754 In order to understand whether technology exists today which will 755 allow us to manage the resources in cellular networks, we briefly 756 look at the protocols that currently exist which address parts or all 757 of these requirements. 759 6.1. End-to-end per-flow resource reservation protocol 761 An end-to-end per-flow resource reservation signaling protocol is 762 applied in an end-to-end IP communication path, and it can be used by 763 an application to make known and reserve its QoS requirements to all 764 the network nodes included in this IP communication path. This type 765 of protocol is typically initiated by an application at the beginning 766 of a communication session. A communication session is typically 767 identified by the combination of the IP destination address, 768 transport layer protocol type and the destination port number. The 769 resources reserved by such a protocol for a certain communication 770 session will be used for all packets belonging to that particular 771 session. Therefore, all resource reservation signaling packets will 772 include details of the session to which they belong. 774 The end-to-end per-flow resource reservation signaling protocol most 775 widely used today is the Resource Reservation Protocol (RSVP) (see 776 [RFC2210], [RFC2205]). The main RSVP messages are the PATH and RESV 777 messages. The PATH message is sent by a source that initiates the 778 communication session. It installs states on the nodes along a data 779 path. Furthermore, it describes the capabilities of the source. The 780 RESV message is issued by the receiver of the communication session, 781 and it follows exactly the path that the RSVP PATH message traveled 782 back to the communication session source. On its way back to the 783 source, the RESV message may install QoS states at each hop. These 784 states are associated with the specific QoS resource requirements of 785 the destination. The RSVP reservation states are temporary states 786 (soft states) that have to be updated regularly. This means that PATH 787 and RESV messages will have to be retransmitted periodically. If 788 these states are not refreshed then they will be removed. The RSVP 789 protocol uses additional messages either to provide information about 790 the QoS state or explicitly to delete the QoS states along the 791 communication session path. RSVP uses in total seven types of 792 messages: 794 * PATH and RESV messages 796 * RESV Confirm message 798 * PATH Error and RESV Error messages 800 * PATH Tear and RESV Tear messages 802 An overview of the functionality of the RSVP functionality includes: 804 * End-to-end reservation with aggregation of path 805 characteristics such as fixed delay. 807 * The same type of reservation functionality in all 808 routers. Only policy handling separates the edge of the 809 domain from other routers. 811 * Multicast and unicast reservations with receiver initiated 812 reservations. RSVP makes reservations for both unicast and 813 many-to-many multicast applications, adapting dynamically 814 to changing routes as well as to group membership. 816 * Shared reservations for multiple flows. 818 * Support for policy handling to handle multi-operator 819 situations since more than one operator will be 820 responsible for RSVP's operation. 822 * Flexible object definitions. RSVP can transport and maintain 823 traffic and policy control parameters that are opaque to 824 RSVP. Each RSVP message may contain up to fourteen classes of 825 attribute objects. Furthermore, each class of RSVP objects 826 may contain multiple types to specify further the format 827 of the encapsulated data. Moreover, the signaling load 828 generated by RSVP on the routers is directly proportional 829 to the flows processed simultaneously by these routers. 830 Furthermore, processing of the individual flows in the 831 networking infrastructure may impose a significant processing 832 burden on the machines, thus hurting throughput. These 833 issues make it reasonable to question the scalability and 834 performance in a large cellular radio access network. 836 * support for uni-directional reservations, not bi-directional. 838 In the situation where a mobile moves or the connection moves from 839 one base station to another, it could force the communication path to 840 change its (source/dest) IP address. The change of IP address will 841 require that RSVP establish a new RSVP session through the new path 842 that interconnects the two end points involved in the RSVP session 843 and release the RSVP session on the old path. During this time, the 844 end-to-end data path connection is incomplete (i.e., QoS disruption) 845 and it will negatively affect the user performance. 847 This approach includes much more functionality and complexity than is 848 required in the cellular RAN. Our problem is significantly simpler to 849 solve. The trade-off between performance and functionality is one of 850 the key issues in the RAN. In our case, the majority of the 851 functionality in RSVP is not required. This is true for four 852 reasons: 854 * Unicast reservations are much less complex than multicast. 856 * Edge-to-edge with one operator does not require policy 857 handling in the interior routers. 859 * Path characteristics and flexible traffic parameters and 860 QoS definitions could be solved by network dimensioning 861 and edge functionality. 863 * Per microflow states in intermediate routers cause severe 864 scalability problems. Furthermore, receiver-initiated 865 reservations impose high complexity in the states due to 866 reverse-direction routing of the RESV messages. A scheme 867 based on sender oriented reservation (see e.g., [AhBe99]) 868 decreases the complexity of the per microflow states due 869 to the fact that no reverse-direction routing is 870 required. 872 6.2. Integrated Services over Differentiated Services 874 The IntServ over DiffServ framework addresses the problem of 875 providing end-to-end QoS using the IntServ model over heterogeneous 876 networks. In this scenario, DiffServ is one of these networks 877 providing edge-to-edge QoS. This is similar to the underlying 878 architecture for this draft, where the specific network is the 879 cellular RAN, and where the end-to-end model is unspecified. As such, 880 the problem addressed by IntServ over DiffServ is similar in nature 881 to the problem described here, although the specific requirements 882 (such as network utilization and performance) are different. 884 The IntServ over DiffServ framework discusses two different possible 885 deployment strategies. The first is based on statically allocated 886 resources in the DiffServ domain. In this strategy the Diffserv 887 domain is statically provisioned (see Section 6.3). Furthermore, in 888 this strategy the devices in the Diffserv network region are not RSVP 889 aware. However, it is considered that each edge node in the customer 890 network is consisting of two parts. One part of a node is a standard 891 Intserv that interfaces to the customer's network region and the 892 other part of the same node interfaces to the Diffserv network 893 region. Any edge node in the customer network maintains a table that 894 indicates the capacity provisioned per SLS (Service Level 895 Specification) at each Diffserv service level. This table is used to 896 perform admission control decisions on Intserv flows that cross the 897 Diffserv region. A disadvantage of this approach is that the edge 898 nodes in the customer network will not be aware of the traffic load 899 in the nodes located within the Diffserv domain. Therefore, a 900 congestion situation on a communication path within the Diffserv 901 domain cannot be predicted by any of these edge nodes. Due to the 902 "Efficient network utilization" requirement explained in Section 5.3, 903 the RAN is dimensioned such that it may have performance bottlenecks 904 which are not visible to the edges. More advantages and disadvantages 905 of this approach are discussed in Section 6.3. 907 The second possible strategy is based on dynamically allocated 908 resources in the DiffServ domain. According to [RFC2998], this can be 909 done using RSVP-aware DiffServ routers. However, this approach has 910 most of the drawbacks described in Section 6.1, and per-microflow 911 state information is kept in the intermediate routers. 913 Alternatively, resources in the DiffServ domain can be dynamically 914 allocated using Aggregated RSVP. This will be discussed in Section 915 6.4. 917 Other approaches related to the bandwidth broker concept are still 918 very immature and will not be discussed here. 920 6.3. Statically-assigned trunk reservations based on Differentiated 921 Services 923 A significant problem in deploying an end-to-end per-flow resource 924 reservation signaling scheme is its scalability. This can be solved 925 by aggregating (trunking) several individual reservations into a 926 common reservation trunk. The reservation trunks can be either 927 statically or dynamically configured. When the reservation trunks 928 are statically configured, no signaling protocol is required for 929 performing the reservation of network resources but is likely to be a 930 difficult management problem. However, due to the different mobility 931 requirements (such as handover) and QoS requirements (such as 932 bandwidth) that the multi-bitrate applications impose on the RAN, it 933 will be difficult to configure the trunked reservations statically 934 and utilize the RAN efficiently. 936 6.4. Dynamic trunk reservations with Aggregated RSVP 938 The reservation trunks can be dynamically configured by using a 939 signaling protocol that manages various mechanisms for dynamic 940 creation of an aggregate reservation, classification of the traffic 941 to which the aggregate reservation applies, determination of the 942 bandwidth needed to achieve the requirement and recovery of the 943 bandwidth when the sub-reservations are no longer required. 945 The first router that handles the aggregated reservations could be 946 called an Aggregator, while the last router in the transit domain 947 that handles the reservations could be called a Deaggregator. 949 The Aggregator and Deaggregator functionality is located in the edge 950 nodes. In particular, an Aggregator is located in an ingress edge 951 node, while a Deaggregator is located in an egress edge node, 952 relative to the traffic source. 954 The aggregation region consists of a set of aggregation capable 955 network nodes. The Aggregator can use a policy that can be based on 956 local configuration and local QoS management architectures to 957 identify and mark the packets passing into the aggregated region. 958 For example, the Aggregator may be the base station that aggregates a 959 set of incoming calls and creates an aggregate reservation across the 960 edge-to-edge domain up to the Deaggregator. In this situation the 961 call signaling is used to establish the end-to-end resource 962 reservations. Based on policy, the Aggregator and Deaggregator will 963 decide when the Aggregated states will be refreshed or updated. 965 One example of a protocol that can be used to accomplish QoS dynamic 966 provisioning via trunk reservations is the RSVP Aggregation signaling 967 protocol specified in [BaIt00]. 969 With regards to aggregated RSVP, even if the reservation is based on 970 aggregated traffic, the number of re-negotiations of the allocated 971 resources due to mobility (handover) does not decrease and each re- 972 negotiation of resources has the same performance requirements as the 973 per-flow reservation procedure. 975 Note that the aggregated RSVP solution may use a policy to maintain 976 the amount of bandwidth required on a given aggregate reservation by 977 taking account of the sum of the underlying end to end reservations, 978 while endeavoring to change it infrequently. However, such solutions 979 (policies) are very useful assuming that the cost of the 980 overprovisioned bandwidth is not significant, since this implies the 981 need for a certain "slop factor" in bandwidth needs. In a RAN, where 982 overprovisioning is not preferable due to high costs of transmission 983 links, a more dynamic QoS provisioning solution is needed. 985 Furthermore, the aggregated RSVP scheme is receiver initiated and 986 cannot support bi-directional reservations. 988 In the aggregated RSVP scheme the resource reservation states stored 989 in all the RSVP aware Edge and Interior nodes represent aggregated 990 RSVP sessions (i.e., trunks of RSVP sessions). Therefore, the number 991 of the resource reservation states in the aggregated RSVP scheme 992 compared to the (per-flow) RSVP scheme, is decreased. However, in a 993 Diffserv based RAN the number of the aggregated RSVP sessions depends 994 on: 996 * the number of Aggregators/Deaggregators; Considering 997 that each base station and each BSC/RNC is used as 998 Aggregator/Deaggregator, the total number of 999 Aggregators/Deaggregators within the RAN is 1000 significantly high. This is due to the fact 1001 that the number of BSCs/RNCs is significantly 1002 high and the number of base stations in a RAN is 1003 in the range of thousands, see Section 3.1. 1004 * the network topology used; The communication between 1005 RNCs is performed in a meshed way, i.e., all to all 1006 communication. This will imply that many communication 1007 paths will have to be maintained by the RAN 1008 simultaneously. 1009 * the number of Diffserv Code Points (DSCPs) used; More 1010 than one traffic classes will be supported 1011 within the RAN. Therefore, the number of the Diffserv 1012 Code Points (DSCPs) used within the RAN will probably 1013 be higher than one. 1015 Therefore, the number of the aggregated RSVP reservation states 1016 within a Diffserv based RAN will be significantly large. 1018 7. Conclusion 1020 Cellular radio access networks and coming wireless applications 1021 impose different requirements on reservation strategies than typical 1022 Internet conditions. 1024 Firstly, the reservation solution does not need to have the same 1025 level of complexity: 1027 * Edge-to-edge not end-to-end: The IP traffic is generated 1028 in the network and is only transported as far as the 1029 cellular-specific nodes (such as the base station and 1030 BSC/RNC). 1032 * Single operator domain and no inter-domain transport: The 1033 transport is owned and managed by a single operator. 1035 * Only unicast not multicast: The end-to-end payload is 1036 transported between nodes. This transport only requires 1037 a unicast reservation. 1039 Furthermore, a cellular radio access network has much higher 1040 performance requirements on the reservation strategy: 1042 * Efficient usage of the transmission network: The transport 1043 between the BSC/RNC and the base station represents a significant 1044 cost for the cellular operator, and efficient usage of 1045 the transmission network is therefore critical from a cost 1046 point of view. The network should allow dynamic allocation 1047 of resources to allow efficient statistical aggregation 1048 of traffic without causing congestion. 1050 * A wide-area network with significant volume of real-time 1051 traffic: Real-time traffic levels up 100% must be 1052 supported. 1054 * The resource reservation process has to handle a 1055 significantly higher volume of requests, and the process 1056 has to be fast enough to avoid packet losses in the 1057 air-interface during handover. 1059 * The scheme must be optimal for interior nodes and not 1060 for the edge nodes. In this way the necessary set of 1061 parameters required for setting up reservations should be 1062 based upon their effect on interior nodes and not on edge 1063 nodes. This reduces the complexity on the interior routers. 1065 Given these requirements, we believe that appropriate standardization 1066 should take place to create the necessary protocols for edge-to-edge 1067 resource management for a single operator domain. 1069 8. References 1071 [AhBe99] Ahlard, D., Bergkvist, J., Cselenyi, I., "Boomerang 1072 Protocol Specification", Internet draft, Work in progress. 1074 [BaIt00] Baker, F., Iturralde, C. Le Faucher, F., Davie, B., 1075 "Aggregation of RSVP for Ipv4 and Ipv6 Reservations", 1076 Internet draft, Work in progress. 1078 [KeMc00] Kempf, J., McCann, P., Roberts, P., " IP Mobility 1079 and the CDMA Radio Access Network: Applicability 1080 Statement for Soft Handoff", Internet draft, Work 1081 in progress. 1083 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., 1084 "Resource ReSerVation Protocol (RSVP) -- Version 1 1085 Functional Specification", IETF RFC 2205, 1997. 1087 [RFC2210] Wroclawski, J., "The use of RSVP with IETF Integrated 1088 Services", IETF RFC 2210, 1997. 1090 [WeLi99] Westberg, L., Lindqvist, M., "Realtime Traffic over 1091 Cellular Access Networks", Internet draft, Work in 1092 progress (expired). 1094 [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., baker, F., Zhang, L., 1095 Speer, M., Braden, R., Davie, B., "Felstaine, E., 1096 "Framework for Integrated Services operation over 1097 Diffserv Networks", IETF RFC 2998, 2000. 1099 9. Acknowledgements 1101 Special thanks to Brian Carpenter, Steven Blake, Phil Chimento, 1102 Anders Bergsten, Marc Greis, Hamad el Allali, 1103 Nicola Blefari-Melazzi, Giuseppe Bianchi and Geert Heijenk for 1104 providing useful comments and input. 1106 10. Authors' Addresses 1108 David Partain 1109 Ericsson Radio Systems AB 1110 P.O. Box 1248 1111 SE-581 12 Linkoping 1112 Sweden 1113 EMail: David.Partain@ericsson.com 1115 Georgios Karagiannis 1116 Ericsson EuroLab Netherlands B.V. 1117 Institutenweg 25 1118 P.O.Box 645 1119 7500 AP Enschede 1120 The Netherlands 1121 EMail: Georgios.Karagiannis@eln.ericsson.se 1123 Pontus Wallentin 1124 Ericsson Radio Systems AB 1125 P.O. Box 1248 1126 SE-581 12 Linkoping 1127 Sweden 1128 EMail: Pontus.Wallentin@era.ericsson.se 1130 Lars Westberg 1131 Ericsson Research 1132 Torshamnsgatan 23 1133 SE-164 80 Stockholm 1134 Sweden 1135 EMail: Lars.Westberg@era-t.ericsson.se 1137 Table of Contents 1139 1 Abstract ........................................................ 2 1140 2 Terminology ..................................................... 3 1141 3 Background and motivation ....................................... 3 1142 3.1 IP transport in radio access networks ......................... 4 1143 3.2 Motivation for this memo ...................................... 7 1144 4 Network characteristics of cellular access networks today ....... 8 1145 4.1 General aspects of the network structure ...................... 8 1146 4.2 High cost for transmission .................................... 9 1147 4.3 Transportation of radio frames ................................ 10 1148 4.4 Mobility aspect of radio frame transport ...................... 12 1149 5 Requirements on a Resource Reservation Scheme ................... 12 1150 5.1 Main requirement on resource reservation scheme ............... 12 1151 5.2 IP must provide same service behavior as the transport net� 1152 works used today ............................................. 13 1153 5.3 Efficient network utilization ................................. 13 1154 5.4 Handover performance requirements on resource reservation 1155 scheme 1156 ......................................................... 14 1157 5.5 Edge-to-edge reservations, not end-to-end ..................... 15 1158 5.6 Reservation functionality in edge nodes versus interior 1159 routers ...................................................... 16 1160 5.7 On-demand and dynamic allocation of resources ................. 17 1161 5.8 Unicast and not multicast ..................................... 17 1162 5.9 A single operator in the RAN .................................. 18 1163 5.10 Minimal impact on router performance ......................... 18 1164 5.11 Scalably Manageable .......................................... 19 1165 5.12 Bi-directional reservations .................................. 19 1166 6 Evaluation of existing strategies ............................... 19 1167 6.1 End-to-end per-flow resource reservation protocol ............. 19 1168 6.2 Integrated Services over Differentiated Services .............. 22 1169 6.3 Statically-assigned trunk reservations based on Differenti� 1170 ated Services ................................................ 23 1171 6.4 Dynamic trunk reservations with Aggregated RSVP ............... 23 1172 7 Conclusion ...................................................... 25 1173 8 References ...................................................... 27 1174 9 Acknowledgements ................................................ 27 1175 10 Authors' Addresses ............................................. 28