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 for conserving network resources comprises releasing network resources related to a User Equipment (“UE”) session at one or more network nodes without notifying the UE. A subset of the session information that can be used to connect with the UE is stored at a network node. If data is received for the UE, the stored subset of information can be used to 1) establish network resources related to the UE that were previously released and 2) deliver the data to the UE. In another embodiment, shared data resources are granted to one or more subscribers associated with a Designated User Group (“DUG”). An online charging session is assigned to the DUG that identifies policy data for granting shared data resources to the Designated User Group.

Description

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 arc 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 art 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 he 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 arid 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 MME 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 MME 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, 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 front 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 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 than 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” (IOT), 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 winch 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 pertonned 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 he added to Diameter (or 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, LTE, 3G)
    • [Serving-Network] (network by which the UE come 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 horn 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 cheeks 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 ('SR 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 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 Lite 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 m 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-IJ 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 A PN, the PCEF could send a request for subscriber policy data to the PCRF. Once subscriber policy data is available fib 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 DUO and APN could chock 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 liar 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 923 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 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. (canceled)

2. A method for terminating an online charging session that is allocated to a device user group (DUG), the method being implemented by a first network node, the method comprising: receiving a first delete session request message from a second network node, wherein the first delete session request message comprises a first request to delete the online charging session, and wherein the first delete session request message further comprises a first subscriber identifier corresponding to a first subscriber that belongs to the DUG;determining that there is at least one additional subscriber besides the first subscriber in the DUG when the first delete session request message is received;sending a first delete session response message to the second network node in response to the first delete session request message, wherein the first delete session response message declines to terminate the online charging session;receiving a second delete session request message from the second network node, wherein the second delete session request message comprises a second request to delete the online charging session, and wherein the second delete session request message further comprises a second subscriber identifier corresponding to a second subscriber that belongs to the DUG;determining that the second subscriber is the last subscriber in the DUG when the second delete session request message is received; andsending a terminate request message to an online charging node in response to determining that the second subscriber is the last subscriber in the DUG when the second delete session request message is received.

3. The method of claim 2, wherein the terminate request message comprises an indication of used service units for members of the DUG.

4. The method of claim 2, wherein: the first network node comprises a packet gateway (PGW);the second network node comprises a serving gateway (SGW); andthe online charging node comprises an online charging system (OCS) server.

5. The method of claim 2, further comprising sending a second delete session response message to the second network node in response to the second delete session request message, wherein the second delete session response message indicates that the online charging session is terminated.

6. A system for tracking resource usage of a device user group (DUG), the system comprising: one or more processors;memory communicatively coupled to the one or more processors; andinstructions stored in the memory, the instructions being executable by the one or more processors to: receive a first data packet corresponding to a first subscriber that belongs to the DUG;send a first request message that identifies the DUG to an online charging node, the first request message initiating an online charging session;receive a first answer in response to the first request message, the first answer being received from the online charging node, the first answer comprising a first resource grant for the DUG;receive a second data packet corresponding to a second subscriber that belongs to the DUG;determine that a combined usage of the first subscriber and the second subscriber exceeds the first resource grant for the DUG;send a second request message that identifies the DUG to the online charging node, the second request message requesting an additional resource grant for the DUG; andreceive a second answer in response to the second request message, the second answer being received from the online charging node, the second answer comprising a second resource grant for the DUG.

7. The system of claim 6, wherein the second request message comprises: a first indication of a first session usage corresponding to the first subscriber; anda second indication of a second session usage corresponding to the second subscriber.

8. The system of claim 6, further comprising additional instructions stored in the memory, the additional instructions being executable by the one or more processors to update at least one of a traffic detection function or a policy and charging enforcement function based at least in part on the second resource grant.

9. The system of claim 6, wherein the online charging node comprises an online charging system (OCS) server.

10. The system of claim 6, wherein the first data packet and the second data packet are received at a packet gateway (PGW) from a serving gateway (SGW).

11. The system of claim 6, wherein: the first request message comprises a first credit control request initialization (CCR-I) message;the second request message comprises a second CCR-I message;the first answer comprises a first credit control answer initialization (CCA-I) message; andthe second answer comprises a second CCA-I message.

12. The system of claim 6, further comprising additional instructions stored in the memory, the additional instructions being executable by the one or more processors to: update a local memory in response to receiving the first data packet, the local memory being updated to reflect a first session usage corresponding to the first subscriber; andupdate the local memory in response to receiving the second data packet, the local memory being updated to reflect a second session usage corresponding to the second subscriber.

13. A computer-readable medium comprising instructions that are executable by one or more processors to cause a computing system to: receive a first create session request message identifying a first subscriber that belongs to a device user group (DUG);determine that no existing online charging session is associated with the DUG when the first create session request message is received;send a request message that identifies the DUG to an online charging node, the request message initiating an online charging session;receive an answer in response to the request message, the answer being received from the online charging node, the answer comprising policy information associated with the DUG;apply the policy information to the first subscriber;receive a second create session request message identifying a second subscriber that belongs to the DUG;determine that the online charging session associated with the DUG is still active when the second create session request message is received; andapply the policy information that was previously received from the online charging node to the second subscriber.

14. The computer-readable medium of claim 13, wherein in response to determining that the online charging session associated with the DUG is still active when the second create session request message is received, a first network node applies the policy information that was previously received from the online charging node to the second subscriber without communicating with the online charging node.

15. The computer-readable medium of claim 14, wherein the policy information comprises one or more quotas, and wherein each quota is associated with one or more services or rating groups.

16. The computer-readable medium of claim 14, wherein the policy information comprises subscriber policy data and default quality of service (QoS) data.

17. The computer-readable medium of claim 13, further comprising additional instructions that are executable by the one or more processors to cause the computing system to periodically check for updates to the policy information at predetermined time intervals.

18. The computer-readable medium of claim 13, wherein the online charging node comprises a policy and charging rules function (PCRF).

19. The computer-readable medium of claim 13, wherein the first create session request message and the second create session request message are received from a second network node, and further comprising additional instructions that are executable by the one or more processors to cause the computing system to: send a first create session response message to the second network node in response to the first create session request message; andsend a second create session response message to the second network node in response to the second create session request message.

20. The computer-readable medium of claim 13, wherein: the first create session request message and the second create session request message are received from a serving gateway (SGW) at a packet gateway (PGW); andthe online charging node comprises a policy and charging rules function (PCRF).

21. The computer-readable medium of claim 13, wherein: the request message comprises a credit control request initialization (CCR-I) message; andthe answer comprises a credit control answer initialization (CCA-I) message.