idnits 2.17.1 draft-partain-wireless-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 459 has weird spacing: '... cannot be pe...' == Line 1104 has weird spacing: '...rements on r...' == Line 1108 has weird spacing: '...rvation funct...' -- 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 (April 2001) is 8412 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' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Wireless Resources Issues April 2001 4 Internet Engineering Task Force D. Partain (ed) 5 INTERNET-DRAFT G. Karagiannis 6 Expires October 2001 P. Wallentin 7 L. Westberg 8 Ericsson 9 April 2001 11 Resource Reservation Issues in Cellular Access Networks 12 draft-partain-wireless-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. 77 2. Terminology 79 The following terminology is used in this memo: 81 * BSC: Base Station Controller 83 * RNC: Radio Network Controller 85 * MSC: Mobile Services Switching Center 87 * GGSN: Gateway GPRS Support Node 89 * SGSN: Serving GPRS Support Node 91 * GPRS: General Packet Radio Service, the packet-switched access 92 scheme and service provided in GSM. 94 * GSM: Global System for Mobile Communications 96 * UMTS: Universal Mobile Telecommunications System, the third 97 generation (3G) mobile system based on WCDMA and GSM, 98 specified by 3GPP (third generation partnership project). 100 * radio frame: a short data segment coded/decoded and 101 transmitted/received by the radio base station. 102 It originates from a mobile station or the BSC/RNC. 104 * WCDMA: Wideband Code Division Multiple Access, the 105 radio transmission technology used in UMTS 107 3. Background and motivation 109 The context of the issues described in this document is the cellular 110 radio access network (RAN). This section briefly discusses two 111 examples of radio access networks (for GSM - Global System for Mobile 112 Communication - and for WCDMA - Wideband Code Division Multiple 113 Access) and then outlines the motivation for this memo. 115 3.1. IP transport in radio access networks 117 This section introduces the radio access network and its use of IP 118 transport. A radio access network (RAN) provides the radio access 119 (e.g., GSM, CDMA, or WCDMA) to mobile stations for a cellular system. 120 The boundaries for a RAN are the radio transmission and reception 121 access points (terminated by base stations) at one end and, at the 122 other end, the interfaces to the gateways (e.g., MSC and SGSN/GGSN), 123 which in turn provide connections to the fixed public network. 125 The radio access network consists of a number of nodes as shown in 126 the Figure 1 below. 128 IP IP 129 <---> <---> 131 |---------| |---------| |---------| 132 Mobile v | Base | | | | MSC/ | Fixed 133 stations |--| station |-----| BSC/RNC |-----| SGSN/ |--- public 134 ^ | | ^ | | ^ | GGSN | network 135 | |---------| | |---------| | |---------| 136 | | | 137 Wireless Wired Wired 138 interface interface interface 140 Radio access network 141 <-------------------------------> 143 Figure 1: Typical radio access network and its boundaries 145 The base station provides the radio channel coding/decoding and 146 transmission/reception function to and from mobile stations in its 147 coverage area, which is called a cell. 149 The BSC/RNC controls a number of base stations including the radio 150 channels and the connections to mobile stations. For a WCDMA radio 151 access network, the BSC/RNC provides soft handover combining and 152 splitting between streams from different base stations belonging to 153 the same mobile station. Furthermore, the BSC/RNC is also 154 responsible for the allocation of transport resources within the 155 radio access network. The transport is either between the base 156 station and the BSC/RNC, between multiple BSC/RNCs, or between the 157 BSC/RNC and the MSC/SGSN. The MSC/SGSN/GGSN controls, among others, 158 the calls between the mobile stations and fixed public networks (e.g. 159 the PSTN - Public Switched Telephone Network or the public Internet). 161 The radio access network consists of potentially thousands of base 162 stations and a significant number of BSCs/RNCs. The traffic volume, 163 in terms of voice-traffic, generated by these nodes can vary from a 164 few up to fifty voice calls per base station, and up to several 165 thousand simultaneous calls (Erlang) per BSC/RNC site. Therefore, a 166 router in the network has to handle many thousands of simultaneous 167 flows. 169 The transmission between base stations and the BSC/RNC is usually on 170 leased lines, and this part (due to the wide area coverage of the 171 cellular network) is usually extremely expensive when compared to the 172 cost of transmission in the backbone. Due the number of base 173 stations, the cost for these leased lines can be quite significant. 174 Dimensioning using over-provisioning might therefore be prohibitively 175 expensive, and it is unlikely that the network will be dimensioned 176 without using the statistical properties of traffic aggregation 177 (e.g., Erlang trunking). 179 |--------| 180 | Upper |<--------------------------------------------> towards the 181 | layers | MSC/SGSN/GGSN 182 |--------| |---------|--------| 183 | Radio | | Radio | | 184 | Link |<----------------------------------->| Link | | 185 | Layer | | Layer | | 186 |--------| |---------| | 187 | | |Radio | |<- 188 | | |Physical | Frame | 189 | | |Layer | transp.| 190 | | |-------|--------| |---------| layer | 191 | | | | Frame |<-------------->| Frame | | 192 | | | | transp.| | transp. | | 193 |Radio | | Radio |--------| |---------|--------| 194 |Physical| | Phys. | UDP |<-------------->| UDP | UDP | 195 |Layer |<->| Layer |--------| |--------| |---------|--------| 196 | | | | IP |<->| IP |<->| IP | IP | 197 | | | |--------| |--------| |---------|--------| 198 | | | | Link | | Link |<->| Link | Link | 199 | | | | Layer |<->| Layer | | Layer | Layer | 200 | | | |--------| |--------| |---------|--------| 201 | | | |Physical| |Physical| |Physical |Physical| 202 | | | | Layer |<->| Layer |<->| Layer | Layer | 203 |--------| |-------|--------| |--------| |------------------| 204 Mobile Base station Router BSC/RNC 205 Station ^ ^ ^ 206 | | | 207 Wireless Wired Wired 208 interface interface interface 210 Radio access network 211 <-----------------------------------------------------> 213 Figure 2: Example of a protocol stack in the 214 radio access network (simplified) 216 Figure 2 shows a simplified example of protocol layering when using 217 IP transport in the radio access network. 219 The radio physical layer performs radio transmission and reception 220 functions, including soft handover splitting and combining in case of 221 WCDMA. 223 The frame transport layer is used to transmit radio frames between 224 the base station and the BSC/RNC. A radio frame is a short data 225 segment coded/decoded and transmitted/received by the radio base 226 station at a given point in time. The radio frames must be delivered 227 in a timely fashion with limited delay. Otherwise, the frames are 228 discarded by the base station or RNC/BSC. The traffic is therefore 229 very sensitive to delays. 231 The radio link layer performs segmentation/re-assembly, 232 retransmission and multiplexing/scheduling functions as well as radio 233 resource control. The adaptation of user data performed by the radio 234 link layer depends on the type of radio channel and the type of 235 service. In one case, that very small radio frames might be 236 transferred, while in other cases the packets are significantly 237 larger. 239 Introducing IP in the radio access network implies that an IP QoS- 240 capable domain, e.g. a Differentiated Services domain, will have to 241 be introduced and managed in the radio access network. This domain 242 consists of edge and interior nodes, where the edge nodes are the 243 nodes located at the boundary of the domain. All the nodes which are 244 part of this QoS-capable domain and are not edge nodes are defined as 245 interior nodes. 247 An edge node can be defined as an ingress node, or a node that 248 handles the traffic as it enters the QoS-capable domain. 249 Alternatively, an edge node might be an egress node, or a node that 250 handles the traffic as it leaves the QoS-capable domain. In this 251 memo, an edge node (ingress or egress) is denoted as the first hop 252 router that the base station or BSC/RNC is connected to. The first 253 hop router might be a part of the base station or BSC/RNC. 255 Furthermore, the base station and BSC/RNC must be able to handle 256 algorithms used for purposes other than edge node functionality that 257 are many times more complex than the algorithms required for handling 258 the edge node functionality. Therefore, the edge node functionality 259 will only have minimal impact on the complexity of the base station 260 or BSC/RNC. 262 3.2. Motivation for this memo 264 The issues described in this document concern only the cellular radio 265 access network (RAN). 267 The architecture of the RAN and the nature of the transported data 268 mean that the RAN has different characteristics when compared with 269 other IP-based networks. However, those differences, which are the 270 motivation for this memo, are limited to the domain of the RAN and do 271 not extend into the backbone of the IP network. 273 In order for the transport within the RAN to function satisfactorily, 274 even if the transport network is IP-based, we need to ensure that 275 there are adequate resources in the transport network to meet the 276 needs of the data flows between the nodes within the RAN. 278 Based upon the characteristics of the RAN (described in Section 4 279 below), the current strategies for resource management do not meet 280 the requirements for an appropriate resource management strategy 281 within a RAN. This document seeks to initiate a dialog on how to 282 correct that situation. 284 4. Network characteristics of cellular access networks today 286 Cellular RANs today have a unique set of characteristics compared to 287 other kinds of IP networks. These characteristics result in a set of 288 requirements on any resource reservation scheme that might be used in 289 the RAN. 291 4.1. General aspects of the network structure 293 The network structure for cellular radio access networks can be 294 described as having the following characteristics: 296 * Operator relationship 298 The RAN is typically controlled by a single cellular operator 299 with full control over the network. The IP network used to 300 transport radio frames might be leased from another operator 301 or be built by the same cellular operator. This network 302 could be thought of as an "intranet". 304 * Size of network 306 RANs can be very large routed networks. Networks including 307 thousands of nodes are certainly within reason. 309 * Traffic volume 311 The traffic from a large number of radio base stations 312 needs to be supported by the same transport network. Even 313 if a single radio base station generates a modest volume of 314 traffic, the total number of flows for radio frame transport 315 in the radio access network is very large. 317 * Transmission sharing 319 The network between the BSC/RNC and the base stations is 320 built to support transmission sharing between different 321 nodes even if they are geographically distributed. 322 One transmission link (possibly with redundancy) can 323 support more than one base station. In other words, one 324 piece of hardware can serve more than one base station and 325 therefore can support more cells in one location, such as 326 a three sector site. This means that the cells that are 327 located at the same location will have to compete for the 328 same transmission resources. 330 * Unicast transport of radio frames 332 The transport of radio frames in the radio access network is 333 point-to-point transport. Even if the soft handover splitting 334 in the BSC/RNC is multicast of radio frames in some sense, 335 this is handled above the IP layer by the frame transport 336 protocol. For each radio channel in each base station the 337 frame transport protocol needs a separate flow. Therefore, 338 the frame transport protocol requires unicast transmission 339 from the IP layer. 341 4.2. High cost for transmission 343 The transmission between base stations and the BSC/RNC is usually on 344 leased lines, and this part (due to the wide area coverage of the 345 cellular network) is usually extremely expensive when compared to the 346 cost of transmission in the backbone. Due to the number of base 347 stations, the cost for these leased lines can be quite significant. 348 Even if the cost for the leased line decreases over the years, the 349 "last mile" to the base station is likely to be expensive due to the 350 location of the base station. 352 Cellular RANs are built over a very wide geographic area. There are, 353 of course, many different networks that cover a wide geographic area 354 (e.g., across USA, and the world), but the dispersion of nodes over 355 the area in the RAN case is different. Due to the fact that the base 356 stations are positioned based on a radio network perspective, i.e., 357 radio coverage, and not based on a transmission perspective, a large 358 proportion of nodes are distributed throughout rural and urban areas, 359 not close to installed high-capacity transmission hubs. Even worse, 360 the the base stations could be positioned far out in the countryside. 362 The peak bitrate of the multirate radio channels is selected on- 363 demand. To utilize the bandwidth of the expensive transmission links 364 used for radio frame transport efficiently, dimensioning using over- 365 provisioning might therefore be prohibitively expensive, and it is 366 unlikely that the network will be dimensioned for peak allocation. 367 Dynamic allocation and optimization to reduce the cost are therefore 368 a fundamental requirement. Resource reservations make it possible to 369 have high utilization of the network for real-time sensitive traffic 370 as well as avoiding congestion in the network. 372 4.3. Transportation of radio frames 374 The traffic in cellular access networks is dramatically different 375 from the Internet in general. The Internet primarily supports best- 376 effort traffic today, while the traffic on a RAN is (at least today) 377 largely real-time traffic. The network from the base station to the 378 BSC/RNC is the part of the network that has the highest volume of 379 real-time traffic and where delay must be minimized as much as 380 possible. The reasons for the this are: 382 * End-to-end delay for speech traffic consists of delays in the 383 mobile stations, the RAN and in the MSC (see Figure 1 in 384 Section 3.1). The major portion of delay in the RAN is caused 385 by the radio-related functionality (e.g., interleaving and 386 coding in the base station and adaptation in the BSC/RNC). 387 Therefore, the combined delay in all parts (MSC, radio 388 network, and mobile stations) must be minimized as much 389 as possible to give the end user proper speech quality. 391 * Handover is a major issue. For GSM, with typically multiple 392 handovers per call, excessive delay in the control, e.g. 393 radio network control traffic, of the radio network will 394 cause a longer handover interruption period. The majority 395 of handovers are also made within the radio network. 397 * The transport of radio frames is very delay-sensitive. In 398 the direction from the BSC/RNC to the base station, a radio 399 frame is a short segment of data (payload) to be coded and 400 transmitted on a given radio channel by the base station at a 401 given point in time. In the direction from the base station 402 to the BSC/RNC, a radio frame is a short segment of data 403 (payload) that was received and decoded by the base station 404 at a given point in time and potentially needs to be combined 405 in the BSC/RNC with radio frames received by other base 406 stations at the same point in time as this particular frame. 407 Note that the data segment in a radio frame may contain user 408 data but also control signalling information and the same 409 type of synchronized frame transport is needed for almost 410 all kinds of radio channels and is generally not coupled 411 to the type of service. Therefore, even if an end to end 412 application is best effort, the transport of the radio frames 413 originating from this application might be treated as real-time 414 within the radio access network. 416 The real-time traffic on the RANs is today almost exclusively voice 417 (up to 90% with 10% signalling), but the cellular systems are 418 evolving to provide capabilities for other kinds of real-time traffic 419 (e.g., video). Nonetheless, voice continues to be one of the most 420 important sources of revenue in most cellular environments today. The 421 transport resources are today allocated when the call is accepted, 422 and the radio frame transport over an IP network has to provide the 423 same guarantees. If real-time traffic cannot be engineered to work 424 correctly, the primary revenue stream will disappear. 426 Some of the sources, such as video-based services and gaming, will be 427 able to send data at a variable bitrate at higher rates. For radio, 428 the rates of the radio channels are selected on-demand. In reality, 429 the radio network can support a wide range of partitioning of the 430 radio resources among the different radio channels. A rather large 431 portion of the transmission resources between the base station and 432 BSC/RNC will have to be allocated for such services. To be able to 433 utilize the bandwidth used for radio frame transport efficiently, the 434 same flexibility is required in assignment of the transport resources 435 as in the air-interface. Therefore, statically-assigned resources 436 will induce a cost which is too high for the operator. 438 4.4. Mobility aspect of radio frame transport 440 The mobility of the mobile stations imposes strong requirements on 441 managing the transmission resources available in the RAN, 442 Furthermore, this also implies that there are strong requirements on 443 the RAN's internal signaling and not only on transferring of packets 444 sent by the mobile station. 446 Hard handover is one of the issues. For GSM, with typically multiple 447 handovers per call, excessive delay in the control of the radio 448 network will cause a longer handover interruption period. Typically, 449 most of the handovers will be made between base stations controlled 450 by the same BSC and therefore extensive delay between base station 451 and BSC will degrade more than delays in the MSC and SGSN/GGSN 452 network. 454 Moreover, for maximal utilization of radio spectrum in WCDMA (and 455 also in CDMA), fast and frequent (soft) handover operations between 456 radio channels and radio base stations are required. The frequency of 457 handover events is therefore typically higher in WCDMA radio access 458 networks than in GSM and means even higher performance requirements 459 on the transport solution. If the soft handover cannot be performed 460 fast enough, spectrum cannot be utilized efficiently, which will 461 cause degradation of the radio network capacity. At each handover 462 event, resource reservation is needed, and therefore resource 463 reservation needs to be fast and will be used very frequently. 465 The impact of mobility in the radio access network has therefore two 466 major differences compared to the fixed network: 467 (1) High volume of resource reservation events 468 (2) Requirement on short response time for reservations 470 5. Requirements on a Resource Reservation Scheme 472 This section outlines what we believe are the fundamental 473 requirements placed on any resource reservation scheme in a cellular 474 radio access network. Later sections will outline how current schemes 475 match these requirements. 477 5.1. Main requirement on resource reservation scheme 479 One of the primary requirements that real-time applications impose on 480 any resource reservation scheme is the provisioning of good QoS 481 (delay and packet loss) guarantees. This can only be achieved if the 482 network can be utilized while avoiding congestion and without having 483 too high packet losses. The level of utilization depends on network 484 topology, traffic mix, scheduling discipline, delay and packet loss 485 requirements. The utilization is given by network dimensioning but 486 should be as high as possible. 488 The resource reservation scheme must be able to keep the real-time 489 traffic under a certain pre-defined network utilization in order to 490 avoid congestion. If you do not, it is difficult to guarantee the 491 QoS requirements for real-time traffic. 493 5.2. IP must provide same service behavior as the transport networks 494 used today 496 Today's commercial IP networks are mainly optimized to carry best- 497 effort traffic. As explained above and also discussed in [WeLi99], 498 the transport of radio frames in the radio access network puts real- 499 time requirements on the underlying transport network. All of these 500 characteristics are fulfilled by the connection-oriented transport 501 networks (STM and ATM) used by cellular networks today. By, at a 502 minimum, meeting these same requirements, the IP networks will be 503 capable of providing the same behavior as the transport networks that 504 are currently used by cellular systems while gaining the advantages 505 of IP networking. 507 5.3. Efficient network utilization 509 Due to the high cost of the leased transmission, we must utilize the 510 network to the highest degree possible, and this must be facilitated 511 by the resource reservation scheme. 513 However, in considering a resource reservation scheme, its impact 514 upon the performance and scalability of the network as a whole must 515 also be taken into account. For example, the performance and 516 scalability impact on the edge and internal routers is a very 517 important consideration. 519 5.4. Handover performance requirements on resource reservation scheme 521 Whatever reservation scheme is used must be highly performant for at 522 least the following reasons: 524 * Handover rates 526 In the GSM case, mobility usually generates an average 527 of one to two handovers per call. For third generation 528 networks (such as WCDMA and cdma2000), where it is 529 necessary to keep radio links to several cells 530 simultaneously (macro-diversity), the handover rate is 531 significantly higher (see for example [KeMc00]). 532 Therefore, the admission control process has to cope 533 with far more admission requests than call setups alone 534 would generate. 536 * Fast reservations 538 Handover can also cause packet losses. If the processing 539 of an admission request causes a delayed handover to the 540 new base station, some packets might be discarded, and 541 the overall speech quality might be degraded 542 significantly. 544 Furthermore, a delay in handover may cause degradation 545 for other users. This is especially true for radio access 546 technologies using macro-diversity, such as WCDMA and CDMA, 547 where a handover delay will cause interference for other 548 users in the same cell. Furthermore, in the worst case 549 scenario, a delay in handover may cause the connection 550 to be dropped if the handover occurred due to bad radio 551 link quality. 553 Therefore, it is critical that an admission control 554 request for handover be carried out very quickly. Since 555 the processing of an admission control request is only 556 one of many tasks performed during handover, the time to 557 perform admission control should be a fraction of the 558 time available for handover. 560 5.5. Edge-to-edge reservations, not end-to-end 562 Real-time applications require a high level of quality of service 563 (QoS) from the underlying transmission network. This can only be 564 achieved by accomplishing the QoS management on an end-to-end basis 565 (i.e., end user to end user), from application to application, 566 potentially across many domains. 568 However, this does not mean that the resource reservation protocol 569 must be applied end-to-end. The end-to-end QoS management 570 architecture may consist of many interoperable edge-to-edge QoS 571 management architectures where each of them might use a different 572 edge-to-edge resource reservation protocol. In fact, this is far 573 more likely to be the case than that a global signaling structure 574 will be available across all different domains in an end-to-end 575 perspective. This will increase the flexibility and the openness of 576 the transmission network since various access networks that are using 577 the same transmission network and different edge-to-edge QoS 578 management architectures will be able to interoperate. 580 It is critical that the appropriate mechanisms for providing the 581 service guarantees needed in the radio access network be put in place 582 independently of solving the more difficult problem of end-to-end 583 QoS. 585 In our case, the access network is simply an intranet in which we 586 need to solve a local QoS problem. This implies that a general 587 solution which handles the end-to-end QoS problem is unnecessarily 588 complicated for solving the intranet problem in the cellular access 589 network. 591 5.6. Reservation functionality in edge nodes versus interior routers 593 In our network, it is important that the reservation mechanism be as 594 simple as possible to implement in the interior nodes since in most 595 cases there might be more interior routers (<= 10 depending on 596 network structure) in the path than there are edge nodes. As such, 597 the scheme must be optimized for the interior nodes and not for the 598 edge nodes, thus reducing the requirements placed on the 599 functionality of the interior routers. This means that we can have 600 complicated mapping of traffic parameters at the edges and a 601 simplified model in the interior nodes, and that the necessary set of 602 parameters required for setting up reservations shall be based upon 603 their effect on interior nodes and not on edge nodes. 605 The edge routers typically have to perform per-session 606 management/control, and hence complex per flow handling is not a 607 significant burden. 609 However, interior nodes do not have per flow responsibilities. We 610 must therefore optimize for simple QoS mechanisms on these interior 611 devices, and use more complex mechanisms in the edge devices. 613 In our case, edge device functionality is implemented in the first 614 hop router that the base station or BSC/RNC is connected to (see 615 Section 3.1). In this way we optimize for simple QoS mechanisms on 616 the interior devices, while the more complex mechanisms are applied 617 on the edge devices, e.g., base station, BSC/RNC. 619 This emphasis on simplicity is due to performance requirements listed 620 above. We need to make sure that we understand the minimal level of 621 functionality required in the reservation scheme in order to 622 guarantee the performance of real-time traffic. 624 5.7. On-demand and dynamic allocation of resources 626 Real-time services require that a portion of network resources is 627 available to them. These resources can be reserved on a static or 628 dynamic basis, or potentially based on some kind of measurement of 629 network load. 631 In the first situation, this may result in an poorly utilized 632 network. This is mainly due to the fact that the network resources 633 are typically reserved for peak real-time traffic values. Mobility 634 in the network makes static configuration even less desirable as the 635 resources will be used even less effectively. 637 If using dynamic allocation, this problem will be avoided since the 638 resources are reserved on demand. However, the load from resource 639 reservation will be much higher than if static allocation of 640 resources is used. If the dynamic allocation of the resources is 641 done on a micro-flow basis, the resulting network load from resource 642 reservation might be quite high. 644 We might use other methods, such as measurement-based admission 645 control, to simplify the reservation protocol, as long as these 646 methods can fulfill the requirements (now or in the future). 648 What is important is that all of these mechanisms can be used for 649 solving part of the network utilization problem, and, as such, any 650 reservation scheme must have the flexibility to provide both on- 651 demand reservations as well as measurement-based admission control. 653 As high bitrate and variable bitrate applications enter the cellular 654 space, the need for on-demand reservations of resources will become 655 even more acute. 657 5.8. Unicast and not multicast 659 The majority of the traffic in the RAN is point-to-point unicast 660 transport of radio frames between the base station and the BSC/RNC. 661 As such, the resource reservation scheme need not to be optimized for 662 multicast. 664 5.9. A single operator in the RAN 666 It is realistic to assume that end-to-end communication in IP 667 networks as well as the end-to-end QoS management architectures will 668 be managed by more than one operator. 670 Furthermore, it also realistic to assume that an edge-to-edge 671 resource reservation protocol can be managed by one single operator. 672 As such, it is reasonable to limit reservation scheme to a single 673 operator domain. This will ensure that each operator can optimize the 674 edge-to-edge QoS management architecture for their needs. Moreover, 675 this limitation (a single operator domain) means that the reservation 676 scheme does not need to handle the issues inherent in a multi- 677 operator domain, thus simplifying the scheme. 679 5.10. Minimal impact on router performance 681 The performance of each network node that is used in an end-to-end 682 communication path has a significant impact on the end-to-end 683 performance of this communication path. Therefore, the end-to-end 684 performance of the communication path can be optimized by optimizing 685 the router performance. It is absolutely critical that the 686 introduction of QoS mechanisms and signaling does not overly impact 687 the performance of the infrastructure. Obviously, you cannot 688 introduce new things that need to be done by networking 689 infrastructure without impacting its performance, but that impact 690 must be minimized to the greatest extent possible. 692 One of the factors that can contribute to this optimization is the 693 minimization of the resource reservation signaling protocol load on 694 each router. When the dynamic allocation of the resources is on a per 695 micro-flow basis, the resource reservation signaling protocol could 696 easily overload a router located in a core network, causing severe 697 router performance degradation. Furthermore, any mechanisms defined 698 must be such that it is reasonable to implement them in hardware 699 which will increase the scalability of the solution. 701 5.11. Scalably Manageable 703 Any strategy for resource management in a RAN must be done in such a 704 way that it is easily manageable in a very large network. This 705 implies as little "laying on of hands" as possible and as much 706 automation as possible. In networks made up of many thousands of 707 routers, changing of even a single parameter in all routers may be 708 prohibitively difficult. Minimizing the involvement of the operator 709 (or the operator's management tools) is therefore an important 710 requirement. 712 5.12. Bi-directional reservations 714 In current RANs, the BSC/RNC is responsible for initiation of 715 reservation of resources in the transport plane. Therefore, via the 716 resource reservation signaling protocol, the BSC/RNC has to support 717 the initiation and management of the resource reservations for both 718 directions, both to and from the base station, simultaneously. In 719 this way a simpler edge-proxy resource reservation functionality will 720 be implemented in the base station, decreasing its complexity. 722 6. Evaluation of existing strategies 724 In order to understand whether technology exists today which will 725 allow us to manage the resources in cellular networks, we briefly 726 look at the protocols that currently exist which address parts or all 727 of these requirements. 729 6.1. End-to-end per-flow resource reservation protocol 731 An end-to-end per-flow resource reservation signaling protocol is 732 applied in an end-to-end IP communication path, and it can be used by 733 an application to make known and reserve its QoS requirements to all 734 the network nodes included in this IP communication path. This type 735 of protocol is typically initiated by an application at the beginning 736 of a communication session. A communication session is typically 737 identified by the combination of the IP destination address, 738 transport layer protocol type and the destination port number. The 739 resources reserved by such a protocol for a certain communication 740 session will be used for all packets belonging to that particular 741 session. Therefore, all resource reservation signaling packets will 742 include details of the session to which they belong. 744 The end-to-end per-flow resource reservation signaling protocol most 745 widely used today is the Resource Reservation Protocol (RSVP) (see 746 [RFC2210], [RFC2205]). The main RSVP messages are the PATH and RESV 747 messages. The PATH message is sent by a source that initiates the 748 communication session. It installs states on the nodes along a data 749 path. Furthermore, it describes the capabilities of the source. The 750 RESV message is issued by the receiver of the communication session, 751 and it follows exactly the path that the RSVP PATH message traveled 752 back to the communication session source. On its way back to the 753 source, the RESV message may install QoS states at each hop. These 754 states are associated with the specific QoS resource requirements of 755 the destination. The RSVP reservation states are temporary states 756 (soft states) that have to be updated regularly. This means that PATH 757 and RESV messages will have to be retransmitted periodically. If 758 these states are not refreshed then they will be removed. The RSVP 759 protocol uses additional messages either to provide information about 760 the QoS state or explicitly to delete the QoS states along the 761 communication session path. RSVP uses in total seven types of 762 messages: 764 * PATH and RESV messages 766 * RESV Confirm message 768 * PATH Error and RESV Error messages 770 * PATH Tear and RESV Tear messages 772 An overview of the functionality of the RSVP functionality includes: 774 * End-to-end reservation with aggregation of path 775 characteristics such as fixed delay. 777 * The same type of reservation functionality in all 778 routers. Only policy handling separates the edge of the 779 domain from other routers. 781 * Multicast and unicast reservations with receiver initiated 782 reservations. RSVP makes reservations for both unicast and 783 many-to-many multicast applications, adapting dynamically 784 to changing routes as well as to group membership. 786 * Shared reservations for multiple flows. 788 * Support for policy handling to handle multi-operator 789 situations since more than one operator will be 790 responsible for RSVP's operation. 792 * Flexible object definitions. RSVP can transport and maintain 793 traffic and policy control parameters that are opaque to 794 RSVP. Each RSVP message may contain up to fourteen classes of 795 attribute objects. Furthermore, each class of RSVP objects 796 may contain multiple types to specify further the format 797 of the encapsulated data. Moreover, the signaling load 798 generated by RSVP on the routers is directly proportional 799 to the flows processed simultaneously by these routers. 800 Furthermore, processing of the individual flows in the 801 networking infrastructure may impose a significant processing 802 burden on the machines, thus hurting throughput. These 803 issues make it reasonable to question the scalability and 804 performance in a large cellular radio access network. 806 * support for uni-directional reservations, not bi-directional. 808 In the situation where a mobile moves or the connection moves from 809 one base station to another, it could force the communication path to 810 change its (source/dest) IP address. The change of IP address will 811 require that RSVP establish a new RSVP session through the new path 812 that interconnects the two end points involved in the RSVP session 813 and release the RSVP session on the old path. During this time, the 814 end-to-end data path connection is incomplete (i.e., QoS disruption) 815 and it will negatively affect the user performance. 817 This approach includes much more functionality and complexity than is 818 required in the cellular RAN. Our problem is significantly simpler to 819 solve. The trade-off between performance and functionality is one of 820 the key issues in the RAN. In our case, the majority of the 821 functionality in RSVP is not required. This is true for four 822 reasons: 824 * Unicast reservations are much less complex than multicast. 826 * Edge-to-edge with one operator does not require policy 827 handling in the interior routers. 829 * Path characteristics and flexible traffic parameters and 830 QoS definitions could be solved by network dimensioning 831 and edge functionality. 833 * Per microflow states in intermediate routers cause severe 834 scalability problems. Furthermore, receiver-initiated 835 reservations impose high complexity in the states due to 836 reverse-direction routing of the RESV messages. A scheme 837 based on sender oriented reservation (see e.g., [AhBe99]) 838 decreases the complexity of the per microflow states due 839 to the fact that no reverse-direction routing is 840 required. 842 6.2. Integrated Services over Differentiated Services 844 The IntServ over DiffServ framework addresses the problem of 845 providing end-to-end QoS using the IntServ model over heterogeneous 846 networks. In this scenario, DiffServ is one of these networks 847 providing edge-to-edge QoS. This is similar to the underlying 848 architecture for this draft, where the specific network is the 849 cellular RAN, and where the end-to-end model is unspecified. As such, 850 the problem addressed by IntServ over DiffServ is similar in nature 851 to the problem described here, although the specific requirements 852 (such as network utilization and performance) are different. 854 The IntServ over DiffServ framework discusses two different possible 855 deployment strategies. The first is based on statically allocated 856 resources in the DiffServ domain. The advantages and disadvantages of 857 this approach are discussed in Section 6.3. 859 The second possible strategy is based on dynamically allocated 860 resources in the DiffServ domain. According to the draft, this can be 861 done using RSVP-aware DiffServ routers. However, this approach has 862 most of the drawbacks described in Section 6.1, and per-microflow 863 state information is kept in the intermediate routers. 865 Alternatively, resources in the DiffServ domain can be dynamically 866 allocated using Aggregated RSVP. This will be discussed in Section 867 6.4. 869 Other approaches related to the bandwidth broker concept are still 870 very immature and will not be discussed here. 872 6.3. Statically-assigned trunk reservations based on Differentiated 873 Services 875 A significant problem in deploying an end-to-end per-flow resource 876 reservation signaling scheme is its scalability. This can be solved 877 by aggregating (trunking) several individual reservations into a 878 common reservation trunk. The reservation trunks can be either 879 statically or dynamically configured. When the reservation trunks 880 are statically configured, no signaling protocol is required for 881 performing the reservation of network resources but is likely to be a 882 difficult management problem. However, due to the different mobility 883 requirements (such as handover) and QoS requirements (such as 884 bandwidth) that the multi-bitrate applications impose on the RAN, it 885 will be difficult to configure the trunked reservations statically 886 and utilize the RAN efficiently. 888 6.4. Dynamic trunk reservations with Aggregated RSVP 890 The reservation trunks can be dynamically configured by using a 891 signaling protocol that manages various mechanisms for dynamic 892 creation of an aggregate reservation, classification of the traffic 893 to which the aggregate reservation applies, determination of the 894 bandwidth needed to achieve the requirement and recovery of the 895 bandwidth when the sub-reservations are no longer required. 897 The first router that handles the aggregated reservations could be 898 called an Aggregator, while the last router in the transit domain 899 that handles the reservations could be called a Deaggregator. 901 The Aggregator and Deaggregator functionality is located in the edge 902 nodes. In particular, an Aggregator is located in an ingress edge 903 node, while a Deaggregator is located in an egress edge node, 904 relative to the traffic source. 906 The aggregation region consists of a set of aggregation capable 907 network nodes. The Aggregator can use a policy that can be based on 908 local configuration and local QoS management architectures to 909 identify and mark the packets passing into the aggregated region. 910 For example, the Aggregator may be the base station that aggregates a 911 set of incoming calls and creates an aggregate reservation across the 912 edge-to-edge domain up to the Deaggregator. In this situation the 913 call signaling is used to establish the end-to-end resource 914 reservations. Based on policy, the Aggregator and Deaggregator will 915 decide when the Aggregated states will be refreshed or updated. 917 One example of a protocol that can be used to accomplish QoS dynamic 918 provisioning via trunk reservations is the RSVP Aggregation signaling 919 protocol specified in [BaIt00]. 921 With regards to aggregated RSVP, even if the reservation is based on 922 aggregated traffic, the number of re-negotiations of the allocated 923 resources due to mobility (handover) does not decrease and each re- 924 negotiation of resources has the same performance requirements as the 925 per-flow reservation procedure. Furthermore, the aggregated RSVP 926 scheme is receiver initiated and cannot support bi-directional 927 reservations. 929 Due to the fact that the resource reservation states stored in all 930 the RSVP aware Edge and Interior nodes represent aggregated RSVP 931 sessions (i.e., trunks of RSVP sessions), the scalability problems on 932 these routers will be drastically minimized. However, we believe that 933 in a fully meshed Diffserv network such as the one shown in Figure 2 934 below, the number of the RSVP aggregated sessions grows as follows: 936 number_aggregates = n^2 - n 938 where n represents the number of edge nodes that simultaneously send 939 and receive information to/from all the other edge nodes of the 940 Diffserv domain. For example, in Figure 2, where the number of edge 941 nodes is 3 (n = 3), the maximum number of simultaneous RSVP 942 aggregated sessions is 6 (number_aggregates = 6). This means that the 943 number of the aggregated states that each interior node will have to 944 maintain simultaneously increases with the number of the edge nodes 945 (= n) that simultaneously send and receive information to/from all 946 the other edge nodes of the Diffserv domain using the equation: 948 number_aggregates = n^2 - n 949 When the number of the edge nodes is high, e.g., 5000 then 950 number_aggregates = 24995000. This may cause scalability problems on 951 the interior nodes of the Diffserv domain. 953 |------| ----- A ------> |----------| --- A ---------> |------| 954 | | | | | | 955 | | <--------- C -- | | <--------- C --- | | 956 | EDGE | | interior | | EDGE | 957 | | --- B --------> | Router | <------ D ------ | | 958 | | | | | | 959 | | <------- E ---- | | ---- F --------> | | 960 |------| |----------| |------| 962 | /|\/|\ | 963 | | | | Arrows represent RSVP 964 | | | | aggregation messages 965 | 966 D E B 967 F | Letters in arrows 968 | | | are RSVP aggregation 969 | | | | Session IDs 970 \|/ | | \|/ 972 |--------| 973 | | 974 | EDGE | 975 | | 976 |--------| 978 Figure 2: Example of a full meshed Diffserv domain 979 with three Edge nodes and one Interior node 981 7. Conclusion 983 Cellular radio access networks and coming wireless applications 984 impose different requirements on reservation strategies than typical 985 Internet conditions. 987 Firstly, the reservation solution does not need to have the same 988 level of complexity: 990 * Edge-to-edge not end-to-end: The IP traffic is generated 991 in the network and is only transported as far as the 992 cellular-specific nodes (such as the base station and 993 BSC/RNC). 995 * Single operator domain and no inter-domain transport: The 996 transport is owned and managed by a single operator. 998 * Only unicast not multicast: The end-to-end payload is 999 transported between nodes. This transport only requires 1000 a unicast reservation. 1002 Furthermore, a cellular radio access network has much higher 1003 performance requirements on the reservation strategy: 1005 * Efficient usage of the transmission network: The transport 1006 between the BSC/RNC and the base station represents a significant 1007 cost for the cellular operator, and efficient usage of 1008 the transmission network is therefore critical from a cost 1009 point of view. The network should allow dynamic allocation 1010 of resources to allow efficient statistical aggregation 1011 of traffic without causing congestion. 1013 * A wide-area network with significant volume of real-time 1014 traffic: Real-time traffic levels up 100% must be 1015 supported. 1017 * The resource reservation process has to handle a 1018 significantly higher volume of requests, and the process 1019 has to be fast enough to avoid packet losses in the 1020 air-interface during handover. 1022 * The scheme must be optimal for interior nodes and not 1023 for the edge nodes. In this way the necessary set of 1024 parameters required for setting up reservations should be 1025 based upon their effect on interior nodes and not on edge 1026 nodes. This reduces the complexity on the interior routers. 1028 Given these requirements, we believe that appropriate standardization 1029 should take place to create the necessary protocols for edge-to-edge 1030 resource management for a single operator domain. 1032 8. References 1034 [AhBe99] Ahlard, D., Bergkvist, J., Cselenyi, I., "Boomerang 1035 Protocol Specification", Internet draft, Work in progress. 1037 [BaIt00] Baker, F., Iturralde, C. Le Faucher, F., Davie, B., 1038 "Aggregation of RSVP for Ipv4 and Ipv6 Reservations", 1039 Internet draft, Work in progress. 1041 [KeMc00] Kempf, J., McCann, P., Roberts, P., " IP Mobility 1042 and the CDMA Radio Access Network: Applicability 1043 Statement for Soft Handoff", Internet draft, Work 1044 in progress. 1046 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., 1047 "Resource ReSerVation Protocol (RSVP) -- Version 1 1048 Functional Specification", IETF RFC 2205, 1997. 1050 [RFC2210] Wroclawski, J., "The use of RSVP with IETF Integrated 1051 Services", IETF RFC 2210, 1997. 1053 [WeLi99] Westberg, L., Lindqvist, M., "Realtime Traffic over 1054 Cellular Access Networks", Internet draft, Work in 1055 progress (expired). 1057 9. Authors' Addresses 1059 David Partain 1060 Ericsson Radio Systems AB 1061 P.O. Box 1248 1062 SE-581 12 Linkoping 1063 Sweden 1064 EMail: David.Partain@ericsson.com 1066 Georgios Karagiannis 1067 Ericsson EuroLab Netherlands B.V. 1068 Institutenweg 25 1069 P.O.Box 645 1070 7500 AP Enschede 1071 The Netherlands 1072 EMail: Georgios.Karagiannis@eln.ericsson.se 1073 Pontus Wallentin 1074 Ericsson Radio Systems AB 1075 P.O. Box 1248 1076 SE-581 12 Linkoping 1077 Sweden 1078 EMail: Pontus.Wallentin@era.ericsson.se 1080 Lars Westberg 1081 Ericsson Research 1082 Torshamnsgatan 23 1083 SE-164 80 Stockholm 1084 Sweden 1085 EMail: Lars.Westberg@era-t.ericsson.se 1087 Table of Contents 1089 1 Abstract ........................................................ 2 1090 2 Terminology ..................................................... 3 1091 3 Background and motivation ....................................... 3 1092 3.1 IP transport in radio access networks ......................... 3 1093 3.2 Motivation for this memo ...................................... 7 1094 4 Network characteristics of cellular access networks today ....... 8 1095 4.1 General aspects of the network structure ...................... 8 1096 4.2 High cost for transmission .................................... 9 1097 4.3 Transportation of radio frames ................................ 10 1098 4.4 Mobility aspect of radio frame transport ...................... 12 1099 5 Requirements on a Resource Reservation Scheme ................... 12 1100 5.1 Main requirement on resource reservation scheme ............... 12 1101 5.2 IP must provide same service behavior as the transport net� 1102 works used today ............................................. 13 1103 5.3 Efficient network utilization ................................. 13 1104 5.4 Handover performance requirements on resource reservation 1105 scheme 1106 ......................................................... 14 1107 5.5 Edge-to-edge reservations, not end-to-end ..................... 15 1108 5.6 Reservation functionality in edge nodes versus interior 1109 routers ...................................................... 15 1110 5.7 On-demand and dynamic allocation of resources ................. 16 1111 5.8 Unicast and not multicast ..................................... 17 1112 5.9 A single operator in the RAN .................................. 17 1113 5.10 Minimal impact on router performance ......................... 18 1114 5.11 Scalably Manageable .......................................... 18 1115 5.12 Bi-directional reservations .................................. 18 1116 6 Evaluation of existing strategies ............................... 19 1117 6.1 End-to-end per-flow resource reservation protocol ............. 19 1118 6.2 Integrated Services over Differentiated Services .............. 21 1119 6.3 Statically-assigned trunk reservations based on Differenti� 1120 ated Services ................................................ 22 1121 6.4 Dynamic trunk reservations with Aggregated RSVP ............... 23 1122 7 Conclusion ...................................................... 25 1123 8 References ...................................................... 27 1124 9 Authors' Addresses .............................................. 27