WO2017125698A1

WO2017125698A1 - Communication system

Info

Publication number: WO2017125698A1
Application number: PCT/GB2016/050105
Authority: WO
Inventors: Filipe LEITAO; Andreas Kunz; Genadi Velev
Original assignee: NEC Europe Ltd
Current assignee: NEC Europe Ltd
Priority date: 2016-01-18
Filing date: 2016-01-18
Publication date: 2017-07-27
Anticipated expiration: 2018-07-18

Abstract

A system is disclosed in which an application server sends, to an interworking function, a request for setting up sponsored data connectivity for one or more services provided by the application server. The request includes an application server identifier and packet flow description(s) associated with the one or more services. The interworking function determines, from the received information, information for forwarding to a core network node, and sends the information to the core network node for managing and/or storing respective policy charging control (PCC) rules associated with the one or more services. The interworking function can be a Service Capability Exposure Function.

Description

Communication System

The present invention relates to mobile communication devices and networks, particularly but not exclusively those operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof, such as the Long Term Evolution (LTE) of the Evolved Packet Core (EPC) network. The invention has particular although not exclusive relevance to sponsored data connectivity for the provision of third party services.

In a mobile (cellular) communications network, (user) communication devices (also known as user equipment (UE), for example mobile telephones) communicate data packets with remote servers or with other communication devices via base stations. Each base station is connected to a core network (such as an EPC network), which is in turn connected to other networks for providing end-to-end connectivity for the users.

The so-called IP connectivity access network (IP-CAN) is an access network that provides Internet Protocol (IP) connectivity between such communication devices and corresponding core network entities (e.g. nodes of an EPC network) using appropriate interfaces and communication protocols. The term IP-CAN usually refers to 3GPP access networks (such as GPRS, EDGE, UTRAN, E-UTRAN), but can be also used to describe wireless local area networks (WLANs), digital subscriber line (DSL) networks, and/or the like.

IP-CAN connectivity is often used by communication devices for communicating with third party service providers (or external service providers), i.e. an endpoint beyond the network operator's infrastructure. For example, users of communication devices may wish to use their IP-CAN connection to access various websites (e.g. social media, news, online TV, music/video streaming, and/or the like), communicate data with remote servers (e.g. cloud services, online backup, file servers, VPN access, and/or the like), and/or communicate with other communication devices (e.g. file transfer/file sharing, VoIP calls, and/or the like) involving third party service providers. Facing the possibility of becoming simple 'dumb pipes' deploying network connectivity (which is primarily used for delivering third party data), network operators start engaging with external third party service providers in order to share the profit generated by the usage of third party applications by their subscribers and to cover their operating expenses. Having external third party service providers paying for, or "sponsoring", network access costs (e.g. used data volume) is an easy and feasible way for network operators to get their slice of third party service providers' profit from their subscribers' data usage.

When it comes to the engagement between operators and third party service providers for sponsored data connectivity, there are two ways to deal with it: offline, when both parties have an offline agreement where data generated from a certain application is always not considered for charging purposes; and online when during the subscribers' data session the third party pro-actively sends a request to the network operator asking for its application data not to be considered for charging.

For the online alternative, 3GPP specified in Release 1 1 a number of "Policy Enhancements for Sponsored Connectivity". These enhancements were initially studied in 3GPP Technical Report (TR) 23.813 V1 1 .0.0 and later accepted in the normative phase with enhancements concerning the so-called 'Rx' reference point (defined in 3GPP Technical Specification (TS) 29.214 V13.4.0), the so-called 'Gx' reference point (defined in 3GPP TS 29.212 V13.4.0), and general procedures relating to Policy Charging Control (PCC) (defined in 3GPP TS 23.203 V13.6.0).

The key in the 3GPP based sponsored connectivity is the relationship between the third party and the network operator. Currently Rx reference point covers the issue of sponsored connectivity with specific procedures between a sponsor (e.g. an Application Function (AF)) and the Policy and Charging Rules Function (PCRF) in the network operator's domain. Sponsored connectivity is currently realised in 3GPP networks using specific Attribute-Value Pairs (AVPs) of the Diameter protocol (specified in the Request for Comments (RFC) no. 6733 of the Internet Engineering Task Force (IETF)). Specifically, 3GPP defines (in TS 29.214 V13.4.0) the requirements for the Sponsored Data Connectivity Request procedure as follows:

"For sponsored data connectivity and if Sponsored Connectivity is supported, the AF shall provide the application service provider identity and the sponsor identity to the PCRF by including the Application-Service- Provider-ldentity AVP and the Sponsor-Identity AVP in the Sponsored- Connectivity-Data AVP in the AA-Request."

"To support the usage monitoring of sponsored data connectivity, the AF may also include the Granted-Service-Unit AVP in the Sponsored- Connectivity-Data AVP and the Specific-Action AVP set to the value USAGE_REPORT in the AA-Request to request notification when the usage threshold has been reached."

The procedure thus uses the Sponsored-Connectivity-Data AVP, which includes the following information: Sponsor-Identity, Application-Service-Provider-ldentity, Granted-Service-Unit, Used-Service-Unit, Sponsoring-Action, and AVP.

