RU2435327C2 - Methods, devices and computer software products for call routing from domain with channels switching into unified service domain - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: first of the specified client applications will be provided on a network side, and the second one of the specified client applications may be potentially provided on a terminal side. The version to implement this method includes, on the network side, the stages, at which the message is received from the terminal side, the client application is detected, in response to the message, for provision of functional capabilities of routing, and activation condition of at least one of these two client applications is managed depending on the result of this detection.

EFFECT: efficient support of call routing from the access domain with channels switching into the unified service domain.

36 cl, 19 dwg

Description

FIELD OF THE INVENTION

The invention generally relates to call routing techniques. In particular, the invention relates to a method for routing a call from a circuit switched access domain to a unified service domain.

State of the art

In second-generation (2G) and third-generation (3G) mobile communication systems, various switching domains can be identified in access networks that link user terminals to core networks serving user terminals. These switching domains include a circuit switched domain (CS) and a packet switched domain (PS). In a circuit switched domain (CS), signals are physically transported to their recipient via a unique connection, while in a packet switched domain (PS), individual packets are dynamically routed to their respective recipients based on the destination address associated with each packet.

User 2G and 3G terminals, operating in accordance with the current standards GSM (global system for mobile communications) and WCDMA (wideband multiple access with code division multiplexing), as a rule, access the core network via a circuit switched access network (CS), that is, through a circuit switched domain (CS). From a circuit switched access domain (CS), the call is routed to a specific service domain in the core network.

Various service domains are currently deployed to provide call services, including call setup services, call support services, or call termination services. In the past, mobile networks were exclusively circuit switched networks (CS). Therefore, the circuit switching (CS) paradigm was at the heart of both the access domain and the service domain. As mobile networks evolved from pure circuit-switched (CS) networks to Internet Protocol (IP) -based networks, new service domains were introduced. One of these new service domains is the IP Multimedia Subsystem (IMS), which is currently standardized through the Third Generation Partnership Project (3GPP). The IMS subsystem is a network architecture serving both fixed and mobile terminals that integrates efficiently into the ubiquitous IP environment, which includes the Internet and other packet-based networks (PS).

The expanded functionality of the service domain of the IMS subsystem, as well as other new service domains, are in most cases provided on a subscription basis. In the illustrative case of the IMS subsystem, this means that a particular call is routed exclusively to the service domain of the IMS subsystem if the subscription of the IMS subsystem can be determined for at least one terminal participating in the call. Otherwise, that is, if the subscription of the IMS subsystem cannot be determined, the call services will be provided in the usual way and, as a rule, in the service domain based on circuit switching (CS).

Many different service domains that can be accessed for an individual call require a mechanism that selectively switches from a specific access domain to any regular service domain (based on circuit switching (CS)), to the service domain of the IMS subsystem, or to any other new service domain. Depending on the current subscription status or other parameters, some call services necessary or requested by the user terminal may be provided in one service domain, while other call services for this terminal may be provided in an alternative service domain. The roaming mobile terminal can provide the same service in different service domains when network capabilities change depending on the location of the terminal. Both scenarios lead to heterogeneous user interaction due to different service domains that potentially handle calls involving the same terminal.

