WO2001041493A1

WO2001041493A1 - Rehoming automation

Info

Publication number: WO2001041493A1
Application number: PCT/SE2000/002354
Authority: WO
Inventors: Robert Petersen; Björn EHRSTEDT
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 1999-12-06
Filing date: 2000-11-28
Publication date: 2001-06-07
Also published as: AU2033901A; CN1435067A; AR029413A1

Abstract

An automated rehoming method and system are disclosed, whereby all pertinent data (e.g., all radio network data and transport network data pertaining to an RNC) are conveyed in one or more messages from a first RNC to a second RNC via an Iur, Iu or management interface, or via any proprietary (standard or non-standard) interface for other 3rd or non-3rd generation systems, and establish a connection between the second RNC and a Node B.

Description

REHOMING AUTOMATION

CROSS-REFERENCES TO RELATED APPLICATIONS

This Application for Patent claims the benefit of priority from, and hereby incorporates by reference the entire disclosures of, co-pending U.S. Provisional

Applications for Patent Serial Nos. 60/169,343, filed December 6, 1999, and 60/202,616, filed May 9, 2000.

BACKGROUND OF THE INVENTION Technical Field of the Invention

The present invention relates in general to the telecommunications field and, in particular, to a method and system for automatically transferring mobile communications network base station data from one network controller to another. Description of Related Art One implementation of the so-called new 3^rd generation mobile communication system is the Universal Mobile Telephone System (UMTS). In such a 3^rd generation system, rehoming is the task of moving a base station connection from one Radio Network Controller (RNC) to another. Basically, rehoming automation refers to the task of automatically transferring relevant radio network data and transport network data associated with a base station from a first RNC to a second RNC. Notably, although the concept of rehoming automation in a UMTS environment is discussed herein, the principles being discussed are also applicable for other types of cellular or mobile networks as well, such as, for example, Global System for Mobile Communications (GSM) networks, IS-95 networks, Digital- Advanced Mobile Phone System (D-AMPS) networks, etc. However, in such cases, the network information to be transferred from a first node to a second node can be passed, for example, via a Mobile Services Switching Center (MSC) and/or a management system.

Rehoming is commonly accepted by many operators as an expedient method for expanding a network. For example, FIGURES 1 A-1C are related block diagrams that illustrate how a rehoming procedure can be used to expand a network (e.g., the network associated with RNC2).

A significant problem with existing rehoming procedures is that they involve some of the most labor intensive Operation & Maintenance (O&M) functions that network operators can perform. The main reason for this problem is that the existing rehoming procedures followed for routing base station data from one RNC (or other such entity) to another RNC are accomplished manually. In other words, using the existing rehoming procedures, a network operator has to manually provide all data associated with a base station to a new RNC and then manually delete the base station- related data from the original RNC. These manual rehoming approaches significantly increase the O&M time and associated costs for operators, and also increase the likelihood that errors will be introduced.

SUMMARY OF THE INVENTION In accordance with a preferred embodiment of the present invention, an automated rehoming method and system are provided, whereby all pertinent data (e.g., all radio network data and transport network data pertaining to a base station) are conveyed in one or more messages from a first RNC to a second RNC via, for example, an lur, Iu or management interface, or via any proprietary (standard or non- standard) interface for other, 3^rd or non-3^rd generation systems, and establish a connection between the second RNC and a Node B.

An important technical advantage of the present invention is that by automating the rehoming procedure, the associated O&M time and costs can be significantly reduced. Another important technical advantage of the present invention is that the probability of reducing errors during the rehoming procedure can be significantly reduced. BRTEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the method and apparatus of the present invention may be had by reference to the following detailed description when taken in conjunction with the accompanying drawings wherein: FIGUREs 1A-1C are related block diagrams that illustrate how a rehoming procedure can be used to expand a network;

