Copyright 1996 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.
This article was published in the June 1996 issue of
IEEE Personal Communications.

ABSTRACT

 

Integration of fixed and mobile networks can be facilitated by reusing fixed network protocols in mobile networks. In this case, mobility aspects of signaling transfer must be handled by the lower-layer protocols in he signaling stack. This article presents a simple connectionless network-layer protocol that implements transparent mobility support and can therefore be used for efficient signaling transfer in a microcellular mobile system. The protocol has been developed as part of the research efforts for the European third-generation mobile system UMTS (Universal Mobile Telecommunication Systems).

 

 

Connectionless Signaling Network Layer in UMTS

 

Hakan Mitts, Technical Research Centre of Finland
Guido Luijten, KPN Research
John A. Korinthios, National Technical University of Athens
John Nelson, University of Limerick

 

In Europe, a third generation mobile system called the Universal Mobile Telecommunication System (UMTS) is under research. UMTS is being standardized by the European Telecommunication Standards Institute (ETSI).1 Work in ETSI is supported by research in the RACE II and ACTS programs funded by the European Union.
When deployed, UMTS should provide mobile users with new wideband services such as wireless multimedia -- including real-time video and high speed data -- in addition to more conventional services already offered by second generation mobile systems. A key element of UMTS is the attempt to integrate it with a fixed network infrastructure, the target being the ATM-based Broadband ISDN (B-ISDN). Information on the UMTS system and services can be found in [1, 2].
UMTS developments have attempted to utilize existing or developing fixed network protocols for control functions common to both mobile and fixed networks. The use of fixed network -- mobile "ignorant" -- signaling protocols could be facilitated by a signaling transfer mechanism that hides the effects of certain mobility aspects, mainly handovers, from the upper layer signaling protocols. The need to support micro cellular networks with very frequent handovers, many usage environments with different network topologies and functional allocations and a high volume of signaling, puts significant requirements on such a signaling transport mechanism.
Many solutions to transparently transfer data in mobile networks have been developed. Some of these could have been adapted to transfer signaling in UMTS. Currently known mechanisms include link layer solutions such as the ATM-specific mechanism presented in [3], and network layer solutions such as Mobile-IP [4]. None of the solutions available at the time of study were found completely satisfactory for UMTS. One of the common problems was the rather high complexity due to versatility beyond the requirements for UMTS signaling transfer. To fulfill the requirements identified, a simple connectionless network layer protocol, tailored for use in rooted tree topologies, was developed.
This article introduces the proposed network layer protocol, the rationale behind it and its main functions and features. While the emphasis of the discussion is on the transfer of signaling, the concepts could also be applicable for the transfer of user information.

UMTS System Requirements

One of the key goals of UMTS is to support unified access of mobile terminals in a wide variety of usage environments. Possible environments, as shown in Fig. 1 [5], include rural and highway environments (today typically served by cellular systems), metropolitan micro and pico-cellular areas (today served by PCS Networks), both domestic and business private indoor environments (today served by wireless systems such as CT2 and DECT) and various mobile environments such as trains and ships.
All these environments have very different characteristics and requirements. To serve them with a single system, UMTS must be very flexible and easily adaptable to many different network topologies and technologies as well as cost and performance constraints.
UMTS can be divided into two main components, the Access network and the Core network. In this article, we will assume that the Core network is based on Broadband ISDN (B-ISDN) and Intelligent Network (IN) technologies. Most of the complexities related to the different UMTS usage environments impact on the UMTS Access network that will be the focus of this article.
From a signaling point of view, the Access network is the part of UMTS where access signaling procedures (as opposed to Signaling System 7 based network signaling) are used. The main component of the UMTS Access network is the Radio Access System (RAS).2 The RAS provides the interface between the mobile terminals (MT) and the UMTS Core network. For switching, the B-ISDN access switch (referred to as the Local Exchange, LE) provides the gateway between the Access and the Core networks. For mobility control, the gateway is the Mobile Service Control Point (MSCP). The LE and the MSCP are thus members of both the Access and the Core Networks. A single Access network contains all Radio Access Systems connected to a single LE and controlled by a single MSCP. The resulting high-level architecture of UMTS is shown in Fig. 2.
The various usage environments to be supported by UMTS affect the topology of the Radio Access Systems and hence also the topology of the Access network. The topology of a RAS can vary from a single base station in the case of a small domestic environment to a multi-level Access network in a public environment. As all the proposed RAS topologies reduce to a logical tree, the Access network will also be tree-like with the LE as the root. Some possible Access network topologies are shown in Fig. 3.
The topology is not the only difference foreseen between different Access networks. There are strong requirements to support different allocations of mobility control functions in different environments. As UMTS will be a multi-operator system used in highly competitive environments, each operator should be able to decide and even change the allocation of control functions to nodes within the Access network depending on the service requirements of their subscribers or on the Quality of Service (QoS) level that is profitable in any given environment. To give an example, time critical control functions might be located close to the radio interface in environments where high speed users (e.g. cars on a highway) are expected. On the other hand, in environments with high densities of base stations it might be much more economical to keep the base stations very simple and provide more centralized control functions allocated closer to the root of the Access network.

UMTS Signaling Requirements