To provide a more consistent user experience, as well as to reduce the workload associated with service domain switching techniques, it is desirable to provide a unified service domain instead of many different service domains. Currently, through the 3GPP project, an appropriate solution is being investigated for sequentially routed calls from a circuit switched access network (CS), through an IMS subsystem network, to an IMS subsystem service domain. The work item is called the centralized services of the IMS subsystem (ICS) and aims to move all subscribers to the IMS subsystem to harmonize the work environment (see 3GPP TSG SA WG2 Architecture - SA2 # 5, Sophia Antipolis, France, August 28 - September 1, 2006, Tdoc S2 -063335).

The routing mechanisms required to use ICS require the installation of an ICS client application that provides basic functionality. Two major alternative client installation options are currently being investigated. According to the first alternative, that is, a network-oriented model, the network side is endowed with new routing functionality. That is, the ICS client application is installed on the network, for example, on the mobile switching center (MSC) or on the server of the MSC (MSC-S). In the second installation model, the ICS client application can be hosted in a terminal.

Both models have their advantages and disadvantages. For example, at the beginning of the introduction, high-speed support for ICS services on the network side is desired. In addition, the network-oriented approach scales better in the widespread use case study and also provides ICS support for legacy and low-performance terminals. However, since there are initially a small number of ICS users, a terminal-oriented solution may be more resource efficient before applying the unified service paradigm as a whole.

Accordingly, there is a need for a methodology that effectively implements a unified service domain without giving up the benefits of separate alternative client application installation options.

Disclosure of invention

According to a first aspect, there is provided a method for controlling the activation state of one or more client applications providing functionality that support call routing from a circuit switched access domain to a unified service domain in which the first client application is provided on the network side and the second client application is potentially provided on side of the terminal. On the network side, the method includes the steps of receiving a message from the terminal side, in response to the message, a client application is detected, that is, to provide routing functionality, and the activation state of at least either the first client application or the second is controlled client application depending on the result of discovery.

A unified service domain can be a service domain selected from two or more potentially available service domains as a specific service domain for harmonization of the service domain. The selection can be made by the network operator. In one embodiment, the unified service domain is the service domain of the IMS subsystem under the ICS service paradigm, as described in 3GPP TSG SA WG2 Architecture - SA2 # 5, Sofia Antipolis, France, August 28 - September 1, 2006, Tdoc S2-063335, with by reference, in particular, regarding the functionality of client applications and aspects of a unified service domain.

Although the access domain is the preferred circuit-switched access (CS) domain, any call transfers from the circuit-switched access domain (CS) to another access domain (for example, to a packet-switched domain (PS) such as IP are not excluded -CAN), or from another similar access domain to a circuit switched access domain (CS), or between two different circuit switched access domains (CS). Such call transmissions may occur, for example, in service continuity (service provisioning) scenarios, such as a voice call continuity scenario (VCC).

The functionality of one or more client applications that support call routing from a circuit switched access (CS) domain to a unified service domain may include routing session control signals between the client application and the interface component to a unified service domain (such as an adapter IMS subsystem interface). In addition to transmitting session control signals, the routing of multimedia data and the transmission of signals associated with multimedia data can also be supported.

Finding a specific client application to provide the necessary routing functionality may include determining the available capabilities on the terminal and / or network side. In one scenario, this is determined if the second client application is fully provided on the terminal side or the specific functionality of any second client application provided on the terminal side is defined. In addition, or alternatively, this is determined if the first client application is fully provided on the network side or the specific functionality of any first client application provided on the network side is defined. Discovery may further include selecting one of the first and second client applications to provide routing functionality. This solution may be based on the availability of at least one of the first and second client applications and / or on the specific functionality provided by at least one of the first and second client applications.

As mentioned above, detection is performed in response to receiving a message from the terminal side. According to a first embodiment, the message includes information that will be evaluated during the detection step. According to a second embodiment, which may be combined with the first embodiment, the receipt of the message serves as a trigger for initiating the detection step. According to a further embodiment, the detection step is carried out in close time communication with the receipt of the message (for example, the receipt of the message starts a timer that determines the time interval for the detection step).

In one control scenario of the present invention, the first client application resident on the network side is controlled to be in an activated state if the second client application cannot be detected on the terminal side. In another control scenario, the first client application is controlled to be in a deactivated state if a second client application can be detected. In the deactivated state of the first client application, the method performed by the node on the network side may further include direct transmission (direct transmission step) of any transmission of control signals from the second client application, as well as to it.

A message received from the terminal side may include an indicator of a specific client application to provide call routing functionality. For example, this indicator may include a notification about the availability of the second client application on the terminal side or, alternatively, a command regarding activation of the first client application on the network side. Moreover, the indicator may be a request to register a user terminal in a unified service domain. This registration request may be generated by or under the control of a second network application (therefore, indicating the availability of the second client application on the terminal side). Based on any indicator received by a message from the terminal side, the network side can appropriately control the activation state of the network first client application.

The network side may control the activation state of the network first client application, the terminal second client application, or both client applications. Management of the activation state of the second client application on the terminal side may include sending an activation command regarding the activation state of the second client application to the terminal side. Therefore, the second client application can be either activated or deactivated.

On the network side, one or more location registration databases can be provided, such as a home subscriber location registration database (HLR) or roaming subscriber location registration database (VLR). In addition, the method may further include the step of storing the current activation state of at least one of the first and second client applications in the location registration database. Moreover, the status of at least one service requested or provided in a unified service domain can be stored in a location registration database.

In one scenario, the method further includes the steps of selecting an interface component for a unified service domain and connecting one activated application from the first and second client applications to the selected interface component. The identifier of the selected interface component (for example, its network address) can be sent to at least one of the location registration databases and one activated application from the first and second client applications.

Regarding the terminal being moved to the guest network, the method may further include the steps of receiving, by the guest network, the identifier of the selected interface component and performing, by the guest network, renewing registration of the moved terminal in the unified service domain through the selected interface component. In the guest network, an additional step of receiving and evaluating the activation status of the first client application in the previous network can be performed. Depending on the activation status of the first client application in the previous network, a new first client application may be created in the guest network. Such a creation can occur, in particular, if it was determined that the first client application in the previous network had or was in an activated state.

Some or all of the routing functionality may be provided on a subscription basis. In such a case, the method, when executed on the network side, may further include at least either requesting or receiving subscription information. In addition, depending on the availability of the subscription, routing functionality of the first client application may be provided. Moreover, authorization information related to routing functionality may be requested within the network. After receiving and evaluating the requested authorization information, a decision can be made as to whether a particular terminal should be registered in a unified service domain.

According to another aspect of the invention, there is provided a method for controlling the activation state of one or more client applications providing functionality that support call routing from a circuit switched access domain to a unified service domain in which the first client application is provided on the network side and the second client application is potentially provided on the side of the terminal. On the terminal side, the method includes the steps of generating a client application indicator to provide call routing functionality and transmitting the indicator to the network side. Thanks to this indicator, the activation status of the first client application on the network side can be influenced, as discussed above.

In one embodiment, the method includes an additional step of providing a second client application on the terminal side. In this case, the indicator transmitted to the network side may include a link to the availability of the second client application on the terminal side. In addition or alternatively, the indicator may include any link to the first client application provided on the network side. The network side may interpret the link to the first client application as a command to control the first client application so that it is in an activated state.

The invention may be practiced as hardware, as software, or as a combined hardware / software approach. According to a software aspect, a computer program product is provided. The computer program product contains elements of program code for performing the steps of the present invention when the computer program product is running on one or more computing devices. The computer program product may be stored on a computer-readable storage medium.

According to a hardware aspect, a network node is provided for controlling the activation state of one or more client applications that provide functionality that supports routing a call from a circuit switched access domain to a unified service domain, with the indicator of the first client being provided on the network side and the second client application potentially provided on the side of the terminal. The network component includes an interface adapted to receive messages from the terminal side, a sensor adapted in response to the message to detect a client application to provide routing functionality, and a controller adapted to control the activation status of at least one of the first client applications , or the second client application, depending on the result of the discovery.

According to another aspect of the hardware, a terminal is provided for controlling the activation status of one or more client applications that provide functionality that supports routing a call from a circuit-switched access domain to a unified service domain, the first client application being provided on the network side and the second client application potentially provided on the side of the terminal. The terminal includes an interface adapted to transmit the indicator of the client application to the network side to provide call routing functionality. The terminal may further include a processor for generating an indicator. In addition, the terminal may be equipped with a second client application.

Brief Description of the Drawings

The invention will now be described with reference to illustrative embodiments illustrated in the drawings, which depict the following:

1 is a structural block diagram illustrating a communication network including two embodiments of the hardware of the present invention;

2 is a flowchart illustrating a first embodiment of a method of the present invention;

3 is a flowchart illustrating a second embodiment of the method of the present invention; and

4-19 are structural block diagrams and signaling block diagrams illustrating various further embodiments of the present invention in an illustrative context of ICS services.

The implementation of the invention

In the following description, in order to provide a thorough understanding of the present invention, for purposes of explanation and not limitation, certain details are described, such as specific steps, interfaces, and configurations. Those skilled in the art will understand that the present invention may be practiced in other embodiments that depart from these specific details. For example, although embodiments will be illustratively described in the context of a unified service domain of an IMS subsystem, it is obvious that the invention can also be practiced in other unified service domains other than those covered by the IMS subsystem. In addition, although the following embodiments will describe separate protocols, such as the Unstructured Data Transfer Protocol for Supplemental Services (USSD), the ISDN network subsystem protocol (ISUP), and the media transfer independent call control protocol (BICC), it should be understood that other suitable protocols may also be used instead of or in addition to one or more of these protocols.

Those skilled in the art will also appreciate that the functions explained later in this document can be implemented using software that operates in conjunction with a programmable microprocessor or universal computers. It should also be understood that although the present invention is primarily described in the form of methods and devices, the invention can also be implemented in a computer program product, as well as in a system including a computer processor and memory connected to the processor moreover, the memory is encrypted by one or more programs that can perform the functions disclosed herein.

FIG. 1 illustrates a communication network 100 including two embodiments of hardware in the form of a terminal 110 on the one hand and a network node 112 on the other. The communication network 100 further includes a unified service domain 114. The terminal 110 may be a fixed or mobile terminal, such as a personal computer, mobile phone, or personal digital assistant (PDA). The network node 112 may be a switching component of a network, such as an MSC or an MSC-S server. Preferably, the network node 102 is mapped or part of a circuit switched access (CS) domain, by which terminal 110 can be mapped to the unified service domain 114, as illustrated by arrow 116 in FIG. 1.

Terminal 110 includes an additional client application 120 that provides functionality that supports call routing from a circuit switched access domain (CS) with network node 112 to a unified service domain 114. Client application 120 is optional in that it can be potentially omitted (for example, if a client application providing essentially the same functionality is located on the network node 112). The terminal 110 further includes a network interface 122 adapted to transmit a specific client application indicator to the network node 112 to provide functionality for routing the call to the unified service domain 114. An indicator for transmission through the network interface 122 is generated by the processor 124 of the terminal 110 As shown in FIG. 1, processor 124 is adapted to interact with both the additional client application 120 and the network interface 122.

The network node 112 comprises a network interface 130 adapted to receive messages from the terminal 110. A message received through the network interface 130 from the terminal 110 may include a client application indicator to provide call routing functionality. However, the message, in principle, may not have such an indicator without affecting the operation of the network node 112. In this case, through the network node 112, support for a unified service domain can be automatically provided.

As shown in FIG. 1, the network node 112 further includes its own client application 132 to selectively provide support for a unified service domain. Like the additional client application 120 of terminal 110, the network client application 132 is adapted to provide features that support the routing of a call from terminal 110 through network node 112 to a unified service domain 114 (see arrow 116). The network node 112 further includes a sensor 134 connected to the network interface 130. The sensor 134 is adapted to be detected in response to receiving a message through the network interface 130 of the client application to provide routing functionality.

The sensor 134 interacts with a controller 136 adapted to control the activation state of at least either a network client application 132 or an additional terminal client application 120 depending on the detection result performed by the sensor 134. Depending on the detection result, the controller 136 may, for example , activate or deactivate the network client application 132. However, the controller 136 can also remotely control the activation status of the terminal client application 1 20. For this purpose, the controller 136 may transmit control commands via the network interface 130 to the terminal 110.

2 is a flowchart 200 of a first embodiment of a method of the present invention. An embodiment aims to control the activation status of one or more client applications that provide functionality that support call routing from a circuit switched access (CS) domain to a unified service domain, with the first client application provided on the network side and the additional second client application potentially provided on the side of the terminal. The method, as illustrated in FIG. 2, may be practiced by the terminal 110 of FIG. 1, or by any other terminal.

The method begins at step 202 with the generation of an indicator of a specific client application to provide call routing functionality. In one example, the indicator provides for detection on the network side that the client application is actually provided on the terminal side. In another example, the indicator requests activation of the network client application.

After generating the indicator in step 202, the method proceeds to step 204. In step 204, the indicator is transmitted to the network side. To this end, the indicator can be placed in a control message interpreted by a host that detects a client application to provide routing functionality. By transmitting the indicator to the network side, the terminal can remotely control the activation status of the network client application.

FIG. 3 depicts a flow diagram 300 of another embodiment for controlling the activation state of one or more client applications providing capabilities that support call routing from a circuit switched access domain (CS) to a unified service domain. This embodiment of the method may be practiced by the network node 112 of FIG. 1, or by any other network node.

In a first step 302, a message is received from the terminal side. The message may be a regular message according to the current protocol standard. The message may include an indicator, as discussed above with reference to the method embodiment illustrated in FIG.

After receiving the message, the method proceeds to step 304, where a client application is detected to provide routing functionality. This detection may be based on the information content of the message received at step 302. Alternatively, the detection may simply be caused by the receipt of this message.

In the next step 306, the activation state of at least either the network client application or the terminal client application is controlled depending on the result of the discovery step 304. Management (control step) may include activation (activation step) of one of the client applications and simultaneous deactivation (simultaneous deactivation phase) of another client application. In the case where the client application is not provided on the terminal side, step 306 may include only the activation (activation step) of the network client application. If the network client application is in an activated state by default, then step 306 will maintain the activated state of the network client application.

Illustrative implementation of ICS

Next, various further embodiments will be discussed with reference to the structural block diagrams of the network and the structural signaling circuits shown in Figs. 4-19. The same reference numbers used in FIG. 1 will be used to refer to identical or similar components.

Additional embodiments of FIGS. 4-19 relate to the dynamic selection of a network or terminal client application in the illustrative context of ICS services. Initially, more detailed solutions for installing the client application on the terminal (Figure 4) and on the network (Figure 5) will be explained.

ICS Terminal and Network Client Applications

4, the network system 400 includes a terminal 110 (also called subscriber equipment (UE)) having access to a circuit switched network (CS). Terminal 110 includes an IMS subsystem client application 156, as well as an additional ICS client application 120. MSC-S server 112, media gateway 154 (MGW), interface adapter (IA) 150, which functions as an interface for IMS subsystem 114, and media proxies 152 (MP) are further included in network system 400.

ICS client application 120 at terminal 110 provides specific tasks in the context of ICS, and also includes two functional components that reflect the layered architecture of network system 400. At the control level (or control plane), ICS client application 120 includes a function block “C” for session management. At the user level (or user plane), the ICS client application 120 includes an “M” function block for managing a multimedia connection. The individual functional blocks of the ICS client application 120 interact with the corresponding functional blocks of the interface adapter (IA) 150. Interaction at the management level involves the USS ICS protocol, while user interaction involves protocols according to the technical specification of the 3GPP project standard 24.008, on the one hand (between ICS client application 120 and MSC-S server 112), and ISUP / BICC , on the other hand (between the MSC-S server 112 and the MP media proxy 152).

The management level and user level are tied to the IMS subsystem 114 through an interface adapter (IA) 150 and a media proxy 152 (MP). As shown in FIG. 4, the IMS subsystem 114 includes an IMS core as well as IMS application services (such as Multimedia Telephony Services (MMTel)). The IMS core and IMS application services communicate through the ICS protocol.

Assuming the existence of an ICS client application somewhere on the network side (see, for example, FIG. 1 above or FIG. 5 below), the terminal 110 shown in FIG. 4 can be configured to execute an embodiment of the method discussed above with reference figure 2. In one embodiment, terminal 110 sends an indicator to the network side that informs the network side of the availability of ICS client application 120 at terminal 110.

Meanwhile, as FIG. 4 illustrates a network system 400 with an ICS terminal client application 120, FIG. 5 depicts a network system 500 with an ICS network client application 132. As will be understood after viewing FIG. 5, the ICS client application 132 is installed on the MSC-S server 112. Another ICS client application may be installed on terminal 110 (as shown in FIG. 4). The MSC-S server depicted in FIG. 5 may be configured to perform an embodiment of the method explained above with reference to FIG. 3. The remaining components of the network system 500 are similar to the components of the aforementioned network system 400, and therefore, a detailed description will be omitted.

Based on FIGS. 4 and 5, it is further assumed that the ICS client application 132 (also called the “uICS client”) will always be installed on the network side, and that the ICS client application 120 (also called the “nnICS client”) can be installed on the side of the terminal.

As already explained above, the ICS client application (network or terminal) will be connected to the IMS subsystem interface adapter (IA) 150, which serves as the interface node for the IMS subsystem 114. The implementation of the interface adapter (IA) 150 should not depend on the location of the ICS client application, that is, the location of the ICS client application (terminal or network side) is preferably hidden from the interface adapter (IA) 150.

The ICS client application 132 on the MSC-S server 112 uses the USS ICS protocol in the same manner as the terminal 110 in the terminal-oriented solution. In the IMSI location / binding update procedures initiated by the terminal 110 through the corresponding messages, the MSC-S server 112 attempts to detect the ICS client application in the terminal 110. If the terminal 110 has ICS client functionality (as shown, for example, in FIG. 4) , then the ICS client application 132 on the MSC-S server is deactivated. Otherwise, if the ICS client application cannot be detected on the terminal 110, then the ICS client application 132 on the MSC-S server 112 is activated (or maintained in an activated state, which should be the default state). A subscriber working with terminal 110 can select a specific ICS client application as the default application (for example, through a web portal) and, therefore, reject any network choice.

Information related to ICS, at least about the activation status of the ICS client application 132, as well as the availability / activation status of the ICS client application 120 potentially provided to terminal 110, is locally stored in the VLR database (not shown in FIG. 4 and 5) 112 MSC-S server. Such information can also be uploaded to the HLR database (not shown in FIGS. 4 and 5).

Therefore, the ICS client status (stored on the MSC-S server 112 and in the HLR database) can take the following states:

- Network Enabled, Deactivated = ICS Terminal Client Assumed.

- Network Entered, Activated (IA ID) = Assumes an ICS network client.

- Subscriber activated = network-based forced

o USSD application on 112 MSC-S server is blocked

o The ICS client based on the MSC-S server is constantly in use

- The subscriber is deactivated = forced on the basis of the terminal

o ICS Client on MSC-S 112 is never activated

o USSD application on 112 MSC-S server is not activated

If, when updating the IMSI location / binding, the MSC-S server 112 cannot detect the ICS terminal client application, then the ICS network client application 132 will select the IA node 150 for use with the IMS subsystem 114. After selecting node 150 IA, the ICS client application 132 initiates an IMS subsystem registration procedure. The IA identifier is returned to the ICS client application 132, and in the case of the ICS network client, the IA identifier and the associated state of the ICS are stored in the VLR and also loaded into the HLR.

When terminal 110 moves from the zone served by the MSC-S server 112 (and through the ICS client application 132 of the MSC-S 112 server) to the zone of the new MSC-S server, the IA identifier and the status of the ICS services are received by the new MSC-S server from HLR bases together with subscriber data. Then, the interface adapter (IA) 150, identified by the received IA identifier, is used by the new MSC-S server to renew registration of the IMS for the roaming terminal 110. This means that the connection identification information of the interface adapter (IA) 150 does not change when the terminal 110 is moved .

The ICS client application 132 on the previous MSC-S server 112 is reset upon receipt of the location deactivation indicator from the HLR. In the case where terminal 110 is freed from serving the MSC-S server 112, the interface adapter (IA) 150 must also be reset.

In the ICS network client scenario, the ICS client application 132 on the MSC-S server 112 unregisters the terminal 110 and resets the IA device. In the ICS terminal client application 120, the IA timer controls the registration of the IMS by the terminal 110. If the timer expires, the IA device is reset.

In the embodiments of FIGS. 4-19, ICS functionality in the IMS subsystem 114 is provided based on a subscription. Subscription to ICS services is provided to each subscriber through an operator in the HLR database and is uploaded to the MSC-S server 112 with the usual MAP subscriber data entry message. If for the terminal 110 served by the MSC-S server 112, the subscription to the ICS cannot be determined, then the terminal 110 is served in accordance with the usual subscription to the ICS, and will also normally be served in the ICS service domain. However, if an ICS subscription can be defined for terminal 110, then the network or terminal ICS client application is activated depending on the state of the ICS client (the possible status of the ICS client has already been described above). The subscriber data may contain an additional uICS prohibition indicator. By setting the uICS prohibition indicator, an operator can prohibit the use of any terminal ICS client application.

The above basic mechanisms involving the dynamic selection of either the ICS terminal application 120 (see FIG. 4) or the ICS network client application 132 (see FIG. 5) will be described in more detail below with reference to signaling scenarios depicted in 6-19. First, we will look at the basic IMSI binding procedures that trigger the dynamic selection of the ICS client application.

IMSI Binding Procedures

6 and 7 depict an IMSI binding procedure for terminal 110 roaming in an ICS-enabled home network. The IMSI binding procedure involves the terminal client application 120 of ICS.

When moving in a home network (or any other ICS-enabled network), the selection procedure, as shown in FIG. 6, is started based on the IMSI binding message sent by the terminal to the MSC-S server 112 (step 1). Then, the MSC-S server 112 must decide whether to use the ICS network client application or use any terminal ICS client application 120 (step 2). This decision on the MSC-S server 112 may be based on various pieces of information, as determined by, for example, a network operator 170. The MSC-S server 112 may detect the presence of the ICS client application 120 in the terminal 110 based on the following criteria:

- The subscriber data in the VLR database (not shown) contains a subscription to ICS services,

- and the request for modification is accepted in the IMSI binding, and this modification is the registration of the IMS subsystem via USSD on a call-independent transaction (so that the USSD application on the MSC-S server 112 checks the USSD lines received from terminal 110 to determine whether registration of the IMS was initiated by terminal 110),

or

- subscriber data in the VLR database contains a subscription to ICS services,

- and a recently defined ICS service indicator information element (IE) is found in the IMSI binding message 24.008,

or

- subscriber data in the VLR database contains a subscription to ICS services,

- and a recently defined information item (IE) of the classification indicator 24.008 is added through terminal 110 to indicate support for ICS services in terminal 110.

Then, the MSC-S server 112 selects an interface adapter (IA) (step 3) based on a load distribution analysis. In the next step, the verification of the subscription to ICS services is performed through the selected adapter 150 interface (IA) for the registry 160 home subscribers (HSR) (step 4). If an ICS subscription exists, then terminal 120 registers with IMS subsystem 114 (step 5). Moreover, the selected interface adapter (IA) 150 returns its unique identifier to the MSC-S server 112, as well as to the ICS client application 120 residing on the terminal 110 (step 6), for further use.

The signal flow in the case where the ICS terminal client application 120 is detected by the MSC-S server 112 is shown schematically in FIG. 7 and is also briefly described below:

Steps 1) to 5): The location update of the IMSI binding type is updated for the HLR base 180 (not shown in FIG. 6), and also enters subscriber data into the VLR base (not shown in FIG. 6). The subscriber data contains an ICS subscription indicator.

