TITLE

METHOD OF ASSIGNING A UNIQUE IDENTIFIER TO A MOBILE STATION

IN A COMMUNICATIONS NETWORK

FIELD OF THE INVENTION The invention generally relates to a method of assigning a unique identifier to a mobile station in a communications network. More particularly, the invention relates to guaranteeing uniqueness and successful relocation of a mo ^¬ bile station from one 3G home NodeB (HNB) to another.

BACKGROUND OF THE INVENTION

The number of Home NodeBs (HNBs) connected to one single Home NodeB Gateway (HNB-GW) can be very high (of the order of thousands) and, especially in an enterprise scenario, it is expected that mobile stations or user equipment (UEs) often need to be relocated from one HNB to another. Relocations can occur both on dedicated and on common ra ^¬ dio resources. When on common radio resources, the rele ^¬ vant UE context is identified by the UTRAN-Radio Network Temporary Identifier (U-RNTI) field sent by the UE to the target HNB via the RRC Cell Update message. A U-RNTI is assigned to the UE by the HNB during the RRC connection establishment procedure so that each UE having an RRC con ^¬ nection in that particular HNB gets a different U-RNTI value. In order to retrieve the relevant UE context during relocation from one HNB to another, it is required that the U-RNTI is also unique within all HNBs controlled by a particular HNB-GW.

According to the 3GPP standard (see TS 25.331), a U-RNTI is a 32 bit field composed by the Radio Network Controller

- Identity (RNC-ID) (or, in the case of a home NodeB net ^¬ work, a HNB-ID) as most significant bits (this can be ei ^¬ ther 12 or 16, for extended identity); and by the Serving Radio Network Controller - Identifier (S-RNTI) for the re- maining bits (20 or 16, respectively) .

While the HNB Identity is fixed for all UEs, the S-RNTI is randomly assigned by the HNB in order to guarantee its uniqueness to the served UEs.

HNBs under the same HNB-GW usually get the same identity; i.e., the same HNB-ID, which is actually the identity of the controlling HNB-GW. This implies that, to guarantee the uniqueness of the U-RNTI within the HNB-GW, S-RNTI al- location should be coordinated among the connected HNBs.

One possibility would be to statically partition the U- RNTI space among the HNBs during, for example, a HNB configuration phase. Yet, due to the limited number of bits composing this field, and the huge number of HNBs which may connect to one HNB-GW, there is a risk of limiting the UE accessibility to one HNB, even though there would be U- RNTI codes left unused in other HNBs. It is believed that a dynamic approach should be followed, with U-RNTI assignment coordinated by the HNB-GW. Two alternative methods for coordinating the U-RNTI as ^¬ signment to the UEs in the HNB-GW using a dynamic approach have been proposed. The first method proposes that the HNB assigns the U-RNTI and the HNB-GW checks whether there is U-RNTI collision with other HNBs . If there is collision, the HNB-GW provides an updated U-RNTI value to the HNB via a new HNBAP procedure, named HNBAP UTRAN Information, on the Iuh in- terface, which in turns triggers the RRC UTRAN Mobility

Information procedure with on air. A disadvantage of this solution is that it requires a new HNBAP procedure. Con ^¬ sidering the very large number of HNBs connected to the HNB-GW, this may increase the signaling load at the HNB-GW quite heavily. In addition, nesting the RRC UTRAN mobility Information procedure within the HNBAP one can introduce new error conditions that need to be defined and which may not be simple to resolve (for example in case the procedure on air fails for any reason) .

The second method proposes that the HNB assigns the U-RNTI and the HNB-GW checks whether there is collision with other HNBs. If there is collision, the HNB-GW will disconnect the RUA Connection for cause "U-RNTI collision". This triggers the RRC UTRAN Mobility Information procedure on air with new U-RNTI assigned to the UE and, on the Iuh interface, repetition of the RUA Connect message with the new U-RNTI. The main disadvantage of this solution is that it suffers from possible back-and-forth signaling be- tween the HNB and HNB-GW for U-RNTI conflict resolution

(due to separate locations for detection and realloca ^¬ tion) . It may also generate a huge number of RUA Discon ^¬ nect messages with consequent overload of the Iuh inter ^¬ face . Another problem with relocation of UEs from one HNB to another is that such movements are made visible to the CN and, as such, dramatically increase the signalling between the core and the HNB-GW. This means that the time for re ^¬ location is likely to be quite long and it introduces un ^¬ wanted delays.

