IP QoS for 3G
A Possible Solution
• The main focus of this network QoS mech
anism is to provide one, real time, service i
n addition to the normal best effort service.
• This real-time service requires that data be
transmitted across the entire network in le
ss than 200 ms, and that no losses due to
network congestion should occur.
Admission Control Descriptions
• Call admission may be based on a number
of parameters that describe the traffic.
• Increasing the number of parameters enab
les more accurate admission decisions, le
ading to more efficient network usage.
• A user can minimise their bill by doing traff
ic shaping to keep the required peak band
width as low as possible.
Proposed Internet QoS Mechanisms
• Integrated Services (IntServ)
• Multi-Protocol Label Switching (MPLS)
• Differentiated Services (DiffServ)
• Integrated Services over Specific Link Lay
ers (ISSLL)
• Resource ReserVation Protocol (RSVP)
IntServ
• The Guaranteed Service gives hard QoS guaran
tees with quantified delay and jitter bounds for th
e traffic. It also guarantees that there will be no p
acket loss from data buffers, thus ensuring near-
lossless transmission. This Service is intended t
o 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).
MPLS
• MPLS was originally presented as a way of improving th
e forwarding speed of routers.
• It appears particularly suited to carrying IP traffic over fas
t ATM networks.
• The basic principle of MPLS is that routers at the edge of
the MPLS domain mark all packets with a fixed-length la
bel that acts as shorthand for the information contained i
n the IP packet header.
• It is usually used as a Layer 2 rather than a Layer 3 solut
ion.
• It cannot provide end-to-end QoS configurable on a flow-
by-flow basis.
DiffServ
• DiffServ provides a simple and coarse method of cl
assifying services of various applications.
• Two standard Per Hop Behaviors (PHB) defined t
hat effectively represent two service levels
– Expedited Forwarding (EF): Has a single codepoint (Diff
Serv value).EF minimizes delay and jitter and provides th
e highest level of aggregate quality of service.
– Assured Forwarding (AF): Has four classes and three dro
p precedences within each class (so a total of twelve code
points).
Each AF class is allocated a certain amount of forwardin
g resources.
ISSLL
• ISSLL working group was initially formed to consider h
ow to provide IntServ over specific link technologies, s
uch as a shared Ethernet cable.
• One of the key ideas to come from this working group i
s an approach to provide IntServ QoS by using DiffSer
v network segments.
ISSLL architecture
RSVP
• It is a key element of both IntServ and ISSLL ap
proaches described above.
• It is important to minimise the amount of signallin
g to save both wireless network bandwidth and
mobile battery power.
• RSVP is an out-of-band signalling system that o
perates in a soft-state mode.
• Initially, RSVP was designed to operate on a ho
p-by-hop basis, but the ISSLL community has no
w considered the use of RSVP across DiffServ d
omains, where only the edge nodes interpret the
RSVP messages.
Details of RSVP Signalling
Establishing a uni-directional RSVP reservation.
Use of RSVP in a Mobile
Environment
Context Transfer Protocol and RSVP
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.
Overall Architecture (cont.)
Summary of generic design decisions
Overall Architecture (cont.)
Shows mobility and wireless design choices
Bounded Delay Differentiated
Service
• One of the key differences between this solution and sta
ndard ISSLL IntServ over DiffServ is that DiffServ routers
are used in the domain at the edge.
• DiffServ requires simpler scheduling and admission contr
ol mechanisms than traditional IntServ.
• The BD service has been proposed as a means to provid
e scalable, guaranteed real-time data transport within the
Internet.
• It does not require any per-flow state to be held at router
s, and admission control is based on a bandwidth sum.
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.
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-en
d transmission delay budget is 200 ms.
• The use of a wireless network can increas
e this transmission latency.
• Internet packets have a maximum number
of routers – usually 30.
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
Mobility Management
• This eliminates scalability concerns and allows t
his service to be used throughout a core network
to provide hard real time QoS.
• BD is still considerably less complex than true In
tServ routers, where more complex scheduler te
chniques and more complex admission control d
ecisions would be needed.
• BD does not guarantee flow isolation: flows are t
reated as aggregate flows.
Signalling
• Building a system that is naturally compati
ble with end-to-end Internet QoS
• RSVP is scalable, but its use hop by hop t
hroughout a network with regular refresh
messages as described in pure IntServ is
not scalable.
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).
Discussions
• The QoS solution finally proposed integrates easi
ly with the ISSLL framework.
• A fundamental difference between this design an
d that of current mobile systems is that it assume
s that the data receiver is responsible for request
ing, and paying for, the QoS provided.
• Actual model for RSVP is ‘receiver pays, but sen
der is ultimately responsible’, in the hope that thi
s would prevent junk traffic.
Discussions (cont.)
• One of the main differences between this discus
sion and current mobile QoS systems is that the
emphasis has been on how end-to-end QoS, incl
uding end-to-end reservation-based QoS, may b
e achieved.
• None of the QoS solutions considered have addr
essed the soft handover problem of CDMA netw
orks.
• One way to manage the problem is to devolve th
is to Layer 2, as in CDMA networks.
‘‘Extended link layer’’
Conclusions
• One particular outstanding issue for IP over wireless Qo
S is the poorly understood problem concerning interactio
ns between the wireless link and the network layer QoS
mechanisms.
• Critics of IP networks believe that achieving the same lev
el of QoS for voice-over-IP as current telephony will alwa
ys be more expensive than the telephony networks.
• Conversely, critics of the telephony network claim that th
ose networks are over-engineered, and that they would r
ather have significantly worse QoS, at a significantly che
aper price!
• There is clearly some way to go before these issues are
resolved.
