CN109417683B

CN109417683B - Core network online charging control for intermediate network traffic steering

Info

Publication number: CN109417683B
Application number: CN201680086638.9A
Authority: CN
Inventors: 乌韦·格莱宁; 迈克尔·荣格; 詹森·申德尔
Original assignee: Redknee Inc
Current assignee: Redknee Inc
Priority date: 2016-06-09
Filing date: 2016-06-09
Publication date: 2021-07-30
Anticipated expiration: 2036-06-09
Also published as: EP3469819A1; CN109417683A; WO2017212318A1

Abstract

A charging server in the core network stores a user record containing a user identifier of the mobile device. The billing server receives a core session request from a gateway server indicating that the mobile device is attempting to communicate with a network, e.g., a Wide Area Network (WAN). The request includes a user identifier of the mobile device and a currently assigned network identifier. The charging server updates the corresponding user record with the association between the user and the network identifier. The billing server also receives a diversion session request including a network identifier from a traffic diversion server in the intermediate network; the traffic steering server sends a steering session request upon receiving the network identifier from the core network policy server. Using the network identifier and stored association in the diverted session request, the billing server retrieves the correct user record and selects either to accept or reject the establishment of the diverted data session based on the contents of the retrieved user record.

Description

Core network online charging control for intermediate network traffic steering

Technical Field

The application relates to traffic steering in an intermediate network, and in particular to online charging control from traffic steering within a core network.

Background

In conventional mobile networks, traffic steering services may be provided by network operators located on steering networks between a core mobile network and a wide area network such as the internet. Such diversion services are typically managed by a traffic diversion support function (TSSF). The TSSF is indicated (e.g., by a policy element in the core network) as to how to route the client data through the steered network. The client device identification is typically based on a (temporary) IP address in the steered network. Instead, the core mobile network uses a user identifier, such as a telephone number, to identify the client device. The use of different identifiers in the core and steering networks, combined with the nature of the contractual connection between the TSSF and the above elements, makes charging control (imposed by the core network) of traffic steering activities difficult or impossible.

Disclosure of Invention

A charging server in the core network stores a user record containing a user identifier of the mobile device. The billing server receives a core session request from the gateway server indicating that the mobile device is attempting to communicate with, for example, a Wide Area Network (WAN). The request includes a user identifier of the mobile device and a currently assigned network identifier. The charging server updates the corresponding user record with the association between the user and the network identifier. The billing server also receives a diversion session request including a network identifier from a traffic diversion server in the intermediate network; the traffic steering server sends a steering session request upon receiving a network identifier from the core network policy server. Using the network identifier and stored association in the diverted session request, the billing server retrieves the correct user record and either accepts or rejects establishment of the diverted data session based on the contents of the retrieved user record.

Drawings

Embodiments are described with reference to the following drawings, in which:

FIG. 1 depicts a communication system according to a non-limiting embodiment;

FIG. 2 depicts certain internal components of the billing and traffic steering server of the system of FIG. 1, according to a non-limiting embodiment.

FIG. 3 depicts a method of initiating charging control in the system of FIG. 1, according to a non-limiting embodiment;

FIG. 4 depicts a method of charging control in the system of FIG. 1, in accordance with a non-limiting embodiment; and

fig. 5 depicts a method of terminating charging control in the system of fig. 1, according to a non-limiting embodiment.

Detailed Description

Fig. 1 depicts a communication system 100. The system 100 includes a mobile device 104, which may be any of a variety of mobile computing devices, including smart phones, cell phones, laptops, and the like. Accordingly, mobile device 104 includes hardware elements including a processing unit, volatile and non-volatile memory, a network interface, input devices, and output devices (e.g., any suitable combination of a display, speaker, microphone, touch screen, etc.). The processing unit of mobile device 104 performs various functions by executing programmed instructions stored in memory (e.g., the non-volatile memory described above), including initiating data communications over various networks. Multiple mobile devices may be included in the system 100, but only the mobile device 104 is shown for illustration purposes.

The mobile device 104 is connected to a core mobile network 108. The core mobile network 108 (also referred to herein as network 108) may be based on any suitable standard or combination of standards. In this example, the network 108 is an Evolved Packet Core (EPC) network constructed in accordance with the Long Term Evolution (LTE) standard set by the third generation partnership project (3 GPP). However, in other examples, the network 108 may be constructed in accordance with various other standards, such as the third generation (3G) standard. Thus, the nature of the connection between the mobile device 104 and the core mobile network 108 is variable and is selected according to the implementation of the core mobile network 108. In this example, where the core mobile network 108 is an EPC network, a connection with the mobile device 104 may be established through a legacy access network, such as an eNodeB.