Furthermore, it is possible that in later releases of the 3GPP standard (e.g. Release 10) a direct interface among

HNBs will be introduced. This would allow even faster com ^¬ munication between two HNBs, as well as fast exchange of local information (e.g. load situation or neighbourhood) which can improve the self configuration of this system.

However, when acting as the core network, the HNB-GW needs to know a lot of information about the context to relocate which is normally known only at the core and at the source HNB, including the radio access bearer (RAB) Identity; data volume report; user plane mode; PDP type; alternative

RAB parameters, and Iu user plane support mode. For each relocated UE context the HNB-GW also needs to know integ ^¬ rity protection and encryption information, UE aggregate maximum bit rate, etc.

Considering the very large number of HNBs connected to one HNB-GW multiplied by the number of calls handled by each HNB, it appears that it is not feasible for the HNB-GW to store all the information above for each established con- text.

A solution to this problem could be either to transfer such information from the source to the target HNB without HNB-GW involvement or providing this information to the HNB-GW only at the point in time when it is needed.

One way of transferring to the HNB-GW the agreed RFCIs is that the source HNB transfers the agreed RFCIs to the tar ^¬ get HNB via a new RUA message also containing the RANAP RELOCATION REQUIRED message. The HNB-GW then adds in the new RUA message to the target HNB, besides the RANAP

RELOCATION REQUEST message, as well as the agreed RFCIs from the source HNB.

This solution allows transfer of information from the source to the target HNB transparently for the HNB-GW. However, it does not solve the problem of how to transfer the other information (e.g. RAB related), which is also needed. Furthermore, it still requires that the HNB-GW generates RANAP messages as per the core.

So far, the only way defined by the 3GPP standard for han- dling a relocation is via 3G standard RANAP messages. The main disadvantage of such procedure is that the HNB-GW needs to act like a core, having to generate its own RANAP messages. The HNB-GW needs to store all UE and RAB con ^¬ text related information, and then transfer such informa- tion to the target HNB. Furthermore, for CS RABs in user- plane support mode, the HNB-GW should either terminate the user-plane or somehow deliver to the target HNB the RFCIs agreed between the source HNB and the core. Still fur ^¬ ther, the number of messages exchanged within the HNB RAN doubles if the UE context to relocate has RABs active in both core network domains .

There is a need for a method of handling UE relocations uniquely between HNBs under the same HNB-GW locally within the HNB-RAN, thus reducing the CN involvement as well as the needed relocation time, with limited complexity for involved HNB RAN network entities.

SUMMARY OF THE INVENTION

Accordingly, the invention provides a method of assigning a unique identifier to a mobile station in a communica ^¬ tions network. A temporary identifier is generated for the mobile station in a source network node upon the mo ^¬ bile station accessing the network via the source network node. The temporary identifier is passed to a control node and looked up in a database at the control node. If the temporary identifier is not contained in the database, it is added to the database as a unique identifier. How ^¬ ever, if the temporary identifier is already contained in the database, a new unique identifier is generated by the control node. The new unique identifier is passed from the control node to the source network node and the source network node updates the new unique identifier to the mo ^¬ bile station as the mobile station identifier if the new unique identifier has a different value to the temporary identifier.

In this way, no static U-RNTI code space sharing among network nodes (HNBs) controlled by the same control node (HNB-GW) is required in order to ensure uniqueness of mo- bile stations accessing the network, which provides the advantage that no code space is wasted. Furthermore, the invention provides that there is no need for new proce ^¬ dures to be introduced at the Iuh interface between the HNBs and HNB-GW. Existing procedures can be used, such as the HNBAP mobile station registration procedure, for adding the new U-RNTI parameter to the exchanged messages.

The step of updating the unique identifier to the mobile station can be performed by using a next radio resource reconfiguration message towards the mobile station from the source network node. This provides the advantage that the HNB does not need to start with any mobile sta ^¬ tion-specific procedure, such as, for example, the RRC UTRAN Mobility Information procedure. New U-RNTI mobile station temporary identifiers can be sent in messages used for RRC Reconfiguration when needed.

A mobile station configuration update message can be sent from the control node to the source network node, which may contain parameters related to that mobile station con ^¬ text. The message for updating the mobile configuration may contain a new value of the mobile station unique iden ^¬ tifier .

