EP3469819A1

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

Info

Publication number: EP3469819A1
Application number: EP16904536.6A
Authority: EP
Inventors: Uwe GLEINIG; Michael Jung; Jens Schendel
Original assignee: Redknee Inc
Current assignee: Redknee Inc
Priority date: 2016-06-09
Filing date: 2016-06-09
Publication date: 2019-04-17
Also published as: WO2017212318A1; CN109417683B; CN109417683A

Abstract

A charging server in a core network stores subscriber records containing subscriber identifiers for mobile devices. The charging server receives a core session request from a gateway server, indicating an attempt by a mobile device to communicate, e.g. with a wide area network (WAN). The request includes the mobile device's subscriber identifier and currently assigned network identifier. The charging server updates the corresponding subscriber record with an association between the subscriber and network identifiers. The charging server also receives a steering session request including the network identifier from a traffic steering server in an intermediation network; the traffic steering server sends the steering session request upon receiving the network identifier from a core network policy server. Using the network identifier in the steering session request and the stored association, the charging server retrieves the correct subscriber record, and accepts or rejects the establishment of a steering data session based on the content of the retrieved subscriber record.

Description

CORE NETWORK ONLINE CHARGING CONTROL FOR

INTERMEDIATE NETWORK TRAFFIC STEERING

FIELD

[0001] The specification relates generally to traffic steering in intermediate networks, and specifically to online charging control of traffic steering from within a core network.

BACKGROUND

[0002] In conventional mobile networks, traffic steering services can be provided by network operators on a steering network positioned between the core mobile network and a wide area network such as the Internet. Such steering services are typically managed by a traffic steering support function (TSSF). The TSSF is instructed (e.g. by a policy element in the core network) as to how to route client data through the steering network. Client device identification is generally based on a (temporary) IP address in the steering network. In contrast, the core mobile network employs a subscriber identifier, such as a telephone number, to identify a client device. The use of distinct identifiers in the core and steering networks, combined with the nature of the convention connection between the TSSF and above-mentioned policy element, renders charging control (exerted by the core network) on traffic steering activities difficult or impossible.

SUMMARY

[0003] A charging server in a core network stores subscriber records containing subscriber identifiers for mobile devices. The charging server receives a core session request from a gateway server, indicating an attempt by a mobile device to communicate, e.g. with a wide area network (WAN). The request includes the mobile device's subscriber identifier and currently assigned network identifier. The charging server updates the corresponding subscriber record with an association between the subscriber and network identifiers. The charging server also receives a steering session request including the network identifier from a traffic steering server in an intermediation network; the traffic steering server sends the steering session request upon receiving the network identifier from a core network policy server. Using the network identifier in the steering session request and the stored association, the charging server retrieves the correct subscriber record, and accepts or rejects the establishment of a steering data session based on the content of the retrieved subscriber record.

BRIEF DESCRIPTIONS OF THE DRAWINGS

[0004] Embodiments are described with reference to the following figures, in which:

[0005] FIG. 1 depicts a communications system, according to a non-limiting embodiment;

[0006] FIG. 2 depicts certain internal components of the charging and traffic steering servers of the system of FIG. 1 , according to a non-limiting embodiment;

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

[0008] FIG. 4 depicts a method of charging control in the system of FIG. 1 , according to a non-limiting embodiment; and

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

DETAILED DESCRIPTION OF THE EMBODIMENTS

[0010] FIG. 1 depicts a communications system 100. System 100 includes a mobile device 104, which can be any of a variety of mobile computing devices, including smart phones, cell phones, laptop computers and the like. Mobile device 104 thus comprises hardware elements including a processing unit, volatile and non-volatile memory, network interfaces, input devices and output devices (e.g. any suitable combination of displays, speakers, microphones, touch screens and the like). The processing unit of mobile device 104 executes programming instructions stored in memory (e.g. the above-mentioned nonvolatile storage) for carrying out various functions, including the initiation of data communications over various networks. Multiple mobile devices may be included in system 100, but only mobile device 104 is shown for the purpose of illustration.