To support the identified system requirements, new capabilities are needed in the signaling protocols used in UMTS. Again, the Access network is the main focus of these requirements, since the signaling capabilities of B-ISDN and IN are assumed for the Core network. Three major requirements can be identified.
The first requirement is to efficiently transport and route signaling messages in all Access network topologies. The system definition of UMTS calls for the ability to exchange signaling messages in an end-to-end fashion between any pair of nodes in the Access network with minimal processing in intermediate nodes. Figure 4 illustrates the potential signaling peers of the mobile terminal in a simplified public environment.
In general, the RAS is composed of a number of Cell Site Switches (CSS) each with an associated number of Base Transceiver Stations (BTSs). The mobility control functions may be distributed to the BTSs, CSSs and MSCPs (of which more than one level can exist). Referring to the topologies of Fig. 3, signaling only takes place between nodes in the same sub-tree.
Another requirement relates to the cellular architecture of UMTS. In areas where high bit rate services will be supported, UMTS must use very small cell sizes. Very small cell sizes may result in very frequent handovers. This puts stringent requirements on signaling performance during handover.
To facilitate the integration of UMTS into B-ISDN and IN, reuse of fixed network protocols is foreseen in the UMTS Access network. The UMTS signaling protocol stack must therefore ensure that existing or developing fixed network protocols can be included. It is also anticipated that UMTS will support different radio access technologies based on advanced CDMA or TDMA with different functionality and protocol stacks [6, 7]. Thus signaling transport in the Access network should be independent of the underlying radio technology while ensuring that many different types of upper layer signaling protocols can be transferred.

Rationale for A Connectionless approach to the transport of signaling

To address the signaling requirements discussed above, a connectionless service has been proposed for the transfer of signaling messages between all nodes in the UMTS Access network. In this section, the rationale for the connectionless network layer approach will be given after reviewing some of the approaches adopted in existing systems.
Current second generation systems like GSM [8] and CDPD [9] have adopted connection-oriented approaches at various protocol layers to implement their respective Access networks.3 For example, GSM uses the connection-oriented class 2 of the Signaling Connection Control Part (SCCP [10]) protocol, while in CDPD networks, signaling is transported on top of the connection oriented Mobile Data Link Protocol (MDLP). Recent research work on mobile systems such as [11] have also addressed the issues of supporting mobile users in a connection-oriented way.
In a mobile environment, the route between a mobile terminal and a fixed network signaling function can change frequently due to the movement of the mobile terminal. A connectionless service can be used to make the movement of the mobile terminal transparent to the fixed peers. That peers are as unaware of the movement of the terminal as possible is particularly useful as cell sizes decrease. In systems with very small cells, a connection oriented approach requires very frequent reconfiguration of all active signaling connections. This puts significant processing requirements on the nodes hosting signaling applications communicating with the terminal. A connection-oriented approach can also be bandwidth consuming, because of the number of messages required to reconfigure the connections.
A connectionless approach can distribute much of the mobility related processing towards the radio interface of a tree-like network, i.e. towards the part of the network where nodes are most abundant (Fig. 3). This can alleviate the potential problem of overloading a single point of control in the fixed network and addresses the requirements related to handover performance.
[12] provides some comparative information on the performance in terms of signaling load and delay for connectionless and connection-oriented systems.
The rationale for the connectionless approach will be discussed from the perspective of: integration with existing systems, multiple signaling transactions, message distribution and reliable transfer.

B-ISDN and IN integration

To support the requirements on integration with B-ISDN and IN, the connectionless service in the signaling protocol stack of the Access network can abstract the signaling applications from certain mobility specific problems, especially those that result from handovers. For instance, it is possible that a terminal will need to change BTSs during a signaling procedure, e.g. while performing a location update. The signaling applications involved in the signaling procedure can be abstracted from the change of BTS by the signaling network layer, allowing the signaling procedure to complete regardless of the handover between BTSs.

Parallel signaling transactions

In UMTS, the use of several parallel signaling transactions between the mobile terminal and fixed nodes in the access network is foreseen. In the connectionless approach, a single routing function handles the transfer of all messages involving the same mobile terminal for any number of concurrent signaling transactions with the same or different network nodes. In a connection oriented approach, the signaling transactions with each node in the fixed network must be transferred through separate connections, each of which must be handled separately thus increasing the load when more than one connection is needed.

Message Distribution

The connectionless approach provides an additional benefit when message distribution functions in the Access network are required. A connection oriented approach is inefficient for distributing messages as a separate connection must be established with each destination. In a connectionless approach, each message sent can easily be 'multiplied' in any node by simply multicasting it over several physical interfaces towards several destinations. This requires very little additional functionality in a routing function.

Reliable Transfer

