MACHINE-TO-MACHINE NETWORK OPTIMIZATION AND ONLINE CHARGING

Abstract

Systems and methods for improving efficiency in a mobile communications network are described. In one embodiment, a method granting data resources to one or more subscribers belonging to a group in a communications network comprises receiving a request to create an online charging session, wherein the request identifies a designated user group (“DUG”) associated with one or more subscribers. If the DUG is not associated with an existing online charging session, the DUG identifier can be used to request a new online charging session and receive from the online charging node policy data assigned to the DUG. In another embodiment, the method includes grating data resources to the one or more subscribers based on the policy data, which are shared by the one or more subscribers.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a divisional of U.S. patent application Ser. No. 15/840,269, filed on Dec. 13, 2017, which claims the benefit under 35 U.S.C. § 119(e) to U.S. Provisional Application No. 62/433,412, entitled “MACHINE-TO-MACHINE NETWORK OPTIMIZATION AND ONLINE CHARGING,” filed on Dec. 13, 2016, the contents of each of which are incorporated by reference herein in their entirety.

FIELD OF INVENTION

The invention generally relates to telecommunications systems and, in particular, to “machine to machine” (M2M) and radio access network (RAN) communication systems.

BACKGROUND

Machine to machine (M2M) communication is a rapidly expanding area in wireless network technology. M2M devices can be: real time or non-real time, low throughput or high throughput, and mobility or no mobility type. The number of M2M devices is expected to reach 1 billion devices by around 2020. With such a dramatic increase in scale, traditional subscriber traffic models and billing/charging plans are not likely to be feasible. In addition, although the number of M2M devices that are connected to long-term evolution (LTE) networks is very high, operators do not receive revenue for each M2M device. Although some M2M devices may fit into existing 3^rd Generation Partnership Project (3GPP) defined charging, not all types of M2M devices will be accommodated.

Operators often need to invest in LTE equipment in proportion to their subscriber counts, however the associated revenue generation is not proportional to the investment. With the advent of M2M, operators may also need to support an increased number of mobility management entities (MMEs), serving gateways (SGWs), packet gateways (PGWs), policy and charging rules functions (PCRFs), home location registers (HLRs), online charging systems (OCSs), and offline charging systems (OFCSs). Moreover, M2M functions, such as energy/power meter reporting and vending machine charging can have different charging parameters. In such arrangements, users of the associated M2M devices do not pay money directly to operators, but rather the energy companies or vending companies that provide the M2M devices to users pay, for example based on overall usage, and/or for the bandwidth wholesale. Some operators are treating these M2M networks as according to the enterprise networks model, and the associated operations support system (OSS) costs can be substantial. M2M operators may not be able to pay the same rates as enterprise customers.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of various embodiments of the disclosed subject matter, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:

FIG. 1 is a flow diagram illustrating a subscriber call flow.

FIG. 2 is a flow diagram illustrating a user equipment (UE) initiated call flow.

FIG. 3 is a flow diagram illustrating a network (NW) initiated call flow.

FIG. 4 is a block diagram illustrating a Diameter credit-control application (DCCA) session, in accordance with some embodiments of the disclosed subject matter.

FIG. 5 is a block diagram illustrating a group DCCA session, in accordance with some embodiments of the disclosed subject matter.

FIG. 6 is a flow diagram illustrating an initial subscriber call flow, in accordance with some embodiments of the disclosed subject matter.

FIG. 7 is a flow diagram illustrating a subscriber termination call flow, in accordance with some embodiments of the disclosed subject matter.

FIG. 8 is a flow diagram illustrating an update call flow, in accordance with some embodiments of the disclosed subject matter.

FIG. 9 is a flow diagram illustrating an initial subscriber call flow, in accordance with some embodiments of the disclosed subject matter.

DETAILED DESCRIPTION

