WO2015005840A1

WO2015005840A1 - Method and apparatus for controlling service traffic in a communication network

Info

Publication number: WO2015005840A1
Application number: PCT/SE2013/051093
Authority: WO
Inventors: Peter Lindau Nordhammer; Irene Martin Cabello; Jiehong YANG
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2013-07-10
Filing date: 2013-09-18
Publication date: 2015-01-15

Abstract

The present solution relates to a service controller, an online charging system and methods for controlling service traffic in a communication network. The method comprises receiving a request for service traffic control in an online charging system, the request including at least data identifying a first communication network account, and determining based on the received data and a predefined set of rules, a first policy input information associated with the first account and a validity attribute of the policy input information. The method further comprises transmitting to a service controller a first policy control command identifying the policy input information and including the validity attribute of the policy input information, to be applied in controlling the service.

Description

METHOD AND APPARATUS FOR CONTROLLING SERVICE TRAFFIC IN A COMMUNICATION NETWORK

TECHNICAL FIELD

The present invention relates to a service controller, online charging system and methods for controlling service traffic in a communication network.

BACKGROUND

Operators of communication networks face a challenge in how to secure mobile broadband revenues.

The tremendous uptake in mobile broadband subscribers and data volume will require substantial investments in operators' telecom infrastructure. On the other hand, users will expect their operator to deliver the service experience they have paid for. Thus, operator revenues from mobile broadband rely on satisfied customers. A small fraction of the users generates traffic exceeding those of normal users with

magnitude. In many networks, these heavy users are consuming a quite large part of the network resources today. Experience shows that heavy users normally constitutes of 5-10% of the total subscribers, but could consume 70-85% of the network resources. It has been shown that often the heavy users are the biggest consumers of the network resources also during busy hour.

With policy control operators can distribute the traffic load more evenly, giving a defined Quality of Service (QoS), e.g. more bandwidth resources, for the normal users (the majority of the subscribers), particularly during the busy hour. Policy control also enables operators to push the heavy user traffic into the non-busy hours where number of normal users is lower. For some heavy user applications, time of day is not very critical since they click to download and leave the application running for hours or even days before completing a larger download. Policy control therefore helps controlling network capacity utilization by managing the traffic in a smarter way.

Today and in the future, operators are introducing new premium services, for example ring tones download, TV, video streaming, Voice over Internet Protocol, etc. To make sure that the subscribers get the best end user experience while consuming these premium services policy control is used to allocate more bandwidth for these applications when being accessed.

Operators use policy control to move away from a blanket, flat fee for everyone, to the right price for the right service at the right time ensuring users get the user experience paid for. This gives consumers the chance to choose a subscription that best meets their circumstances and decide how to act when the subscription doesn't meet their current, specific needs.

For operators, policy control makes it possible to get the most value from their bandwidth, by leveraging the right price for the right service at the right time.

In order to handle policy control and charging, the 3rd Generation Partnership Project (3GPP) has in TS 23.203 V. l l .10.0 specified a Policy and Charging Control (PCC) functionality encompassing the two main functions:

Flow Based Charging, including charging control and online credit control;

Policy control (e.g. gating control, QoS control, QoS signaling, etc.).

The PCC functionality is comprised by the functions of the Policy and Charging Enforcement Function (PCEF), the Bearer Binding and Event Reporting Function (BBERF), the Policy and Charging Rules Function (PCRF), the Application Function (AF), the Online Charging System (OCS), the Offline Charging System (OFCS) and the Subscription Profile Repository (SPR) or the User Data Repository (UDR).

The PCC architecture extends the architecture of an IP Connectivity Access Network IP- CAN, e.g. General Packet Radio Services (GPRS), where the PCEF is a functional entity in the gateway node implementing the IP access to the Packet Data Network (PDN).

The PCRF is the part of the network architecture that aggregates information to and from the network supporting the creation of rules and then making policy decisions for subscribers active on the network. EP 2 296 309 Al discloses a method for delivering policy rules to an end user, according on his/her account balance and service subscription level, in a telecommunication network.

MARC CHEBOLDAEFF: "Interaction between an Online Charging System and a Policy Server", IARIA ICN 2011, 23 January 2011 (2011-01-23), pages 47-51, XP002656352, Conference ICN2011 St. Maarten, The Netherlands Antilles; ISBN: 978-1-61208-113-7 describes interaction between an Online Charging System and a Policy Server.

GRGIC T ET AL: "Policy-based charging in IMS for multimedia services with negotiable QoS requirements", CAD SYSTEMS IN MICROELECTRONICS, 2009. CADSM 2009. 10 : TH INTERNATIONAL CONFERENCE - THE EXPERIENCE OF DESIGNING AND APPLICATION OF, IEEE, PISCATAWAY, NJ, USA, 8 June 2009 (2009-06-08), pages 257- 264, XP031514058, ISBN: 978-953-184-130-6 discloses policy based charging in FMS for multimedia services with negotiable QoS requirements.

