Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/14—Session management
  • H04L67/141—Setup of application sessions
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L12/00—Data switching networks
  • H04L12/02—Details
  • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L12/00—Data switching networks
  • H04L12/02—Details
  • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
  • H04L12/1403—Architecture for metering, charging or billing
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L12/00—Data switching networks
  • H04L12/02—Details
  • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
  • H04L12/1403—Architecture for metering, charging or billing
  • H04L12/1407—Policy-and-charging control [PCC] architecture
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L45/00—Routing or path finding of packets in data switching networks
  • H04L45/302—Route determination based on requested QoS
  • H04L45/306—Route determination based on the nature of the carried application
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04M—TELEPHONIC COMMUNICATION
  • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04M—TELEPHONIC COMMUNICATION
  • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
  • H04M15/66—Policy and charging system
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04M—TELEPHONIC COMMUNICATION
  • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
  • H04M15/82—Criteria or parameters used for performing billing operations
  • H04M15/8214—Data or packet based
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04M—TELEPHONIC COMMUNICATION
  • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
  • H04M15/82—Criteria or parameters used for performing billing operations
  • H04M15/8228—Session based
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
  • H04W4/24—Accounting or billing

Definitions

• the specification relates generally to traffic steering in intermediate networks, and specifically to online charging control of traffic steering from within a core network.
• 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.
• the core mobile network employs a subscriber identifier, such as a telephone number, to identify a client device.
• 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.
• 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.
• FIG. 1 depicts a communications system, according to a non-limiting embodiment
• 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
• 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 , according to a non-limiting embodiment
• FIG. 5 depicts a method of terminating charging control in the system of FIG. 1 , according to a non-limiting embodiment.
• 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.
• 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.
• 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).
• EPC Evolved Packet Core
• LTE Long Term Evolution
• 3GPP 3rd Generation Partnership Project
• 3G Third Generation
• 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.
• 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.
• Network 108 includes a gateway server 1 12, a policy server 1 16, and a charging server 120.
• 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 may also be referred to as an Online Charging System (OCS).
• OCS Online Charging System
• charging server 120 includes certain novel features that depart from those of the OCS as defined by the 3GPP specifications.
• 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
• MME Mobility Management Entity
• HSS Home Subscriber Server
• S-GW Serving Gateways
• TDF Traffic Detection Function
• 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.
• WAN wide area network
• 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 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.
• SPR Subscriber Profile Repository
• 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.
• AF Application Function
• policy server 1 16 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 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.
• QoS quality of service
• 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).
• 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.
• 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).
• 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.
• 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).
• 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.
• 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.
• SFs steering functions
• three steering functions 136-1 , 136-2, and 136-3 are shown.
• 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.
• video optimization algorithms e.g. to compress video data travelling from WAN 124 to mobile device 104
• anti-malware algorithms e.g. to compress video data travelling from WAN 124 to mobile device 104
• parental control functions e.g. to firewall and network address translation functions
• firewall and network address translation functions e.g., firewall and network address translation functions.
• 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.
• 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.
• 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.
• TSSF Traffic Steering Support Function
• 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.
• Traffic steering server 140 like charging server 120, also implements functionality that is not contemplated in the 3GPP specifications.
• 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.
• Gyt novel interface
• FIG. 2 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.
• charging server 120 includes a central processing unit (CPU) 200, also referred to herein as a processor 200, interconnected with a memory 204.
• CPU central processing unit
• 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).
• 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.
• RAM Random Access Memory
• ROM read only memory
• EEPROM Electrically Erasable Programmable Read Only Memory
• flash memory magnetic computer storage device, or optical disc
• memory 204 includes both volatile and non-volatile storage.
• 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.
• 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.
• 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.
• processor 200 may execute the instructions of one or more such applications in order to perform various operations defined within the instructions.
• 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.
• 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.
• 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.
• MSISDN Mobile Station International Subscriber Directory Number
• IMSI International Mobile Subscriber Identity
• 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.
• Each subscriber record also includes charging data corresponding to the identified mobile device, such as an account balance and one or more usage counters.
• 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 .
• 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.
• quotas e.g. volumes of data reserved for certain applications or services
• lists of services or applications to which each subscriber identifier has access lists of services or applications to which each subscriber identifier has access
• Each subscriber record also contains a network identifier association ("Current Network ID").
• Current Network ID the network identifier association for mobile device 104 is empty; the population of that field will be discussed below in greater detail.
• 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).
• 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.
• 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.
• 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.
• 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.
• processor 250 may execute the instructions of one or more such applications in order to perform various operations defined within the instructions.
• 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.
• 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).
• 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:
• a traffic steering policy 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).
• 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.
• charging server 120 is configured to receive a core session request from gateway server 1 12.
• 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).
• gateway server 1 12 may establish communications with policy server 1 16 to receive the rules mentioned above, before contacting charging server 120.
• 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.
• the request received at block 305 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.
• a subscriber identifier such as a MSISDN, IMSI or the like
• a network identifier e.g. an IP address; typically referred to as a PDP- Address in the context of a Gy session
• 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.
• a core data session e.g. over the Gy interface
• 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.
• 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.
• the request received at block 315 includes at least a network identifier and a traffic steering policy identifier.
• 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.
• 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 .
• 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.
• the request transmitted by traffic steering server 140 can include additional data beyond the network identifier currently assigned to mobile device 104.
• the request can include identifiers of each of the steering functions in the chain defined by the policy record loaded at block 320.
• 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).
• charging server 120 is configured to receive the steering session request from traffic steering server 140.
• 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.
• 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.
• 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.
• 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".
• 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.
• 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.
• 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.
• charging server 120 can initiate charging control on traffic steering activities within network 132.
• traffic steering server 140 controls network 132 to route data associated with mobile device 104 through the appropriate chain of steering functions 136.
• 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.
• 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.
• 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.
• 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.
• quota requests include the volume of data actually consumed as well as a request for additional quota.
• 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.
• 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.
• the request sent at block 405 includes a network identifier currently assigned to the relevant mobile device.
• 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.
• 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.
• 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.
• 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.
• the current time period e.g. the current month
• Charging server 120 may also update usage counters stored in the selected subscriber record to reflect the usage report received at block 410.
• 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.
• 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.
• policy server 1 16 e.g. over the Sy interface
• 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.
• 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.
• CCA Diameter Credit Control Answer
• 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.
• an identifier e.g. a URL
• 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.
• 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.
• the performance of method 400 can be repeated any suitable number of times, until the data session associated with mobile device 104 is terminated.
• Method 500 is performed by charging server 120, via the execution of application 212.
• 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).
• 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.
• 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.
• charging server 120 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.
• traffic steering server 140 may also be implemented in a core network employing offline (i.e. post-pay) charging, instead of or in combination with online charging.
• 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.
• Gzt further interface
• 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).
• 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.
• 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.
• ASICs application specific integrated circuits
• EEPROMs electrically erasable programmable read-only memories

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Mobile Radio Communication Systems (AREA)

Applications Claiming Priority (1)

Publications (1)

Family

ID=60578408

Family Applications (1)

Country Status (3)

Family Cites Families (3)

• 2016
  • 2016-06-09 CN CN201680086638.9A patent/CN109417683B/zh active Active
  • 2016-06-09 WO PCT/IB2016/053414 patent/WO2017212318A1/en unknown
  • 2016-06-09 EP EP16904536.6A patent/EP3469819A1/de not_active Withdrawn

Also Published As

Similar Documents

Legal Events