Routing procedure for a communication system

ROUTING PROCEDURE FOR A COMMUNICATION SYSTEM

This application claims priority to U.S. Provisional Patent Application No. 60/447,752, entitled "Routing Procedure for a Communication system," filed on February 19, 2003, which is incorporated herein by reference.

The present invention relates generally to a communication system in which a plurality of core networks (CNs) share a common radio access network (RAN). More particularly, the invention relates to a routing procedure in a system of this type. In general, since core networks are operated by different operators, the system in this respect is called a Multi-Operator Core Network (MOCN). Routing in general herein relates to the process during which the RAN selects a core network for a user terminal in response to an initial message from a user terminal.

3 Expensive licenses for 3G mobile telephony networks (3G), along with high costs for deployment of 3G network infrastructures, require innovative strategies in the development of new network infrastructures. For network operators, an effective way to reduce the investment cost and risk of such development is to share the new network infrastructure with other network operators. In many countries, authorities have become sympathetic to network sharing, allowing network operators to form alliances to share part or the entire network, provided competition is not hampered.

In the current dynamic economic market, these developments allow operators to collaborate more cooperatively and constructively. This trend also emphasizes the need for tools that enable the implementation of varying degrees of network sharing.

One way to share a network infrastructure is a solution in which several operators share a common radio access network. In such a network, a common radio access network is connected to several core networks operated by different operators. This concept is called MultiOperator Core Network (MOCN). Despite some operators, a user may perceive a network as a single network according to his/her terminal communication capacity, and the identity of this network is broadcast by the radio access network.

From the operator's point of view, the advantages of the MOCN infrastructure are, for example:

MOCN allows independent dimensioning of the core network;

A charging entity is located in each operator's core network;

MOCN allows complete control of the services provided and also allows for good control of the quality of service.

In the MOCN network, the radio access network sends an initial message from the user to one of the core networks. If the core network receiving the initial message from the radio access network cannot service the user, the core network notifies the radio access network accordingly, and then the radio access network sends the initial message to another core network. , and check whether it can be serviced by the core network.

One problem with current MOCNs relates to denial of service in situations where neither core network (ie, operator) is able to provide service to a particular subscriber. In this situation, the final core network to which the initial message, which is a non-access stratum (NAS) message, is rerouted, knows that the message has already been routed to all other core networks of the MOCN and that no other core network can service the subscriber. do not know. Therefore, no core network capable of serving can be found, but there is a possibility that the final core network will initiate a new rerouting procedure. Alternatively, upon receipt of a denial of service from the ultimate core network, the radio access network, as no mechanism currently exists to handle this kind of situation in the radio access network, the radio access network may Release the signaling connection to the terminal. Therefore, after entering Mobility Management-Idle (MM-IDLE) or Packet Mobility Management-Idle (PMM-IDLE) state, the user starts the whole procedure again.

Generally, the problem arises when a subscriber tries to register with the network. Therefore, the initial message from the terminal is also called "registration request" in this situation.

It is an object of the present invention to propose a solution capable of avoiding the aforementioned disadvantages.

In one embodiment of the present invention, we present a mechanism by which the MOCN routing procedure, particularly the rejection of registration request, can be implemented in a controlled manner to avoid unnecessary rerouting and registration attempts.

In another embodiment of the present invention, potential serving Core Networks (ie, core networks likely to service registration requests) are determined in the radio access network. Then, the radio access network sends the request to a first one of the core networks. If the first core network indicates that it cannot service the request, the radio access network generally forwards the request to a second one of the potential serving core networks. Thus, the radio access network selects one potential serving core network at a time, sends the request to the selected core network, and waits for a response before selecting a new core network. If one of the core networks accepts the request, the routing process terminates and service continues in a normal manner, ie the user is served as in a single operator network.

In one example, the radio access network knows the status of the core network to which the request has already been sent and is still available. At the same time, the radio access network monitors whether at least one predetermined criterion is met. If met, the radio access network notifies the selected core network that the registration request must be processed normally, ie as in a single operator network. The predetermined criterion may be a situation in which no core network is available other than the currently selected core network for the registration request. However, the notification may also be triggered if a certain combination of two or more predetermined criteria is met. For example, the radio access network receives and analyzes information from outside the RAN (eg, status information from one or more other core networks), by which the RAN determines whether the currently selected core network should service the registration request. do.

Accordingly, in one embodiment, the present invention includes a method for performing routing in a communication system comprising a radio access network and a plurality of core networks connected to the radio access network. The method includes receiving a registration request in a radio access network, selecting a core network for the registration request, and sending the request to the selected core network. In response to at least one predetermined criterion being met, the selected core network is notified that a registration request should be served by the selected core network.