Some embodiments described herein relate to freeing up capacity in Evolved Packet Core (EPC) and other similar networks, so as to better accommodate M2M-type devices. For example, the number of OCS server sessions needed to service a given volume of network elements can be reduced using methods and systems described herein, such that an operator can use the EPC resources more efficiently. Other embodiments relate to online charging of grouped M2M devices, as opposed to individual devices.

Radio Access Network (RAN) Optimizations in Core Networks

In the context of Evolved Packet Core (EPC) networks, certain types of M2M devices do not necessarily need to be kept continuously online. Nevertheless, existing 4G LTE network architectures keep all subscriber sessions as “always on.” As such, all associated network elements (e.g., mobility management entities (MMEs), home subscriber servers (HSS), serving gateways (SGWs), packet gateways (PGWs), policy and charging rules functions (PCRFs), online charging systems (OCSs), and offline charging systems (OFCSs)) are continuously operating in order to maintain the subscriber sessions. As the number of subscribers/M2M devices increases, the corresponding need for such network elements increases linearly. Maintaining a billion sessions at network elements MME, HSS, SGW, PGW, PCRF, OCS, OFCS can involve extensive infrastructure and extremely high operator costs. Virtualization of certain elements can help in reducing the costs, but still may not be economically feasible or justified.

Certain types of M2M devices do not need to remain continuously online. However, current LTE architectures do not allow network elements to release sessions on the network element (NE) side, and even if sessions are released, the user equipment (UE) would immediately come back. Moreover, if a UE releases its session, the network may not be able to reach the UE to reconnect.

Methods of improving NE resource utilization described herein include releasing NE session resources being consumed by an M2M device/UE while maintaining the user equipment (UE) session. While a session remains open, all the network elements MME, HSS, SGW, PGW, PCRF, OCS, OFCS need to maintain the subscriber sessions. In some embodiments, connectivity is maintained for these devices despite releasing the session resources by 1) maintaining the session between the UE and the network (i.e., the UE thinks that it is connected to the network), and storing session information in the PGW (or in any other node that is in communication with the PGW, such as the cloud) in a compressed or truncated fashion. For example, in some embodiments, a subset of session information can be stored. If, for example, the network later attempts to contact the UE (e.g. to send a data packet), the stored session information can be used to establish session resources that were previously released. In some embodiments, the session information can be stored in the PGW (or other node) in a compressed or truncated format without releasing session resources at some or all of the other network elements.

Techniques described herein can be applied to different network element levels, for example:

• • PGW only (+external nodes resources such as PCRF, OCS, etc.)
  • PGW and SGW (+external nodes resources)
  • SGW, MME and PGW (+external nodes resources)

Techniques described herein can be implemented with different timeout periods (e.g., 6 hours, 24-28 hours, on the order of days or weeks, etc.), for example depending upon the M2M device type. Closing the session can be initiated, for example, based on Device User Group “DUG” (e.g., when all members in the DUG have been inactive for more than a predetermined period of time) or based on information from authentication, authorization and accounting (“AAA”) servers (e.g., specifying a predetermined session duration).

In some embodiments, a session database is created and/or maintained on a PGW (or on any other node that is in communication with the PGW, such as the cloud) that can serve as a transaction-oriented system. For example, some or all sessions can be placed in the session database. Subsequently, whenever a session needs to be served, it could be assigned to a gateway (“GW”), or to a workflow (“WF”) which can specify one or more gateway functions from a control plane perspective, based on the load on each GW. After a certain idle period of each session, the session can be purged from the GW but stored in the session database and, optionally, compressed or truncated. In some embodiments, when a network packet is received, the PGW would look in DB and initiate close on the session.

