Patent Application
20120284189
The present invention relates to billing a subscriber for content delivered over a network, more specifically over a mobile communication network.
Networks of general purpose computer systems and specialized devices connected by external communication links are well known and widely used in commerce. The networks often include one or more network devices that facilitate the passage of information between the computer systems and devices. A network node is a network device or computer or specialized device connected by the communication links. An end node is a network node that is configured to originate or terminate communications over the network. An intermediate network node facilitates the passage of data between end nodes.
Subscribers obtain access to a packet-switched network (PSN) of an Internet Service Provider (ISP) through a network access gateway. The network access gateway determines whether an entity attempting access is in fact a subscriber authorized to access the network by exchanging packets with an Authentication, Authorization, and Accounting (AAA) server.
A modern ISP can offer different services to different subscribers. Network quality of service refers to techniques for providing different treatment for different flows of data packets between a subscriber's end node and a remote end node reached through the ISP's network. Rather than forwarding all packets of all flows with the same best effort, some flows receive preferential treatment in terms of more bandwidth, guaranteed minimum bandwidth, shorter delays, less variability in arrival time (such variability is called jitter) or less noise, or other benefits, alone or in some combination. An intermediate network node that provides network quality of service keeps statistics used for allocating forwarding resources for various flows.
Communications between network nodes are typically effected by exchanging discrete packets of data. Information is exchanged within data packets according to one or more of many protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other based on information sent over the communication links. Each packet typically comprises header information associated with a particular protocol, and payload information that follows the header information and contains information that may be processed independently of that particular protocol. The header includes information used by the protocol, such as the source of the packet, its destination, the length of the payload, and other properties, depending on the protocol. Often, the data in the payload for the particular protocol includes a header and payload for a different protocol associated with a different layer of detail for information exchange. The header for a particular protocol typically indicates a type for the next protocol contained in its payload. The usually higher layer protocol in the payload is said to be encapsulated in the lower layer protocol in the header.
The headers included in a packet traversing multiple heterogeneous networks, such as the Internet, typically include a physical (layer 1) header, a data-link (layer 2) header, an internetwork (layer 3) header and a transport (layer 4) header, as defined by the Open Systems Interconnection (OSI) Reference Model.
The data-link header provides information defining a particular communication link between one network node and an adjacent node. The internetwork header provides information defining the source and destination address within the computer network. Notably, the path may span multiple physical links. The internetwork header may be formatted according to the Internet Protocol (IP), which specifies IP addresses of both a source and destination node at the end points of the logical path. Thus, the packet may “hop” from node to node along its logical path until it reaches the end node assigned to the destination IP address stored in the packet's internetwork header. After each hop, the source or destination addresses in the packet's data-link header may be updated, as necessary. However, the source and destination IP addresses typically remain unchanged as the packet is transferred from link to link in the network. The IP payload often includes data for an application (layer 7 header and payload).
Routers and switches are intermediate network nodes that determine which communication link or links to employ to support the progress of data packets through the network. An intermediate network node that determines which links to employ based on information in the internetwork header (layer 3) is called a router.
These principles also apply to mobile communication networks. Mobile communication networks have been developed to provide a dynamic combination of voice, video, messaging, data, etc. within the same session. The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3 GPP) to provide IP Multimedia services over mobile communication networks.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals or user equipments (UE) (or user equipments and application servers). The Session Description Protocol (SDP), carried by SIP signaling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
Control of communications occurs at three layers. The lowest layer is the Connectivity Layer, also referred to as the bearer plane and through which signals are directed to/from user equipments accessing the network. The GPRS network includes 10 various GPRS Support Nodes (GSNs). A gateway GPRS support node (GGSN) acts as an interface between the GPRS backbone network and other networks (radio network and the IMS network or other Operator's IP services infrastructure). The Systems Architecture Evolution (SAE) Network includes various Evolved Packet Core (EPC) Nodes. A PDN gateway node (P-GW) acts as an interface between the EPC backbone network and other networks.
The IMS includes a core network, which operates over the middle, Control Layer and the Connectivity Layer, and a Service Network. The IMS core network includes nodes that send/receive signals to/from the GPRS network via the GGSN at the Connectivity Layer and network nodes that include Call/Session Control Functions (CSCFs), which operate as SIP proxies within the IMS in the middle, Control Layer. 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 user that the user 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.
At the top is the Application Layer, which includes the IMS service network. Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end-users, and may be connected either as end-points, or “linked in” by an S-CSCF.
The IMS architecture makes it possible to deploy peer-to-peer applications where two or more users exchange data during a SIP session. Examples of such peer-to-peer applications include Multimedia Telephony (MMTeI), Push to Talk over Cellular (PoC), streaming, real-time video sharing, file sharing, gaming etc. The transport connection is negotiated dynamically by means of the SIP/SDP protocol exchange between the two end points (user equipments).
In order to support such peer-to-peer applications, there are two requirements: a mechanism is needed to selectively control the SIP signal flows associated with the IMS session of a subscriber; and a functionality is needed to control the IP flows through the dynamically negotiated transport connections in order to apply an effective charging for usage of services. One important aspect concerns the resources required for the session, which will impact on the different Quality of Service (QoS) provided for the session (e.g. the data rate at which data is transferred between the end users). In the discussion below the term QoS is used to refer to those parameters of a requested or on-going session that determine the Quality of the session Service experienced by the end user. Though not the only one, the principal bearer resource characteristic affecting QoS is the available bandwidth for the session.
3GPP has recognized such needs and has defined a Policy and Charging Control (PCC) Architecture (see 3GPP TS 23.203).
A Policy and Charging Rules Function (PCRF) 14 resides in between the AF 16 and the PCEF 12. The PCRF 14 is the entity that controls policies and charging based on the monitored data flow. The PCRF 14 determines rules for charging and policies to be applied for a particular subscriber, by retrieving information over the Sp interface from a Subscription Profile Repository (SPR) 18, which includes a database of subscriber information. The PCRF 14 installs these PCC rules at the PCEF 12 over the Gx interface. These ensure that only authorized media flows associated with the requested services are allowed. In addition, the PCC rules installed at the PCEF 12 ensure that the right Qos, charging and priority are applied through the right bearer. Therefore, the PCRF 14 receives input from a Bearer Binding and Event Reporting Function BBERF 17 over the Gxx interface.
Once session characteristics are negotiated between the communication peers and the session characteristics are authorized within the AF (e.g IMS Core Network . . . ), the AF 16 provides to the PCRF 14 input over the Rx interface so that the corresponding resource reservation can be performed at the Connectivity Layer.
In practice, the PCRF interacts with other functions for its policy decisions. Based on inputs mainly related to the requested service, the network capability and user's subscription, the PCRF derives the Qos and the corresponding bandwidth to be applied.
Many events can trigger PCC decisions inducing Qos or bandwidth changes (for instance service description or Radio Access Technology change).
In case a user account has insufficient credits or when the account is refilled (respectively identified by the events OUT_OF_CREDIT and REALLOCATION_OF_CREDIT), the PCC has no means to dynamically change the Qos or bandwidth. In case the user account has insufficient credits, the PCC usually carries out a drastic session cut off, which is particularly annoying for the end users, when a simple Qos downgrading would be more appropriate. In case the user has refilled his account after a session was opened in downgraded mode, this refill does not lead to a dynamic improvement of the Qos or bandwidth. There is no suitable solution available for solving this technical problem.
Several propositions are being discussed in order to overcome these drawbacks. It has been proposed to interface the OCS with the PCRF, in order to dynamically change the Qos/bandwidth further to a billing event. Another proposal was to interface the OCS with the PCRF through the SPR, in order to dynamically change relevant user data for this Qos/bandwidth change. Another proposal was to integrate a combination of the OCS and PCRF functionalities in a single system. These propositions present drawbacks. These propositions either require a lengthy standardization process or are simply not appropriate for a great number of cases.
There is thus a need for a corresponding Qos control method overcoming these drawbacks.
The invention relates to a method for dynamically controlling the quality of service attributed for the communication session of a user equipment in a 3GPP compliant communication network, comprising the steps of:
In an embodiment, the online charging system detects an event on the account of the user of said session, said decision step being triggered by the detection step.
Said detected event can be that the user's account is inferior to a predetermined threshold, and said instruction is a request for downgrading the quality of service within the session.
The online charging system can grant credit units remaining on said user's account to said policy control enforcement function along with the sending of the change of quality of service instruction to be applied after the consumption of the final granted units.
Said policy control enforcement function may forward said instruction only once the granted credit units are exhausted.
According to another embodiment, said detected event is a replenishing of the user's account, and said instruction is a request for upgrading the quality of service within the session.
The online charging system may request said policy control enforcement function to re-authorize for current quota, before sending said change of quality of service instruction to it.
The change of quality of service instruction is preferably sent on a Gy interface between the OCS and the PCEF.
The change of quality of service instruction is preferably forwarded on a Gx interface between the PCEF and the PCRF.
The invention also relates to a system for a 3GPP compliant communication network, comprising:
In an embodiment, the online charging system is adapted to detect an event on the account of the user of said session, and adapted to decide said change of parameters based on the detection step.
The advantage of the present invention will become apparent from the following description of several embodiments with reference to the accompanying drawings, in which:
The invention proposes to dynamically control the quality of service attributed for the communication session of a user equipment in a 3GPP compliant communication network. During the communication session, the online charging system detects an event on the account of the user of the session. The online charging system decides that this event has to induce a change in the parameters of the applied quality of service. The online charging system sends a change of quality of service instruction to be applied, to a policy enforcement function. This policy enforcement function forwards the request to a policy and charging rules function. The policy and charging rules function then derives modified policy charging and control rules from forwarded instruction for change of quality of service within the session. The policy control enforcement function receives and applies the modified policy charging and control rules for the ongoing session.
Thus, the invention does not necessitate architecture changes. The invention can be carried out by minor extensions in the protocols supporting Gx and Gy interfaces either in an existing Attribute Value Pairs or in dedicated Attribute Value Pairs. A great variety of upgrades or downgrades of the Qos can be dynamically triggered by a real time study of a user's account balance. The invention requires only minor modifications of the PCEF, OCS and PCRF. Thus, the invention does not incur a major cost increase or a lengthy standardization process. The quality of service level can be considered as dynamically changed if said changes are carried out on an ongoing communication session.
At step 201, the user equipment (UE) initiates a session request to the Policy Control Enforcement Function (PCEF). At step 202, the PCEF sends a Gx CC request to the PCRF, requesting Policy and Charging rules.
At step 203, the PCRF derives PCC rules with Qos to be applied. The PCC rules are derived based on the network input provided by the PCEF, and possibly based on the AF input through the Rx interface and/or based on the SPR input through the Sp interface.
At step 204, the PCRF sends a Gx CC answer to the PCEF including the PCC rules with Qos to be applied. At step 205, the PCEF installs the PCC rules provided by the PCRF.
At step 206, the PCEF requests units to the OCS for the rating groups (RG) (corresponding to a charging key or charging parameters for a set of users and services) associated with these PCC rules, by sending a Gy CC Request.
At step 207, the OCS controls the user's account for the service in use and reserves units for the corresponding rating groups.
At step 208, the OCS grants units to the PCEF by sending a Gy CC Answer. At step 209, the PCEF enforces the installed PCC rules and establishes the communication session of the UE.
At step 210, the session continues with the installed PCC rules and the PCEF controls the consumed credits and regularly requests more units to the OCS.
At step 301, during the communication session of the UE, the PCEF requests additional units to the OCS through a Gy CC Request. At step 302, the OCS detects that the remaining units reserved for the session have reached a credit threshold in the user's account with the current Qos/bandwidth usage. The OCS generates corresponding dedicated instructions for changing the Qos/bandwidth beyond these remaining reserved units. The credit threshold can be set either for a pre-paid or a post-paid user's account.
At step 303, the OCS grants remaining reserved units to the PCEF and sends the generated instructions to the PCEF. At step 304, the remaining reserved units are consumed by continuing the communication session.
At step 305, the PCEF notifies the PCRF that the user's credit for the installed PCC rules is exhausted. The PCEF forwards the instructions generated by the OCS to the PCRF through a Gx CC Request. At step 306, the PCRF dynamically derives updated PCC rules with Qos to be applied further to the credit exhaustion. The updated PCC rules are derived based on the instructions forwarded by the PCEF and based on the network input provided by the PCEF. The internal rules of the PCRF can also be taken into account, and/or the AF input through the Rx interface and/or the SPR input through the Sp interface.
At step 307, The PCRF sends a Gx CC answer to the PCEF including the updated PCC rules with Qos to be applied. At step 308, the PCEF installs the updated PCC rules provided by the PCRF.
At step 309, the PCEF requests units to the OCS for the rating groups (RG) associated with these updated PCC rules, by sending a Gy CC Request.
At step 310, the OCS controls the user's account for the service in use and reserves units for the corresponding rating groups associated to the updated PCC rules.
At step 311, the OCS grants units to the PCEF by sending a Gy CC Answer. At step 312, the PCEF enforces the installed updated PCC rules and continues the communication session of the UE.
At step 401, a session is ongoing with previously installed PCC rules. The PCEF controls the consumed credits and regularly requests more units to the OCS.
At step 402, the user's account undergoes a change. At step 403, the OCS identifies that account change as an event that should modify the Qos/bandwidth applied to the communication session. For instance, the OCS can determine that a user account has been replenished or that the user has bought additional quota. For such events, the OCS determines that the Qos/bandwidth applied shall be upgraded.
At step 404, the OCS sends a Gy Re-authorization request to the PCEF. At step 405, the PCEF answers this Re-authorization request.
At step 406, the PCEF requests units to the OCS for the current rating groups (RG), by sending a Gy CC Request.
At step 407, the OCS determines that the user's account is such that the session shall be continued with improved Qos/bandwidth.
At step 408, the OCS informs the PCEF that an account threshold for the current Qos/bandwidth usage has been reached. The OCS generates corresponding dedicated instructions for changing the Qos/bandwidth to be applied next.
At step 409, the PCEF finds that no more quota are allocated.
At step 410, the PCEF notifies the PCRF that the quota for the installed PCC rules is exhausted. The PCEF forwards the instructions generated by the OCS to the PCRF through a Gx CC Request.
At step 411, the PCRF dynamically derives updated PCC rules with an upgraded Qos to be applied further to the account changes. The updated PCC rules are derived based on the instructions forwarded by the PCEF and based on the network input provided by the PCEF. As in the ‘B’ process, the internal rules of the PCRF can also be taken into account, and/or the AF input and/or the SPR input.
At step 412, the PCRF sends a Gx CC answer to the PCEF including the updated PCC rules with upgraded Qos to be applied. At step 413, the PCEF installs the updated PCC rules provided by the PCRF.
At step 414, the PCEF requests units to the OCS for the rating groups associated with these updated PCC rules, by sending a Gy CC Request.
At step 415, the OCS controls the user's account for the service in use and reserves units for the corresponding rating groups associated to the updated PCC rules.
At step 416, the OCS grants units to the PCEF by sending a Gy CC Answer. At step 417, the PCEF enforces the installed updated PCC rules and continues the communication session of the UE.
Each communication session can combine several services or several media flows within a same session. Within a session, each service or media flow can have its Qos changed independently from the other services or media flows. For instance, the Qos for a voice flow can be modified in parallel or at a different timing than the Qos for a video flow depending on the OCS decision.
The instructions generated by the OCS are interpretable by the OCS, the PCEF and the PCRF. These instructions can be high level descriptions of requested Qos/bandwidth changes, so they can be interpreted from a subscription and rating perspective by the OCS and/or from a network bearer characteristic perspective by the PCRF. Thus, different upgraded/downgraded modes are dynamically available for a given session when charging events occur on a user's account.
The OCS decision to modify the Qos of the previous examples is based on an event detection on a user's account. However, other parameters can also be taken into account to trigger the OCS decision. Such parameters can be internal rules of the OCS related to subscribers, the subscriber's profile, or the volume consumed by the user during a given period.
As illustrated in the architecture of
The invention is applicable to any 3GPP compliant mobile packet communication network. For instance, the invention can apply as to GPRS, UMTS or LTE communication networks.
| Number | Date | Country | Kind |
|---|---|---|---|
| 10290003.2 | Jan 2010 | EP | regional |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP2011/050097 | 1/5/2011 | WO | 00 | 7/5/2012 |