According to the current 3GPP specifications, whenever the third party service provider (sponsor) desires to "sponsor" a particular user's traffic, the third party service provider sends the Sponsored-Connectivity-Data AVP to the network operator, including the information of "how much" it is sponsoring in the Granted- Service-Units AVP (e.g. 100MB of data). The network operator then updates the subscribers' IP-CAN session with new PCC rules updated accordingly. This procedure is detailed in section 4.3.1 of 3GPP TS 29.213 V13.2.0, the contents of which are incorporated herein by reference.

The inventors have identified a number of issues with the current sponsored connectivity procedures. For example, sponsored connectivity procedures are carried out individually per subscriber, i.e. they occur when, during an ongoing individual IP-CAN session, a subscriber uses a service that decides to sponsor for its network consumption while the subscriber is using it. This means that service description information, used for service detection at the Policy and Charging Enforcement Function (PCEF) / Traffic Detection Function (TDF) level, is also sent via the Rx reference point when the AF/sponsor requests the PCRF for sponsored connectivity.

However, this procedure is inefficient because the third party service provider needs to send the service flow information (for service identification/detection) for each subscriber using the service, and each time a particular subscriber is using the service. Moreover, whenever a third party service provider modifies its server details it needs to send corresponding new service flow information to the operator domain again (for each subscriber).

Accordingly, preferred embodiments of the present invention aim to provide methods and apparatus which overcome or at least partially alleviate the above issues.

In one aspect, the invention provides an interworking function for a cellular communication system, the interworking function comprising: a transceiver operable to receive, from an application server, a request for setting up sponsored data connectivity for at least one service provided by the application server, the request comprising information identifying at least: the application server and at least one packet flow description associated with the at least one service; and a processor operable to determine, from the received information, information for forwarding to said cellular communication system; wherein the transceiver is operable to send the information for forwarding to a node (e.g. an SPR/UDR and/or a PCRF) of the cellular communication system responsible for managing (and/or storing) respective policy charging control, PCC, rules associated with a particular service.

In one aspect, the invention provides an application server for providing at least one service for nodes of a cellular communication system, the application server comprising: a transceiver operable to: send, to an interworking function, a request for setting up sponsored data connectivity for at least one service provided by the application server, the request comprising information identifying at least: the application server and at least one packet flow description associated with the at least one service; and communicate data for at least one user using said sponsored data connectivity and in accordance with said at least one packet flow description associated with the at least one service.

In one aspect, the invention provides a core network node (e.g. an SPR/UDR and/or a PCRF) configured as a subscriber information repository, the core network node comprising: a transceiver operable to receive, from an interworking node, information identifying at least: an application server and at least one packet flow description associated with at least one service provided by the application server; and a processor operable to update, based on said received information, information associated with at least one subscriber profile held at said core network node; wherein said transceiver is operable to provide said updated information to a policy control node for generating a policy charging control, PCC, rule associated with said at least one service.

Aspects of the invention extend to corresponding systems, methods, and computer program products such as computer readable storage media having instructions stored thereon which are operable to program a programmable processor to carry out a method as described in the aspects and possibilities set out above or recited in the claims and/or to program a suitably adapted computer to provide the apparatus recited in any of the claims.

Each feature disclosed in this specification (which term includes the claims) and/or shown in the drawings may be incorporated in the invention independently (or in combination with) any other disclosed and/or illustrated features. In particular but without limitation the features of any of the claims dependent from a particular independent claim may be introduced into that independent claim in any combination or individually. Exemplary embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings in which:

Figure 1 illustrates a mobile (cellular) telecommunication system of a type to which embodiments of the invention are applicable;

Figure 2 is an exemplary block diagram illustrating the main functionalities of an SCEF of the system shown in Figure 1 ; Figure 3 is an exemplary block diagram illustrating the main functionalities of an SPR/UDR of the system shown in Figure 1 ;

Figure 4 is an exemplary block diagram illustrating the main functionalities of an SCS/AS of the system shown in Figure 1 ; and

Figures 5 and 6 are exemplary timing diagrams illustrating methods performed by components of the mobile telecommunication system of Figure 1 whilst carrying out embodiments of the invention.

Overview

Figure 1 schematically illustrates a mobile (cellular) telecommunication network 1 in which users of mobile devices 3 can communicate with each other and other users via E-UTRAN base stations 5 and a core network 10 using an E-UTRA radio access technology (RAT). As those skilled in the art will appreciate, whilst one mobile device 3 and one base station 5 are shown in Figure 1 for illustration purposes, the system, when implemented, will typically include other base stations and mobile devices. It will be appreciated that the radio access technology is not limited to E-UTRAN, and may comprise any suitable access technology in accordance with one or more of the following standards: LTE, UMTS, GPRS, WiFi, WiMAX, and/or the like.