In some implementations, PageBlock Info IE is added to GTPv2 Control Signal in the create session request (CSR), (MBR). For example, an MIME sends PageBlock Info IE with page details of the UE. A new cause code (e.g., NW_REL_ONLY) is added to the release cause codes set so that the MME does not notify the UE about the session release, but releases local resources. In other words, unlike in traditional systems, the MIME no longer retains information, such as the PageBlock Info IE, about the UE. Alternatively, or in addition, a network node element can be added, on which data released from the MME and/or the PGW can be stored. The PGW can release UE session resources while maintaining a compressed or truncated copy of session information. In some embodiments, the PGW can maintain the following information: UE IP Address, Page Information, and MME/SGW Information.

Turning now to the figures, FIG. 1 shows a subscriber call flow 100, according to some embodiments. As shown, a subscriber's UE 102 sends an “attach” request to mobility management entity (MME) 104, which generates a create session request (CSR) (including PageInfo data) and sends it to serving gateway (SGW) 106. SGW 106 forwards the CSR message to a PGW 108 which, in response, generates and sends a CCR-I message to the OCS server 110 to initiate a session. The OCS server 110 sends a CCA-I message back to PGW 108, establishing the session. The PGW 108 generates and sends a create session response (CS Resp) to SGW 106, which forwards the CS Resp to MME 104, which in turn sends an attach response (Attach Resp) to UE 102. Subsequently, PGW 108 decides to release some network resource, and sends a delete bearer request (DBR), specifying cause code network release “cc-NW_REL,” to SGW 106. The PGW 108's decision to release network resources can be based on one or more of: time period over which a particular resource has been in use, network load, a least recently used algorithm, capacity exceeding a predetermined threshold, and identification of one or more resources that has least recently been used. PGW 108 also sends a credit control request terminate (CCR-T) message to OCS server 110, which returns a credit control answer terminate (CCA-T) message to PGW 108. SGW 106 forwards the DBR message to MME 104. MME 104 sends a DBRsp message back to SGW 106 in response, and SGW 106 forwards the DBRsp message to PGW 108. At the end of subscriber call flow 100, the PGW has released UE session resources, but session data pertaining to the UE 102 is compressed and stored at the PGW 108, such that the session does not completely terminate, but is using fewer resources until the session becomes active again. The compressed session data can include one or more of: the UE 102's IP address, page information (e.g., PageBlock), and MME/SGW information. From the point of view of the UE 102, there is no apparent change in the session state.

FIG. 2 shows a UE initiated call flow 200, according to some embodiments. The flow 200 begins with subscriber UE 202 attempting to initiate a call by sending a message to MME 204 including the session ID that is known to the UE. Not detecting an active session (because it no longer stores the UE-related data), the MME 204 sends a “close” message (including the cause code “cc=SessionNotFound”) back to UE 202. Next, UE 202 sends an “attach” message to MME 204, which generates and sends a CSR message (including “PageInfo”) to SGW 206. SGW 206 sends the CSR message (including “PageInfo”) to PGW 208, which generates and sends a CCR-I message to the OCS server 210 to initiate a session. OCS server 210 returns a CCA-I message to PGW 208, which generates and sends a “CS Resp” message to SGW 206, which in turn forwards the CS Resp to MME 204. MME 204 then sends an Attach Resp to UE 202 to confirm that a session has been initiated.