FIGURE 2 is a block diagram of a 3^rd generation mobile communication network, which can be used to implement a preferred embodiment of the present invention; FIGURES 3 A, 3B and 3C are related block diagrams of a 3^rd generation mobile communication system, which can be used to implement the preferred embodiment of the present invention if a rehoming procedure is fully or partly successful, or unsuccessful;

FIGURE 4 is a time sequence diagram that illustrates an example of a successfully performed rehoming procedure, in accordance with the preferred embodiment of the present invention;

FIGURE 5 is a time sequence diagram that illustrates a second example of a successfully performed rehoming procedure, in accordance with the preferred embodiment of the present invention; FIGURE 6 is a time sequence diagram that illustrates a third example of a successfully performed rehoming procedure, in accordance with the preferred embodiment of the present invention;

FIGURE 7 is a time sequence diagram that illustrates an example of an unsuccessful rehoming procedure, in accordance with the preferred embodiment of the present invention;

FIGURE 8 is a time sequence diagram that illustrates a second example of an unsuccessful rehoming procedure, in accordance with the preferred embodiment of the present invention; and

FIGURE 9 is a time sequence diagram that illustrates a third example of an unsuccessful rehoming procedure, in accordance with the preferred embodiment of the present invention. DETATLED DESCRIPTION OF THE DRAWINGS

The preferred embodiment of the present invention and its advantages are best understood by referring to FIGURES 1 A- 9 of the drawings, like numerals being used for like and corresponding parts of the various drawings. Essentially, in accordance with a preferred embodiment of the present invention, an automated rehoming method and system are provided, whereby all pertinent data (e.g., all radio network data and transport network data pertaining to a base station) are conveyed in one or more messages from a first RNC to a second RNC via, for example, an lur, lu or management interface, or via any proprietary (standard or non-standard) interface for other, 3^rd or non-3^rd generation systems, and establish a connection between the second RNC and a Node B. As such, the present invention is independent of the underlying transport network technology used for signalling and data transport. The transport networks involved can include circuit- switched transport networks, packet-switched transport networks, or any type of transport network such as, for example, an ATM transport network, an IP transport network, a CCS 7 transport network, etc.

Specifically, FIGURE 2 is a block diagram of an exemplary mobile communication network such as, for example, a 3^rd generation mobile communication network, which can be used to implement a preferred embodiment of the present invention. Referring to FIGURE 2, a Universal Mobile Telephony System (UMTS)

10 configured in accordance with the 3^rd Generation Partnership Project (3GPP) technical specifications is shown. The exemplary UMTS 10 shown includes a Core Network 12, and a Universal Terrestrial Radio Access Network (UTRAN) 11 including one or more Radio Network Subsystems (RNSs), such as RNSs 13a and 13b. The Core Network 12 enables subscribers to access services from a network operator. Also, for this example, the RNSs shown include respective RNCs 14a, 14b and related Node Bs 16a, 16b, 16c, 16d.

Specifically, an RNS (e.g., 13a or 13b) can function in a UTRAN as, for example, the access part of a UMTS network, and can allocate and release specific radio resources in order to establish connections between a UTRAN (e.g., 11) and a radio terminal (User Equipment or UE) 18. As such, an RNS is responsible for the radio resources and transmission/reception in a set of cells. The RNCs (e.g., 14a, 14b) in the respective RNSs function to control the use and integrity of the radio resources. Each Node B (e.g., 16a, 16b, 16c, 16d) is a logical node responsible for the radio transmission/reception in one or more cells and to or from a UE (e.g., 18). A Node B is similar to a base station in a non-3^rd generation system. Notably, an RNC (e.g.,

14b) can function as a Controlling RNC (CRNC) with respect to a specific set of Node Bs. However, a Node B typically has only one CRNC. A CRNC controls the logical resources of its related Node Bs.