EP 2 509 254 Al discloses a method and corresponding apparatus for controlling service traffic in a communication network wherein a network traffic policy profile is determined and a policy control command including an identifier identifying the network traffic policy profile is transmitted to the PCRF, to be applied in controlling the service.

However, there is a need to provide for the communication network to enforce a QoS in a more flexible way allowing better control in how a traffic policy is applied to the users' traffic, with the policy depending on what service the a communication terminal is entitle to utilize thereby avoiding network congestion.

SUMMARY

An object of the present solution is to provide a method and apparatus for controlling service traffic in a communication network avoiding the above mentioned problem.

A first aspect relates to a method for controlling service traffic in a communication network The method comprises receiving a request for service traffic control in an online charging system, the request including at least data identifying a first communication network account, and determining based on the received data and a predefined set of rules, a first policy input information associated with the first account and a validity attribute of the policy input information. The method further comprises transmitting to a service controller a first policy control command identifying the policy input information and including the validity attribute of the policy input information, to be applied in controlling the service.

A second aspect relates to a method for controlling service traffic in a communication network. The method comprises in a service controller transmitting a request for service traffic control to an online charging system, the request including at least data identifying a first communication network account. The method further comprises receiving from the online charging system a first policy control command identifying a policy input information and including a validity attribute of the policy input information. The method also comprises comparing the policy input information including the validity attribute with an event data and based on the comparison determining a policy to be applied in controlling the service.

A third aspect relates to an online charging system for controlling service traffic in a communication network. The online charging system comprises a processor and a memory containing instructions executable by said processor whereby said online charging system is operative to receive a request for service traffic control, the request including at least data identifying a first communication network account and to determine, based on the received data and a predefined set of rules, a first policy input information associated with the first account and a validity attribute of the policy input information. The online charging system is further operative to transmit to a service controller a first policy control command identifying the policy input information and including the validity attribute of the policy input information, to be applied in controlling the service.

A fourth aspect relates to a service controller for controlling service traffic in a

communication network, comprising a processor and a memory. The memory contains instructions executable by the processor whereby the service controller is operative to transmit to an online charging system a request for service traffic control, the request including at least data identifying a first communication network account. The service controller is further operative to receive from the online charging system a first policy control command identifying policy input information and including validity attribute of the policy input information. The service controller is also operative compare the policy input information including the validity attribute with an event data and based on the comparison; determine a policy to be applied in controlling the service.

A fifth aspect relates to an online charging system for controlling service traffic in a communication network. The online charging system comprises an interface module for receiving a request for service traffic control, the request including at least data identifying a first communication network account. The online charging system also comprises a determination module for determining, based on the received data and a predefined set of rules, first policy input information associated with the first account and a validity attribute of the policy input information. The interface module is also for transmitting to a service controller a first policy control command identifying the policy input information and including the validity attribute of the policy input information, to be applied in controlling the service. A sixth aspect relates to a service controller for controlling service traffic in a communication network. The service controller comprises an interface module for transmitting to an online charging system a request for service traffic control, the request including at least data identifying a first communication network account; and for receiving from the online charging system a first policy control command identifying a policy input information and including a validity attribute of the policy input information. The service controller also comprises a determination module for comparing the policy input information including the validity attribute with an event data and based on the comparison, determining a policy to be applied in controlling the service.

An advantage is that the solution provides for a service controller, for example a PCRF, to receive validation information and can thereby determine in which situation the policy input information is valid and thereby to support more advanced communication scenarios with service control.

Embodiments of the present solution will now be described in more detail with reference to the enclosed drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram showing a PCC architecture according to an exemplary embodiment of the present solution.

Figure 2 is a block diagram showing a PCC architecture where exemplary embodiments of the present solution is useful.

Figure 3 is a message sequence chart showing a method for controlling services in a communication network according to an exemplary embodiment of the present solution.

Figure 4 is a flow chart showing an exemplary embodiment of a method for controlling services in a communication network according to the present solution. Figure 5 is a block diagram showing an exemplary computing device for implementing an online charging system or a service controller for controlling services in a communication network according to an exemplary embodiment.

DETAILED DESCRIPTION

The following detailed description of the exemplary embodiments refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. Also, the following detailed description does not limit the present solution.

Figure 1 is a block diagram showing a PCC architecture according to an exemplary embodiment of the present solution allowing a user equipment (UE) 190 access to a Packet Data Network (PDN) 195 via an IP Connectivity Access Network IP CAN 185, e.g. GPRS.

The Rx reference point 165 connects the Application Function (AF) 170 and the Policy and Charging Rules Function (PCRF) 120. This reference point enables transport of application level session information from AF to PCRF The Gx reference point 150 connects the Policy and Charging Enforcement Function (PCEF) 130 of a gateway 135, e.g. a GPRS Gateway Support Node (GGSN), and the PCRF and enables a PCRF to have dynamic control over the PCC behavior at a PCEF. The Gx reference point enables the signaling of PCC decisions, which governs the PCC behavior.

The Gxx reference point 155 connects the Bearer Binding and Event Reporting Function (BBERF) 160 and the PCRF. The Gxx reference point enables a PCRF to have dynamic control over the BBERF behavior.

