Subsequent set-up of circuit-switched and packet-switched connections

This invention relates to establishing connections in a communication system such as a mobile telephony system.

<figref idref="f0001">Figure 1</figref> is a simplified diagram of one form of communications system. The structure of <figref idref="f0001">figure 1</figref> is based on the architecture of the third generation (3G) UMTS mobile communication system. The system of <figref idref="f0002">figure 3</figref> includes two user equipment devices or terminals (UE) 1, 2 which are capable of communicating by means of a network 3. Each of the terminals communicates with the network by radio, and gains access to the network 3 via a radio access network (RAN) 4, 5. The network 3 provides for two forms of communication between the terminals. Circuit-switched connections, for example for voice communication, pass between the radio access networks 4, 5 via mobile switching centres (MSC) 6, 7. Packet-switched connections, for example for data connections, pass between the radio access networks via serving GPRS support node (SGSN) 8, 9 and gateway GPRS support node (GGSN) 10,11.

Conventionally, when a connection is to be set up between two terminals the terminals decide on the basis of the nature of the proposed connection - for example the required data rate and the amount of delay that can be tolerated - whether to set up a packet switched connection or a circuit-switched connection. Some applications can be satisfied by either type of connection. For example, in many situations voice traffic can be carried satisfactorily over a circuit switched connection or a packet switched connection (for example by means of the SIP or H.323 protocol). Especially with packet switched connections data of more than one form can be carried over the link, so that (for example) voice and video data could be carried simultaneously. This provides a convenient way to implement enhanced services such as click-to-talk whiteboarding and chatting.

However, packet-switched voice is relatively new. In most existing networks voice traffic is carried almost exclusively over circuit switched links because in those networks packet switched links cannot be guaranteed to provide a sufficient quality of service; for example due to the possibility of there being delay that is excessive for voice traffic. It can be expected that in the future networks will be able to carry packet-switched traffic at a level of service that allows enhanced services of the types listed above to be supported reliably over packet-switched links. However, in the meantime, as demand for such enhanced services grows, there is a need to bridge the gap before packet switched networks of higher capability are generally available, and allow such enhanced services to be provided over more conventional networks.

Furthermore, even when networks of higher capability are available it can be anticipated that in many cases circuit-switched and packet-switched channels will be available. The inventors of the present invention have noticed that in order to balance the utilisation of bandwidth over both parts of the network it would be useful to have additional flexibility in the allocation of connections to the available forms of channel.

<patcit id="pcit0001" dnum="EP1021053A"><text>EP 1021053</text></patcit> discloses a wireless terminal arrangement and a method of data transmission channels in a multimedia connection having a parallel arrangement of a real-time channel and a non-real time packet channel. The method comprises the steps of setting up the connection by communicating connection capabilities between the communicating parties via a circuit switched connection. If both communicating parties are capable of maintaining both a real-time channel and a non-real time packet channel then both the real-time connections are established.

Request for comments (RFC) 2916 "E.164 number DNS" by P. Falstrom, Cisco Systems Incc of September 2000, discusses the use of the Domain Name System (DNS) for storage of E.164 numbers, and how DNS can be used for identifying available services and address information connected to one E.164 number.

An apparatus according to the invention is defined in claim 1 and a method according to the invention is defined in claim 10. Claim 15 defines a communication system according to the invention.

Dependent claims define more specific embodiments of the invention.

The network is preferably a mobile communication network. The terminals are preferably mobile terminals. The terminals are preferably capable of communicating over the radio interface with the network. The network and/or the terminals may be operable according to the GSM, GPRS or UMTS systems or a derivative thereof. The network may comprise one or more core networks.

The present invention will now be described by way of example with reference to the accompanying drawings, in which: <ul id="ul0001" list-style="none" compact="compact"><li><figref idref="f0001">figure 1</figref> is a schematic diagram of a communication network;</li><li><figref idref="f0001">figure 2</figref> shows a simplified functional architecture of a user equipment terminal;</li><li><figref idref="f0002">figure 3</figref> shows message flow during the setup of a whiteboard communication session;</li><li><figref idref="f0003">figure 4</figref> shows message flow during the continuation of a communication session;</li><li><figref idref="f0001">figure 5</figref> shows another simplified functional architecture of a user equipment terminal;</li><li><figref idref="f0004">figure 6</figref> shows message flow during the continuation of a packet switched communication session by a circuit switched connection;</li></ul>

