. 125
( 132 .)





IPv6 IPv6

Datalink Datalink

Physical Physical

Figure 9.36 Iub IP protocol stack

protocols such as PPPMux, LIPE or CIP. These can be used to provide fragmentation and
aggregation functions, which are important when providing ef¬cient transport and QoS.
These options are discussed in more detail in the following section.

9.8.7 IP QoS in RAN
Traf¬c moving within the RAN has certain QoS requirements. With the Release 99 version
of UMTS these requirements are met by the use of ATM, in particular AAL2, to carry
delay-sensitive traf¬c and AAL5 for signalling. With the use of IP within the RAN, 3GPP
R5 speci¬es support for DiffServ marking for all RAN interfaces (Iu, Iur and Iub). For
networks running IP over ATM, there are a number of approaches to QoS provision,
including the mapping of codepoints to ATM SVC or PVC and the use of MPLS.
Another issue that needs to be addressed with regard to QoS for IP in the RAN is
head of line blocking. This can happen when a high-priority frame is held up by the
transmission of a long, lower priority frame. An example illustrates the point. What will
be the delay that a high-priority frame will have to suffer given that it is at the head of
its queue, assuming the link has already started to transmit a frame 1280 bytes in length?
The number of bits to transmit will be 1280 — 8 = 10 240.

Delay for 128 kbps link: 10 240/128 000 = 0.08 s = 80 ms
Delay for 256 kbps link: 10 240/256 000 = 0.04 s = 40 ms
Delay for 1 mbps link: 10 240/1 000 000 = 0.001024 s = 10.24 ms

For ATM this problem is addressed with the use of AAL2 packet segmentation and
reassembly (SSSAR; see Chapter 7). Each long packet is broken up into many small
fragments before being transmitted in an ATM cell.
Different schemes have been proposed to allow for the fragmentation and aggregation
of payloads within IP, including composite IP (CIP), lightweight IP encapsulation (LIPE)
and multiplexed PPP. These protocols are currently classi¬ed as study areas for 3GPP (TS
25.933), meaning that more work is required before an actual standard can be produced.
The operation of each proposed scheme is now explained.

9.8.8 Composite IP (CIP)
CIP provides both aggregation and fragmentation. Figure 9.37 shows the contents of how
FP PDUs are packed into CIP containers. Each FP PDU (or fragment of FP PDU) is
contained within a separate CIP payload. A long FP PDU will require multiple CIP
payloads, each containing a fragment of the original. A header is then added to each CIP
payload that allows for demultiplexing and reassembly at the far end.
A number of CIP packets are then assembled into a CIP container payload, a CIP con-
tainer header is added and the whole container is then transmitted using UDP. Currently
the speci¬cation de¬nes a CIP container header of null.


segment segment segment

header payload header payload header payload header payload

header header header payload header payload header payload header payload

CIP container

Figure 9.37 Transport using CIP packet format

Res Seg Payload End Sequence
CRC CIP packet payload
CID flag number
flag flag length

3 bits 1 bit 1 bit 11 bits 8 bits 1 bit 7 bits 1-255 bits
CID section length sequence no.
section section

Figure 9.38 CIP packet header

The CIP packet header is shown in Figure 9.38. It is split into three sections. The ¬rst
is the CID section, which identi¬es the stream to which the packet belongs, which is used
for multiplexing. Each CIP packet belonging to a different FP PDU stream is assigned a
different CID ¬eld value. It is equivalent to the AAL2 CID ¬eld. The segmentation ¬‚ag
is set to 1 if the payload following is a PDU segment and 0 if it contains a whole PDU.
The 3-bit CRC protects the whole contents of the CID section, including the reserved
¬‚ag (Res), which is available for further extensions to the protocol. The second section
indicates the length of the payload, which is 8 bits and can thus indicate a payload length
between 1 and 255 bytes. Finally, the optional sequence number section is used to aid
segmentation and reassembly. This section is only present if the segmentation ¬‚ag (Seg)
is set to 1 in the CID section. The end ¬‚ag is set to 1 for the last segment in a sequence,
and the sequence number is used to order the fragments on reassembly. It is set to 0 at
the start of each FP PDU and incremented by 1 for each subsequent segment.

9.8.9 Lightweight IP encapsulation protocol (LIPE)
Originally proposed in an Internet draft as a replacement for RTP, LIPE provides both
fragmentation and aggregation. It also allows for extensions to packet headers so that



Figure 9.39 LIPE encapsulation format

media dependent information can be sent to help decode the data stream. Figure 9.39
shows the format of a LIPE packet carried over UDP and also a format de¬ned for IP
(this has been dropped in the latest LIPE draft). The description given here relates to the
LIPE draft titled draft-chuah-avt-lipe-02.txt. The LIPE PDU is comprised of multiplexed
data (MD) payloads, each pre¬xed with a multiplexed header (MH) Each MD can contain
whole parts or fragments of individual data streams.
The MH provides information on the channel ID for each of the MD packets plus
fragmentation information. It is shown in Figure 9.40. The basic MH format is shown in
Figure 9.40(a). The standard header length is 3 bytes if the E bit is set to 0. If E is 1 then
an extended form of header of variable length up to a maximum of 19 bytes is de¬ned.
Figure 9.40(b) shows the basic header format without fragmentation, which is suitable
for smaller packets. Only a sequence number and FlowID are provided. The sequence
number allows out of order packets to be reordered (as in RTP). The FlowID allows
different ¬‚ows across the link to be demultiplexed. In Figure 9.40(c) the packet format
which supports fragmentation is shown. In this case the EOF bit is used to indicate if this
is the last frame in the fragment list. Also note that the FlowID for fragmented packets is