[0011] Mobile device 104 is connected to a core mobile network 108. Core mobile network 108, also referred to herein as network 108, can be based on any suitable standard or combination of standards. In the present example, network 108 is an Evolved Packet Core (EPC) network structured according to the Long Term Evolution (LTE) standard set by the 3rd Generation Partnership Project (3GPP). In other examples, however, network 108 can be structured according to a wide variety of other standards, such as the third Generation (3G) standard. The nature of the connection between mobile device 104 and core mobile network 108 is therefore variable, and is selected according to the implementation of core mobile network 108. In the present example, in which core mobile network 108 is an EPC network, the connection with mobile device 104 can be established through a conventional access network such as eNodeB.

[0012] Network 108 includes a gateway server 1 12, a policy server 1 16, and a charging server 120. In the present example, in which core network 108 is an LTE core network, it will be apparent to those skilled in the art that gateway server 1 12 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 1 16 may also be referred to as a Policy and Charging Rules Function (PCRF) defined by the 3GPP specifications. Charging server 120, in turn, may also be referred to as an Online Charging System (OCS). Various features of a P-GW, PCRF and OCS will be known to those skilled in the art from published 3GPP specifications, including 3GPP Technical Specification 23.203. As will be seen below, however, charging server 120 includes certain novel features that depart from those of the OCS as defined by the 3GPP specifications. [0013] Other elements of core mobile network 108 (such as a Mobility Management Entity, MME, a Home Subscriber Server, HSS, one or more Serving Gateways, S-GW, a Traffic Detection Function, TDF, and the like) can be implemented conventionally, and are therefore not shown herein for simplicity.

[0014] In general, core mobile network 108 allows 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 1 12 (via other network elements such as the MME and S-GW mentioned above). Gateway server 1 12, in turn, contacts policy server 1 16 over a communications link, which in the present embodiment is based on the known Gx interface (a variant of the Diameter protocol) to obtain policy and charging control rules to be applied to the communications between mobile device 104 and WAN 124. Policy server 1 16 generates such rules based on information received from gateway server 1 12, as well as information retrieved from a Subscriber Profile Repository (SPR) database 128. In some cases, policy server 1 16 may also receive information for use in rule generation from an application function (AF, not shown) residing in WAN 124, to which mobile device 104 has requested access.

[0015] Having generated the above-mentioned rules, policy server 1 16 provides the rules over the Gx interface to gateway server 1 12. Gateway server 1 12, in turn, enforces those rules during communications between mobile device 104 and WAN 124. The rules may specify the quality of service (QoS) parameters to which mobile device 104 is entitled (e.g. bandwidth and latency), usage limits, charging parameters and the like. During communications between mobile device 104 and WAN 124, gateway server 1 12 can provide usage data (e.g. what volume of data has been carried between mobile device 104 and WAN 124) to policy server 1 16 over the Gx interface, and to charging server 120 over the known Gy interface (another variant of the Diameter protocol).

[0016] In addition, policy server 1 16 may generate (or update, after communications between mobile device 104 and WAN 124 have begun) the above-mentioned rules based on information received from charging server 120. Specifically, charging server 120 maintains a charging database, in which the above-mentioned usage data from gateway server 1 12 is stored. The charging database also stores charging related information associated with mobile device 104, such as an account balance and rating information (e.g. how much mobile device 104 must pay for certain volumes of data, certain services, and the like). In addition, charging server 120 can determine monetary values for the usage data and deduct those values from the account balance associated with mobile device 104. Charging server 120 can also track the usage data, the monetary values, or both, by updating counters in the charging database. Such counters can be provided by charging server 120 to policy server 1 16 for controlling mobile device 104's access to WAN 124. For example, policy server 1 16 may be configured to alter the bandwidth available to mobile device 104 once mobile device 104 has exchanged a volume of data exceeding a predetermined monetary cost with WAN 124. The exchange of usage counters between charging server 120 and policy server 1 16 can be conducted over the known Sy interface (as defined by 3GPP TS 29.219).

[0017] Thus, network 108 permits mobile device 104 to access WAN 124, and such access is regulated by gateway server 1 12 based on control information generated by policy server 1 16. An account associated with mobile device 104 maintained at charging server 120 is debited during the access, and the status of that account can also be employed to control the access.