Steps 6) - 7): Mobility management level on server 112 MSC-S verifies ICS subscription in the VLR database. In this sequence, it is assumed that the ICS client application 120 in the terminal 110 is detected by a subsequent request on the IMSI binding.

Steps 8) - 9): Terminal 110 opens a call-independent transaction.

Steps 10) through 12): The terminal ICS client application 120 uses the established call-independent transaction to send the USSD string to interface adapter 150 (IA).

Steps 13) - 16): The interface adapter (IA) 150 authorizes the ICS service in the 160 HSR base and performs the registration of the IMS subsystem.

Steps 17) to 20): Interface adapter (IA) 150 returns a USSD string to ICS client application 120 at terminal 110 to indicate successful registration of the IMS subsystem. ICS client application 120 starts a registration watch timer.

Steps 21) - 22): The USSD application on the MSC-S server 112 updates the status of the ICS services in the VLR database as well as in the 180 HLR database, indicating that the ICS network client application is deactivated. Then the selection procedure is completed.

In the case where the MSC-S server 112 cannot detect terminal support for ICS services, network support for ICS services is activated. In this regard, FIGS. 8 and 9 depict an IMSI binding procedure for terminal 110 roaming in a home network. The IMSI binding procedure involves the ICS network client application 132 and executes schematically depicted in FIG. 8 through steps 1-7. A more detailed description of the associated signal stream is shown in Fig.9.

