Moby Dick Consolidated System Integration Plan

D0103v1.doc Version 1 6.7.2003
In case of Fast Handover, it might be necessary to buffer IP packets from the new Access Router, during
the bi-casting phase, before the new connection between the Mobile Terminal and the Radio Gateway is
established. In fact, the problem happens only for a Fast Handover between two Radio Gateways, where
there is a time interval during which the MT has closed its connection to the old RG and not opened yet
the connection to the new RG (the MT can handle a connection to only one RG at the same time). From
an implementation point of view, there is nothing simple we can do, as the RGs are not aware of a Fast
Handover taking place. Therefore, we accept to loose a “certain” number of packets in this specific case.
The Packet Transmission block receives IP packets from the IWF via a raw socket interface, using the
message IWF_IP_PACKET. The associated local connection reference will be used to determine to which
MT (radio connection in fact) it is associated.
Then it will determine if it is an IP signalling packet or an IP data packet, by analysing its DSCP code
(the IP signalling packets have a DSCP corresponding to a specific class).
The IP signalling packets are transmitted directly to the Control Channel Management block of the RCF
(with the local connection reference).
The data packets are analysed to perform the mapping between IP QoS classes and radio bearers / radio
QoS classes: based on the DSCP code of the IP packet, a radio bearer is selected, with a radio QoS class
associated to it. The RCM manages a fixed number of radio bearers per MT, each one associated to one of
the radio QoS class available. These radio bearers will be: 0—4 for signalling channels, 5—31 for data
channels.
At the RCM level, a table will be stored for each MT identified by its local connection reference with, for
each valid DSCP code, the associated [bearer id, Radio QoS class, SAP id].
If the radio bearer is not yet established, the QoS Broker “is about to” send the characteristics of this radio
bearer to the IWF, which will forward the information to the RCF with message
RADIO_ACCESS_ALLOCATION. In the meantime, the IP packets will be stored.
When the message RADIO_ACCESS_ALLOCATION is received from the IWF, we update the RCM table
and a request is made to the Data Channel Management block of the RCF to establish the radio bearer,
with the local connection reference, the radio bearer Id, the radio QoS class, the DSCP code, as
parameters.
An answer is expected from the RCF, to give the status of this operation, upon which the radio bearer is
declared established or not. The answer will contain the local connection reference, the DSCP code, the
radio bearer Id and a SAP Id as parameters.
If it is established, the IP data packets can be transmitted to the Data Channel Management block of the
RCF (with the local connection reference, the radio bearer Id and SAP id), to be sent on the radio bearer
by the AS.
The RCM can also receive the message RADIO_ACCESS_ALLOCATION from the QoS Attendant of the
IWF, when a request from a MT to open a radio bearer associated to this DSCP code has been sent to the
QoS Broker. We will use the same process as for an incoming IP packet, which has been described before
(mapping between DSCP / radio bearer + radio QoS class, update of RCF table, and request to the RCF to
open the radio bearer).
The RCM can also receive the message RADIO_ACCESS_ALLOCATION from the QoS Attendant of the
IWF, in the Fast Handover case (a specific value of parameter status will identify this situation). In this
case, we receive a list of the currently used DSCP codes, and their associated radio QoS classes. We will
store this information in the RCM, and when the radio connection between the MT and RG is opened (as
a part of the Fast Handover process), we will use these data to establish the radio bearers, at the same time
we establish the radio connection.
4.3.2.3 Packet Reception block
The IP signalling packets and the IP data packets received from the RCF are transmitted to the IWF via a
raw socket interface, using the message IWF_IP_PACKET.
D0103v1.doc 82 / 168