The mobile device 3 and the base station 5 are connected via an LTE air interface, the so-called "Uu" interface. In this example, the base station 5 forms part of a so- called IP-CAN network (not shown in Figure 1 for simplicity) for providing IP-CAN data connectivity for the mobile device 3. The base station 5 (and hence the mobile device 3) is coupled to the core network 10 via an appropriate interface (in this example, an 'S1 ' interface). The core network 10 includes, amongst others, a Policy and Charging Enforcement Function (PCEF) 12, a Policy Control and Charging Rules Function (PCRF) 13, a Service Capability Exposure Function (SCEF) 14, a Subscriber Profile Repository / User Data Repository (SPR/UDR) 15, a Mobility Management Entity (MME) 16, a Serving Gateway (S-GW) 18, and a Packet Data Network (PDN) Gateway 19. It will be appreciated that the core network 10 may also include other nodes, such as a gateway general packet radio service support node (GGSN), a home subscriber server (HSS), an operation and maintenance (OAM) entity, which are omitted from Figure 1 for simplicity.

The PCEF 12 is responsible for enforcing policing and charging rules associated with a particular subscriber (e.g. the user of the mobile device 3) and/or service. The PCRF 13 is responsible for deriving appropriate PCC rules for a given service requested by the user of the mobile device 3 (i.e. an associated subscriber). Based on the applicable PCC rules, the PCRF 13 triggers PCC procedures (in accordance with 3GPP TS 23.203 V13.6.0) in order to provide the respective policing and charging information (rules) to the PCEF 12, the S-GW 18, and/or the P-GW 19.

The SCEF 14 is responsible for authorising a particular service for a given subscriber and assists the other core network nodes in deriving and applying appropriate PCC rules for third party services. As specified in 3GPP TS 23.682 V13.4.0, the SCEF 14 is an entity within the 3GPP architecture for service capability exposure that provides a means to securely expose the services and capabilities provided by 3GPP network interfaces. In order to do so, the SCEF 14 communicates with the other core network nodes (such as the PCEF 12, the PCRF 13, and the SPR/UDR 15), as appropriate. Further details of the PCC procedures and involved core network nodes are given in e.g. clause 7.4.2 of 3GPP TS 23.203 V13.6.0, the contents of which are incorporated herein by reference.

In this example, the SCEF 14 provides a web-based variant of the Rx reference point (thus beneficially allows third party service providers to interwork with the core network 10 without having to support / use the Diameter protocol). It will be appreciated that such web-based interface may comprise an interface based on the Extensible Markup Language (XML) and/or other application program interface (API) suitable for communicating with third party service providers.

The SPR/UDR 15 is responsible for storing information relating to subscribers (e.g. a subscription profile for a particular subscriber) and information relating to user data (e.g. user plane data to be communicated for a particular subscriber). The SPR/UDR 15 provides this information to other nodes (e.g. the PCRF 13) upon request (e.g. when a particular subscriber starts using a service).

As is well known, a mobile device 3 may enter and leave the areas (i.e. radio cells) served by the various base stations 5 as the mobile device 3 is moving around in the geographical area covered by the telecommunication system 1 . The MME 16 is responsible for keeping track of the mobile device 3 and for facilitating movement of the mobile device 3 between the different base stations 5.

The core network 10 is coupled to an external network 20 (e.g. via the P-GW 19). Thus, in turn, the core network 10 provides connectivity between the mobile telephone 3 connected to the base station 5 (IP-CAN network) and the external network 20. The external network 20 typically comprises an Internet Protocol (IP) based network such as the Internet and/or the like.

The external network 20 includes a Service Capability Server / Application Server (SCS/AS) 27, which is responsible for end-to-end communications between (an appropriate application in) the mobile device 3 and a corresponding (third party) application in the external network 20. The third party application is typically hosted by an application server (AS) in the external network 20 and may make use of a service capability server (SCS) for additional value added services. Typically, the SCS performs user plane and/or control plane communication with the mobile device 3 relating to the services provided by the AS. It will be appreciated that the functionalities of the SCS and the AS may be provided separately (using separate network nodes) and, if appropriate, the SCS and/or the AS may also be provided in the core network 10 (shown in dashed lines in Figure 1 ), rather than in the external network 20. Further details of the SCS/AS are given in 3GPP TS 23.682 V13.4.0, the contents of which are incorporated herein by reference.

In this system, in order to support third party sponsored connectivity for mobile devices, the SCEF 14 is used as a mediator between a third party service provider (in this example, the SCS/AS 27) and the 3GPP operator domain (the nodes of the core network 10). Thus, the SCEF 14 is able to facilitate the SCS/AS 27 to request an appropriate QoS for its applications. Beneficially, the SCEF 14 allows the SCS/AS 27 (or similar third party service provider) to send information to the operator outside any subscriber IP-CAN session context (i.e. independently from the current usage of services hosted by the SCS/AS 27). Accordingly, information for supporting third party sponsored connectivity need not be sent for every subscriber's IP-CAN session as part of that session. Instead the information can be sent to support third party sponsored connectivity for a specific service (possibly for a specific subscriber or group of subscribers) and that information can be maintained, without further signalling from the SCS/AS 27, for multiple IP-CAN sessions. Specifically, for each hosted application, the SCS/AS 27 is configured to send, to the SCEF 14, an application identifier (e.g. an appropriate 'App Service Provider Id') associated with the SCS/AS 27 and a service flow description information (e.g. Service Data Flow (SDF) information) representing the characteristics/parameters of the traffic associated with that particular service. For example, rather having to send information in every IP-CAN session, the SCS/AS 27 may send the application identifier / SDF information when it is first connected to the core network 10, whenever the SCS/AS 27 is updated (e.g. one or more services and/or associated parameters change), and/or whenever application servers are added/removed by the third party service provider. Beneficially, the SCS/AS 27 is configured to send this information to the SCEF 14 in a signalling message over the web-based API provided between them (e.g. in XML format and/or the like). For example, the application identifier / SDF information may be provided in the form of an SDF list (and/or the like) comprising respective identifiers for each hosted application and corresponding SDF parameters. Optionally, the SCS/AS 27 may also send information (e.g. a list / XML data) identifying each affected user/subscriber (e.g. by their associated subscriber identifiers) to be sponsored and/or the amount of data to be sponsored (e.g. a default amount and/or an amount per subscriber).