In another embodiment, the present invention includes a system for performing routing in a radio access network. The radio access network may be connected to a plurality of core networks. The system includes first interface means for receiving a registration request, selecting means for selecting a core network for the registration request, and transmitting means for sending the registration request to the selected core network. The monitoring means monitors whether at least one predetermined criterion is met. The notification means, in response to the monitoring means, notifies the selected core network that a registration request must be performed by the selected core network.

Another embodiment of the present invention includes a core network component for a communication network. The communication network includes, for example, a radio access network and a plurality of core networks. The core network component includes first interface means for receiving a registration request from the radio access network, and determining means for determining whether the registration request should be served by the core network to which the core network component belongs in response to the first interface means. includes The transmitting means sends, in response to the determining means, a rerouting command to the radio access network. The reroute command indicates that the registration request should be routed to another core network. The first interface means is configured to receive a notification notifying whether a particular registration request should be serviced by the core network to which the core network element belongs.

Another embodiment of the present invention includes a mechanism to enable the MOCN to act as a single network from a terminal point of view, for example with respect to roaming. That is, the present invention, for example, allows the MOCN to behave consistently in all situations, so that rerouting can be hidden from the terminal side, and from the terminal point of view, the MOCN can be guaranteed to appear as a single network in all situations. .

In another embodiment of the present invention, a cause value may be carried in the rerouting command sent from the core network. The reason value indicates why in this case the relevant core network is unable to service the subscriber. The reason value(s) received from the core networks are transmitted to the next core network in connection with a new routing attempt. In this way, the core network knows why the registration request was previously rejected, so that the user can also be informed of the reason.

Other features and advantages of the present invention will become apparent upon reference to the following detailed description and accompanying drawings.

In the following, the present invention and preferred embodiments thereof will be described in detail with reference to the examples shown in FIGS. 1 to 9 of the accompanying drawings.

1 shows the network structure underlying the MOCN according to the present invention;

2 shows an example of a MOCN network;

3 shows message exchange in a first embodiment of the present invention;

4 shows message exchange in a second embodiment of the present invention;

5 shows message exchange in a third embodiment of the present invention;

6 is a flowchart illustrating the operation of a radio network controller;

7 is a schematic representation of a radio network controller;

8 is a flowchart illustrating the operation of a core network component; and

9 is a schematic representation of a core network component in communication with a radio network controller.

In the following, the present invention and preferred embodiments thereof are described using terms and concepts commonly used in connection with a UMTS (Universal Mobile Communication System) environment. However, it should be recognized that the present invention is not limited to a specific technology such as UMTS, and can be applied to all MOCN networks.

A MOCN network is shown in conjunction with FIGS. 1 and 2 . 1 shows a general UMTS structure. As is known, a UMTS network comprises three interactive areas: User Equipment (UE), Radio Access Network (RAN), and Core Network (CN). In the figure, a core network is denoted by reference numeral 120 , a radio access network (such as UTRAN, Universal Mobile Telecommunication System Terrestrial Radio Access Network) is denoted by reference numeral 110 , and user equipment is connected to a plurality of mobile terminals 100 . is displayed In this context, the term "mobile terminal" refers to any terminal device (mobile equipment with a subscriber identity module) that is controllable by a user and capable of communicating with a radio access network. The mobile terminal may be connected to the Node B element 111, which is a physical unit for wireless transmission/reception in a cellular network, via the Uu air interface. In addition to the Node B elements, the radio access network also includes a radio network controller (RNC) 112 , each of which may be connected to a set of Node B elements via an Iu interface. Each radio network controller is responsible for controlling the radio resources within that controller's domain (ie, a set of Node B elements connected to the controller). The radio network controller 112 connected to the core network via the Iu interface forms a service access point for the services that the RAN provides to the core network 120 .

The core network can be divided into a circuit-switched (CS) and a packet-switched (PS) domain, wherein the former is in charge of the conventional circuit-switched service and the latter is in charge of the packet-switched service. The circuit switched area may be connected to the radio access network through a Mobile Services Switching Center (MSC) 121 and the packet switched area through a Serving GPRS Support Node (SGSN) 123 .

The MSC may include a Visitor Location Register (VLR), a database that holds a copy of the mobile terminal's location information and the visiting user's service profile. The MSC/VLR may be coupled to an external circuit switched network 130 , such as Public Switched Telephone Networks (PSTN), via a gateway MSC 122 .

