Providing packet-based multimedia services via a circuit bearer

Background of the invention

The present disclosure relates generally to supporting packet-based multimedia services in a communications system.

Telecommunications systems, such as Universal Mobile Telecommunications System (UMTS) wireless networks, are evolving into systems that may carry both voice and data traffic via fixed, wireless, and satellite networks. Part of this evolution includes developing and providing packet frameworks for the delivery of IP based, real-time, conversational, multimedia services. For example, an IP multimedia subsystem (IMS) standard has been defined as part of a third generation partnership project (3GPP) to provide such services.

Standards (such as IMS) that address the delivery of multimedia services via a packet based network generally require quality of service (QoS) mechanisms that are intended to ensure a certain level of quality. However, most wireless packet networks require relatively substantial enhancements before such QoS mechanisms can be provided, which slows down the implementation of the associated standards. For example, while IMS provides a framework to support the delivery of multimedia services in a wireless network, most wireless networks need upgrades to their access/radio layers, as well as to their packet core/general packet radio service (GPRS) subsystems before IMS can be properly supported. Implementing these upgrades may involve a considerable amount of time and expense, as the upgrades will need to be developed, deployed and tested.

Accordingly, what is needed is an improved system and method to provide for the delivery of IP based, real-time, conversational, multimedia services. It is desirable to deliver these services to mobile devices via networks that may not support QoS mechanisms specified for the delivery of such services, or networks which are not capable of efficiently carrying IP based traffic.

Summary of the invention

Accordingly, an aspect of the present invention provides a method for providing a packet-based multimedia service to a terminal in a network. A packet signaling connection is established between the terminal and the network. A circuit bearer connection is established between the terminal and the network. Signaling information for the multimedia service is transferred via the packet signaling connection and data for the multimedia service is transferred via the circuit bearer connection.

Using a circuit bearer connection to carry data for the packet-based multimedia service has several advantages. Where the packet-switched capabilities of a network do not support the quality of service (QoS) demanded by the multimedia service, the circuit bearer can be used to ensure that data is carried in a manner that meets the required QoS. Alternatively, where data for the multimedia service can be carried more efficiently by the circuit bearer, it is advantageous to use a circuit bearer to carry the data, even if the packet-switched capabilities of the network would support the required QoS. An example of this is where the multimedia service is a voice-based service. Many networks are optimised to efficiently carry voice data, and it is more efficient to carry voice data over a circuit bearer connection rather than packing the voice data into IP packets where voice-specific optimizations may not be applied.

The circuit bearer can be used on just one leg of the total path between the terminal and a called party. The circuit bearer can be local to an end-user terminal and is treated simply as a bearer for the first `hop` of a Media Component in a Session Initiation Protocol (SIP) session. The circuit bearer connection can be established by a network entity or by the terminal. Preferably, the circuit bearer is interworked to a packet-switched bearer at some point in the network, such as at a gateway, so as to provide a remote party with the appearance that a fully packet-switched connection is being used. Thus, the remote party can continue to use the normal packet-switched protocols for signalling and bearer traffic.

The method can be used at the start of a call. The method can also be used part-way through an existing call to transfer an ongoing packet-based call (e.g. a SIP VoIP call) to the circuit-switched domain over at least one leg of the call. This situation can arise if a mobile user moves away from an area where coverage is provided by a wireless local area network (WLAN) or 3G network, which supports a packet-switched bearer connection, to an area where coverage is provided by an alternative network which is not optimised to support a packet-switched bearer connection.

In one embodiment, a method is provided for providing a packet-based multimedia service to a mobile device in a network. The service is defined by a telecommunications standard, and the network does not support efficient packet quality of service (QoS) functionality as required by the standard. The method comprises establishing a packet signaling connection and a circuit bearer connection between the mobile device and network. Signaling information for the multimedia service is transferred via the packet signaling connection in alignment with the standard. Data for the multimedia service is transferred via the circuit bearer connection in alignment with the standard. This provides the multimedia service to the mobile device via the network as specified by the standard, even though the network does not support the required QoS functionality. The circuit bearer is used in a manner which complies with normal circuit bearer standards and so there is no requirement to change the way in the circuit network operates.

