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

SUBSEQUENT CONFIGURATION OF CIRCUIT SWITCHING AND PACKAGE SWITCHING

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

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

Conventionally, when a connection is to be configured 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 if a packet-switched connection or a circuit-switched connection. Some applications can be satisfied by any kind of connection. For example, in many situations voice traffic can be satisfactorily carried over a circuit-switched connection or a

ΕΡ2265080Β1 packet switching (for example through the H.323 or SIP protocol). Especially with packet-switched links data of more than one form may be carried over the link so that (for example) video and voice data could be carried simultaneously. This provides a convenient way to implement enhanced services such as chat and click-to-talk whiteboards.

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

In fact, even when larger capacity networks 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 noted that in order to balance bandwidth utilization across both parts of the network it might be useful to have additional flexibility in allocating links to available channel shapes.

Document 1021053 discloses a wireless terminal arrangement and a method of data transmission channels in a multimedia connection which has a parallel arrangement of a real-time channel and a non-real-time packet channel. The method comprises the steps of configuring the link by communicating link capacities between the communicating parties via a circuit-switched link. If both communicating parties are able to maintain a real-time channel war against a non-real-time packet channel then both real-time links 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 storing E.164 numbers, and how DNS can be used to identify available services and address information linked to an 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 further 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 via the radio interface with the network. The network and / or terminals may be operable according to GSM, GPRS or UMTS systems or a derivative thereof. The network may comprise one or more core networks.

ΕΡ2265080Β1

The present invention will now be described by way of example with reference to the accompanying drawings, in which:

Figure 1 is a schematic diagram of a communication network;

Figure 2 shows a simplified functional architecture of a user equipment terminal;

<td>Figure 3</td><td>show</td><td>flow</td><td>in</td><td>message</td><td>during</td><td>The</td>

<td>configuration</td><td>of a</td><td>session</td><td>in</td><td>Communication</td><td colspan="2">of frame</td>

<td>White;</td><td></td><td></td><td></td><td></td><td></td><td></td>

<td>Figure 4</td><td>show</td><td>flow</td><td>in</td><td>message</td><td>during</td><td>The</td>

<td colspan="3">continuation of a session of</td><td colspan="2">Communication;</td><td></td><td></td>

<td>Figure 5</td><td>show</td><td>other</td><td colspan="2">architecture</td><td colspan="2">functional</td>

<td>simplified</td><td>on one</td><td colspan="2">terminal</td><td colspan="2">of equipment</td><td>in</td>

<td>user;</td><td></td><td></td><td></td><td></td><td></td><td></td>

<td>Figure 6</td><td>show</td><td>flow</td><td>in</td><td>message</td><td>during</td><td>The</td>

continuing a packet-switched communication session over a circuit-switched connection;

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 communication service users are beginning to request make use of either highly critical delay data such as voice information or associated less critical delay data. Examples of such less critical delay data

62265080Β1 include images to support click-to-talk services, drawings that are to be shared on whiteboard services, and support data on participant actions to support chat services. In each of these cases, voice data could be carried as normal with minimal delay, but supporting data may tolerate more delay. As will be understood, these services may conveniently be supported by circuit-switched and simultaneous packet-switched connections between common terminals or endpoints. Such an arrangement may be implemented in a network of the schematic form shown in Figure 1, but with the user terminals / equipment and the network side components having the intrascribed architecture and capabilities.

Figure 2 shows the functional architecture of a terminal suitable for acting as UE 1, 2 in the architecture of Figure 1, and providing simultaneous circuit-switched and packet-switched connections between common endpoints. Upper level 20 of the architecture is the user interface, which deals with the interaction between lower level components and the user. Under the user interface 20 is an application 21 running on the terminal. In this example the application is one that can support rich or enhanced calling services. Under application are layers that format output data or process input data according to the requirements by packet switching or circuit switching. In this example, the packet switched layers (PS) comprise an upper internet protocol (IP) layer 22 and a general gateway radio service layer (GGPRS) 23. Circuit switching (CS) processing is handled by a CS 24 protocol layer. The specific layers PS and CS are effectively in parallel. Under the

ΕΡ2265080Β1 layer PS and CS is the radio interface for 3G CDMA (W-CDMA) broadband.

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

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

Preferred means by which the PS connection may be provided is the internet protocol (IP). In this case, the terminals should know each other's IP addresses and the port numbers that are to be used to configure the combined CS and PS connection. This information could be communicated between terminals using signaling.