In accordance with the embodiment exemplified by FIGURE 2, two types of network data are involved during the rehoming procedure: radio network data and transport network data. The radio network data includes all data configured in a base station received from a CRNC preferably over an Iub interface. Such radio network data can be derived from certain procedures such as, for example, cell setup, cell reconfiguration, common transport channel setup, common transport channel reconfiguration, system information update, common measurements initiation, and resource status indication procedures. The radio network data can also include neighboring cell information stored in a CRNC for all cells configured in the base station which is to be moved (connected) to another RNC. A detailed listing of the radio network data used for a 3^rd generation system is disclosed in the UTRAN Technical Specification TS 25.433 (UTRAN Iub Interface NBAP Signalling from

3GPP).

The transport network data can include transport layer addresses, link characteristics, and other transport layer-related data needed to establish transport bearers used for carrying user plane data between a new RNC and a base station. For example, this data can be ATM endpoint addresses, peak/average bit rates, etc., in an

ATM-based transport network.

If necessary, in accordance with the preferred embodiment of the present invention, new radio network configuration data which has not been used by a first and second RNC, can be sent from the management system to the first and second RNC. Also, new radio network configuration data can be sent from the management system to the first RNC, which can then send the data in a container message to the first and second RNC.

Specifically, FIGURES 3 A, 3B and 3C are related block diagrams of an exemplary 3^rd generation mobile communication system 100, which can be used to implement the preferred embodiment of the present invention, if an attempted automated rehoming procedure is fully successful, partly successful, or unsuccessful. As shown in FIGURES 3 A, 3B and 3C, the exemplary system 100 includes a management system 102, a first RNC 104, a second RNC 106, and a base station BS2 108. As such, the management system 102 performs network management functions and provides a management interface with an operator.

In operation, referring to FIGURE 3A, the (automated) rehoming procedure to be performed is initiated by a control message (denoted by 103) from the management system 102. The control message orders RNC1 104 to take all cells supported by BS2 108 out of operation, and place all relevant radio network and transport network data regarding BS2 108, which is to be used by RNC2 106, into one or more container messages. RNC1 104 then sends the one or more container message(s) to RNC2 106 via the lur interface (denoted by 105), before BS2 108 is moved and connected to RNC2 106. As such, all relevant configuration data remains unchanged in BS2 108 during the rehoming procedure. Any required reconfiguration of the transport network and signalling network can be accomplished before initiating the rehoming procedure. However, the transport bearers to be used for carrying user plane data between BS2 108 and RNC2 106 can be pre-configured prior to rehoming, or dynamically established during a rehoming procedure.

Referring to FIGURE 3B, RNC2 106 then performs an audit procedure via the Iub interface to ensure that it has the same radio network configuration information as BS2 108 (denoted by 107). If the audit procedure's results are correct, RNC2 106 sends a response message to RNCl 104 via the lur interface, which causes RNCl to delete its data about BS2 108 (denoted by 109). RNCl 104 and/or RNC2 106 sends a message to the management system 102 via a management interface I l ia and/or 111b, which informs the management system that the rehoming procedure was successfully completed. The management system 102 then notifies the operator (113) that the rehoming procedure was successfully completed.

In the event that the rehoming procedure was only partially successful, the operator can decide whether to complete the rehoming procedure with the degraded performance, or perform a rollback procedure (return to the original configuration).

Such a decision can be made by the operator on-line (e.g., in real-time) or implemented and so configured before the rehoming procedure is performed. In any event, the decision about whether to complete a degraded performance rehoming procedure or perform a rollback procedure, can be configured by the management system 102 so that for certain circumstances, the operator can make the decision online. For example, if the Broadcast Channel (BCH) cannot be supported by the rehoming procedure, the operator can decide that a rollback procedure is to be performed. As another example, if less than 50% of the transport bearers required for the Fast Acquisition Channel (FACH), Paging Channel (PCH), and/or Random Access Channel (RACH) can be established, the operator can make the decision on-line about whether to complete the rehoming procedure or perform a roll-back procedure. As yet another example, if more than 50% of the transport bearers required for the FACH, PCH, and/or RACH can be established, then the operator can decide on-line that the rehoming procedure is to be completed. As such, it should be understood that there are a number of reasons, other than a shortage of transport bearers, why an operator might decide to terminate the rehoming procedure. For example, an operator might terminate a rehoming procedure if certain internal RNC errors were to occur, or there is a shortage of processor or memory capacity in an RNC.

