WO2001072076A1

WO2001072076A1 - Handover in a multi-bearer-type network

Info

Publication number: WO2001072076A1
Application number: PCT/FI2001/000275
Authority: WO
Inventors: Lin Xu; Toni Paila
Original assignee: Nokia Corporation
Priority date: 2000-03-21
Filing date: 2001-03-20
Publication date: 2001-09-27
Also published as: AU2001248392A1; FI20000662A0; FI20000662A; EP1275264A1

Abstract

A network element, or MBAS, for supporting mobility of mobile nodes (MN) in a system (MBN) which is connected to several different cellular bearer networks (BN) including unidirectional networks (DAB, DVB) and bidirectional networks (GSM, GPRS, UMTS). The MBAS is associated with at least one support area, each support area comprising one or more cells in the bearer networks (BN). The MBAS acts as a home agent to mobile nodes at home and as a foreign agent to visiting mobile nodes. The home agent and foreign agent functions are substantially compatible with mobile-IP protocol. The MBAS and the mobile node (MN) have a handover logic for handing over a mobile node to a neighbouring network element. The handover logic is adapted to provide continuous service for a mobile node after it has moved to the support area of the neighbouring network element and before it has re-registered with its home agent.

Description

Handover in a multi-bearer-type network

Background of the invention

The invention relates to traffic management in a multi-bearer packet data network. A multi-bearer network, or an MBN, is a network having the ca- pability to carry a data packet via one of several alternative bearers. To be more precise, the term 'multi-bearer network' should be interpreted as meaning 'multi-bearer-type network', or in other words, a network arrangement which provides multiple different bearer types for data packet delivery. An example of an MBN is a concept known as MEMO (Multimedia Environment for Mobiles), see reference 1. Additionally, the MBN supports mobility of a subscriber terminal. An example of terminal mobility is IP mobility, which is the topic of standard RFC2002 by the Internet Engineering Task Force (IETF). This RFC standard is incorporated herein by reference.

A general problem underlying the invention is how to select an op- timal bearer for each data packet in varying situations in a multi-bearer network. Data packets have different quality-of-service requirements. Situations may vary because the subscriber moves or the network load changes. A solution to the general problem is disclosed in a co-pending patent application FI992850 which, however, is not published at the priority date of the present invention. Accordingly, the solution to the general problem is repeated here.

Selecting the optimal bearer for a data packet between the MBN and the mobile node is based on a combination of 1) the quality-of-service requirement (traffic class) of the data packet in question, 2) the mobility data related to the mobile node, 3) the traffic data related to the multiple bearers, and 4) bearer preference information. The bearer preference information can be obtained from the mobile node, and optionally, from the operators of the home and visited MBN operators. It is possible to implement the above method by means of a single visitor administration system (VAS) which is a logical extension of a foreign agent in the IP mobility scheme. Additionally, a network typi- cally comprises a home administration system (HAS) which is largely equivalent to a home agent in the IP mobility scheme. Later in this application, the single-VAS/HAS architecture will be referred to as 'simplified architecture'.

A specific problem underlying the invention is how to perform a smooth handover between subnetworks of an MBN. A smooth handover is a handover with essentially no packet loss. A subnetwork is a part of a network which is under one foreign agent (FA) In conventional mobile IP, a handover between subnetwork under different foreign agents requires registration with the mobile node's home agent (HA) and foreign agent The (re)regιstratιon of a mobile node means that the mobile node registers with its new foreign agent and its home agent The mobile node must register its new care-of-address (le the address of its new foreign agent) into the mobile node's mobility binding list in its home agent In mobile IP, the re-registration is necessary because only by re-registration can the mobile node's home agent redirect IP traffic to the new foreign agent of the mobile node The re-registration is a time- consuming process during which a fast-moving node may move completely out of the coverage area of the old cell before receiving service from the new cell As a result some packets may be lost A similar problem exists in other wireless IP networks

Brief summary of the invention The object of the invention to solve the specific problem relating to handovers in mobile-IP networks A preferred embodiment of the invention, referred to as 'enhanced architecture', provides a solution for the handover- related problem The enhanced architecture is based on the idea that during handover, an administration system (AS) acts as a foreign agent for all mobile nodes staying in the cells controlled by the AS The AS forwards data packets to correct interface units (by routing or tunnelling, depending on whether there is a physical or logical link, respectively, between the administration system and the interface units) The AS has a mobility management function for supporting mobility between cells controlled by the AS and border cells of a neighbouring AS Handover between cells under one AS is performed locally, and there is no need for authentication and re-registration with the home agent In a handover between two administration systems belonging to one operator, there is a trust relationship, and the new administration system makes use of the authentication performed by the old administration system (or the first one which authenticated the mobile node) By temporarily replacing the conventional re-registration process with this trust relationship, handovers between administration systems can be streamlined, and packet loss is kept to a minimum

According to a further preferred embodiment, the functions of the home administration system (HAS) and the visitor administration system (VAS) are combined into a single functional entity or network element, which will be referred to as a multi-bearer administration system (MBAS) A network may comprise more than one MBAS elements A system according to the enhanced architecture provides better scalability and other benefits, which will be apparent after reading the detailed description In order to save the battery of a portable mobile node, it is preferable that the mobile node only monitors one bearer type (network) at a time For example, the subscriber data related to the mobile node can include a default bearer type, such as GSM or UMTS The mobile node should be paged on this bearer The mobile node can be ordered to monitor the selected bearer type by sending a modified page message which indicates the selected bearer type, channel, possible decryption data, etc Alternatively, such information can be sent in a separate message, such as a short message, USSD, (Unstructured Supplementary Service Data) data call or the like

According to another preferred embodiment of the invention, as long as the mobile node is within a certain coverage area, all IP packets belonging to the same session (or flow if flow labels are used) are routed via the same interface unit For example, if a mobile node is receiving IP packets from a DAB network, via a cell x, all IP packets of the same session should be routed via DAB cell x, unless the mobile node moves out of the coverage area

Brief description of the drawings

The method and the apparatus according to the invention will be described in more detail by means of preferred embodiments with reference to the appended drawing in which Figure 1A shows the overall concept of the simplified architecture according to the invention and the available options for mobile node- terminated (downlink) traffic,

Figure 1 B shows the available options for mobile node-originated (uplink) traffic, Figure 2 shows the major functional blocks of a visitor administration system,

Figures 3A and 3B show the internal structure of the visitor administration system VAS in more detail,

