Routing based on transport utilizationTechnical Field
The present invention relates generally to a method of integrating routing between a pool of network nodes and radio access network nodes in GSM and UMTS telecommunications systems. In particular, the routing is based on utilization of the transport facilities between the pool of integrated network nodes and the radio access network nodes.
Background
An MSC pool is defined as a pool of MSC/VLR nodes linked to a plurality of RAN nodes. In the GSM standard, the RAN node is referred to as BSC node, whereas in the WCDMA standard, the RAN node is referred to as RNC node. The invention is applicable to both GSM and WCDMA systems, but the following description relates only to GSM systems. Each BSC is connected to each MSC/VLR in the pool of MSC/VLRs.
In [1], a scheme with a pool consisting of integrated core network nodes MSC/VLR has been selected and specified. By limiting the impact of MSC/VLR node outages, the concept of pooling the core network has been proposed as a way to ease the scalability of the core network and to increase the availability of services in the core network.
When more capacity is needed, additional MSC/VLR nodes can be added to the pool without increasing the traffic for location updates and inter-MSC handovers. The MS will register with the same MSC/VLR node as long as the mobile station is located within the radio network associated with the MSC/VLR pool.
Between the BSC and MSC/VLR nodes, terrestrial transmission resources are required in order to convey the traffic channels. The traffic channel may be used for voice calls or circuit switched data calls, for example.
The radio network controlled by the BSC node will generate speech calls etc. specific traffic and in order to match this traffic a number of terrestrial transmission resources need to be configured between the BSC and the MSC node. The amount of terrestrial transmission resources required depends on a number of factors such as requirements regarding the probability of blocking at call setup (during busy hours) and the estimated amount of busy hour traffic.
A BSC node connected to the pooled core network would require multiple terrestrial transmission resources for each MSC in the MSC pool. Since it is the MSC node that controls the terrestrial transmission resource allocation, there will be a terrestrial transmission resource pool for each BSC-MSC connection.
Remember that each BSC node is connected to each MSC/VLR node in the MSC/VLR pool. It is also remembered that when an MS registers its presence in the system, it will register its presence in an MSC/VLR node in the core network. If the MS performs registration in the special MSC pool for the first time, the MSC/VLR node is selected from the MSC/VLR nodes in the pool; in all other cases, registration will be performed with the MSC/VLR in which the MS is currently registered.
Since it is the MSC node that allocates terrestrial transmission resources during call setup, it may be the case that call setup fails due to terrestrial resource shortage between the BSC and a particular MSC. Subsequently, a shortage of terrestrial resources is detected, and the MSC node will terminate the call setup and request the BSC node to release the radio resources allocated during the early phase of the call setup.
As the traffic load in the system increases, the transport facilities between the MSC pool and the BSC nodes will become increasingly heavily loaded and eventually no or only a small amount of transport facilities will be available for the call. If the MS makes a call under these circumstances, the call will be rejected. This situation is of course severe in itself, but not too severe since the probability of finding unoccupied transmissions elsewhere in the system under load is low, assuming MSC pool load balancing.
It is assumed that the transport facilities between the individual BSC nodes and the MSC pool fail significantly and stop functioning. Further, it is assumed that the traffic load is low. If the MS makes a call under these circumstances, the call will be rejected as no transport facilities are available between the BSC node and the MSC that allocates the transport resources. This situation is referred to hereinafter as the "local shortage problem" and is serious because transmission facilities are available elsewhere in the system. Such unoccupied transport facilities will exist between the BSC node and other pooled MSCs in addition to the MSC currently registering the MS.
Assuming that there is a predetermined traffic load, it can be seen that if the MSC node is pooled in the above-described manner, the amount of transmission facilities required to handle the traffic load will increase compared to the case where the MSC node is not pooled. The pooling itself will therefore increase the demand on the transport facilities.
Disclosure of Invention
The present invention addresses the problems associated with mobile originated call failures due to "local" shortages of terrestrial resources and also addresses the problem of increased terrestrial resource demand due to the introduction of MSCs in the pool concept.
In a broad aspect, the "local" shortage problem is solved according to the present invention if the BSC node checks the terrestrial resource situation before sending the call setup service request to the MSC. This is possible because the BSC knows the terrestrial resources occupied between the BSC and a particular MSC node. If all or almost all terrestrial resources are occupied between the BSC and the MSC, the BSC routes the call setup service request to another MSC node in the MSC pool, which has available idle terrestrial transmission resources for the requested service.
By performing the inventive check, i.e. checking for available terrestrial resources already in the BSC node, the BSC node may view terrestrial resources from the BSC node towards the MSC nodes in the pool as one large terrestrial resource pool. This means that a part of the increased ground resource requirement is unnecessary. More specifically, terrestrial resources required for mobile originated calls may be reduced. The terrestrial resources required to terminate the call are not affected by the present invention.
The invention also relates to a BSC node and a telecommunication system having a BSC node, the BSC node being provided with an MSC allocation algorithm cooperating with a BSC resource handler for selecting an MSC in a pool having free terrestrial transmission resources available.
One feature of the present invention relates to the case when no or only a small amount of resources are free to be available for the serving MSC. The service request will in this case include a TMSI value. At the first call attempt initiated by the user of the MS, the BSC selects another MSC in the pool, hereinafter referred to as the second MSC, that is different from the MSC in which the MS is registered, and forwards the service request to the second MSC. Since the MS is not registered with the second MSC, the second MSC cannot recognize it and initiates a new procedure requesting the MS to identify itself. The MS sends its IMSI value to the second MSC. The second MSC checks its list and finds that it cannot serve the MS with the indicated IMSI value and therefore rejects the call. Receipt of the call rejection triggers the MS to automatically begin running a location update procedure with the second MSC, with the result that the second MSC registers the presence of the MS (identified by its IMSI value) in its associated VLR. In addition, the second MSC assigns a TMSI value to the MS. The allocated TMSI value is communicated to the MS and the second MSC associates the allocated TMSI value with the IMSI value of the MS and stores this relationship in its table. The next time the MS makes a call attempt, it will be served by a second MSC, which preferably has idle terrestrial transmission resources for the call.
In yet another embodiment of the present invention, the BSC, upon receiving a location update message containing the IMSI value of the MS, checks the available terrestrial transmission resources among the MSC nodes in the MSC pool and selects an MSC that has sufficient such resources free. The BSC then routes the location update to the selected MSC where the MS now registers its presence and receives the TMSI value. If the time interval between the location update and the next call setup attempt is not too long, it is preferable that some of these idle resources remain idle at the selected MSC so that the call setup is successful. If the time interval is rather short, the chance of call setup success is high.
Drawings
Figure 1 is a block diagram illustrating the MSC pool concept,
figure 2 is a signaling diagram illustrating signaling between an MS and an MSC when the MS is registered in an MSC/VLR node of a core network,
figure 3 is a signaling diagram illustrating call setup according to the prior art,
figure 4 is a block and signalling diagram showing the combination of the first part of call setup according to the invention in case no terrestrial transmission resources are available,
figure 5 is a block and signalling diagram showing the combination of the second part of the call set-up in the case where no terrestrial resources are available,
figure 6 is a signaling diagram illustrating a complete call setup without terrestrial transmission resources available,
figure 7 is a block diagram of a BSC according to the invention,
FIG. 8 is a flow chart of a location update algorithm, an
Figure 9 is a flow chart of a call setup routing algorithm.
In the following, the prior art and the present invention will be described with reference to the circuit switched domain of an evolved GSM telecommunication system.
Detailed description of the prior art
Fig. 1 discloses a pool 1 consisting of a pair of integrated MSC node 2 and VLR node 3. Each integrated node MSC/VLR is connected to a plurality of BSC nodes 4 via terrestrial transmission resources, which typically include signalling links and links for traffic channel transmission. In terrestrial transmission resources, only transmission links are the subject of the present invention and these will be indicated by reference numeral 5.
Each MSC includes a resource processor 6 that processes terrestrial transmission resources to each respective BSC. Each BSC also comprises a respective resource processor 7 which handles terrestrial transmission resources to each respective integrated MSC/VLR node.
The MSC/VLR is part of the core network and the BSC is part of the radio network. The term Mobile Station (MS) is used to designate a mobile device in the GSM system (in the WCDMA system the corresponding term UE). In fig. 1, the MS is denoted by reference numeral 8.
An MS registers its presence in the GSM system by performing a location update procedure with the MSC in which the MS is registered in many different situations, for example when it is switched on and thus becomes active, or when an active MS moves from an area without radio coverage into an area with radio coverage. If the MS is not registered before, then MSC/VLR node is selected from MSC/VLR nodes in MSC pool. The signaling between the MS and the MSC/VLR is performed via a BSC node called serving BSC. As shown, any BSC may be connected to any MSC in the pool.
The integrated MSC/VLR node pool serves a pool area, not shown, in which the MS can roam but is still registered in the same MSC/VLR.
The right part of fig. 1 discloses the case of an unfused MSC connected to a private BSC.
Fig. 2 schematically shows the registration process. Only those parts of the registration process that are important for understanding the present invention will be described.
When the MS is switched on, it establishes a radio connection with a nearby radio base station RBS, not shown, and sends a registration message 9 to it. The registration message contains the IMSI value of the MS. The RBS, not shown, signals a registration message to the BSC serving the RBS. The BSC in turn processes the message and forwards a registration message 10 to the MSC in the pool. The MSC receiving this message is the MSC serving the particular MS. As will be further described below.
Each MSC in pool 1 has a pool of local TMSI numbers, not shown. The TMSI number is specific to each individual MSC.
The TMSI number is a temporary identifier of 4 octets in length that is assigned to the MS when the MS registers in the MSC/VLR. The use of TMSI avoids the sending of IMSI numbers over the air interface, improving user privacy. Once the TMSI has been assigned to the MS, the MS uses the TMSI to identify itself in the network. The use of TMSI within the pool of integrated MSC/VLR nodes is necessary.
The TMSI concept is therefore not modified by the introduction of the MSC/VLR pool, but the TMSI structure is modified to include more information: a Network Resource Identifier (NRI). The NRI field consists of 0 to 10 bits encoded within the TMSI and it is required to define a unique MSC/VLR within the MSC pool. At least one NRI value is to be assigned to an MSC/VLR in the MSC pool. The TMSI number assigned by a particular MSC/VLR node will include the NRI field associated with the assigned MSC/VLR node.
The routing function in the BSC routes messages originated by the MS to the MSC in which the MS is registered, the so-called serving MSC, using the NRI field in the TMSI structure.
In response to receipt of the registration message 10, the MSC registers the IMSI of the MS in its registration table and assigns a TMSI number to the MS indicating the relationship between the received IMSI number and the assigned TMSI number. Thereafter, the MSC sends a registration confirmation message 11 including the TMSI number to the MS. This ends the registration process. The IMSI number is globally unique, while the TMSI number is locally unique.
It should be noted that the MS will repeat the registration process periodically and also when the MS roams into a new location area. If the MS received the TMSI value earlier, and the registration procedure was previously performed, this TMSI value, rather than the IMSI value, is used as the identity in subsequent registration activities.
When a user of the MS wants to make a call, he/she dials the number of the desired destination and presses the off-hook button on the MS. This triggers the MS to convey a service request message 12 to the BSC, which includes the TMSI number assigned to the MS. The service request is often referred to as a call setup or call setup attempt. This message is received at the serving BSC, which processes the message and forwards the processed service request 13 containing the TMSI to the serving MSC. Upon receipt of the service request message, the MSC compares the TMSI numbered therein with its registry to find the MS that is engaged in the call. It then retrieves the corresponding subscriber data from its VLR and takes appropriate measures for call setup, including transmission resource allocation, terrestrial and radio constraints for the call.
Fig. 3 discloses call setup when terrestrial transmission resources are available as shown in the upper part of the figure and call setup when no terrestrial transmission resources are available as shown in the lower part of the figure.
When the MSC receives the processed service request with TMSI 13, it checks by its resource handler whether there are any free terrestrial transmission resources to the serving BSC by sending an occupancy request message 14 to its terrestrial transmission resource handler. If there are idle resources, the resource handler will allocate idle resources for the service request and return an occupation request acknowledgement message 15 including the CIC value identifying the link and slot on which the call will be transmitted. The MSC composes an assignment request message 16 for the BSC and includes therein the assigned CIC value.
Upon receiving the assignment request message, the BSC sends an occupation request message 17 to its terrestrial transport resource handler 7. The BSC terrestrial transmission resource processor knows the total amount of terrestrial resources existing between the BSC and the MSC in the MSC pool, and keeps continuous counting of occupied terrestrial transmission resources. Accordingly, there is a one-to-one correspondence between resources reserved by the MSC and resources occupied by the BSC. The BSC will thus be aware of the terrestrial transmission resources allocated by the MSC and the terrestrial transmission resources that are idle.
The resource handler 7, upon receiving the occupation request message 17, checks its table to see if there are free resources available. In this case, it is assumed that there are free resources and the resource handler occupies the circuitry indicated by the CIC value in the occupation request. The resource handler returns a size request acknowledge message 18 including the CIC value to the BSC.
The BSC will in turn compose an assignment command message 19. An assignment command message is sent to the MS and includes information that enables the MS to establish a dedicated radio channel to the BSC. Note that it is the BSC node that allocates the radio channels required for the call. This concludes the successful call setup.
If the MSC resource processor finds that there are no idle terrestrial transmission resources, it will respond to the camp request message 14 by returning a camp request negative acknowledgement signal 20 to the MSC. The MSC composes a clear order message 21 and sends it to the BSC, and the BSC sends a channel release message 22 to the MS. The MS aborts the setup procedure. The setup request is thus denied without success.
The user must make a new call if he/she still needs to communicate, i.e. he/she must enter the digits again. If he/she does this, the same BSC will capture the connection request and the BSC will forward the request to the same MSC as in the example. If terrestrial transmission resources between the BSC and said MSC are faulty, e.g. the transmission link is disconnected, or if a re-established service request is made within a short time, e.g. within a few minutes, after receiving the channel release message, no terrestrial resources are available, or most likely the resources have not been cleared and the re-established service request is rejected.
So far a call set-up according to the prior art has been described.
Detailed Description
The present invention will now be described with reference to fig. 4-6. Assume that the pool includes a plurality of MSC/VLR nodes labeled MSC 1, MSC 2. Each MSC includes a logical entity labeled as a call setup processor 40 and each BSC includes a logical entity labeled as a call setup processor 41. The call set-up processors 40 and 41 communicate via a signalling link 5 (see figure 1).
The invention will be described in connection with MSC 2. However, it should be understood that the following process is performed in any combination of the MSC/VLR node and the BSC node.
In fig. 4, it is assumed that there are no idle terrestrial transmission resources for traffic channel (i.e., voice call) transmissions between the serving BSC and the MSC serving the MS, in this case MSC 1. The MS sends a normal service request message 12 to the BSC serving it. The BSC extracts the TMSI number included in the service request message and knows the serving MSC (the MSC in which the MS is registered), in the example MSC 1. The BSC will start running a checking procedure by its resource handler 7 to find out if terrestrial transmission resources are available for the serving MSC 1 instead of forwarding the request immediately to the MSC 1 as in fig. 3 at arrow 13. To do this, the BSC sends a resource check message 23 to its resource handler. The resource check is thus done before the service request is routed to the MSC. The resource handler checks the resources of MSC 1 in its table and responds to the resource check message by a resource check response message 24 comprising the amount of idle terrestrial transmission resources for all MSCs in the MSC pool, including MSC 1. The BSC has a call set-up routing algorithm (shown in fig. 9) designed such that when the resource check response message is negative, i.e. there are no or few idle terrestrial transmission resources for the shown MSC (in this example MSC 1), it routes the service request to another pooled MSC with available idle terrestrial transmission resources according to the resource check response message. In this example, assume that the BSC routes a "complete layer 3 information signal" 25 to the MSC2, this signal 25 including the service request 12.
Upon receiving the rerouted service request 12 containing the TMSI of the MS in MSC 1, MSC2 checks its TMSI table to determine the IMSI identity of the MS delivering the request. It does not find a TMSI number that matches the received TMSI. MSC2 therefore cannot grant the request. Instead, it responds to the service request by sending an identity request message 26 to the BSC, which forwards the message transparently to the MS. This process conforms to the layer 3 protocol of reference [2 ].
The MS, upon receiving the identity request message, is triggered to send an identity response 27 containing the IMSI of the MS. The MS does this automatically and its user does not need to take steps to convey this message. The identity response is sent to MSC 2. MSC2 detects that the IMSI is not registered in its VLR and this triggers MSC2 to send a service reject message 28 to the MS.
Receipt of the service reject message triggers the MS to initiate a location update procedure by sending a location update message 29 containing its IMSI to the BSC. The BSC has a location update routing algorithm (shown in fig. 8) designed such that on receipt of a location update message containing an IMSI, the algorithm will distribute the location update message 29 to all nodes in the MSC pool. In this example we assume that the BSC has chosen to route the location update message 29 to the MSC2 as indicated by arrow 30. The location update message is received by MSC2, which registers the MS in its VLR and assigns a TMSI value to it. The MSC2 replies to the MS with a normal registration acknowledge message 11, which is not shown in fig. 4 for clarity. This concludes the unsuccessful service request. The result of the procedure described in connection with fig. 4 is that the first service request 12 initiated by the user is rejected by the MSC 1 due to lack of resources, service rejection triggers the MS to perform a location update, and the result of the location update procedure is that the MS is registered and assigned a TMSI number in the MSC 2.
Refer to fig. 5. It is assumed that the procedure of fig. 4 has been performed and that MSC2 has idle terrestrial transmission resources. Assume that the user needs to contact the user of the telephone number he/she entered in the rejected first setup request. The user dials the same number a second time, thereby initiating a second service request message 12 as shown in figure 5. The BSC receives the message, extracts from it that the MS is registered in MSC2, and performs the check according to the invention by sending a resource check message 31 to its resource handler. The resource processor returns the amount of idle terrestrial transmission resources. Since there are idle resources for MSC2, the resource check response message 32 is positive and the routing algorithm in the BSC sends the service request with TMSI to MSC 2. The TMSI number is recognised by the MSC2 and the MSC2 sends a size request 14 to its resource handler, which responds with an occupancy request acknowledgement message 15 containing a CIC value identifying the allocated terrestrial transmission resource. The signalling is then similar to that shown in the upper part of figure 3 and messages 16-19 are sent. The second setup request ends successfully when the MS receives the assignment command 19.
For the non-core network pooling case shown on the right side of fig. 1, the above inventive check is not performed, since the BSC is always connected to only one MSC node.
In fig. 6, the signaling sequences described in connection with fig. 4 and 5 are merged and shown in a diagram showing the nodes involved in the signaling in the horizontal direction and the time in the vertical direction. The reference numerals used for the signaling arrows in fig. 6 are not consecutive, in accordance with the requirement that like reference numerals in the figures apply to like items. The events represented by arrows in the signaling diagrams of fig. 2, 3 and 6 are shown in chronological order from the top to the bottom of the respective diagrams.
In fig. 7, a block diagram of an entity that characterizes the BSC in accordance with the present invention is shown. The call set-up processor 41 cooperates with a logical entity called checking function means 42 for checking the terrestrial transmission resources to each MSC node in the pool. These resources are shown symbolically in table 43. The call setup processor also cooperates with the routing algorithm 44 described above for MSC assignment. The resource processor 7 cooperates with a plurality of logical transmission means 45 representing the terrestrial transmission resources 5. Each logical transmission means is associated with a time slot on the transmission link. The time slots are identified by CIC values.
In fig. 8, the location update algorithm 46 in the BSC is designed such that, upon receipt of a location update message with an IMSI (block 47), the MS identity contained in the message is checked (block 48). If the TMSI value is retrieved, indicating that the MS is already registered with the serving MSC, a location update message is sent to the serving MSC as indicated by the NRI value contained in the TMSI parameter (block 49). If the TMSI value is not included in the location update message and the IMSI value is present, the BSC checks with its resource processor to find MSCs with sufficient available idle terrestrial resources and selects one MSC (block 50). The BSC then sends a location update message to the selected MSC (block 51). The selected MSC will return the TMSI value to the MS and register the MS in its associated VLR, but this is not shown. The selected MSC is thus the MSC serving the MS. Preferably, the MSC does not lack terrestrial resources and the call setup from the MS will then succeed. The location update algorithm 46 is not shown in fig. 6, but it starts at a circle 52 close to the arrow 29 and ends at the end of the arrow 30 in the BSC node.
As previously mentioned, the location update algorithm may be designed such that receiving a location update with the IMSI at the BSC will cause the algorithm to select any MSC node in the pool. The selected MSC node will then assign a TMSI value to the MS and signal the assigned TMSI value to the MS. This ends the unsuccessful service request. The next time the MS makes a call setup attempt, the call setup algorithm in the BSC node performs a check through the resource processor to find out whether the serving MSC has sufficient idle terrestrial resources free for the call.
The location update routing algorithm may include a list containing MSC nodes having available idle terrestrial transmission resources. In this case, information about free resources needs to be stored in two locations, i.e. in the resource handler and in the location update algorithm. Alternatively, the location update routing algorithm interacts with the resource processor to retrieve information about the idle resources, which is stored by the resource processor. The location update message with the IMSI is thus routed to the MSC node with sufficient idle terrestrial resources.
A call setup routing algorithm 53 for routing service requests containing TMSI values is shown in fig. 9 and is executed in the BSC. A service request containing the TMSI is received by the BSC (block 54). The BSC checks through its resource processor to see if there are idle terrestrial transmission resources to the serving MSC node free (block 55). If so, the algorithm sends a service request that is forwarded to it (block 56). If no such resources are available, the check at the resource handler will provide as a result MSC nodes in the pool having sufficient idle resources available and the algorithm selects one of them (block 57). The service request is forwarded to the selected MSC node (block 58).
Although the invention is described with reference to the GSM system, it will be appreciated that the invention can equally well be used in WCDMA systems.
The abbreviations and references used in the specification are listed in table 1 below.
TABLE 1
List of abbreviations
3GPP third generation partnership project
BSC base station controller
CN core network
CIC circuit identification code
GPRS general packet radio system
GSM Global System for Mobile communications, formerly group-specific Mobile communicators
System for making
IMSI international mobile subscriber identity
LA location area
MS mobile station
MSC mobile switching center
NRI network resource identifier
PROM programmable read-only memory
RAN radio access network
RNC radio network controller
SGSN service GPRS node
TMSI temporary mobile subscriber identity code
UT user terminal
UMTS universal mobile telecommunications system
VLR visiting location register
Reference to the literature
[1]3GPP technical specification TS 23.236V5(2003-03)
[2]3GPP technical specification TS 24.008V6(2004-06)