The present invention will be described by way of example with reference to the architecture of a 3G network. However, it will be understood that it can be applied to any other suitable form of network.

Numerous enhanced services that users of communication services are beginning to demand make use of both highly delay-critical data, such as voice information, and associated less delay-critical data. Examples of such less delay-critical data include images to support click-to-talk services, drawings that are to be shared in whiteboard services, and supporting data on participants' actions for supporting chat services. In each of these cases, voice data should be carried as normal with minimal delay, but the supporting data can tolerate more delay. As will be described below, these services can be conveniently supported by means of simultaneous circuit-switched and packet-switched links between common end-points or terminals. Such an arrangement can be implemented in a network of the schematic form shown in <figref idref="f0001">figure 1</figref>, but with the terminals / user equipment and the network-side components having the architecture and capabilities described below.

<figref idref="f0001">Figure 2</figref> shows the functional architecture of a terminal suitable for acting as UE 1, 2 in the architecture of <figref idref="f0001">figure 1</figref>, and providing for simultaneous circuit-switched and packet-switched links between common end-points. The upper level 20 of the architecture is the user interface, which handles the interaction between lower-level components and the user. Below the user interface 20 is an application 21 running on the terminal. In this example the application is one that can support enhanced or "rich call" services. Below the application are the layers that format outgoing data or process incoming data according to packet-switched or circuit-switched requirements. In this example, the packet-switched (PS) layers comprise an upper internet protocol (IP) layer 22 and a gateway general packet radio service (G-GPRS) layer 23. The circuit switched (CS) processing is handled by a CS protocols layer 24. The PS- and CS-specific layers are effectively in parallel. Below the PS and CS layers is the radio interface to the 3G wide-band CDMA (W-CDMA).

In providing a rich call service the rich-call application (RCA) 21 is capable of communicating with both the PS-specific functionality 22, 23 and the CS-specific functionality 24. The RCA coordinates usage of CS and PS connections and provides a coherent user experience through the user interface when the service is in use.

When one terminal of the type illustrated in <figref idref="f0001">figure 2</figref> is to communicate with another such terminal by means of a rich call service, the users of each terminal activate applications 21 on their respective terminals to support the service. The applications negotiate with each other over the network 3 to determine how the service is to be provided. One possible arrangement is for the terminals to agree that more delay-critical data, such as voice data, will be sent over a circuit-switched connection between the terminals and that less delay-critical data, such as associated visual or descriptive data, will be sent over a packet-switched connection between the same terminals. Once the terminals have established that they both support such an arrangement and have agreed to proceed, the terminals establish simultaneous circuit-switched and packet-switched connections over the network, and then proceed with communication to provide the service.

One preferred means by which the PS connection may be provided is the internet protocol (IP). In this case, the terminals should know each others' IP addresses and the port numbers that are to be used in order to set up the combined CS and PS connection. This information could be communicated between the terminals using user-to-user signalling (UUS), for example. One specific approach is to use the session description protocol (SDP) with is defined in RFC-2327.

The information on terminals' IP addresses etc. could be sent during the call setup process or later during the call, for example if the users decide during a conventional call to activate an enhanced service. In normal circumstances the former approach would be preferred.

An example of the operation of the setup procedure will be described with reference to <figref idref="f0002">figure 3</figref>. The example of <figref idref="f0002">figure 3</figref> shows the setting up of a whiteboard session between users termed Ann (A) and Bob (B). <figref idref="f0002">Figure 3</figref> shows A's terminal 30 and B's terminal 31. Each terminal includes a rich call application 32, 33; an IP stack 34, 35 for handing PS communications; and a CS protocol processing arrangement 36, 37 for handling CS communications. The terminals are connected for CS communication via a mobile switching centre 38 of the network. For simplicity the PS units of the network are not shown.

In this example it is assumed that both terminals initially have active PDP contexts with assigned IP addresses. Otherwise, this could be arranged before further setup proceeds.

In the process illustrated in <figref idref="f0002">figure 3</figref>, Ann's terminal displays an icon on which Ann clicks (at 40) to initiate a call. The RCA 32 interprets the request and determines that it would be preferred to satisfy the request for a call by means of a CS connection. Accordingly, the terminal 30 and the terminal 31 communicate in the normal way as shown in steps 41 to 50 to establish a CS call between the terminals and to open a path for speech using a CS bearer channel.