If the source network node determines that a handover to a target node is required for an accessing mobile station, the target node can be determined by the source node from the accessing mobile station unique identifier and the source node can then forward that mobile station unique identifier to the target node. This provides the advan ^¬ tage that two HNBs may communicate directly with each other over a HNB to HNB interface so that relocation of a mobile station from one HNB to another may take place without the involvement of the HNB-GW. Therefore the com ^¬ putational load on the HNB-GW can be reduced, which re ^¬ duces the relocation time. The target node can identify the so-far stored mobile sta ^¬ tion context from the mobile station unique identifier re ^¬ ceived from the source network node and can then send that mobile station context information to the source node.

Alternatively, the mobile station may request access to a target network node by providing its mobile station unique identifier to the target network node. The target network node then requests information (for example context infor ^¬ mation) about the mobile station from the control node, based on the provided mobile station unique identifier. The control node can then determine the source network node which stores that mobile station context based on the mobile station unique identifier and can trigger the source network node to forward mobile station-related in ^¬ formation to the target node.

In this way, mobile station relocations can be handled from one HNB to another HNB, where both HNBs are controlled by the same HNB-GW, locally within the HNB-RA . Therefore, the core network involvement in mobile station relocation is reduced, which results in a reduced reloca ^¬ tion time with limited complexity for the network entities of the HNB-RAN. This embodiment may be used when source and target HNBs cannot communicate over a common interface or in a situation where no such interface exists.

Preferably, forwarding mobile station-related information includes sending a relocation request message from the source network node to the target network node. The relo ^¬ cation request message can be sent via the control node and, in this case, may contain a transparent part. This means that the request is not to be processed by nodes in ^¬ termediate the source network node and the target network node. Alternatively, the relocation request message can be sent directly from the source network node to the tar ^¬ get network node. The target network node may send an ac ^¬ knowledgement to the source network node upon reception of the information (for example context information) about the mobile station.

If the radio access bearer (RAB) is a PS RAB, a relocation commit message may be sent from the source network node to the target network node. The relocation commit message can be sent via the control node, in which case the mes ^¬ sage may include a transparent part so that it cannot be processed by nodes intermediate the source network node and the target network node.

In one embodiment of the invention, the mobile station context is swapped from the source network node to the target network node if a relocation complete message is received at the control node from the target network node.

The invention also provides a method of assigning a unique identifier to a mobile station in a communications net ^¬ work. A unique mobile station identifier is passed to a source network node by a control node. The unique identi- fier is assigned to a first mobile station to access the network via the source network node after the unique iden ^¬ tifier has been passed to the source network node by the control node. This first mobile station to access the network is then registered at the control node by the ac- cessed source nod. The control node returns another unique mobile station ID to the source network node for a second mobile station to access the network via that source network node immediately following the first mobile station . The invention further provides a method of exchanging data in a communications network, which includes creating a communications tunnel between a first network node and a second network node across a physical interface with a third network node. Data is sent between the first net ^¬ work node and the second network node through the communications tunnel, such that the data exchanged within the communication tunnel is fully transparent to the third network node. This can be achieved by sending messages between the first and second network node that include a transparent part or "transparent container", such that the messages cannot be looked at or processed by the third network node.

The invention further provides a network node for a communications network. The network node includes an identi ^¬ fier generator for generating a temporary identifier for a mobile station accessing the network via that network node. A transmitter is provided for passing the temporary identifier to a control node and updating the temporary identifier to the mobile station as a mobile station identifier. A receiver receives a new generated unique iden ^¬ tifier as the mobile station identifier if the temporary identifier is already stored in a network database. The transmitter is further adapted to pass the new unique identifier to the mobile station if the new unique identi ^¬ fier has a different value to the temporary identifier. The network node can be a source network node and advanta ^¬ geously includes means for determining if a handover to a target network node is required, and means for determining the target network node. The transmitter of the source network node may be adapted to forward information about the mobile station to the target network node.

The invention additionally provides a control node for a communications network. The control node includes a re ^¬ ceiver for receiving a temporary identifier of a mobile station accessing the network via a source network node. A database is provided for storing mobile station identi ^¬ fiers. A comparator is configured to compare the tempo- rary mobile station identifier with the database of mobile station identifiers. An identifier generator is provided for generating a new unique mobile station identifier if the temporary identifier is already stored in the data ^¬ base, and a transmitter is adapted to pass the new unique mobile station identifier to the network node.