Network 108 includes gateway server 112, policy server 116, and billing server 120. In this example, where the core network 108 is an LTE core network, it will be apparent to those of ordinary skill in the art that the gateway server 112 may also be referred to as a packet data network gateway (PDN gateway or P-GW), implementing the Policy and Charging Enforcement Function (PCEF) defined by the 3GPP specifications. Policy server 116 may also be referred to as a Policy and Charging Rules Function (PCRF) defined by the 3GPP specifications. The charging server 120 may also be referred to as an Online Charging System (OCS). Those of ordinary skill in the art will appreciate the various features of the P-GW, PCRF, and OCS from published 3GPP specifications, including 3GPP technical specification 23.203. However, as shown below, the charging server 120 includes certain new features that are different from the OCS defined by the 3GPP specifications.

Other elements of the core mobile network 108, such as a mobility management entity, MME, home subscriber server, HSS, one or more serving gateways, S-GW, traffic detection functions, TDF, etc., may be implemented as conventional and, therefore, are not shown here for simplicity.

In general, the core mobile network 108 allows the mobile device 104 to gain access to other networks, including a Wide Area Network (WAN)124, such as the internet. To access WAN 124, mobile device 104 contacts gateway server 112 (through other network elements such as the MME and S-GW described above). Gateway server 112, in turn, contacts policy server 116 through a communication link, which in this embodiment is based on the known Gx interface (a variant of the Diameter protocol), to obtain policy and charging control rules that apply to communications between mobile device 104 and WAN 124. Policy server 116 generates such rules based on information received from gateway server 112 and information retrieved from Subscriber Profile Repository (SPR) database 128. In some cases, policy server 116 may also receive information for rule generation from an application function (AF, not shown) stored in WAN 124, where mobile device 104 has requested access to the application function.

After generating the above rules, the policy server 116 provides the rules to the gateway server 112 over the Gx interface. The gateway server 112, in turn, enforces those rules during communication between the mobile device 104 and the WAN 124. The rules can specify quality of service (QoS) parameters (e.g., bandwidth and delay), usage limits, billing parameters, etc. to which the mobile device 104 is entitled. During communication between mobile device 104 and WAN 124, gateway server 112 may provide usage data (e.g., the amount of data already carried between mobile device 104 and WAN 124) to policy server 116 over the Gx interface and to billing server 120 over the known Gy interface (another form of Diameter protocol).

Additionally, the policy server 116 may generate (or otherwise update after communication between the mobile device 104 and the WAN 124 has begun) the above-described rules based on information received from the billing server 120. In particular, the billing server 120 maintains a billing database that stores the aforementioned usage data from the gateway server 112. The billing database also stores billing-related information related to the mobile device 104, such as account balance and rating information (e.g., how much the mobile device 104 must pay for certain amounts of data, certain services, etc.). Additionally, the billing server 120 may determine monetary values for the usage data and deduct these values from the account balance associated with the mobile device 104. The billing server 120 may also track usage data, monetary value, or both by updating counters in the billing database. These counters may be provided by the billing server 120 to the policy server 116 for controlling access of the mobile device 104 to the WAN 124. For example, the policy server 116 may be used to change the bandwidth available to the mobile device 104 once the mobile device 104 has exchanged large amounts of data with the WAN 124 that exceed a predetermined monetary cost. The exchange of counters between the charging server 120 and the policy server 116 may be done over the known Sy interface (as defined by 3GPP TS 29.219).

Thus, the network 108 allows mobile device 104 access to WAN 124, and such access is regulated by gateway server 112 based on control information generated by policy server 116. The account associated with the mobile device 104 maintained at the billing server 120 is in a debit state during access, and the state of the account may also be employed to control access.

In this embodiment, communications between the mobile device 104 and the WAN 124 are not only routed through the core network 108 (and in particular the gateway server 112), but may also pass through an intermediate network 132, which may also be referred to as an (S) Gi-LAN, for interconnecting the gateway server 112 and the (S) Gi interface of the network 132 (see 3GPP TS 29.061). The network 132 contains one or more network elements, referred to as Steering Functions (SFs), through which communications between the mobile device 104 and the WAN 124 may be routed. In the present embodiment, three steering functions 136-1, 136-2, and 136-3 (collectively referred to as steering functions 136 and generally referred to as steering functions 136) are shown.

The nature of the steering function is not particularly limited: the steering function may perform video optimization algorithms (e.g., compressing video data communicated from the WAN 124 to the mobile device 104), anti-malware algorithms, monitoring management functions, firewall and network address translation functions, and the like. As will now be apparent to those of ordinary skill in the art, the nature of the communication between the mobile device 104 and the WAN 124 may determine which of the steering functions are appropriate for use. For example, if the data exchanged between the mobile device 104 and the WAN 124 does not include video data, there is no reason to spend the computational resources of the video optimization diversion function to process the data.