Perhaps the main argument against using a connectionless approach in a mobile system is that a connectionless message transport function is unreliable due to the lack of end-to-end delivery guarantees. However, this potential drawback can be overcome in UMTS for the reasons discussed below.
In a wireless system, the radio interface is the most unreliable communication link. However, in UMTS the radio interface is will provide many forms of protection against message loss including adaptive Forward Error Correction (FEC), Automatic Repeat Request (ARQ) and diversity mechanisms. With these, a bit error rate of 10-6 is targeted [13].
In connectionless systems, the main source of message loss is congestion experienced in the intermediate routing nodes. For signaling this is less of a problem as the amount of signaling is lower and also more predictable than the amount of user data. The maximum number of mobiles making active use of an Access network can be estimated and -- if needed -- limited, again making signaling load estimation easier. Therefore it is possible to dimension the buffers needed so that message loss is avoided.
Even if message loss occurs, its consequences can be counteracted in UMTS. Signaling applications in UMTS are expected to communicate using upper layer end-to-end protocols which can include the capability to detect message loss. In this way any residual message loss can be handled in an end-to-end fashion and the signaling error rate over the air interface will be sufficiently low for signaling purposes.
Based on the above, we argue that the use of a connectionless service to transport signaling messages can provide a viable alternative to the connection-oriented approach.

Introducing a Signaling Network Layer in the UMTS Access network

The connectionless signaling transfer is introduced into the UMTS Access network in the framework of a layered protocol model. More specifically, a (Signaling) Network Layer has been included in the signaling stack of the UMTS Access network as illustrated in Fig. 5. It is not anticipated that the B-ISDN LE will include a Signaling Network Layer and hence the LE is not included in Fig. 5. The full functionality of the Signaling Network Layer protocol has been presented in [14]. A more formal definition of a simplified version is given in [12].
The proposed Network Layer performs the functions assigned to a network layer in the OSI Reference model. It routes upper layer messages between communicating end nodes. It does not perform actual mobility or call control functions. These functions are performed by the signaling applications, that communicate with their peers using application layer protocols.
The service offered by the proposed Network Layer is similar to that of the OSI Connectionless Network Layer Protocol (CLNP) [15] or the Internet IP-protocol [16]. The service interface chosen for the Network Layer is however that of the connectionless Signaling Connection Control Part protocol (SCCP, [10]) of the Signaling System 7 (SS7). The reason for this is that many of the application layer protocols carried in the Access network are expected to be based on the SS7 association control protocol TCAP (Transaction Capabilities Application Part, [17]),4 which has a defined interface to connectionless SCCP. In this way, no convergence function is needed to support TCAP-based protocols over the proposed network layer. It should be stressed that only the SCCP service interface definition has been adopted, the protocol itself is quite different from the SCCP protocol.
The network layer protocol has been defined to operate on a tree-like topology of any depth. The Access network topologies considered for UMTS can be reduced to logical trees provided that one node is selected as the root and a hierarchy of nodes is maintained. This includes all topologies shown in Fig. 3.
Within the Access network topology, three types of nodes are identified. The Network Layer has different functions in each type of node. The node types for a simplified Access network topology are shown in Fig. 6.
The mobile terminal is one of the three types of nodes in the Access network. The Network Layer in the mobile terminal is very simple, as it only needs to distribute incoming messages to the signaling applications in the terminal and forward outbound messages to the fixed network. No dynamic routing information is maintained in the mobile terminal.
The fixed part of the Access network is composed of two types of nodes. An Edge node is the fixed network termination of the radio link layer, i.e. the node closest to the edge of the Access network that contains a Network Layer. Normally the Edge nodes correspond to base stations, however in CDMA-based systems a level of nodes implementing macro diversity combining could exist between the Edge node and the radio interface , see [6].
All other nodes in the fixed part of the Access network are of the type Fixed. Any number of hierarchical levels of Fixed nodes can exist. In UMTS, typically, two levels are foreseen, as shown in Fig. 6.
It should further be noted that for signaling in UMTS, the fixed network nodes are restricted to communicating with (effectively controlling) mobile terminals only in the subtree below themselves. Thus, Fixed node (A) can communicate with a mobile that is within the coverage area of any of the Edge nodes (1-4), while Fixed node (B) can only communicate with a mobile terminal that is within the coverage area of Edge nodes (1-2). This limitation resulting from the overall UMTS design has been exploited to restrict routing information for a mobile to the path extending from the Edge node currently used by the mobile towards the root of the tree, e.g. to the nodes (2), (B) and (A) in Fig. 6. Therefore, routing information for the MT is not maintained outside the single path towards the top-most node of the hierarchy.
For communication between fixed nodes, no such restrictions are needed but the maintenance of the related routing information is outside the scope of the Network Layer protocol presented.

The Network Layer protocol