The Sp reference point 175 connects the Subscription Profile Repository (SPR) 180 and the PCRF. The Sp reference point allows the PCRF to request subscription information related to the IP CAN transport level policies from the SPR based on a subscriber ID, a Packet Data Network (PDN) identifier and possible further IP CAN session attributes.

The Gy reference point 125 connects the Service Data Flow Based Credit Control component 110 of an Online Charging System (OCS) 105 and the PCEF. The Gy reference point allows online credit control for service data flow based charging. The Gz reference point 140 connects the PCEF and the Offline Charging System (OFCS) 145 and enables transport of service data flow based offline charging information.

The PCRF is connected to a PCEF to handle policy enforcement. The PCRF is also connected to an OCS to get Policy Input Information (PII). In order to provide policy information valid for a Gx 150 session to PCRF 120 based on information available in OCS 105 (information like product offerings, time of day based tariff, usage, location etc.) an interface Sy 115 between PCRF and OCS is introduced. By using the Sy interface, the PCRF is able to get policy input information from the OCS.

The 3 GPP PCC architecture specifies one type of PII, the Policy Counter Status (PCS) information, and how the PCS is sent from OCS to PCRF. The PCS can be used to indicate if a limit has been reached or not. The Sy interface is used between OCS and PCRF to transport this information.

The protocol implemented on the Sy interface may also support sending a Network Traffic Policy Profile (NTPP) or a parameter identifying such an NTPP stored in a NTPP Entity 122 accessible by the PCRF, as PII answer to a request from the PCRF.

The OCS, by using subscription information and usage information may add validation information to the PII, e.g. the PCS or the NTPP. The PCRF can by using the validation information connected to the PII decide in which situation the PII is valid. The validation information could for example be device identity or personal date/data information but also a location information such as cell identity or a satellite based position.

Thereby, the solution includes the possibility to send additional validation information for the PII from OCS to PCRF to support more advanced use cases.

One example of such use cases when a user has a subscription allowing multiple devices" and where several devices are sharing a common account/bundle. Each device also has a limit of how much usage is allowed for that specific device. The device is identified by either

International Mobile Equipment Identity (FMEI), as identifier of the hardware, or International Mobile Subscription Identity (IMSI), as identifier of the Subscriber Identity Module (SIM) card in the device. Different actions are taken for that specific device such as decrease the bandwidth or stop the access to certain services when the limit of the device is reached. Other devices connected to that subscription should not be affected. For this example the information about the subscription "Multiple Devices", total usage and usage per device is stored in OCS but needs not to be stored in PCRF to avoid duplication of information, duplicate reporting of usage and duplication of provisioning.

Thus, the OCS may by using for example subscription information and usage information add validation information to a policy control command as Policy Input Information PII (e.g. a PCS or a NTPP). A PCRF receiving the validation information can thereby decide in which situation the PII is valid. The validation information could for example be device identify, personal date information such as birthday or a location such has a home or work address

The Sy interface may use existing Diameter base (RFC 3588) and Diameter Credit Control (DCC) commands (RFC 4006) such as Credit Control Request (CCR), Credit Control Answer (CCA), Re- Authorization Request (RAR) and Re- Authorization Answer (RAA). 3 GPP has defined spending limit reporting over Sy the reference point in TS 29.219 VI 1.5.0 wherein for example a Spending-Limit-Request (SLR) command corresponds to the CCR and a Spending-Limit-Answer (SLA) command corresponds to the CCA. In the OCS a Policy Data Definition PDD) is created in a Determination module (also referred to as a determination unit) (DM) 107 of the OCS. Based on a configuration of selection rules of the PDD, e.g. selection trees, a PII and optionally additional PII attributes will be determined by the DM when traversing the selection rules. Thus, in one alternative solution a special rule set separate from the rating rule set, e.g. a special network traffic policy profile rule tree is introduced in DM for policy profile determination. This policy profile rule tree may then be used for deciding policy both at Sy requests and when rechecking policy after a Gy request.

The NTPP may thus be determined by the policy rule tree, where for example subscriber group defined by Service Class and Offers data are provisioned, and these data can thereby be used to affect the NTPP being selected by being part of the conditions in the policy rule tree structure.

The PCRF uses the chosen PII and attributes to set the Quality of Service QoS for a data session.

A request for PII determination from the PCRF to the OCS, e.g. a Diameter CCR Initial (S RFC 4006) or SLR, over Sy may support conveying the following parameters: Subscriber-Id

Serving GPRS Support Node (SGSN) Address, used for deciding the NTPP and attributes in DM

SGSN-MCC-MNC (identifies PLMN), used for deciding the NTPP and attributes in DM

User Location Information, used for deciding the NTPP and attributes in DM

MS-Time-Zone, used for deciding the NTPP and attributes in DM