The terminals suitably exchange SDP information with each other via UUS during call setup.

Then Bob decides to open a whiteboard session (at 51). The RCA 33 determines that parallel CS and PS connections should preferably be used to satisfy the requirement for voice and whiteboard data. Accordingly, the application 33 signals the IP stack 35 to initiate the whiteboard session (at 52). With knowledge of the IP address of terminal 30 the terminal 31 signals terminal 30 to invite it to initiate a whiteboard session over a parallel PS link (at 53). The IP stack 34 signals the RCA 32 that a whiteboard session is requested (at 54). Ann indicates via the user interface of terminal 30 that she accepts the whiteboard session (at 55). RCA 32 signals to IP stack that the request is accepted (at 56) and IP stack 34 returns a 200 OK message (at 57) to IP stack 35, which indicates (at 58) to the RCA that the whiteboard session is established. The whiteboard session may then continue using a packet-switched bearer channel, as indicated at 59.

As illustrated in <figref idref="f0003">figure 4</figref>, the session may continue by Ann requesting to book a meeting with Bob. To do so, meeting information is exchanged as illustrated generally at 60 using a further PS exchange. This exchange does not result in an ongoing communication session / channel of the form illustrated at 59.

When the call is to be ended Ann signals the RCA 32 that the call is to be ended (at 61). The RCA signals the IP stack 34 that the ongoing whiteboard session is to be ended (at 62) and signals the CS protocols 36 that the CS call is to be ended (at 62, 63). Disconnect messages 64, 65 are sent in the normal way. The CS protocols 37 inform the RCA 35 of the party that did not initiate the termination that the call is to be disconnected (at 66). That RCA 35 informs the IP stack 36 that the whiteboard session is to be ended and acknowledges to the CS protocols the disconnection of the call (at 67 and 68). Acknowledgements 69, 70 71 are then sent in the normal way. The CS and PS connections are handled as a single logical communication arrangement. This linkage of the connections means that it is straightforward for the terminal to terminate one of the connections if the other is terminated.

The end-user application manages the number and nature of the connections transparently from the user's point of view, so that for the user the connections can be made and terminated straightforwardly even though they are of different types.

<figref idref="f0001">Figures 5</figref> and <figref idref="f0004">6</figref> illustrate another arrangement. In the embodiment of <figref idref="f0001">figures 5</figref> and <figref idref="f0004">6</figref> the terminals of A and B include an adaptation layer 80 (see <figref idref="f0001">figure 5</figref>). The adaptation layer allows the establishment of CS or PS calls to be transparent to the application 81 that is running on the terminal. The adaptation layer can be provided in the terminals independently of any application that is to run on them. The adaptation layer sits between the application and the CS and PS communication layers. When the application issues a request for a connection the adaptation layer interprets that request and passes it to the CS or PS layers as appropriate.

<figref idref="f0004">Figure 6</figref> shows an example of an operation that is supported by terminals having the architecture shown in <figref idref="f0001">figure 5</figref>. In the example of <figref idref="f0004">figure 6</figref> it is supposed that two terminals 90, 91 are already communicating by means of a packet switched connection (see 92). The terminals have application layers 93, 94; adaptation layers 95, 96; IP stacks 97, 98 and circuit switched protocol stacks 99, 100. The terminals can communicate for CS calls via MSC 101.

User A decides to initiate a voice call with user B. User A signals the application layer 93 of her terminal to indicate that the voice call should be initiated (at 102). Since the terminals are already engaged in a PS call, in this example it is supposed that the application layer initiates the voice call by means of a request (formatted for example as indicated in <figref idref="f0004">figure 6</figref>) based on the address of the counterparty terminal as appropriate for a PS connection, e.g. in SIP (session initiation protocol) format. The adaptation layer could attempt to initiate the voice call over a PS link. However, in this example it is assumed that the adaptation layer decides that a CS bearer should be used. This decision could be made based on the adaptation unit's knowledge of the network's capabilities. As shown in <figref idref="f0004">figure 6</figref>, the adaptation layer sends an SIP INVITE message via the IP stack 97 to B's terminal. The INVITE message contains SIP parameters indicating that a CS bearer should be used and indicates the MSISDN of A's terminal (see 103). Knowledge of this MSISDN will enable B's terminal to identify the call when the setup request for the call arrives at B's terminal.

