Patent Application
20060046724
1. Field of the Invention
The invention relates to a method for optimizing handoff procedures in a cellular telecommunication network.
2. Description of the Related Art
As of today, a mobile terminal (MT) may roam in a telecommunication network during a call. The MT may roam from its home network to a foreign network and this depending on agreements between different service providers. For doing so, the MT is handed off following network operations in the telecommunication network. For instance, a mobile switching center (MSC) could perform the network operations or alternatively the handoff may be performed between a source base station controller (BSC) and a target BSC.
A BSC is the control part of a radio base station (RBS). The BS is central radio transmitter/receiver that maintains communications with the MT. The BS usually covers a given range (typically a cell) for MTs. The BSC controls one or more BSs radio signals, thus reducing the load on the MSC. The BSC also performs radio signal management functions for BSs and manages functions such as frequency assignment and handoff.
As defined in interim standard (IS), Interoperability Specifications (IOS) for CDMA2000 Access Network Interfaces, TIA/EIA/IS-2001-A published in 2000 by the TIA/EIA, which is included herewith by reference, a source BSC hands off a MT during a call to a target BSC and this when detecting that the signal strength with the MT is below a certain threshold. The source BSC further informs the associated serving MSC of the new location of the MT. Next, the source BSC establishes a path with a target BSC for handing off the MT. This type of hand off is called inter-BSC soft handoff of the MT. Inter-BSC soft handoff includes the capability of the BSC to act as both the ‘source’ and the ‘target’ in a soft handoff. As a ‘source’, the BSC is responsible for initiating and maintaining a radio link between the MT that is being served by the BSC and a BS that is within another BSC. As a ‘target’, the BSC is responsible for providing a radio link between a BS within a source BSC, and a MT that is being served by another BSC (target BSC). Inter-BSC soft handoff functionality is supported by the A3 and A7 interfaces to the BSC.
The A3 interface is composed of signaling and traffic channels. It provides an ability to establish and remove A3 traffic connections. The A3 interface also provides support for operational procedures, such as turning on/off voice privacy or changing the service configuration of a call. The A7 interface provides direct BSC to BSC signaling for the support of an efficient soft handoff procedure. Only a call release procedure can interrupt a handoff procedure.
The current A7 interface does not support multiple instances of endpoints. Therefore, the source BSC has a single instance of the soft handoff functionality running on the ‘target’ BSC. When calls are handed off from the source BSC to the target BSC, the source BSC allocates a board for each call on its side and the same thing is applied at the target BSC side for handing off MTs and further calls from the MTs. More than one call can be allocated to a board in the target BSC or in the source BSC. A hardware or software failure at the source or the target BSC results in complete dropped handoffs calls and the inability to process new requests. Furthermore, the capacity for handling calls is limited to the resources of the hardware running the software, which is not scalable. A solution to that problem of limited resources is to perform a load distribution of calls within the source BSC or the target BSC.
However, if a failure occurs it cannot be possible to remove the soft handoff calls on the source BSC, since it cannot be possible to identify which calls were associated to failed instance of a software running on the source BSC or the target BSC. Therefore, this results in dropping all soft handoffs calls at the source BSC or the target BSC during hardware of software failure that occurs at the same source BSC or target BSC. A solution to this problem could be a static load distribution. However, this causes inefficient use of resources.
Another impact of load distribution is the handling of requests associated to soft handoff calls. Without such a mechanism, such requests will be difficult to handle and waste resources defeating the purpose of load distribution. Therefore, there is a need to improve the ability of a BSC to support soft handoff for a MT, between base-stations located within different BSCs. The invention provides a solution to that problem.
It is therefore one broad object of this invention to provide a method for performing a soft handoff of a mobile terminal (MT) from a source base station controller (BSC) to a target BSC in a telecommunication network, the method comprising steps of:
sending from the source BSC to the target BSC a request for handing off the MT to the target BSC, the request including a source process identifier (Source ID) for identifying a source process that handles a call for the MT in the source BSC;
assigning a target process at the target BSC for handling the call;
storing at the target BSC the Source ID and a target process identifier (Target ID), wherein the Target ID identifies the target process that handles the call for the MT in the target BSC;
sending from the target BSC to the source BSC a handoff response, the handoff response including the Target ID;
detecting a failure at one of the target BSC and the source BSC;
responsive to the detection, sending a reset message from one of the target BSC and the source BSC to one of the source BSC and the target BSC, the reset message including the Target ID if the failure is detected at the target BSC and the Source ID if the failure is detected at the source BSC; and
using one of the Source ID or the Target ID of the reset message for tearing down the call at one of the target BSC and the source BSC.
It is therefore another broad object of his invention to provide a target base station controller (BSC) for handing off a mobile terminal (MT) in a telecommunication network, the BSC comprises:
a service logic for:
wherein the service logic detects a failure at the target BSC and sends to the source BSC a reset message including the Target ID for tearing down the call associated with the at the source BSC.
For a more detailed understanding of the invention, for further objects and advantages thereof, reference can now be made to the following description, taken in conjunction with the accompanying drawings, in which:
a is a flow chart showing a method for tearing down a call if a failure occurs at a source BSC in accordance to the invention; and
b is a flow chart showing a method for tearing down a call if a failure occurs at a target BSC in accordance to the invention.
Reference is now made to
The telecommunication network 100 also comprises other network elements defined in IS-2001 and which are omitted in
BSC 20 and BSC 30 each serve at least one radio base station (RBS). In
The service logic 21 and the service logic 31 provide load balancing and soft handoff processing of calls for MTs that are served by BSC 20 and BSC 30 in the telecommunication network 100. A service logic can be a software, a hardware or any combination thereof.
A BSC comprises at least one process for handling calls for MTs and which is a piece of hardware such as a physical electronic board, a software or a combination thereof. In particular, a process of a source BSC is a source process and a process in a target BSC becomes a target process and this depending on the role of a BSC. Each process has a unique identifier in each a BSC.
In
It can be understood that a source process and a target process can handle more than one call. For instance, call 26 (call A) and call 27 (call B) are both handled by source process 24 at the source BSC 20 and are handed off to the target BSC 30 and more particularly the target process 34 and the target process 35. Another example is call 28 (call C), which is handled with source process 25 and which is handed off to target process 36.
Whenever, the MT 10 roams outside the cells covered by RBSs 12, 13 or 14 during a call, the service logic 21 detects that the signal strength between one of the RBS 12, 13 or 14 is decreasing and hands off the MT 10 to a neighbored RBS which can be any of the RBSs 15, 16 and 18 therefore the BSC 20 hands off the MT 10 to the BSC 30. For instance, the MT 10 may be involved in call 26 (call A). The BSC 20 then communicates with the BSC 30 via an A7 interface 50 for establishing a path for call 26 and for sending/receiving messages.
Reference is now made to
In a distributed architecture, a source and a target BSCs may have several paths on an A7 interface if they have distributed process handling. As a consequence, each call may have its associated path. Any request associated to the same call must specify its path or its endpoints (Source ID and Target ID) in an A7 message. For example, path 53 is established for call 27 and path 54 for call 28. Calls 27 and 28 involve other MTs (not shown) in the telecommunication network 100.
Alternatively, the Source ID 210 and Target ID 225 can be inserted in a field of an A7 Originating identifier (A7 Originating ID) (not shown) or an A7 Destination identifier (A7 Destination ID) (not shown). The A7 Originating ID may be further sent from the target BSC 30 to the source BSC 20 and the Destination ID may be further sent from the source BSC 20 to the target BSC 30.
At step 260, the service logic 21 at the source BSC 20 processes the A7 Handoff response message 240 and stores in the memory 22 the Source ID 210 and Target ID 225 associated with call 26 (step 270). The source BSC 20 further includes the Source ID 210 in any subsequent A7 messages that needs to be sent to the target BSC 30. On the other hand, the target BSC 30 includes the Target ID 225 in any subsequent A7 messages related to the same call 26 that needs to be sent to the source BSC 20.
Advantageously, all subsequent messages for the same call 26 or for any call handled by the source BSC 20 or the target BSC 30 must contain a Source ID or a Target ID so they can be routed to the process that handles the call. This includes any future A7 message for an already established call with an established path. This is done in a way to allow the target process and the source process to handle all requests messages for the same call. Consequently, sending the Source ID 210 to the target BSC 30 and the Target ID 225 to the source BSC 20 increases the capacity of both BSCs (number of soft handoff calls) and set-up rate and minimize the number of lost soft handoff during a hardware or software failure.
A failure may happen at one of the source BSC 20 or the target BSC 30 for any reason such as software or hardware failure affecting a target process or a source process. Consequently, in case of a failure, all calls associated with a failed path can be dropped without affecting other calls that are set up on other paths. For instance, if a failure occurs at the target process 34, only calls handled by target process 34 need to be dropped.
In particular, if a failure occurs at one of the processes handling calls either on a source or target BSC, a message such as an A7 Reset message can be sent to a remote BSC for tearing down calls associated to a path. Reference is now made to
For instance, a failure has occurred at source process 24, which handles call 26 and call 27. In this example, the service logic 21 detects that a failure occurred at the source process 24 (step 305). The service logic 21 then sends to the target BSC 30 a Source ID 210=1 that identifies source process 24 in an A7 reset message 335 for tearing down the calls handled by source process 24 (calls 26 and 27). At step 337, the source process 24 does not send messages related to the calls until it receives a confirmation that the calls are dropped at the target BSC 30. At step 315, the service logic 31 processes the reset message 335. The service logic 31 further sends to its target processes an indication 340 that Source ID 210=1 (source process 24) has failed and that all associated calls should be dropped (step 320). The target processes 34, 35 and 36 each accesses their memory for retrieving the calls associated with Source ID 210=1 (step 325).
At step 330, the appropriate target processes drop the calls associated with failed Source ID 210=1 (source process 24). More particularly, call 26 is dropped at the target process 34 and call 27 is dropped at target process 35. At step 340, target processes 34 and 35 send a confirmation 342 to the service logic 31 and therefore the source BSC 20 for indicating that the calls handled by the failed source process 24 have been dropped. Consequently, the target BSC 30 sends an A7 reset response 345 to the source BSC 20 for indicating that the calls have been dropped. At step 350, the service logic 21 sends a confirmation 348 to the failed source process 24 for informing the source BSC 20 that the calls handled by the source process 24 have been dropped at the target BSC 30.
Alternatively, a failure may occur at the target BSC 30. Reference is now made to
For instance, a failure has occurred at target process 35, which handles call 27. In this example, the service logic 31 detects that a failure occurred at the target process 35 (step 405). The service logic 31 then sends to the source BSC 20 a Target ID 225=2 that identifies target process 35 in an A7 reset message 435 for tearing down the call handled by the target process 35 (call 27). At step 437, the target process 35 does not send messages related to the calls until it receives a confirmation that the calls are dropped at the target BSC 30. At step 415, the service logic 31 processes the reset message 435. The service logic 21 further sends to its source processes an indication 440 that Target ID 225=2 (target process 35) has failed and that all associated calls should be dropped (step 420). The source processes 24 and 25 each accesses their memory for retrieving the calls associated with Target ID 225=2 (step 425).
At step 430, the appropriate source processes drop the calls associated with failed Target ID 225=2 (target process 35). More particularly, call 27 is dropped at the source process 24. At step 440, source process 25 sends a confirmation 442 to the service logic 21 and therefore the source BSC 20 for indicating that the calls handled by the failed target process 35 have been dropped. Consequently, the source BSC 20 sends an A7 reset response 445 to the target BSC 30. At step 450, the service logic 31 sends a confirmation 448 to the failed target process 35 for informing the target BSC 30 that the calls handled by the target process 35 have been dropped at the source BSC 20.
It can be understood that some messages and therefore some parameters sent from the MT 10 to the telecommunication network 100 and vice versa are not mentioned nor described for clarity reasons. Also some messages and therefore some parameters sent between network elements in the telecommunication network 100 are omitted for clarity reasons. It should also be understood that
Although several preferred embodiments of the present invention have 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 embodiments 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.