[0018] In the present embodiment, communications between mobile device 104 and WAN 124 are routed not only through core network 108 (in particular, gateway server 1 12), but also through an intermediate network 132, which may also be referred to as an (S)Gi-LAN, for the (S)Gi interface (see 3GPP TS 29.061 ) interconnecting gateway server 1 12 and network 132. Network 132 contains one or more network elements referred to as steering functions (SFs) through which the communications between mobile device 104 and WAN 124 can be routed. In the present embodiment, three steering functions 136-1 , 136-2, and 136-3 (collectively referred to as steering functions 136, and generically referred to as a steering function 136) are shown. [0019] The nature of the steering functions is not particularly limited: steering functions can execute video optimization algorithms (e.g. to compress video data travelling from WAN 124 to mobile device 104), anti-malware algorithms, parental control functions, firewall and network address translation functions, and the like. As will now be apparent to those skilled in the art, the nature of the communications between mobile device 104 and WAN 124 can determine which steering functions are suitable for use. For example, if the data exchanged between mobile device 104 and WAN 124 does not include video data, then there is little reason to expend the computational resources of a video optimization steering function to process that data.

[0020] Network 132 therefore includes a traffic steering server 140, also referred to as a Traffic Steering Support Function (TSSF), for controlling which steering functions 136 are employed for any given stream of data travelling to or from mobile device 104. For example a path 144 shown in FIG. 1 illustrates that data destined for mobile device 104 travels first through steering function 136-1 , then through steering function 136-2 (and not through steering function 136-3) before being routed to core network 108 via traffic steering server 140.

[0021] Certain functions of traffic steering server 140 will occur to those skilled in the art, as they are defined in the 3GPP specifications. In particular, traffic steering server 140 maintains steering policies defining various chains of service functions. Policy server 1 16 is configured to instruct traffic steering server 140, over the known St interface, which steering policy (or policies) to implement at any given time for mobile device 104. Traffic steering server 140 is then configured to control the steering functions 136 of network 132 to route data destined for mobile device 104 (or originating from mobile device 104) through the specified chain of steering functions 136.

[0022] Traffic steering server 140, like charging server 120, also implements functionality that is not contemplated in the 3GPP specifications. In particular, traffic steering server 140 and charging server 120 are configured to communicate directly with each other over a novel interface (referred to in FIG. 1 as "Gyt"), and to perform various actions as a result of such communications. Before discussing the actions of charging server 120 and traffic steering server 140 in detail, a brief description of certain internal components of charging server 120 and traffic steering server 140 will be provided, with reference to FIG. 2.

[0023] Turning to FIG. 2, charging server 120 includes a central processing unit (CPU) 200, also referred to herein as a processor 200, interconnected with a memory 204. Processor 200 and memory 204 are generally comprised of one or more integrated circuits (ICs), and can have a variety of structures, as will now occur to those skilled in the art (for example, more than one CPU can be provided).

[0024] Memory 204 can 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 device, or optical disc) memory. In the present example, memory 204 includes both volatile and non-volatile storage.

[0025] Processor 200 is also interconnected with one or more network interfaces, such as a network interface controller (NIC) 208, which allows charging server 120 to connect to other computing devices in networks 108, 124 and 132. NIC 208 thus includes the necessary hardware to communicate over the above networks. Charging server 120 can also include input devices (not shown) interconnected with processor 200, such as a keyboard and mouse, as well as output devices (not shown) interconnected with processor 200, such as a display. In some embodiments, the input and output devices can be connected to processor 200 via NIC 208 and another computing device. In other words, input and output devices can be local to charging server 120, or remote.

[0026] Memory 204 stores a plurality of computer-readable programming instructions, executable by processor 200, in the form of various applications, and also stores various non-executable data for use during the execution of those applications. As will be understood by those skilled in the art, processor 200 may execute the instructions of one or more such applications in order to perform various operations defined within the instructions. In the description below, processor 200 or charging server 120 more generally are said to be "configured to" or "operated to" perform certain functions. It will be understood that charging server 120 is so configured via the processing of the instructions of the applications stored in memory 204.

[0027] Among the applications stored in memory 204 is a charging application 212, containing instructions executable by processor 200 to cause server 120 to perform various actions described herein related to authorizing and charging for communications between mobile device 104 and WAN 124. In addition, memory 204 stores a charging database 216, as mentioned above. Charging database 216 contains a plurality of subscriber records, each containing respective subscriber identifiers such as a Mobile Station International Subscriber Directory Number (MSISDN) or an International Mobile Subscriber Identity (IMSI) number corresponding to a mobile device. As will now be apparent to those skilled in the art, the above subscriber identifiers are not necessarily tied permanently to a given mobile device - telephone numbers can be reassigned to other mobile devices. However, for the purposes of this discussion, it will be assumed that a subscriber identifier corresponds to a specific mobile device, for simplicity.

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