The SGSN may be connected to a Gateway GPRS Support Node (GGSN) 124 , which connects the core network to an external packet switched network 140 such as the Internet. SGSN and GGSN have functions similar to those of MSC/VLR and GMSC, respectively, except for those related to packet switched services. Some network elements of the core network, such as home location register (HLR) 125, are shared by both regions.

A network as shown in FIG. 1 is shared by several operators, for example as shown in FIG. 2 . In this case, the common RAN 210 may be shared by three different operators A, B, and C, each operator having their own core network (core networks 220,221, and 222, respectively). operate All core networks can be connected to the same RNC of the shared RAN. In the network sharing scenario of FIG. 2 , the shared RAN 210 broadcasts a Public Land Mobile Network (PLMN) identity "X" to the terminal, and the terminal may not see the identities of different core network operators according to its capacity. can However, operators may have dedicated radio frequencies, and thus operators may transmit their own Mobile Network Codes (MNC) to their dedicated carrier.

As in the network of FIG. 1 , the radio resource control (RRC) handles the signaling on the Uu interface, and the radio access network application (RANAP) handles the signaling on the Iu interface.

Fig. 3 shows a first embodiment of the present invention by showing the exchange of messages between the different entities of Fig. 2; As mentioned above, RRC can be used in UMTS to connect a terminal to a radio access network. Therefore, when the user enters the network, an RRC connection must first be established through the Uu interface (step 300). The terminal then uses an initial direct transfer procedure to convey the initial message to the RAN over the air interface (step 301). The initial message is a non-access stratum (NAS) message that is transparently transmitted to the CN through the RAN. The NAS message is the above-described registration request, which may be, for example, a location update request, a routing area update request, or an attachment message (PS attachment or CS attachment) in relation to registration.

Then, the RNC initiates the initial UE message procedure according to the RANAP protocol, and first sends the NAS message in the initial UE message including the NAS message to the core network 220 of operator A (step 302). Here, it is assumed that the core network 220 cannot service the request, and accordingly, the core network returns a rerouting command to the RNC (step 303). The rerouting command is a message according to the RANAP protocol, and the IE (information element) type of the message indicates that the rerouting command has a problem.

The RNC then selects operator B's core network (here, the core network 221) and repeats the transmission of the NAS message (step 304). It is also assumed here that the core network 221 is also unable to service the request, and accordingly the core network 221 returns a rerouting command to the RNC, as did the CN 220 (step 305). In response to the second rerouting command, the RNC recognizes that only one potential serving core network remains, and repeats the transmission of the NAS message to the core network 222 (step 304). However, since the RNC is aware that the core network is the last available core network capable of servicing the registration request, the RNC indicates in the message that the core network cannot reroute the request. Inserting "no rerouting allowed" information into the message is performed by inserting a reason IE in the initial UE message according to RANAP, wherein the reason IE indicates, for example, "rerouting allowed". Instead of the new reason IE value, the "rerouting not allowed" information may also be carried by a separate new parameter inserted in the message. When the core network receives this message, it recognizes that it should process the message as if no MOCN was included. That is, the core network processes the request as in a normal single operator network, and sends the normal direct transmission message to the RNC, which is a (non-access layer-protocol data unit) NAS-PDU IE directed to the terminal. and a signaling message such as (step 307). The RNC then uses the downlink direct transfer procedure to carry the signaling message to the terminal over the air interface (step 308). In the first embodiment, when sending a registration request to the last available CN, an indication such as a reason IE is inserted in the message.

Figure 4 shows a second embodiment of the present invention by showing the exchange of messages between the different entities of Figure 2; The second embodiment is the same as the first embodiment, except that the reason IE is not used in the initial UE message in the second embodiment. Instead, if the network attempts to reroute the registration request, a separate message is sent by the RNC to the final available core network. This message informs the core network that this rerouting is not allowed. That is, this separate message carries semantically the same information as the Reason IE in the first embodiment. Accordingly, steps 300 to 305 are the same in the above two embodiments. Step 406 of the second embodiment differs from step 306 of the first embodiment in that step 406 does not use a reason IE in the initial UE message. Instead, the RNC sends a rerouting rejection message in response to the rerouting command received from the last available core network (step 408). When the core network receives this message, it also knows that the corresponding request should be processed as if no MOCN was included. Then, steps 409 and 410 correspond to steps 307 and 308, respectively. The rerouting rejection message is a message conforming to the RANAP protocol, and the IE type of this message indicates that rerouting rejection is a problem. 3 and 4, the NAS message is returned to the RNC in the rerouting command (ie, the NAS message is not stored in the RNC). Thus, the rerouting rejection message is the only message type shown in the figure that does not carry a NAS message therein.