In addition to the data which is carried over the circuit bearer connection, other data for the multimedia service can be carried via a packet-switched connection. Typically, this is data which does not have strict QoS requirements, or data which is best carried in packet form rather than via a circuit bearer, such as Instant Messaging.

The invention is particularly useful with wireless communications systems which lack the packet QoS functionality required by a service or which cannot efficiently carry the data in packet form, although it can equally be applied to any situation in which a terminal has access to both a packet-based connection (such as a low-bandwidth IP connection) and also a circuit bearer (such as a telephony) connection.

Further aspects of the invention relate to methods of operating a control entity at a terminal and to a method of operating a control entity in the network. Still further aspects of the invention relate to a control entity which implements these methods.

The functionality described here can be implemented in software, hardware or a combination of these. Accordingly, further aspects of the invention provide a computer program product for implementing any combination of the steps of the methods according to the invention. It will be appreciated that the software can be installed on the host apparatus (e.g. a network entity such as an application server or the terminal) at any point during the life of the equipment. The software may be stored on an electronic memory device, hard disk, optical disk or other machine-readable storage medium. The software may be delivered as a computer program product on a machine-readable carrier or it may be downloaded directly to the host via a network connection.

Brief description of the drawings

FIG. 1 shows a flowchart of an exemplary method for providing multimedia services to a mobile device using a circuit bearer;

FIG. 2 shows an exemplary UMTS wireless network in which the method of FIG. 1 may be implemented;

FIGS. 3 and 4 show embodiments of an architecture that may be used to implement the method of FIG. 1 within the system of FIG. 2;

FIG. 5 shows a terminal for implementing the method according to the invention;

FIGS. 6 and 7 shows call flows of a call set-up in which a circuit bearer is requested by a network via a media gateway within the architecture of FIG. 3;

FIG. 8 shows a call flow of the terminating leg of a call where a circuit bearer is initiated by the network;

FIG. 9 shows a call flow of a call set-up in which a circuit bearer is requested by a mobile device within the architecture of FIG. 3;

FIG. 10 shows a call flow in which a mobile device establishes an outgoing circuit bearer;

FIG. 11 shows a call flow for a terminating leg of a call in which a terminal establishes an outgoing circuit bearer;

FIG. 12 shows a call flow for a call set-up in which call control is performed by the mobile device;

FIG. 13 shows a call flow for a call set-up in which call control is performed by the mobile device, and devices at both ends of the connection can support a circuit bearer;

FIGS. 14-17 show call flows where a circuit bearer is established during an existing call session;

FIG. 18 shows another embodiment of an architecture that may be used to implement the method of FIG. 1 within the system of FIG. 2;

FIG. 19 shows a call flow of a call set-up in which a circuit bearer is requested by a network via an intelligent gateway within the architecture of FIG. 18;

FIG. 20 shows yet another embodiment of an architecture that may be used to implement the method of FIG. 1 within the system of FIG. 2;

FIG. 21 shows a call flow of a call set-up in which a mobile device initiates a call to a network within the architecture of FIG. 20; and

FIG. 22 shows a call flow of a call set-up in which a network initiates a call to a mobile device within the architecture of FIG. 20.

Detailed description

The present disclosure relates generally to supporting Internet protocol (IP) based multimedia services using a combination of an IP connection and a circuit bearer. While the main embodiments describe the application to wireless communications systems it could equally apply to any situation in which there exists a packet-based connection (such as a low-bandwidth IP connection) and also a circuit bearer (such as a telephony) connection. It is understood that the following disclosure provides many different embodiments or examples. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting. In addition, the present disclosure may repeat reference numerals and/or letters in the various examples. This repetition is for the purpose of simplicity and clarity and does not in itself dictate a relationship between the various embodiments and/or configurations discussed.