Access Network Charging Identifier Gx and Access Network Charging Address, used for correlation of Sy and Gy sessions in OCS. An interface module 108 is used to communicate with other function units e.g. PCRF over Sy or PCEF over Gy. The interface module may comprise a LAN/WAN interface or a local connection or bus connecting the OCS to functional units of other physical nodes. The interface module may also comprise a software unit allowing communication with logical functional units residing on the same physical node. Figure 2 is a block diagram showing a PCC architecture where exemplary

embodiments of the present solution is useful.

Following a policy decision request 205 received over Sy via interface module 108, a Mobile Subscriber ISDN Number (MSISDN) e.g. 123456789 is received in the request and is used to access subscriber related data from a database 250 of the DM 107. Access to subscriber related data may include determining service packages as offers subscribed to, e.g. a service "data gold" with the identifier "400", accumulator values storing subscriber parameters, subscriber group data as service class e.g. "Normal Subscriber" etc. Further data related to the subscribed service packages may also be accessed. For example, the Data Gold package may include a multiple device option where several devices are sharing a common account up to a certain threshold. In the present example the multiple device option provides for two devices to share the account. A first device having IMSI 345345 is provisioned and allowed to consume an amount of 1000 (e.g. MB of data transmission) and a second device is provisioned for the subscription with an allowed consumption amount of 3000 (e.g. MB). A counter keeping track of the present usage may also be accessed. In the present example the first device has consumed its allowed 1000 (MB) and the second device has consumed 2200 (MB). Other subscriber identifiers than MSISDN (E.164) is possible, e.g. International Mobile Subscriber Identity (IMSI), E.212, Session Initiated Protocol - Uniform Resource Locator (SIP-URI), RFC 3261, Network Access Identifier (NAI), RFC 2486 and PRIVATE. In one exemplary solution the identifications are processed in the order that they appear in the id received. The first id that results in "subscriber found" in the database 220 may be used.

The DM 107 holds a Policy Data Definition PDD 210 which may define a plurality of service package products, e.g. the "data gold" product offer "400" offering the user a fixed usage allowance with a higher QoS and when such usage allowance has been consumed the user may continue services with a lower QoS. In the present example, the PDD is configured with the "data gold" product which allows a subscriber having access to the service package to utilize two devices. One first device is allowed a higher QoS while a second device is allowed a lower QoS. The "gold data" is configured with rules determining that the first device is entitled to utilize NTPPId=100 provided that the present usage is below a threshold.

Similarly, a second device is entitled to utilize the NTPPId=20 provided a threshold value is not exceeded.

Using the subscriber's static or near static data retrieved from the database 250 possibly augmented with dynamic data received via the request 205 a PII such as an NTPP is determined by applying the selection rules of the PDD 210. In the present example, for "data gold" package, the selection rule for the package defines that device 1 should be checked for and that the present usage does not exceeds the threshold.

Since usage for devicel .counter=1350 exceeds the threshold=1000 the NTPPId=100 is not usable for the subscriber.

The PDD is continued to be traversed and for the low QoS alternative it is checked whether device2 exceeds the threshold. Since device2.counter=2200 it does thereby not exceed the threshold. NTPPId=20 is therefore usable for the subscriber provided the device2 having IMSI 876876 is used.

E.g. specific NTPP identification "100" is determined. Optionally one or a plurality of additional policy attributes may also be determined by the PDD.

A response message 215 containing the NTPP identifier NTPPId=20 and validation information as a validity attribute FMSI=876876 and optional attributes is then transmitted to the PCRF via interface module 108. The identifier identifies the corresponding NTTP 250 in the PCRF 120 which may define attributes such as uplink bit rate, downlink bit rate, priority etc. set to specific values.

In one solution, the response message may comprise a plurality of identifiers identifying a plurality of network traffic policy profiles and a priority value indicating which NTPP to apply when several are applicable to the service.

In a further possible solution, the interface Sy provides for the response message to convey a NTTP including the NTTP identity, should the profile not be available to the PCRF.

Thus, the NTTP identifier, and where applicable the additional policy attributes, rule activation time, rule de-activation time, revalidation time, priority and additional NTTP identifier is responded back to the PCRF in answer 215.

Thus, once a request is received from policy request is received from the PCEF of the gateway via the Gx interface, including the identity of the subscription and an IMSI. The PCRF determined the policy to be used by comparing the EVISI received from the PCEF with the EVISI received as validation attribute with the NTPP and decides policy based on the NTPP and possibly other information available.

In step 305 a request message from the network, e.g. PCEF 130, is sent to the PCRF 120 including the identity of the subscription, e.g. MSISDN. The request message may as an option include further parameters useful for validating whether a policy may be applied, such as the identity of the device used. For example, a Packet Data Protocol (PDP) context activation triggers the PCEF of the gateway, e.g. GGSN, 135 to request authorization by sending request for service traffic control as a CCR Initial request including for example MSISDN, QoS-Information, Charging -Id, SGSN-address, SGSN-MCC-MNC, User- Location, Time-Zone etc to the PCRF.