Preferably, the control node further includes means for determining a source network node based on the unique mo ^¬ bile station identifier and means for triggering the source network node to forward mobile station-related in ^¬ formation to a target node if a request for information about the mobile station is received from the target node at the receiver. Additionally, a communications network is provided by the invention. The network first network node and a second network node for providing access to the network for a mobile station. The first and second network nodes are cou ^¬ pled by a communication tunnel across a physical interface with a third network node. The communication tunnel is configured such that the data exchanged between the first and second network nodes within the communication tunnel is fully transparent to the third network node. The invention will now be described, by way of example only, with reference to specific embodiments, and to the accompanying drawings, in which:

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a simplified schematic block diagram of a com munications network in which a method according to the in vention may be implemented;

Figure 2 is a message flow diagram illustrating a method according to an embodiment of the invention; Figure 3 is a message flow diagram illustrating a method according to an embodiment of the invention;

Figure 4 is a message flow diagram illustrating a method according to an embodiment of the invention;

Figure 5 is a message flow diagram illustrating a method according to an embodiment of the invention; and

Figure 6 is a message flow diagram illustrating a method according to an embodiment of the invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Figure 1 shows a wireless communications network, which includes a home NodeB radio access network HNB-RAN coupl to a core network CN. Although the following examples have been described with reference to a HNB-RAN network, the invention could also be applied in any other similar wireless network.

The HNB-RAN includes two home NodeBs as network nodes for providing access to the HNB-RAN network for mobile stations UE1 and UE2. The home NodeBs are designated as a source home NodeB SHNB and a target home NodeB THNB and are structurally the same, including a transmitter T, a receiver R and a database DB . The home NodeBs SHNB and THNB are able to generate temporary identifier values (U-

RNTIs) for the mobile stations UE1, UE2. The SHNB and THNB can communicate over a direct physical interface Id or via their control node, which is a home NodeB gateway HNB-GW. The mobile station UE1, UE2 accesses the HNB-RAN network via one home NodeB, for example the source NodeB

SHNB, but may be relocated from the SHNB to the THNB if needed .

The home NodeBs SHNB and THNB are coupled to the home NodeB gateway HNB-GW over an interface Iuh. The HNB-GW acts as a control node or gateway node for controlling the home NodeBs SHNB, THNB and coupling them to the core net ^¬ work CN. Of course, in reality, many home NodeBs (of the order of thousands) would be controlled by the HNB-GW but only two are shown here for the sake of clarity.

The HNB-GW includes a transmitter T and a receiver R, which can receive a temporary unique identifier (U-RNTI) for the mobile station UE1, UE2 accessing the network. A database DB is included for storing mobile station identi ^¬ fiers and other mobile-station related information, such as UE context information. Figure 2 shows a message flow diagram illustrating a method according to a first embodiment of the invention for assigning a unique identifier value to the mobile sta ^¬ tion UE1 and/or UE2.

In step 1, the mobile station UE1, UE2 requests to connect to the network HNB-RAN by sending an RRC Connection Request message to the source HNB SHNB. Before connecting to the HNB RAN via the source home NodeB SHNB, each mobile station UE1, UE2 needs to be registered. This is achieved via the HNBAP UE Registration procedure between the HNB-GW and the SHNB, during which the control node HNB-GW assigns a context identity to the mobile station UE1, UE2 (a UE Context ID) which is kept at least for all the lifetime of the RRC connection in the source home NodeB SHNB and in the HNB-GW.

During the registration procedure of the mobile station UE1, UE2, the HNB-GW also assigns a U-RNTI value to the mobile station UE1, UE2. If this value is different from the one already assigned by the SHNB during the RRC Con ^¬ nection Setup procedure, the SHNB stores this value until the next opportunity to reconfigure the UE Radio Bearer.

When reconfiguring the mobile station radio bearer for the mobile station UE1, UE2 (e.g. via the RRC Radio Bearer setup; the RRC Radio Bearer Reconfiguration or the RRC Transport Channel Reconfiguration; or the RRC Physical Channel Reconfiguration procedure) the SHNB also reconfigures the U-RNTI to the value received from the HNB-GW. Alternatively, the SHNB can trigger the RRC UTRAN Mobility Information procedure to immediately update the UE U-RNTI for the mobile station UE1, UE2. The HNB-GW can send a new HNBAP UE Register Update message when it is required to update any UE context related pa ^¬ rameter for the mobile station UE1, UE2 such as, for example, the U-RNTI.