Steps 1) - 5): Updating the location of the IMSI binding type is updated for the 180 HLR base, and also enters the subscriber data into the VLR base. The subscriber data contains a subscription to ICS services.

Steps 6) - 7): Mobility management level on server 112 MSC-S verifies ICS subscription in the VLR database. In this sequence, it is assumed that the ICS client application at terminal 110 cannot be detected.

Step 8): The mobility management layer on the MSC-S 112 server activates the ICS network support for the subscriber

Steps 9) - 10): The ICS network client application uses an established, call-independent transaction to send a USSD string to interface adapter (IA) 150.

Steps 11) to 14): The interface adapter (IA) 150 authorizes the ICS service in the 160 HSR base and performs registration of the IMS subsystem.

Steps 15) - 17): Interface adapter (IA) 150 returns a USSD string to the ICS network client application to indicate successful registration of the IMS subsystem. The ICS client application starts the registration monitoring timer.

Steps 21) - 22): The USSD application on the MSC-S server 112 updates the status of the ICS services in the VLR database, as well as in the 180 HLR database, indicating that the ICS network client application is activated, as well as the IA identifier that was accepted in answer. Then the selection procedure is completed.

10 depicts an IMSI binding procedure for terminal 110 roaming in a guest network without network support for ICS. In this case, the terminal client application 120 of the ICS services should be used, otherwise the subscriber will not be able to use the centralized services of the IMS subsystem at all.