The PCRF requests for PII from the OCS including the identity of the subscription in step 310. For example, the OCS receives the Sy CCR Initial or SLR request from the PCRF. In one possible solution the request may include an access network charging address and an access network charging identifier, e.g. an Access-Network-Charging-Identifier-Gx. Parameters in the Sy CCR Initial or SLR may include MSISDN, Charging Id, SGSN- Address, SGSN-MCC-MNC, User Location, Time Zone etc.

In step 311, based on the subscription information and usage information the OCS decides which PII and validation information that should be returned to PCRF. Using MSISDN a subscriber account and associated service packages may be identified. The DM 107 of the OCS is then interrogated for policy determination. Parameters that may be included in the Sy CCR Initial and used in the policy determination are

3GPP-MS-TimeZone

3 GPP-RAT-Type

· 3GPP-SGSN-Address

3GPP-SGSN-MCC-MNC

• 3 GPP -User-Location-Info

Called-Station-ID

RAT-Type

· User-Equipment-Info

The policy input information, such as a network traffic policy profile, and attributes associated with the account is then determined based on the data received in the request and/or account data and stored. Examples of account data are service packages or subscriber group data, e.g. Service Class, associated with the account. The OCS sends a policy control command including PII and the validation information for the PII over Sy in step 315. The PII can include several PII instances and validation information as validity attribute for each PII instance. The policy control command may be sent as a CCA Initial response to the PCRF including an NTTP identifier as policy data and optionally an event trigger. The identifier is identifying a network traffic policy profile stored in a network traffic policy profile entity so that it may be applied in controlling the service.

In step 320 the received policy input information, e.g. NTPP identifier, is evaluated by the PCRF to obtain policy parameters stored in the NTTP Entity identified by the identifier.

The PCRF determines the policy to be used by comparing the information received from the network with the validation information for each PII to decide which PII(s) to use, and decide policy based on PII and other information available. The PCRF responds to the network with the decided policy with a CCA Initial over Gx to the PCEF providing the policy information in step 325.

Figure 4 is a flow chart showing an exemplary embodiment of a method for controlling services in a communication network according to the present solution.

The solution may be based on an integrated charging and policy architecture as specified by 3 GPP in the Policy and Charging Control (PCC) architecture. The PCC architecture includes the Sy interface between the Online Charging System (OCS) and the Policy and Charging Rules Function (PCRF) as service controller.

Initial configuration of subscription and policy rules may be done once per subscription. Initial provisioning may be done once per subscription. Requests from the network may be received one or several times for a user session. A user session could for example be one instance of a data connection.

The OCS is configured in step 410 wherein the subscriptions are configured, including for example usage accumulation per device.

It is also included in the subscription configuration that the value of each PII instance may depend on the value of the usage accumulation for the device mapped to the PII instance. The subscription information may include "usage accumulation per device" (example specification where multiple instances are possible):

Define item:

device 1 that contains an EVISI, a counter with threshold

Define rule:

If device l .IMSI equals input IMSI then increase devi cel . counter with volume usage

It is also included in the subscription configuration that each device may map to an instance of PII (instance of PCS or NTPP). The subscription information may thus include "Device to PII mapping" (example specification where multiple instances are possible):

Define item:

PolicyCounterl with validation information

Define rule:

If devicel subscribed then use PolicyCounterl The subscription information may further include "Rules to set values in ΡΠ" (example specification where multiple instances are possible):

Define item:

PolicyCounterStatusl=NOT_PASSED

PolicyCounterStatus2=PASSED

Define rule:

If devicel . counter below threshold then set PolicyCounterl to PolicyCounterStatusl else set PolicyCounterl to PolicyCounterStatus2

It is also included in the subscription configuration that validation information may be added to each PII instance including the identity of the device. The subscription information may thereby include "Rules to set validation information for PII to the device identity" (example specification where multiple instances are possible):

Define item: Define rule:

If devicel subscribed then set validation information for PolicyCounterl to devicel . IMSI

In step 420 the policy rules in PCRF including using the PII instances are configured. The policy rules includes that the value of the PII instances should be used as input to the policy decision. The policy rules also includes that the PII instances used for a policy decision is decided using but not limited to the validation information for each PII instance. Further, the policy rules includes that the PII instances used for a policy decision is decided comparing the identity of the device included in validation information for the PII instance with the identity of the device received in the request from the network.

For example, the PII is used as input to the rules. The validation information for the rules are then compared to event data received from the network (e.g. from the PCEF) such as for example present device identity, to find a valid PII.

Subscriptions are then provisioned in the OCS in step 430. For example the provisioned subscription can be identified as "subscriptionl". The provisioning may include the included devices and their identity, e.g. devicel TMSI = 1234567 and .threshold = 1000; and device2 .IMSI = 2345678 and .threshold = 3000. The provisioning may also include usage accumulation such as device 1. counter = X and device2. counter = Y.

A request for service traffic control for a service is received from the network, e.g. PCEF, by the PCRF in step 440. The request includes the identity of the subscription and the identity of the device used.

In step 450 the PCRF transmits a request for service traffic controlto the OCS. The request includes at least data identifying a communication network account, e.g. the identity of the subscription.