Referring to FIG. 1, in one embodiment, a method 100 may be used to provide a packet-based multimedia service to a mobile device in a network. As will be described later in greater detail, the service is defined by a telecommunications standard that specifies quality of service (QoS) functionality for packet-based data transfers. However, the network does not efficiently support such QoS functionality. Accordingly, the method 100 may be used for providing the multimedia service in accordance with the standard on the non-compliant network.

In step 102, a packet signaling connection may be established between the mobile device and network. This signaling connection may use, for example, a signaling protocol that provides call setup, routing, authentication, and other messages to endpoints within an IP network. In step 104, a circuit bearer connection is established between the mobile device and network. Because the circuit bearer and packet signaling connections exist simultaneously, the mobile device should have functionality that supports this dual connection operation.

In step 106, signaling information and data associated with the multimedia service may be transferred between the network and the mobile device. For example, in step 108, signaling information for the multimedia service may be transferred via the packet signaling connection in alignment with the standard. In step 110, data for the multimedia service may be transferred via the circuit bearer connection in alignment with the standard. It is understood that steps 108 and 110 may occur simultaneously, as signaling and data transfer may occur throughout a communication session. Accordingly, the method 100 enables the multimedia service to be provided to the mobile device via the network as specified by the standard, even though the network does not support the specified QoS functionality.

Referring now to FIG. 2, a telecommunications network 200 illustrates a system in which the method 100 described in reference to FIG. 1 may be practised. In the present example, the network 200 is a wireless network that supports both voice and data packet communications using General Packet Service Radio (GPRS) and/or Universal Mobile Telecommunications System (UMTS) technologies.

The network 200 comprises a Radio Access Network (RAN) 202 and a core network 204. The core network 204 further comprises a circuit domain 206 and a packet domain 208. Other networks may be accessible to the network 200, such as a Public Switch Telephone Network (PSTN) 210 (connected to the circuit domain 206), Internet 212, and an X.25 network 214 (both connected to the packet domain 208).

The RAN 202 includes a plurality of cells (not shown) serviced by base transceiver stations (BTS) 216, 218, and 220. The BTS 216 is connected to a base station controller (BSC) 222 to provide a second-generation wireless network. The BTSs 218, 220 are accessible to radio network controllers (RNCs) 224, 226, respectively, to provide a third-generation wireless network. A mobile switching center/visitor location register (MSC/VLR) 228 may be used to connect the core network 204 with other networks, such as the PSTN 210. A home location register (HLR) 230 may be accessible to the MSC/VLR 228 and also to a serving GPRS support node (SGSN) 232 and a gateway GPRS support node (GGSN) 234 in the packet domain 208.

The network 200 enables at least one mobile device 236 to establish a communication session with another device via the BTS 216. For example, a request to establish a communication session with the mobile device 236 may be directed by the MSC/VLR 228 to

a second mobile device 238,

a voice terminal (not shown) coupled to the PSTN 210, or

a data terminal (not shown) coupled elsewhere to the telecommunications network 200. For example, if the communication session is a circuit data transfer session, the request may be to connect the mobile device 236 to a computer or other data device via the network 200. If the communication is a packet data transfer session, the request may be routed through the SGSN 232, the GGSN 234, and to the Internet 212. It is noted that the mobile devices 236 and 238, while illustrated as mobile telephones, may be any mobile device capable of communicating via the network 200. Furthermore, the mobile devices 236, 238 may be capable of simultaneous circuit/data (e.g., packet) connections. It is understood that the network 200 is for purposes of illustration and the present disclosure may be equally applicable to other networks.

Referring now to FIG. 3, an architecture 300 may be used to implement a call session representing the method 100 of FIG. 1. In the present example, the call session may be requested by the network via a media gateway or by an end user, such as a mobile station. The session is to provide IP based, real-time, conversational, multimedia services. For example, the services may be provided using an IP multimedia subsystem (IMS), which is defined as part of a third generation partnership project (3GPP). Providing these services in compliance with 3GPP may require certain QoS mechanisms that may not exist in some networks, such as QoS for packet and access layers associated with the telecommunications network 200 of FIG. 2. Accordingly, the architecture 300 enables the use of 3GPP IMS services prior to the introduction of the IP QoS mechanisms as follows, although it is understood that the present disclosure may also be implemented in a network in which such QoS mechanisms do exist.