Figure 4 illustrates the cooperation between a traffic management unit TMU and a traffic distribution unit, and Figure 5 shows a preferred version of a routing table with two optional fields,

Figure 6 illustrates the procedures performed by a traffic management unit after receiving an IP packet Figure 7 illustrates the hierarchical structure on an enhanced multi- bearer network MBN by means of an abstract model,

Figures 8A and 8B show the internal structure of the multi-bearer administration system MBAS in more detail,

Figure 9 shows the logical links between the MBAS elements and the network interface units,

Figures 10 and 11 illustrate broadcasting the ID number of the MBAS element via broadcast and non-broadcast networks, respectively

Figure 12 shows a preferred internal structure of an MBAS element,

Figure 13 shows a preferred internal structure of an interface unit, Figure 14 illustrates traffic flow for uplink user traffic,

Figures 15A and 15B illustrate traffic flow for downlink user traffic,

Figure 16 illustrates an intra-MBAS handover between two DVB cells, and

Figures 17A and 17B illustrate an inter-MBAS handover between two DVB cells

Detailed description of the invention

Simplified Architecture

Figure 1A shows a preferred structure of a network arrangement in which the invention can be used A mobile node MN communicates with its correspondent node MCN via a multi-bearer network MBN which offers several alternative bearers for a data packet DP Each data packet comprises a header H and a payload part PL To be precise, a data packet typically has several headers inside each other, because each protocol layer inserts its own header However, each protocol layer only handles each own header and a model with only one network layer header is usually sufficient for describing the invention The header indicates, directly or indirectly, a quality-of-service requirement QoS for the data packet An example of a direct QoS indication is a case where the data packet header includes a parameter which is or which can be directly mapped to a quality-of-service requirement parameter An ex- ample of an indirect QoS indication is a case where the header indicates a PDP (packet data protocol) context, and the PDP context in turn indicates the QoS requirement. It should be understood, that 'quality of service' is a very generic term indicating certain requested or negotiated transmission characteristics, such as bit rate, maximum delay and/or packet loss probability. De- pending on the actual protocol used, quality of service is indicated by or mapped to one of the existing appropriate fields, such as the Traffic Class field of IPv6 or the Type of Service of IPv4. The term 'traffic class' is used to refer collectively to the fields which are used to indicate the quality-of-service requirement. In Figure 1A, it has been assumed that the MBN communicates with the MCN via the Internet. There is preferably a firewall FW at the edge of the MBN. A gateway node GW interfaces the MBN to the Internet. A backbone network BBN combines the different bearer networks BN. It may be the MBN operator's internal network. A physical example of a BBN is a high-speed lo- cal-area network or a wide-area network. A home administration system HAS is largely equivalent to a home agent in the IP mobility scheme (described in the RFC 2002). A visitor administration system VAS is a logical extension of a foreign agent in the IP mobility scheme. The MBN has access to several bearers for conveying the data packet to the mobile node MN. The bearers include a first set of bidirectional bearers. Examples of bidirectional bearers are circuit-switched mobile networks, such as GSM (Global System for Mobile communications), and packet-switched mobile networks, such as GPRS (General Packet Radio Service), and third generation mobile networks, such as UMTS (Universal Mobile Telecommunications Sys- tem), which offer both circuit-switched and packet-switched bearers. For each bidirectional bearer, there is a corresponding interface unit GSM_IU, GPRS U and UMTSJU.

The bearers include a second set of unidirectional bearers. Examples of unidirectional bearers are digital audio broadcast (DAB) and digital video broadcast (DVB). For both DAB and DVB, Figure 1 shows two cells DAB_C1 , DAB_C2; DVB_C1 , DVB_C2, and their corresponding interface units DABJU1 , DABJU2; DVBJU1 , DVBJU2.

The set of unidirectional bearers can also be called broadcast bearers, and the set of bidirectional bearers can also be called non-broadcast bearers. In the system of Figure 1 , there is another difference between the first and second set of bearers in addition to being bidirectional, the bearers of the first set are point-to-point bearers In other words, each connection is customized to one particular recipient In contrast, the bearers of the second set are broadcast or multicast bearers In other words, it is not immediately apparent how a connection can be customized to individual recipients One solution to this problem is encryption of the broadcast/multicast bearers with distribution of decryption keys only to the intended recipients

Within the context of this application, 'uplink' means from the mobile node MN to the correspondent node MCN and 'downlink' means the inverse direction The bold arrows in Figure 1 depict various routing options for data packets in the downlink direction For the span 12 between the MCN and the VAS, data packets are routed directly if the IP address of the mobile node MN (or its subscriber) does not belong to the MBN network If the IP address be- longs to the MBN network, data packets are routed via the home administration system HAS This route is drawn with a thin dotted line 11 For the span 12 between the VAS and the MN, the VAS has several alternative bearers According to the invention, the VAS considers all of the following 1) the qual- ity-of-service requirement (the traffic class) of the data packet in question 2) the mobility data related to the mobile node (i e , which bearers and which interface units can be used to reach the MN), 3) the traffic load/resource availability data related to the multiple bearers, and 4) bearer preference information The optimal bearer selection and the internal structure of the VAS will be described later in more detail Figure 1 B shows the available bearer options for uplink traffic between the MN and the MCN Because the DAB and DVB bearers are unidirectional (downlink only), they are not available for uplink traffic, and the only available bearers 21a to 21c are via the mobile networks GSM, GPRS and UMTS Figure 2 shows the major functional blocks of a visitor administration system VAS The VAS has three main functions or sections 1) a mobility management function MMF, 2) a traffic management function TMF, and 3) a caching proxy CP The mobility management function MMF of the VAS is largely equivalent to a foreign agent in the IP mobility scheme of RFC 2002 The MMF may also participate in authentication and/or charging The functions of the traffic management function TMF include a) collecting traffic information from the various bearer networks (GSM, GPRS, UMTS, DAB, DVB...), b) collecting traffic management-related information from the mobile node MN and its home MBN, c) sending traffic management-related messages to the mobile node MN, d) selecting the bearer network for downlink traffic, and e) forward- ing downlink traffic to the selected bearer network. The extended TCP proposed in reference 1 can be used for this purpose. The function of the caching proxy CP is to maintain frequently-requested content in high-speed memory in order to minimize retrieval of such content over telecommunication lines. The caching proxy CP should have enough intelligence to handle data packets in an application-specific manner, instead of merely caching IP traffic packets.