FIG. 3 shows a NW initiated call flow 300, according to some embodiments. Much of the flow described above with reference to FIG. 2 is also present in FIG. 3, however a data packet is first sent from the internet 312 to the PGW 308—where compressed or truncated session data is being stored—and the PGW 308 generates and sends DownLinkData (including PageInfo) to MME 304, which sends a page to UE 302. Call flow 300 is similar to call flow 200, described above. Upon receiving the page, UE 302 attempts to initiate a call by sending a message to MME 304. The MME 302 does not detect an active session and sends a “close message (including the cause code “cc=SessionNotFound”) back to UE 302. Next, UE 302 sends an “attach” message to MME 304, which generates and sends a CSR message (including “PageInfo” to SGW 306. SGW 306 sends the CSR message (including “PageInfo”) to PGW 308, which generates and sends a CCR-I message to OCS server 310 to initiate a session. OCS server 310 returns a CCA-I message to PGW 308, which generates a “CS Resp” message to SGW 306, which in turn forwards the CS Resp to MME 304. MME 304 then sends an Attach Resp to UE 302 to confirm that a session has been initiated. The data packet first sent from the internet 312 to the PGW 308 is then delivered to UE 302 in a typical fashion.

Charging Optimizations for M2M

In existing network charging architectures, a single OCS session corresponds to a single subscriber. However, as M2M devices grow in prevalence, i.e., with the advent of the “internet of things” (JOT), there will be pressure to change the scale of servicing such devices. The 3^rd Generation Partnership Project (3GPP) defines charging guidelines (under TR 23.887) for M2M devices, for example, to generate bulk charging data records (CDRs) for M2M devices belonging to the same group, however only offline charging is supported.

In some embodiments of the present disclosure, M2M devices are grouped together, for example using a common group identifier (ID) or “device user group” (DUG), such that they can be charged to the same (common) M2M operator for purposes of online charging. Such configurations can reduce the number of sessions that a given OCS needs to accommodate at a given time, releasing OCS capacity so that more subscribers can be serviced. For example, supposing that a subscriber requests a data allowance (e.g., 10 MB), an OCS/operator can approve the request and assign the 10 MB to a DUG without needing to know which device(s) or network elements the subscriber is using the data allowance for. This eliminates the one-to-one coupling between user devices and the OCS that charges the associated subscriber(s), and multiple subscribers and/or user devices can charge data via a single OCS session. In other words, a consolidation is implemented at the network element level. As a result, the number of sessions with the OCS server, for servicing a given number of subscribers, is reduced. The OCS also thereby processes data allowance requests in a more aggregated way, rather than based on small transactions/usages.

In some implementations, a group of “same service” M2M devices can be configured locally or via one or more corresponding charging servers. Data/unit grants, usage and reporting levels can thus be performed at the group level rather than at the single-subscriber level.

In some embodiments, an online charging system (OCS) uses a Diameter Credit-Control Application (DCCA) application, such as RFC 4006, 32.299 Gx, Gy, etc., but streamlines the protocol to accommodate a group of M2M devices (associating multiple M2M devices with a single DUG and, optionally, a single associated quota). For example, online charging can be performed using a Credit Control application with the following messages:

Credit Control Request (CCR)

• • INITIAL, UPDATE AND TERMINATE

Credit Control Answer (CCA)

• • INITIAL, UPDATE AND TERMINATE

Re-authorization (RAR)

FIG. 4 is a block diagram illustrating a single DCCA session for facilitating real-time online charging (e.g., performing grants), in accordance with some embodiments of the disclosed subject matter. As shown in FIG. 4, a single DCCA session 414 (e.g., hosted by an OCS server) is, for example, associated with five services identified by service identifiers “A” through “E”; 416A-416E, respectively. Each service is linked to a corresponding quota (418A, 418B and/or 418C) that is, in some cases, shared by multiple services. During the DCCA session, subscribers make data allowance requests, and data units can be granted if there is sufficient quota available to the subscriber. The service identifiers (“Service-Id”s) and the Rating Groups (“1” and “n”; 417A and 417B, respectively) are used to associate the granted unit(s) to a given service or rating group. This configuration provides flexibility to operators so that they can build/structure different services differently, since one or more different quotas can be assigned for each service that an operator has. For example, when a resource such as call time is cheap, the quota associated with that resource can be higher. In other words, resource allocations (e.g., energy units, data units, etc.) can be “cheaper” or “more expensive” (e.g., as indicated by an associated rating group) at different time periods within the same session. Quotas and/or rating groups can be based at least in part on the aggregation of a large plurality of devices (e.g., electric meters, cell phones, computing devices, etc.).

FIG. 5 is a block diagram illustrating a “group DCCA session” 520, in accordance with some embodiments of the disclosed subject matter. The group DCCA session 520 can correspond to a single subscriber (e.g. a water company) or a group of devices in a DUG (e.g. a plurality of water meters). A time series of subservient sessions (sessions “1” through “n”; 514A through 514B, respectively) can interact with the group DCCA session 520 in order to service online charging requests originating from individual subscribers or devices in a DUG. Each subservient session 514A-514B then operates as described above with reference to FIG. 4. In other words, session 1 (514A) and session n (514B) are, for example, each associated with five services identified by service identifiers “A” through “E”; 516A-516E, respectively. Each service is linked to a corresponding quota (518A, 518B and/or 518C) that is, in some cases, shared by multiple services. During each of sessions 1 through n, subscribers make data allowance requests, and data units can be granted if there is sufficient quota available to the subscriber. As above, the service identifiers (“Service-Id”s) and the Rating Groups (“1” and “n”; 517A and 517B, respectively) are used to associate the granted unit(s) to a given service or rating group.

Modifications to DCCA AVPs

In some embodiments, a Subscription-Id-Type Attribute-Value Pair (AVP) is used to identify a user's subscription. A new Subscription Identifier type “END_USER_GROUP” can be defined to identify what group a particular M2M device belongs to. This information could be received, for example, from an M2M UE Device or home subscriber server (HSS) via a GTP-C V2 message. Another subscription identifier type “END_USER_IMEI” can be added to send an International Mobile Station Equipment Identity (IMEI) as part of Subscription-Id value. A Device-User-Group Name AVP can be added to Diameter (or any other suitable protocol that can be used for credit control applications) to represent the DUG.

In some embodiments, Used-Service-Unit AVPs can be used to carry each M2M device's specific information along with usage data. An embodiment of a Used-Service-Unit AVP according to the invention is as follows (see the parameters in bold):

Used-Service-Unit ::= < AVP Header: 446 >
[ Tariff-Change-Usage ]
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ subscription-Id ]
[ ULI ] (user location information)
[ UE-IP-Address]
[ IMEISV] (international mobile station equipment identity
software version)
[ RATType] (radio access technology type, e.g., LTE, 3G)
[ Serving-Network] (network by which the UE came to the
PGW)
*[ AVP ]