In the event a significant error occurs during the rehoming procedure, a rollback procedure can be performed. For example, referring to FIGURE 3C, during the above-described rehoming procedure, if the transport bearers between BS2 108 and RNC2 106 cannot be established for all PCHs, or some other error occurs that results in an unsuccessful rehoming procedure, BS2 108 can be moved back (connected) to RNCl 104. As such, RNC2 106 releases all of its newly established transport bearers to BS2 108 (115) via the Iub interface, before RNC2 106 informs RNC1 104 that the rehoming attempt has failed (117). RNC2 106 deletes the pertinent data previously received in container message(s) from RNCl 104.

In response, RNCl 104 initiates an audit procedure for (or can send a Rehoming Failure message to) BS2 108 via the Iub interface (119), in order to re- establish the connection between RNC 1 104 and BS2 108, and ensure that RNC 1 104 and BS2 108 have the same opinion about the configuration in BS2 108. RNCl 104 then informs the management system 102 that the rehoming procedure attempt was unsuccessful. BS2 108 is connected back to RNCl 104 (121). The management system 102 then notifies the operator (123) that the rehoming procedure attempt has failed.

In accordance with the existing UMTS standard, the RNC can perform an audit procedure to determine whether both nodes (e.g., RNC and base station) have the same opinion about the configuration of the base station. This audit procedure can be performed due to a break in communications between the base station and an RNC. If the two nodes' opinions differ, then the RNC can take appropriate actions until the differences are resolved and consistent opinions about the configuration of the base station are formed by the two nodes.

FIGURE 4 is a time sequence diagram that illustrates an example of a successfully performed rehoming procedure, in accordance with the preferred embodiment of the present invention. Referring to the system shown in FIGURE 3 A, and the method 150 shown in FIGURE 4, at step 152, the management system 102 sends a rehoming request message to RNCl 104 via the management interface. In response, at step 154, RNC 1 104 sends a rehoming request message to RNC2 106 via the lur interface. This rehoming request message includes pertinent radio network and transport network data.

At step 156, RNC2 106 sends an audit request message to BS2 108 via the Iub interface. This audit request message indicates to BS2 108 that a rehoming attempt to RNC2 106 is to be performed. In response, at step 158, BS2 108 sends an audit response message to RNC2 106 via the Iub interface. This audit response message includes the Binding IDs for the transport bearers that RNC2 106 is to use. At step

160, RNC2 106 establishes the transport bearers for the common transport channels to be used. When RNC2 106 has established the required transport bearers, at step 162, RNC2 sends an audit complete message (e.g., a new Node B Application Protocol (NBAP) message within the UMTS specification) to BS2 108 via the Iub interface, which informs BS2 that the newly established transport bearers are to be used.

At step 164, RNC2 106 sends a rehoming response message to RNC 1 104 via the lur interface. In response, at step 166, RNCl 104 releases the transport bearers used between RNCl andBS2 108. The radio network data and transport network data forBS2 108 should be deleted in RNCl 104 after the release. At step 168, RNCl 104 sends a rehoming response message to the management system 102 via the management interface, which informs the management system that the rehoming procedure has been successfully completed.

FIGURE 5 is a time sequence diagram that illustrates a second example of a successfully performed rehoming procedure, in accordance with the preferred embodiment of the present invention. Referring again to the system shown in

FIGURE 3 A, and the method 170 shown in FIGURE 5, at step 172, the management system 102 sends a rehoming request message to RNC 1 104 via the management interface. In response, at step 174, RNCl 104 sends an audit request message to BS2 108 via the Iub interface. This audit request message indicates to BS2 108 that a rehoming attempt to RNC2 106 is to be performed. In response, at step 176, BS2 108 sends an audit response message to RNCl 104 via the Iub interface. This audit response message includes the Binding IDs for the transport bearers that RNC2 106 is to use. At step 178, RNC 1 104 sends a rehoming request message to RNC2 106 via the lur interface. This rehoming request message includes radio network data with the Binding IDs for the transport bearers RNC2 106 is to use, and transport network data.