Based on the received data and a predefined set of rules, (e.g. based on subscription information and usage information) OCS determines which policy input information and validity attribute that should be returned to PCRF in step 460.

A validity attribute may be a relatively static data related to the individual subscriber such as terminal identity (e.g. IMSI, IMEI), subscriber date information such as birthday, subscription location data such as home location etc. These can then be compared by the service controller (e.g. PCRF) with event data, which may be more dynamic data, such as present terminal used, present date, present location (e.g. home location) defined using cell identity or

latitude/longitude information determined using e.g. GPS/AGPS. Event data may be information included in the request to the service controller which is received from a policy enforcer in the network, such as a 3 GPP PCEF. The OCS answers the request from PCRF including the PII and the validation information for each PII in step 470 by transmitting a policy control command to the PCRF identifying the policy input information and including the validity attribute of the policy input information, to be applied in controlling the service. The policy input information may be an NTPP or an identifier identifying NTPP stored in a network traffic policy profile entity, or it may be a PCS.

The policy input information determined by the OCS and transmitted to the PCRF may include plural policy input information instances, and wherein the validity attribute includes plural validity attribute instances each associated with one or more of the plural policy input information instances. In step 480 the PCRF determines the policy to be used by comparing event data with the validity attributes for each PII (or PII instance if plural exists) to determine which PII(s) are valid to use for the service.

The PCRF then decides the policy to be applied in controlling the service based on the valid PII(s) and other information available in step 490. The decided policy may involve decreasing bandwidth or stopping access to certain services.

In step 495 the PCRF answers back to the network with the decided policy.

Thus, where the PII is sent from OCS to PCRF together with validation information it is possible to decide in PCRF which PII is valid and should be used for a session. An advantage is that the solution provides the possibility to have subscription information and accumulation stored in OCS only but still has the possibility to have different policy decision based on individual or device specific information such as accumulation of for example sent and/or received data volume per device.

Figure 5 is a block diagram showing an exemplary computing device for implementing a system for controlling services in a communication network according to an exemplary embodiment.

Although as made clear above, the computing system environment 500 is only one example of a suitable computing environment for an Online Charging System or a Policy Control Rules Function and is not intended to suggest any limitation as to the scope of use or functionality of the claimed subject matter. Further, the computing environment 800 is not intended to suggest any dependency or requirement relating to the claimed subject matter and any one or combination of components illustrated in the example operating environment 500.

Looking now to FIG. 5, an example of a device for implementing the previously described solution includes a general purpose computing device in the form of a computer 510.

Components of computer 510 can include, but are not limited to, a processing unit 520, a system memory 530, and a system bus 521 that couples various system components including the system memory to the processing unit 520. The system bus 521 can be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. Computer 510 can include a variety of transitory and non-transitory computer readable media. Computer readable media can be any available media that can be accessed by computer 510. By way of example, and not limitation, computer readable media can comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile as well as removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, program units or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 510.

Communication media can embody computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and can include any suitable information delivery media. The system memory 530 can include computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) and/or random access memory (RAM). A basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within computer 510, such as during start-up, can be stored in memory 530. Memory 530 can also contain data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 520. By way of non-limiting example, memory 530 can also include an operating system, application programs, other program modules, and program data.

The system memory 530 may include a determination module 107 and an interface module 108 as software modules loaded in the memory and processable by the processing unit, or other circuitry, adapting the computer for performing the steps of the service controller or online charging system according to the disclosed solution.

As an example, the determination module and interface module may be adapting the computer 510 into online charging system for controlling service traffic in a communication network. The online charging system comprises a processor and a memory and the memory contains instructions executable by the processor. The online charging system is thereby operative to receive a request for service traffic control, the request including at least data identifying a first communication network account and to determine, based on the received data and a predefined set of rules, a first policy input information associated with the first account and a validity attribute of the policy input information. The online charging system is further operative to transmit to a service controller a first policy control command identifying the policy input information and including the validity attribute of the policy input information, to be applied in controlling the service.

As a further example, the determination module and interface module may be adapting the computer 510 into service controller for controlling service traffic in a communication network. The service controller comprises a processor and a memory and the memory contains instructions executable by the processor. The service controller is thereby operative to transmit to an online charging system a request for service traffic control, the request including at least data identifying a first communication network account. The service controller is further operative to receive from the online charging system a first policy control command identifying a policy input information and including a validity attribute of the policy input information. The service controller is also operative compare the policy input information including the validity attribute with an event data and based on the comparison; determine a policy to be applied in controlling the service.

The computer 510 can also include other removable/non-removable and

volatile/nonvolatile computer storage media. For example, computer 510 can include a hard disk drive that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive that reads from or writes to a removable, nonvolatile magnetic disk, and/or an optical disk drive that reads from or writes to a removable, nonvolatile optical disk, such as a CD-ROM or other optical media. Other removable/non-removable,

volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM and the like. A hard disk drive can be connected to the system bus 521 through a non-removable memory interface such as an interface, and a magnetic disk drive or optical disk drive can be connected to the system bus 521 by a removable memory interface, such as an interface.

