WO2009121406A1

WO2009121406A1 - Transmission mode selection mechanism

Info

Publication number: WO2009121406A1
Application number: PCT/EP2008/053945
Authority: WO
Inventors: Jan Holm; Peter Edlund
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2008-04-02
Filing date: 2008-04-02
Publication date: 2009-10-08

Abstract

A method of selecting a transmission mode for media associated with a Push to talk Over Cellular, PoC, call involving a PoC Group. The method comprises, at a PoC Server implementing a participating PoC function associated with a PoC Client of said PoC Group, receiving from a controlling PoC function an indication that transmission mode selection rights are delegated to the participating PoC function (3,7). Thereafter, the participating PoC function makes a transmission mode selection (9) and, if the selection is that of a multicast or broadcast transmission mode, sends a re-invite to a multicast/broadcast bearer to said PoC Client (12).

Description

TRANSMISSION MODE SELECTION MECHANISM

Technical Field

The present invention relates to a transmission mode selection mechanism and is applicable in particular, though not necessarily, to such a mechanism suitable for use with a Push-to-talk over Cellular service.

Background

IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end subscribers will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called "combinational IP Multimedia" services.

IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) and ETSI TISPAN group to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7, and TS 24.173 Release 7). IMS provides key features to enrich the end-subscriber person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP -based networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between subscriber terminals (or subscriber terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a subscriber- to-subscriber protocol, IMS allows operators and service providers to control subscriber access to services and to charge subscribers accordingly. By way of example, Figure 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other IP access networks, known generically as IP Connectivity Access Networks or IP-CANs). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the subscriber and which the subscriber is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.

The IMS architecture offers the opportunity to deploy peer-to-peer applications where two or more users exchange user data directly, following SIP session establishment via IMS. A service particularly suited to the IMS is that known as Push-To-Talk (PTT). PTT is a "walkie-talkie" type of service where an end user can establish a voice call to one or more users substantially at the press of a button. Push to talk Over Cellular (PoC) is a particular implementation that has been standardised by the Open Mobile Alliance (OMA) and which is being implemented over IMS. PoC 2.0 includes a definition of a Quality of Experience (QoE) which can be used to express a desired (or required) level of service. A number of profiles are defined. QoE is a combination of Quality of Service (QoS) and prioritisation/preemption.

The OMA is currently working on PoC release 2.1. Key issues to be addressed by this release are those of national security and public safety in order to allow PoC to be used by the military, police, and other emergency services.

Communication systems for public safety have in the past tended to be dedicated systems designed for that specific use case. Even though some broad standards have been defined, for example Tetra and P25, it is still fair to say that the market is fragmented from a technology and standard point of view. There is no single commonly used standard that dominates the market place. This fragmentation and the relatively small market size have made public safety technology expensive and/or short on functionality.

Communication systems for public safety and military use must satisfy extremely challenging requirements. Consider for example an emergency involving a fire at a large chemical plant. Many hundreds of emergency personal may be in attendance and the majority may wish to participate simultaneously in a communication session using personal communication equipment.

PoC and IMS provide a possible standardised solution to this problem. However, it is currently not possible to efficiently support hundreds of simultaneous PoC Users using unicast IP bearers in existing radio access technologies, e.g. over the UMTS Radio Access Network (UTRAN). To be able to support such large numbers of simultaneous PoC Users, multicast or enhanced broadcast will need to be employed by PoC in order to efficiently use scarce transmission and radio resources, and to ensure rapid connection set-up and joining times.

Summary

According to a first aspect of the present invention there is provided a method of selecting a transmission mode for media associated with a Push to talk Over Cellular (PoC) call involving a PoC Group. The method comprises, at a PoC Server implementing a participating PoC function associated with a PoC Client of said PoC Group, receiving from a controlling PoC function an indication that transmission mode selection rights are delegated to the participating PoC function. Thereafter, the participating PoC function makes a transmission mode selection and, if the selection is that of a multicast or broadcast transmission mode, sends a re-invite to a multicast/broadcast bearer to said PoC Client.

It will be understood that said transmission mode selection may involve selecting one of a unicast and multicast/broadcast transmission mode. In the event that the selection is that of a multicast or broadcast transmission mode, said participating PoC function may initiate establishment of a multicast/broadcast bearer covering a service area including said PoC Client. Standardised mechanisms exist for enabling this.