The Network Layer is implemented using a very simple protocol. Simplicity of the protocol is essential to enable efficient and rapid operation. The details of the protocol will be described using an example shown in Figs. 7 to 10.
The aim of the example is to highlight how the protocol implements message (re)routing during handover. In developing the protocol described, many different ways to implement handover were considered. Analysis indicated that the worst case scenario was one where handover occurs so suddenly, that no messages to control the handover can be sent over the old base station. This type of handover is sometimes called hard, forward handover. The functionality needed to support this type of handover however was found to be applicable to any other type of handover with little loss in overall performance. Thus, in order to keep the protocol simple, all handovers are handled by the protocol as if they were hard, forward handovers. Therefore the example will be described in terms of this type of handover even though many other handover types could be supported as well.
The protocol has four messages. The messages and their use are described below:
Unitdata (udt) -- This message is used to carry upper layer data. In addition to the usual fields of upper layer payload and Destination and Originator addresses, the udt message can also contain an address indicating Intended recipient. This allows the udt message to carry the address of a mobile as the Intended recipient even when the message is multicasted within the Access network based on a multicast Destination address (this is required in the initial route set-up described in steps 1-3 in the example below).
Routing update (rtu) -- This message carries the information that allows routing data pertaining to a specific mobile terminal to be modified. In addition to the identity of the mobile, the message indicates whether routing information pertaining to a mobile is to be added (new route, add) or deleted (old route, del). Sending of rtus is controlled by base stations according to the status of the radio link with a given mobile terminal.
Find (fnd) -- This message is sent over a broadcast radio channel when a base station receives a packet for a terminal for which no routing information is available and the whole udt message is not broadcasted over the radio interface.
Identify (idn) -- This message is sent by a mobile terminal to a base station whenever a mobile terminal has established a radio link with a base station. This happens when a mobile terminal connects to a new base station during handover or for terminal initiated functions.
The operation of the Network Layer functions will be illustrated within a UMTS Access network, which follows the topology of Fig. 6. The MSCP with address (A) and the CSSs with addresses (B) and (C) are of type Fixed. The BTSs with addresses (1), (2), (3) and (4) are of type Edge . The MT with address (MT) is of type Mobile Terminal.
The example is composed of a number of steps executed in enumerated chronological order. The contents of the routing tables of the involved nodes are shown in the figures. Also the protocol messages exchanged are shown with the information relevant for the protocol. The example starts with the idle mobile terminal MT near BTS(2). A signaling application in the MSCP needs to exchange signaling messages with the MT. The signaling application knows of the existence of the MT as the result of a registration process outside the scope of this study. During the example, the MT will hand over to the BTS(3).
The steps 1-3 refer to Fig. 7 and depict the steps required to deliver the first outbound message to the mobile. This process results in the routing information for the mobile to be set up.

1 -- In the MSCP, a signaling application generates a first upper layer signaling message for the mobile. The message is passed to the network layer within the MSCP over the network layer service interface, indicating the MT as the destination. The routing table of the MSCP is consulted and no routing information is found for the MT. Therefore, special process must be started to initially locate the terminal. A network layer Unitdata (udt) message is constructed with A as the originating address and a suitable multicast address X as the destination address. The field for the Intended recipient in the udt message will contain the final destination address, i.e. the address of the MT.

2 -- The multicast address is used to distribute the message within the fixed part of the access network. If additional knowledge about the assumed whereabouts of the terminal is available, a smaller set of the Access network might be tried first (this is assumed in Fig. 7). Alternatively, the message is distributed (effectively broadcasted) in the whole Access network using a different multicast address.

3 -- Eventually the message will reach one or more BTSs. Each BTS receiving a multicast addressed message stores the message in a local buffer and broadcasts a Find (fnd) message over the paging channel of the air interface. The fnd message is used to alert the MT. For this purpose it carries the MT address. The Find message can be repeated to ensure that the mobile receives it in spite of temporary coverage problems, etc. If no answer is received from the MT within a given time period, the received multicasted udt message is deleted from the local buffer with the assumption that the terminal is not within the coverage area of the BTS.

If all goes well, one of the broadcasted fnd messages will be intercepted by the MT. The fnd will indicate to the MT that there is a message waiting for it in the BTS that sent the message. Steps 4-6 below refer to Fig. 8, which illustrates the way the first message is received by an MT and the creation of the initial routing path.

4 -- To communicate with a BTS, the MT must first establish a radio link using some radio interface dependent link layer protocol. Depending on radio access technology, this could involve acquiring a TDMA slot or a CDMA spreading code enabling communication between the MT and the BTS, see e.g. [UM&95]. Over this link the MT can then issue an Identify (idn) message containing the network layer address of the MT. This allows the BTS(2) to create a mapping between a radio link, i.e. RL1 in Fig. 8, and the MT address. The related entry is added to the routing table. RL1 can now be used to deliver any signaling message to the MT.

5 -- The base station delivers the pending udt to the MT over the radio interface from BTS(2).

6 -- Concurrently, the BTS(2) issues a Routing Update (rtu) message towards the rest of the fixed nodes. Since there were no entries previously associated to MT, the rtu message is forwarded to the root node of the network. Each time the rtu message reaches a node, a mapping between a signaling link and the MT address is created in the routing table. As an example, in the routing table of CSS(B) a mapping is created between the MT address and the link that connects CSS(B) to BTS(2). As a result, a complete routing path up to the MT is created.

Normal message exchange can proceed once the initial path to the MT has been created. Suddenly, the radio link quality deteriorates below a given threshold and a handover has to be performed, as illustrated in Fig. 9. During a handover, the routing tables in all affected entities must be updated, to create a new routing path to the MT.

7 -- Firstly, the old radio link is released. Note that this could happen in a controlled way so that the MT releases the link or abruptly, in which case a link layer abort will be detected by the BTS, see [7] for details. In either case, BTS(2) deletes the entry for the MT in its routing table.

8 -- As BTS(2) no longer has a route to the MT, it informs CSS(B) about the loss of connectivity using the RTU_del message. Note that BTS(2) does not know that the MT is going to connect to BTS(3). When receiving the RTU_del message, CSS(B) modifies the entry for MT in its routing table to point to a local buffer. This buffer is used to store any messages in transit for the MT while no valid routing information is available for the MT. Note that no RTU_del message is sent higher up in the Access network. This is only done if routing information for MT is not obtained within a time-out period. Only if a time out occurs, will the next level in the hierarchy (the MSCP) be informed. The time-out period should be selected relative to the time a mobile needs to acquire a new base station.