Thus, the network 132 includes a traffic steering server 140, also referred to as a Traffic Steering Support Function (TSSF), for controlling the steering function 136 used to transmit any given data stream to the mobile device 104 or to transmit data streams from the mobile device 104. For example, the path 144 shown in fig. 1 illustrates that data destined for the mobile device 104 is first transferred through the steering function 136-1 and then through the steering function 136-2 (rather than through the steering function 136-3) before being routed to the core network 108 through the traffic steering server 140.

Certain functions of the traffic steering server 140 will occur to those skilled in the art, as they are defined in the 3GPP specifications. In particular, the traffic steering server 140 maintains steering policies that define various series of service functions. The policy server 116 is used to instruct the traffic steering server 140, via the known St interface, to implement a certain steering policy (or policies) for the mobile device 104 at any given time. The traffic steering server 140 is then configured to control the steering functions 136 of the network 132 to route data to the mobile device 104 (or originating from the mobile device 104) through a specified series of steering functions 136.

Similar to the billing server 120, the traffic steering server 140 also implements functions not expected in the 3GPP specifications. In particular, the traffic steering server 140 and the billing server 120 are configured to communicate directly with each other through a new interface (referred to as "Gyt" in fig. 1), and perform various actions as a result of such communication. Before discussing the actions of the billing server 120 and the traffic steering server 140 in detail, a brief description of certain internal components of the billing server 120 and the traffic steering server 140 will be provided with reference to FIG. 2.

Turning to fig. 2, billing server 120 includes a Central Processing Unit (CPU) 200, also referred to herein as processor 200, interconnected with a memory 204. The processor 200 and memory 204 typically comprise one or more Integrated Circuits (ICs) and may have a variety of configurations as can now be implemented by those of ordinary skill in the art (e.g., more than one CPU may be provided).

Memory 204 may be any suitable combination of volatile (e.g., Random Access Memory (RAM)) and non-volatile (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic computer storage devices, or optical disks) memory. In this example, memory 204 includes volatile and non-volatile storage.

The processor 200 is also interconnected with one or more network interfaces, such as a Network Interface Controller (NIC) 208, which allows the billing server 120 to connect to other computing devices in the

networks

108, 124, and 132. Thus, NIC 208 includes the hardware necessary to communicate over the network described above. Billing server 120 may also include input devices (not shown), such as a keyboard and mouse, interconnected with processor 200, and output devices (not shown), such as a display, interconnected with processor 200. In some embodiments, input and output devices may be connected to processor 200 through NIC 208 and another computing device. In other words, the input and output devices may be local to the billing server 120 or remote.

Memory 204 stores at least two computer-readable programming instructions executable by processor 200 in the form of various applications and also stores various non-executable data used during execution of those applications. As will be appreciated by one of ordinary skill in the art, the processor 200 may execute instructions of one or more such applications in order to perform various operations defined within the instructions. In the following description, the processor 200 or billing server 120 is more generally referred to as "being used for" or "being operated to" perform certain functions. It should be understood that billing server 120 is so configured by processing the instructions of the application program stored in memory 204.

One of the applications stored in the memory 204 is a billing application 212 containing instructions executable by the processor 200 to cause the server 120 to perform various actions described herein relating to authorizing and communications between the billing mobile device 104 and the WAN 124. In addition, as described above, the memory 204 stores the billing database 216. The billing database 216 contains at least two subscriber records, each subscriber record containing a corresponding subscriber identifier, such as a Mobile Station International Subscriber Directory Number (MSISDN), or an International Mobile Subscriber Identity (IMSI) number corresponding to the mobile device. As will now be apparent to those of ordinary skill in the art, the above-described user identifiers need not be permanently associated with a given mobile device-telephone numbers may be reassigned to other mobile devices. For purposes of this application, however, it will be assumed for simplicity that the user identifier corresponds to a particular mobile device.

Each user record also includes billing data, such as an account balance and one or more counters, corresponding to the identified mobile device. Various other billing data corresponding to each subscriber identifier may also be stored in the database 216. An example of database 216 is shown in table 1 below.

Table 1: example billing database 216

