has been an Associate Professor at the Institute of
Communications Engineering, Nanjing, China since 1995. He currently
teaches courses on computer networks and mobile computer networks.
He area of research is mobile data networks and broadband
This article focuses on the problem of
maintaining real-time traffic continuity and quality during
inter-RNS handover/relocation in packet-domain/all-IP UMTS. We
propose fully seamless SRNS relocation mechanisms for the UMTS
Conversational traffic and Streaming traffic. By adapting and
extending the UMTS data link protocols GTP-U/PDCP/RLC, we
synchronize the traffic streams in the new and old communication
paths. Radio-signal macro-diversity and packets bi-casting can
guarantee the multimedia traffic QoS. For the Streaming class, we
propose a new RLC mode called No-sequencing Acknowledged RLC,
assuring lossless packet delivery and steady throughput during
Europe has developed the UMTS (Universal Mobile Telephone
System), a 3rd-generation mobile communication system. There are
four different QoS (Quality of Service) classes, or traffic
classes, in UMTS:
- Conversational Class
- Streaming Class
- Interactive Class
- Background Class.
Conversational real-time services, like video telephony, are the
most delay-sensitive applications. The real-time streaming class
data flow always aims at a live (human) destination. Web-based
streaming of continuous media, such as video and audio, is becoming
increasingly popular. This data flow is a one-way transport,
characterized such that the time relation (variation) between
information entities, samples and packets, within a flow is
preserved. Traditional Internet applications, such as worldwide
web, Email, Telnet, FTP, and News, are main uses of interactive and
background classes. Due to looser delay requirements, compared to
conversational and streaming classes, interactive and background
classes provide lower error rates through channel coding and
When a UE (User Equipment of a UMTS network) moves from one cell
to another cell, its communication path will change—this is
called handover. Handovers in UMTS networks may be soft handover or
hard handover. Soft handover can maintain the new and old
communication paths concurrently, guaranteeing communication
continuity and quality; while hard handover cannot make these
guarantees. When the new and old cells are within the same RNS
(Radio Network Subsystem), controlled by an RNC (Radio Network
Controller), the handover is called intra-RNS handover. When they
belong to different RNSs, the handover is called inter-RNS.
Inter-RNS handover is more difficult to handle than intra-RNS. Both
intra-RNS and inter-RNS handovers via Iur interface between RNSs
can be handled as soft handovers. Inter-RNS handover without an Iur
and handover between UMTS and GPRS are examples of hard
The all-IP UMTS network will support voice, data, and real-time
multimedia with the IP network elements. Real-time mobile
multimedia services require the QoS of conversational and streaming
classes. In this paper, we mainly studied seamless handovers of
these two classes of services for the case of inter-RNS via Iur
interface. The ETSI 3GPP/UMTS technical specifications give the
basic procedures for handover of inter-RNS via Iur in a
packet-domain/all-IP UMTS network. However, you cannot directly
ascertain how to guarantee different multimedia service
QoS—this requires further study.
There has been some research regarding multimedia handover, but
little about UMTS handover. If not properly handled, the connection
rerouting may lead to some QoS degradation over the connection. The
cause of this possible degradation is twofold. First, data packets
may be delivered to the terminal in a wrong sequence if the
rerouted connection is less congested than the previous connection.
Second, if packets are transmitted over the rerouted connection
while it is not yet fully operational, packets losses may occur
within the network.
A seamless handover protocol performs buffering at some network nodes while
the connection is rerouted, thus guaranteeing the expected packet
loss ratio. But there is still stream-traffic interruption. To be
fully seamless, you need to use macro-diversity. Although soft
handover in CDMA can use macro-diversity to maintain the old and
new radio connections concurrently, how to do relocation between
the old and new base stations in a packet domain is another
problem. The relocation should also be done seamlessly.
In this article, we propose fully seamless handover/relocation
mechanisms for conversational and streaming traffic in UMTS
networks. By adapting and extending the UMTS data link protocols
GTP-U/PDCP/RLC, we could synchronize the new and old traffic
streams. Our mechanisms are based on existing basic UMTS inter-RNS
procedures and could be easily integrated into UMTS inter-RNS.
UMTS Network Architecture
shows the protocol stacks of user planes for
packet-domain services in UMTS. The data-link layer is divided into
- Medium Access Control (MAC)
- Radio Link Control (RLC)
- Packet Data-Convergence Protocol (PDCP)/Gprs Tunnelling
Figure 1: User Plane for Packet Domain services in
The RLC sublayer provides ARQ functionality closely coupled with
the applied radio transmission technique. Services provided to the
upper layer by RLC are transparent data transfer, unacknowledged
data transfer, and acknowledged data transfer. The PDCP Functions
- Mapping of Network PDUs from one network protocol to one RLC
- Compression in the transmitting entity and decompression in the
receiving entity of redundant Network PDU control information
(header compression/ decompression). This may include TCP/IP header
compression and decompression.
Figure 2 shows the format of the PDCP-SeqNum-PDU. PID is
used for packet-header compression. In UMTS, the only use of SeqNum
PDCP is to support lossless handover with the help of
acknowledged in-sequence RLC. However, in the all-IP UMTS the
conversational and streaming traffic handovers also need the
support of SeqNum PDCP, although they do not require lossless
Figure 2: PDCP-SeqNum-PDU format
GTP allows multi-protocol packets to be tunnelled through the
UMTS/GPRS Backbone between GSNs and between SGSN and UTRAN. GTP
includes both the GTP control plane (GTP-C) and user data transfer
(GTP-U) procedures. At handover/relocation, packets stored in the
Source RNS and not yet sent to the UE are tunneled to the Target
RNC, via the pair of SGSNs to which the Source RNS and the Target
RNS are attached.
Seamless UMTS Handover
In this section we consider seamless UMTS handover. We assume
there are Iur interfaces between UMTS RNSs. Macro-diversity and
mirroring guarantee the continuity of multimedia traffic at
handover and relocation. Handover is the transfer between radio
channels, and can be handled as soft handover in UMTS. Relocation
is the transfer between backbone routes. Inter-RNS transfer
includes both the radio-channel and backbone-route changes.
shows the basic intra-3G_MSC SRNS relocation. The
3G_MSC can be SGSNs or GGSNs. Intra-3G_MSC means the RNSs are
within UMTS network.
Figure 3: Basic intra-3G_MSC SRNS Relocation
When RNS-B receives the IU-RELOCATION- REQUEST message, it takes
the necessary action to establish the new Iur transport bearers for
each Radio Access Bearer related to 3G_MSC for the UE in question.
Once RNS-B completes resource allocation, it returns an
IU-RELOCATION-REQUEST-ACKNOWLEDGE to 3G_MSC. RNS-B duplicates the
uplink stream via SGSN-B, as shown in Figure 4.
Figure 4: Synchronous Packet Streams Merging
For the downlink, we suppose GGSN/SGSN can multicast packets to
RNS-A and RNS-B. When the IU-RELOCATION-REQUEST-ACKNOWLEDGE message
is received by 3G-MSC (GGSN/SGSN), 3G_MSC bi-casts packets to RNS-A
and RNS-B. There are two paths between RNC-B and GGSN to
accommodate uplink and downlink. Then GGSN indicates the completion
of the preparation phase on the core network side for the SRNS
Relocation. An IU-RELOCATION-COMMAND message is sent to RNS-A.
Then, RNS-A contexts are sent to RNS-B for each concerned Radio
Access Bearer. These contexts contain the sequence numbers of the
GTP-PDUs next to be transmitted in the uplink and downlink
directions and the next PDCP sequence numbers that would have been
used to send data to and receive data from the UE.
When the new stream is synchronous with the old stream, the
RNS-A sends an IUR-SRNS-RELOCATION-COMMIT message to the RNS-B to
trigger the Relocation execution. For seamless handover, the RNC-B
stream should be adjusted to keep pace with the RNC-A stream. If
the RNC-B stream is later than RNC-A stream, then its transmission
delay should be reduced. If it is earlier, then its transmission
delay should be increased. The RNC-B stream can thus be adjusted to
synchronize with RNC-A stream. The conversational and streaming
traffics have different adjusting methods.
For Conversational service there is no buffered packet to be
transferred from RNS-A to RNS-B. In the future broadband IP
transport network, the packets-delay constraint at every hop can be
guaranteed. In Figure 4
, by specifying exact delay
requirements for connection between GGSN, SGSN, RNS-B and UE, the
RNS-B stream can keep pace with the RNS-A stream. To facilitate
stream-synchronization checking, the GTP/PDCP packets should
contain sequence numbers.
For the uplink, the GGSN performs stream comparison at the GTP-U
layer. The GTP-U packet should be extended to contain bi-casting
information. At RNC, when a PDCP packet arrives, the PDCP-SDU is
recovered and put into GTP-U PDU with the extension of bi-casting
information. Using such information, GGSN GTP-U can perform packet
comparison for the uplink stream. For the downlink, the RNC-B
performs stream comparison at the physical-transport layer.
The unidirectional streaming service is sensitive to delay
variation, but not sensitive to delay. The streaming can be
buffered at intermediate switches, nodes and UEs. The maximum
end-to-end transfer delay in UMTS can be up to 250 ms. The transfer
delay requirements for streaming are typically in a range; in this
range, you may use RLC retransmission. Application-layer buffering at
the receiving end is needed to guarantee media-playing continuity.
RLC retransmission can achieve lossless packet delivery. Because
the application-layer buffer at the receiving end can absorb delay
variation, the delay increase caused by RLC retransmission will
have no impact on the playing quality if there is enough data in
the receiver buffer.
The RLC retransmission delay is about 20 ms. Assuming the
streaming rate is 1.2 Mbps, the data prefetched in the receiver
buffer should be greater than 3000 bytes. If we use acknowledged
in-sequence delivery RLC, the data volume stored in the
receiving-end RLC buffer will be about 3000 bytes when one packet
is lost. Because the typical RLC payload unit size is 126 bytes,
the number of PDUs in the receiving-end RLC buffer is around 24.
Since the RLC receiving window can be up to 211, the
number of RLC PDUs in the receiving buffer would be much larger with a
higher transmission rate. However, the management of the RLC buffer
would be rather difficult. There would be no such problem if
out-of-sequence packet delivery were used in RLC. You should thus
adapt the necessary PDCP/RLC work setting.
PDCP packets should contain SeqNum, RLC packets should be
acknowledged, and both PDCP/RLC are used in out-of-sequence mode.
We call this type of RLC as a No-sequencing Acknowledged RLC. The
PDCP SeqNum is used for the packet-comparison function, not for
retransmission. Allowing out-of-sequence delivery can save memory
in the PDCP/RLC and achieve a stable flow rate. In the receiving
PDCP entities, no buffer is needed to store out-of-sequence
packets. In the receiving RLC entities, little buffer space is
needed to store out-of-sequence SDU segments. These packets can be
acknowledged immediately, reducing the data volume stored in the
RLC sending buffer. However, the sending window doesn't have to be
small. With large sending windows, the stream traffic would not
pause for retransmissions, the stream traffic rate would be steady,
and the radio bandwidth could be easily managed. In fact, some H323
videoconference products such as that manufactured by VCON allow
out-of-sequence packet arrival.
After RNS-A receives the IU-RELOCATION-COMMAND message, SGSN/GGSN
and RNS-A should suspend GTP-U and PDCP sending. The PDCP packets
buffered in RNS-A should be transferred to RNS-B. Because the PDCP
sending buffer is small, the transfer time is small. RNS-B can now
mirror the RNS-A state exactly, necessary for acknowledged RLC.
GGSN should then bi-cast packets to RNS-A and RNS-B, while RNS-A
should send an IUR-SRNS-RELOCATION-COMMIT message to RNS-B.
Because stream traffic pauses during handover, the UE should
store some packets in its application-layer buffer. For a 1.2 Mbps
video stream, supposing the maximum transfer delay is 200 ms, the
UE should use a 30 Kbyte buffer to store packets. In UMTS, the time
for UE access detection and connection establishment is about 10-20
ms. If the traffic pause time is 20 ms, the data size in the UE
buffer should be greater than 3000 bytes. These prefetched data
prevent video-play discontinuity during handover and during bad
wireless link times.
If the streaming traffic is transmitted via uplink, there is no
buffered packet to be transferred from RNS-A to RNS-B, but RNS-A
RLC should transfer its receiving status to RNS-B. The traffic can
be sent to RNS-A and RNS-B directly from the UE during handover, as
shown in Figure 4. RNS-A and RNS-B transfer the GTP-U
packets to GGSN concurrently. GGSN compares these GTP-U packets.
When the RNS-B stream is stable, the RNS-A stream is cleared.
The interactive and background traffic classes in UMTS are not
sensitive to delay. They require correct packet delivery, lossless
and error free. Their handovers and relocations should be lossless
instead of seamless. The Acknowledged sequence RLC and SeqNum PDCP
are used for lossless packet delivering. During their relocations,
multicast is not used, which introduces some delay.
This article described the handover of multimedia services in
packet-domain/all-IP UMTS, focusing on inter-RNS
handover/relocation. We described the problem to maintain realtime
traffic continuity during the inter-RNS handover/relocation. Based
on the existing basic inter-RNS relocation procedure, we presented
relocation mechanisms for conversational and streaming traffic. Our
mechanisms make use of the UMTS data link protocols and
GTP-U/PDCP/RLC flexibility, and extend to synchronize the new and
old traffic. For a streaming class, we propose a new RLC mode
called No-sequencing Acknowledged RLC. This mode is a lightweight
protocol, easily mirrored, and assures lossless packet delivery and
steady throughput during handover. Our mechanisms can be easily
integrated into existing basic UMTS relocation procedures, and are
applicable for inter-MSC handover if there is an Iur interface
between old and new RNSs.
This work was supported by the Visiting Scholar Foundation of Key Lab. In University of China and by the Open Projects of the National Key Mobile Communications Laboratory in Southeast University.