9 -- In the mean time, the MT has found a new BTS and has set up a new radio link with BTS(3). The MT can then issue an Identify (idn) message to BTS(3) over the new radio link. Within the BTS(3) an entry for MT is created indicating that the MT is now connected via radio link RL2.

10 -- Next, a RTU_add message is sent to CSS(C). The RTU_add message is processed in CSS(C), and an MT entry is added to its routing table pointing to BTS(3).

11 -- CSS(C) forwards the RTU_add message to the MSCP. On receiving the RTU_add message the MSCP Network layer proceeds to update the MT entry, and will find that there already is a valid entry for the MT (i.e. not a pointer to a buffer). The existence of a pointer indicates to the MSCP that an invalid "downward" route exists for the MT. After the MT entry had been modified, the MSCP sends an RTU_del message along the old route to delete it.

12 -- The RTU_del message sent by the MSCP arrives in the CSS(B). Here it results in the deletion of the MT entry. As the entry is pointing to a buffer, no RTU_del message needs to be sent by CSS(B).

Now the Routing Table Update procedure is finished and the messages can be routed via the new path to the MT. This is shown in Fig. 10.

13 -- As the entry in CSS(B) was pointing to a buffer, any messages for MT stored in a buffer in CSS(B) will be released. When the messages are released from the buffer, no valid routing information exists any more in CSS(B). In this case, the routing function will try to return a message to its originator to indicate that a problem has been encountered while routing. In this case the message will be returned towards the MSCP.

14 -- In the MSCP however, an attempt will be made to route the message for MT. As valid routing information exists for the MT in the MSCP, the messages can be routed to the CSS(C). Had this not been the case, the message would have resulted in an error indication to the originating application process in the MSCP. The originator would then know that the destination is no longer reachable and, if required, route finding can be initiated.

15,16 -- Since the routing tables in CSS(C) and BTS(3) are also updated, the Network Layer messages can be sent correctly to the MT, without being lost due to the handover. When the messages have finally reached the Mobile Terminal they are delivered to the Application Layer.

Note that with this functionality in the Network Layer, it is not necessary to release the upper (Application) layer signaling associations between the MT and the MSCP during handover. Nevertheless, if MT would have had an Application Layer signaling associations with BTS(2) and/or CSS(B), these would have been released, as MT moved out of the subtree of these nodes when handing over to BTS(3).

Functions of the Signaling Network Layer

Next, some of the key functions of the Network Layer relevant to the routing of signaling messages will be discussed. While the connectionless routing as described in the previous sections forms the conceptual foundation of the Network Layer, a number of additional functions have been included, either because they are essential to routing in a mobile environment or because their inclusion has not resulted in a significant increase in the complexity of the protocol.

Route Finding

When a signaling application in the fixed network needs to send messages to a mobile terminal not actively engaged in communication, routing information for that terminal will not initially be available. Route finding (see steps 1-3 of the example) is the function of initially determining the path towards a given mobile terminal and sets up the routing tables in the appropriate nodes to make it possible to route messages to the mobile terminal. After Route finding has completed, the Routing update function is used to maintain routing information for mobiles that are actively engaged in communication, i.e. that have established a radio link with a base station.
In current mobile networks, the Route finding function is usually covered by paging. Paging however mainly refers to finding the exact point of attachment of the mobile terminal during call set-up. Route finding is a more generic function in that it enables any node and any signaling application (not just call set-up) in the fixed network to initiate signaling with a mobile terminal. Route finding also differs from paging in that routing information will be available for a given terminal in the complete path from the current Edge node towards the root of the Access network after Route finding has complete, regardless of which node initiated the function.
Route finding is based on multicasting. When a signaling application sends a message (the first) towards a mobile terminal for which no routing information is available, the message is multicasted within the relevant subtree of the Access network. In the simplest case, the message is multicasted over the complete subtree. In a more advanced scheme, additional intelligence in the Access network might provide information about the likely whereabouts of the mobile terminal. This would allows the message to be multicasted only in some parts of the Access network, thus reducing the overall load on the Access network.
When a multicasted message reaches the base stations, one of two approaches can be followed. If radio bandwidth is to be carefully conserved, a base station can store the received message and only send a short Find message over the radio interface as shown in the example. If radio bandwidth is not quite as scarce, the delay performance of the Route finding function can be improved by broadcasting the complete message over the radio interface. Just as in the example, a mobile terminal would need send an Identify message in response to a full message to trigger the Routing update process.
In both cases, subsequent messages will find that routing information for the terminal is available. When the interaction of the terminal with the network ends, the routing information will be deleted. Any new message exchange, initiated by a fixed node, will again trigger the complete Route finding function.

Routing