Said step of making said transmission mode selection may make use of one or more of the following: a PoC Group Identity; an identity of a PoC Service Provider operating a PoC Server acting as said controlling PoC function; user preferences; a location of said PoC Client; a number of participants in the same PoC Session; capabilities of the PoC participant's user equipment; a local policy in the PoC Server; a Quality of Experience profile.

In order to make the transmission mode selection, the participating PoC function may send a request to an external server, the request including a PoC Group Identity for said PoC Group and/or a Quality of Experience profile. The participating PoC function receives a selected mode back from the external server. The response may include a service area across which a multicast/broadcast bearer is to extend.

A second aspect of the invention provides for a Push-to-talk over Cellular server configured to implement the method of the above first aspect of the invention.

According to a third aspect of the present invention there is provided a method of selecting a transmission mode for media associated with a Push-to-talk over Cellular (PoC) call involving a PoC Group. The method comprises receiving a SIP INVITE at a PoC server implementing a controlling PoC function, the INVITE requesting admission to or initiation of said PoC call on behalf of a PoC client. The INVITE is authorised at said controlling PoC function and a SIP 200 OK returned to the participating PoC function associated with said PoC client. The 200 OK may contain an indication that transmission mode selection rights are delegated to the participating PoC function. Said participating PoC function receives said 200 OK and makes a transmission mode selection and, if the selection is that of a multicast or broadcast transmission mode, sends to said PoC Client a re-invite to a multicast/broadcast bearer.

According to a fourth aspect of the present invention there is provided a method of selecting a transmission mode for media associated with a Push to talk Over Cellular (PoC) call involving a PoC Group. The method comprises, at a PoC Server implementing a participating PoC function associated with a PoC Client of said PoC Group, making a transmission mode selection by sending a transmission mode selection request to an external server and receiving a response therefrom indicating one of a multicast/broadcast and unicast transmission mode. In the event that the selection is that of a multicast or broadcast transmission mode, the participating PoC function sends to said PoC Client a re-invite to a multicast/broadcast bearer.

The selection request sent by the participating PoC function to the external server may include a Quality of Experience profile, with that profile being used by said external server to make the transmission mode selection. In addition or alternatively, the request may include a PoC Group Identity, with that Group Identity being used by said external server to make the transmission mode selection.

A fifth aspect of the invention provides for a Push-to-talk over Cellular server configured to implement the method of the above fourth aspect of the invention.

Brief Description of the Drawings

Figure 1 illustrates schematically components of an IP Multimedia Subsystem overlayed on a packet switched access network;

Figure 2 illustrates schematically a PoC architecture comprising participating PoC functions and a controlling PoC function; Figure 3 illustrates an example signalling flow within the architecture of Figure 2 for the purpose of selecting a transmission mode for a PoC Client;

Figure 4 is a flow diagram illustrating a transmission mode selection process carried out at a participating PoC function;

Figure 5 illustrates schematically a PoC server implementing a plurality of participating PoC function; and

Figure 6 illustrates an alternative example signalling flow for the purpose of selecting a transmission mode for a PoC Client Detailed Description

A crucial part of the Push to talk Over Cellular (PoC) service implementation within an IMS context is the PoC server or PoC AS. The PoC server consists of a PoC logic part which forms part of the IMS service network, and a media handling part. Whilst the logic part is responsible for authorising user session initiation, the media handling part sits within the media plane and is responsible for multiplying a speaker's bitstream to multiple streams for peer PoC participants. The media handling part is also responsible for media burst control, i.e. it handles floor control ensuring that only one participant speaks at a time.

In order to facilitate inter-operator PoC calls, the current PoC releases specify two distinct roles for the PoC server. The determination of the role played by a PoC server is made during session establishment and lasts for the duration of the call. The two defined roles are that of Controlling PoC function (CF) and Participating PoC function (PF).

For a given PoC call, only one CF is defined. This is typically implemented within the PoC AS of the home network of the initiating PoC user. The CF has N SIP sessions and media and talk burst communication sessions in one PoC session, where N is the number of participants in the PoC session. The CF will not have any direct communication with the PoC client (within its own network) or with other participating

PoC clients, but rather will interact with that PoC client via the associated PFs. The CF has a knowledge of the PoC group, i.e. it knows the identities of all participants as well as the properties of the PoC group, and is responsible for multiplexing a talk burst bitstream to the appropriate PoC clients via the respective PFs.

One PF is defined for each participating PoC client, i.e. there are N PFs. A PF has direct communication with the PoC client with which it is associated. The PF has knowledge about the PoC client that it is serving, but no knowledge about the PoC

Group itself, other than the identity of the CF. A given PoC AS may implement one or more PFs as well as a CF.