As illustrated in FIG. 10, signaling begins with an IMSI binding message, which is sent from terminal 110 to MSC-S server 112 in the guest network (step 1). The MSC-S server 112 in the guest network does not provide support for ICS services and, therefore, directly sends any USSD operations to the USSD application residing in the 180 HLR database in the home network (step 2). The HLR base 180 selects an interface adapter (IA) (step 3) based on an analysis of load balancing. Then, through the selected interface adapter (IA) 150 for the HSR base 160, the subscription to ICS services is verified (step 4). If an ICS subscription exists, then terminal 120 registers with IMS subsystem 114 (step 5). In addition, the selected interface adapter (IA) 150 returns its unique identifier to the HLR base 180, as well as to the ICS client application 120 residing on the terminal 110 (step 6) for further use.

In the scenarios depicted in FIGS. 6-10, the MSC-S server 112 may also implement additional mechanisms to provide an operator 170 or a subscriber with control over whether to use the ICS network client application or the ICS terminal client application. Additional functionality on the MSC-S server 112 may activate ICS network support even though the ICS terminal client application is available and has been discovered through the MSC-S server 112. This replacement can be based on the operator’s settings, for example, expressed by a prohibition indicator for the end-to-end support of ICS services in subscriber data, or by setting such a prohibition for all roaming subscribers from a particular network. Replacement can be implemented in the USSD application of the MSC-S server 112 (for example, by rejecting any USSD lines of registration of the IMS subsystem on the MSC-S server 112).