The Session Initiation Protocol (SIP) has been adopted by the 3GPP IMS for the transport of multimedia services. SIP messaging is based on a request-response paradigm and may be divided into SIP request messages and SIP response messages. SIP request messages include INVITE (which initiates a call or changes call parameters), ACK (which confirms a final response for INVITE), BYE (which terminates the call), CANCEL (which cancels an ongoing INVITE), OPTIONS (which queries a server about its capabilities), REGISTER (which registers with the location service), and INFO (which sends in-progress information). The SIP response messages may contain response codes such as 100 (continue), 180 (ringing), 200 (OK), 302 (moved temporarily), 401 (unauthorized), and 600 (busy). The use of SIP enables flexibility in the call session, and may also serve to align the call session with known standards, such as 3GPP IMS. A part of SIP is the Session Description Protocol (SDP) which is used, inter alia, to declare capabilities of network entities.

The architecture 300 comprises a signaling path 302 and a bearer path 304 between a mobile station (MS) 306 (which will also be called a User Equipment UE-A) and another party 308 (which will also be called a User Equipment UE-B). Mobile station 306 can be a dual mode mobile phone which is capable of simultaneous circuit and data connections. The MS 306 is connected to a GGSN 310 via a packet domain connection 312 (e.g., using dynamic host configuration protocol (DHCP), domain name service (DNS), etc.) The GGSN 310 is connected to a Proxy Call Session Control Function (P-CSCF) 314 which, in turn, may communicate with a Serving Call Session Control Function (S-CSCF) 316. It is understood that other network entities may be used, such as an Interrogating Call Session Control Function (I-CSCF) (shown with the S-CSCF 316). The P-CSCF 314 may provide a point of contact in a visited network after the MS 306 is registered in the network. The S-CSCF 316 may be used to identify privileges associated with the MS 306, as well as for selecting and providing access to a home network application server (315). The I-CSCF (also 316) may be used to locate the S-CSCF and hide the S-CSCF's network architecture. The P-CSCF 314 and I/S-CSCF 316 may be viewed as functional blocks that may be located on any of a plurality of network nodes, including within the GGSN 310. The I/S-CSCF 316 communicates with the called party 308 via SIP messaging. A SIP Application Server (AS) 315 supports various SIP services. The SIP AS is connected to the I/S-CSCF via an ISC interface which carries SIP messaging. A Home Subscriber Server (HSS) acts as a repository for data relating to subscribers, including authentication information and information on the services that each subscriber is authorized to access. The I-CSCF and S-CSCF communicate with the HSS using the Cx interface, in order to obtain this information so that subscribers can be authenticated and authorized for access to the network and services. Similarly, the AS 315 communicates with the HSS using the Sh interface for the same purposes. A Media Gateway Control Function (MGCF) provides for routing of calls outside the IP Multimedia Subsystem. The MGCF communicates with SIP entities in the IMS (CSCFs) and also with call handling entities within the circuit switched network. It also communicates with a Media Gateway to control the mapping of user data (media) between IMS and Circuit Switched domains.

The MS 306 is also connected to a media gateway (MGW) 318 via a circuit domain connection 320. The MGW 318 can communicate with the called party (UE-B) 308 via an IP bearer path 322. In the present example, the MGW 318 converts the circuit-switched bearer traffic received from the MS 306 via the circuit domain connection 320 into IP packet based bearer traffic. The circuit-switched bearer 320 may be initiated by the MS 306 or by an intelligent node in the network, such as the MGW 318. As will be shown later in greater detail, the messaging used to establish the call session within the architecture 300 enables the session to accommodate later network changes, such as the implementation of QoS mechanisms. It is noted that the circuit domain connection 320 is used solely for bearer traffic to and from the MS 306, while signaling information is routed via the P-CSCF 314. Called party 308 (and any other entities to the right hand side of FIG. 3) see a conventional VoIP call 330. In the following description the provision of a Circuit Bearer connection for at least part of the bearer path between a calling party