Figure 2 illustrates schematically the relationship between PFs, the CFs, PoC ASs, and

PoC service providers. In the illustrated example, two Participants belongs to PoC Service Provider A and are connected via the PoC Server A. For each of these

Participants there is one instance of a PF implemented within PoC server A. A third participant belongs to PoC Service Provider B who is the "owner" of the CF. In PoC

Server B therefore there is one instance handling the CF and another handling the PF.

A fourth participant belongs to PoC Service Provider C and is connected via the PoC Server C. For this Participant there is one instance of a PF implemented within PoC server C.

A PoC client will have established a packet bearer with the GGSN within its access network at registration. This "pipe" will extend across the radio access network, passing through a SGSN. When the client seeks to establish a PoC call, according to current mechanisms, that pipe is used to transport the talk burst bitstreams as unicast data. In the event that multiple participating PoC clients are present within the same network, each client will make use of its own unicast pipe.

As described above, particularly for large PoC groups such as might arise in an emergency situation, it is desirable to make use of one of the multicast or broadcast services to efficiently deliver PoC Media to multiple PoC clients in parallel. An example multicast/broadcast service is that known as Multimedia Broadcast Multicast Service (MBMS). A mechanism has been standardised [3GPP TS 23.246 "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description (Release 7)"] that will allow a PF to establish such a multicast service by directly communicating with the GGSN (via the Gi reference point), or via an intermediate entity. It is expected that when a PF is first established at a given PoC server in respect of a given PoC call, the PF will establish the multicast service and will re-invite the associated PoC client to that multicast (nb. initially, the client will receive Media over the already established unicast PDP bearer, before transferring the multicast/broadcast bearer). Any PoC client that subsequently seeks to join the same PoC call via the same PoC server will also be re-invited to the multicast by the PF that is established for the new PoC client.

A problem arises however in that a PF only has knowledge of the PoC client for which it is established. It has no knowledge of the PoC group and in particular does not know if the group is one which might advantageously make use of multicast/broadcast. Only the CF has this knowledge. A PoC Transmission mode selection mechanism is therefore required in order to control the transmission mode for PoC services at the service layer. The result of transmission mode selection should be a multicast bearer, a broadcast bearer or a uni-cast bearer established over the access network, e.g. an MBMS RAB or PS RAB bearer. By controlling the transmission mode at the service layer it is possible for operators and PoC Group owners to flexibly control transmission. The selection logic is implemented in the PoC Server acting as PF, in the PoC Server acting as CF, and in an external server (e.g. a server dedicated for emergency multicast/broadcast PoC Groups). An external server may be a server provided by the relevant authorities in a given country. The external server may be implemented either as a distributed server (each operator has one server) or as a centralised server (maintained by the authorities). An example implementation may utilise an XML over UDP interface between the PoC server and the external server.

The CF and the PFs handle transmission decision making according to a master-slave relationship, with the CF delegating decision making rights to the PFs. Decision making at the CF may be based on:

1) The PoC Group Identity and PoC Group data (e.g. a multicast indication, PoC User preferences, etc);

2) Inter-operator agreements;

3) A local policy in the PoC Server or a PoC service provider policy; 4) QoE; or

5) Any combination of the above. A delegation decision is signaled by the CF to the PoC Server acting as PF, when the transmission mode is set up for the PoC Group. The decision may include geographical location or the service area (SAI) in which to apply the multicast/broadcast bearer. Depending upon the level of delegation granted by the CF, the PoC Server acting as PF takes the decision to use uni-cast, multicast, or broadcast based on:

1) The PoC Group Identity;

2) The identity of the PoC Service Provider operating the PoC Server acting as CF;

3) User preferences; 4) The location of the PoC Client. This can be the geographical location or the service area (SAI);

5) Number of Participants in the same PoC Session;

6) The capabilities of the PoC participants' user equipment;

7) A local policy in the PoC Server; 8) QoE; or,

9) Any combination of the above.

The PoC Server performing the PF may use an external server in the transmission mode selection process. In such a case, the external server possesses information identifying those PoC Groups that shall always use multicast/broadcast. If multicast/broadcast shall be used, the external server returns all necessary information needed by the PoC Server to establish the multicast/broadcast bearer, e.g. service area (SAI). The inputs to the external server are:

The PoC Group Identity. The identity of the PoC Service Provider operating the PoC Server acting as CF.

The identity of the PoC Service Provider of the PoC Server acting as PF. Quality of Experience (QoE)

