Differentiated Services QoS Issues in Next Generation Radio Access Network: a New Management Policy for Expedited Forwarding Per-Hop Behaviour

Transcription

1 Vehicular Technology Conference, VTC2004-Fall IEEE 60th Differentiated Services QoS Issues in Next Generation Radio Access Network: a New Management Policy for Expedited Forwarding Per-Hop Behaviour G. Araniti, F. Calabrò, A. Iera, A. Molinaro, and S.Pulitano D.I.M.E.T. University Mediterranea, Via Graziella (Loc. Feo di Vito), Reggio Calabria Italy Abstract - In this work, the authors attention is focused on Quality of Services issues in 3G-beyond radio access networks. Using the Differentiated Services (DiffServ) approach considering the characteristics of UMTS traffic, we investigate about alternative management policies for Expedited Forwarding (EF) traffic in an all-ip UMTS Terrestrial Radio Access Network (UTRAN). This research work aims at reducing the EF packets loss, with no decreasing the QoS level of other kinds of traffic belonging to same DiffServ domain. In order to verify the robustness of the proposed policy, an exhaustive simulation campaign has been conducted. As we will show, the obtained results are very encouraging. I. INTRODUCTION Next generation communication systems (3G beyond) will provide users a global access to information by integrating IP wired infrastructures with 3G mobile communication ones such as UMTS (Universal Mobile Telecommunication System) [1] [2] [3] [4]. Third Generation Partnership Project (3GPP) [5] community, currently, is addressing its efforts by developing an all-ip architecture. In such a scenario, the UTRAN will play a fundamental role. In fact, the UTRAN is the interface between the radio domain (i.e. NodeBs, the UMTS radio base stations) and the IP backbone, passing through the Radio Network Controller (RNC). Generally, hundreds of NodeBs will be connected to RNC using an already existing IP network that will convoy UMTS and non-umts traffic. So that, the traffic load will be very heavy. The use of IP protocol jointly with the diffusion of application with stringent constraints, in terms of bandwidth requirements and delivery delay, make the implementation of a valid Quality of Service management mechanism a must. Obviously, UTRAN network entities have to be involved in the provisioning of a differentiated network-level QoS. The QoS concept has been successfully introduced into the Internet world and it is currently widely accepted by the Internet community. This has been performed through the introduction of the Integrated Services (IntServ) with Resource Reservation Protocol (RSVP) [6][7] and Differentiated Services (DiffServ) with RSVPAggregate models [8][9] into the traditional Best Effort IP environment. According to 3GPP suggestions [5], it is important to use already standardized protocol for QoS issues, adapting it to the UMTS traffic peculiarity. In so doing we will have an optimal integration between heterogeneous network domains, increasing the users level of satisfaction. Reaching such objectives will be feasible by the study and development of efficient resources management strategies both in wireless and wired regions of the global information system. In this work, authors propose an alternative policy for high-priority traffic treatment when Differentiated Services approach is used in an all-ip UTRAN environment. The paper is organized as follow: the next section will outline the reference scenario. Section III briefly describes standard DiffServ policy, then the new management strategies will be explained in section IV. Finally, simulation assessments and authors conclusions will be illustrated. II. ALL-IP REFENCE SCENARIO In this section, we describe the models of network used for performance analyses. The reference scenario is represented by a next generation All-IP UTRAN. It is formed by a set of NodeBs, each of one is connected to an IP DiffServ wired domain. UTRAN Edge Routers (hereinafter ) forward the traffic streams from NodeBs toward the DiffServ Core Router. Finally, we have the Radio Network Controller (RNC) that connects the UTRAN system to Core Network. Diff-Serv Region All-IP UTRAN Figure 1: All-IP UTRAN scenario RNC

