An Internet Protocol (IP) Multimedia Core Network Subsystem (IMS), which is an IP-based network architecture presented by the 3rd Generation Partnership Project (3GPP), constructs an open and flexible service environment, supports multimedia applications and provides abundant multimedia services for users.
The IMS, which is an IP-based telecommunication network architecture and is independent of access technologies, may provide services for a mobile cellular network, such as Global System for Mobile communication (GSM), Universal Mobile Telecommunications System (UMTS), etc., in addition to providing services for a packet access network, such as General Packet Radio Service (GPRS), Wireless Local Area Network (WLAN), etc.
The mobile cellular network, such as GSM and UMTS, uses a circuit switching technology, which is called a Circuit Switched (CS) domain and able to provide basic voice services and supplementary services based on voice services for users. When accessing to the IMS, the CS domain evolves into an access mode, where services are provided entirely by the IMS. Such technology is called IMS Centralized Services (ICS for short).
The IMS centralized services have the following advantages:
(1) the IMS provides uniform services for access modes, such as circuit switched domain and packet domain, and supports network convergence;
(2) it supports the evolvement of a CS network into an IMS network; and
(3) it supports both a user device with ICS ability and an existing user device without ICS ability.
FIG. 1 is a frame diagram of IMS centralized services comprising the following network elements: a User Equipment (UE) 101, a Visited Mobile Switch Center (VMSC) 102, a Home User Server (HSS) 103, a Media Gateway Control Function (MGCF) 104, a Media Gateway (MGW) 105, an IMS CS Control Function (ICCF) 106, a Call Session Control Function (CSCF) 107 and a Telecom Application Server (TAS) 108.
Three paths from the UE 101 to the ICCF 106 in an IMS domain through the VMSC 102 are established: a session control path, a bearer control path and a bearer path, wherein,
The session control path, which passes through the VMSC 102 and the HSS 103, is borne on a CS domain and uses unstructured supplementary service data (USSD). If there is a PS network in a network where the UE 101 is located, then session control signaling may be accessed through the PS network.
The UE 101 in the bearer control path accesses to the VMSC 102 using standard CS control signaling and accesses to the IMS through the MGCF 104 and reaches the ICCF 106 through the CSCF 107.
The UE 101 in the bearer path accesses to the IMS through the VMSC 102 and the MGW 105 and establishes a media connection with a remote user device of the session.
The IMS centralized services utilize the session control path between the UE 101 and the ICCF 106 to interact with session control information and establishes and controls media bearer through the bearer control path, where the ICCF 106 acts as a user agent of the IMS to access to the IMS in place of the user equipment.
The TAS 108 may provide various complementary services, such as call holding, call transfer, number display, call forwarding and thus be called complementary service server.
Call forwarding services are a type of complementary services in communication systems and comprises call forwarding unconditionally, call forwarding on no answer and call forwarding on busy, wherein, mobile user busy includes network-determined user busy and user-determined user busy. The network-determined user busy means that a user state recorded by a network is busy, for example, the user is on the phone; while the user-determined user busy means that a mobile user refuses to answer a call immediately after receiving a call ringing notification and his incoming call is transferred to a preset phone or voice mailbox by a network.
As a telecommunication system, the ICS must support call forwarding services.
FIG. 2 illustrates a prior art scheme where on a session control path in a CS domain, a user A of an IMS calls a user B with ICS capability accessing from the CS domain, and the user B implements a call forwarding procedure through a user-determined user busy cause value contained in a release message. A session between the user B and an ICCF is established using a called process. The procedure shown in FIG. 2 will be described below.
201. The CSCF receives a Session Initiation Protocol (SIP) session request message at a called side initiated from the user A on a calling side to the user B on a called side. The CSCF routes the SIP session request message to a telecom application server (TAS) in charge of call forwarding services based on initial Filter Criteria (iFC) after receiving the SIP session request message.
202. The TAS routes the called SIP session request message to the ICCF through the CSCF.
203. After acquiring a roaming number of the user B, the ICCF routes the SIP session request message of the calling user to a MGCF through the CSCF.
204. The MGCF sends an Initial Address Message (IAM) of an ISDN user part (ISUP) to a VMSC.
205. The VMSC sends a call setup request to the user B, and user B begins to ring.
206. The user B rejects the call because of busyness, sends a hang-up message to the VMSC, and the hang-up message containing the user-determined user busy cause value.
207. The VMSC releases resources of this session and sends a release message to the MGCF, the release message containing the user-determined user busy cause value.
208. The MGCF generates a SIP 486 user busy message based on the user-determined user busy cause value and sends the SIP 486 user busy message to the CSCF, which in turn forwards the SIP 486 user busy message.
209. The ICCF sends back the SIP 486 user busy message to the CSCF, which in turn routes the SIP 486 user busy message to the TAS.
210. The TAS triggers the procedure of call forwarding on user-determined user busy by a call forwarding logic.
FIG. 3 illustrates a prior art scheme where on a session control path in a CS domain, a user A of an IMS calls a user B with ICS capability accessing from the CS domain, and the user B implements a call forwarding procedure by a TAS. A session between the user B and an ICCF is established using a calling process. The procedure shown in FIG. 3 will be described below.
301. The CSCF receives a called SIP session request message initiated from the user A on a calling side to the user B on a called side. The CSCF routes the SIP session request message to a telecom application server (TAS) in charge of call forwarding services based on initial filter criteria (iFC) after receiving the SIP session request message.
302. The TAS routes the called SIP session request message to the ICCF through the CSCF.
303. The ICCF determines, based on the acquired message at the called side, that a called terminal is a UE supporting an ICS, and then assigns an ICCF address (which is a dynamically assigned address) to the user B and sends the SIP session request message containing the ICCF address to the user B using USSD via the session control path in the CS domain.
304. The user B uses the ICCF address as a called number to initiate a call setup request to a VMSC immediately after receiving the SIP session request message.
305. The VMSC analyzes the ICCF address and sends an Initial Address Message (IAM) to a MGCF.
306. The MGCF generates a new SIP session request message and routes it to the CSCF based on the ICCF address, and then the CSCF routes the SIP session request message to the ICCF based on the ICCF address.
307. After receiving the SIP session request message from the user B, the ICCF sends back a SIP 180 ringing message to the CSCF, which in turn sends back the SIP 180 ringing message to the MGCF.
308. The MGCF sends back an Address Complete Message (ACM) to the VMSC after receiving the SIP 180 ringing message.
309. The VMSC sends back the SIP 180 ringing message to the user B.
In the step 307-309, the ICCF sends the ringing message to the terminal UE via the bearer control path in the CS domain to notify the UE of successful setup of the call. The notification of the ICCF is not limited to the SIP ringing message, and other messages may be used.
310. The user B begins to ring and sends the ringing message to the ICCF using USSD via the session control path in the CS domain.
The step 310 is a response to the step 303 and may be omitted without affecting the connection of the ICCF.
311. The ICCF sends the SIP 180 ringing message to the CSCF after receiving the ringing message (or after receiving the SIP session request message from the user B in step 307).
312. The CSCF notifies the user B on calling side to ring.
313. The user B is busy now, and cannot answer the session initiated by the user A on calling side, so the user B rejects the call request and sends a normally disconnecting request to the VMSC, the disconnecting request containing a normally releasing message.
314. The VMSC releases resources for this session and sends the release message to the MGCF.
315: The MGCF converts a resources-releasing request into a SIP cancel request and sends the SIP cancel request to the CSCF, which in turn routes the SIP cancel request to the ICCF and releases the session between the user and the ICCF.
It can be seen from the existing call forwarding procedure that when the call between the user B and the ICCF is established using the called process, the hang-up request sent to the VMSC by the user B may contain a user-determined user busy cause value when the user B refuse to answer the call because of busyness, thereby implementing a call forwarding service user-determined user busy. However, when the call between the user B and the ICCF is established using the calling process, the call forwarding service on user-determined user busy cannot be implemented. This is because, when the user B refuse to answer the call due to busyness, the user B is a calling party, the disconnecting request that he sent to the VMSC is incapable of carry the user-determined user busy cause value but only a normally disconnecting cause value. Thus, when the call between the user B and the ICCF is established using the calling process, the call forwarding service on user-determined user busy cannot be implemented using the existing technology.
USPTO Backgrounds
USPTO Backgrounds