Table 1 : Example Charging Database 216

[0029] As seen in Table 1 , a subscriber record corresponding to mobile device 104 is contained in database 216, and includes an account balance and a set of usage counters. Specifically, a first usage counter represents the volume of data that mobile device 104 has "consumed" over the current month, and a second usage counter represents the volume of data (e.g. for the current month) that has been transmitted to mobile device 104 having been routed through a video optimization steering function 136. A wide variety of other counters may also be stored in the records of database 216. Various other charging data may also be tracked in each subscriber record, such as quotas (e.g. volumes of data reserved for certain applications or services), lists of services or applications to which each subscriber identifier has access, rates (per volume of data, or flat) that each subscriber pays for various services or applications, and the like.

[0030] Each subscriber record also contains a network identifier association ("Current Network ID"). In the example of Table 1 , the network identifier association for mobile device 104 is empty; the population of that field will be discussed below in greater detail.

[0031] Referring again to FIG. 2, traffic steering server 140 includes a CPU 250, also referred to herein as a processor 200, interconnected with a memory 254. Processor 250 and memory 254 are generally comprised of one or more ICs, and can have a variety of structures, as will now occur to those skilled in the art (for example, more than one CPU can be provided).

[0032] Memory 254 can be any suitable combination of volatile (e.g. RAM) and non-volatile (e.g. ROM, EEPROM), flash memory, magnetic computer storage device, or optical disc) memory. In the present example, memory 254 includes both volatile and non-volatile storage.

[0033] Processor 250 is also interconnected with one or more network interfaces, such as a network interface controller (NIC) 258, which allows traffic steering server 140 to connect to other computing devices in networks 108, 124 and 132. NIC 258 thus includes the necessary hardware to communicate over the above networks. Traffic steering server 140 can also include input devices (not shown) interconnected with processor 250, such as a keyboard and mouse, as well as output devices (not shown) interconnected with processor 250, such as a display. In some embodiments, the input and output devices can be connected to processor 250 via NIC 258 and another computing device. In other words, input and output devices can be local to traffic steering server 140, or remote.

[0034] Memory 254 stores a plurality of computer-readable programming instructions, executable by processor 250, in the form of various applications, and also stores various non-executable data for use during the execution of those applications. As will be understood by those skilled in the art, processor 250 may execute the instructions of one or more such applications in order to perform various operations defined within the instructions. In the description below, processor 250 or traffic steering server 140 more generally are said to be "configured to" or "operated to" perform certain functions. It will be understood that traffic steering server 140 is so configured via the processing of the instructions of the applications stored in memory 254.

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

Table 2: Example Traffic Steering Policy Database 216

[0036] As seen in Table 2, two example records each define a traffic steering policy. The "video" steering policy routes traffic through steering functions 136-1 and 136-2, while the "anti-malware" steering policy routes traffic through steering functions 136-1 and 136-3. Other steering policy records can define steering function chains with more or fewer steering functions 136 (i.e. a steering policy can include a single steering function 136). Database 216 can contain additional data, such as service identifiers for each steering function 136, as well as control parameters for each steering function 136 (e.g. a resolution for video optimization, a parameter for enabling or disabling an ad-blocking function provided by the video optimization steering function, and the like).

[0037] Turning now to Figure 3, a method 300 of charging control initiation for traffic steering is illustrated. Method 300 will be described in conjunction with its performance on system 100, although it will be apparent to those skilled in the art that method 300 may also be performed on suitable variants of system 100.

[0038] Beginning at block 305, charging server 120 is configured to receive a core session request from gateway server 1 12. As will now be apparent, prior to the receipt of the request at block 305, various other conventional events occur, including the transmission of a request from mobile device 104 to gateway server 1 12 (e.g. requesting access to a particular resource in WAN 124). Additionally, gateway server 1 12 may establish communications with policy server 1 16 to receive the rules mentioned above, before contacting charging server 120. Further, policy server 1 16 may establish communications (e.g. over the Sy interface) with charging server 120 to obtain charging data for use in generating rules to deploy to gateway server 1 12.