Figures 3A and 3B show the internal structure of the visitor administration system VAS in more detail from the point of view of traffic management. Figure 3A shows the VAS structure from the point of view of user traffic. IP Routing Software blocks 31 to 33 route data packets to the ap- propriate recipients, based on the packet headers. These blocks also decap- sulate IP packets towards the VAS and pass the decapsulated packets to the upper layers for further processing. Correspondingly, the blocks 31 to 33 also encapsulate packets arriving from the upper layers. In Figures 3A and 3B, the packets from the upper layers are indicated as the traffic flow entering the blocks 31 to 33 from above. The VAS also comprises a traffic distribution unit TDU. The function of the TDU is a) to determine the traffic class of incoming IP packets based on one or more quality-of-service related parameters indicated by the packet header (these parameters may comprise 'Type of Service' for IPv4 and 'Traffic Class' or 'flow label' for IPv6), b) based on the traffic class/QoS requirement, to select an appropriate bearer (radio network) for downlink traffic, and c) to encapsulate each IP packet into an outer IP header towards the selected bearer network and interface unit. The fact that the arrow from the TDU enters IP routing block 32 from below indicates that the TDU has already encapsulated the IP packets, and the block 32 should not perform an- other encapsulation.

Figure 3B shows the VAS structure from the point of view of system traffic, mobility management and traffic management. A mobility management unit MMU performs the functions which are normally performed by a foreign agent in an IP network with mobile IP support, with some enhanced function- ality related to MBN support, such as cell selection and handover control within a broadcast network or between networks. The function of the traffic management unit TMU is a) to collect traffic load information from the various bearer networks BN (DVB, DAB, UMTS, etc ), b) to collect and to update (via the MMU) bearer preference information from the mobile nodes, c) optionally to collect bearer type preference information from the home network of each mobile node, d) to create and update bearer routing information to the TDU, and e) to send traffic administrative messages to the mobile nodes For performing these functions, the traffic management unit TMU receives the following input a) traffic load information from the various bearer networks BN, b) bearer preference information from the mobile nodes, and c) optionally bearer type preference information from the home MBN of each mobile node The traffic distribution unit TDU and the traffic management unit TMU cooperate to perform the traffic management function TMF shown in Figure 2 The cooperation of the TDU and the TMU will be described in more detail in connection with Figure 4 Figure 4 illustrates the cooperation between the traffic management unit TMU and the traffic distribution unit TDU The traffic management unit TMU considers three kinds of information 1) traffic load information 41 from the various bearer networks BN, 2) available interface unit information 42 and 3) preferred bearer type 43 The traffic information 41 from the various bearer networks BN indicates the load (or inversely the available capacity) on the alternative bearer networks This information may be used as a basis for hard decisions (whether or not a requested bearer can be allocated) or for soft decisions (whether or not tariffs should be adjusted to promote the use of lightly loaded bearer networks) The available interface unit information 42 can be generated as follows A preferred interface unit table PIU indicates for each bearer type (DVB, DAB, UMTS, GPRS and GSM) one or more preferred interface units (or to be more precise the IP addresses of the preferred interface units) and their rank of preference The PIU table is mobile-node-specific Each mobile node MN should directly or indirectly indicate its PIU table during registration and in connection with location updates For example, an MN may indicate the PIU directly by forming and sending the PIU table to the VAS The PIU table is not sent to the TMU directly, however Instead, the mobility management unit MMU controls handover within and between the networks Accordingly, the MMU also selects the interface unit for each broadcast network The MMU considers the PIU and the mobility data related to the mobile node (i e , what interface unit can be used to reach the MN) The MMU uses this information to create an available interface unit table AIU which is then applied to the TMU (instead of the PIU table as such) The preferred bearer type information 43 can be organized as a table of a preferred bearer type PBT The PBT table indicates, for each traffic class, several alternative bearer types with decreasing preference The acronym 'WLAN' stands for wireless local-area network, although such a network is not shown separately in Figures 1A and 1 B For example, for traffic class 1 , the most preferred bearer types are WLAN and UMTS, but GPRS and GSM are also possible choices The VAS may obtain a home-MBN-specific PBT table in connection with MN registration, or it may use a generic default PBT table

The traffic management unit TMU considers all the available information 41 through 43, and creates and updates a Multi-Bearer Routing Table MBRT in the traffic distribution unit TDU The MBRT indicates the IP address of the appropriate interface unit for each combination of active user w w+1 , etc and traffic class 1 through 5 (the number 5 being just one example) It should be noted that a user with multiple simultaneous sessions can have an entry for each session in the MBRT table When the traffic distribution unit TDU receives a data packet whose header H indirectly indicates a traffic class (via a QoS-related parameter), the TDU uses the corresponding user ID and the traffic class to retrieve the IP address of the appropriate interface from the Multi-Bearer Routing Table MBRT Next, the TDU encapsulates the data packet DP into another data packet DP' whose header H' indicates the IP address (of the selected interface unit) which was retrieved from the MBRT When the selected interface unit receives the data packet DP' it decapsulates the outer header H' and sends the original data packet DP to the mobile node MN An advantage of an MBRT table substantially as shown in Figure 4 is that it directly indicates, for each data packet, the IP address to which the packet is to be sent In other words, sending an individual data packet involves no decision-making, just a retrieval of an IP address from the MBRT table For IPv6, the traffic class can be mapped to Preference For IPv4, the traffic class can be mapped to Type of Service If the Differentiated Services protocol is used, traffic class can be mapped to bits reserved for future use According to a preferred embodiment of the invention, for IPv6, all packets with identical flow labels are usually mapped identically Let us assume that a user w has three simultaneous applications news, FTP and video on demand The IP packets from the MCN to this user may have a preference/priority value of 1 for news, 4 for FTP and 9 for video. The PIU and PBT tables are as shown in Figure 4 and the MBN uses five traffic classes, and the mapping between the preference value and the traffic class is as follows:

In such a case, the IP packets carrying news belong to traffic class 1 , and they are routed via the router whose IP address is IP-GPRS_IUa. The IP packets carrying FTP belong to traffic class 3, and they are routed via the router whose IP address is IP-DABJUx. The IP packets carrying video belong to traffic class 4, and they are routed via the router whose IP address is IP- DABJUx.

Let us now assume that the user w starts yet another application, such as e-mail having a preference value of 2. In this case, IP packets carrying e-mail belong to traffic class 1 , and they are routed via the router whose IP address is IP-GPRSJUa.