Modifications to GTP-C V2 Messages

In some embodiments, a new identifier is added to a General Packet Radio Service (GRPS) Tunneling Protocol (GTP-C) message to identify a M2M Device Group User. The new identifier can be UTF8-encoded and be a string-type variable. The new identifier can be used to define a group of same-type M2M Devices (i.e., that are supported by a single user) under a single access point name (APN), thereby supporting (i.e., facilitating charging, PCRF policy setting, etc.) multiple M2M Device User Group members in a single APN. A home subscriber server (HSS) or UE device can send this new information/attribute. If an HSS sends the information, it can override UE-passed information. The corresponding mobility management entity (MME) could then send the information to a SGW, and the SGW could send the information to PGW. In some implementations, the information is sent as part of an initial bearer setup message, for example a Create Session Request message, which cannot be modified once the bearer is setup. If the HSS modifies it, the bearer would be terminated and re-created with new attribute value.

An example of the Device Group Identifier Attribute is as follows:

	Bits
Octets	8	7	6	5	4	3	2	1
1	Type = 221
2 to 3	Length = n
4	Spare	Instance
5 to (n + 4)	These octet(s) is/are present only if explicitly specified

The Device Group Identifier can come in one of several ways. For example, the UE may itself contain the Device Group Identifier (e.g., in memory) and send it. Alternatively or in addition, the HSS can obtain the Device Group Identifier while performing authentication of a UE and send it to a SGW/PGW using GTP V2/V1 control protocol. Alternatively or in addition, the Device Group Identifier can be received from any external authentication, authorization and accounting (AAA) servers, for example using 29.061 Radius/Diameter protocols.