The SCEF 14 validates the request received from the SCS/AS 27 and maps the received information (SDF list / XML data) into the core network protocol used for communicating with the subscriber profile repository function (forming part of the SPR/UDR 15 in Figure 1 ). In this example, this core network protocol is referred to as the 'Spt' reference point (although other suitable protocols may also be used).

The SPR/UDR 15 processes the received information (mapped by the SCEF 14) and updates its database entries for the subscribers identified by the SCS/AS 27 (via the SCEF 14). Specifically, the SPR/UDR 15 updates the subscription information (such as subscription tables/profiles) for subscribers identified as users of one or more service hosted by the SCS/AS 27. It will be appreciated that the SCEF 14 and/or the SPR/UDR 15 may also update any other core network function that deals with third party service providers. Beneficially, when a particular subscriber (e.g. the user of the mobile device 3) starts using a third party service provided by the SCS/AS 27, there is no need for the SCS/AS 27 to inform the core network 10 entities about the parameters required for sponsoring the traffic for that service and/or an associated QoS. This in turn may contribute to faster deployment of such third party services and improved / more efficient enforcement of any associated policy charging control rules.

The provision of the application identifier and respective SDF information for each service (by the SCS/AS 27) in a single message also increases the efficiency of the configuration (and updating) of the services provided by the SCS/AS 27 without compromising on the ability to provide sponsored services for the users / mobile device 3.

The mapping between the information from the SCS/AS 27 and the format required by the SPR/UDR 15 (e.g. XML to Spt) is performed by the SCEF 14. This beneficially ensures compatibility with the core network protocols used in this core network 10 and prevents erroneous handling of sponsoring request without having to adapt the SCS/AS 27 to this particular type of core network.

The operator can also benefit in terms of reduced signalling overhead by receiving the list of users to be sponsored, together with the amount of data (if any) to be sponsored by default for those users. It is also possible to provide a default amount of data to be sponsored without explicitly identifying any particular user, in which case the default amount may be applied for all users. Another advantage of using an interworking function (such as the SCEF 14) is that the procedures performed by the PCEF 12 and the PCRF 13 remain unaffected (e.g. the way PCC rules are generated and enforced conform to the current standards), thus there is no need to modify (the standards defining) the operation of these entities.

Service Capability Exposure Function

Figure 2 is a block diagram illustrating the main components of the SCEF 14 shown in Figure 1. As shown, the SCEF 14 has a transceiver circuit 31 , and a network interface 33 for transmitting signals to and for receiving signals from other network nodes (such as the PCEF 12, the PCRF 13, and the SPR/UDR 15). The SCEF 14 has a controller 35 to control the operation of the SCEF 14. The controller 35 is associated with a memory 37.

Software may be pre-installed in the memory 37 and/or may be downloaded via the communication network 1 or from a removable data storage device (RMD), for example. The controller 35 is configured to control the overall operation of the SCEF 14 by, in this example, program instructions or software instructions stored within memory 37. As shown, these software instructions include, among other things, an operating system 39, a communications control module 41 , a service authorisation module 43, a parameter mapping module 45, and an API module 47. The communications control module 41 controls the communication between the SCEF 14 and other network entities that are connected to the SCEF 14 (e.g. the PCEF 12, the PCRF 13, and the SPR/UDR 15).

The service authorisation module 43 is responsible for authorising services (including third party services) for the subscribers (e.g. the user of the mobile device 3) in accordance with their subscription parameters and/or network policies.

The parameter mapping module 45 performs mapping between the parameters associated with third party services (e.g. an SDF-list received via the API module 47) and corresponding parameters of a core network protocol used by the subscriber profile repository function (forming part of the SPR/UDR 15). For example, the parameter mapping module 45 may perform a mapping between an XML format (and/or similar web-based format) used by the SCS/AS 27 and a core network specific format (e.g. Spt) used by the SPR/UDR 15.

The API module 47 is responsible for handling (generating, sending, and receiving) signalling messages formatted in accordance with the API used by the SCEF 14 for communicating with third party service providers (e.g. the SCS/AS 27). Such signalling messages may include, for example, messages including an SDF-list relating to the services provided by the SCS/AS 27 and associated responses.

Subscriber Profile Repository / Unified Data Repository node

