Moby Dick Consolidated System Integration Plan

D0103v1.doc Version 1 6.7.2003
instead of a DSCP, and the TUM associates itself this service identifier with a DSCP value, loaded from
the network, thanks to the Service Table.
So, when a user registers, the AAAC module in the MT simply sends a list of service identifiers, with
their associated DSCPs, to the TUM, via the /dev/dscp character device (see figure 27). For example, it
can write ‘SIG 50’, ‘S1 5’, ‘S2 10’, ‘S3 15’, …, ‘S7 35’ on the device. Then the ST looks like in Table 5.
Service DSCP
SIG 50
S1 5
S2 10
S3 15
S4 20
S5 25
S6 30
S7 35
Table 4: Service Table example
What we call here a ‘service’ is only a marking type. The service notion in the MT is lightly different
from the service notion in the network. In fact, S1 means ‘the first service marking type’. So, if the user is
authorized to use only a subset of the network services, it is possible that several marking types will have
the same value, which means that different applications associated with different service names may, in
fact, use the same DSCP.
During the user registration, the MT will always receive seven DSCP codes, which is the number of CoS
defined in Moby Dick. The filters will also be the same in all the Mobile Terminals.
By default, all the DSCPs are set to 0, excepted the SIG value, which is set to 34 (100010 in binary). Each
DSCP can be manually initialised, by the user or the MT administrator himself, by writing ‘SX DSCPX’
on the /dev/dscp character device, where X is the service number. However, a manual initialisation of the
DSCPs is probably useless, considering that a user cannot send traffic towards the network without
registering first.
4.1.2.10 Monitoring Extensions to Ethernet / WLAN driver
4.1.2.10.1 Monitoring Extensions to Ethernet driver
One of the access technologies covered by the inter-technology handover within Moby Dick is Ethernet,
which entails specific availability constraints, as described in this section. This evaluation requires the
distinction between a handover (i) towards an Ethernet interface and (ii) away from an Ethernet interface
to a different technology.
In the (i) case, the handover decision algorithm, which is located in the MTNM on the Mobile Terminal
within the framework of Moby Dick, has to be aware about the presence and availability of the Ethernet
link. This is not as trivial as for example in WLAN, where the signal quality, which is provided by the
wireless tools from the periodical beacons, implies the presence of the medium. In order to signal the
availability of the Ethernet medium to the MTNM module, a monitoring extension is required. Therefore,
the medium-independent interface (MII) is deployed in Moby Dick. This extension is part of the Fast
Ethernet standard and provides support for 10 and 100 Mbps media segments. In order to announce
medium availability to the MTNM module, the status register of this attachment is deployed.
The second case does not require extension, but the user has to be aware that a handover away from
Ethernet has to be announced ‘manually’, since there is no signal quality decrease, which gives handover
preparation time. The medium availability is one or zero; i.e., the cable is connected or unplugged. In
order to provide fast handover from Ethernet to any other technology, the user must announce the desire
to handover via a manual trigger before unplugging the cable.
4.1.2.10.2 Monitoring Extensions to WLAN driver
In Moby Dick the hostap driver (http://hostap.epitest.fi/), version 19-05, created by Jouni Malinen will be
used.
The WLAN driver at the MT will include also a filtering function to be able to provide the right
information/messages to the upper layers (essentially the MTNM and the IPv6 stack).
The WLAN driver will be configured to work in ad-hoc mode, using a common SSID and a common
frequency with the WLAN ARs in the Moby Dick network. This configuration, and the reasons behind it,
is explained in detail in appendix A.
The filtering function has three missions:
D0103v1.doc 43 / 168