In step 2, in the RRC Connection Setup message, the SHNB assigns the incoming mobile station UE1, UE2 with a new U- RNTI, "U-RNTIx" , if the mobile station UE1, UE2 is an unknown mobile station. Otherwise, if the mobile station UE1, UE2 is already known by the SHNB; i.e. if the mobile station UE1, UE2 is already registered with the HNB RAN and has been assigned a UE Context identity and a U-RNTI from the HNB-GW, the SHNB reuses that U-RNTI. In Step 3, the mobile station UE1, UE2 sends an RRC Connec ^¬ tion Setup Complete message to the SHNB and in Step 4 the SHNB sends an HNBAP UE Registration Request message to the HNB-GW, which includes the assigned U-RNTI, U-RNTIx. The HNB-GW performs an access control, assigns the UE Context identifier and checks for the uniqueness of the U-RNTI for the mobile station UE1, UE2 in the database DB .

If the temporary identifier U-RNTIx assigned to the mobile station UE1, UE2 by the SHNB is already used in other HNBs in the network HNB-RAN (and therefore stored in the data ^¬ base DB) , the HNB-GW assigns a new U-RNTI, U-RNTIy, and forwards it to the SHNB in the HNBAP UE Registration Accept reply message in Step 5. The SHNB and HNB-GW (in the data ^¬ base DB) store the new U-RNTI U-RNTIy together with its Context ID, until the mobile station context for the mobile station UE1, UE2 is released. This information can be used by the HNB-GW to determine the appropriate HNB for handling the mobile station context during, for example, an intra- HNB-GW relocation according to later embodiments of the invention .

Step 5 is not required if it is determined that the mobile station UE1, UE2 is already registered with the network

HNB-RAN. In this case, the U-RNTI context assigned by the SHNB to the mobile station UE1, UE2 at Step 2 (U-RNTIx) shall be the one received by the HNB-GW during the previous UE Registration of the mobile station UE1, UE2.

In Step 7 and Step 8, at the next opportunity to perform an RRC Reconfiguration, the SHNB assigns a new U-RNTI value to the mobile station UE1, UE2, if the value currently in use (U-RNTIx) differs from the value (U-RNTIy) received from the HNB-GW.

In Step 9, if the HNB-GW needs to update some parameters related to the UE Context of the mobile station UE1, UE2, for example the U-RNTI, it can send a new HNBAP message, named here "HNBAP UE Register Update", carrying the new parameter value. Specifically, this can be a new U-RNTI.

Upon reception of a new U-RNTI value (U-RNTIz) for a connected mobile station UE1, UE2 in Steps 10 and 11, the SHNB can wait until the next RRC Reconfiguration to provide the new value to the mobile station UE1, UE2 or it can immedi ^¬ ately start the RRC UTRAN Mobility Information procedure.

An RRC reconfiguration procedure always occurs if the mo- bile station UE1, UE2 is requesting a data service to the core network CN domain (CS or PS) . Otherwise, if the RRC connection is only used to exchange signaling with the core network CN (for sending a Location Update message, for example) no RRC configuration will occur. In a second embodiment of the invention, the HNB-GW gener ^¬ ates one or more new U-RNTI temporary identifier values, which it passes to the SHNB for assigning to mobile sta- tions UE1 and UE2 accessing the network HNB-RAN. One of these new U-RNTI values is assigned by the SHNB to the first mobile station UE1, which is the first mobile station to access the network HNB-RAN immediately after the U-RNTI has been passed to the SHNB. The mobile station UE1 is then registered with the HNB-GW. The HNB-GW then returns another unique U-RNTI value to the mobile station UE2, which is for the next mobile station accessing the network HNB-RAN immediately following UE1. In the following embodiments, the U-RNTI values obtained as described above are used for relocating the mobile station UE1 or UE2 from the source home NodeB SHNB to the target home NodeB THNB. In a third embodiment, a method for relocating a mobile station from a source to a target HNB in the Cell DCH is provided as illustrated in Figure 3. There are four new HNBAP messages provided for relocating the mobile station UE1, UE2 from the SHNB to the THNB. These messages carry HNB to HNB direct information, which is transparent to the