Figure 3 is a block diagram illustrating the main components of the SPR/UDR 15 shown in Figure 1 . As shown, the SPR/UDR 15 has a transceiver circuit 51 , and a network interface 53 for transmitting signals to and for receiving signals from other network nodes (such as the PCEF 12 and the PCRF 13). The SPR/UDR 15 has a controller 55 to control the operation of the SPR/UDR 15. The controller 55 is associated with a memory 57.

Software may be pre-installed in the memory 57 and/or may be downloaded via the communication network 1 or from a removable data storage device (RMD), for example. The controller 55 is configured to control the overall operation of the SPR/UDR 15 by, in this example, program instructions or software instructions stored within memory 57. As shown, these software instructions include, among other things, an operating system 59, a communications control module 61 , a subscriber profile module 63, and a service data flow (SDF) information module 65.

The communications control module 61 controls the communication between the SPR/UDR 15 and other network entities that are connected to the SPR/UDR 15 (e.g. the PCEF 12 and the PCRF 13).

The subscriber profile module 63 is responsible for storing information relating to subscribers (e.g. a subscription profile for a particular subscriber) and information relating to management of user data (e.g. user plane data to be communicated for a particular subscriber). The subscriber profile module 63 provides this information to other nodes (e.g. the PCRF 13) upon request (e.g. when a particular subscriber starts using a service).

The SDF information module 65 is responsible for storing, for each service, information relating to a respective service data flow associated with that service (e.g. a service provided by the core network 10 or a third-party service, such as a service provided by the SCS/AS 27). The information held by the SDF information module 65 is used for determining (e.g. by a traffic detection function) which data packets belong to which service and to derive (e.g. by the PCRF 13) and enforce corresponding PCC rules (e.g. by the PCEF 12, the PCRF 13, the S-GW 18, and/or the P-GW 19).

Service Capability Server / Application Server

Figure 4 is a block diagram illustrating the main components of the SCS/AS 27 shown in Figure 1 . As shown, the SCS/AS 27 has a transceiver circuit 71 , and a network interface 73 for transmitting signals to and for receiving signals from other network nodes (such as the SCEF 14 and/or the mobile device 3). The SCS/AS 27 has a controller 75 to control the operation of the SCS/AS 27. The controller 75 is associated with a memory 77.

Software may be pre-installed in the memory 77 and/or may be downloaded via the communication network 1 or from a removable data storage device (RMD), for example. The controller 75 is configured to control the overall operation of the SCS/AS 27 by, in this example, program instructions or software instructions stored within memory 77. As shown, these software instructions include, among other things, an operating system 79, a communications control module 81 , a service capability server module 83, an application server module 85, and an API module 87.

The communications control module 81 controls the communication between the SCS/AS 27 and other network entities that are connected to the SCS/AS 27 (e.g. the mobile device 3 and/or core network nodes, such as the SCEF 14).

The SCS module 83 performs user plane and/or control plane communication with the mobile device 3 relating to the services provided by the SCS/AS 27 (e.g. the AS module 85). The SCS module 83 is also responsible for the provision of value added services.

The AS module 85 hosts one or more applications for the mobile device 3 (and/or other user equipment) having an IP-CAN connectivity (via the base station 5). For each application, the AS module 85 holds a respective application identifier (e.g. an App Service Provider Id and/or the like) in order to distinguish between different applications and/or different application servers.

The API module 87 is responsible for handling (generating, sending, and receiving) signalling messages formatted in accordance with the API used by the SCEF 14. Such signalling messages may include, for example, messages including an SDF-list relating to the services provided by the SCS/AS 27 and associated responses.

In the above description, the SCEF 14, the SPR/UDR 15, and the SCS/AS 27 are described for ease of understanding as having a number of discrete modules (such as the communications control modules, the service authorisation module, the SDF information module, and the SCS module). Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities. These modules may also be implemented in software, hardware, firmware or a mix of these.

Operation - provisioning of service flow information

Figure 5 is an exemplary timing diagram illustrating a method performed by components of the mobile telecommunication system of Figure 1 for facilitating the provision of sponsored third party communication services.

In this example, the SCEF 14 is configured to interact with the third party application provider (e.g. the SCS/AS 27) and the operator's subscriber profile manager (e.g. the 3GPP Service Profile Repository (SPR) although it may comprise other subscriber profile database as well). This way, third party service providers are able to send service flow information to the operator's subscriber data base (in this case, the SPR/UDR 15), at any time, independently from any IP- CAN session associated with a subscriber using the third party service.

As can be seen, the procedure begins in step S501 , in which the SCS/AS 27 generates (using its API module 87) and sends an appropriately formatted signalling message to the SCEF 14. This step may happen at any time, and it is independent of any ongoing subscriber IP-CAN session. It will be appreciated that the SCS/AS 27 may send this message (denoted 'SDF-List' in Figure 5) when the SCS/AS 27 is first connected to the core network 10, when the SCS/AS 27 is updated (e.g. one or more services and/or associated parameters change), and/or whenever application servers are added/removed to the external network 20. Accordingly, the message may comprise a request for provisioning, updating, and/or deleting service information.

In this example, the third party service provider has new server(s) information, i.e. the service flow information held by the operator (e.g. in the SPR/UDR 15), is no longer valid. This may happen, for example, because the third party service provider decided to allocate new or different servers for the service provided by the SCS/AS 27.