The instruction returned to the PF is one of 1) use multicast/broadcast, 2) "use unicast" or 3) use multicast/broadcast depending on a local policy of the PoC Server, e.g. the number of participants using the PoC Server and/or the geographical area(s) it should be applied in. By allowing each PoC Server acting as PF to take its own local decision regarding transmission mode, the transmission mode for the PoC Group Session may involve a mixture of multicast/broadcast and unicast distribution channels. Indeed, this may be required in order to ensure backward compatibility. A suitably compatible terminal connected to a unicast connection may receive a Re-invite containing a multicast identity and will eventually detect the same PoC Session on the multicast (MBMS) bearer, using the multicast identity. The UE may decide to release the RAB for the unicast connection and switch to the multicast/broadcast bearer.

Figure 3 illustrates how the transmission mode is selected for one PoC Session, using a simplified example where one PoC Client is invited to join a PoC session initiated by another PoC Client. [In practice, many PoC clients may be invited.] The steps of the flow are as follows:

1) The PoC Client A sends a SIP INVITE to PoC Server A (participating) in order to establish a Pre-arranged PoC Group Session. PoC Client A is capable of using multicast/broadcast.

2) PoC Server A forwards the SIP INVITE request to PoC Server X (controlling).

3) PoC Server X selects the "allowed to take own decision" transmission mode from the Pre-arranged PoC Group document, and sends the SIP INVITE request to the PoC Server B (participating).

4) PoC Server B removes the transmission mode "allowed to take own decision" from the SIP INVITE request, and sends the SIP INVITE request to PoC Client B.

5) PoC Client B accepts the invitation and returns a SIP 200 OK response to PoC Server B.

6) PoC Server B forwards the SIP 200 OK response to PoC Server X.

7) Since this is the first PoC Client accepting the invitation, PoC Server X sends the SIP 200 OK response to PoC Server A. The transmission mode "allowed to take own decision" is indicated in the response. 8) PoC Server A removes the transmission mode "allowed to take own decision" from the SIP 200 OK, and sends the SIP 200 OK to PoC Client A. Nb. At this time, the PoC Clients can begin sending and receiving Media bursts over the existing (unicast) PDP bearers. 9) The participating PoC Servers A/B each send a select transmission mode request to an external server based on local policy in the PoC Server. 10) The external servers return information necessary to establish the multicast/broadcast bearers to the respective PoC Servers A/B. H) PoC Servers A/B start the multicast/broadcast bearers (e.g. by signalling to respective GGSNs via the Gi reference point).

12) When the multicast/broadcast bearers are started, PoC Servers A/B send a SIP re-INVITE request to the respective PoC Clients in order to transfer the Clients from the unicast bearers to the started multicast/broadcast bearers.

13) Each PoC Client A/B checks if the multicast/broadcast bearer is available in its cell and, if so, sends a SIP 200 OK response to its PoC Server A/B.

14) Each PoC Client A/B connects to the multicast/broadcast bearer. 15) Each PoC Servers A/B sends a 'Multicast in use' indication to the PoC Server X.

This may be contained within a SIP request or a SIP response.

In the event that both participating PoC Functions A and B are located in the same PoC Server, steps 9 to 11 are carried out only once. Similarly, for each PoC client that subsequently attempts to join the group, a PoC Server that already implements at least one PF only needs to re-invite the new client to the multicast/broadcast.

Figure 4 is a flow diagram further illustrating the transmission mode selection process, from the point of view of the PF. The process begins at step 100, following which the PF receives the 200 OK from the CF, step 101. The 200 OK contains an indication that transmission mode selection rights are delegated to the PF. At step 102, the PF sends a request to the external server, including inter alia the PoC Group Identity. Based upon the Identity and other policy rules, the external server returns a response at step 103. In this example, the response indicates that multicast/broadcast mode should be applied to the PoC Client. At step 104, the PF determines whether or not a multicast/broadcast bearer already exists. If so, at step 106, the PF issues a Re-INVITE to the PoC Client in order to transfer the PoC call to the MBMS bearer. If not multicast/broadcast bearer exists, at step 105, the PF initiates the multicast/broadcast bearer before issuing the Re- INVITE at step 106. The process ends at step 197.

With reference now to Figure 5, there is illustrates a PoC server 1 suitable for performing the transmission mode selection procedure described above. The server comprises processor and memory means 2 for implementing a number of PF instances. An interface 3 allows the PoC server to send and receive selection requests to an external server. In the event that a response from the external server requires a new MBMS bearer to be established, this is achieved via bearer controller 4.