The routing function makes up the core of the connectionless network layer service. It is located in every node in the Access network except for the mobile terminal.
An important aspect of most connectionless services and associated routing protocols is the capability to adapt to topological changes in the network and to route messages around failed connections. In a tree topology there are no redundant routes and consequently there is no need to support adapting to topological changes. Such a feature has thus been excluded from the protocol.
On the other hand, to support routing in a mobile system, a function not normally associated with connectionless services has been introduced. During handovers, short intervals can be encountered, when complete routing information does not exist for a mobile terminal (see step 8 in the example). These intervals occur when the terminal changes base stations and last until all the routing tables affected by the movement have been updated with the new routing information. In order not to lose messages in such cases, messages are stored by the routing function for a short time to await that the routing information will be updated. The aim is to keep messages buffered until the new routing information becomes available and the buffered messages can be correctly re-routed to the intended destination.

Routing Update

For the network layer to correctly route the signaling messages, a mechanism to maintain the routing information is required. Here two cases can be identified. The first one applies to routing information for signaling applications, while the second one applies to the mobile terminals.
Since signaling applications are fairly static, their routing information only changes slowly, i.e. only when a signaling application is redeployed within the Access network. Consequently the routing update function for information pertaining to applications can be based on management procedures.
To maintain the routing information pertaining to mobile terminals, the mechanism described in the example is used. As the routing update function is quite simple, it has not been defined as a separate protocol as is commonly done for protocols like IP and OSI CLNP. Instead the routing updates for mobiles form an integral part of the network layer protocol.
One of the key features of the protocol is that the Edge nodes completely control routing updates. This is possible because the link layer of the radio interfaces proposed for UMTS are connection oriented. Therefore a base station will always maintain some form of logical link with all active mobile terminals within its coverage area. When a mobile terminal enters the coverage area of a base station, the mobile and the base station must establish a new radio link. Over this link, the mobile identifies itself and the base station uses this information to initiate the addition of a new route. The link is maintained for as long as the mobile stays connected to the base station and maintains communication. When a radio link cannot be maintained any longer, a base station can initiate the deletion of routing information for a given mobile without the need for any additional message exchange between the mobile and the base station.

Addressing Considerations

In the UMTS Access network, three cases of routing need to be supported. The first two place special requirements on the Network Layer with respect to addressing.
Firstly, routing is required for messages sent from nodes in the fixed network towards the mobile terminals. The main goal is to isolate signaling applications from tracking the exact location of the terminal. Routing decisions are made based on the identity of the mobile terminal. Consequently, each mobile terminal in the Access network must have a unique address. In this article, we will not discuss how a unique address could be assigned. We will assume that a suitable method of assigning temporary location dependent addresses is used such as the TMSI assignment for GSM [8] or the use of the DCHP as discussed in [18].
Secondly, messages sent from the mobile terminal must be routed towards signaling applications in the fixed network. Here the main goal is to provide location transparency to the signaling applications in the mobile terminal when these access signaling applications in the fixed network. Location transparency isolates the functions in the mobile terminal from the topology of the Access network and the allocation of the signaling functions on top of this topology. To achieve this, each signaling application must be reachable through a unique address. The assignment of these addresses could be standardized or "well known".
Thirdly, messages should be transferred between signaling applications residing in different nodes in the fixed part of the Access network. This case does not impose any specific requirements and is not considered further.
A key aspect of the proposed Network Layer is providing an addressing format that allows a single routing function to provide routing both towards mobile terminals and towards specific signaling applications regardless of the location of the application within the Access network. The difference between the different routing cases described earlier is limited to the semantics of the addresses used.
When messages are destined towards a terminal, the main component of the routing address is the identity of the terminal. In the direction towards the fixed network, the main component of the address is the identity of the desired signaling application. To support both aspects of routing, a special address format is needed. A conceptual address format for the Network Layer address format, shown in Fig. 11, is assumed. Actual addresses must be defined within the context of a hosting network.
The address format consists of a node part and an application part. When sending messages to a terminal, the node part of the address will contain the terminal identity and the application part the identity of the signaling application residing in the terminal. In the direction towards the terminal, messages are routed based on the node part, i.e. effectively based on the terminal identity. Within the terminal, the Application part of the address allows the Network Layer to deliver received messages to the correct signaling application.
When messages are sent from the terminal towards nodes in the fixed network, the terminal needs to communicate with a specific signaling application to implement a function such as call set-up. To achieve this, the address component used will be the application part. The node part of the address will contain a null identifier (effectively indicating 'I do not care what node this application resides on'). In this case the messages are routed based on the application part of the address.
It should be noted that a node performing routing does not need to know the 'direction' of a message to correctly route a message. Whenever a node part is present in the address, it is used as the primary input to the routing algorithm. When the node part is missing, messages are routed based on the application part.
The addressing structure also supports multicasting and broadcasting of messages. If a message is to be multicasted, a multicast address is used in the node part of the address. The routing tables contain one or more entries for multicast addresses and the messages are duplicated as appropriate.

Additional Protocol Features