The adaptation layer in B's terminal detects the incoming INVITE message. Since the form of the INVITE message indicates a request for an incoming CS call it responds with a 200 OK message including the MSISDN of terminal B (see 104). Knowledge of the MSISDN of terminal B will enable terminal A to call that MSISDN to set up the impending CS call.

When the OK message with the MSISDN of terminal B arrives at terminal A the adaptation layer 95 of terminal A begins to establish a call to that MSISDN (see 105). The adaptation layer 98 of the receiving terminal compares the MSISDN of the incoming call to the one received in step 103. Since they match, it informs the application layer 100 of terminal B of the incoming call (at 106). The application layer 100 which responds with an acceptance message 107 and in response the adaptation layer 98 accepts the CS call (at 108). The CS call is then established (at 109) at the same time, and between the same end-points as the original IP connection 92.

The same procedure can be used if SIP proxies (or CSCFs) are involved.

Other means may be used to establish the PS connection.

If two conventional GPRS (general packet radio service) terminals are engaged in a circuit-switched call, each knows the other's E.164 number, but neither necessarily knows the other's IP address as assigned by the GGSN. In this case, if a PS connection is then to be established in parallel with the existing CS connection there is a need for a means for the terminals to access each other's IP address and any necessary firewall and/or proxy traversal information.

In this situation the SIP protocol (RFC-2543), which was originally designed for voice-over-IP calls, can be used whilst the CS call is in progress. In order to determine the SIP URL of a CS user, there is preferably a predefined mapping from E.164 identities to SIP URLs. This mapping may make use of a predefined logic, or may be stored as a look-up table. Such address mapping can be performed by the SIP proxy in the network (120 in <figref idref="f0001">figure 1</figref>). It may implement a simple mapping table, or may use a more complex database which has to be searched to determine a mapping. In the former solution, the look-up table could list the SIP proxy corresponding to each E.164 number, for example: <tables id="tabl0001" num="0001"><table frame="none"><tgroup cols="3" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="25mm" /><colspec colnum="2" colname="col2" colwidth="33mm" /><colspec colnum="3" colname="col3" colwidth="18mm" /><thead><row><entry valign="top">E.164 Number</entry><entry valign="top">SIP Proxy</entry><entry valign="top">Operator</entry></row></thead><tbody><row><entry>+358 40</entry><entry>sip.soneragprs.fi</entry><entry>SONERA</entry></row><row><entry>+358 41</entry><entry>sipgw.teliagprs.com</entry><entry>TELIA</entry></row><row><entry>+ 1 30</entry><entry>mcigprs.com</entry><entry>MCI</entry></row></tbody></tgroup></table></tables>

In the latter solution, the SIP proxy may provide in essence a DNS (domain name service) query service using DNS SRV records.

During a CS call, users know the E.164 address of the remote party. The application at an initiating terminal that is to initiate the PS bearer connection to another terminal uses the E.164 address to create a SIP INVITE (or SIP INFO) message and sends it to the local SIP proxy. The destination is the E.164 number of the other party (sent with a tag to indicate that the address is a phone number instead of a user name) and that local proxy uses its mapping table (or a more complex scheme) to determine the corresponding destination SIP proxy. The identity of the destination SIP proxy is returned to the initiating terminal. The initiating terminal sends an INVITE (or INFO) message to that destination proxy indicating the E.164 identity of the other terminal. The destination proxy determines the SIP URL address that has been allocated to the terminal using that E.164 identity. The destination proxy can then forward that request to the said other terminal by means of its IP address, and the setup of the PS connection can continue generally as normal. Note that the destination proxy can determine from the fact that there is no session information in the payload of the INVITE (or INFO) message that the message does not indicate a <u>call</u> setup.

Appropriate billing procedures can be applied, for example based on the parsed payload type or the size of the data to be transported. For example large uncompressed image files can be made more costly to transfer than smaller compressed image files. The SIP proxies can also maintain a register service which can apply different functions depending on the time of day, payload type etc. For instance, a user may define that if he receives a GIF image and the time is after 16:00 then the image is forwarded to an assigned e-mail address.

Alternatively, the SIP INVITE or INFO messages themselves could be used for transferring user data.

The present invention has been described with specific reference to the UMTS and GPRS systems. However, it is not limited to these systems.

The applicant draws attention to the fact that the present invention may include any feature or combination of features disclosed herein either implicitly or explicitly or any generalisation thereof, without limitation to the scope of any of the present claims. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.