At step 180, RNC2 106 establishes the transport bearers for the common transport channels to be used. When RNC2 106 has established the required transport bearers, at step 182, RNC2 sends an audit request message to BS2 108 via the Iub interface. The primary purpose of this audit request message is to ensure that the two nodes (RNC2 and BS2) have the same opinion about the configuration in BS2. In response, at step 184, BS2 108 sends an audit response message to RNC2 106 via the Iub interface. For this example, it can be assumed that this audit response message indicates that the two nodes' opinions are consistent about the configuration in BS2 108.

At step 186, RNC2 106 sends a rehoming response message to RNC 1 104 via the lur interface. This rehoming response message indicates to RNCl 104 that the rehoming procedure was successfully performed. At step 188, RNCl 104 sends an audit complete message to BS2 108 (e.g., a new NBAP message) via the Iub interface. This audit complete message indicates to BS2 108 that the new transport bearers to RNC2 106 are to be used. In response, at step 190, RNCl 104 releases the transport bearers used between RNCl and BS2 108. At step 192, RNCl 104 sends a rehoming response message to the management system 102 via the management interface. This rehoming response message informs the management system 102 that the rehoming procedure has been successfully completed.

FIGURE 6 is a time sequence diagram that illustrates a third example of a successfully performed rehoming procedure, in accordance with the preferred embodiment of the present invention. Referring again to the system shown in FIGURE 3 A, and the method 200 shown in FIGURE 6, at step 202, the management system 102 sends a rehoming request message to RNCl 104 via the management interface. In response, at step 204, RNCl 104 sends a rehoming request message to BS2 108 via the Iub interface, which indicates to BS2 108 that a rehoming attempt to

RNC2 106 is to be performed (e.g., a new NBAP message). At step 206, BS2 108 sends a rehoming response message to RNCl 104 via the Iub interface. This rehoming response message includes the Binding IDs for the transport bearers that RNC2 106 is to use (e.g., a new NBAP message). In response, at step 208, RNC 1 104 sends a rehoming request message to RNC2 106 via the lur interface. This rehoming request message includes radio network data with the Binding IDs for the transport bearers RNC2 106 is to use, and transport network data.

At step 210, RNC2 106 establishes the transport bearers for the common transport channels to be used. When RNC2 106 has established the required transport bearers, at step 212, RNC2 sends an audit request message to BS2 108 via the Iub interface. The primary purpose of this audit request message is to ensure that the two nodes (RNC2 and BS2) have the same opinion about the configuration in BS2 108. In response, at step 214, BS2 108 sends an audit response message to RNC2 106 via the Iub interface. For this example, it can be assumed that this audit response message indicates that the two nodes' opinions are consistent about the configuration in BS2 108.

At step 216, RNC2 106 sends a rehoming response message to RNC 1 104 via the lur interface. This rehoming response message indicates to RNCl 104 that the rehoming procedure was successfully performed. At step 218, RNCl 104 sends a rehoming complete message to BS2 108 via the Iub interface (e.g., a new NBAP message). This rehoming complete message informs BS2 108 that the transport bearers to RNC2 106 are to be used. In response, at step 220, RNC 1 104 releases the transport bearers used between RNCl and BS2 108. At step 222, RNCl 104 sends a rehoming response message to the management system 102 via the management interface. This rehoming response message informs the management system 102 that the rehoming procedure has been successfully completed.

FIGURE 7 is a time sequence diagram that illustrates an example of an unsuccessful rehoming procedure, in accordance with the preferred embodiment of the present invention. Referring to the system shown in FIGURE 3C, and the method 230 shown in FIGURE 7, at step 232, the management system 102 sends a rehoming request message to RNC 1 104 via the management interface. In response, at step 234,