[0039] The contents of the request received at block 305 will be apparent to those skilled in the art. For the purpose of this discussion, it will be noted that the request includes both a subscriber identifier such as a MSISDN, IMSI or the like, and a network identifier (e.g. an IP address; typically referred to as a PDP- Address in the context of a Gy session), which is typically assigned temporarily (i.e. for the duration of the requested access to WAN 124) to mobile device 104 by an element of core network 108 or the access network connecting mobile device 104 to core network 108.

[0040] At block 310, having received the request from gateway server 1 12, charging server 120 is configured to establish a core data session (e.g. over the Gy interface) with gateway server 1 12, or alternatively, to reject establishment of such a session, for example if the account associated with mobile device 104 in charging database 216 has an insufficient balance to support the requested access to WAN 124. In the present example performance of method 300, it will be assumed that the Gx session is successfully established. In addition, at block 310 charging server 120 is configured to update charging database 216 with an association between the subscriber identifier and network identifier received in the request at block 305.

[0041] Specifically, charging server 120 is configured to select the subscriber record containing the subscriber identifier in the request, and update that record to complete the "Current Network ID" field with the network identifier contained in the request. An example of database 216 following the performance of block 310 is shown below in Table 3.

Table 1 : Example Charging Database 216

[0042] As seen above, an association between the subscriber identifier assigned to mobile device 104 and the temporary network identifier assigned to mobile device 104 has been established by storing the network identifier in the subscriber record. The association may be stored by various other mechanisms. For example, charging server 120 can maintain a separate index of such associations, rather than updating the subscriber record as shown above. [0043] At block 315, traffic steering server 140 is configured to receive a policy session request from policy server 1 16 (e.g. over the St interface). The request received at block 315 generally temporally follows the establishment of the core data session between charging server 120 and gateway server 1 12, although this is not mandatory.

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

[0045] At block 325, in contrast to conventional traffic steering support functions, traffic steering server 140 is configured to send a steering session request to charging server 120, including the network identifier received from policy server 1 16. The request sent at block 325 is transmitted over the interface labelled as Gyt in FIG. 1 . Typically, the request sent at block 325 does not include the subscriber identifier corresponding to mobile device 104 - indeed, traffic steering server 140 may not be configured to recognize or store subscriber identifiers. The steering session request can take the form of a Diameter Credit Control Request (CCR), an HTTP request, or the like.

[0046] The request transmitted by traffic steering server 140 can include additional data beyond the network identifier currently assigned to mobile device 104. For example, the request can include identifiers of each of the steering functions in the chain defined by the policy record loaded at block 320. In addition, the request can include operational attributes for the steering functions in the chain (e.g. a resolution attribute such as "high definition" or "standard definition" for a video optimization steering function).

[0047] At block 330, charging server 120 is configured to receive the steering session request from traffic steering server 140. At block 335, charging server 120 is configured to select one of the subscriber records in database 216 based on the network identifier contained in the request from traffic steering server 140. In particular, the selection of a subscriber record at charging server 120 is enabled by charging server 120's previous storage of an association between the network identifier and the comparatively permanent subscriber identifier corresponding to mobile device 104.

[0048] Therefore, at block 335, charging server 120 is configured to select the subscriber record that contains an association between the network identifier received from traffic steering server 140 and a subscriber identifier. In the present example, at block 335 charging server 120 selects the record shown in Table 3, which contains the current IP address of mobile device 104, in association with the subscriber identifier "104@acme.com".

[0049] Having selected a subscriber record, charging server 120 is then configured to generate and send a response to traffic steering server 140 based on the contents of the selected subscriber record. The generation of a response can include a variety of determinations at charging server 120. For example, charging server 120 may retrieve a rate for the requested traffic steering functions from memory 204 and determine whether the account balance of the selected subscriber record is sufficient to support a predefined volume of data at the retrieved rate. As another example, charging server 120 can simply determine whether the account balance is above a predefined monetary threshold (e.g. stored in memory 204). The generation of a response can also include reserving a portion of the account balance and allocating a quota (e.g. in the form of a volume of data) for use by traffic steering functions.

[0050] More generally, the response generated by charging server 120 indicates whether the request by traffic server 140 is accepted or rejected, and when the request is accepted, may also include parameters such as the above- mentioned quotas, for use by traffic steering server 140 in controlling the steering functions 136 of network 132.