Figure 5 shows yet another preferred feature or addition to the embodiment shown in Figure 4. This preferred feature allows paging the mobile node via a single default bearer and using a single interface unit as long as the mobile node is within its coverage area. The feature is based on the idea that IP packets separated by a time interval exceeding a certain maximum time Tmax are treated by the MBN as belonging to two separate sessions. In this case, each entry in the MBRT table includes not only the IP address of the relevant interface unit but also a busy flag B and a timer field T. The timer field T is compared with the maximum value Tmax, the value of which is optimized by the operator. If the busy flag B is zero, it means that no IP packets used this entry for the past time interval of Tmax. If the busy flag B is set (indicated in Figure 6 with 'B=1'), it means that at least one IP packet used this entry for the past time interval of Tmax. The value of each timer field T is incremented by the TMU in a constant time interval. Each time an IP packet is routed by using a certain entry in the MBRT table, the corresponding timer field T of that entry is reset to zero and the busy flag is set to one Setting the busy flag to '1 ' is preferably performed or triggered by the TDU when it routes an IP packet

Figure 6 shows a way to use the B and T fields shown in Figure 5 In step 61 , the traffic distribution unit TDU examines the header of an incoming IP packet The TDU determines the destination IP address and traffic class (direct or indirect mapping) and retrieves the corresponding entry from the MBRT table In step 62, the TDU checks the busy flag B to see if the selected interface unit IU has been used by this user/session during the last time interval Tmax If not, then in step 63 the TDU begins to buffer incoming IP packets and in step 64 the TDU pages the mobile node More preferably to reduce the computational load of the TDU, the TDU can only trigger a page while the actual page operation is performed by another unit, such as the TMU In step 65 when the page operation is complete and the mobile node responds, the busy flag T is set to one and the timer field T is initialized to zero In step 66, the TDU begins encapsulating each original IP packet with another IP header whose destination IP address is retrieved from the MBRT table Finally, in step 67, the encapsulated IP packets are delivered via the IP routing software to the mobile node

The traffic management unit TMU is responsible for updating the MBRT The MBRT updating should obey the following principles An entry of the MBRT table, or more specifically, the IP address for a certain combination of a user/session and a traffic class, can only be modified under the following circumstances If the busy flag B is nonzero, the IP address can be updated if a) the modification is caused by a handover between cells of a broadcast net- work or between different networks, b) the mobile node moves out of the coverage area of one bearer, or c) the traffic load/resource availability changes On the other hand, if the busy flag B is zero, the IP address can be updated if a) the modification is caused by a handover between cells of a broadcast network, b) the mobile node moves out of the coverage area of one bearer, or c) there is an extraordinary change of traffic condition Interruption of IP traffic flow should be avoided, if possible This is particularly important with IP packets having high QoS requirements Inversely, flows with low QoS requirements should be interrupted first, if interruptions cannot be avoided Obeying these principles allows the use of the same interface unit as long as possible Enhanced Architecture

The embodiment described under 'Simplified architecture' leaves some questions unanswered. Most notably, a single VAS can be a performance bottleneck. Scalability is not achieved by simply installing more VAS elements, because the simplified architecture comprises no mechanisms for inter-VAS handovers.

An essential feature of the enhanced architecture is the ability to support multiple administration systems, such as the MBAS elements. Each MBAS element is responsible for the delivery of IP packets to a group of home users (as a home agent) and a group of visited users (as a foreign agent). For example, an MBAS in Helsinki acts as a home agent for Helsinki-based subscribers. When these users are away from Helsinki, the MBAS forwards their traffic to the relevant foreign network. The same MBAS acts as a foreign agent for users whose home network is elsewhere but who are currently roaming in Helsinki.

Figure 7 illustrates the hierarchical structure of an enhanced multi- bearer network MBN by means of an abstract model. In Figure 7, reference signs AS1 and AS2 denote administration systems which are essentially foreign agents (FA) with an extended mobility support function. In the MBN, the AS can be like the visitor administration system VAS described in connection with the simplified architecture, or an enhanced multi-bearer administration system MBAS. Reference signs AP1 a to AP2b denote access points. In the multi-bearer network MBN, they represent interface units of broadcast networks. Reference signs 71 denote conventional hierarchical connections be- tween administration systems AS and access points AP. These connections are drawn with solid lines. Conventional mobile IP suffers from the drawback that a mobile node MN must register with its home agent before receiving any services if it moves from one access point to another, if the access points are under different foreign agents. This is why the enhanced architecture of the in- vention makes use of connections 72, shown as dotted lines. The connections 72 are used primarily to provide continuous support for a mobile node during an inter-AS handover, for example a handover from a cell 73 under access point AP1 b to a cell 74 under access point AP2a. Without the connections 72, the high-level architecture of Figure 7 closely resembles that of some existing wireless IP networks. Traffic on connections 72 is more restricted than traffic on connections 71 . For instance, the connections 72 are not allowed to be used for establishing new sessions, and the lifetime of a connection is limited to a short period after an inter-AS handover until the mobile node registers with its new foreign agent and updates its mobility binding in its home agent.

Figures 8A and 8B show the internal structure of the multi-bearer administration system MBAS in more detail. In terms of hardware, a typical implementation of the MBAS element resembles a suitably conFigured powerful router. The novel features of this invention can be implemented by software routines. The most notable difference between the MBAS shown in Figures 8A and 8B and the VAS shown in Figures 2, 3A and 3B is the fact that the MBAS is a combination of a VAS and a HAS. It also includes the home agent and foreign agent functions, HA and FA, which are largely equivalent to the corresponding functions within the Mobile-IP scheme. To be more precise, the home agent function in a home MBAS according to the invention corresponds to the home agent of the mobile IP. Correspondingly, the foreign agent function in a visited MBAS according to the invention corresponds to the foreign agent of mobile IP. Reference sign HL points commonly to blocks MMU, HA and FA which constitute the handover logic within the MBAS.