As shown in table 1, the user record corresponding to the mobile device 104 is contained in the database 216 and includes an account balance and a set of counters. In particular, the first counter represents the amount of data that mobile device 104 "consumes" in the current month, and the second counter represents the amount of data that has been sent to the mobile device (e.g., the current month). The mobile device 104 has been routed through the video optimization steering function 136. Various other counts may also be stored in the records of the database 216. Various other billing data may also be tracked in each user record, such as quotas (e.g., the amount of data reserved for certain applications or services), a list of services or applications that each user identifier may access, rates (per amount of data, or traffic) paid by each user for various services or applications, and so forth.

Each user record also contains a network identifier association ("current network ID"). In the example of table 1, the network identifier association of the mobile device 104 is empty; the general state of the art will be discussed in more detail below.

Referring again to fig. 2, the traffic steering server 140 includes a CPU 250, also referred to herein as a processor 250, interconnected with a memory 254. The processor 250 and memory 254 typically include one or more ICs and may have a variety of configurations as can now be implemented by those of ordinary skill in the art (e.g., more than one CPU may be provided).

The memory 254 may be any suitable combination of volatile (e.g., RAM) and non-volatile (e.g., ROM, EEPROM), flash memory, magnetic computer storage devices, or optical disk (memory) memory. In the present example, the memory 254 includes volatile and non-volatile storage.

The processor 250 is also interconnected with one or more network interfaces, such as a Network Interface Controller (NIC) 258, which allows the traffic steering server 140 to connect to other computing devices in the

networks

108, 124, and 132. Thus, the NIC 258 includes the hardware necessary to communicate over the network described above. The traffic steering server 140 may also include input devices (not shown), such as a keyboard and mouse, interconnected with the processor 250, and output devices (not shown), such as a display, interconnected with the processor 250. In some embodiments, input and output devices may be connected to the processor 250 through the NIC 258 and another computing device. In other words, the input and output devices may be local to the traffic steering server 140 or remote.

Memory 254 stores at least two computer-readable programming instructions executable by processor 250 in the form of various applications and may also store various non-executable data used during execution of those applications. As will be appreciated by one of ordinary skill in the art, the processor 250 may execute instructions of one or more such applications in order to perform various operations defined within the instructions. In the description that follows, the processor 250 or traffic steering server 140 is more generally referred to as being "used for" or "operated to" perform certain functions. It should be appreciated that the traffic steering server 140 is so configured by processing the instructions of the application program stored in the memory 254.

The application stored in the memory 254 is a traffic steering control application 262 containing instructions executable by the processor 250 to cause the server 140 to control network elements of the network 132 to route data traffic (through the core network 108) between the WAN 124 and the mobile device 104. In addition, the memory 254 stores a traffic steering strategy database 266. The steering policy database contains at least two policy records, each policy record containing a policy identifier and a series of intermediate network element identifiers. An example of database 266 is shown in Table 2 below:

table 2: example traffic guidance policy database 216

ID	Steering function chain
		Video	136-1、136-2
Anti-malware	136-1、136-3
		…	…

As shown in Table 2, both example records define a traffic control strategy. The "video" diversion policy routes traffic through diversion functions 136-1 and 136-2, while the "anti-malware" diversion policy routes traffic through diversion functions 136-1 and 136-3. Other steering records may define a steering function chain with more or fewer steering functions 136 (i.e., a steering strategy may include a single steering function 136). The database 216 may contain additional data such as a service identifier for each diversion function 136, and control parameters for each diversion function 136 (e.g., resolution of video optimization, parameters provided by the optimization diversion function to enable or disable the video advertisement blocking function, etc.).

Turning now to fig. 3, a method 300 of billing control initiation for traffic steering is shown. The method 300 will be described in connection with its performance on the system 100, but it will be apparent to one of ordinary skill in the art that the method 300 may also be performed on suitable variations of the system 100.

Beginning in block 305, the billing server 120 is operable to receive a core session request from the gateway server 112. As can now be apparent, prior to receiving the request at block 305, various other conventional events will occur, including sending a request from the mobile device 104 to the gateway server 112 (e.g., requesting access to a particular resource in the WAN 124). Additionally, the gateway server 112 may establish communication with the policy server 116 to receive the rules described above prior to contacting the billing server 120. Further, the policy server 116 may establish communication with the billing server 120 (e.g., through the Sy interface) to obtain billing data for generating rules for deployment to the gateway server 112.

The contents of the request received at block 305 will be apparent to one of ordinary skill in the art. For purposes of this application, it will be noted that the request includes a user identifier, such as an MSISDN, IMSI, etc., and a network identifier (e.g., IP address; often referred to as a PDP address in the context of a Gy session), which is typically assigned to the mobile device 104 temporarily (i.e., the duration of the requested access to the WAN 124) by: elements of the core network 108 or an access network connecting the mobile device 104 to the core network 108.