Accordingly, the SCS/AS 27 includes in the message at S501 a list of (updated) SDFs for any application currently provided by this SCS/AS 27 (and/or a list of SDFs for applications provided by other application servers). Specifically, the SDF list includes, for each application, an application identifier (e.g. an App Service Provider Id associated with the SCS/AS 27) and an SDF associated with that application. Optionally, the SDF list may also include information identifying at least one user (e.g. by their respective User IDs / Mobile Station International Subscriber Directory Numbers (MSISDNs)) and/or information identifying an associated sponsored usage (which may be given e.g. in units of bytes / kilobytes / megabytes etc. and/or units of time). The sponsored usage may be given as a default sponsored usage and/or as a user specific sponsored usage (in which case different usage values may be associated with different subscribers). When the SCEF 14 (acting as an interworking node) receives the list of new service flow descriptions, it proceeds to authorise, in step S503, the new service parameters (using its service authorisation module 43) in order to verify that the AS is authorised to perform this request (e.g. using an authorisation procedure described in 3GPP TS 23.682) and to ensure that the request is in accordance with the applicable network policies. For example, the SCEF 14 may apply policies to control the overall amount of pre-defined QoS (e.g. sponsored data) authorized for the SCS/AS 27. The SCEF 14 uses the application identifier associated with a particular application and/or SCS/AS 27 to correlate that application identifier with the corresponding application identifier used internally in the core network 10 for that application (and/or application server). It will be appreciated that the SCEF 14 may be configured to notify the SCS/AS 27 at this point if the authorization fails.

Following successful authorisation of the request from the SCS/AS 27, the SCEF 14 (using its parameter mapping module 45) maps, in step S505, the received information to the corresponding (internal) protocol used for communication between the SCEF 14 and the appropriate core network node responsible for third party services. For example, the SCEF 14 may perform a mapping procedure described in 3GPP TS 23.682. In this example, the core network node responsible for third party services is a database where the operator stores subscription information that is used for managing an associated IP-CAN session. In the context of 3GPP this database is the Subscription Profile Repository (which forms part of the SPR/UDR 15 in this example).

In step S507, the SCEF 14 generates and sends an appropriately formatted update request towards the operator's subscriber profile manager (SPR/UDR 15), including the list of new (updated) service flow descriptions (SDFs) and the corresponding identification of the third party service provider (i.e. the App Service Provider ID(s) received from the SCS/AS 27 and/or corresponding internal application identifiers). If received in step S501 , the SCEF 14 may also send the list of users to be sponsored (e.g. list of MSISDNs) and the amount of data to be sponsored (time and/or volume) per user (default/user specific).

It will be appreciated that this action is protocol-agnostic, as most SPR implementations are vendor-specific. For simplification, this invention refers to this (SCEF-SDF) reference point as the Spt Reference Point (as a reference to the 'Sp' reference point disclosed in 3GPP TS 23.203, for communications between the PCRF 14 and the SPR function).

As generally illustrated in step S509, the SPR/UDR 15 (using its subscriber profile module 63 and SDF information module 65) updates the new service flow descriptions for all subscriber profiles associated with users of services provided by the third party service provider. It will be appreciated that the SPR/UDR 15 may store an indication that a particular subscriber is a user of a given third party service by associating the application identifier with the subscriber description (held by the subscriber profile module 63). Although not shown in Figure 5 for simplicity, the updated service flow descriptions may cause the core network 10 (e.g. PCEF 12 / PCRF 13) to derive and apply new policy decisions (PCC rules) and consequently trigger an update of all IP- CAN sessions where the third party service provider is being accessed (i.e. update each IP-CAN session associated with an App Service Provider Id / corresponding internal application identifier for which an updated SDF is available). Accordingly, regardless whether or not the mobile device 3 has any IP-CAN session for a service provided by the SCS/AS 27, the SCS/AS 27 is able to trigger the necessary changes in the core network policies to reflect the new configuration used by the third party service provider. Thus, when the PCRF 13 is taking a decision on the PCC Rules applicable to a certain IP-CAN session, and consults the SPR to gather subscriber information (e.g. as illustrated in step 4 of 4.3.1.2.1 .1 flow of 3GPP TS 29.213 v13.2.0), the subscriber profile is already updated with the third party service provider SDF information.

In step S51 1 , the SPR function (of the SPR/UDR 15) generates and sends an appropriate reply (acknowledgment) to the SCEF 14 including information regarding the success of updating subscriber profiles. In step S513, the SCEF 14 forwards (using its API module 47) the received acknowledgment to the third party service provider AS (SCS/AS 27). Operation - updating the service flow information

Figure 6 is an exemplary timing diagram illustrating a method performed by components of the mobile telecommunication system of Figure 1 when updating the information held by the core network about third party communication services. In this example, the SCS/AS 27 updates the service parameters (e.g. QoS) associated with a particular subscriber (e.g. the user of the mobile device 3), using legacy procedures. Specifically, the SCS/AS 27 uses a procedure in accordance with the procedure illustrated in Figure 5.1 1 -1 of 3GPP TS 23.682.