HNB-GW. The HNB to HNB information is exchanged across the HNB-GW as a transparent container.

In step 1, the Source HNB SHNB initiates the relocation of the mobile station UE1, UE2 by sending the HNBAP Relocation

Request message to the HNB-GW. This message is composed of a header containing a SHNB ID; a THNB ID; UE Context ID in the SHNB; and a "source to target transparent container" named here "HNBAPx Relocation Request message" Information Element (IE) . Using the transparent container ensures that no network nodes in between the source network node and the target network node process the relocation request. In Step 2, upon detection of the HNBAP Relocation Request message from the source HNB SHNB, the HNB-GW can run the appropriate access control, for example it checks whether the mobile station UE1 or UE2 can be relocated to the tar ^¬ get HNB THNB. If the mobile station UE1, UE2 can be relo- cated to the THNB, then the HNB-GW forwards the HNBAP Relo ^¬ cation Request message to the THNB as follows:

The header contains the SHNB ID, the THNB ID, the UE Context ID stored in the SHNB, the U-RNTI of the mobile sta- tion UE1, UE2 and optionally (if different from the one stored in the source HNB) the UE Context ID assigned to the THNB, and the "source to target HNB transparent container" as received from the SHNB at Stepl . At this point, the HNB-GW assumes that mobile station UE1, UE2 is successfully registered (i.e. that the UE context has been created) at the THNB. This is an implicit mobile station registration in the HNB through HNBAP.

In Step 3, upon detection of the HNBAP Relocation Request message from the HNB-GW, the THNB performs access control and checks whether the RABs can be relocated. If the THNB determines that the RABs can be relocated, it creates the HNBAP Relocation ACK message and sends it to the HNB-GW. The HNBAP Relocation ACK message contains: a header, in- eluding the SHNB-ID; the THNB-ID, the UE Context ID in the

THNB; the RABs accepted to relocate (RABs ID) with the cor ^¬ responding DL transport addresses and per core network do ^¬ main, and the "Target to source transparent con ^¬ tainer"/"HNBAPx Relocation Ack message" IE. From now on, the THNB uses the UE Context ID received from the HNB-GW when exchanging signaling related to that UE .

In Step 4, when the HNB-GW detects the HNBAP Relocation ACK message from the target HNB THNB, it forwards this message to the source SHNB as follows: The header contains the SHNB ID; THNB ID; UE Context ID stored in the SHNB; and the "target to source HNB transparent container" IE as received from the SHNB. At this point, the HNB-GW can start for- warding data to the THNB.

In Step 5, when the SHNB detects the HNBAP Relocation ACK message from the HNB-GW, the SHNB considers relocation suc ^¬ cessful. It then sends the RRC reconfiguration message to the mobile station UE1, UE2 and the HNBAP Relocation Commit message to the THNB via the HNB-GW. This latter message contains a header, carrying the SHNB ID; the THNB ID; the UE context ID stored in the SHNB and the "source to target transparent container"/"HNBAPx Relocation Commit message" , which is aligned with the RNSAP Relocation Commit message.

This message will be sent only if there are PS RABs to re ^¬ locate .

In Step 6, when the HNB-GW receives the HNBAP Relocation Commit message from the source HNB SHNB, the HNB-GW for ^¬ wards this message to the target HNB THNB as follows: the header includes the SHNB ID; the THNB ID; UE Context ID stored in the THNB; and the "source to target HNB transpar ^¬ ent container" as received from the SHNB.

In Step 7, upon detection of the appropriate RRC message from the mobile station UE1, UE2, the THNB sends the HNBAP Relocation Complete message to the HNB-GW. This message is composed of a header including the THNB ID, the UE context ID stored in the THNB and a "Cause" value (successful) . When the HNB-GW receives this message, the HNB-GW swaps the UE context from the SHNB to the THNB. In Steps 8 to 12, the HNB-GW then proceeds to release the

RABs that have failed to relocate towards the core network CN and releases the UE Context with the associated signal ^¬ ing towards the source HNB . Figure 4 illustrates a method according to a fourth embodi ^¬ ment of the invention, in which relocation of the mobile station UE1, UE2 from the source home NodeB SHNB to the target home NodeB THNB takes place in the Cell FACH. In Step 1 a HNBAP Context Retrieve Request is sent from the