Having received the request from the gateway server 112 at block 310, the billing server 120 operates to establish a core data session with the gateway server 112 (e.g., via a Gy interface), or alternatively, to deny establishment of such a session, for example, if the balance of the account associated with the mobile device 104 in the billing database 216 is insufficient to support the requested access to the WAN 124. In the current example performance of the method 300, it will be assumed that the Gx session was successfully established. In addition, at block 310, billing server 120 is operable to update billing database 216, wherein at block 305 an association exists between the user identifier and the network identifier received in the request.

In particular, the billing server 120 is operable to select a user record containing the user identifier in the request and update the record to complete the "current network ID" field of the network identifier contained in the request. An example of database 216 after execution of block 310 is shown in table 3 below.

Table 3: example billing database 216

As described above, by storing the network identifier in the user record, an association between the user identifier assigned to the mobile device 104 and the temporary network identifier assigned to the mobile device 104 has been established. The association may be stored by various other mechanisms. For example, rather than updating the user record as shown above, billing server 120 may maintain a separate index of such associations.

At block 315, the traffic steering server 140 is operable to receive a policy session request (e.g., via the St interface) from the policy server 116. The request received at block 315 typically temporarily follows the core data session established between the billing server 120 and the gateway server 112, although this is not mandatory.

The request received at block 315 includes at least a network identifier and a traffic steering strategy identifier. At block 320, the traffic steering server 140 is configured to establish a policy data session with the policy server 116 (e.g., by returning an acknowledgement message to the policy server 116) and retrieve the traffic steering policy record identified in the request from the database 266.

At block 325, the traffic steering server 140 is configured to send a steering session request to the billing server 120, including the network identifier received from the policy server 116, as opposed to conventional traffic steering support functions. The request sent at block 325 is sent over the interface labeled Gyt in fig. 1. Typically, the request sent at block 325 does not include a user identifier corresponding to the mobile device 104 — in fact, the traffic steering server 140 may not be used to identify or store the user identifier. The diversion session request may take the form of a Diameter Credit Control Request (CCR), an HTTP request, or the like.

The request sent by the traffic steering server 140 may include additional data beyond the network identifier currently assigned to the mobile device 104. For example, the request may include an identifier for each divert function in the chain defined by the policy record loaded at block 320. In addition, the request may include operational attributes of the steering functions in the chain (e.g., resolution attributes such as "high definition" or "standard definition" for the video-optimized steering function).

At block 330, the billing server 120 is operable to receive a diversion session request from the traffic diversion server 140. At block 335, the billing server 120 is operable to select one of the user records in the database 216 based on the network identifier included in the request from the traffic steering server 140. In particular, selection of the user record at the billing server 120 is enabled by an association between a network identifier previously stored by the billing server 120 and a relatively permanent user identifier corresponding to the mobile device 104.

Accordingly, at block 335, the billing server 120 is configured to select a user record containing an association between the network identifier and the user identifier received from the traffic steering server 140. In this example, at block 335, the billing server 120 selects the record shown in table 3 that is associated with the user identifier "104 @ acme.com", which contains the current IP address of the mobile device 104.

After the user record is selected, the billing server 120 is then used to generate and send a response to the traffic steering server 140 based on the content of the selected user record. The generation of the response may include various determinations at the billing server 120. For example, the billing server 120 may retrieve the requested rate of the traffic diversion function from the memory 204 and determine whether the selected account balance of the user record is sufficient to support a predefined amount of data for the retrieved rate. As another example, billing server 120 may simply determine whether the account balance is above a predefined monetary threshold (e.g., stored in memory 204). The generation of the response may also include reserving a portion of the account balance and allocating a quota (e.g., in the form of a data volume) for use by the traffic steering function.

More generally, the response generated by the billing server 120 indicates whether the request by the traffic steering server 140 was accepted or rejected, and when the request is accepted, may also include a parameter, such as the quota described above, for use by the traffic steering server 140 in controlling the steering function 136 of the network 132.

At block 345, after receiving the response from the billing server 120, the traffic steering server 140 is operable to control the elements of the network 132 according to the response and the steering policy loaded at block 320. For example, if the response includes a quota indicating a maximum allowable amount of data to be routed for the mobile device 104 through the steering function 136-1, the traffic steering server 140 may begin routing data for the mobile device 104 through the steering function 136-1 and monitor the amount of data that has been routed to ensure that the quota is not exceeded. If the response indicates that the request from block 345 was denied, the traffic steering server 140 may be operable to return an error message to one or both of the policy server 116 and the gateway server 112 indicating that current traffic steering service is not available for the mobile device 104.