RNCl 104 sends a rehoming request message to RNC2 106 via the lur interface. This rehoming request message includes pertinent radio network and transport network data.

At step 236, RNC2 106 sends an audit request message to BS2 108 via the Iub interface. This audit request message indicates to BS2 108 that a rehoming attempt to RNC2 106 is to be performed. In response, at step 238, BS2 108 sends an audit response message to RNC2 106 via the Iub interface. This audit response message includes the Binding IDs for the transport bearers that RNC2 106 is to use.

At step 240, RNC2 106 attempts to establish the transport bearers for the common transport channels to be used between RNC2 and BS2 108. Assuming, for this example, that only one transport bearer (e.g., out of five) can be established, at step 241, the rehoming a .empt is considered unsuccessful (by data configured in RNC2 106). Consequently, at step 242, RNC2 106 releases the newly established transport bearer. At step 244, RNC2 106 sends a rehoming response message to RNC 1 104 via the lur interface. This rehoming response message indicates to RNC 1 104 that the rehoming attempt failed. At step 246, RNCl 104 sends an audit request message to BS2 108 via the Iub interface, in order to determine the state of the configuration in BS2 108, and rollback the original transport bearers between RNCl 104 and BS2 108. At step 248, BS2 108 sends an audit response message to RNCl 104 via the Iub interface, which indicates to RNCl 104 that the requested audit has been performed. At step 250, RNCl 104 sends a rehoming response message to the management system 102 via the management interface. This rehoming response message informs the management system that the rehoming attempt failed.

FIGURE 8 is a time sequence diagram that illustrates a second example of an unsuccessful rehoming procedure, in accordance with the preferred embodiment of the present invention. Referring again to the system shown in FIGURE 3C, and the method 260 shown in FIGURE 8, at step 262, the management system 102 sends a rehoming request message to RNCl 104 via the management interface. In response, at step 264, RNCl 104 sends an audit request message to BS2 108 via the Iub interface. This audit request message indicates to BS2 108 that a rehoming attempt to RNC2 106 is to be performed (e.g., a new NBAP message). In response, at step

266, BS2 108 sends an audit response message to RNCl 104 via the Iub interface. This audit response message includes the Binding IDs for the transport bearers that RNC2 106 is to use. At step 268, RNCl 104 sends a rehoming request message to RNC2 106 via the lur interface. This rehoming request message includes radio network data with the Binding IDs for the transport bearers RNC2 is to use, and transport network data.

At step 270, RNC2 106 establishes the transport bearers for the common transport channels to be used to BS2 108. When RNC2 106 has established the required transport bearers, at step 272, RNC2 sends an audit request message to BS2 108 via the Iub interface. The primary purpose of this audit request message is to ensure that the two nodes (RNC2 and BS2) have the same opinion about the configuration in BS2. In response, at step 274, BS2 108 sends an audit response message to RNC2 106 via the Iub interface. For this example, it can be assumed that this audit response message indicates that the BCH, primary and secondary SCHs, and the primary and secondary CPICH were not operable, and a criterion configured in RNC2 106 for a failed rehoming attempt is that a BCH is not operable. In other words, this rehoming attempt has failed (step 276). Consequently, at step 278, RNC2 106 releases the newly established transport bearers to BS2 108. At step 280, RNC2 106 sends a rehoming response message to RNCl 104 via the lur interface. This rehoming response message indicates to RNCl 104 that the rehoming attempt failed. At step 282, RNC 1 104 sends an audit complete message (e.g., a new NBAP message) to BS2 108 via the Iub interface. This audit complete message informs BS2 108 that the original transport bearers to RNCl 104 are to be rolled back (restored). At step 284, RNCl 104 sends a rehoming response message to the management system 102 via the management interface. This rehoming response message informs the management system that the rehoming attempt failed.