THNB to the HNB-GW. This message contains the target HNB- ID, the UE U-RNTI received from the mobile station UE1, UE2 with the Cell Update; the cause for such request (e.g.

"Cell Update") . This message can be used by a HNB for any kind of context retrieval; e.g. for fetching a neighbour

HNB IP address in order to establish a direct connection if the HNB to HNB direct interface Id is defined.

In Step 2, when the HNB-GW detects the HNBAP Context Re- trieve Request message from the THNB, the HNB-GW tries to find out the source HNB where that UE context is stored. This is performed via the U-RNTI parameter. Once the HNB-GW has determined the source HNB where the UE context is stored, the HNB-GW sends a HNBAP Context Retrieve Request message to the SHNB. This message contains the UE Context

ID in the SHNB, the THNB ID and the "context retrieve re ^¬ quest" cause value. In Steps 3 to 12, upon detection of this message, the SHNB starts the relocation procedure as described above for the third embodiment. The HNB-GW can autonomously send the HNBAP Context Retrieve Request message to a HNB selecting a target HNB, in order to distribute the load among HNBs.

Figure 5 illustrates a method according to a fifth embodi ^¬ ment of the invention in which relocation of the mobile station UE1, UE2 from the SHNB to the THNB takes place in the Cell DCH, where the SHNB and THNB can communicate with each other over the direct interface Id.

The protocol used by the two HNBs SHNB and THNB to exchange messages on the direct interface is named here as "HNBAPx". With reference to Figure 5, the new HNBAPx messages have same content as the corresponding ones described in Figure 3 in the "source (/target) to target (/source) transparent containers" . The difference is that, in addition, trans ^¬ port addresses for data forwarding across the SHNB to THNB interface Id can be provided by the SHNB and by the THNB, respectively, since there is a direct communication between them. Furthermore, the HNBAPx Relocation Request message will also include the UL transport addresses for the relo ^¬ cated RABs at the HNB-GW.

Steps 1 to 3 are the same as for the previous two embodi ^¬ ments .

In Step 4 the HNBAP Relocation Complete Request message sent from the THNB to the HNB-GW includes a header. The message header includes a SHNB ID, THNB ID, UE Context ID strored in the SHNB; and the RABs ID for relocation with the corresponding DL transport addresses at the THNB. No SHNB to THNB transparent container is included in the header in this embodiment.

In Step 5, upon detection of the HNBAP Relocation Complete Request message from the target HNB, the HNB-GW checks whether the UE context for the mobile station UE1, UE2 can be relocated to the THNB. If the HNB-GW determines that the UE context can be relocated to the THNB, the HNB-GW sends the HNBAP Relocation Complete Response message to the tar- get HNB as follows: This message contains a header, which includes the THNB ID; the UE Context and UE U-RNTI assigned to the THNB; and the list of RABs to relocate with the UL transport addresses. At this point, HNB-GW considers the mobile station UE1, UE2 successfully registered in the tar- get HNB and can start sending data to it.

In Step 6, when the THNB is successfully synchronised on the user plane, it sends a HNBAP Relocation Complete Con ^¬ firm message to the HNB-GW. This message contains a header carrying the UE Context ID; the THNB- ID; and a "Cause" value (e.g. successful") . At this point, the HNB-GW swaps the UE context for the mobile station UE1, UE2 to the THNB. Sending of this message is required only for relocation of CS RABs .

Steps 7 to 10 take place as for Steps 9 to 12 of the previ ^¬ ous embodiment.

Figure 6 illustrates a method according to a sixth embodi- ment of the invention in which relocation of the mobile station UE1, UE2 from the SHNB to the THNB takes place in the Cell FACH, where the SHNB and THNB can communicate with each other over the direct physical interface Id. In Step 1, the mobile station UE1, UE2 sends an RRC Cell Update message to the THNB. Upon detection of the RRC Cell Update message in Step 2, the THNB requests UE context re ^¬ trieval from the HNB-GW via the HNBAP Context Retrieve Re ^¬ quest message. This message has the same content as de ^¬ scribed for Steps 1 and 2 of the fourth embodiment de ^¬ scribed above.

All other messages sent in Steps 3 to 12 are the same as those in the corresponding steps described for the previous embodiment above .

Although the invention has been described hereinabove with reference to specific embodiments, it is not limited to these embodiments and no doubt further alternatives will occur to the skilled person, that lie within the scope of the invention as claimed.