Thus, in summary, billing server 120 may initiate billing control for traffic steering activity within network 132 through an association between a (relatively) permanent user identifier and a temporary network identifier stored at billing server 120, and through a direct communication link between billing server 120 and traffic steering server 140.

After the steering data session is established between the billing server 120 and the traffic steering server 140, the traffic steering server 140 controls the network 132 to route data associated with the mobile device 104 through a series of appropriate steering functions 136, as described above. During such routing activities, as described below, the traffic steering server 140 is operable to report usage data to the billing server 120, enabling the billing server 120 to implement various control mechanisms for communication between the WAN 124 and the mobile device 104 based on either or both of the usage data traditionally reported by the gateway server 112 (e.g., via the core data session described above) and the new type of steered data session established by execution of the method 300.

Turning now to fig. 4, a method 400 for implementing billing control for traffic steering operations is shown. The performance of method 400 follows the performance of method 300; that is, before the method 400 begins, communication has been established between the billing server 120 and the traffic steering server 140, and it is assumed that data is being routed between the mobile device 104 and the WAN 124 through the core network 108 and the intermediate network 132.

At block 405, the traffic steering server is operable to report usage data to the billing server 120 via the steering data session established by performing the method 300. The reporting of usage data may take a variety of forms. For example, the traffic steering server 140 may be configured to monitor the amount of data associated with the mobile device 104 that passes through a series of steering functions 136, and deduct that amount from a quota previously allocated to the traffic steering server 140 by the billing server 120. Thus, when the current quota is below a predetermined threshold, the traffic steering server 140 can enable reporting of usage data by requesting additional quotas. It is now apparent to one of ordinary skill in the art that such quota requests include the amount of data actually consumed and requests for additional quotas.

The usage report may also include data identifying the steering function(s) 136 through which data related to the mobile device 104 may be routed as well as any of the various parameters defining the activity of the steering function (e.g., the aforementioned video resolution parameters). The quota request may also be specific to certain steering functions, e.g., may cause the traffic steering server 140 to report usage separately for each of the steering functions 136-1 and 136-2.

As will now be apparent, the usage report sent at block 405 is a variation of the request sent at block 325 except that it relates to the initial session request, while block 405 relates to the session update request. Of particular note, similar to the request of block 325, the request sent at block 405 includes a network identifier currently assigned to the relevant mobile device.

At block 410, the billing server 120 is operable to receive the usage data from the traffic steering server 140 and select a user record from the database 216 based on the network identifier. The selection of the user record may be performed in the same manner as described above in connection with block 335 of method 300. In other embodiments, the billing server 120 may be configured to store a session identifier for a particular session initiated via block 325, and may also identify the associated user record. Subsequent requests, such as the request sent at block 405, may include a session identifier, allowing the billing server 120 to retrieve the correct user record without using the above-described association between the user and the network identifier. However, this association allows the correct user record to be retrieved without a separate session list.

At block 415, the billing server 120 may be configured to update the account balance of the selected user record based on the usage report received at block 410. For example, the billing server 120 may determine a reported usage rate (e.g., based on reported usage of the diversion function 136) and deduct an amount from the account balance based on the reported data volume and rate. In other examples, the billing server 120 may be operable to deduct a predetermined fee from the account balance at a first instance of use given the diversion function 136 during a predetermined period of time. Thus, any use of certain diversion functions may be billed monthly, with the fee being fixed regardless of the extent to which those diversion functions are used by mobile device 104.

The billing server 120 may also determine that the account balance does not need to be updated at block 415. For example, some of the diversion functions 136 may have a zero storage rate or may be identified on a list of white list diversion functions stored in memory 204. In other examples, for a given turn-around function, the billing server 120 may determine that the above-described flat fee has been applied for the current time period (e.g., the current month), and therefore need not be applied again.

Billing server 120 may also update the counters stored in the selected user records to reflect the usage reports received at block 410. For example, the video optimization counters shown in fig. 1 and 3 may be updated in response to receipt of usage data identifying a video optimization diversion function. Further, the billing server 120 may be used to provide counters to the policy server 116 (e.g., through the Sy interface), which may in turn send updated traffic policy instructions to the traffic steering server 140. Thus, when a predetermined video optimal use threshold is exceeded, the interconnection between the traffic steering server 140 and the billing server 120 may allow the policy server 116 to update the traffic steering policy applied by the traffic steering server 140 to cease using the video optimal steering function.

The account balance and counters are updated according to the request and the counters are sent to the policy server 116 according to the request, and the billing server 120 is used to generate and send response data to the traffic steering server 140 at block 420 (i.e., in response to the request received at block 410). The response may take the form of a Diameter Credit Control Answer (CCA) message, an HTTP response, or the like.