2 Even if the best approach in terms of QoS guarantees would be the exploitation of IntServ model supported by the RSVP signalling protocol implementation, as clearly emerges to readers attention, this scenario could lead to scalability problems. In fact, as early introduced, it must be taken in account both the largeness of UTRAN network and the traffic amount that will be convoyed by it. In fact, being a preexisting IP network, the UTRAN is not more a UMTSdedicated domain. So that, the traffic produced in wireless environment will pass through the routers that will be shared with non-umts traffic (i.e. wired Internet browsing, VOIP applications and so on). The presence on non-umts traffic will contribute to increase the congestion level of the UTRAN. Differentiated Services model represents an efficient alternative for the QoS management within the UTRAN system. It was designed as a QoS support policy for the Internet. Traffic entering a particular network is classified into different classes (named Per Hop Behaviors - PHB). The PHB to be applied to a packet is indicated by a DiffServ Codepoint (DSCP) in the IP header of the packet. The advantage of such a mechanism is that several different traffic streams can be aggregated to one of a small number of behaviour aggregates (BA), each of which is forwarded using the same PHB. This approach mainly provides three PHB: Expedited Forwarding (EF) [10], Assured Forwarding () [11] and best-effort (BE) service. The last one is the default service deployed by the current Internet. The Assured Forwarding () PHB [11] offers different levels of forwarding treatments for IP packets crossing a DiffServ Domain. For instance, PHB groups can be used to differentiate the level of urgency of behaviour aggregates. The Expedited Forwarding (EF) [10] service provides low loss, low latency and low jitter end-to-end service. 3GPP proposes, among different solutions, the joint implementation of Differentiated Services paradigm with the MPLS protocol (Multi Protocol Label Switching). In fact, the MPLS protocol is well suited to simply differentiate traffic flows with different QoS requirements: we could have a different label (named LPS in MPLS) for each one of traffic classes passing through the same network. Considering different LPS for different PHB we have a perfect integration between DiffServ and MPLS. As presented in a previous research work of the authors [12], the IntServ-over-DiffServ model is also very promising. Anyway, this paper would give a contribution to the studies related to the implementation of the DiffServ model in the next generation mobile communication systems. III. DIFFSV TRFIC TREATMENT ISSUE The Differentiated Services model does not allow a mechanism to explicitly request and reserve resources along the data path from the source to the destination peers. It only gives a qualitative assurance about the QoS level for all the traffic flows belonging to the same PHB. In so doing, the resources of the network are not quantitatively shared among the users, so congestion events could arise. In order to avoid such scenarios, the DiffServ implements a traffic conditioner entity in the Edge Router. This functional block imposes constraints to the sources data rates, depending on the PHB. The traffic conditioner block is composed by different elements: (i) classifier, (ii) meter, (iii) marker, (iv) shaper and (v) dropper. Based on the information present in the IP packet header, the classifier divides the traffic streams in different flows. The meter measures the traffic flows temporal properties, and compares them with a pre-defined profile. In so doing for every PHB we can distinguish two sub-classes: conforming and non-conforming traffic. The first one represents the amount of traffic produced below the imposed threshold, the non-conforming the exceeding amount of traffic that will be dropped at the boundaries of the DiffServ region. Then, the meter passes such kinds of information to other conditioning functions to trigger particular actions for conforming and non-conforming packets. The marker entity sets the DS field in the packets entering the DiffServ region with a particular DSCP, associating them to a PHB. Furthermore it plays the re-marking operation, changing the DSCP of particular packets. Usually the remarking function acts at the edge between two different DiffServ domains in which identical PHB are identified by different DSCP. Anyway, as will clearly emerge, we will use such a functionality in our management strategy, aiming at improving the system performances for the EF traffic class. The Shaper partially or completely delays a traffic flow in order to bring it compliant with a reference traffic profile. Usually, the shaping block uses a finite-size buffer. For this, dropping of packets is possible if there is not sufficient space to hold the delayed packets. The dropper will discard the nonconforming delayed packets. In an all-ip UMTS environment, the shaper has to assume a relevant role. In fact, UMTS traffic is characterized by continuous rate variations due to the resources renegotiation algorithms depending on either radio channel conditions or user mobility. This variability, if not well managed, could influence the QoS level in terms of delivery delay and packet loss in the wired side of UTRAN. In the next section our management policy is explained. IV. A NEW MANAGEMENT STRATEGY In UMTS, four QoS categories have been standardized: Conversational, Streaming, Interactive and Background. Real time conversational class is transferred over dedicated physical channels (DPCH) established between end users. Streaming data is also an example of traffic class requiring dedicated channels for data transfer. The Interactive and Background Classes, which do not have real time delay restrictions utilize Physical Random Access Channel (PRACH) and Physical Downlink Shared Channel (PDSCH) for data transmission.