and called party (308), as part of a SIP session, will be referred to as a SIP Circuit Bearer (SCB).

A fully packet-switched SIP service would firstly establish a connection between the MS 306 and called party 308 using SIP signalling, identifying both parties, such that data packets which carry data for the service can be routed across the network via an IP bearer. Where a SIP Circuit Bearer is used a part of the bearer path--in this case between the mobile device MS 306 and gateway MGW 318--is provided by a circuit-switched connection. As part of the SIP signalling, the called party UE-B 308 is provided with the address of the gateway MGW 318 so that data packets are correctly routed to the gateway 318 rather than the mobile device 306.

Three functional elements are added to a conventional network to support a SIP circuit bearer (SCB). Firstly, a Circuit Bearer Control Function (CBCF) performs third party call control to mediate between the SIP Circuit Bearer 320 and IP bearer 322. The CBCF sits in the signalling path 302 and presents the appearance of a standard SIP call using IP bearers 322 to the terminating SIP user agent (called party UE-B 308). It also instructs a Circuit Bearer Originating Function (CBOF), which may reside in the network or the terminal, to initiate a circuit bearer call 320.

Secondly, a Circuit Bearer Originating Function (CBOF) originates the Circuit Bearer portion 320 of the call towards a telephone number (an E.164 number) provided by the CBCF. The CBCF may already be configured with the E.164 number (in the case that it is fixed as part of the network coordination) or the CBCF will have to obtain the number from the CBTF. If the CBOF is within the network, as shown in FIG. 3, (rather than at the client as shown in FIG. 4), then it will need to provide the IP address/port of the gateway MGW to the CBCF in order for the CBCF to provide them to the called party.

Finally, a Circuit Bearer Termination Function (CBTF) terminates the Circuit Bearer portion of the call. It can allocate a circuit number that can be used to route a call from the CBOF, receives the incoming circuit call and notifies the CBCF (if required). If the CBTF is in the network, then the "call" is routed through the MGW/MGCF (which turns it from a circuit call to a SIP call) and onwards to the CBTF. For compatibility reasons, it is desirable that the MGW/MGCF is not modified to provide any additional functionality specific to SIP Circuit Bearer, and just converts the call as it would any other call. The CBTF in this case will act as a terminating SIP User Agent.