The content of the response is based on the selected user record and the request. For example, if a request from the traffic steering server 140 gives the steering function an additional quota, the response may indicate whether the additional quota is granted (in determining whether the account balance is sufficient to grant the additional quota). If the account balance is exhausted, the response may include instructions to stop routing data to or from mobile device 104. In other embodiments, the response may include a redirect command when the account balance is exhausted or below a predetermined threshold. The redirect command may include an identifier (e.g., a URL) of the account replenishment webpage at which the mobile device 104 may initiate replenishment of the account balance.

The response from billing server 120 may also include instructions to update the control parameters for the steering function. For example, when the account balance is below a predetermined threshold, the billing server 120 may instruct the traffic steering server 140 to continue using the video optimization steering function described above, but reduce the resolution of the video data provided to the mobile device 104. The response from the billing server 120 may also include other information identified in the request, such as the current location of the mobile device 104 (the billing server 120 may obtain from other network elements in the core network 108), an identifier of the access technology currently used by the mobile device 104, a subscriber identifier (e.g., MSISDN, IMSI), and so forth.

At block 425, the traffic steering server 140 is operable to receive the response from the billing server 120 and control the elements of the intermediate network 132 according to the currently loaded traffic steering policy and response. When there is a conflict between the steering policy and the response data from the billing server 120, the traffic steering server 140 may be configured to prioritize the response data.

After execution of block 425, performance of method 400 can be repeated any suitable number of times until the data session associated with mobile device 104 is terminated.

Turning now to fig. 5, a method 500 of terminating billing control for traffic steering operations is depicted. The method 500 is performed by the billing server 120 by executing the application 212. Generally, the functionality of method 500 is initiated during execution of method 400 (i.e., when data is routed between mobile device 104 and WAN 124). At block 505, the billing server receives a notification from the gateway server 112 to terminate the core data session established at block 305 of method 300. The notification indicates that the corresponding data flow between the mobile device 104 and the WAN 124 has ceased, although it is apparent that other data flows between the mobile device 104 and the WAN 124 are still active. The notification received at block may be, for example, a CCR message including a termination instruction, as well as a subscriber identifier associated with the mobile device and a current network identifier for the mobile device.

At block 510, the billing server 120 is configured to determine whether any other core data sessions remain active for the mobile device 104. As will be apparent to one of ordinary skill in the art, at least two requests from the WAN 124 by the mobile device 104 may result in at least two different data sessions by the mobile device 104. The billing server 120 may be used to maintain a list of the current core data sessions for each mobile device, for example in an additional field in the relevant user record. Thus, at block 510, the billing server 120 may be configured to remove the session identified in the request from the similar list and determine whether there are any other sessions in the list at block 505.

When the determination at block 510 is affirmative, execution of method 500 proceeds to block 515 where the billing server 120 terminates the core data session but does not change the association between the network and user identifiers of the mobile device 104 at block 515. Conversely, when the determination at block 510 is negative, the billing server 120 is configured to terminate the core data session and delete the association between the network and the user identifier. In other words, the contents of the database 216 are restored from the contents shown in table 3 to the contents shown in table 1. The billing server 120 may also send a session termination instruction to the traffic steering server 140.

Although substantially real-time online charging is discussed above, the interconnection between the traffic steering server 140 and the charging entity may also be implemented in a core network that employs offline (i.e., post-paid) charging, rather than or in combination with online charging. For example, the traffic steering server 140 may be connected to an offline billing server in the network 108 through an additional interface (which may be referred to as Gzt), as opposed to the billing server 120. In this embodiment, the traffic steering server 140 may report usage data to an offline billing server, although the offline server typically will not respond to such reports (beyond confirmation of the report).

It will now be apparent to those skilled in the art that the establishment of a session of data usage reported by the billing server 120 through the gateway server 112 and the traffic steering server 140 may result in usage reports from each of the gateway server 112 and the traffic steering server 140 for the same amount of data. To avoid double billing, the billing server 120 may be configured to implement any of a wide variety of billing schemes. For example, billing may be based primarily on usage data from the gateway server 112, and additional fixed (e.g., monthly) charges may be applied to use certain traffic steering services. In other embodiments, the billing server 120 may effect billing based only on the reported data from the traffic steering server 140 and grant large quota amounts to the gateway server 112 without deduction from the account balance of those quota amounts. The billing server 120 may also instruct the gateway server 112 to whitelist (i.e., free) some or all of the data associated with the mobile device 104, thereby eliminating the need for the gateway server 112 to report usage to the billing server 120. In such an embodiment, instead, the gateway server 112 need only report the establishment and termination of the data session to the billing server 120.