3 Obviously, choosing the radio channel for a traffic stream is not sufficient. All the network elements (the DiffServ routers too) have to be involved in order to apply a common treatment policy for the communication sessions. A mapping between UMTS service classes and DSCP of DiffServ domain is introduced. This mapping will be managed by the network administrator and it must take into account the users request [13]. Table 1 shows the mapping used by the authors. Traffic classes PHB DSCP Conversational EF 10 Streaming, Interactive 20 Background, Best Effort BE 25 heavy loading conditions. Figure 2 shows an example about possible interconnections among the functional blocks explained in the previous section. The classifier node acts as a demultiplexer, dividing the traffic stream in three logically different traffic flows. The first flow (named flow A) enters into the meter. Here, if there is some out-of-profile packet, the exceeding traffic will be marked, in the marker module, with a DSCP corresponding to the low priority traffic (name B). Otherwise will be treated with the foreseen behaviour. This is the case of EF traffic treatment that we propose. Table 1:Traffic Mapping UMTS-Diffserv It must be noted that the traffic mapped on the EF PHB uses, over the radio interface, the Dedicated Channel. This latter allows users to vary his/her transmission rate during a communication session, using suitable resources renegotiation algorithms [14] in a soft-qos fashion. This could lead, in the standard DiffServ implementation, to a non-conforming packets production with the consequent packets discarding at the dropper entity. It is clear how the implementation of the DiffServ model in the UTRAN with no modifications make the 3G-beyond system not so flexible, reducing the soft-qos efficiency. EF PHB will be used to convoy the high priority UMTS traffic. So, it is clear that the packet dropping of such a class leads to a perceivable QoS degradation. This work is focused on considering an alternative policy for EF traffic management in UTRAN. Our aim is to reduce the non conforming EF packets dropping while guaranteeing the other kinds of traffic belonging to same DiffServ domain and maintaining a high QoS level for every single flow. As we previously stated, being the UTRAN an IP network shared among different kind of system (UMTS, IP wired system) [3], domain administrator must do a trade-off among the requirements of such different types of users. The DiffServ standard for the EF traffic foresees that only the conforming packets flow has to enter the marker block, while the non-conforming must be addressed towards the dropping module. In such a way, all the EF non-conforming packets will be dropped. The architectural modification we propose, is the utilization of two different marker modules at meter output: one for the conforming packets and the other for the non-conforming ones. This latter will mark the incoming packets with the same DSCP used for the Best Effort traffic. In so doing, if a user is exceeding the constraints imposed by the edge routers his/her overall non-conforming traffic will not be discarded. However, it must be noted that the constrains are timevarying, depending on the network condition. For light network load, this constrains will be less stringent than for Figure 2 : An interconnections example We didn t choose the code point to forward this kind of traffic because, as clearly emerged in our simulation campaign, in so doing the QoS index was hardly degraded. Instead, as we tested in our simulation studies, the proposed policy assures that conforming EF and traffic obtain the negotiated resources, presenting acceptable transfer delays. At the same time, we allow forwarding the non conforming EF packets toward the receiver end users. V. SIMULATION ASSESSMENTS In order to verify our proposed policy, we made an exhaustive simulation campaign using the NS-2 simulation tools. Different scenarios have been tested, varying the traffic load (in terms of calls/sec) and considering different classes of traffic. The standard Differentiated Services policy has been tested. Considering the proposed policy, we will demonstrate that remarking procedure introduces some advantages. In fact, a high amount of non conforming packets, forwarded as Best Effort traffic, will reach final destinations respecting the UMTS end to end transfer delay bounds. It will be shown how the deployment of our remarking policy improves the EF traffic performances, without degrading the quality of service level of the other kinds of traffic ( and BE) present in the DiffServ region. The UMTS reference scenario adopted during our simulation campaign consists of 16 circular micro-cells (300m cell radius).