[0051] At block 345, traffic steering server 140 is configured, following receipt of the response from charging server 120, to control the elements of network 132 according to the response as well as the steering policy loaded at block 320. For example, if the response included a quota indicating a maximum allowable volume of data to be routed via steering function 136-1 for mobile device 104, traffic steering server 140 can begin routing data for mobile device 104 through steering function 136-1 , and monitor the volume of data so routed to ensure that the quota is not exceeded. If the response indicates that the request from block 345 is rejected, traffic steering server 140 can be configured to return an error message to one or both of policy server 1 16 and gateway server 1 12, indicating that traffic steering services are not currently available for mobile device 104.

[0052] In summary, therefore, through the storage of an association between a (relatively) permanent subscriber identifier and a temporary network identifier at charging server 120, as well as through the direct communication link between charging server 120 and traffic steering server 140, charging server 120 can initiate charging control on traffic steering activities within network 132.

[0053] Following the establishment of a steering data session between charging server 120 and traffic steering server 140, as noted above, traffic steering server 140 controls network 132 to route data associated with mobile device 104 through the appropriate chain of steering functions 136. During such routing activities, as will be discussed below, traffic steering server 140 is configured to report usage data to charging server 120, enabling charging server 120 to implement various control mechanisms on the communications between WAN 124 and mobile device 104 based on either or both of usage data reported conventionally by gateway server 1 12 (e.g. over the core data session mentioned above) and the novel steering data session established via the performance of method 300.

[0054] Turning now to FIG. 4, a method 400 of implementing charging control for traffic steering operations is illustrated. The performance of method 400 follows a performance of method 300; that is, prior to the beginning of method 400, communications have been established between charging server 120 and traffic steering server 140, and it is assumed that data is being routed between mobile device 104 and WAN 124 via core network 108 and intermediate network 132.

[0055] At block 405, traffic steering server is configured to report usage data to charging server 120 over the steering data session established through the performance of method 300. The reporting of usage data can take any of a variety of forms. For example, traffic steering server 140 can be configured to monitor the volume of data traversing the relevant chain of steering functions 136 in association with mobile device 104, and deduct the volume from a quota previously allocated to traffic steering server 140 by charging server 120. The reporting of usage data can therefore be implemented by traffic server 140 by requesting additional quota when the current quota falls below a predefined threshold. Such quota requests, as will now be apparent to those skilled in the art, include the volume of data actually consumed as well as a request for additional quota.

[0056] The usage reporting can also include data identifying the steering function (or multiple steering functions) 136 through which data associated with mobile device 104 is currently being routed, as well as any of a variety of parameters defining the activities of the steering functions (e.g. the video resolution parameter mentioned earlier). Quota requests may also be specific to certain steering functions, such that traffic steering server 140 may report usage separately for each of steering functions 136-1 and 136-2, for example.

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

[0058] At block 410, charging server 120 is configured to receive the usage data from traffic steering server 140, and to select a subscriber record from database 216 based on the network identifier. The selection of a subscriber record can be performed in the same way as described above in connection with block 335 of method 300. In other embodiments, charging server 120 can be configured to store a session identifier specific to the session initiated via block 325 and also identifying the relevant subscriber record. Subsequent requests (such as that sent at block 405) can include the session identifier, permitting charging server 120 to retrieve the correct subscriber record without the use of the above-mentioned association between subscriber and network identifiers. However, the association permits the retrieval of the correct subscriber record without a separate session list.

[0059] At block 415, charging server 120 can be configured to update the account balance of the selected subscriber record based on the usage report received at block 410. For example, charging server 120 can determine a rate for the reported usage (e.g. based on which steering function(s) 136 usage is reported for) and deduct an amount from the account balance according to the reported volume of data and the rate(s). In other examples, charging server 120 can be configured to deduct a predefined fee from the account balance at the first instance of usage of a given steering function 136 during a predefined time period. Thus, any use of certain steering functions can be billed on a monthly basis, with the fee being fixed regardless of the extent to which mobile device 104 makes use of those steering functions.

[0060] At block 415, charging server 120 may also determine that no updates are required to the account balance. For example, some steering functions 136 may have a stored rate of zero or be identified on a list of whitelisted steering functions stored in memory 204. In other examples, charging server 120 may determine that the above-mentioned fixed fee has already been applied for the current time period (e.g. the current month) for a given steering function, and that there is therefore no need to apply the fee again.

