H ip qo s for 3g
Download as ppt, pdf0 likes289 views
The document discusses various methods for providing quality of service (QoS) for real-time applications over 3G networks, including admission control, differentiated services (DiffServ), multi-protocol label switching (MPLS), integrated services (IntServ), and resource reservation protocol (RSVP). It proposes a bounded delay differentiated service that uses DiffServ at network edges to provide hard real-time guarantees with scalable and simple scheduling. Signalling is done using RSVP to establish reservations across DiffServ domains. Outstanding issues include interactions between wireless links and network layer QoS mechanisms.
H ip qo s for 3g
- 1. IP QoS for 3G
- 2. A Possible Solution • The main focus of this network QoS mechanism is to provide one, real time, service in addition to the normal best effort service. • This real-time service requires that data be transmitted across the entire network in less than 200 ms, and that no losses due to network congestion should occur.
- 3. Admission Control Descriptions • Call admission may be based on a number of parameters that describe the traffic. • Increasing the number of parameters enables more accurate admission decisions, leading to more efficient network usage. • A user can minimise their bill by doing traffic shaping to keep the required peak bandwidth as low as possible.
- 4. Proposed Internet QoS Mechanisms • Integrated Services (IntServ) • Multi-Protocol Label Switching (MPLS) • Differentiated Services (DiffServ) • Integrated Services over Specific Link Layers (ISSLL) • Resource ReserVation Protocol (RSVP)
- 5. IntServ • The Guaranteed Service gives hard QoS guarantees with quantified delay and jitter bounds for the traffic. It also guarantees that there will be no packet loss from data buffers, thus ensuring near-lossless transmission. This Service is intended to support real-time traffic. • The Controlled Load Service makes the network appear to be a lightly loaded best-effort network. This class is aimed at delay-tolerant applications. • Best Effort (no reservation required).
- 6. MPLS • MPLS was originally presented as a way of improving the forwarding speed of routers. • It appears particularly suited to carrying IP traffic over fast ATM networks. • The basic principle of MPLS is that routers at the edge of the MPLS domain mark all packets with a fixed-length label that acts as shorthand for the information contained in the IP packet header. • It is usually used as a Layer 2 rather than a Layer 3 solution. • It cannot provide end-to-end QoS configurable on a flow- by-flow basis.
- 7. DiffServ • DiffServ provides a simple and coarse method of classifying services of various applications. • Two standard Per Hop Behaviors (PHB) defined that effectively represent two service levels – Expedited Forwarding (EF): Has a single codepoint (DiffServ value).EF minimizes delay and jitter and provides the highest level of aggregate quality of service. – Assured Forwarding (AF): Has four classes and three drop precedences within each class (so a total of twelve codepoints). Each AF class is allocated a certain amount of forwarding resources.
- 8. ISSLL • ISSLL working group was initially formed to consider how to provide IntServ over specific link technologies, such as a shared Ethernet cable. • One of the key ideas to come from this working group is an approach to provide IntServ QoS by using DiffServ network segments. ISSLL architecture
- 9. RSVP • It is a key element of both IntServ and ISSLL approaches described above. • It is important to minimise the amount of signalling to save both wireless network bandwidth and mobile battery power. • RSVP is an out-of-band signalling system that operates in a soft-state mode. • Initially, RSVP was designed to operate on a hop-by-hop basis, but the ISSLL community has now considered the use of RSVP across DiffServ domains, where only the edge nodes interpret the RSVP messages.
- 10. Details of RSVP Signalling Establishing a uni-directional RSVP reservation.
- 11. Use of RSVP in a Mobile Environment Context Transfer Protocol and RSVP
- 12. Overall Architecture • It is based upon the ISSLL architecture. • Core network operators are implementing DiffServ based core networks. In keeping with this, RSVP is used as the signalling protocol for real-time services. Architecture for QoS in mobile network.
- 13. Overall Architecture (cont.) Summary of generic design decisions
- 14. Overall Architecture (cont.) Shows mobility and wireless design choices
- 15. Bounded Delay Differentiated Service • One of the key differences between this solution and standard ISSLL IntServ over DiffServ is that DiffServ routers are used in the domain at the edge. • DiffServ requires simpler scheduling and admission control mechanisms than traditional IntServ. • The BD service has been proposed as a means to provide scalable, guaranteed real-time data transport within the Internet. • It does not require any per-flow state to be held at routers, and admission control is based on a bandwidth sum.
- 16. Basic Operation of Bounded Delay Service • All traffic for this service can be scheduled using simple FIFO queuing algorithms. • This worst-case delay is fixed for that output port. • N is the number of active BD flows destined for the output port. • MTUBD and MTUBE are the Maximum Transmission Units of the bounded delay and best effort flows respectively. • R is the link speed of the output port.
- 17. Building a Network Behaviour from the Bounded Delay DS • This is known as a per-hop behaviour. • To build a real-time service, the end-to- end transmission delay budget is 200 ms. • The use of a wireless network can increase this transmission latency. • Internet packets have a maximum number of routers – usually 30.
- 18. Building a Network Behaviour from the Bounded Delay DS (cont.) Minimum bounded delay of a node is determined by size. Buffer sizes required if jitter is not controlled independently from delay
- 19. Mobility Management • This eliminates scalability concerns and allows this service to be used throughout a core network to provide hard real time QoS. • BD is still considerably less complex than true IntServ routers, where more complex scheduler techniques and more complex admission control decisions would be needed. • BD does not guarantee flow isolation: flows are treated as aggregate flows.
- 20. Signalling • Building a system that is naturally compatible with end-to-end Internet QoS • RSVP is scalable, but its use hop by hop throughout a network with regular refresh messages as described in pure IntServ is not scalable.
- 21. Signalling (cont.) • The D parameter to represent the fixed worst- case delay of the node. • C is the bandwidth dependent delay (in bytes) and D is the bandwidth independent delay (in microseconds).
- 22. Discussions • The QoS solution finally proposed integrates easily with the ISSLL framework. • A fundamental difference between this design and that of current mobile systems is that it assumes that the data receiver is responsible for requesting, and paying for, the QoS provided. • Actual model for RSVP is ‘receiver pays, but sender is ultimately responsible’, in the hope that this would prevent junk traffic.
- 23. Discussions (cont.) • One of the main differences between this discussion and current mobile QoS systems is that the emphasis has been on how end-to-end QoS, including end-to-end reservation-based QoS, may be achieved. • None of the QoS solutions considered have addressed the soft handover problem of CDMA networks. • One way to manage the problem is to devolve this to Layer 2, as in CDMA networks.
- 25. Conclusions • One particular outstanding issue for IP over wireless QoS is the poorly understood problem concerning interactions between the wireless link and the network layer QoS mechanisms. • Critics of IP networks believe that achieving the same level of QoS for voice-over-IP as current telephony will always be more expensive than the telephony networks. • Conversely, critics of the telephony network claim that those networks are over-engineered, and that they would rather have significantly worse QoS, at a significantly cheaper price! • There is clearly some way to go before these issues are resolved.