4 A Poisson process is used to generate new users entering the system. Varying the mean value of the process (mean number of calls per second), we vary the network load factor. The sojourn time of a user in a cell is exponentially distributed, its mean value is given by the ratio between the radio coverage diameter of a cell and the user average velocity. Two classes of users are considered: pedestrian and vehicular. The pedestrian users move at 3 Km/h and the vehicular ones move at 60 Km/h nominal speed. Handover events are distributed according to a decreasing exponential function with mean equal to the sojourn time. A perfect power control is assumed. In order to avoid EF PHB executing an unlimited preemption of other traffic a limiter is implemented at the Edge Router. The limiter parameters have been chosen so that the UMTS traffic classes delay constraints [13] are respected, even when the DiffServ domain is heavy loaded. Table 2 shows the maximum delay experienced by the EF conforming traffic and the percentage of conforming EF packets delivered to destinations, for different load factor. Load Factor Conforming EF Packet Ratio (CPR) 0,1 calls/sec 0,91 31 ms 0,2 calls/sec 0,90 34 ms 0,4 calls/sec 0,89 37 ms 1 calls/sec 0,87 45 ms 2 calls/sec 0,80 78 ms Table 2: EF behavior for different load factor It must be noted that the maximum delay for 2 calls/sec is 78 ms. This value is less than the transfer delay constraints for the Conversational UMTS traffic. Referring to the standard DiffServ approach, we have a 2 packet loss ratio included in the range from 9 10 up to 1 2,0 10. Such values can be obtained from table 3 as (1- CPR). But they are too elevated for the UMTS conversational connections. Our proposed policy aims at recovering discarded packets at the edge routers, remarking them as Best Effort packets. As we will show, most of the remarked packets will reach the final destination respecting the UMTS transfer delay. The second column of Table 3 shows the non conforming EF packets ratio. Referring to the fourth column, it must be noted that the Random Early Detection (RED) policy, adopted for buffers management, doesn t permit to forward all the non conforming packets. So, only a certain percentage of the remarked packets are forwarded as Best Effort traffic. The system is loaded by heterogeneous traffic according to the following percentages: 60% EF traffic, 20% traffic, 20% Best Effort (BE) traffic. We have overloaded the system with high priority traffic to consider a scenario with nonconforming EF traffic generation. In the routers, a Weighted Fair Queueing strategy has been adopted. For the sake of simplicity, we suppose that each user changes its transmission bit rate only when executing handoff, implementing a soft-qos paradigm. Due to the length constraints, only the most interesting results are presented here. Load Factor Non Conforming EF Packet Ratio (NCPR) EF-NC Recovered packets with DiffServ standard EF-NC Recovered packets with Remarking policy 0,1 calls/sec 0,09 0% 98,3% 0,2 calls/sec 0,1 0% 92,4% 0,4 calls/sec 0,11 0% 87,5% 1 calls/sec 0,13 0% 66% 2 calls/sec 0,2 0% 55% Table 3: Percentage of forwarded remarked packets Obviously, the non conforming packets being declassified in Best Effort traffic could degrade the overall EF class QoS level. So it must be considered the end-to-end delay transfer that such packets will experience. In order to respect the UMTS specifications [13], and considering the worst case in term of load factor, we chose the 78ms value as maximum acceptable delay. Packet accepted Packet rejected Load Factor < 78ms >78ms 0,1 calls/sec 95% 5% 0,2 calls/sec 90% 10% 0,4 calls/sec 88% 12% 1 calls/sec 68% 32% 2 calls/sec 49% 51% Table 4: Percentage of accepted packets at end receivers Figure 3 shows a comparison between the Packet Loss Ratio experienced with DiffServ standard policy and with the remarking policy for different values of the load factor. The figure puts in evidence that the proposed policy increases the fraction of Expedited Forwarding packets reaching the receiver users even for high load. The tables 5 and 6, show that the remarking policy, proposed by the authors, doesn t degrade the performance of and BE traffic, in terms of end to end transfer delay.

5 3,E-01 2,E-01 2,E-01 1,E-01 5,E-02 0,E ,5 1 1,5 2 Call/sec Figure 3: Packet Loss Ratio, standard policy vs. remarking policy Traffic Class conforming Nonconforming 120 0,004 0,004 0, ,056 BE 450 0, ,081 Table 5: and BE performances for 0,2 calls per second Traffic Class conforming Nonconforming 170 0,08 0,14 0, ,16 VII. REFENCES [1] Y. B. Lin and A. C. Pang, An all-ip Approach for UMTS Third-Generation Mobile Networks, IEEE Network, September/October [2] V.Gazis et al., Evolving Perspective of 4th Generation Mobile Communication Systems, PIMRC [3] Sotiris I. Maniatis, Eugenia G. Nikolouzou, and Iakovos S. Venieris, "QoS Issues in the Converged 3G Wireless and Wired [4] Bongkyo Moon, Hamid Aghvami, "DiffServ Extensions for QoS Provisioning in IP Mobility Environments", IEEE Wireless Communications, no. 5, October 2003 [5] 3GPP, IP Transport in UTRAN Work Task Technical Report, TR [6] IETF RFC 1633, Integrated Services in the Internet Architecture: an Overview, June [7] IETF RFC 2210, The Use of RSVP with IETF Integrated Services, Sep [8] IETF RFC2475, An Architecture for Differentiated Service. S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. December [9] IETF draft-ietf-issll-rsvp-aggr-02.txt, Aggregation of RSVP for IPv4 and IPv6 reservations, Mar [10] IETF RFC 3246, An Expedited Forwarding PHB (Per- Hop Behavior). B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec [11] IETF RFC 2597, Assured Forwarding PHB Group. J. Heinanen, F. Baker, W. Weiss, J. Wroclawski. June [12] G. Araniti, A. Iera, A. Molinaro, S. Pulitanò, Managing IP Traffic in Radio Access Networks of Next Generation Mobile Systems, accepted for publication in Wireless Communication Magazine Aug [13] 3GPP, Quality of Service concept and architecture, Technical Specification [14] 3GPP, RAB Quality of Service Negotiation over Iu, TR BE 650 0, ,22 Table 6: and BE performances for 1 call per second VI. CONCLUSIONS The 3G beyond systems will provide users a global access to information. The way to reach this objective is the integration of wireless and wired system in a global QoSaware infrastructure. In this research work the authors proposed an alternative way for the EF packets treatment in an all-ip UMTS with a QoS-aware UTRAN. The obtained results show the implementation of the remarking policy permits to reduce the high priority packets discarding at edge routers. Furthermore, the stringent end-to-end transfer delay constraints of UMTS are respected.