Those of ordinary skill in the art will appreciate that in some embodiments, the functionality of the

applications

216 and 266 may be implemented using pre-programmed hardware or firmware elements (e.g., Application Specific Integrated Circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs)), and the like, or other related components.

The scope of the claims should not be limited by the embodiments set forth in the above examples, but should be given the broadest interpretation consistent with the description as a whole.

Claims

1. A method in a charging server of a core mobile network, the charging server having a processor, a communication interface, and a memory, the method comprising:

storing at least two user records in the memory, the user records containing respective user identifiers corresponding to respective mobile devices;

receiving a core session request from a gateway server in the core mobile network, the core session request indicating that one of the mobile devices is attempting to communicate with a wide area network through the core mobile network, and the core session request including one of the user identifiers and a network identifier corresponding to the one mobile device;

updating one of said user records, said one user record comprising a user identifier and an association between said one user identifier and said network identifier;

establishing a core data session with the gateway server in response to the core session request;

receiving a diversion session request from a traffic diversion support server in an intermediate network, the diversion session request indicating an attempt to route communications between the one mobile device and the wide area network through the intermediate network, and the diversion session request including the network identifier;

selecting said one user record based on the stored association between said network identifier and said one user identifier; and

sending a response to the traffic steering support server accepting or rejecting the establishment of a steering data session based on the selected content of the user record.

2. The method of claim 1, further comprising:

receiving usage reporting data from the traffic steering support server in response to sending a response to the traffic steering support server accepting establishment of the steering data session, the usage reporting data representing an amount of data exchanged between the mobile device and the wide area network over the traffic steering network; and

updating the one user record based on the usage reporting data.

3. The method of claim 2, wherein the one subscriber record includes an account balance associated with the one mobile device, and wherein updating the one subscriber record includes updating the account balance.

4. The method of claim 3, wherein updating the account balance comprises deducting an amount from the account balance based on the amount of data represented by the usage reporting data.

5. The method of claim 3, further comprising:

in response to receiving the usage reporting data, determining whether the account balance exceeds a predetermined threshold; and

when the account balance does not exceed the predetermined threshold, sending a response to the traffic steering support server including a redirect command identifying an account replenishment web page.

6. The method of claim 2, the usage reporting data comprising an identifier of a traffic steering function within the intermediate network; the method further comprises the following steps:

updating a counter corresponding to the traffic steering function in the one user record.

7. The method of claim 6, further comprising:

in response to updating the counter, sending the counter to a policy server in the core mobile network.

8. The method of claim 1, further comprising:

receiving a notification from the gateway server to terminate the core data session;

determining whether other core data sessions have been established in relation to the mobile device in response to receiving the notification; and

when the determination is negative, updating the one user record to delete the association between the one user identifier and the network identifier.

9. A method in a traffic steering support server of an intermediate network, the method configured for routing communications between a wide area network and a core mobile network, the traffic steering support server having a processor, a communication interface, and a memory, the method comprising:

storing in the memory at least two traffic steering policy records, each policy record comprising a policy identifier and a series of intermediate network element identifiers;

receiving a policy session request from a policy server in the core mobile network, the policy session request including one of the policy identifiers and a network identifier corresponding to a mobile device;

in response to the policy session request, establishing a policy data session with the policy server and loading the policy record including the one policy identifier;

sending a turn-to-session request to a charging server in the core mobile network, the turn-to-session request including the network identifier;

receiving a response of the charging server accepting or rejecting to establish the diverted data session; and

routing communications between the mobile device and the wide area network through the series of intermediate network elements identified in the loaded policy record when the response indicates acceptance of the diverted data session.

10. The method of claim 9, further comprising:

storing usage data representing an amount of data routed between the mobile device and the wide area network through the intermediate network in response to a routed communication between the mobile device and the wide area network; and

sending usage reporting data to the billing server, the usage reporting data including the usage data.

11. The method of claim 10, wherein the usage reporting data comprises an identifier of at least one element in the series of intermediate network elements.

12. The method of claim 10, wherein the usage reporting data comprises a quota reservation request from an account balance associated with the mobile device.

13. The method of claim 10, wherein the usage reporting data comprises the network identifier.

14. A charging server in a core mobile network, comprising:

a communication interface;

a memory; and

a processor interconnected with the communication interface and the memory, the processor configured to perform the method of any of claims 1-8.

15. A traffic steering support server in an intermediate network for routing communications between a wide area network and a core mobile network, comprising:

a communication interface;

a memory; and

a processor interconnected with the communication interface and the memory, the processor configured to perform the method of any of claims 9-13.