ΕΡ2265080Β1 user-user (UUS), for example. A specific approach is to use the session description protocol (SDP) as defined in RFC-2327.

Information about terminal IP addresses etc. it could be sent during the call setup process or later during the call, for example if users decide during a conventional call to activate an enhanced service. Under normal circumstances the old approach could be preferred.

An example of the operation of the setup procedure will be described with reference to Fig. 3. The example of Fig. 3 shows the setup of a whiteboard session between users named Ann (A) and Bob (B). Figure 3 shows A 30 terminal and B 31 terminal. Each terminal includes a rich calling application 32, 33; an IP stack 34, 35 to deliver PS communications; and a CS protocol processing arrangement 36, 37 for handling CS communications. The terminals are connected for CS communication via a mobile network switching center 38. For simplicity PS network drives are not shown.

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

In the process illustrated in Figure 3, Ann's terminal shows an icon where Ann clicks (at 40) to initiate a call. RCA 32 interprets the request and determines that it would be preferable to satisfy the request for a call over a CS connection. Consequently, terminal 30 and terminal 31 communicate in the normal manner as shown in steps 41 to 50 to establish a CS call between

Terminais2265080Β1 terminals and open a path for speech that uses a CS bearer channel.

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

So Bob decides to open a whiteboard session (in

51). RCA 33 determines which CS connections

Parallel PS should preferably be used to satisfy the whiteboard data requirement.

Consequently, application 33 signals to start the whiteboard (in 52) voice session.

IP 35 battery

Knowing the IP address of terminal 30 terminal 31 signals terminal 30 to invite you to start a whiteboard session via a parallel PS connection (at 53). IP stack 34 signals RCA 32 that a whiteboard session is requested (at 54). Ann indicates via terminal user interface 30 that she accepts the whiteboard session (at 55). RCA 32 signals the 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 can then continue using a packet-switched bearer channel, as indicated at 59.

As illustrated in Figure 4, Ann's request session to schedule a meeting to do this, meeting information is generally exchanged at 60 using additional PS exchange, resulting in a communication channel / session as illustrated at 59.

You can go on with Bob. For as illustrated This exchange does not course as

When the call is to be terminated Ann signals RCA 32 that the call is to be terminated (at 61). The RCA signals the IP 34 stack that the whiteboard session in

The ΕΡ2265080Β1 course is to be terminated (at 62) and signals the CS protocols 36 that the CS call is to be terminated (at 62, 63).

Shutdown messages 64, 65 are sent in the normal manner. The CS 37 protocols inform the RCA 35 of the non-terminating party that the call is to be disconnected (at 66). This RCA 35 informs the IP 36 stack that the whiteboard session is to be terminated and acknowledges to the CS protocols call termination (at 67 and 68). Acknowledgments 69, 70, 71 are then sent in the normal manner. CS and PS connections are treated as a single logical communication arrangement. This linking of links means that it is immediate 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 point of view, so that for the user the connections can be made and terminated immediately even though they are of different types.

Figures 5 and 6 illustrate another arrangement. In the embodiment of figures 5 and 6 the terminals A and B include an adaptation layer 80 (see figure 5). The adaptation layer allows the establishment of CS or PS calls to be transparent to the application 81 running on the terminal. The adaptation layer can be provided on 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 link the adaptation layer interprets that request and passes it to the CS or PS layers as appropriate.

Figure 6 shows an example of an operation that is supported by terminals that have an architecture shown.

ΕΡ2265080Β1 in Fig. 5. In the example of Fig. 6 it is assumed that two terminals 90, 91 are already communicating via a packet-switched connection (see 92). The terminals have application layers 93, 94; adaptation layers 95, 96; IP 97, 98 batteries, and circuit-switched protocol batteries 99, 100. Terminals can communicate for CS calls via MSC 101.

User A decides to initiate a voice call with user B. User A signals application layer 93 of his terminal to indicate that voice should be started (at 102). As the terminals are already involved in a PS call, in this example the application layer is supposed to initiate the voice by means of a request (formatted for example as indicated in figure 6) based on the counterpart terminal address as appropriate for a PS connection for example in session initiation protocol (SIP) format. The adaptation layer could try to initiate the voice call through a PS connection. However, in this example it is assumed that the adaptation layer decides that a CS bearer should be used. This decision could be made on the basis of knowledge of network capacity adaptation unit. As shown in Figure 6, the adapter layer sends a SIP INVITE message via the IP 97 stack to terminal B. The INVITE message contains SIP parameters indicating that a CS bearer should be used and indicates the A terminal MSISDN (see 103). Knowledge of this MSISDN will allow terminal B to identify the call when the configuration request arrives at terminal B.