FIGURE 9 is a time sequence diagram that illustrates a third example of an unsuccessful rehoming procedure, in accordance with the preferred embodiment of the present invention. Referring again to the system shown in FIGURE 3C, and the method 300 shown in FIGURE 9, at step 302, the management system 102 sends a rehoming request message to RNCl 104 via the management interface. In response, at step 304, RNCl 104 sends a rehoming request message to BS2 108 via the Iub interface, which indicates to BS2 108 that a rehoming attempt to RNC2 106 is to be performed (e.g., a new NBAP message). At step 306, BS2 108 sends a rehoming response message to RNCl 104 via the Iub interface (e.g., a new NBAP message). This rehoming response message includes the Binding IDs for the transport bearers that RNC2 106 is to use. In response, at step 308, RNCl 104 sends a rehoming request message to RNC2 106 via the lur interface. This rehoming request message includes radio network data with the Binding IDs for the transport bearers RNC2 106 is to use, and transport network data. At step 310, RNC2 106 establishes the transport bearers for the common transport channels to be used to BS2 108. When RNC2 106 has established the required transport bearers, at step 312, RNC2 sends an audit request message to BS2 108 via the Iub interface. The primary purpose of this audit request message is to ensure that the two nodes (RNC2 and BS2) have the same opinion about the configuration in BS2 108. In response, at step 314, BS2 108 sends an audit response message to RNC2 106 via the Iub interface. For this example, it can be assumed that this audit response message indicates that the BCH, primary and secondary SCHs, and primary and secondary CPICH are not operable, and a criterion configured in RNC2 106 for a failed rehoming attempt is a non-operable BCH. In other words, this rehoming attempt failed (step 316). At step 318, RNC2 106 releases the newly established transport bearers to BS2 108, and at step 320, sends a rehoming response message to RNC 1 104 via the lur interface. This rehoming response message informs RNCl 104 that the rehoming attempt failed. At step 322, RNCl 104 sends a rehoming failure message to BS2 108 (e.g., a new NBAP message), which informs BS2 that the original transport bearers to BS2 108 are to be rolled back (restored). At step 324, RNC 1 104 sends a rehoming response message to the management system

102 via the management interface. This rehoming response message informs the management system that the rehoming attempt failed.

Although a preferred embodiment of the method and apparatus of the present invention has been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it will be understood that the invention is not limited to the embodiment disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.

Claims

WHAT IS CLAIMED IS:

1. A rehoming method for a mobile communication system, comprising the steps of: informing a first network control unit to remove from operation at least one cell generated by a base station; inserting radio network data associated with a connection between a second network control unit and said base station in at least one container message; sending said at least one container message to said second network control unit; and establishing said connection between said base station and said second network control unit.

2. The rehoming method of Claim 1, further comprising the step of determining if said second network control unit and said base station agree about a radio network configuration for said base station.

3. The method of Claim 2, further comprising the steps of: if said second network control unit and said base station agree about a radio network configuration for said base station, said second network control unit sending a confirmation message to said first network control unit; and said first network control unit deleting connection data associated with said base station.

4. The method of Claim 2, further comprising the steps of: if said second network control unit and said base station do not agree about a radio network configuration for said base station, instead of establishing said connection between said base station and said second network control unit, establishing a connection between said base station and said first network control unit.

5. The method of Claim 2, further comprising the steps of: if said second network control unit and said base station do not agree about a radio network configuration for said base station, establishing said connection between said base station and said second network control unit.

6. The method of Claim 1 , wherein the inserting step and sending step are performed by said first network control unit.

7. The method of Claim 1, wherein the step of sending said at least one container message to said second network control unit comprises sending said at least one container message to said second network control unit via an lur interface.

8. The method of Claim 1 , wherein the step of informing a first network control unit to remove from operation at least one cell generated by a base station comprises a management system instructing said first network control unit to remove from operation said at least one cell generated by said base station.

9. The method of Claim 1, further comprising the step of establishing at least one transport bearer to be used for said connection between said base station and said second network control unit.

10. The method of Claim 1 , wherein the step of determining if said second network control unit and said base station agree about a radio network configuration for said base station comprises a step of initiating an audit procedure.