Figure 9 shows the logical links between the MBAS elements and the network interface units. Each MBAS element should be physically or logi- cally attached to only one interface unit of each non-broadcast (bi-directional) bearer network (GSM, GPRS or UMTS). However, an MBAS element can be physically or logically attached to several interface units of each broadcast (unidirectional) bearer network. Figure 9 shows several interface units xxJU, where 'xx' is the name of a bearer network, such as DAB, DVB, GSM, GPRS or UMTS. Each interface unit is responsible for the delivery of data packets to a network selected by the MBAS. Each GSM interface unit GSMJU can be connected to an interworking unit (IWU, not shown separately) in a GSM network. Each GPRS/UMTS interface unit GPRSJU, UMTSJU can be connected to a gateway support node (GGSN, not shown separately) in a GPRS or UMTS network. The embodiments shown in the Figures comprise a separate interface unit (DABJU, DVBJU) for each cell in a broadcast network (DAB and DVB) because these networks do not support IP routing. In contrast, the bidirectional networks (GSM, GPRS and UMTS) do support IP routing, and for each of these networks there is an interface unit which is common to all cells of the network. In other words, each MBAS has one interface unit for each network with IP routing capability and one interface unit for each cell in a network without IP routing capability. Strictly speaking, GSM infrastructure does not support IP routing directly, but a similar function can be achieved by the PPP (point-to-point protocol) between the MBAS and a mobile station. By conveying IP packets on top of the PPP, packets can be delivered to any cell under the MBAS. As shown in Figure 9, an MBAS element MBAS1 is connected to each bi-directional bearer network UMTS, GSM and GPRS via interface units 91 1 , 912 and 913 respectively. In contrast, the embodiment shown in Figure 9 has a separate interface unit for each cell in the unidirectional networks DVB and DAB. In this case, interface units 914 and 915 each serve one DVB cell and interface units 916 and 917 each serve one DAB cell. The invention preferably makes use of concepts 'master MBAS' and 'MBAS-area'. Each DAB or DVB cell is physically or logically connected to its nearest MBAS element. 'Nearest' can be interpreted as being the geographically closest (for example, by means of a look-up table) or as having the smallest number of hops via its interface unit. The nearest MBAS acts as a master MBAS for the cells to which it is the nearest MBAS. For example in Figure 9, MBAS1 is the nearest MBAS for DVB interface units 914 and 915 and DAB interface units 916 and 917. Thus MBAS1 is the master MBAS for DVB cells 924 and 925 and DAB cells 926 and 927. These cells, which are under one master MBAS, form an MBAS support area, or simply 'MBAS area'. It should be noted that an MBAS area does not necessarily have one clearly defined geographical border. Because the sizes of DVB cells and DAB cells can be different, a certain location, such as the location 950, can have MBAS1 as its master MBAS for DAB but MBAS2 as its master MBAS for DVB. In other words, the geographical border of an MBAS area may differ between the bearer networks, and an MBAS supporting five bearer networks (GSM, GPRS, UMTS, DAB and DVB) may have five different MBAS areas.

For each cell, only its master MBAS is allowed to grant a new session to start in it. Other MBAS elements, even if they are physically or logically connected to the cell, can only grant traffic routing via this cell in a handover situation. The resources (total bandwidth, time in use after a handover...) allocated to a non-master MBAS are limited. Most resources of a cell are allocated to its master MBAS.

It is not necessary to connect every cell to several MBAS elements. Only those cells that are located along the border of two MBAS areas should be physically or logically connected to several MBAS elements. Connecting a border cell to more than one MBAS element facilitates a smooth handover between two different MBAS areas

Because GSM, GPRS and UMTS networks have inherent routing and handover capability, it is not necessary to employ the concepts of master MBAS' and 'MBAS area' in these networks, unless the ID of an MBAS is broadcast in these networks In this case, an MBAS area comprises the cells broadcasting its ID An MBAS is a master MBAS to such cells

Each cell in a broadcast network (DAB, DVB) has a unique ID (identifier) number Each DAB or DVB cell broadcasts its own ID number peπ- odically Based on this ID number, the IP address of the corresponding interface unit xx_IU can be determined For example, each MBAS may store a look-up table which maps a cell ID to an IP address of an interface unit When a mobile node registers with an MBAS, the MBAS can send this information to the mobile node The look-up table stored in each MBAS should contain the information of all cells in this MBAS area as well as in the neighbouring MBAS area

Each MBAS element should also broadcast its IP address or ID number If the ID number is broadcast, each MBAS should also have a unique number, based on which the IP address of the MBAS can be determined For example, in each MBN, there can be a look-up table which maps a cell ID to an IP address The element storing the look-up table is called an ID storage device Each MBN should also store a look-up table of other networks whose operators have a roaming agreement with the operator of the home network Only the look-up table of the currently visited (home or foreign) network needs to be stored in the mobile node Upon entering a new MBN a mobile node can request the ID storage device of its home network to send the look-up table of the new MBN The request may contain an unknown MBAS ID that is broadcast in the new MBN The ID storage device of the home network finds the corresponding look-up table and sends it to the mobile node The request is conveyed via the bidirectional network directly (not via the MBN) Optionally, a mobile node can cache several look-up tables of frequently visited MBNs

Figures 10 and 11 illustrate broadcasting the ID number of the MBAS element in broadcast and non-broadcast networks, respectively Because each non-broadcast interface unit (GSMJU, GPRSJU and UMTSJU) is (logically or physically) linked to only one MBAS element, there is no need to broadcast the ID number of those interface units. The IP address of those units can be derived directly from the ID number of the MBAS.

The various network elements will now be described in more detail. The MBAS elements are adapted 1 ) to attract and intercept datagrams that are destined to the home address of any of its registered mobile nodes (ie to act as a home agent, preferably supporting route optimization); 2) to forward traffic to mobile nodes that are in their home networks (via a traffic distribution unit TDU, see Figure 3A) or away from their home networks (to act as a foreign agent.); 3) to select an appropriate bearer type for each session; 4) to as- sist mobile nodes in inter-cell handovers (especially in broadcast networks) and inter-MBAS handovers; and 5) to act as a caching proxy. Figure 12 shows a preferred internal structure of an MBAS. The four leftmost elements, ie the CP, the MMU, the TMU and the TDU have already been described in connection with Figures 2, 3A and 3B. The foreign and home agent functions, FA and HA, are largely equivalent to the corresponding the functions in the known IP mobility scheme.

Figure 13 shows a preferred internal structure of an interface unit xxJU. The interface units have a Protocol Adaptation function PA to encapsulate incoming IP packets into protocols suitable for the radio bearer, for ex- ample to encapsulate IP packets over MPE&section&MPEG2 TS protocols for transferring them via a DVB network. A Traffic Control function TC controls incoming traffic, limits the traffic from each MBAS and discards packets from unidentified sources. A Resource Management function RM monitors, reports on and controls the use of resources allocated to the interface unit. Figures 14, 15A and 15B illustrate traffic flow for user traffic. As stated, each operator may have one or more MBAS elements in a multi-bearer network. Each MBAS is responsible for handling a group of users. Each MBAS broadcasts its ID number in its MBAS area. From the ID number of the MBAS, a mobile node MN is able to determine the IP address of the MBAS. Alterna- tively, it is also possible to broadcast the IP address of the MBAS elements.