The B-terminal adaptation layer detects the incoming INVITE message. Because the form of the INVITE message indicates a request for an incoming CS call responds with an OK 200 message that includes the terminal B MSISDN (see

ΕΡ2265080Β1

104). Knowledge of Terminal B MSISDN will allow Terminal A to call MSISDN to configure the pending CS call.

When the OK message with terminal B MSISDN arrives at terminal A, terminal A adaptation layer 95 begins to establish a call to that MSISDN (see 105). The receiving terminal adaptation layer 98 compares the incoming call MSISDN with that received in step 103. As they correspond, it informs the terminal B application layer 100 of the incoming call (at 10 6). The application layer 100 that responds with an acceptance message 107 and in response to 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 endpoints 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 packet radio service (GPRS) terminals are involved 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 one means for the terminals to access another's IP address and any necessary proxy and / or firewall traversal information.

In this situation the SIP protocol (RFC-2543), which was originally designed for voice-over-IP calls, can

ΕΡ2265080Β1 be used while the CS call is in progress. To determine a CS user's SIP URL, there is preferably a predefined mapping of E.164 identities to SIP URLs. This mapping can make use of predefined logic, or it can be stored as a lookup table. Such address mapping can be performed by the SIP proxy on the network (120 in figure 1). You can implement a simple mapping table, or you can use a more complex database that has to be searched to determine a mapping. In the old solution, the lookup table could list the SIP proxy corresponding to each E.164 number, for example:

<td>E.164 Number</td><td>SIP proxy</td><td>Operator</td><td></td><td></td>

<td> +358 40</td><td colspan="2">sip.soneragprs.fi SONERA</td><td></td><td></td>

<td> +358 41</td><td colspan="2">sipgw.teliagprs.com TELIA</td><td></td><td></td>

<td> + 1 30</td><td>mcigprs.com</td><td>MCI</td><td></td><td></td>

<td>On the last</td><td colspan="2">solution, the SIP proxy can</td><td>to provide</td><td>in</td>

<td colspan="2">essence a consultation service</td><td>DNS (service</td><td>by name</td><td>in</td>

<td>domain) that uses</td><td>SRV records of</td><td>DNS.</td><td></td><td></td>

<td colspan="2">During a CS call,</td><td>users</td><td>know</td><td>O</td>

<td colspan="2">E.164 address of the remote party.</td><td colspan="3">The application on a terminal</td>

<td>initiator that is</td><td>to start</td><td colspan="2">PS carrier connection</td><td>The</td>

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 other party's E.164 number (sent with a label to indicate that the address is a telephone number instead of a username) and that the local proxy uses its mapping table (or a more complex) 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 this destination proxy that

ΕΡ2265080Β1 indicates the E.164 identity of the other terminal. The destination proxy determines the SIP URL address that has been allocated to the endpoint using this E.164 identity. The destination proxy may then forward such request to said other terminal via its IP address, and the PS connection configuration may generally continue as normal. Note that the destination proxy can determine from the fact that there is no information and session in the INVITE (or INFO) message payload that the message does not indicate a call setup.

Appropriate billing procedures may be applied, for example based on the type of payload analyzed or the size of the data to be transported. For example large uncompressed image files may be made more costly to download than smaller compressed image files. SIP proxies can also maintain a logging service that can apply different functions depending on time of day, payload type, and so on. For example, 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 email address.

Alternatively, the SIP INVITE or INFO message themselves could be used to transfer user data.

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

Applicant draws attention to the fact that the present invention may include any feature or combination of features disclosed herein.

This document is either implicitly or explicitly generalized, without limitation to the scope of any of the foregoing claims. In the foregoing it will be apparent to a person skilled in the art that various modifications may be made within the scope of the present invention.

DOCUMENTS REFERRED TO IN THE DESCRIPTION

This list of documents referred to by the author of this patent application is for the reader's information only. It is not an integral part of the European patent document. Notwithstanding its careful preparation, IEP assumes no responsibility for any errors or omissions.

Patent documents referred to in the description • EP 1021053 A [0006]

Lisbon, 8th October 2013