Circuit Switched Network (CS) Scenarios

FIGS. 11 and 12 illustrate actions with respect to the activated ICS terminal client application that are performed for roaming terminal 110. When moving to a service area of a similar MSC-S server 112, which performed the basic ICS client selection procedure shown in FIG. 6 and 7, no new actions are performed, as illustrated in FIG. 11 through steps 1) to 6). When leaving the service area of the old MSC-S server 112 and entering the service area of the new MSC-S server 112 ', the IA identifier and ICS status are downloaded from the HLR database 180, and in cases where the ICS terminal client application has been used before, this state will be unchanged, and the same IA interface adapter 150 will be used further (steps 7) to 12) in FIG. 11).

A more detailed description of the associated signal stream is shown in Fig.12:

Steps 1) - 5): Updating the location of the LA change type is updated for the HLR 180 and also enters the subscriber data into the VLR. The subscriber data contains an ICS subscription. Status indicates that ICS network support (that is, the ICS network client application) is deactivated.

Steps 6) - 7): Mobility management level on server 112 MSC-S verifies ICS subscription in the VLR database. Because the status indicates that the ICS network support is deactivated, no further action is taken on the MSC-S server 112.

FIGS. 13 and 14 illustrate actions with respect to the activated ICS network client application that are performed for the roaming terminal 110. When moving to the coverage area, a similar MSC-S server 112, which has performed the basic ICS client selection procedure, as illustrated in FIG. and 9, no new actions are performed, as illustrated in FIG. 13 through steps 1) to 5). When leaving the service area of the old MSC-S 112 server and entering the service area of the new MSC-S 112 server, the IA identifier and ICS status are loaded into the HLR database 180, and in cases where the ICS network client application has been used before, this state will be unchanged, and the same IA interface adapter 150 will be used further (steps 6) to 12) in FIG. 13).

A more detailed description of the associated signal stream is depicted in Fig.14:

Steps 1) - 5): Updating the location of the LA change type is updated for the HLR 180 and enters the subscriber data into the VLR. The subscriber data again contains a subscription to ICS. Status indicates that ICS network support is activated, as well as a distributed IA identifier.

Steps 6) - 7): The MSC-S 'server mobility management level 112 verifies the subscription to ICS services in the VLR database. Since the status indicates that ICS network support has been activated, the new local ICS network client application should be used through the MSC-S server 112`.

Steps 8) - 9): The new ICS client application is used. Since the new ICS client application does not have information about the active registration of the IMS subsystem, as well as the timer status, re-registration of the IMS subsystem must be called.

Steps 10) - 16): Re-registration of the IMS subsystem is performed using the same interface adapter 150 (IA) as before. Verification of the HSR subscription is not required.

Location cancellation procedures involving the HLR base