After obtaining the IP address of its visited MBAS, a mobile node has to perform registration with its home MBAS as well as the visited MBAS before receiving any multi-bearer services. The registration procedure is basically similar to the one in the mobile IP scheme. A mobile node has to register even if it is in its home network. Because the broadcast cells overlap, there are likely to be locations in which a mobile node can receive different MBAS ID numbers from different cells In this case, a mobile node should select the MBAS whose ID is broadcast in an active cell, or in other words, the broadcast cell which is being or going to be used for transferring the downlink traffic of the mobile node However, in some circumstances, for example during a handover of an ongoing data call, or when a mobile node is moving around a border area the mobile node can be attached to a visited MBAS whose ID is different from the one broadcast in the active cell Figure 14 illustrates traffic flow for uplink user traffic Uplink user traffic is transmitted from the mobile node MN via one or more of the bidirectional networks to the visited MBAS which forwards the traffic via the gateway GW and the Internet to the mobile node's correspondent node MCN

Figure 15A illustrates downlink user traffic flow from the correspon- dent node MCN to the MBAS Downlink traffic is delivered to the visited MBAS directly if the mobile node is under its home MBAS (its home MBAS and visited MBAS are the same), or if route optimization is used This case is shown with a solid arrow 151 Downlink traffic is delivered to the visited MBAS via the mobile node's home MBAS if the mobile node is away from its home network and route optimization is not used This case is shown with a dotted arrow 152

Figure 15B illustrates downlink user traffic flow from the MBAS to the mobile node MN Downlink traffic is delivered from the visited MBAS via the selected bearer network BN The selection has been described in connec- tion with the simplified architecture The traffic management unit of the visited MBAS decides to which bearer network the traffic should be directed When a mobile node is away from its home network (out of the administrative range of its home MBAS), the home MBAS will act as the home agent and the visited MBAS acts as the foreign agent The home MBAS tunnels the downlink traffic to the mobile node's visited MBAS Route optimization can be used in this case

When a mobile node is in its home network, its home MBAS receives IP traffic to the mobile node from the backbone network and forwards the traffic to the mobile node via a traffic distribution unit TDU in the home MBAS In this respect, the home agent function of an MBAS differs from a conventional home agent in the mobile IP scheme, which does not need to forward IP packets to a mobile node when the mobile node is in its home network. In most networks, when a mobile node is in its home network, it is on the same physical link with its home agent. The mobile node can directly receive all the packets addressed to it, and forwarding is not needed. But in some networks there is no direct physical link between a mobile node and the home agent, and the home agent must forward packets to the mobile node via a tunnel.

Mobility support in a multi-bearer network

In a bidirectional (non-broadcast) bearer network, a multi-bearer administration system MBAS can establish virtual links with all the cells via a corresponding interface unit IU. An MBAS can also establish virtual links with the broadcast cells within its MBAS area, and with their neighbouring cells.

Let us now return briefly to Figures 10 and 11. Figure 10 illustrates broadcasting the ID number of the MBAS elements via a broadcast network (DAB or DVB). DVB cells 101 , 102 and DAB cells 103, 104 broadcast the ID number of the MBAS element MBAS1 , while DVB cells 105, 106 and DAB cells 107, 108 broadcast the ID number of the MBAS element MBAS2. Figure 11 illustrates broadcasting the ID number of the MBAS elements via a non- broadcast (bidirectional) network (GSM, GPRS or UMTS). UMTS cells 111 , GSM cells 112 and GPRS cells 113 broadcast the ID number of the MBAS element MBAS1 , while UMTS cells 114, GSM cells 115 and GPRS cells 116 broadcast the ID number of the MBAS element MBAS2.

Different handover types

A mobile node MN may face four different handover situations. In the first handover type, the MN is moving from one cell to another in a non- broadcast network, such as GPRS. This handover is supported by the non- broadcast network in question. The MBN has to take action only if the ID of the serving MBAS is broadcast over a non-broadcast network and the MN moves between cells broadcasting the ID of different MBAS elements. If the MN moves between different MBAS areas, it should register with its home MBAS and the new visited MBAS after completing the inter-cell handover.

In the second handover type, the MN is moving from one cell to another in a broadcast network (DAB or DVB) such that both cells belong to the same network (such as DAB) and to the same MBAS area. In this case, the mobility management unit MMU of a visited MBAS and the corresponding enti- ties of the mobile node are responsible for handling micro-mobility A general procedure for such a handover is as follows

1 The mobile node detects signal deterioration

2 The mobile node measures the signal strength in the neighbour- ing cells, makes a list of recommended cells, and sends the measurement data (signal strength and cell ID) as well as the recommendation list to the mobility management unit MMU in the visited MBAS

3 The mobility management unit MMU of the visited MBAS determines the available resources and instructs the mobile node to perform an in- tra-system or inter-system handover (or roaming)

4 After the MBAS has sent a handover command to the MN, the MBAS may optionally buffer incoming data to the MN until the MN acknowledges the attachment to the new cell As the inter-cell handover takes place locally, the time from the handover command to the acknowledgement is short, and a reasonably small buffer is sufficient

5 When the mobile node is attached to a new cell, the Mobility management unit MMU directs the traffic distribution unit TDU to route the traffic to the new cell From now on, the traffic is routed to the new cell

The term 'roaming' in general means simply moving from one net- work to another The term 'handover means handing over an ongoing call

(which can be a voice call, a data call a multimedia call or the like) Roaming support can be achieved with relative ease because there is no ongoing traffic

Figure 16 illustrates a handover between two DVB cells belonging to the same MBAS area The solid single-headed arrows denote the connec- tion before the handover, and the dashed single-headed arrows denote the connection after the handover The dotted double-headed arrows denote signalling connections by which the mobile node reports the signal strengths of the cells it can receive