The previous sections only presented the key features of the Network Layer. A number of additional features have been included in the complete Network Layer functionality as described in [14]. These additional features do not require new protocol messages but can be implemented by simply extending the messages with new parameters. Some of the functions that could be supported are:
Allocation of Temporary Addresses to Mobile Terminals -- For security reasons, UMTS system requirements specify that information sent in clear over the radio interface must not reveal the identity of an attached user nor of the terminal itself to guarantee location privacy. As the mobile terminal's address needs to be sent at least during the Route finding stage, a mechanism of assigning temporary addresses of local significance to mobile terminals can be adopted. A temporary address can be assigned using the first Identify message and the subsequent Unitdata message sent from the network whenever a new mobile terminal enters an Access network.
Authentication of the Terminal -- After each handover, the mobile terminal's identity must be provided to the network. One-way authentication of the terminal can be supported by extending the Identify message. This can be used to prevent signaling messages from being intercepted by terminals masquerading as valid terminals. More extensive security mechanisms would be implemented as application layer protocols.
Tracking -- Normally, routing information for a mobile terminal is deleted when the radio link to the mobile is released. If found useful, the routing information for a mobile could be maintained even when no radio link exists. In this case the mobile must report back to the network whenever it notes that its preferred base station changes or when stationary, based on a timer. The benefit of this would be that the Route finding function would not be required while the cost is one of contacting each base station even when no communication is active.
Support for User Data Services -- While the main purpose of the proposed Network Layer is to transport signaling, end-user data could also be carried. This includes the transfer of services similar to the Short Message Service (SMS) in the GSM system where also user information is carried using the signaling channel [MP92]. In UMTS, the Network Layer could be useful to transport very bursty, low volume user data or user data that is broadcasted in the Access network. In other networks, the proposed protocol could of course be used solely for user data transfer.

SDL Verification

A functional and behavioral analysis of the Network Layer was undertaken by generating formal SDL specifications for each type of node: Fixed, Edge and Terminal. SDL is the ITU-T Specification and Description Language [19, 20]. The SDL supporting toolset used was the Telelogic SDT [21].The purpose was to functionally prove the concepts and to determine the degree of complexity of the operations. Verification and validation were completed by generating and testing a number of network configurations.
Figure 12 is a block diagram of one of the test configurations corresponding to a simple tree based UMTS network architecture. The network nodes MSCP (of type Fixed), CSS (Fixed), BTS (Edge) and MT (Terminal) have been included. This example contains a single MSCP with two attached CSSs, each of which has a single BTS attached. In the configuration, the fixed network links are assumed to be ATM based, for example, using ATM Adaptation Layer type 5 [22]. A generic model is used for the radio interface.
Each of the blocks was decomposed into a number of interacting processes (not shown). Overall, the Network Layer specification and evaluation demonstrated a high degree of simplicity in terms of functionality, potential implementation and reusability of the processes defined. A brief description of the level of functionality associated with each major function (defined as a SDL processes) follows. There was a large amount of re-use of functionality with minor modifications according to node type.
Routing -- The routing function is implemented using a simple algorithm that checks the destination field of the UDTs. If the destination is the current node, the message is delivered, otherwise a request is sent to the routing database to determine the next node.
Routing Database -- As for most routing techniques the main component is the routing database that maintains the routing information. Major functions such as adding, deleting and searching are supported.
Routing Control -- The routing control process is responsible for maintaining routing information (for example, in the fixed network to process the RTUs) and for creating and associating buffers with terminals, as required.
Buffering -- A buffer process is created per mobile terminal when required. It is responsible for temporarily buffering the UDTs, in FIFO order, when there is no current path to the terminal.
Higher Level Abstract Service Interface -- Currently, a rather simplified SCCP interface has been adopted.
Set-up/Initialization -- The set-up/initialization function is responsible for instantiating the various processes and is specific to the simulation model adopted.
A number of test cases were undertaken to test the functionality and to explore the performance of the network layer. The major verification aid was a number of test architectures, similar to that presented earlier, based on various network topologies. One valuable aid was the use of Message Sequence Charts for both test case documentation and result analysis.
The network layer must now be evaluated for performance under different load conditions, and other UMTS access network topologies.

Conclusions

In this article we have introduced the basic functionality of a connectionless Network Layer with capabilities to efficiently support mobile terminals. The protocol has been specified to provide transport of signaling in the UMTS Access network in a flexible and signaling efficient manner. The basic functionality of the layer is the routing, routing updating for mobile terminals and route finding to initially locate mobile terminals. The SDL implementation, and evaluation, of the network layer confirmed the simplicity of the connectionless approach and the specification of a custom-made solution for UMTS. The solution is simple with a high degree of reusability across the supported functions.
While the Network Layer has been given a number of tasks, it should be stressed that all functionality builds upon a few, very basic operations. Thus, implementation of the Network Layer is expected to be simple so as not to cause significant processing or buffering overhead in the fixed network nodes.
The principles presented could be applied to other environments, where efficient and flexible transporting of upper layer protocols in micro and pico cellular environments is required.

Acknowledgments

This article is based on work done in the Work Package GA4 of the RACE II MONET project. All members of the work package have contributed towards the ideas presented in this article; their contributions are hereby acknowledged. The authors would in particular like to acknowledge the onerous SDL specification and implementation of Harri Hansén (VTT) and Michael Barry (UL).

References
 [1] J. Rapeli, "UMTS: Targets, system concept, and standardization in a global framework," IEEE Pers. Commun. Mag., vol. 2, no. 1, Feb., 1995.