In one embodiment of the present invention, the first and second embodiments are combined, so that the "rerouting not allowed" indication of the first embodiment and the rerouting rejection message of the second embodiment are specified for the MOCN. The first embodiment allows the signaling to be optimized, while the second embodiment allows the MOCN to cover some abnormal situations in that rerouting commands are still received from the core network. Accordingly, the first and second embodiments are not exclusive solutions and can also be used at the same time.

In the core network, service may be denied for various reasons. For example, the core network may reject the registration request because of an overload situation in one network, and the other CN may reject the request because it has not entered into a roaming agreement with the subscriber's home network operator. Therefore, it is also possible that the last available core network does not enter into such a roaming agreement, whereby the terminal is not allowed to roam when the request is only temporarily rejected for other reasons such as overload at present in the core network where roaming is allowed. , which is incorrect. Since the information received from the core network where roaming is not allowed in this MOCN is stored in the terminal (U) SIM, which controls the network selection in the terminal, the terminal may no longer attempt to register with the MOCN.

To avoid the above situation, the core network notifies the next attempted core network of the reason the registration request is rejected. This is done by adding a reason value to the rerouting command that indicates why the rerouting occurred. Fig. 5 illustrates this embodiment by showing the exchange of messages between the different entities of Fig. 2; In this embodiment, each rerouting command sent by the core network to the RNC includes a reason value indicating why the core network rejected the request (compare steps 503 and 505). The RNC sends the reason value received from the core network to the next core network in the initial UE message, so that each core network receiving a registration request is responsible for why the request was previously rejected by one or more core networks. Receive information (compare steps 504 and 506). Here, it should be noted that the reason value may be used in the embodiment of FIG. 3 , in the embodiment of FIG. 4 , or in the combined embodiment described above. In the embodiment of Fig. 5, it is assumed that the second embodiment is used and the final CN accepts the registration request.

Each core network uses reason values when processing the request. Although the reason value cannot influence the final decision (acceptance or rejection of service) of a separate core network, the final core network may indicate the correct reason for rejection in the NAS message sent to the terminal via the RNC in each case. can This NAS message may be, for example, location update rejection or routing area update rejection, which the CN sends in a direct transmission message. One or more reason values will then be transmitted to the core network. That is, the core network simply adds its own reason value to the reason value list as shown in FIG. 5, or adds a new reason value based on the reason value(s) received by the core network and its own reason value. defined and only the newly defined reason value can be transmitted to the next CN.

Transmission of the reason value(s) is carried out by, for example, defining a transparent container for CN-to-CN communication for RANAP, which is a conventional transparent container defined for RNC-to-RNC communication. Similar to 'Source RNC to Target RNC Transparent Container' and 'Target RNC to Source RNC Transparent Container' in When the reason value is carried in this container, no change is required in the RNC even if new information is added to this container.

Accordingly, in the present invention, the (UT) RAN tracks which core networks are still available by tracking the core networks that have already received the request. Although these operations may be distributed, they are typically located in a single network element, such as an RNC.

6 is a flowchart illustrating an example of the operation of the RNC, it is assumed that the RNC operates according to the above-described combined embodiment of the present invention. When a registration message is received from the terminal (step 600), the RNC first checks whether the message indicates whether the terminal has already selected a specific PLMN, that is, a core network (step 601). If not, the RNC determines a set of available Core Networks (step 602). Here, it should be noted that the set does not necessarily correspond to the set of core networks connected to the radio access network, since the RNC already knows that one or more core networks cannot service the request for some reason.

The RNC then selects the first core network to which the request is sent, and removes the selected core network from the set of available core networks to prevent the same core network from being selected again (steps 603 and 604). The RNC then checks whether there are any available networks left in the set. If there is, the RNC sends the request to the core network selected in the initial UE message (step 606). If no core networks remain in the set of available core networks, that is, if the selected core network is the last core network capable of servicing the request, the RNC inserts a reason IE in the message, wherein the reason IE is the CN act as a notification indicating that rerouting is not allowed (step 607). If the RNC recognizes that the terminal has selected the serving PLMN, this step may also start directly from step 601 .

The RNC then continues its normal operation, while also monitoring whether a rerouting command is received (step 609), which occurs if the message sent to the core network does not contain the reason IE. If a rerouting command is received, the RNC jumps to step 603 to select a new core network if there is still a core network available (checked in step 610). If the currently selected core network that sent the rerouting command is recognized as the last available core network in this step, a rerouting rejection message is transmitted to that core network (step 611). Also, if no rerouting command is received from the selected core network, the operation proceeds as if the network has only a single core network.