In the third handover type, the MN is moving from one cell to an- other within one MBAS area but in different bearer networks For example, the MN may move from a DAB cell to a DVB cell This type of handover takes place when the MN is moving out of the coverage range of one network or when the neighbouring cell that belongs to the same network is congested This type of handover follows the same procedure as the second type of han- dover In the fourth handover type, the MN is moving from one MBAS area to another In other words, the MN moves between cells having different master MBAS elements Normally, the master MBAS of the MN s active cell should act as the MN's visited MBAS because it is the MBAS having the shortest distance to the interface unit of the active cell In this context, 'distance' may mean physical distance or a number of hops, depending on the implementation To achieve a smooth handover between MBAS elements the MN does not have to change its visited MBAS during an inter-MBAS-area handover Instead, it should first perform an inter-cell handover aided by its old MBAS (the master MBAS of the previous cell) When the inter-cell handover has been performed successfully, the MN can perform normal Mobile IP registration with the new visited MBAS (the MBAS of the MN's new cell) and

Such a two-phase handover has two major benefits The handover is fast and data loss is minimized The inter-cell handover according to this preferred embodiment of the invention dispenses with registration and authentication with a foreign agent and a home agent Such operations can be very time-consuming, especially when the MN's home MBAS is in another MBN, located far away Another feature improving the speed of the handover is the fact that during the mobile node's binding update the Mobile IP registration process is carried out in parallel with user data transfer In other words, the MN does not have to stop data reception during the registration process The reduced duration of the handover and the parallel registration and data transfer processes eliminate or at least significantly reduce data loss during an in- ter-AS handover Further, when the MN updates its mobility binding its user traffic is delivered via the same broadcast cell, and the MN does not miss any packets before or after the mobility binding update

A failure to follow the above-specified two-phase handover procedure, ie an attempt to perform an inter-MBAS handover before starting to re- ceive data from the new cell, may result in service degradation because of the time involved in the inter-MBAS handover An example of such a handover is a handover between cells belonging to different MMAs (Mobility Management Agents) in the MEMO concept

Figures 17A and 17B further illustrate the two-phase handover be- tween two DVB cells Figure 17A illustrates a first phase in which the mobile node MN performs a normal inter-cell handover During the first phase, the old visited MBAS, MBAS2, is still used for serving the mobile node. The mobility management unit inside the old MBAS2 instructs the mobile node to perform an inter-cell handover. Figure 17B illustrates a second phase in which the mobile node performs a mobility binding update by following normal mobile-IP procedures. Because downlink traffic is always forwarded via the same cell during an inter-MBAS handover, the handover will not cause packet loss. In more detail, an inter-MBAS handover in a situation as shown in Figures 17A and 17B comprises the following steps.

1. A mobile node MN, which is registered with MBAS2, measures the signal strength (or some other criterion of signal quality, such as bit error ratio) of DVB cells 171 and 172. The former broadcasts the ID of MBAS2 and the latter broadcasts the ID of MBAS3. MBAS1 is the mobile node's home MBAS. The mobile node detects that the signal quality of DVB cell 172 is so much better that a handover is justified. The signal quality measurements and a handover request are sent to MBAS2.

2. The mobility management unit MMU in MBAS2 decides to hand over the mobile node's traffic to DVB cell 172. The mobility management unit MMU in MBAS2 assists the mobile node MN in performing an inter-cell handover to DVB cell 172. After the inter-cell handover, the MN begins to receive data from cell 172.

3. The mobile node MN detects that cell 172 broadcasts the ID of MBAS3, ie the ID of a different MBAS from the one the MN is registered with.

4. The mobile node measures the signal quality of the cells broadcasting the ID of MBAS2. and other neighbouring cells. If the signal quality of cell 172 is much better than the quality of all neighbouring cells, or if the cells which broadcast the ID of MBAS2 are too weak to receive, the MN begins to perform an inter-MBAS handover.

5. The mobile node sends a registration request to MBAS1 (its home MBAS) and to MBAS3 (a visited MBAS). The registration request per se can be implemented by conventional mobile-IP procedures. In the registration request, the IP address of MBAS3 is provided as the mobile node's care-of- address. During the registration process, the mobile node keeps receiving traffic from cell 172 (via MBAS2).