The procedure begins in step S601 , in which the SCS/AS 27 initiates the setting up of a connection between the SCS/AS 27 and the mobile device 3 (UE) with a QoS required for the service. The SCS/AS 27 generates (using its API module 87) and sends an On-demand QoS request message to the SCEF 14. The SCS/AS 27 also includes in this message an IP address associated with the mobile device 3 (UE IP address), an identifier associated with the SCS/AS, an SCS/AS Reference ID, and a description of the application flows (SDF) with reference to a pre-defined QoS required for the service. Optionally, a period of time and/or a traffic volume for the requested QoS may also be included in the SCS/AS request.

In step S603, the SCEF 14 authorizes the request from the SCS/AS 27 and it may also apply policies to control the overall amount of pre-defined QoS authorized for the SCS/AS 27. Further details of this step are given below with reference to step S503.

In step S605, the SCEF 14 (using its parameter mapping module 45) maps the UE IP address, the SCS/AS Identifier, the description of the application flows and the reference to pre-defined QoS information to corresponding core network parameters (e.g. Rx parameters) including the optionally received period of time and/or traffic volume which is mapped to sponsored data connectivity information. Effectively, the SCEF 14 acts as an application function defined in TS 23.203.

As generally shown in step S606, the SCEF 14 is configured to interact with the PCRF 13 (via the Rx interface) and trigger a so-called 'PCRF initiated IP-CAN Session Modification procedure' as described in clause 7.4.2 of TS 23.203. The PCRF 13 derives the required QoS based on the information provided by the SCEF 14 and determines whether the requested QoS is allowed (according to the PCRF configuration for this third party SCS/AS 27), and notifies the result to the SCEF 14.

Beneficially, as generally shown in step S606a (which forms part of the PCRF initiated IP-CAN session modification procedure), the PCRF 13 is configured to retrieve the updated SDF information from the SPR/UDR 15. Specifically, the SPR/UDR 15 uses the same App Service Provider Id as used for the provisioning (received by the SPR/UDR 15 in step S507 of Figure 5 and mapped by the SCEF 14 to a corresponding internal application identifier in step S505) so that the PCRF 13 is able to update the PCC rules for that particular application / SDF.