As described above, FIG. 6 shows the operation of the RNC according to the first embodiment of the present invention. In general, the RNC selects a set of available core networks and sends registration requests to these core networks one after the other in a specific order, until either one of the core networks accepts the request or at least one predetermined criterion is met. Start. If the criteria/criteria are met, the RNC notifies the currently selected core network that rerouting is not allowed. In the above embodiments, two separate criteria are used, and when the criteria are met, each criterion triggers the transmission of "rerouting not allowed" information. The first criterion is satisfied when there are no more core networks in the set of available core networks, whereas the second criterion is satisfied if the RNC recognizes that a particular core network has already been selected by the terminal as the serving core network. Other more complex criteria may also be used to trigger the transmission of "rerouting not allowed" information. For example, the RAN may also analyze information received from outside of the RAN to determine whether transmission of "rerouting not allowed" information should be triggered. For example, it may indicate that a particular core network is temporarily unavailable, so that certain criteria may be met when this situation occurs. The above-described combined embodiment is suitable for the following system: if the RNC has already sent a registration request to the second final core network without indicating that rerouting is not permitted, the RNC at the time of notifying that the final core network is unavailable can transmit a rerouting rejection message to the second final core network when the final core network returns a rerouting command.

In general, triggering of a "rerouting not allowed" information transmission requires that one or more predetermined criteria be met. If certain critical criteria are met, the transmission of "reroute not allowed" information is triggered, without the need to analyze the status of other criteria. However, in the case of the above-described second embodiment, the transmission also requires that a certain combination of two or more predetermined criteria be satisfied: if there is no core network available, and the final CN returns a rerouting command, the rerouting rejection message is sent

The RNC may temporarily change the forced delivery of the registration request, so that the RNC does not wait for a rerouting command, and inserts "rerouting disallowed" information in each registration request. That is, the first core network selected by the RNC must service the registration request.

7 is a schematic diagram of the basic elements of an RNC; The heart of the RNC is a switching unit 700, which is connected to the Node B elements (base station) via a first interface 701, to the core network via a second interface 702, and to a third interface ( 703) to other RNCs. The RNC also includes a control unit 704 , a radio resource management unit 705 , and an operation and maintenance unit 706 . The radio resource management unit is responsible for the control of radio resources of Node B elements (base stations) connected to the RNC, and the operation and maintenance unit functions as an interface to network management, allowing the operator to manage and configure the RNC from an external management system. make it possible The above-described functions of the present invention may be performed in a control unit.

8 is a flow diagram illustrating exemplary operation of a core network component in communication with an RNC. As shown in Figure 1, this network element is either MSC/VLR or SGSN. When a registration request is received from the radio access network, the request is processed first and a determination is made as to whether the request can be serviced (steps 801 and 802). If the network element determines that the service can be provided, the process of the registration request continues as if no MOCN was included (step 803). If, on the contrary, the network element determines that the service cannot be provided, then the process continues depending on whether a "reroute not allowed" indication has been received in connection with the request. If the network element sees in step 801 that the radio access network has notified (in reason IE) that rerouting is not allowed, then the process continues as if no MOCN was involved (step 806). If no such indication is received, a rerouting command, preferably provided with a reason value, is sent to the RNC (step 805). Steps 803 and 806 are shown as separate, separate steps with each operation. In step 803, the network element sends an accept message (NAS message) to the RNC, while in step 806, another NAS message (reject) is sent.

9 is a schematic diagram illustrating the elements of a suitable MSC/VLR or SGSN in view of the present invention. The network element comprises two logical units responsible for the functioning of the present invention: a layer (3) protocol controller 901 and a database 902. The controller includes a RANAP entity 903 that forms an interface towards the radio access network, and a mobility management entity 904 that communicates with a database comprising a memory 906 and a database management application 905 . The RANAP entity receives an initial UE message from a radio access network. The mobility management unit processes the request included in the message using the database to determine whether a service is to be provided. In accordance with the determination, the RANAP entity sends an appropriate NAS message or rerouting command to the radio access network. The determination may be made in a mobility management unit or a management application.

Although the present invention has been described with reference to the examples shown in the accompanying drawings, it is apparent that the present invention is not limited thereto, and can be modified within the spirit and scope of the present invention by those skilled in the art. For example, the method of the present invention can be applied to other types of networks shared by several operators.