When the terminal 110 enters the service area of the new MSC-S server 112`, the old MSC-S server 112 is canceled from the HLR base 180. In the case of an activated ICS terminal client application, no further action is required. This case is identified by the new MSC-S 112` server by checking the subscription status of ICS services in the VLR database. If ICS network support was used, then the ICS client application on the old MSC-S server 112 should be reset, as shown in the signal flow in FIG. Since the interface adapter (IA) 150 is again being used by the new MSC-S server 112`, no additional steps are required for the interface adapter (IA) 150 or the IMS subsystem 114.

Perform CS Unlink

When the terminal 110 is turned off, the unbind indicator is received at the MSC-S server 112, as shown schematically in the signal flows of FIGS. 16 and 17.

With respect to the ICS terminal client application (FIG. 16), no further action can be performed since terminal 110 cannot send the USSD string.

Step 1): An unlinking indicator from terminal 110 is received by the MSC-S server 112.

Steps 2) - 3): The mobility management layer on the MSC-S server 112 verifies the subscription to ICS services. Since ICS network support is deactivated, no further action is taken.

Steps 4) to 5): The registration monitoring timer in the interface adapter (IA) 150 expires and the interface adapter (IA) 150 is reset. Registration of the IMS subsystem expires and is deleted automatically by the IMS subsystem 114.

It should be noted that in the scenario illustrated in FIG. 16, the MSC-S server 112 cannot communicate with the interface adapter (IA) 150 due to the fact that it is not informed about the IA identifier (terminal support for ICS services).

With respect to network support for the ICS client, the ICS network client application can still unregister the IMS subsystem, as shown schematically in FIG. 17:

Step 1): An unlinking indicator from terminal 110 is received by the MSC-S server 112.

Steps 2) - 3): The mobility management level on the MSC-S server 112 verifies the subscription to ICS services, this check indicates that the ICS network client application is in an activated state.

Step 4): The mobility management layer informs the ICS client application on the network of the unlinking.

Steps 5) to 11): The IMS subsystem is deregistered using the interface adapter (IA) 150, and the IA device is reset.

Steps 12) - 13): The USSD application on the MSC-S 112 server updates the 180 HLR base as well as the VLR base and removes the IA identifier.

Re-registration procedure

The ICS client application monitors the registration of the IMS subsystem, that is, shortly before the expiration of the registration of the IMS subsystem, the ICS client application must re-register the subscriber and, therefore, terminal 110.

For an ICS terminal client application, this is done within terminal 110, as shown in more detail in the signal flow of FIG. 18. After the timer expires, a call-independent transaction is established and re-registration is initiated using USSD.

With respect to the ICS network client application, the timer is started on the MSC-S server 112, as illustrated in the signal flow of FIG. 19. After the timer expires, the ICS network client application contacts the interface adapter (IA) 150 to re-register.

Self management

Network support for ICS and its status management can be provided through an operator in the 180 HLR database. The status can be changed by the subscriber when using:

- Existing Extended Service Procedures (SS) enhanced with nICS, or

- ut procedures, or

- A web portal and packet switched access (PS) to this web portal.

As will be understood from the embodiments, the benefits of ICS terminal services (uICS) and ICS network services (nICS) can be combined into one dynamic solution, where terminal and network client applications are present on the same network for one subscriber (or one terminal). If the subscriber uses a more modern (improved) terminal, which includes the ICS client application, then the subscriber can use the terminal-based approach and get the full scope of the IMS subsystem capabilities. If a subscriber uses an outdated terminal without an ICS client application, network support can be provided to take advantage of one, several, or all of the capabilities of the IMS subsystem.

In embodiments, the network side dynamically adapts to the capabilities of the terminal side and provides either the ICS network client application, or the ICS network client application is deactivated if the network detects the ICS client application on the terminal, or the network explicitly instructs the terminal to activate the ICS client application, installed on the terminal. In addition, embodiments illustrate how once-provided ICS client support is served when moving in a circuit switched network (CS) between MSC-S server nodes.

Although embodiments of the present invention have been illustrated in the accompanying drawings and described herein, it is intended that the invention is not limited to the embodiments disclosed herein. In particular, the invention allows for numerous rearrangements, modifications and replacements without departing from the essence of the invention, as formulated and defined by the following claims.

Claims (36)

1. A method for managing the activation status of one or more client applications of centralized IMS (ICS), providing functionality that supports ICS call routing from a circuit switched access domain (122) to a unified IMS service domain (114), in which the first client ICS application (132) is provided on a network node (112), the method comprising, on a network node (112), the steps of:
receive a message from the terminal (110);
detecting, in response to a message, that a second ICS client application (120) is provided at the terminal (110) to provide routing functionality; and
controlling the activation state of the first client ICS application (132) depending on the detection result, the control step including the step of deactivating the first client ICS application (132). 2. The method according to claim 1, further comprising the step of controlling the activation state of the second ICS application (120), the control step including the step of activating the second client ICS application (120). 3. The method according to claim 1 or 2, in which the first client ICS application (132) is controlled so that it is in a deactivated state if the second client ICS application (120) can be detected. 4. The method according to claim 3, further comprising, in the deactivated state of the first client ICS application (132), the step of directly sending control signals from and to the second client ICS application (120). 5. The method according to claim 1, in which the message includes an indicator of the client ICS application for providing call routing functionality, and in which the activation state of the first client ICS application (132) is controlled depending on the indicator in the message. 6. The method according to claim 5, in which the indicator is a registration request in a unified service IMS domain (114) generated by a second ICS client application (120). 7. The method according to claim 1, further comprising sending to the terminal (110) instructions regarding the activation status of the second client ICS application (120). 8. The method according to claim 1, further comprising storing the current activation state of at least one of the first and second client ICS applications (132; 120) in the location registration database (180). 9. The method according to claim 1, further comprising the steps of selecting an interface component (150) for the unified service IMS domain (114) and connecting the activated one of the first and second ICS client applications (132; 120) with the selected component (150) interface. 10. The method according to claim 9, further comprising the step of sending the identifier of the selected interface component (150) to at least one of the location registration database (180) and one of the first and second client ICS component activated (132, 120). 11. The method of claim 10, further comprising, for the terminal (110) moving to the guest network, the steps of receiving, by the guest network, the identifier of the selected interface component (150) and performing, by the guest network, renewing registration of the moving terminal (110) in the unified service IMS domain using the selected component (150) of the interface. 12. The method according to claim 11, further comprising, in the guest network, the steps of receiving and evaluating the activation state of the first client ICS application (132) in the previous network and creating a new first first ICS client application (132) in the guest network, if the first client ICS application (132) in the previous network was in an activated state. 13. The method of claim 1, wherein the routing functionality is provided based on the subscription, and further comprising at least the steps of requesting and receiving subscription information. 14. The method of claim 1, further comprising the steps of requesting authorization information regarding routing functionality; accept the requested authorization information; and register the terminal (110) in the unified service IMS domain (114) depending on the received authorization information. 15. A method for controlling the activation state of one or more client applications of centralized IMS (ICS), providing functionality that supports ICS call routing from a circuit switched access domain (122) to a unified service IMS domain (114), the first ICS client application (132) is provided on the network node (112), the method comprising, on the network node (112), the steps of:
receive a message from the terminal (110);
detect, in response to a message, that no second ICS client application (120) on the terminal (110) provides routing functionality; and
controlling the activation state of the first client ICS application (132) depending on the detection result, the control step including the step of activating or maintaining the activated state of the first client ICS application (132). 16. The method according to clause 15, in which the first client ICS application (132) is controlled so that it is in an activated state if the second client ICS application (120) cannot be detected. 17. The method according to clause 15, in which the message includes a client ICS application indicator for providing call routing functionality, and in which the activation state of the first ICS client application (132) is controlled depending on the indicator in the message. 18. The method according to 17, in which the indicator is a registration request in a unified service IMS domain (114) generated by a second ICS client application (120). 19. The method according to clause 15, further comprising sending to the terminal (110) instructions regarding the activation status of the second client ICS application (120). 20. The method of claim 15, further comprising storing the current activation state of at least one of the first and second client ICS applications (132; 120) in the location registration data database (180). 21. The method according to clause 15, further comprising stages, which select the component (150) of the interface for the unified service IMS domain (114), and connect the activated one of the first and second client ICS applications (132; 120) with the selected component (150 ) interface. 22. The method according to item 21, further comprising the step of sending the identifier of the selected interface component (150) to at least one of the location registration database (180) and one of the first and second client ICS component activated (132, 120). 23. The method according to item 22, further comprising, for the terminal (110) moving to the guest network, the steps of receiving, by the guest network, the identifier of the selected interface component (150), and performing, via the guest network, renewing registration of the moving terminal (110) in the unified service IMS domain using the selected component (150) of the interface. 24. The method according to claim 23, further comprising, in the guest network, the steps of receiving and evaluating the activation state of the first client IMS application (132) in the previous network and creating a new first client ICS application (132) in the guest network, if the first client ICS application (132) in the previous network was in an activated state. 25. The method of claim 15, wherein the routing functionality is provided based on the subscription, and further comprising at least the steps of requesting and receiving subscription information. 26. The method according to clause 15, further comprising stages, which request authorization information regarding routing functionality; accept the requested authorization information; and register the terminal (110) in the unified service IMS domain (114) depending on the received authorization information. 27. A method for managing the activation status of one or more client applications of centralized IMS (ICS) providing functionality that supports ICS call routing from a circuit switched access domain (122) to a unified service IMS domain (114), the first ICS client application (132) is provided on the network node (112), the method comprising, on the terminal side, the steps of:
generating an indicator that the second client ICS application (120) provided on the terminal (110) provides call routing functionality; and
transmit the indicator to the network node (112) to perform the deactivation of the first client ICS application (132). 28. The method according to item 27, further containing a stage in which a second client ICS application (120) is provided at the terminal (110); moreover, the indicator includes a link to the availability of the second client ICS application (120). 29. The method according to item 27 or 28, further comprising the step of activating the second client ICS application (120). 30. A computer-readable medium on which a computer program product is stored comprising portions of program code for performing steps of the method according to any one of claims 1-14, when the computer program product is executed on one or more computing devices. 31. A computer-readable medium on which a computer program product is stored comprising portions of program code for performing steps of the method according to any one of claims 15 to 26, when the computer program product is executed on one or more computing devices. 32. A computer-readable medium on which a computer program product is stored comprising portions of program code for performing steps of the method according to any one of claims 27 to 29, when the computer program product is executed on one or more computing devices. 33. The network node (112) for managing the activation state of one or more client applications of centralized IMS (ICS), providing functionality that supports ICS call routing from a circuit switched access domain (122) to a unified service IMS domain (114), moreover, the first client application (132) is provided on the network node (112), while the network node (112) contains:
an interface (130) configured to receive a message from the terminal (110);
a sensor (134) configured to detect, in response to the message, that a second client ICS application (120) is provided at the terminal (110) to provide routing functionality; and
a controller (136), configured to control the activation state of the first client application (132), depending on the result of the detection, the control step includes the step of deactivating the first client ICS application (132). 34. The network node (112) for managing the activation status of one or more client applications of centralized IMS (ICS), providing functionality that supports ICS call routing from a circuit switched access domain (122) to a unified service IMS domain (114), moreover, the first client application (132) is provided on the network node (112), while the network node (112) contains:
an interface (130) configured to receive a message from the terminal (110);
a sensor (134) configured to detect, in response to the message, that the second client ICS application (120) is not provided at the terminal (110) to provide routing functionality; and
a controller (136) configured to control the activation state of the first client application (132), depending on the result of the detection, the control step including the step of activating or maintaining the first client ICS application (132) in an activated state. 35. A terminal (110) for managing the activation status of one or more client applications of centralized IMS (ICS), providing functionality that supports call routing from a circuit switched access domain (122) to a unified service IMS domain (114), the first the client ICS application (132) is provided on the network node (112), while the terminal (110) contains:
a processor (124) configured to generate an indicator that a second client ICS application (120) is provided at the terminal (110) to provide call routing functionality; and
an interface (122) configured to transmit an indicator to a network node (112) to perform deactivation of the first client ICS application (132). 36. The terminal of claim 35, further comprising a second client application (120).

Images