[0061] Charging server 120 may also update usage counters stored in the selected subscriber record to reflect the usage report received at block 410. For example, the video optimization usage counter shown in FIGS. 1 and 3 may be updated responsive to receipt of usage data identifying the video optimization steering function. Further, charging server 120 may be configured to provide the usage counters to policy server 1 16 (e.g. over the Sy interface), which may in turn send updated traffic policy instructions to traffic steering server 140. Thus, the interconnection between traffic steering server 140 and charging server 120 may permit policy server 1 16 to update the traffic steering policies being applied by traffic steering server 140 to cease using a video optimization steering function when a predefined threshold of video optimization usage has been exceeded.

[0062] Having updated the account balance and usage counters as required, as well as sending counters to policy server 1 16 as required, at block 420 charging server 120 is configured to generate and send response data to traffic steering server 140 (i.e. responding to the request received at block 410). The response can take the form of a Diameter Credit Control Answer (CCA) message, an HTTP response, or the like.

[0063] The contents of the response is based on the selected subscriber record as well as the request. For example, if the request from traffic steering server 140 requested additional quota for a given steering function, the response can indicate whether or not the additional quota is granted (following a determination as to whether or not the account balance is sufficient to grant the additional quota). If the account balance is exhausted, the response may include an instruction to cease routing data to or from mobile device 104. In other embodiments, the response may include a redirection command when the account balance is exhausted or below a predefined threshold. The redirection command can include an identifier (e.g. a URL) of an account replenishment web page at which mobile device 104 can initiate a replenishment of the account balance.

[0064] The response from charging server 120 may also include instructions to update the control parameters for steering functions. For example, when the account balance falls below a predefined threshold, charging server 120 may instruct traffic steering server 140 to continue using the above-mentioned video optimization steering function, but to reduce the resolution of the video data provided to mobile device 104. The response from charging server 120 may also include other information identified in the request, such as a current location of mobile device 104 (which charging server 120 can obtain from other network elements in core network 108), an identifier of the access technology currently employed by mobile device 104, subscriber identifiers (e.g. MSISDN, IMSI) and the like.

[0065] At block 425, traffic steering server 140 is configured to receive the response from charging server 120, and to control the elements of intermediate network 132 according to the currently loaded traffic steering policies and the response. Traffic steering server 140 may be configured, when a conflict exists between the steering policy and the response data from charging server 120, to give precedence to the response data.

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

[0067] Turning now to FIG. 5, a method 500 of terminating charging control for traffic steering operations is depicted. Method 500 is performed by charging server 120, via the execution of application 212. Typically, the performance of method 500 is initiated during a performance of method 400 (i.e. while data is being routed between mobile device 104 and WAN 124). At block 505, charging server receives a notification from gateway server 1 12 terminating the core data session established at block 305 of method 300. The notification indicates that the corresponding flow of data between mobile device 104 and WAN 124 has ceased, although it will be apparent that other flows of data between mobile device 104 and WAN 124 remain in effect. The notification received at block may be, for example, a CCR message containing a termination instruction, as well as the subscriber identifier of the relevant mobile device and the current network identifier of that mobile device. [0068] At block 510, charging server 120 is configured to determine whether any other core data sessions remain active for mobile device 104. As will be apparent to those skilled in the art, a plurality of requests for resources from WAN 124 by mobile device 104 may result in a plurality of distinct data sessions for mobile device 104. Charging server 120 can be configured to maintain a list of current core data sessions for each mobile device, for example in an additional field in the relevant subscriber record. Thus, at block 510, charging server 120 can be configured to remove the session identified in the request at block 505 from such as list, and determine whether any other sessions are present in the list.

[0069] When the determination at block 510 is affirmative, performance of method 500 proceeds to block 515, at which charging server 120 terminates the core data session, but makes no change to the association between network and subscriber identifiers for mobile device 104. In contrast, when the determination at block 510 is negative, charging server 120 is configured to terminate the core data session and also delete the association between network and subscriber identifiers. In other words, the contents of database 216 reverts from that shown in Table 3 to that shown in Table 1 . Charging server 120 may also send a session termination instruction to traffic steering server 140.