A virtual EPC implementation (e.g., such as Affirmed Network's gateway MCC) can use the Device Group Identifier as a subscriber analyzer key. A number of devices in a group can be defined, for example, based on a local configuration on each interface type (e.g., PCRF interface, AAA interface, OCS interface, credit control interface, offline charging interface), or a PCRF/AAA/OCS server can determine the number of devices in each group.

In some embodiments, multiple Diameter sessions can exist for each device user group, but individual devices can be present in only one of the Diameter session groups. A particular IMEI can only belong to a single DUG, however the DUG can be associated with multiple sessions concurrently.

FIG. 6 is a flow diagram illustrating an initial subscriber call flow 600, according to some embodiments. An MME 604 sends a create session request (CSR) for international mobile subscriber identity (“IMSI”) of “IMSI1” and a designated user group (DUG) “TED” to SGW 606, which passes the CSR to PGW 608, which checks for the “TED” user group. In the scenario shown in FIG. 6, there is no existing OCS session at the time that the PGW receives the CSR, so the PGW sends a credit control request initiate (“CCR-I”) message for DUG “TED” to the OCS server 610, requesting a session to be initiated. The OCS server sends back a credit control answer (CCA-I), specifying granted service units (“GSU”=100 MB) and a validity time (“VT”=300 seconds). A create session response (“CS Resp”) is sent from PGW 608 to SGW 606, which passes it to the MME 604. Later, the MME 604 sends a second CSR, this time for IMSI2, who also belongs to DUG “TED,” to the SGW 606, which again sends a CSR to PGW 608. PGW 608 again checks for the “TED” user group, and this time detects that there is already an existing OCS session. As such, the PGW 608 does not need to send another CCR-I request to the OCS. Rather, the PGW 608 uses data units already previously granted to “TED” during the existing session, and generates a CS Resp (which it sends to SGW 606) on that basis. The SGW 606 then passes the CS Resp to MME 604 for IMSI2.

FIG. 7 is a flow diagram illustrating a subscriber termination call flow 700, according to some embodiments. An MME 704 sends a delete session request for IMSI1 to the SGW 706, which in response sends a delete session request to PGW 708. The PGW 708 checks to see whether IMSI1 is the last subscriber in the TED group grant discussed above with reference to FIG. 6. If PGW 708 determines that IMSI1 is not the last TED subscriber, then the PGW 708 declines to terminate the online charging (e.g., Diameter) session, and communicates that denial via a “delete session response” message to SGW 706, who forwards it to MME 704. Lower in the flow diagram, MME 704 sends another delete session request for IMSI2. This time, the PGW 708 determines that IMSI1 is the last TED subscriber, and sends a CCR-T terminate request to OCS 710, specifying used service units (“USU”) for IMSI1 and IMSI2 (both members of DUG “TED”). As shown in FIG. 7, IMSI1 used 100,000 USUs and IMSI2 used 35,000 USUs. The OCS server 710 sends a credit control answer (CCA-T) terminate acknowledgment to PGW 708. PGW 708 then generates a delete session response, which it passes to SGW 706, who forwards it to MME 704.

FIG. 8 is a flow diagram illustrating an update call flow 800, according to some embodiments. At 822, eNodeB sends a bearer data packet for IMSI1 to SGW 806, which generates a packet and sends it to PGW 808. The PGW 808 then updates its local memory to reflect IMSI1's (of user group “TED”) session usage against the TED data grant. PGW 808 then sends a CCR-I message for DUG=TED to the OCS server 810. The OCS server 810 replies with a CCA-I, granting 100 MB of GSUs. Subsequently, eNodeB 822 sends a bearer data packet for IMSI2 to SGW 806, which generates another packet and sends it to PGW 808. The PGW 808 then updates its local memory to reflect IMSI2's (of user group “TED”) session usage against the TED data grant. At this point in FIG. 8, the PGW 808 determined that the combined usage of IMSI1 and IMSI2 now exceeds the granted service units (GSU) for the user group TED. As such, PGW 808 then sends a CCR-U message for DUG=TED to the OCS server 810, specifying “USU1—100K, IMSI1” and “USU2—300K, IMSI1.” The OCS server 810 replies with a CCA-A, granting another 100 MB of GSUs. The PGW 808 then updates a traffic detection function (“TDF”) and/or a policy and charging enforcement function (“PCEF”) with 100 MB of GSUs for the TED device user group.

Gx Interface Optimizations

In some embodiments, instead of obtaining subscriber policies for each subscriber, a Policy Control and Charging Function (PCEF) can determine whether a group policy has already been received from the Policy Control and Charging Rules Function (PCRF). Based on the M2M device group user name and associated APN, the PCEF could send a request for subscriber policy data to the PCRF. Once subscriber policy data is available for a given M2M device group user, it (e.g., the PGW) could cache this policy data. In some embodiments, another M2M device with the same DUG and APN could check first locally to determine whether policy data has already been fetched. If so, it would use them. PCRF or local configuration data can be used to determine the number of subscribers in a given user group. The PCRF also can set a validity timer (e.g., a predetermined time interval after which the PCRF performs a check for updates) to force a re-evaluation of these subscriber rules. The PCRF can still use a reauthorization (RAR) message to re-authenticate based on the user groups whenever there is a change in the operator configuration of these device groups.

FIG. 9 is a flow diagram illustrating another initial subscriber call flow 900, according to some embodiments. The flow begins with MME 904 sending a CSR for IMSI1 of user group “TED” to the SGW 906, as previously described. The SGW 906 sends a CSR to PGW 908, which checks for the TED user group, and also determines that there is currently no existing PCRF session. As such, the PGW 908 initiates a PCRF session (e.g., so that it can obtain subscriber policy data) by sending a CCR-I for user group TED to PCRF 924. PCRF 924 returns a CCA-I message, including subscriber policy data and default quality of service (QoS) data, to PGW 908. The PGW 908 then generates a CS Resp message, which it sends to SGW 906, which in turn sends it to MME 904. Subsequently, MME 904 sends a CSR for IMSI2 of user group “TED” to SGW 906, which sends a CSR to PGW 908, which checks for the TED user group, and also this time determines that there is currently an existing PCRF session. As such, the PGW 908 applies the policies that are assigned to the TED group, which it has already obtained from the previous CCA-I message received from the PCRF 924 earlier in the session. Accordingly, the PGW 908 does not need to communicate with the PCRF 924 at this stage. The PGW 908 again generates a CS Resp message, which it sends to SGW 906, which in turn sends it to MME 904. In some implementations, the flow 900 of FIG. 9 can include a PCRF termination process similar to the OCS session termination process described above with reference to FIG. 7. For example, if a user IMSI1 commences a session, the PCRF responds, IMSI1 later drops off and no other users join the session, the PCRF can terminate the session. In some embodiments, re-validation of a subscriber policy can be performed (e.g., by the PGW 908 sending a CCR-I message to the PCRF 924) according to a predetermined schedule. Alternatively, or in addition, the PCRF can “push” updates to the PGW 908 (e.g., CCA-I via RAR, no need to terminate) in response to a change that is detected at the server level (i.e., a change in subscriber policy). In some such cases, the PCRF 924 only pushes changes to the subscriber policy to the PGW 908 if there is a session in progress at the time the update/change is detected by the PCRF 924.

The techniques and systems disclosed herein may be implemented as a computer program product for use with a network, computer system or computerized electronic device. Such implementations may include a series of computer instructions, or logic, fixed either on a tangible medium, such as a computer readable medium (e.g., a diskette, CD-ROM, ROM, flash memory or other memory or fixed disk) or transmittable to a network, computer system or a device, via a modem or other interface device, such as a communications adapter connected to a network over a medium.

The medium may be either a tangible medium (e.g., optical or analog communications lines) or a medium implemented with wireless techniques (e.g., Wi-Fi, cellular, microwave, infrared or other transmission techniques). The series of computer instructions embodies at least part of the functionality described herein with respect to the system. Those skilled in the art should appreciate that such computer instructions can be written in a number of programming languages for use with many computer architectures or operating systems.

Furthermore, such instructions may be stored in any tangible memory device, such as semiconductor, magnetic, optical or other memory devices, and may be transmitted using any communications technology, such as optical, infrared, microwave, or other transmission technologies.

It is expected that such a computer program product may be distributed as a removable medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the network (e.g., the Internet or World Wide Web). Of course, some embodiments of the invention may be implemented as a combination of both software (e.g., a computer program product) and hardware. Still other embodiments of the invention are implemented as entirely hardware, or entirely software (e.g., a computer program product).

In the foregoing description, certain steps or processes can be performed on particular servers or as part of a particular engine. These descriptions are merely illustrative, as the specific steps can be performed on various hardware devices, including, but not limited to, server systems and/or mobile devices. Similarly, the division of where the particular steps are performed can vary, it being understood that no division or a different division is within the scope of the invention. Moreover, the use of “module” and/or other terms used to describe computer system processing is intended to be interchangeable and to represent logic or circuitry in which the functionality can be executed.

Claims

1. A method for granting data resources to one or more subscribers belonging to a group in a communications network comprising:

receiving a request to create an online charging session, wherein the request identifies a designated user group (“DUG”), which is associated with one or more subscribers;

determining whether the DUG is associated with an existing online charging session; if no existing online charging session is associated with the DUG, sending a message, which identifies the DUG, to an online charging node to request a new online charging session and receiving from the online charging node policy data that is assigned to the DUG; if an existing online charging session is associated with the DUG, retrieving policy data previously assigned to the DUG; and

granting data resources to the one or more subscribers based on the policy data wherein the data resources are shared by the one or more subscribers.

2. The method of claim 1, wherein the policy data comprises one or more quotas, each quota associated with one or more services or rating groups.

3. The method of claim 1, wherein the online charging node is an Online Charging System (“OCS”) server or a Policy Control and Charging Rules function (“PCRF”) server.

4. The method of claim 1, further comprising caching the policy data.

5. The method of claim 4, further comprising checking for updates to the policy data based on a predetermined time interval.

6. The method of claim 1, further comprising deleting the online charging session only if a request to delete the session is associated with a last subscriber associated with the DUG.

7. A non-transitory computer readable medium for granting data resources to one or more subscribers belonging to a group in a communications network comprising a network node configured to:

receive a request to create an online charging session, wherein the request identifies a designated user group (“DUG”), which is associated with one or more subscribers;

determine whether the DUG is associated with an existing online charging session; if no existing online charging session is associated with the DUG, sending a message, which identifies the DUG, to an online charging node to request a new online charging session and receiving from the online charging node policy data that is assigned to the DUG; if an existing online charging session is associated with the DUG, retrieving policy data previously assigned to the DUG; and

grant data resources to the one or more subscribers based on the policy data, wherein the data resources are shared by the one or more subscribers.

8. The non-transitory computer readable medium of claim 7, wherein the policy data comprises one or more quotas, each quota associated with one or more services or rating groups.

9. The non-transitory computer readable medium of claim 7, wherein the online charging node is an Online Charging System (“OCS”) server or a Policy Control and Charging Rules function (“PCRF”) server.

10. The non-transitory computer readable medium of claim 7, wherein the network node is further configured to cache the policy data.

11. The non-transitory computer readable medium of claim 10, wherein the network node is further configured to check for updates to the policy data based on a predetermined time interval.

12. The non-transitory computer readable medium of claim 7, wherein the network node is further configured to delete the online charging session only if a request to delete the session is associated with a last subscriber associated with the DUG.