There are various ways in which these functional elements can be added to the network. FIG. 3 shows a solution where most of the functionality is provided in the network. The call control (CBCF) and circuit bearer originating functions (CBOF) are provided in the network, and a convenient place for these is a SIP Application Server (AS) 315. The mobile device MS is modified to include a circuit bearer terminating function (CBTF) so that it can respond to a circuit bearer initiated by the network. FIG. 4 shows a solution where most (or all) of the functionality is provided at the terminal. The call control (CBCF) and circuit bearer originating and terminating functions (CBOF/CBTF) are part of the terminal. As a further alternative, both the network and terminal can have one or more of the CBCF, CBOF and CBTF functional elements. This allows either the terminal or network to control the SIP circuit bearer call, and either the terminal or network to establish the circuit bearer leg 320 of the call. Signalling messages (SDP) can indicate whether the terminal wishes to make or receive the Circuit Bearer call (or whether it doesn't care) and this can be negotiated between the network and terminal. If the terminal supports a CBCF, then it can indicate support for a standard VoIP media component within the Session Description (SDP). If this media component is accepted by the called party, the terminal will invoke the CBCF to establish the circuit bearer and obtain the VoIP parameters (address/port of the MGW) that need to be passed to the called party. In the case that the terminal supports CBTF or CBOF, then it can indicate that it supports SIP Circuit Bearer within the Session by including a separate media component with SCB parameters. The network may then invoke its own CBCF. If the network supports a network-based Circuit Bearer Control Function, then it is preferred that this is used to control the SCB. If the network does not have it's own Circuit Bearer Control Function (CBCF) then the terminal can detect this and perform the CBCF function itself

It is preferable that a terminal supports the SIP Circuit Bearer mechanism in a manner which is transparent to the user such that a user is not made aware of the difference between a SIP Circuit Bearer call and a normal SIP call in any way. To achieve this, it is preferred that the terminal includes the following: standard 3GPP IMS call control capabilities; the ability to request SIP Circuit Bearer in its SDP, the ability to recognise a SIP Circuit Bearer request in incoming SDP; the ability to recognise and silently accept an incoming SIP Circuit Bearer call or to automatically make an outgoing SIP Circuit Bearer call; to associate a SIP Circuit Bearer Call with the corresponding SIP session in a transparent manner; and the ability to support simultaneous CS domain and PS domain connections.

FIG. 5 shows the main parts of a terminal which is adapted to support SIP Circuit Bearer. An IMS Client 250 supports SIP signalling and real-time packet-switched multimedia services 255. The IMS Client 250 is connected to a packet-switched (PS) domain interface 280 which formats signals for transmission and reception along a PS connection. The IMS client 250 includes one or more of the CBCF, CBOF and CBTF functions described above to support the SIP Circuit Bearer. IMS Client 250 is connected to a circuit-switched telephony function and a circuit-switched domain interface 290, which allows the terminal to transmit and receive CS data over a CS connection when a SIP Circuit Bearer is required. Both the PS domain interface 280 and CS domain interface 290 connect to a radio interface 295 which includes conventional coding and modulation functions for transporting the PS and CS signals over a radio interface. A user interface 260 includes conventional features such as a microphone, loudspeaker, display and keypad. The functions of the IMS Client 250 and blocks 270, 280, 290, 295 are typically realised as software executed by a microprocessor, by a combination of hardware and software, or by dedicated processing equipment.

A number of different call flows will now be described to illustrate the various ways in which embodiments of the invention can operate. In each of these call flows it is assumed that the terminal is aware that a SIP Circuit Bearer (SCB) is required, i.e. the terminal knows that the current access system is not optimised for supporting native VoIP. All call flows begin with the terminal sending an INVITE message with the SCB SDP, requesting a SCB. If the terminal supports it's own CBCF then it will indicate in the SDP that it would like either a SCB connection or a normal VoIP connection--the `normal VoIP` SDP is included because the terminal can convert this into a SIP Circuit Bearer by using it's own CBCF. There are four main possibilities: 1. The terminal has indicated that it accepts incoming SCB calls. The network detects the SCB SDP and invokes the Circuit Bearer Control Function. The network makes the CS call to the terminal and links it to the SIP session. The network provides information in the form of SDP of the Media Gateway to the far endpoint. This includes the IP address of the Media Gateway. 2. The terminal has indicated that it wishes to make an outgoing SCB call. The network detects the SCB SDP and invokes the Circuit Bearer Control Function. The network CBCF responds to the terminal with the E.164 number that should be used for the circuit bearer connection. The terminal makes the CB call and the CBTF in the network receives the call and forwards to the CBCF. The network CBCF then provides the SDP of the Media Gateway MGW to the far endpoint. 3. The network does not recognise the SCB SDP, i.e. the network does not have a CBCF, and the SDP is forwarded to the far endpoint, which also does not recognise it but accepts the VoIP part of the call. The calling terminal invokes it's own CBCF and the call flows continue as in

or

with the terminal performing the CBCF function and either CBOF or CBTF. 4. The network does not recognise the SCB SDP and it is forwarded to the far endpoint, which does recognise it. According to the preference indicated by the calling terminal, the called or calling terminal invokes a CBOF to establish a Circuit Bearer directly between the two endpoints. As the Circuit Bearer is established directly between CBOF and CBTF at the two endpoints there is no need for mediating between a Circuit Bearer and a VoIP connection and hence no need for a CBCF. A further possibility in this case is that the SCB parameters negotiated in the session description identify an already established CS domain call between the two endpoints. In this way, an IMS session can be established making use of a pre-existing CS domain call between the two users.

For simplicity, some network entities have been omitted from the call flows, such as the various CSCFs that signaling messages would be routed through. Where there is a network based CBCF, it is shown as an individual entity although it will, in reality, be provided at the P-CSCF, S-CSCF or SIP AS. The call flows are the same, although the discovery of information such as E.164 numbers may differ. The terminal UE-A has a CS domain subscription with a Mobile Station ISDN number (MSISDN) +447710875525. When the CBCF is network-based, it operates a full back-to-back User Agent, meaning that it acts as a SIP User Agent Server towards the originating SIP User Agent and as a SIP User Agent Client towards the terminating SIP User Agent, mediating between the two.

We consider the case that UE-A wants to use a SIP Circuit Bearer. This is transparent to UE-B in Cases 1-3. UE-B may also use SCB, in which case (for cases 1-3) the call flow for UE-B is essentially the mirror of that for UE-A. Messages that are tagged with an asterisk symbol `*` indicate that pre-conditions are not yet met. SDP extensions are required for describing a Circuit Bearer. These are outlined in the Appendix.

FIG. 6 generally shows a first call flow in which the network manages the call flow, and the network initiates the SCB. Data is carried over a first leg of the session by circuit domain connection 320. This may be accomplished by establishing a signaling PDP context between the MS 306 and the P-CSCF 314 (via the GGSN 310). SIP signaling then occurs between the MS 306 and the P-CSCF 314 to establish a call session. Network services may be executed using the S-CSCF 316, and a circuit bearer is requested to establish the circuit domain connection 320. A second leg of the connection is established to the other party 308 via the MGW 318 using either a packet or circuit connection. The MGW 318 then bridges both the first and second legs to connect the MS 306 and other party 308. In the call flow 400, the MOW 318 is used to establish the circuit domain connection 320. As shown in FIG. 6, the call flow 400 includes the MS 306, the P-CSCF 314, the I/S-CSCF 316, and the MGW 318. The call flow 400 relies heavily upon SIP messaging.

The call flow 400 begins in step 402 when the MS 306 sends a SIP INVITE message to the P-CSCF 314. The INVITE message includes an initial session description protocol (SDP) packet in the SIP INVITE message body. SDP is a protocol that may be used to indicate a multimedia session, and may include such information as a session name and purpose. The SIP INVITE message is forwarded from the P-CSCF 314 to the MGW 318 via the I/S-CSCF 316.

The MS 306, P-CSCF 314, I/S-CSCF 316, and MGW 318 conduct SDP negotiations via SIP messages in step 404. These negotiations may include SDP answer, SDP offer, SDP success, and SDP answer exchanges. The SDP negotiations include a reservation of circuit resources by the MGW 318, as indicated by step 406.

In step 408, the P-CSCF 314 utilizes a Policy Control Function (PCF) mechanism to authorize QoS resources requested during the SDP negotiations in step 404, which may occur multiple times during the SDP negotiations. In the present example, this a NULL operation because no QoS is being requested (i.e., conversational grade QoS is inherent in the circuit domain connection 320 and need not be requested). In step 410, the MGW 318 sets up first and second circuit legs to the MS 306 and the other party 308, respectively.

The MGW 318 receives a ringing indication in step 412 and maps the ringing indication to a SIP ringing response message, which is then sent to the MS 306 via the I/S-CSCF 316 and P-CSCF 314. When the MGW 318 receives an answer indication in step 414, it relays this information as a SIP OK message to the P-CSCF 314 via the I/S-CSCF 316 in step 416. The P-CSCF 314 utilizes the PCF to commit the requested QoS in step 418, which is a NULL operation because no QoS was requested. The P-CSCF 314 then forwards the SIP OK message to the MS 306 in step 420. The MS 306 may then begin using the media resources authorized and committed in the call set-up in step 422. In step 424, the MS 306 sends a SIP ACK message to the I/S-CSCF 316 via the P-CSCF 314.

FIG. 7 shows a similar call flow in greater detail. The Circuit Bearer Control Function (CBCF) is network-based and the Circuit Bearer is initiated by a CBOF in the network. For clarity the CBOF and CBTF are not explicitly shown but the CBOF is collocated with the CBCF and the CBTF is at UE-A. The call flow begins at step 1 when UE-A sends a SIP INVITE message which is addressed to UE-B (the called party). UE-A knows that the access network is not optimised to support VoIP and so it includes SDP declaring that UE-A supports SIP Circuit Bearer. This SDP also indicates that UE-A supports the Circuit Bearer Terminating Function (i.e. that the UE is capable of receiving an incoming Circuit-switched connection for SCB) and the address to which the SCB call should routed (which will be a MSISDN allocated to UE-A). This number may be a special number allocated to the UE for SIP Circuit Bearer purposes or it may be the normal MSISDN of the terminal. This information can be indicated using suitable extensions to the Session Description Protocol, as described in the Appendix. Alternatively, the capabilities of UE-A may already be known to the network, based for example on the user identity. In this case, the network may automatically retrieve the relevant parameters from a database of subscription information, such as the HSS (FIG. 3).

The INVITE message is received by the CBCF, which recognises that UE-A supports SCB. The CBCF removes the SCB field from the SDP, adds the standard VoIP field, and then forwards the modified INVITE message to UE-B at step 2. UE-B replies, at step 3, with a message indicating that it supports VoIP. The CBCF then forwards a modified message to UE-A, at step 4, indicating that the network CBCF supports SCB. This message also includes the CLI of the CBOF that will be making the circuit bearer call.

The CBCF then instructs the CBOF to initiate the circuit bearer leg of the call. A SIP INVITE message is sent to the Gateway, at step 5, which includes the circuit bearer number of UE-A. The Gateway initiates, at step 6, a circuit call to UE-A. UE-A recognises the circuit bearer call and responds, preferably without ringing to alert the user. The terminal knows to associate this call with the existing SIP call as it has already been told the CLI of the CBOF that will be making an incoming call and is expecting the incoming call.

Having established a circuit bearer call between UE-A and the Gateway, the CBCF informs UE-B of the IP address of the Gateway in a SIP UPDATE message. A VoIP connection is established between the Gateway and UE-B. In parallel with the above steps, on receiving and answering the incoming Circuit call, UE-A sends an UPDATE message (Step 14) towards the CBCF. This message updates session description information indicating that the pre-conditions for the session have now been met. This is according to standard procedures in which sessions are established with "pre-conditions" which are then cleared when the resources necessary for the session have been established. The CBCF forwards the UPDATE towards UE-B, making appropriate modifications to the session description to replace the references to SCB with standard VoIP parameters. It should be noted that steps 14-17 could occur either before or after steps 12-13. In messages to UE-B then pre-conditions will only be marked as `met` when both messages 10 and 14 have been received by the CBCF.

According to standard procedures, on receipt of an indication that pre-conditions have been met, UE-B can begin alerting the terminating user UE-B. UE-B returns a message (at step 18) to indicate that called party alerting has begun. This is passed to UE-A by the CBCF. When the called user answers the call, this is indicated by messages at steps 20 and 22. At step 23 the connection is cut-through in both directions, to establish an end-to-end connection which comprises the circuit domain connection between UE-A and the Gateway and the packet-domain connection between the Gateway and UE-B. It should be noted that UE-B is not aware that a SIP Circuit Bearer is in use between UE-A and the network.

FIG. 8 shows a call flow for the situation where a SIP circuit bearer is established at the terminating leg of a call to terminal UE-B. Terminal UE-A initiates a call by sending a SIP INVITE message towards UE-B, indicating that a VoIP connection is required. The CBCF intercepts the message. Knowing that the network which will be used for the terminating leg of the call is not optimised for VoIP, the CBCF forwards the message at step 2, substituting an indication that SCB should be used. Note that, alternatively, the CBCF may add an indication that SCB is available, leaving it to UE-B to determine whether SCB or standard VoIP should be used. UE-B responds at step 3, indicating that it supports SCB. The CBCF instructs a Gateway to initiate a circuit call to UE-B at step 5. The circuit call is set up between the Gateway and UE-B at steps 6-8 in a similar manner to the previously described call flow.

The description continues in the full USPTO document.