Optional extended
Standard Extended
Length header (if E bit = 1)
E Header
7 bits 16 bits
16 bits

(a) Basic format

Length FlowID
0 X=0
7 bits 12 bits
3 bits

(b) Without fragmentation

Length EOF FlowID
0 X=1
7 bits 1 bit 11 bits
3 bits

(c) With fragmentation

PTI PID length PID payload
4 bits 4 bits maximum 15 bytes

(d) Optional payload ID field

Figure 9.40 LIPE multiplexed header

reduced to 11 bits. If the E bit is set to 1 extra information is provided, called the payload
ID ¬eld. This is shown in Figure 9.40(d). The payload type identi¬er (PTI) is used to
indicate different types of wireless network (e.g. type 1 = IS95 network, type 2 = UMTS
network). The PTI is followed by a length ¬eld and then some application-speci¬c data
called the PID payload. This could be timing information for the CODEC, long sequence
numbers or voice quality indicators.
Since the FlowID must be interpreted at both ends of the link, LIPE also de¬nes
mechanisms to set up FlowIDs from one side to the other. Mechanisms are also provided
to set up the UDP port number, which will be used to tunnel the LIPE packets. To enable
this function LIPE provides a number of signalling messages, listed in Table 9.8.
Each end needs ¬rst to agree on a UDP port number to forward packets through. This
process is carried out using the tunnel setup messages (request and response). Once a
tunnel has been set up, the ¬‚ow setup messages are used to set up LIP ¬‚ows for the
RABs. Each bearer is identi¬ed via the use of a 16 bit RAB ID. Finally, there is support
for soft handover. This is carried out as follows. An RNC can send a software handoff
request to another RNC (or Node B) asking for a LIPE ¬‚ow to be set up for a given RAB
ID. Given that the other UTRAN node can locate the appropriate radio bearer, the new
¬‚ow will be allocated between the originator and the new node for the given RAB ID.

9.8.10 Multiplexed PPP
Multiplexed PPP allows multiple ¬‚ows of data to be carried within one PPP frame.
This reduces the amount of PPP overhead suffered when sending many small packets, a
common problem with VoIP. Multiplexing is actually an option that can be established
during the LCP negotiation phase of PPP. If the receiver offers to accept multiplexed
frames the transmitter for each frame can choose to multiplex or not. Figure 9.41 shows
the format of a PPP multiplexed frame using HDLC.
In this case each UDP payload is preceded by three ¬elds. There is a protocol ¬eld ¬‚ag,
which is set to 1 if the protocol ¬eld is present. For subframes with the same protocol

Table 9.8 LIPE signalling message types
Message Description
Tunnel setup Sets up UDP tunnel for LIPE on a given UDP port
Tunnel tear down Releases tunnel
Flow setup Sets up ¬‚ow for a given FlowId and RABID
Flow tear down Release ¬‚ow
Soft handover request Sets up alternative ¬‚ow for the same RABID

HDLC PPPmux Protocol PPP Payload Protocol PPP Payload
Length Length
header ID protocol cUDP/IP Field protocol cUDP/IP
(7 bits) (7 bits)
1 byte (0x59) Flag 1 bit field + data Flag 1 bit field + data

Figure 9.41 PPP multiplexed frame option

¬eld as their predecessor this ¬‚ag can be set to 0 and the protocol ¬eld omitted The length
bits de¬ne the data length from 1“127 bytes. This is then followed by the protocol ¬eld,
which is compressed using protocol ¬eld compression (PFC) for PPP. The payload for
PPP multiplexed is carried within UDP/IP with the headers being compressed using the
scheme de¬ned in RFC 2508.

9.8.11 AAL2 over UDP
Another potential solution is to use AAL2 over UDP/IP. In this technique, only the
SSSAR and CPS layers of AAL2 are needed. The packet format for this scheme is shown
in Figure 9.42.
Note that with this scheme no start ¬eld is included. This is because the size of a UDP
frame is variable in length, and therefore a CPS packet does not need to align to 48-byte
ATM cell payloads, thus fragmentation of a CPS packet over two UDP packets is not
required. For the very same reason padding is also omitted. AAL2 over UDP allows the
delivery of AAL2 packets over an IP infrastructure. This is useful when internetworking
between IP and ATM networks since it allows the AAL2 to be delivered transparently
over both the ATM and IP infrastructure.

9.8.12 IP ATM interoperating
When migrating a network from R99 to an all-IP platform, a number of interoperability


. 125
( 132 .)