[2] E. Buitenwerf et al., "UMTS: Fixed network issues and design options," IEEE Pers. Commun. Mag., vol. 2, no. 1, Feb., 1995.
[3] A. Acampora and M. Nagshineh, "An Architecture and Methodology for Mobile-Executed Handoff on Cellular ATM Networks," IEEE JSAC, vol. 12, no. 8, Oct. 1994.
[4] C. Perkins, "IP Mobility Support," Internet draft, available over Internet from ftp:://nic.nordu.net/internet-drafts/draft-ietf-mobileip-protocol-xx.txt where "xx" is the latest version number, being 14 at the time of writing.
[5] T. Norp and A. J. M. Roovers, "UMTS Integrated with BISDN," IEEE Commun. Mag., vol. 32, no. 11, Nov. 1994.
[6] P.-G. Andermo and L.-M. Ewerbring, "A CDMA-based radio access design for UMTS," IEEE Pers. Commun. Mag., vol. 2, no. 1, Feb. 1995.
[7] [Author: please supply reference info for: "UM&95"
[8] M. Mouly and M.-B. Pautet, "The GSM System for Mobile Communication," published by the authors (fax: +33-1-6931-0338), 1992.
[9] The CDPD Forum, "Cellular Digital Packet Data System Specification," Release 1.1, 1995.
[10] CCITT Recommendation Q.711, "Functional Description of the Signaling Connection Control Part of Signaling System No. 7," CCITT, Geneva, 1989.
[11] K. Keeton et al., "Providing Connection-Oriented Network Services to Mobile Hosts," USENIX symposium on Mobile and Location-Independent Computing, Cambridge, Mass., Aug. 1993.
[12] H. Mitts and Harri Hansén, "A simple and efficient routing protocol for the UMTS Access network," Mobile Networks and Nomadic Applications (NOMAD), vol. 1, no. 4, 1996 (to be published).
[13] A. Urie et al., "An advanced TDMA mobile access system for UMTS," IEEE Personal Communications, vol. 2, no. 1, Feb., 1995.
[14] CEC deliverable No. R2066/VTT/GA4/DS/P/065/b1, "Evaluation of Supporting Protocol Stacks," Sept. 1994.
[15] ISO IS-8473, Information Processing Systems - Data Communication - Protocol for providing the Connectionless-mode Network Service and Provision of Underlying Service, ISO.
[16] J. Postel, RFC 791, "Internet Protocol, Protocol Specification," Defense Advanced Research Projects Agency, 1981.
[17] CCITT Recommendations Q.771-Q.775, "Transaction Capabilities Application Part for Signaling System No. 7," CCITT, 1992.
[18] C. Perkins and K. Luo, "Using DHCP with computers that move," Wireless Networks, vol. 1, no. 3, Oct. 1995.
[19] CCITT Recommendation Z.100, "Specification and Description Language SDL," CCITT, Geneva, 1989.
[20] R. Saracco, J. R. W. Smith, and R. Reed, "Telecommunications Systems Engineering using SDL," North-Holland, 1989.
[21] "SDT 2.3 Reference Manual," vols. 1 and 2, Telelogic, Sweden, 1993.

[22] T. Suzuki, "ATM Adaption Layer Protocol," IEEE Commun. Mag., vol. 32, no. 4, April 1994.

Biographies
 Hĺkan Mitts received a M.Sc. in Electrical Engineering from the Helsinki University of Technology in 1992. After graduation he worked with Nokia Corporation in the field of satellite control systems and with Digital Equipment Corporation as a networking specialist. In 1992 he joined the Technical Research Centre of Finland (VTT) to work in the RACE II MONET project were he acted as the work package leader for the group GA4 studying UMTS signaling protocols as well as IN and ATM aspects. His current research interest include wireless ATM and mobile multimedia systems.
Guido Luijten received his M.Sc. degree in Electrical Engineering from the Delft University of Technology in 1991. In the same year he joined KPN Research to work on the Universal Personal Telecommunication (UPT) service. In 1992 he joined the RACE II MONET project. First he worked on the signaling aspects of UMTS including the use of IN and ATM, and after that on the UMTS radio access system. His other fields of interest are Service Creation, Intelligent Networks (IN), GSM/DCS1800, DECT and PCS (Personal Communication Services).
John A. Korinthios received a Diploma degree in electrical engineering in 1990, and a Ph.D. degree in computer science in 1995, both from the National Technical University of Athens (NTUA). Since 1990 he is working as a researcher in the telecommunications laboratory of NTUA and has been involved in several projects of the European Community including the RACE II MONET project. He has also been working in research projects in collaboration with OTE (the Greek PTT). His research interests include integrated services networks, personal and mobile communication systems, signaling protocols, numbering and addressing, and performance evaluation of mobile networks. He is a member of the Technical Chamber of Greece.
John Nelson graduated with a B.Eng. in electronic engineering from the National Institute for Higher Education in 1983, and received a Ph.D. from the University of Limerick in 1990, where he is currently employed as a Senior Lecturer. His research interests include architectures and protocols to integrate mobile and fixed networks, ranging from system design to physical aspects. He participated in the RACE II MONET project and is participating in the ACTS Rainbow and Exodus projects, the latter through Teltec Ireland. Other interests include architectures and algorithms for VLSI implementation in the areas of error control coding and alternative number systems. He holds an Analog Devices Research Fellowship, leading a project investigating the magnetic read channel.