[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Context transfer
Hi,
Here is some proposed text on context transfer. It is an updated version of
a previous contribution in June(http://www.cdt.luth.se/rohc/msg00508.html).
I propose it to be inserted after Haihong's material on the context in
section 6.
Khiem
Add to Terminology section:
- Downlink: link that carries traffic going from network to mobile
terminal
- Uplink: link that carries traffic going from mobile terminal to
network
- N-HD: Entity located in the network that performs header
decompression for uplink traffic.
- N-HC: Entity located in the network that performs header compression
for downlink traffic.
- N-HD and N-HC are collectively referred to as N-HCD
- M-HC: Entity located in the mobile terminal that performs header
compression for uplink traffic.
- M-HD: Entity located in the mobile terminal that performs header
decompression for downlink traffic.
- M-HD and M-HC are collectively referred to as M-HCD
- N-context-C: compression context used by the N-HCD
- N-context-D: decompression context used by the N-HCD
- N-context-C and N-context-D are collectively referred to as N-context
- M-context-C: compression context used by the M-HCD
- M-context-D: decompression context used by the M-HCD
- M-context-C and M-context-D are collectively referred to as M-context
- Context synchronization: a compression context is synchronized with a
decompression context when a header compressed according to the
compression context is correctly decompressed with the decompression
context
- Link switching: process by which the mobile terminal releases a
physical link and reestablishes a new one. In the case of cellular,
link switching corresponds to radio handover, where the mobile
terminal tunes out of a radio cell and tunes into another radio cell;
link switching may be preceded by a preparation phase, during which
information necessary to carry out the switching is exchanged between
the controlling entities.
Add to "Context section"
When the Timer-based and scaled TS encoding is used, the part of compression context
corresponding to that encoding is:
· TS_offset, TS_stride
· a_ref = Arrival time of packet used as reference
· T_ref: Scaled RTP TS of reference header
· a_j: Arrival time of packet j, for all packet j in sliding window
· T_j: Scaled RTP TS of packet j, for all packet j in sliding window
· CURR_TIME: current value of S_timer; S_timer is used to measure the arrival times
The corresponding decompression context element is:
· TS_offset, TS_stride
· a_ref = Arrival time of reference header (value of R_timer when the reference header was received)
· T_ref = Scaled RTP TS of reference header
· a_i: Arrival time of packet i
· T_i: Scaled RTP TS of packet i
· CURR_TIME: Current value of R_timer; R_timer is used to measure the arrival times
X. Handover Operation
There are two types of handovers: soft and hard. Soft handover takes
place when identical copies of the same user data are transmitted on
separate radio paths, and a selector/combiner entity at the radio
receiving end eliminates the duplication by combining data coming from
multiple paths or selecting the best copy, before relaying further to
the ultimate destination. Hard handover takes place when the mobile
terminal has to switch from one radio path to another, and at any given
time during the process, a single copy of the user data is sent on
only one radio path. Some radio technologies may not have soft
handover, but all technologies have hard handover. When soft handover
is present, for technological reasons, it is reasonable to assume that
header decompression is done after the data has gone through the
selector/combiner entity, and therefore soft handover is a mechanism
not visible to the compressor/decompressor. For the purpose of header
compression, we only need to consider hard handover.
Hard handover presents a problem for the header compression process
because it normally results in the loss of multiple packets between
compressor and decompressor. Most of the loss is the result of
sending/receiving necessary signalling and synchronization information,
when the mobile station would otherwise be sending/receiving user
traffic.
Another issue with handover is the N-HCD relocation. When header
compression is applied to a cellular environment, there is a
network-based header compressor/decompressor (N-HCD), which acts as
decompressor for the uplink and a compressor for the downlink. As the
mobile terminal moves farther and farther away from the location where
the call initially started, routing efficiency considerations may
require that the header compression/decompression function be relocated
from the initial N-HCD to another N-HCD. Such relocation of functions
already exists in third generation UMTS systems, for the purpose of
routing optimization when soft handover is done. Without appropriate
mechanisms, the new N-HCD would have to restart the whole process by
sending and receiving full headers. The full header restart is clearly
undesirable. It creates a surge in bandwidth demand, which is dealt
with by different radio technologies with varying degrees of
efficiency. Some technologies may need to totally blank out the user
data to make room for the full header, thus impacting the media quality
and extending the data loss duration. In addition, because a full
header carries more bits, it has more chance to be corrupted by
transmission errors. Hence it requires stronger error protection
and/or multiple repetitions, which makes the blanking problem worse.
Full header restart also has a negative effect on overall compression
efficiency. Note that some, not all hard handovers involve N-HCD
relocation.
To meet the ROHC handover requirement, ROHC must be designed so that it
can cope efficiently with multiple packet loss and N-HCD relocation.
Efficiency is important, since in some types of wireless systems
(e.g. PCS), cells can be so small (several hundred to a few thousand
feet), that handovers can occur quite frequently at mobile speeds.
In the remainder of this section, we focus on N-HCD relocation, since
the packet loss issue is well known. To maximize the generality, the
problem is modeled as link switching which entails change of N-HCD.
Cellular radio handover is a particular case of link switching. To
avoid full header restart, N-context information must be transferred
from the original N-HCD to the new N-HCD, to jumpstart the process at
the new N-HCD. The header compression scheme must be such that it can
handle that context information transfer without being disrupted. The
basic idea is that the old N-HCD takes a snapshot of its N-context
information and transfers it to the new N-HCD. When the mobile terminal
resumes communication after link switching, the new N-HCD will use the
transferred N-contexts to resume the compression/decompression. The
next section outlines the main challenges or pitfalls to overcome when
the contexts are transferred from the old N-HCD to the new N-HCD.
X.1. Challenges of context transfer
X.1.1. Stale context
There is some elapsed time between T1, the time when the old N-HCD
takes a snapshot of its context for transfer to the new N-HCD, and T2,
the time when the new N-HCD starts to use the contexts. Between T1 and
T2, the old N-HCD and M-HCD may have continued to exchange traffic on
the old link. The old N-HCD may have updated its compression context,
and the M-HCD updated its decompression context accordingly to stay in
synchronization. In the same fashion, the M-HCD may have updated its
compression context, and the N-HCD updated its decompression context
accordingly. When that happens, the N-contexts used by the new N-HCD
may be out of sync with the M-contexts, and consequently, decompression
is incorrect. In particular, the modes have to be in sync after handover.
The stale context problem may or may not exist, depending
on the radio link technology.
X.1.2. Skew of timer
The current value of S_timer and R_timer (CURR_TIME) are part of
the context transferred from the old N-HCD to the new N-HCD, so the new N-HCD can
initialize its timer with the transferred values. The
transfer latency time may create a skew in the calculation of the
elapsed time for the first few headers compressed or decompressed by
the new N-HCD, since that elapsed time is the difference between two
arrival times measured by two different timers (one, a_i at the new N-HCD,
and the other, a_ref at the old N-HCD).
The skew may or may not be a problem, depending on the magnitude of T_transfer.
X.2. Assumptions
The following assumptions are made
- Network-based Link Switching Controller (N-LSC) is a network
entity that decides whether a link switching has to be performed;
N-LSC interacts with the Mobile-based Link Switching Controller
(M-LSC), located in the mobile terminal, to carry out the link
switching.
- N-LSC is functionally separate from N-HCD, but there is a means
for the N-LSC to exchange information with the N-HCD
- There is a means to transport information between the old N-HCD
and new N-HCD
Two schemes are described next:
1) Relocation-concurrent-with-Link-Switching and
2) Relocation-deferred-after-Link-Switching
X.3. Relocation-concurrent-with-Link-Switching (RCLS)
In this scheme, the compression/decompression is relocated from the old
N-HCD to the new N-HCD, concurrently with link switching. This scheme
has the advantage of simplicity. The only requiremant is that the
context transfer be at least as fast as link switching (Otherwise, the
system backs down to full header restart). In cellular systems, it is
likely that the context transfer can be executed fast enough, so the
RCLS is the preferred approach for its simplicity.
X.3.1. R mode
Notes:
- For clarity, the uplink and downlink traffic cases are described
as separate procedures; in practice, when both uplink and downlink
traffic are present, the two procedures can be combined
- Messaging exchanged between the different entities in the above
steps use some protocol and transport that is sytem dependent and
not specified here
- The syntax and format of the messages are also not specified here
- Since the context updates are temporarily inhibited, some
compression efficiency may be lost
For uplink traffic, relocation proceeds through the following steps:
1 - N-LSC determines that relocation has to be performed and sends an
Initiate_relocation_request to the old N-HD
2 - The old N-HD does the following in an atomic fashion:
- takes a snapshot of its N-context-D (denoted N-context-D*) and
transfers it to the new N-HD; (if the transfer cannot be done
successfully or in a timely manner, the new N-HD will have to
send a request for IR or IR-DYN to the M-HC right after link switching)
- stops generating ack (so the M-HC no longer updates its
M-context-C)
3 - Link switching takes place some time between steps 2 and 4
4 - Right after link switching, the new N-HD will decompress using
N-context-D*, and sends acks at appropriate times; the M-HC will
continue to compress normally.
Note for uplink:
- In phase 2, if the old N-HD determines that it needs a context
refresh (e.g. due to excessive detected residual error), N-context-D* will just
contain the static fields. As a result, the new N-HD will
automatically send a request for IR-DYN in phase 4.
For downlink traffic, relocation proceeds through the following steps:
1 - N-LSC determines that relocation has to be performed and sends an
Initiate_relocation_request to the old N-HC
2 - The old N-HC does the following in an atomic fashion:
- takes a snapshot of its N-context-C (denoted N-context-C*) and
transfers it to the new N-HC; (if the transfer cannot be done
successfully or in a timely manner, the new N-HC will have to do
a full header restart right after link switching)
- inhibits its N-context-C update (i.e. will not update the
context as a result of receiving acks)
3 - Link switching takes place some time between steps 2 and 4
4 - Right after link switching, the new N-HC will compress using
N-context-C*; the M-HD will continue to decompress normally, and
send acks at appropriate events, as in the normal case.
Note for downlink:
- If there is a Link Switching Command sent from the N-LSC to instruct
the M-LSC to carry out link switching, as an optional optimization,
upon receiving that command, the M-LSC can notify the M-HD to inhibit
its ack generation and transmission.
X.3.2. UO modes
Uplink: Same as R mode, except that the M-HC has to be aware of the
duration of the radio handover and repeat the Update headers the
necessary number of times, to have good confidence they are received
across the radio handover. All actions related to ack are omitted.
Downlink: Same as R mode, except all actions related to ack are omitted.
X.4. Relocation-deferred-after-Link-Switching (RDLS)
This scheme has looser requirements on speed of context transfer, but
is more complex. It should be used only if the context transfer is not
fast enough for RCLS.
In this scheme, the relocation takes place some time after the link
switching. Right after link switching has taken place, the old N-HCD
still does compression and decompression, and the user data
(compressed header and payload) is physically transiting through the
new N-HCD, which just acts as a relay between the old N-HCD and the
M-HCD, until the context is built up at the new N-HCD and N-HCD
relocation can be completed. After relocation is done, a network path
optimization may be carried out, after which the flow of packets no
longer transits through the old N-HCD.
X.4.1. R mode
Notes:
- For clarity, the uplink and downlink traffic cases are described
as separate procedures; in practice, when both uplink and downlink
traffic are present, the two procedures can be combined
- Messaging exchanged between the different entities in the above
steps use some protocol and transport that is sytem dependent and
not specified here
- The syntax and format of the messages are also not specified here
For uplink traffic, relocation proceeds through the following phases:
1 - The old N-HD takes a snapshot of its N-context-D (denoted
N-context-D*) and sends it to the new N-HD
2 - When the new N-HD receives a N-context-D* for the first time, it
will initialize its N-context-D using the received information
3 - Once the new N-HD has initialized its N-context-D, it monitors
the flow of compressed headers coming from the M-HC; when it
sees an update header, it will use its N-context-D to decompress
and update its N-context-D
4 - The new N-HD decompresses subsequent headers and sends the
decompressed headers to the old N-HD, instead of the compressed
headers
5 - When the old N-HD sees decompressed headers coming from the new
N-HD (instead of compressed headers), it knows that the new N-HD
has taken over header decompression
6 - Network path optimization may take place
7 - From phase 1 until phase 5, when the old N-HD sees an update
header, it will do the following in an atomic fashion:
- update its N-context-D
- take a snapshot of it, denoted N-context-D*
- attach N-context-D* to an ack and send in an atomic entity
to the new N-HD
8 - When the new N-HD receives the ack and N-context-D*, it will
relay the ack to the M-HC, and update its N-context-D with the
received N-context-D*
Notes:
- In phases 1, 2, 3 and 8, the new N-HD continues to relay the
compressed headers (update and non-update) from the M-HC to the
old N-HD and to relay feedback (e.g. ack) from the old N-HD to the
M-HC;
- The initial N-context-D* and subsequent N-context-D* attached to
acks are assumed to be delivered in order. If in-order delivery
cannot be guaranteed, the old N-HD can attach a context generation
number to each N-context-D*. The context generation number is
incremented whenever the N-context-D is updated by the old N-HD.
The new H-HD uses the generation number to detect and discard
contexts older than the one it has already received; attached acks
are also discarded by the new N-HD, i.e. not relayed to the M-HC
- A reliable mechanism can be added if needed in phase 1, e.g. ack
between old and new N-HD, to help the old N-HD detect loss of
N-context-D* and reinitiate the process.
For downlink traffic, relocation proceeds through the following phases:
1 - When the old N-HC sends an update header to the M-HD via the new
N-HC, it attaches the corresponding uncompressed header and
sends the result in an atomic entity
2 - When the new N-HC receives an uncompressed header attached to an
update header for the first time, it will initialize its
N-context-C using the uncompressed header information;
3 - The new N-HC will update the N-context-C when it receives
subsequent uncompressed headers attached to update headers
4 - Once the new N-HC has initialized its N-context-C, it monitors
the flow coming from the M-HD; when it sees an ack corresponding
to an update header relayed after its N-context-C has been
initialized, it updates its N-context-C and moves to phase 5
5 - The new N-HC compresses subsequent headers and sends the
compressed headers to the M-HD; it sends a
Compression_started_notification to the old N-HC
6 - When the old N-HC receives the Compression_started_notification,
it knows that the new N-HC has started compression and stops
compression; it then relays only the uncompressed headers to the
new N-HC
7 - Network path optimization may take place
8 - From phase 1 until phase 6, the old N-HC attaches to each
compressed header (update or non-update) the corresponding
uncompressed header and sends the result in an atomic entity
Notes:
- In phases 1, 2, 3 and 4, the new N-HC continues to relay the
compressed headers (update and non-update) from the old N-HC to the
M-HD and to relay feedback (e.g. ack) from the M-HD to the old N-HC
- The transmission between the old N-HC and new N-HC is assumed to
preserve the order, as it is part of the path between the compressor
and decompressor
- If needed, the old N-HC can optimize the bandwidth usage by
including only the non-static fields in the uncompressed headers
sent between phase 1 and 5; static fields can be sent only once at
the beginning, using some reliable mechanism.
X.4.2. O mode
Uplink: Same as R mode. The M-HC will generate an update header
once aware of the handover, and the old N-HD is expected to ack.
Downlink: Same as R mode. The old N-HCD generates an update header, and the
M-HD is expected to ack.
X.4.3. U mode
Uplink: Same as R mode, except the ack from the old N-HD is not relayed to the
M-HC.
Downlink: Same as R mode, except the old N-HC has to repeat the update headers
the necessary number of times, to have good confidence they are received
by the M-HD. The new N-HC starts to compress once it has seen the
necessary number of update headers, rather than waiting for an ack from the M-HD.
X.5. How the challenges are addressed
X.5.1. Stale context
RCLS procedure: The stale context problem is avoided by inhibiting
any context update once the transfer has started.
RDLS procedures: The stale context problem does not exist because the
new N-HCD monitors the exchange between the old N-HCD and M-HCD and
updates its context to stay synchronized with the one at the old N-HCD.
X.5.2. Skew of timer
RCLS procedures: The issue does not exist if the
transfer latency is small, or if it is bounded. If the latency is
bounded, it can be compensated in the elapsed time calculation.
RDLS procedures: They are not subject to the skew problem, because the arrival
times used in the differences a_i - a_ref or a_i - a_j are all measured by the timer at the
new N-HCD. Before the new N-HCD starts to compress or decompress, it records the
arrival times of the reference header using its own timer.
For example, Downlink, R mode: As part of the N-context-C initialization in phase 2,
the new N-HC starts its S_timer (can be initialized to any value), and
the timer value is recorded as a_ref. The new N-HCD will wait for an ack to confirm
that the update header can be used as the reference (phase 4). To compress subsequent
headers, the elapsed time is calculated as the difference between
arrival times measured by the same timer. Uplink, R mode: As part of the
N-context-D initialization in phase 2,
the new N-HD starts its R_timer (can be initialized to any value). When
the new N-HD sees the first update header after it has initialized its
context, it will record its arrival time as a_ref. Subsequent headers are
decompressed using a_ref.