11. The method of Claim 1 , wherein said mobile communication system comprises a UMTS.

12. The method of Claim 1 , wherein if a connection performance between said second network control unit and said base station is less than a predetermined level, instead of establishing said connection between said base station and said second network control unit, re-establishing a connection between said base station and said first network control unit.

13. The method of Claim 12, wherein the step of re-establishing said connection between said base station and said first network control unit comprises performing a rollback procedure.

14. The method of Claim 9, wherein if the step of establishing said at least one transport bearer to be used for said connection between said base station and said second network control unit is unsuccessful, said second network control unit releasing any established transport bearer to be used for said connection between said base station and said second network control unit, and informing said first network control unit that a rehoming attempt has failed.

15. The method of Claim 1, wherein said first network control unit and said second network control unit comprise a first radio network controller and a second radio network controller, respectively.

16. The method of Claim 1, wherein the inserting step further comprises inserting transport network data associated with said connection in said at least one container message.

17. An automated rehoming system for a mobile communication system, comprising: a base station; a first network control unit, said first network control unit operable to establish a first radio connection with said base station; a second network control unit, said second network control unit operable to establish a second radio connection with said base station; and a network interface, said network interface operable to establish a signalling connection with at least one of said base station, said first network control unit, and said second network control unit, said network interface further operable to: instruct said first network control unit to remove from operation at least one cell generated by said base station; and said first radio network control unit further operable to: insert radio network data associated with said second radio connection between said second network control unit and said base station in at least one container message; and send said at least one container message to said second network control unit; said second radio network control unit further operable to: establish said radio connection between said base station and said second network control unit.

18. The automated rehoming system of Claim 17, said system further operable to determine if said second network control unit and said base station agree about a radio network configuration for said base station.

19. The automated rehoming system of Claim 18, said second network control unit further operable to send a confirmation message to said first network control unit if said second network control unit and said base station agree about a radio network configuration for said base station, said first network control unit further operable to delete connection data associated with said base station.

20. The automated rehoming system of Claim 18, said first network control unit further operable to establish a connection between said base station and said first network control unit if said second network control unit and said base station do not agree about a radio network configuration for said base station.

21. The automated rehoming system of Claim 18, said second network control unit further operable to establish said connection between said base station and said second network control unit if said second network control unit and said base station do not agree about a radio network configuration for said base station.

22. The automated rehoming system of Claim 17, wherein said first network control unit is further operable to send said at least one container message to said second network control unit via an lur interface.

23. The automated rehoming system of Claim 17, wherein said management system is further operable to instruct said first network control unit to remove from operation said at least one cell generated by said base station.

24. The automated rehoming system of Claim 17, said second network control unit further operable to establish at least one transport bearer to be used for said connection between said base station and said second network control unit.

25. The automated rehoming system of Claim 17, wherein said second network control unit is further operable to initiate an audit procedure if said second network control unit and said base station agree about a radio network configuration for said base station.

26. The automated rehoming system of Claim 17, wherein said mobile communication system comprises a UMTS.

27. The automated rehoming system of Claim 17, wherein said first network control unit is further operable to re-establish a connection between said base station and said first network control unit if a connection performance between said second network control unit and said base station is less than a predetermined level.

28. The automated rehoming system of Claim 27, wherein said first network control unit is further operable to re-establish said connection between said base station and said first network control unit by performing a rollback procedure.

29. The automated rehoming system of Claim 24, wherein said second network control unit is further operable to release any established transport bearer to be used for said connection between said base station and said second network control unit, and inform said first network control unit that a rehoming attempt has failed, if an attempt to establish said at least one transport bearer to be used for said connection between said base station and said second network control unit is unsuccessful.

30. The automated rehoming system of Claim 17, wherein said first network control unit and said second network control unit comprise a first radio network controller and a second radio network controller, respectively.

31. The automated rehoming system of Claim 17, wherein said first radio network control unit is further operable to insert transport network data associated with said second radio connection in said at least one container message.