Figure 6 illustrates a signalling flow associated with an alternative procedure for selecting a transmission mode for a PoC Client. The process generally follows that illustrated in Figure 3, except that the CF does not perform any role in explicitly delegating transmission mode selection rights to the PF. Rather, the selection process is the responsibility of the PF and the external server.

According to the procedures of Figures 3 and 6, a parameter used by the external server to determine the transmission mode may be the PoC parameter Quality of Experience (QoE). Four QoE profiles are currently defined for PoC, namely: basic, premium, professional, and government use. A profile may be included in a SIP INVITE sent by a PoC Client and (after verification within the IMS) may be used by the external server to determine a transmission mode.

Claims

CLAIMS:

1. A method of selecting a transmission mode for media associated with a Push to talk Over Cellular, PoC, call involving a PoC Group, the method comprising: at a PoC Server implementing a participating PoC function associated with a PoC Client of said PoC Group, receiving from a controlling PoC function an indication that transmission mode selection rights are delegated to the participating PoC function; and at the participating PoC function, making a transmission mode selection and, if the selection is that of a multicast or broadcast transmission mode, sending to said PoC Client a re-invite to a multicast/broadcast bearer.

2. A method according to claim 1, wherein said transmission mode selection involves selecting one of a unicast and multicast/broadcast transmission mode.

3. A method according to claim 1 or 2, wherein said indication is contained within a SIP 200 OK response.

4. A method according to any one of the preceding claim, wherein, if the selection is that of a multicast or broadcast transmission mode, said participating PoC function initiates establishment of a multicast/broadcast bearer covering a service area including said PoC Client.

5. A method according to any one of the preceding claims and comprising making said transmission mode selection based upon one or more of the following: a PoC Group Identity; an identity of a PoC Service Provider operating a PoC Server acting as said controlling PoC function; user preferences; a location of said PoC Client; a number of participants in the same PoC Session; capabilities of the PoC participant's user equipment; a local policy in the PoC Server; a Quality of Experience profile.

6. A method according to any one of the preceding claims, wherein said step of making a transmission mode selection comprises sending a request from said participating PoC function to an external server, the request including a PoC Group Identity for said PoC Group, and receiving from the external server a mode selection.

7. A method according to claim 6 and comprising receiving in the response from said external server a service area across which a multicast/broadcast bearer is to extend.

8. A Push-to-talk over Cellular server configured to implement the method of any one of the preceding claims.

9. A method of selecting a transmission mode for media associated with a Push-to- talk over Cellular, PoC, call involving a PoC Group, the method comprising: receiving a SIP INVITE at a PoC server implementing a controlling PoC function, the INVITE requesting admission to or initiation of said PoC call on behalf of a PoC client; authorising said INVITE at said controlling PoC function and returning a SIP 200 OK to a participating PoC function associated with said PoC client, the 200 OK containing an indication that transmission mode selection rights are delegated to the participating PoC function; and at said participating PoC function, receiving said 200 OK and making a transmission mode selection and, if the selection is that of a multicast or broadcast transmission mode, sending to said PoC Client a re-invite to a multicast/broadcast bearer.

10. A method of selecting a transmission mode for media associated with a Push to talk Over Cellular, PoC, call involving a PoC Group, the method comprising: at a PoC Server implementing a participating PoC function associated with a PoC Client of said PoC Group, making a transmission mode selection by sending a transmission mode selection request to an external server and receiving a response therefrom indicating one of a multicast/broadcast and unicast transmission mode, and, if the selection is that of a multicast or broadcast transmission mode, sending to said PoC Client a re-invite to a multicast/broadcast bearer.

11. A method according to claim 10 and comprising, at said PoC server making a decision to send said request to said external server based upon one or more of the following: a PoC Group Identity; an identity of a PoC Service Provider operating a PoC Server acting as controlling PoC function; user preferences; a location of said PoC Client; a number of participants in the same PoC Session; capabilities of the PoC Client user equipment; a local policy in the PoC Server; and a Quality of Experience profile.

12. A method according to claim 10 or 11, wherein said selection request includes a Quality of Experience profile, and that profile is used by said external server to make the transmission mode selection.

13. A method according to any one of claims 10 to 12, wherein said selection request includes a PoC Group Identity, and that Group Identity is used by said external server to make the transmission mode selection.

14. A method according to any one of claims 10 to 13 and comprising synchronising PoC Group data between said external server and one or more further external servers.

15. A Push-to-talk over Cellular server configured to implement the method of claim 10.