[0070] Although substantially real-time, online charging is discussed above, the interconnection between traffic steering server 140 and a charging entity may also be implemented in a core network employing offline (i.e. post-pay) charging, instead of or in combination with online charging. For example, traffic steering server 140 may be connected via a further interface (which may be referred to as Gzt) to an offline charging server in network 108, distinct from charging server 120. In this embodiment, traffic steering server 140 can report usage data to the offline charging server, although the offline server generally will not respond to such reports (beyond an acknowledgement of the reports).

[0071] As will now be apparent to those skilled in the art, the establishment by charging server 120 of sessions through which data usage is reported with both gateway server 1 12 and traffic steering server 140 may result in the usage reports from each of gateway server 1 12 and traffic steering server 140 for the same volumes of data. In order to avoid double-billing, charging server 120 can be configured to implement any of a wide variety of charging scenarios. For example, charging can be conducted primarily based on usage data from gateway server 1 12, and additional fixed (e.g. monthly) fees can be applied for the use of certain traffic steering services. In other embodiments, charging server 120 can effect charging based only on reporting data from traffic steering server 140, and grant large quota volumes to gateway server 1 12 without deducting from the account balance for those quota volumes. Charging server 120 may also instruct gateway server 1 12 that some or all data associated with mobile device 104 is whitelisted (i.e. free of charge), thus eliminating the need for gateway server 1 12 to report usage to charging server 120. Instead, in such embodiments, gateway server 1 12 need only report the establishment and termination of data sessions to charging server 120.

[0072] Those skilled in the art will appreciate that in some embodiments, the functionality of applications 216 and 266 may be implemented using preprogrammed hardware or firmware elements (e.g., application specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), etc.), or other related components.

[0073] 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

Claims:

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

storing a plurality of subscriber records in the memory, the subscriber records containing respective subscriber 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 an attempt by one of the mobile devices to communicate with a wide area network via the core mobile network, and including one of the subscriber identifiers corresponding to the one mobile device and a network identifier;

updating one of the subscriber records that contains the one subscriber identifier with an association between the one subscriber identifier and the network identifier;

responsive to the core session request, establishing a core data session with the gateway server;

receiving a steering session request from a traffic steering support server in the intermediation network, the steering session request indicating an attempt to route communications between the one mobile device and the wide area network via an intermediation network, and containing the network identifier; based on the stored association between the network identifier and the one subscriber identifier, selecting the one subscriber record; and

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

2. The method of claim 1 , further comprising:

responsive to sending a response to the traffic steering support server accepting the establishment of the steering data session, receiving usage report data from the traffic steering support server, the usage report data representing a volume of data exchanged between the mobile device and the wide area network via the traffic steering network; and

updating the one subscriber record based on the usage report data.

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

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

5. The method of claim 2, further comprising:

determining, responsive to receiving the usage report data, whether the account balance exceeds a predetermined threshold; and

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

6. The method of claim 2, the usage report data including an identifier of a traffic steering function within the intermediation network; the method further comprising:

updating, in the one subscriber record, a usage counter corresponding to the identified traffic steering function.

7. The method of claim 6, further comprising:

responsive to updating the usage counter, transmitting the usage 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 terminating the core data session;

responsive to receiving the notification, determining whether an other core data sessions have been established in association with the mobile device; and when the determination is negative, updating the one subscriber record to delete the association between the one subscriber identifier and the network identifier.

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

storing a plurality of traffic steering policy records in the memory, each policy record containing a policy identifier and a chain of intermediate network element identifiers;

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

responsive to the policy session request, establishing a policy data session with the policy server and loading the policy record containing the one policy identifier;

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

receiving a response from the charging server accepting or rejecting the establishment of a steering data session; and

when the response indicates acceptance of the steering data session, routing communications between the mobile device and the wide area network via the chain of intermediate network elements identified in the loaded policy record.

10. The method of claim 9, further comprising: responsive to routing communications between the mobile device and the wide area network, storing usage data representing a volume of data routed between the mobile device and the wide area network via the intermediation network; and

sending usage report data to the charging server, including the usage data.

1 1 . The method of claim 10, wherein the usage report data includes an identifier of at least one of the chain of intermediate network elements.

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

13. The method of claim 10, wherein the usage report data includes the network identifier.

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

a communications interface;

a memory; and

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

15. A traffic steering support server in an intermediation network configured to route communications between a wide area network and a core mobile network, comprising:

a communications interface;

a memory; and

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