Following the PCRF initiated IP-CAN session modification procedure, the SCEF 14 generates (using its API module 47) and sends, in step S613, an appropriate response to the SCS/AS 27. The response (e.g. an On-demand QoS response') includes the SCS/AS Identifier, the SCS/AS Reference ID, and information on the result (e.g. success/failure) indicating whether the QoS request is granted or not.

Modifications and Alternatives

Detailed embodiments have been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above embodiments whilst still benefiting from the inventions embodied therein. By way of illustration only a number of these alternatives and modifications will now be described.

In the above description of the embodiments the SCEF is used as an exemplary interworking function for facilitating the exchange of service related information between a third party application provider and a service control node in the core network. However, it will be appreciated that such interworking functionality may also be provided using other nodes, if appropriate.

It will be appreciated that in some deployments the functionality of the SPR and/or UDR may be integrated with (provided as part of) the PCRF. Moreover, the SCS may be integrated with the SCEF rather than the AS. In the above embodiments, a mobile telephone based telecommunications system was described. As those skilled in the art will appreciate, the signaling techniques described in the present application can be employed in other communications system. Other communications nodes or devices may include user devices such as, for example, personal digital assistants, laptop/tablet computers, booklet computers, wireless routers, web browsers, e-book readers, etc. As those skilled in the art will appreciate, it is not essential that the above described system be used for mobile communications devices. The system can be used to improve a network having one or more fixed communication devices as well as or instead of the mobile communicating devices.

In the above embodiments, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the node as a signal over a computer network, or on a recording medium. Further, the functionality performed by part or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the node in order to update its functionality. Similarly, although the above embodiments employed transceiver circuitry, at least some of the functionality of the transceiver circuitry can be performed by software. The information received by the interworking function (from the application server) may be formatted in accordance with the Extensible Markup Language, XML, standard.

The processor of the interworking function may be operable to determine the information for forwarding by mapping the received information to information in accordance with a protocol specific to a subscriber information repository node of the cellular communication system. The processor of the interworking function may be operable to determine the information for forwarding by mapping the received information to pre-defined QoS information.

The request received by the interworking function may include at least one of: information identifying at least one user; information identifying an amount of data and/or an amount of time to be sponsored; an IP address associated with a user of said at least one service; information relating to a packet flow associated with said at least one application; and a reference.

The processor of the interworking function may be operable to authorise the received request (e.g. by checking whether a Quality of Service, QoS, required for the at least one service can be provided by the cellular communication system).

The transceiver of the interworking function may be operable to send a response, to said application server, confirming whether or not a required Quality of Service, QoS, can be provided for said at least one service, based on said received request. The interworking function may comprise a Service Capability Exposure Function (SCEF).

The packet flow description may comprise Service Data Flow (SDF) information (e.g. respective SDF information for all services provided by the application server). The application server's request may include at least one of: information identifying at least one user; information identifying an amount of data and/or an amount of time to be sponsored; an IP address associated with a user of said at least one service; information relating to a packet flow associated with said at least one application; and a reference. The application server may further comprise a service capability server (SCS).

The transceiver of the core network node may be operable to provide the updated information to the policy control node upon request by said policy control node. For example, the transceiver of the core network node may be operable to provide the updated information to the policy control node upon setting up an Internet Protocol connectivity access network, IP-CAN, session for said at least one service provided by the application server.

Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

Claims

An interworking function for a cellular communication system, the interworking function comprising: a transceiver operable to receive, from an application server, a request for setting up sponsored data connectivity for at least one service provided by the application server, the request comprising information identifying at least: the application server and at least one packet flow description associated with the at least one service; and a processor operable to determine, from the received information, information for forwarding to said cellular communication system; wherein the transceiver is operable to send the information for forwarding to a node of the cellular communication system responsible for managing (and/or storing) respective policy charging control, PCC, rules associated with a particular service.

The interworking function according to claim 1 , wherein said processor is operable to determine said information for forwarding by mapping the received information to information in accordance with a protocol specific to a subscriber information repository node of the cellular communication system.

The interworking function according to claim 1 or 2, wherein said received information is formatted in accordance with the Extensible Markup Language, XML, standard.

The interworking function according to any of claims 1 to 3, wherein said processor is operable to determine said information for forwarding by mapping the received information to pre-defined QoS information.

The interworking function according to any of claims 1 to 4, wherein the received request includes at least one of: information identifying at least one user; information identifying an amount of data and/or an amount of time to be sponsored; an IP address associated with a user of said at least one service; information relating to a packet flow associated with said at least one application; and a reference.

The interworking function according to any of claims 1 to 5, wherein said processor is operable to authorise the received request (e.g. by checking whether a Quality of Service, QoS, required for the at least one service can be provided by the cellular communication system).

The interworking function according to any of claims 1 to 6, wherein the transceiver is operable to send a response, to said application server, confirming whether or not a required Quality of Service, QoS, can be provided for said at least one service, based on said received request.

The interworking function according to any of claims 1 to 7, wherein said packet flow description comprises Service Data Flow, SDF, information (e.g. respective SDF information for all services provided by the application server).

The interworking function according to any of claims 1 to 8 comprising a Service Capability Exposure Function, SCEF.

An application server for providing at least one service for nodes of a cellular communication system, the application server comprising: a transceiver operable to: send, to an interworking function, a request for setting up sponsored data connectivity for at least one service provided by the application server, the request comprising information identifying at least: the application server and at least one packet flow description associated with the at least one service; and communicate data for at least one user using said sponsored data connectivity and in accordance with said at least one packet flow description associated with the at least one service.

1 1 . The application server according to claim 10, wherein the request includes at least one of: information identifying at least one user; information identifying an amount of data and/or an amount of time to be sponsored; an IP address associated with a user of said at least one service; information relating to a packet flow associated with said at least one application; and a reference.

12. The application server according to claim 10 or 1 1 , wherein said packet flow description comprises Service Data Flow, SDF, information (e.g. respective SDF information for all services provided by the application server).

13. The application server according to any of claims 10 to 12, further comprising a service capability server, SCS.

14. A core network node configured as a subscriber information repository, the core network node comprising: a transceiver operable to receive, from an interworking node, information identifying at least: an application server and at least one packet flow description associated with at least one service provided by the application server; and a processor operable to update, based on said received information, information associated with at least one subscriber profile held at said core network node; wherein said transceiver is operable to provide said updated information to a policy control node for generating a policy charging control, PCC, rule associated with said at least one service.

15. The core network node according to claim 14, wherein said transceiver is operable to provide said updated information to said policy control node upon request by said policy control node.

16. The core network node according to claim 14 or 15, wherein said transceiver is operable to provide said updated information to said policy control node upon setting up an Internet Protocol connectivity access network, IP-CAN, session for said at least one service provided by the application server.

17. A system comprising the interworking function according to any of claims 1 to 9, the application server according to any of claims 10 to 13, and the core network node according to any of claims 14 to 16.

18. A method performed by an interworking function for a cellular communication system, the method comprising: receiving, from an application server, a request for setting up sponsored data connectivity for at least one service provided by the application server, the request comprising information identifying at least: the application server and at least one packet flow description associated with the at least one service; determining, from the received information, information for forwarding to said cellular communication system; and sending the information for forwarding to a node of the cellular communication system responsible for managing (and/or storing) respective policy charging control, PCC, rules associated with a particular service.

19. A method performed by an application server for providing at least one service for nodes of a cellular communication system, the method comprising: sending, to an interworking function, a request for setting up sponsored data connectivity for at least one service provided by the application server, the request comprising information identifying at least: the application server and at least one packet flow description associated with the at least one service; and communicating data for at least one user using said sponsored data connectivity and in accordance with said at least one packet flow description associated with the at least one service.

20. A method performed by a core network node configured as a subscriber information repository, the method comprising: receiving, from an interworking node, information identifying at least: an application server and at least one packet flow description associated with at least one service provided by the application server; updating, based on said received information, information associated with at least one subscriber profile held at said core network node; and providing said updated information to a policy control node for generating a policy charging control, PCC, rule associated with said at least one service.

A computer program product comprising computer implementable instructions for causing a programmable computer device to perform the method of any of claims 18 to 20.