A user can enter commands and information into the computer 510 through input devices such as a keyboard or a pointing device such as a mouse, trackball, touch pad, and/or other pointing device. Other input devices can include a microphone, joystick, game pad, satellite dish, scanner, or similar devices. These and/or other input devices can be connected to the processing unit 520 through user input 540 and associated interface(s) that are coupled to the system bus 521, but can be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB).

A graphics subsystem can also be connected to the system bus 521. In addition, a monitor or other type of display device can be connected to the system bus 521 through an interface, such as output interface 550, which can in turn communicate with video memory. In addition to a monitor, computers can also include other peripheral output devices, such as speakers and/or printing devices, which can also be connected through output interface 550.

The computer 510 can operate in a networked or distributed environment using logical connections to one or more other remote computers, such as remote server 570, which can in turn have media capabilities different from device 510. The remote server 570 can be a personal computer, a server, a router, a network PC, a peer device or other common network node, and/or any other remote media consumption or transmission device, and can include any or all of the elements described above relative to the computer 510. The logical connections depicted in FIG. 5 include a network 571, such as a local area network (LAN) or a wide area network (WAN), but can also include other networks/buses.

When used in a LAN networking environment, the computer 510 is connected to the LAN 571 through a network interface or adapter 560. When used in a WAN networking

environment, the computer 510 can include a communications component, such as a modem, or other means for establishing communications over a WAN, such as the Internet. A communications component, such as a modem, which can be internal or external, can be connected to the system bus 521 through the user input interface at input 540 and/or other appropriate mechanism.

In a networked environment, program modules depicted relative to the computer 510, or portions thereof, can be stored in a remote memory storage device. It should be noted that the network connections shown and described are exemplary and other means of establishing a communications link between the computers can be used.

Additionally, it should be noted that as used in this application, terms such as "component," "display," "interface," and other similar terms are intended to refer to a computing device, either hardware, a combination of hardware and software, software, or software in execution as applied to a computing device. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program and a computing device. As an example, both an application running on a computing device and the computing device can be components. One or more components can reside within a process and/or thread of execution and a component can be localized on one computing device and/or distributed between two or more computing devices, and/or communicatively connected modules. Further, it should be noted that as used in this application, terms such as "system user," "user," and similar terms are intended to refer to the person operating the computing device referenced above.

When an element is referred to as being "connected", "coupled", "responsive", or variants thereof to another element, it can be directly connected, coupled, or responsive to the other element or intervening elements may be present. In contrast, when an element is referred to as being "directly connected", "directly coupled", "directly responsive", or variants thereof to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, "coupled", "connected", "responsive", or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and/or clarity. The term "and/or" includes any and all combinations of one or more of the associated listed items.

As used herein, the terms "comprise", "comprising", "comprises", "include",

"including", "includes", "have", "has", "having", or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof. Furthermore, as used herein, the common abbreviation "e.g.", which derives from the Latin phrase "exempli gratia," may be used to introduce or specify a general example or examples of a previously mentioned item, and is not intended to be limiting of such item. The common abbreviation "i.e.", which derives from the Latin phrase "id est," may be used to specify a particular item from a more general recitation.

It should also be noted that in some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated.

Finally, other blocks may be added/inserted between the blocks that are illustrated. Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

Many different embodiments have been disclosed herein, in connection with the above description and the drawings. It will be understood that it would be unduly repetitious and obfuscating to literally describe and illustrate every combination and subcombination of these embodiments. Accordingly, the present specification, including the drawings, shall be construed to constitute a complete written description of various exemplary combinations and subcombinations of embodiments and of the manner and process of making and using them, and shall support claims to any such combination or subcombination.

Many variations and modifications can be made to the embodiments without substantially departing from the principles of the present solution. All such variations and modifications are intended to be included herein within the scope of the present solution.

Claims

1. A method for controlling service traffic in a communication network (100), comprising in an online charging system (105) performing the steps of:

- receiving (310, 450) a request for service traffic control, the request including at least data identifying a first communication network account;

- determining (313, 460), based on the received data and a predefined set of rules, a first policy input information associated with the first account and a validity attribute of the policy input information;

- transmitting (315, 470) to a service controller (120) a first policy control command identifying the policy input information and including the validity attribute of the policy input information, to be applied in controlling the service.

2. A method according to claim 1 wherein the policy input information is a network traffic policy profile.

3. A method according to claim 2 wherein the policy control command includes an identifier identifying the first network traffic policy profile stored in a network traffic policy profile entity (122).

4. A method according to claim 1 wherein the policy input information is a policy counter status.

5. A method according to any one of claims 1-4 wherein the validity attribute is a device identifier.

6. A method according to claim 5 wherein the device identifier is an IMSI or an IMEI.

7. A method according to any one of claims 1-4 wherein the validity attribute is subscriber date information.

8. A method according to any one of claims 1-4 wherein the validity attribute is a subscription location data.

9. A method according to any one of the preceding claims wherein the first policy input information includes plural policy input information instances, and wherein the validity attribute includes plural validity attribute instances each associated with one or more of the plural policy input information instances.