6. MBAS1 (the mobile node's home MBAS) performs a binding up- date. In other words, it registers MBAS3 as the mobile node's foreign agent.

Before the binding update, MBAS2 acts as the mobile node's visited MBAS. After the binding update, MBAS3 acts as the mobile node's visited MBAS, and all user traffic to the MN is routed via MBAS3. From this point on, the mobility management unit of MBAS3 is responsible for handling the mobile node MN. 7. Optionally, the mobile node can send a de-registration message to MBAS2, informing it about the successful handover. Alternatively, each MBAS may employ a mobile-node-specific timer. If the MBAS receives nothing from a mobile node, the MBAS can assume that the mobile node has been switched off or it has moved elsewhere.

An essential feature of the above-described inter-MBAS handover is that the mobile node receives service from a new MBAS during the entire handover process. This is in stark contrast to the scheme outlined in reference 1 (the MEMO project), in which a mobile node must register with a PSTS (personal services transport server) before receiving service from a cell under that element. In other words, a system according to reference 1 is not able to hand over an ongoing call, at least not without packet loss.

To avoid unnecessary back-and-forth mobility binding updates for mobile nodes wandering around a border area, some kind of hysteresis can be employed. For example, after a handover between cells in different MBAS areas, a mobile node may wait some time before it begins a mobility binding up- date. During the waiting time, the MN may monitor the signal strength of its old cell and new cell to determine whether it is really moving away from its old cell. If a mobile node is staying in the border area between two MBAS elements for an extended period of time, it can request the old visited MBAS to support it without re-registration with its new visited MBAS. A mobile node according to the enhanced architecture of the invention should be aware of the handover logic. When the mobile node is handed over to a cell which belongs to a different administration system (PSTS in the MEMO concept, MBAS in the present invention) than the one which served the mobile node's old cell, the mobile node should start performing mobile-IP registration and a binding update within a certain time limit. If the mobile node is uncertain whether it will soon return to the area of the old administration system, it should send the administration system a request for extending support time.

The enhanced architecture has been described in connection with a single network operator. On the basis of the description, a skilled reader can implement a multi-bearer network which can be at least partially shared by multiple network operators In this case the operators can share at least some bearer networks and/or network elements, most notably the interface units IU, while each operator has its own MBAS element

Reference 1 MEMO network documentation (collectively referred to as the

"MEMO concept"), available at http : / / memo , lboro . ac . U K

Claims

1. A network element (MBAS) for supporting mobility of a mobile node (MN) in a system (MBN) which comprises or is connected to several different bearer networks (BN), the bearer networks comprising at least one uni- directional network (DAB, DVB) and at least one bidirectional network (GSM. GPRS, UMTS); the network element (MBAS) being c h a ra cte ri z e d by: at least one support area, each support area comprising one or more cells in said bearer networks (BN); a home agent function (HA) for acting as a home agent to mobile nodes at home and a foreign agent function (FA) for acting as a foreign agent to visiting mobile nodes, the home agent and foreign agent functions being substantially compatible with mobile-IP protocol; and a handover logic (HL) for handing over a mobile node to a neigh- bouring network element, the handover logic being adapted to provide continuous service for a mobile node after it has moved to the support area of the neighbouring network element and before it has re-registered with its home agent.

2. A network element (MBAS) for supporting mobility of a mobile node (MN) in a system (MBN) which comprises or is connected to several different bearer networks (BN), the bearer networks comprising at least one unidirectional network (DAB, DVB) and at least one bidirectional network (GSM, GPRS, UMTS); the network element being c h a ra cte r i ze d by at least one support area, each support area comprising one or more cells in said bearer networks (BN); first connections (71) to the cells in its own support area and second connections (72) to at least a subset of cells in the support area of each neighbouring network element, the second connections having one or more limitations compared to the first connections; and handover logic (HL) for handing over an ongoing call of the mobile node to a neighbouring network element by using the second connections (72).

3. A network element according to claim 1 , c h a ra ct e r i z e d by first connections (71) to the cells in its own support area and second connec- tions (72) to at least a subset of cells in the support area of each neighbouring network element, the second connections having one or more limitations compared to the first connections

4 A network element according to claim 2 or 3, characterized in that said second connections (72) are limited in time

5 A network element according to claim 4 characterized in that said second connections (72) are limited to a predetermined time after a handover to a neighbouring network element

6 A network element according to any one of claims 2 to 4, cha- r a c t e r i z e d in that said second connections (72) are limited by the fact that no new sessions are granted via them

7 A network element according to any one of the preceding claims, characterized in that the subset of cells substantially consists of one or a few cells along the border of the support area of the network element in ques- tion and its neighbour

8 A network element according to any one of the preceding claims, characterized by a traffic management function (TMF) for selecting an optimal bearer network (BN) for a data packet (DP) between the MBN and the mobile node (MN) based on the quality-of-service requirement (QoS) of the data packet (DP) in question, traffic load data (41) related to the multiple bearers, interface unit preference information (PIU, 42), and bearer type preference information (PBT, 43)

9 A telecommunications system for conveying mobile-IP traffic to a mobile node (MN), wherein the system comprises or is connected to several different cellular bearer networks (BN), the bearer networks comprising at least one unidirectional network (DAB, DVB) and at least one bidirectional network (GSM, GPRS, UMTS), characterized by a network element (MBAS) which is associated with at least one support area, each of which comprises one or more cells in the bearer networks (BN); the network element (MBAS) having first connections (71) to the cells in its own support area and second connections (72) to at least a subset of cells in the support area of each neighbouring network element, the second connections (72) having one or more limitations compared to the first connections (71).

10. A handover method for handing over an ongoing call of a mobile node (MN) in a system (MBN) which comprises or is connected to several different bearer networks (BN), the bearer networks comprising at least one unidirectional network (DAB, DVB) and at least one bidirectional network (GSM, GPRS, UMTS); c h a ra cte rized by controlling the handover method at least in part by a network element (MBAS) which is associated with at least one support area, each of which comprises one or more cells in the bearer networks (BN); providing the network element (MBAS) with first connections (71) to the cells in its own support area and second connections (72) to at least a subset of cells in the support area of each neighbouring network element; associating the mobile node with a home network element; handing over the mobile node (MS) to a neighbouring cell; and using the second connections (72) to provide continuous service for the mobile node after it has moved to the support area of a new network ele- ment and before it has re-registered with its home network element.

11. A handover method for handing over an ongoing call of a mobile node (MN) from a first subnetwork to second subnetwork, each subnetwork comprising one or more access points (AP) and a group of cells under one foreign agent function (FA, MBAS); the handover method comprising conveying said call between the foreign agent function (FA, MBAS) and an access point (AP) via at least one first connection (71); c h a ra cte ri z ed by a first phase in which the call is handed over from a cell (73, 171) in the first subnetwork to a cell (74, 172) in the second subnetwork; a second phase in which the call is handed over from a foreign agent function (FA, MBAS2) in the in the first subnetwork to a foreign agent function (FA, MBAS3) in the in the second subnetwork; and using at least one second connection (72) for conveying said call between the foreign agent function (FA, MBAS2) in the in the first subnetwork and the cell (74, 172) in the second subnetwork, the at least one second connection (72) being more limited than the first connection (71 ).

12. A hierarchical wireless cellular IP network for handling a call to/from a mobile node (MN), the network comprising: a home agent function (HA) for registering the mobile node; several foreign agent functions (FA, AS1 , AS2, MBAS); one or more subnetworks (SNW) under each foreign agent function, each subnetwork comprising at least one cell and having at least one access point (AP, AP1 a ... AP2b); and at least one first connection (71) between each foreign agent function and each access point under it; c h a ra c t e r i z e d by at least one second connection (72) for temporary call support between a foreign agent function (AS1 ) of one subnetwork and an access point (AP2a) of a neighbouring subnetwork, the at least one second connection (72) being more limited than the first connection (71); whereby the network is capable of smooth handover of the call between subnetworks until the mobile node re-registers with the home agent function (HA).

13. A mobile node (MN), operable to hand over an ongoing call from a first subnetwork to second subnetwork, each subnetwork comprising one or more access points (AP) and a group of cells under one foreign agent function (FA, MBAS); c h a ra ct e r i z e d by being adapted to: hand over a call to/from the mobile node in two phases, namely a first phase for handing over the call from a cell (73, 171 ) in the first subnetwork to a cell (74, 172) in the second subnetwork, and a second phase for handing over the call from a foreign agent function (FA, MBAS2) in the in the first subnetwork to a foreign agent function (FA, MBAS3) in the in the second subnet- work; perform a re-registration with its home agent function (HA) within a predetermined time limit from the second phase, and to: communicate with the foreign agent function (FA, MBAS2) in the in the first subnetwork until it the re-registration with its home agent function is completed.

14. A mobile node according to claim 13, c h a ra cte r i zed by being adapted to send the foreign agent function (FA, MBAS2) in the first subnetwork a request for extending communication time if the mobile node remains in a border area between the subnetworks for a time likely to exceed the predetermined time limit.