10. A method for controlling service traffic in a communication network (100), comprising in a service controller (120) performing the steps of:

- transmitting (310, 450) to an online charging system (105)a request for service traffic control, the request including at least data identifying a first communication network account; - receiving (315, 470) from the online charging system (105) a first policy control command identifying a policy input information and including a validity attribute of the policy input information;

- comparing (480) the policy input information including the validity attribute with an event data; and

-based on the comparison, determining a policy (490) to be applied in controlling the service.

11. A method according to claim 10 wherein the policy input information is a network traffic policy profile.

12. A method according to claim 11 wherein the policy control command includes an identifier identifying the first network traffic policy profile stored in a network traffic policy profile entity (122).

13. A method according to claim 10 wherein the policy input information is a policy counter status

14. A method according to any one of claims 10-13 wherein the validity attribute is a device identifier.

15. A method according to claim 14 wherein the device identifier is an IMSI or an IMEI.

16. A method according to any one of claims 10-13 wherein the validity attribute is a subscriber date information.

17. A method according to any one of claims 10-13 wherein the validity attribute is a subscription location data.

18. A method according to any one of claims 10-17 wherein the first policy input information includes plural policy input information instances, and wherein the validity attribute includes plural validity attribute instances each associated with one or more of the plural policy input information instances.

19. An online charging system (105) for controlling service traffic in a communication network (100), comprising a processor (520) and a memory (530) containing instructions executable by said processor whereby said online charging system is operative to:

- receive a request for service traffic control, the request including at least data identifying a first communication network account;

- determine, based on the received data and a predefined set of rules, a first policy input information associated with the first account and a validity attribute of the policy input information;

- transmit to a service controller (120) a first policy control command identifying the policy input information and including the validity attribute of the policy input information, to be applied in controlling the service.

20. An online charging system according to claim 19 wherein the policy input information is a network traffic policy profile.

21. An online charging system according to claim 20 wherein the policy control command includes an identifier identifying the first network traffic policy profile stored in a network traffic policy profile entity (122).

22. An online charging system according to claim 19 wherein the policy input information is a policy counter status.

23. An online charging system according to any one of claims 19-22 wherein the validity attribute is a device identifier.

24. An online charging system according to claim 23 wherein the device identifier is an IMSI or an IMEI.

25. An online charging system according to any one of claims 19-22 wherein the validity attribute is a subscriber date information.

26. An online charging system according to any one of claims 19-22 wherein the validity attribute is a subscription location data.

27. An online charging system according to any one of claims 19-26 wherein the first policy input information includes plural policy input information instances, and wherein the validity attribute includes plural validity attribute instances each associated with one or more of the plural policy input information instances.

28. A service controller (120) for controlling service traffic in a communication network (100), comprising a processor (520) and a memory (530), said memory containing

instructions executable by said processor whereby said service controller (120) is operative to:

- transmit to an online charging system (105)a request for service traffic control, the request including at least data identifying a first communication network account; - receive from the online charging system (105) a first policy control command identifying a policy input information and including a validity attribute of the policy input information;

- compare the policy input information including the validity attribute with an event data; and -based on the comparison, determining a policy to be applied in controlling the service.

29. A service controller according to claim 28 wherein the policy input information is a network traffic policy profile.

30. A service controller according to claim 29 wherein the policy control command includes an identifier identifying the first network traffic policy profile stored in a network traffic policy profile entity (122).

31. A service controller according to claim 28 wherein the policy input information is a policy counter status

32. A service controller according to any one of claims 28-31 wherein the validity attribute is a device identifier.

33. A service controller according to claim 32 wherein the device identifier is an IMSI or an IMEI.

34. A service controller according to any one of claims 28-31 wherein the validity attribute is subscriber date information.

35. A service controller according to any one of claims 28-31 wherein the validity attribute is a subscription location data.

36. A service controller according to any one of claims 28-35 wherein the first policy input information includes plural policy input information instances, and wherein the validity attribute includes plural validity attribute instances each associated with one or more of the plural policy input information instances.

37. An online charging system (105) for controlling service traffic in a communication network (100) whereby said online charging system comprises:

- an interface module (108) for receiving a request for service traffic control, the request including at least data identifying a first communication network account;

- a determination module (107) for determining, based on the received data and a predefined set of rules, a first policy input information associated with the first account and a validity attribute of the policy input information;

- the interface module for transmitting to a service controller (120) a first policy control command identifying the policy input information and including the validity attribute of the policy input information, to be applied in controlling the service.

38. A service controller (120) for controlling service traffic in a communication network (100) whereby said service controller (120) comprises:

- an interface module (108) for transmitting to an online charging system a request for service traffic control, the request including at least data identifying a first communication network account;

- the interface module for receiving from the online charging system (105) a first policy control command identifying a policy input information and including a validity attribute of the policy input information;

- a determination module for comparing the policy input information including the validity attribute with an event data and based on the comparison, determining a policy to be applied in controlling the service.