SYSTEM, DEVICE, AND METHOD OF TRAFFIC DETECTION
CROSS-REFERENCE TO RELATED APPLICATIONS
[001] This application claims priority and benefit from United States Provisional Patent
Application Number 61/680,291, filed on August 7, 2012, which is hereby incorporated by
reference in its entirety.
FIELD
[002] The present invention is related to the field of wireless communication.
BACKGROUND
[003] Many users utilize laptop computers and Personal Computers (PCs) in order to access the
Internet, browse websites on the World Wide Web, send and receive electronic mail (email),
perform online transactions, and engage in various other online activities. Typically, such laptop
computer or PC may be connected to the Internet through a wired link or through a wireless
communication link. For example, a laptop computer may connect to the Internet by utilizing
one or more IEEE 802.1 1 wireless communication standards or protocols ("Wi-Fi"), by utilizing
one or more IEEE 802.16 wireless communication standards or protocols ("Wi-Max"), or by
utilizing other suitable communication standards or protocols.
[004] In the last few years, smartphones have been introduced and have become increasingly
popular. A smartphone is a hybrid mobile device which combines functions of a cellular phone
with functions of a Personal Digital Assistant (PDA). Furthermore, some smartphones may
include, for example, a built-in camera able to capture photographs and video clips, a highresolution
color screen able to playback videos, Global Positioning System (GPS) navigation
capabilities, and/or other advanced features.
SUMMARY
[005] In accordance with the present invention, for example, a cellular traffic monitoring
system comprises: a Traffic Detection Function (TDF) module to monitor cellular traffic
associated with a cellular subscriber device, and to generate application detection output
indicative of an application used by the cellular subscriber device; an application-based charging
module to generate, based on the application detection output of said TDF module, applicationbased
charging data related to said cellular subscriber device; a Policy Charging and
Enforcement Function (PCEF) module to enforce one or more charging rules that are Service
Data Flow (SDF) based and are related to said cellular subscriber device; an SDF-based charging
module to generate SDF-based charging data related to said cellular subscriber device; a
charging correlator module to identify a potential over-charging due to an overlap between the
application-based charging data and the SDF-based charging data.
[006] The system may further comprise: an Application Detection and Control (ADC) module,
associated with said TDF module, to generate an ADC rule indicating an identity of said
application used by the cellular subscriber device; wherein the PCEF module takes into account
said ADC rule for generating SDF-based charging data.
[007] The system may further comprise: a Policy and Charging Rules Function (PCRF) to set a
value of a Charging Method parameter indicating whether application-based charging or SDFbased
charging is to be used in association with cellular traffic of said application used by said
cellular subscriber device.
[008] The system may further comprise: a Policy and Charging Rules Function (PCRF) to set a
value of a Measurement Method parameter indicating a method of measurement for charging to
be used in association with cellular traffic of said application used by said cellular subscriber
device, wherein said value of the Measurement Method parameter indicates to measure charging
in accordance with a charging method selected from the group consisting of: a charging method
based on volume of transferred data, a charging method based on duration of transferred
transfer, a charging method based on both duration and volume of transferred data, and an eventbased
charging method.
[009] The system may further comprise: a Policy and Charging Rules Function (PCRF) to set a
value of a Service Identifier Level Reporting parameter indicating whether separate usage reports
are required to be generated for a current Service Identifier associated with said application used
by said cellular subscriber device.
[0010] The system may further comprise: a Policy and Charging Rules Function (PCRF) set a
value of a Service Identifier parameter identifying said application used by said cellular
subscriber device, wherein said Service Identifier parameter and a rating group value is utilized
via Multiple Services Credit Control (MSCC) per application for application-based charging.
[001 1] The system may further comprise: a Policy and Charging Rules Function (PCRF) to set a
value of a Charging Key parameter indicating a charging tariff to be applied if SDF-based
charging is to be performed.
[0012] The system may further comprise: a Generic Tunneling Protocol (GTP) encapsulator to
mark in downlink direction, within a GTP extension header, an application type associated with
cellular traffic transferred in said downlink direction; wherein the PCEF module comprises a
reflective QoS module to determine, based on said GTP extension header, which cellular packets
belong to said application type and to avoid double-counting of said cellular packets in both
SDF-based charging and application-based charging.
[0013] The system may further comprise: a Differentiated Services Code Point (DSCP) marking
module to mark Internet Protocol (IP) headers of cellular packets that belong to said application
used by the cellular subscriber device, as cellular packets that belong to said application; wherein
the PCEF module comprises a reflective QoS module to determine, based on said IP headers
marked by said DSCP marking module, which cellular packets belong to said application and to
avoid double- counting of said cellular packets in both SDF-based charging and application-based
charging.
[0014] The system may further comprise: a charging method selector to selectively activate or
deactivate an application-based charging module and an SDF-based charging module to prevent
over-charging due to an overlap between the application-based charging data and the SDF-based
charging data.
[0015] The system may further comprise: a packet count adjuster to adjust a count of cellular
packets transferred to said cellular subscriber device, based on output generated by said charging
correlator module, to prevent over-charging due to overlap between the application-based
charging data and the SDF-based charging data.
[0016] The system may utilize a charging algorithm which assumes that the SDF is nondeducible
from the detected application, regardless of whether or not the SDF is deducible from
the detected application.
[0017] The system may further comprise: a Policy and Charging Rules Function (PCRF) to
generate a charging rule in accordance with subscriber data, and to send said charging rule to the
TDF module; wherein the TDF module is to apply said charging rule within an application-based
charging operation.
[0018] The system may further comprise: a Policy and Charging Rules Function (PCRF) to
provide to the TDF module all downlink-direction SDFs that are covered by at least one Policy
Charging and Control (PCC) rule; wherein the TDF module is to enforce a bandwidth limitation
in downlink direction for said downlink-direction SDFs.
[0019] In some implementations, if said downlink-direction SDFs belong to an application that
requires reporting to a charging system, then the TDF module is (a) to obtain a usage monitoring
report about usage of said downlink-direction SDFs, and (b) to utilize said usage monitoring
report to prevent over-charging.
[0020] In some implementations, if said downlink-direction SDFs belong to an application that
requires reporting to a charging system, then the PCRF is to adjust an Application Data and
Control (ADC) rule for said application in downlink direction, to match an enforcement action
defined in one or more PCC Rules for said SDFs belonging to said detected.
[0021] In some implementations, if said downlink-direction SDFs belong to an application that
requires reporting to a charging system, then the TDF module is (a) to obtain Quality of Service
(QoS) information about said downlink-direction SDFs, and (b) to transfer said QoS information
about said downlink-direction SDFs to a charging system together with an application ID
corresponding to said downlink-direction SDFs.
[0022] A method of cellular traffic monitoring may comprise: in a Traffic Detection Function
(TDF) module, monitoring cellular traffic associated with a cellular subscriber device, and
generating application detection output indicative of an application used by the cellular
subscriber device; in an application-based charging module, generating, based on the application
detection output of said TDF module, application-based charging data related to said cellular
subscriber device; in a Policy Charging and Enforcement Function (PCEF) module, enforcing
one or more charging rules that are Service Data Flow (SDF) based and are related to said
cellular subscriber device; in an SDF-based charging module, generating SDF-based charging
data related to said cellular subscriber device; in a charging correlator module, identifying a
potential over-charging due to an overlap between the application-based charging data and the
SDF-based charging data.
[0023] The present invention may provide other and/or additional benefits and/or advantages.
BRIEF DESCRIPTION OF THE DRAWINGS
[0024] For simplicity and clarity of illustration, elements shown in the figures have not
necessarily been drawn to scale. For example, the dimensions of some of the elements may be
exaggerated relative to other elements for clarity of presentation. Furthermore, reference
numerals may be repeated among the figures to indicate corresponding or analogous elements.
The figures are listed below.
[0025] Figs. 1A and IB are schematic block-diagram illustrations of communication systems in
accordance with the present invention.
DETAILED DESCRIPTION
[0026] In the following detailed description, numerous specific details are set forth in order to
provide a thorough understanding of some embodiments. However, it will be understood by
persons of ordinary skill in the art that some embodiments may be practiced without these
specific details. In other instances, well-known methods, procedures, components, units and/or
circuits have not been described in detail so as not to obscure the discussion.
[0027] Applicants have realized that users are increasingly utilizing smartphones in order to
access the Internet and to engage in various types of online activities. Applicants have realized
that it may be beneficial for cellular service providers to detect such Internet utilization which is
performed via smartphones or other mobile devices, and to perform one or more particular
operations in response to such detections. Such operations may include for example, traffic
steering; generation of usage monitoring reports; charging operations; and/or supplemental
services, e.g., content filtering, anti-virus scanning, or the like. Accordingly, the present
invention may include an application-based charging system that utilizes a traffic detection
function.
[0028] In accordance with 3rd Generation Partnership Project (3GPP) communications, that
Policy and Charging Control (PCC) architecture may allow for a Policy and Charging Rules
Function (PCRF) to provide PCC rules for enforcement by a Policy and Charging Enforcement
Function (PCEF). The PCEF may control or authorize Quality of Service (QoS) and may
provide specifications for Service Data Flow (SDF) based charging. Charging parameters may
be transferred within PCC rules for the services which are to be charged. The charging
parameters may include, for example, a Service Identifier (SI) of the SDF(s) in a PCC rule relate
to, the charging key to determine the tariff to apply for the SDF(s), the charging method to be
applied (online charging method, offline charging method, or no charging method to be applied),
and/or a measurement method which indicates whether SDFs' data volume, duration, combined
volume/duration and/or event should be measured. Based on these parameters, the PCEF may
establish sessions with an Online Charging System (OCS) and/or an Offline Charging System
(OFCS) and may provide SDF-based charging.
[0029] The PCC architecture may provide application awareness even when there is no explicit
service level signaling. The application detection and control may be implemented, for example,
by the Traffic Detection Function entity, or by the PCEF enhanced with an Application
Detection and Control (ADC) function. The mechanisms of detection and, in case of solicited
application reporting also the mechanisms of control (e.g., gating, bandwidth limitation,
redirection, and/or usage monitoring per detected application) may be applicable also for
services or applications with non-deducible SDFs. Similar to PCC Rules, ADC Rules may be
defined per each application which is required to be detected and controlled. The PCRF may
correlate PCC Rules and ADC Rules, for the case of TDF-based operation.
[0030] In some PCC implementations, the TDF may implement application detection and
enforcement, whereas the PCEF may implement charging for Internet Protocol Connectivity
Access Network (IP-CAN) session traffic. Applicants have realized that in such
implementations, packets counted in the PCEF may not be delivered to their intended recipient
or destination, due to enforcement actions in the TDF (e.g., gating, bandwidth limitation, and/or
redirection). Applicants have thus devised methods and systems for properly counting traffic
when TDF is involved in enforcement.
[0031] The present invention may utilize a communication system in which the TDF may
perform both application detection and enforcement actions (e.g., gating, bandwidth limitation,
redirection, and/or usage monitoring report to the PCRF 111 about consumed usage per session
or per each one of the detected applications). In such system, the PCEF may perform SDF-based
charging and/or bearer-based charging, and may communicate with the OCS and/or OFCS. The
PCEF may be augmented with ADC capabilities, and may perform functionality which may be
equivalent to or overlapping with the TDF.
[0032] The present invention may provide PCC enhancements in order to support online and
offline charging for the services and applications, particularly when the TDF detects applications
and performs enforcement actions as per ADC Rules (which may be received from the PCRF)
and when the SDFs of the detected application(s) are non-deducible, and thus may not be
transferred from the TDF to the PCEF through the PCRF.
[0033] The present invention may operate in conjunction with an application that has nondeducible
SDFs. For example, each Internet Protocol (IP) based application may utilize one or
more SDF(s), which may change (e.g., in a frequent manner); and such rapidly-changing or
frequently-changing SDFs may not be transferred online to another entity or function in the
system (or, such SDFs may be transferred to another entity in a way that causes the receiving
entity performance to be significantly affected). An application having such SDF(s), may be
referred to herein as an application associated with non-deducible SDF(s).
[0034] Reference is made to Figs. 1A and IB, which are schematic block-diagram illustrations
of a communication system 101A and 101B (respectively) in accordance with the present
invention. System 101A or 101B may be part of, or may be associated with, a cellular
communication network, serving cellular subscriber devices, cellular phones, smartphones,
tablets, or other suitable devices. Such cellular communication network may comprise, for
example, at least one cell site (not shown), which in turn may comprise at least one cell radio
(not shown). System 101A shows some of the main components or modules; whereas system
101B shows additional and/or optional components and/or modules. Components or modules
that are discussed herein with reference to system 101B, may also be comprised in, or used by,
system 101A; and vice versa.
[0035] System 101B may comprise, for example, a Policy and Charging Rules Function (PCRF)
111, which may communicate with a Subscription Profile Repository (SPR) 112 and an
Application Function (AF) 113, as well as with a Bearer Binding and Event Reporting Function
(BBERF) 114, a Traffic Detection Function (TDF) 115, and a gateway 150. PCRF 111 may
further communicate (e.g., directly) with an Online Charging System (OCS) 117; and may
further communicate with an Offline Charging System (OFCS) 118 (e.g., indirectly, via gateway
150). Each one of the components of system 101B may be implemented by utilizing suitable
hardware components and/or software components, for example, processors, memory units,
storage units, network elements, transmitters, receivers, transceivers, modems, wireless radios,
antennas, Operating System (OS), applications, or the like.
[0036] Policy and Charging Rules Function (PCRF) 111 may aggregate data about network
traffic, may take into account data from Subscription Profile Repository (SPR) 112 (or from
other suitable Subscriber Profile Database (SPDB) unit), and may generate subscriber-specific
traffic-handling rules and/or subscriber-specific traffic-handling decisions. Such subscriberspecific
rules may be provided by PCRF 111 to TDF 115, to service gateway 150, and to a
Policy and Enforcement Charging Function (PCEF) 151 which may be internal to service
gateway 150 or external thereto.
[0037] In conjunction with such subscriber-specific rules and/or decisions, Traffic Detection
Function (TDF) 115 may detect an application that a particular subscriber may be running, and
may enforce traffic-handling rules or other suitable rules (e.g., charging, supplemental services,
or the like), optionally utilizing other network elements (e.g., service gateway 150, and/or PCEF
151). TDF 115 may operate by utilizing ADC Rules received from PCRF 111.
[0038] PCEF 151 may enforce the PCC rules on SDF level, and optionally may perform
charging on SDF level.
[0039] Gateway 150 may be a cellular gateway or other suitable service gateway or network
element; and may comprise, for example, PCEF 151, as well as a Deep Packet Inspection (DPI)
module 152 able to inspect packets and identify an application being use.
[0040] System 101B may further include, optionally, an extended Application Detection and
Control (ADC) Rules function 155, able to implement application-based charging.
[0041] System 101B may further comprise, optionally, a Subscriber Management Platform
(SMP) 156 for obtaining the ADC Rules and reporting further to other system components (e.g.,
to PCRF 111, to OCS 117, to OFCS 118). In some implementations, TDF 115 may be
implemented as a combination of SMP 156 and gateway 150.
[0042] Components of system 101B, and particularly, TDF 115 and/or PCRF 111, may utilize
Enhanced ADC Rules which may be determined or generated by Enhanced ADC Rules Function
155, and may enable application-based charging (e.g., in addition to parameters defined in 3GPP
TS 23.203).
[0043] The Enhanced ADC Rules may comprise, for example, charging rules and parameters
enabling to define identities and instructions for charging and accounting, which may be used by
an access point where application-based charging is configured. For example, a Charging Key
parameter may be used by a charging system (e.g., OCS 117 and/or OFCS 118) to determine the
tariff to apply for an application that is subject to application-based charging.
[0044] The Enhanced ADC Rules may comprise, for example, Application Identifier or Service
Identifier rules or parameter(s), indicating the identity of an application and/or service being used
by the subscriber and being subject to application-based charging and/or to SDF-based charging.
Application Identifier parameters or Service Identifier parameters may comprise, for example, a
Charging Method parameter indicating a required charging method for the applicable ADC Rule
(e.g., online application-based charging, offline application-based charging, or no applicationbased
charging). Additionally, a Measurement Method parameter may indicate whether the
application data volume, duration, combined volume/duration, and/or event is (or are) to be
measured, for application-based charging purposes (this may be applicable for reporting, if the
charging method is online or offline; whereas event-based charging may be applicable to pre
defined ADC rules). Additionally, a Service Identifier Level Reporting parameter may indicate
that separate usage reports are to be generated for the current Service Identifier, e.g., having a
binary value of "required" (or mandated) or "not required").
[0045] The Service Identifier may be implemented as a new parameter which may be transferred
to the charging system (e.g., to OCS 117 and/or OFCS 118) within Multiple Services Credit
Control (MSCC) per each application (e.g., instead of Service Identifier) for application-based
charging. In some implementations, if there is at least one ADC Rule that contains or refers to
charging parameters, then the session with OCS 117 or OFCS 118 may need to be established by
the TDF.
[0046] Some implementations may operate to ensure that over-charging is not performed, even if
both PCEF 151 and TDF 115 report for charging (e.g., to OCS 117 and/or to OFCS 118). Some
components of system 101B may assume that the SDF(s) of the detected application (e.g.,
detected by TDF 115) are non-deducible; however, this does not necessarily preclude that TDF
115 is actually aware of those SDF(s). Some implementations may assume that some of the
SDF(s), that are enforced by PCEF 151 based on PCC Rules received from PCRF 111, belong
also to the application detected and enforced by TDF 115; otherwise, there may not be a need to
correlate charging reports, as no over-charging would be performed even if PCEF 151 and TDF
115 both report for charging.
[0047] In accordance with the present invention, system 101B may utilize a charging model per
session which may require one of the following: (a) only application usage charging is required
for the corresponding IP-CAN session; or (b) only SDF-based charging is required for the
corresponding IP-CAN session; or (c) both SDF-based charging and application usage charging
are required for the corresponding IP-CAN session. Each one of these alternative requirements
may trigger a different set of operations, as described herein.
[0048] If only application usage charging is required for the corresponding IP-CAN session, then
the following operations may be used. For event-based charging, there is no need to perform
charging correlation, as, for example, Application ID or an Application instance ID number is
reported. For time-based charging, there is no need to perform charging correlation, as time per
application usage (or time per SDF usage) is to be reported to the charging system(s). For
volume -based charging, or for time-and-volume based charging, the following may be
performed: In the uplink direction, TDF 115 may receive correct information as packets pass
through TDF 115 after any possible enforcement action done by PCEF 151. In order to charge
for correct downlink information, PCRF 111 may provide to TDF 115 all the SDFs that are part
of PCC Rules, in case there is any bandwidth limitation in the downlink direction for those SDFs
(otherwise, this operation may not be required, as TDF 115 may correctly perform the charging).
If those SDFs belong also to the application which needs to be reported to the charging systems,
then TDF 115 may request from PCRF 111 (and in turn, PCRF may request from PCEF 151) to
provide usage monitoring report about those SDFs usage, and the monitoring report may be
reported back from PCEF 151 through PCRF 111 to TDF 115. Accordingly, TDF 115 may have
correct information about usage, and may send to OCS 117 and/or to OFCS 118 accurate reports
without over-charging. Alternatively, PCRF 111 may adjust the ADC Rules for the application in
the downlink direction, if appropriate, to match the same enforcement action as defined in the
PCC Rules for the SDFs, belonging to the detected application. Optionally, PCRF 111 may
transfer to TDF 115 also full QoS-information for those SDFs, and thus TDF 115 may also
transfer the QoS information to the charging systems (OCS 117 and/or OFCS 118) along with
the Application ID to mention the SDF(s) belonging to it (which are enforced in downlink
direction by PCEF 151). In this case, TDF 115 is the exclusive charging reporting entity. The
charging for all applications may be performed by using charging parameters within the ADC
Rules.
[0049] If only SDF usage charging is required for the corresponding IP-CAN session, then the
following operations may be performed. For event-based charging, there is no need to perform
charging correlation, and event-based SDF reporting may be used. For time-based charging,
there is no need to perform charging correlation, and time-based SDF reporting may be used.
For volume-based charging, or for time-and-volume based charging, the following operations
may be performed. In the downlink direction, PCEF 151 obtains correct information as packets
pass through PCEF 111 after any possible enforcement action done by TDF 115. In order to
charge correctly for uplink information, PCRF 111 may provide to TDF 115 all the SDFs that are
part of PCC Rules. In case one or more of those SDFs belong to detected application(s), then the
following may be performed. If there is any bandwidth limitation or gating or redirection in the
uplink direction for those SDFs as a part of the enforced application (otherwise, no need for this
operation as PCEF 151 may correctly perform the charging), then TDF 115 informs PCRF 111
by providing those SDFs belonging to the application with their enforcement action, and/or with
an indication of which ADC Rule(s) they belong to. PCRF 111 may then adjust the enforcement
and charging model for PCEF 151 by, for example, creating one or more new PCC Rule(s) for
those SDFs with a higher priority. If zero charging is detected (e.g., in case of redirection), then
the bandwidth limitation of those SDFs may be adjusted to the values provided to TDF 115 per
application (i.e., per the application that includes, or is assumed to include, those SDFs).
Accordingly, PCEF 151 may have correct information about usage, and may send to OCS 117
and/or to OFCS 118 accurate charging reports without over-charging. In this case, PCEF 151 is
the only charging reporting entity. The charging for all PCC Rules may be performed by
utilizing SDF charging principles.
[0050] If both SDF-based charging and application usage charging are required for the
corresponding IP-CAN session, then the following operations may be performed. For eventbased
charging, there is no need for charging correlation, and system 10 IB may utilize eventbased
SDF reporting and application-based charging for Application Instance identifier events.
For time-based charging, there is no need for charging correlation, as the PCC Rules may include
also other SDFs and the detected application may also include one or more other SDFs; and
therefore the effective time measured for PCC and/or ADC Rule is not affected. For volumebased
charging, or for volume-and-time based charging, the following set of operations may be
performed. Firstly, PCC Rules for SDF-based charging may be provided (e.g., by PCRF 111) to
PCEF 151, and ADC Rules for application-based charging may be provided (e.g., by PCRF 111)
to TDF 115. Then, PCRF 111 may provide to TDF 115 all the SDFs from the corresponding
PCC Rules. If some of those SDFs belong to the detected application, which needs to be
enforced and/or charged, then the following operations may be performed, described herein with
regard to the uplink direction and the downlink direction
[005 1] In the uplink direction, if TDF 115 performs enforcement actions but does not need to
charge per this specific application, in order to correlate for the impacted SDFs, TDF 115 may
inform PCRF 111 by providing those SDFs belonging to application with their enforcement
action and/or with indication of which ADC Rule(s) they belong to. Then, PCRF 111 may adjust
the enforcement and charging model for PCEF 151, for example, by creating one or more new
PCC rule(s) for those SDFs with a higher priority; and in case of zero charging (e.g., in case of
redirection), adjusting bandwidth limitation of those SDFs to the values provided to TDF 115 per
application which includes (or is assumed to include) those SDFs. Thus, PCEF 151 may have
correct information about usage, and may send to OCS 117 and/or to OFCS 118 correct reports
without over-charging. However, this does not necessarily preclude charging of PCEF 151 for
any additional PCC Rules which do not include those SDFs and any applications for the same IPCAN
session.
[0052] In the uplink direction, if TDF 115 performs enforcement actions and needs to charge per
this specific application, then TDF 115 may inform PCRF 111 by providing those SDFs
belonging to application with their enforcement action and/or indication of which ADC Rule(s)
they belong to. Then, PCRF 111 may adjust the enforcement and charging model for PCEF 151,
for example, by creating one or more new PCC rule(s) for those SDFs with a higher priority; and
when having zero charging (e.g., in case of redirection), adjusting bandwidth limitation of those
SDFs to the values provided to TDF 115 per application which include (or are assumed to
include) those SDFs. Then, PCRF 111 may signal to TDF 115 whether or not those SDFs should
be counted for application-based; an indication not to count for application-based charging
means that those SDFs are to be counted within PCC Rules only. Optionally, such indication
may also be part of ADC Rule. If those SDFs are to be counted by TDF 115, and PCRF 111
adjusted the PCC Rules for those SDFs, then charging is correctly performed. Otherwise, if
SDFs need to be excluded from TDF's 115 counting per application, then TDF 115 may provide
application-based charging for all accumulated traffic excluding the SDFs that are also reported
by PCC Rules.
[0053] In the downlink direction, if PCEF 151 performs enforcement actions per PCC Rules
with the affected SDFs, but does not need to charge per this specific SDF, then PCRF 111 may
provide to TDF 115 all SDFs that are part of PCC Rules, in case there is any enforcement action
(e.g., bandwidth limitation) in the downlink direction for those SDFs (otherwise, no need for this
operation as TDF 115 may correctly perform charging). If those SDFs belong also to the
application which needs to be reported, then TDF 115 may request from PCRF 111 (which in
turn may request from PCEF 151) to provide usage monitoring report about those SDFs usage;
and PCEF 151 may provide such usage monitoring report via PCRF 111 to TDF 115. Thus,
TDF 115 may have correct information about usage, and may send to OCS 117 and/or to OFCS
118 correct charging reports without over-charging. Alternatively, PCRF 111 may adjust ADC
Rules for the application in the downlink direction, if appropriate, to match the same
enforcement action as defined in PCC Rules for the SDFs belonging to the detected application.
Optionally, PCRF 111 may transfer to TDF 115 also full QoS-Information for those SDFs, and
thus TDF 115 may also transfer the full QoS Information to OCS 117 (along with Application ID
to mention the SDFs belonging to it (which are enforced in the downlink direction by PCEF 151)
with their QoS-Information). This may not necessarily preclude charging of PCEF 151 for any
additional PCC Rules which do not include such SDF and any applications for the same IP-CAN
session.
[0054] In the downlink direction, if PCEF 151 performs enforcement actions and needs to charge
per this specific SDF, then PCRF 111 may provide to TDF 115 all SDFs which are part of
affected PCC Rules. If those SDFs belong also to the application which needs to be reported,
then TDF 115 may request from PCRF 111 (which, in turn, may request from PCEF 151) to
provide usage monitoring report; and PCEF 151 may provide the usage monitoring report via
PCRF 111 to TDF 115, about those SDFs usage. Thus, TDF 115 may have correct information
about usage, and may send to OCS 117 and/or to OFCS 118 correct charging reports without
over-charging. Alternatively, PCRF 111 may adjust ADC Rules for the application in the
downlink direction, if appropriate, to match the same enforcement action as defined in PCC
Rules for the SDF(s) belonging to the detected application. Optionally, PCRF 111 may transfer
to TDF 115 also full QoS-Information for those SDFs, and TDF 115 may also transfer the full
QoS Information to OCS 117 (along with the Application ID to mention the SDF(s) belonging to
it (which may be enforced in the downlink direction by PCEF 151) with their respective QoSInformation).
[0055] Other suitable sets of operations, or conditions or parameters, may be used such that
PCRF 111 may control and ensure that TDF 115 and/or PCEF 151 correctly report the charging
for those SDFs that are supposed to be charged by both of these module, but without doublecharging
or over- charging.
[0056] Optionally, system 101B may comprise a charging correlator 161, which me be
implemented, for example, as a stand-alone unit or module able to communicate with other
component(s) of system 101B, as part of PCRF 111, as part of OCS 117, or as part of OFCS 118.
In some implementations, for example, charging correlator 161 may correlate or perform
adjustment to data generated by, or utilized by, an application-based charging module 182 (e.g.,
which may be associated with TDF 115) and/or an SDF-based charging module 181 (e.g., which
may be associated with PCEF 151). Optionally, charging correlator 161 may utilize other
modules or elements, for example, packet count adjuster 174 described herein.
[0057] In a demonstrative example, correlation of charging reports may be performed by PCRF
111, which may optionally comprise charging correlator 161. For example, PCRF 111 may
provide PCC Rules for SDF-based charging to PCEF 151, and may provide ADC-based Rules
for application-based charging to TDF 115. The ADC-based charging rules may begin to be
enforced only when an application is detected to be running on the subscriber's device. Since
the SDFs of the application may be non-deducible (and thus PCRF 111 may not recognize them),
in order to avoid double-charging or over-charging, only charging models where either SDFbased
charging or application-based charging may be enabled, but not both charging models
simultaneously. In the uplink direction, TDF 115 may perform enforcement action per detected
application (e.g., traffic gating, traffic shaping, traffic redirection), and if such enforcement
action is required, then system 101B may switch from SDF-based charging to application-based
charging upon application detection. PCRF 111 may ensure there is no overlap or over
charging; such as, when an application that needs to be charged is detected, the charging is
switched off for PCC Rules (i.e., for charging on the SDF level). In this method, both PCEF 151
and TDF 115 may provide charging reports to the charging system(s), and PCRF 111 may ensure
that double-charging is avoided.
[0058] Alternatively, correlation of charging reports may be performed by the charging
system(s), for example, by OCS 117 and/or OFCS 118; which may optionally utilize charging
correlator 161 for this purpose. For example, PCRF 111 may provide PCC Rules for SDF-based
charging to PCEF 151, and may provide ADC Rules for application-based charging to TDF 115.
The ADC charging rules may begin to be enforced only when an application is detected to be
running on the subscriber's device. The SDFs of the application may be non-deducible (and thus
PCRF 111 may not be aware of them), and thus, in order to avoid double charging or ov er
charging, only charging models where either SDF-based charging or application-based charging
may be enabled, but not both charging models simultaneously. In the uplink direction, TDF 115
may perform enforcement action per detected application (e.g., traffic gating, traffic shaping,
traffic redirection), and thus, if such enforcement action is required, system 101B may switch
from SDF-based charging to application-based charging upon application detection. This may be
done by OCS 117 and/or by OFCS 118; for example, starting at the point in time (e.g., by using
timestamp) in which charging request per application is received, then charging per SDF is
ignored or discarded via a discarding module 173 (e.g., which may be part of OCS 117 and/or
OFCS 118, or may be associated with such components). In this method, both PCEF 151 and
TDF 115 may provide charging reports, and the charging system(s), for example, OCS 117
and/or OFCS 118 may operate to avoid double-charging or over-charging.
[0059] System 101B may report the monitored usage, per detected application, via a suitable
route of components; for example, a report request going from TDF 115 to PCRF 111 to PCEF
151, and, a report response going from PCEF 151 to PCRF 111 to TDF 115; optionally utilizing
a monitored usage reporting module 172 (e.g., which may be part of PCEF 151 and/or PCRF
111, or may be associated therewith). For example, PCRF 111 may inform TDF 115 about
SDF(s) reported for charging by PCEF 151. In response, or at any point of time subsequently, if
those SDF(s) belong to one or some of the detected applications, then TDF 115 may request
(indirectly through PCRF 111) to receive from PCEF 151 (indirectly through PCRF 111) report
usage monitoring per those SDF(s). Usage monitoring may be performed and/or reported by
volume, by time, or by volume -per-time. Usage monitoring and/or reporting may also be done on
demand, for example, every time that TDF 115 has to report application-based charging to
charging function(s). When reporting to the charging function(s) (e.g., to OCS 117 and/or OFCS
118), TDF 115 may reduce SDF volume/time, as reported by usage monitoring, and may thus
provide accurate information per application(s). In this method, both PCEF 151 and TDF 115
may provide charging reports.
[0060] Optionally, system 10 IB may utilize Sy interface enhancements to carry application-level
reports, for example, from TDF 115 through PCRF 111 to OCS 117. For example, both PCEF
151 and TDF 115 may report (based on SDF and/or on application level). Sy interface may be
extended with usage monitoring report from PCRF 111 to OCS 117 per detected application(s)
and/or per SDF(s). It may be required to report to OCS 117 if the SDF(s) are also part of the
detected application's traffic. Then, OCS 117 may reduce or deduct the SDF(s) reported, from
the total application's consumed traffic amount, thereby avoiding or preventing double-charging
or over-charging. In this method, both PCEF 151 and TDF 111 may provide charging reports.
[0061] System 10 IB may optionally utilize a tunneling protocol, which may be defined,
established and utilized between PCEF 151 and TDF 115. In the downlink direction, TDF 115
may mark (e.g., by using an optional tunneling marker module 176) all IP packets belonging to
the detected application, by using a field dedicated for this purpose in the tunneling protocol
header. Then, PCEF 151 may, for example, utilize reflective QoS functionality (e.g., by
utilizing an optional Reflective QoS module 177), and may detect which IP packets belong to the
detected application, thereby avoiding an over-count or double-count of those IP packets while
reporting SDF-based charging and/or application-based charging. In this method, PCEF 151
may be the only enforcing and also charging reporting entity, and TDF 115 may not report
charging.
[0062] System 10 IB may optionally utilize an extended or improved version of Generic
Tunneling Protocol (GTP) encapsulation, for example, in case of TDF 115 deployment in
network(s). For example, GTP extension header for Service Identification for RRC
Improvements in GERAN (SIRIG) (3GPP R-l 1) may be utilized (e.g., by using an optional GTP
Encapsulator 178) to mark the application type in the downlink. Then, PCEF 151 may utilize
reflective QoS functionality to determine which packets belong to the detected application,
thereby avoiding packet over-count or packet double-count while reporting SDF-based charging
and/or application-based charging. In this method, PCEF 151 may be the only enforcing and
also charging reporting entity, and TD 115 may not report charging.
[0063] System 10 IB may optionally re-use Differentiated Services Code Point (DSCP) values
for packet marking. For example, each ADC rule that is provided to TDF 115, may insert or
may include a DSCP value (e.g., by using an optional DSCP marking module 179) to mark
packets belonging to specific application in the IP header. The ADC Rules may not include
enforcement actions. TDF 115 may report to PCRF 111 about the detected application, and
PCRF 111 may inform PCEF 151 which DSCP value in the IP header corresponds to which
detected application. PCEF 151 may utilize reflective QoS functionality to detect which packets
belong to the detected application in the uplink direction, thereby avoiding packet over-count or
packet double-count while reporting SDF-based charging and/or application-based charging. In
this method, PCEF 151 may be the only enforcing and also charging reporting entity, and TD
115 may not report charging.
[0064] The present invention may utilize one or more dedicated modules, which may be stand
alone modules or may be integrated within other component(s) of system 101B (e.g., within
PCRF 111, within TDF 115, within PCEF 115). Such optional modules or functions may
include, for example, a charging method selector 171 able to select, activate or de-activate
charging method(s), or able to enable/disable SDF-based charging, or able to enable/disable
application-based charging. Such optional modules or functions may include, for example, a
packet count adjuster 174 able to adjust, modify, increase or decrease packet count, for example,
in OCS 117 and/or in OFCS 118, in order to compensate for (or prevent) double-counted packets
due to carrying on of both SDF-based charging and application-based charging. Other suitable
modules or functions may be used.
[0065]
[0066] It is noted that the drawings may show demonstrative implementations of links, interfaces
and/or connections; yet other suitable links, interfaces or connections may be used in accordance
with the present invention. For example, Gyn interface may be used instead of Gy interface; Gzn
interface may be used instead of Gz interface; or the like.
[0067] The present invention may be implemented by using any suitable combination of
hardware components and/or software modules; and may utilize, for example, processors,
controllers, Integrated Circuits (ICs), logic units, memory units, storage units, buffers, modems,
radios, transmitters, receivers, transmitters, wireless communication units, wired communication
units, cellular communication units, routers, hubs, switches, antennas, power sources, distributed
architecture, client/server architecture, peer-to-peer architecture, Operating Systems, drivers,
firmware, software applications, stand-alone units or systems, integrated system or units, or any
suitable combination thereof.
[0068] Functions, operations, components and/or features described herein with reference to one
or more embodiments, may be combined with, or may be utilized in combination with, one or
more other functions, operations, components and/or features described herein with reference to
one or more other embodiments, or vice versa.
[0069] While certain features of some embodiments of the present invention have been
illustrated and described herein, many modifications, substitutions, changes, and equivalents may
occur to those skilled in the art. Accordingly, the claims are intended to cover all such
modifications, substitutions, changes, and equivalents.

CLAIMS
What is claimed is:
1. A cellular traffic monitoring system comprising:
a Traffic Detection Function (TDF) module to monitor cellular traffic associated with a
cellular subscriber device, and to generate application detection output indicative of an
application used by the cellular subscriber device;
an application-based charging module to generate, based on the application detection
output of said TDF module, application-based charging data related to said cellular
subscriber device;
a Policy Charging and Enforcement Function (PCEF) module to enforce one or more
charging rules that are Service Data Flow (SDF) based and are related to said cellular
subscriber device;
an SDF-based charging module to generate SDF-based charging data related to said
cellular subscriber device;
a charging correlator module to identify a potential over-charging due to an overlap
between the application-based charging data and the SDF-based charging data.
2. The system of claim 1, further comprising:
an Application Detection and Control (ADC) module, associated with said TDF module, to
generate an ADC rule indicating an identity of said application used by the cellular
subscriber device;
wherein the PCEF module takes into account said ADC rule for generating SDF-based
charging data.
3. The system of claim 1, further comprising:
a Policy and Charging Rules Function (PCRF) to set a value of a Charging Method
parameter indicating whether application-based charging or SDF-based charging is to be
used in association with cellular traffic of said application used by said cellular subscriber
device.
4. The system of claim 1, further comprising:
a Policy and Charging Rules Function (PCRF) to set a value of a Measurement Method
parameter indicating a method of measurement for charging to be used in association with
cellular traffic of said application used by said cellular subscriber device, wherein said
value of the Measurement Method parameter indicates to measure charging in accordance
with a charging method selected from the group consisting of:
a charging method based on volume of transferred data,
a charging method based on duration of transferred transfer,
a charging method based on both duration and volume of transferred data, and
an event-based charging method.
5. The system of claim 1, further comprising:
a Policy and Charging Rules Function (PCRF) to set a value of a Service Identifier Level
Reporting parameter indicating whether separate usage reports are required to be generated
for a current Service Identifier associated with said application used by said cellular
subscriber device.
6. The system of claim 1, further comprising:
a Policy and Charging Rules Function (PCRF) set a value of a Service Identifier parameter
identifying said application used by said cellular subscriber device, wherein said Service
Identifier parameter and a rating group value is utilized via Multiple Services Credit
Control (MSCC) per application for application-based charging.
7. The system of claim 1, further comprising:
a Policy and Charging Rules Function (PCRF) to set a value of a Charging Key parameter
indicating a charging tariff to be applied if SDF-based charging is to be performed.
8. The system of claim 1, further comprising:
a Generic Tunneling Protocol (GTP) encapsulator to mark in downlink direction, within a
GTP extension header, an application type associated with cellular traffic transferred in
said downlink direction;
wherein the PCEF module comprises a reflective QoS module to determine, based on said
GTP extension header, which cellular packets belong to said application type and to avoid
double-counting of said cellular packets in both SDF-based charging and application-based
charging.
9. The system of claim 1, further comprising:
a Differentiated Services Code Point (DSCP) marking module to mark Internet Protocol
(IP) headers of cellular packets that belong to said application used by the cellular
subscriber device, as cellular packets that belong to said application;
wherein the PCEF module comprises a reflective QoS module to determine, based on said
IP headers marked by said DSCP marking module, which cellular packets belong to said
application and to avoid double-counting of said cellular packets in both SDF-based
charging and application-based charging.
10. The system of claim 1, further comprising:
a charging method selector to selectively activate or deactivate an application-based
charging module and an SDF-based charging module to prevent over-charging due to an
overlap between the application-based charging data and the SDF-based charging data.
11. The system of claim 1, further comprising:
a packet count adjuster to adjust a count of cellular packets transferred to said cellular
subscriber device, based on output generated by said charging correlator module, to prevent
over-charging due to overlap between the application-based charging data and the SDFbased
charging data.
12. The system of claim 1, wherein the system utilizes a charging algorithm which assumes
that the SDF is non-deducible from the detected application, regardless of whether or not
the SDF is deducible from the detected application.
13. The system of claim 1, further comprising:
a Policy and Charging Rules Function (PCRF) to generate a charging rule in accordance
with subscriber data, and to send said charging rule to the TDF module;
wherein the TDF module is to apply said charging rule within an application-based
charging operation.
14. The system of claim 1, further comprising:
a Policy and Charging Rules Function (PCRF) to provide to the TDF module all downlinkdirection
SDFs that are covered by at least one Policy Charging and Control (PCC) rule;
wherein the TDF module is to enforce a bandwidth limitation in downlink direction for said
downlink-direction SDFs.
15. The system of claim 14, wherein, if said downlink-direction SDFs belong to an application
that requires reporting to a charging system, then the TDF module is (a) to obtain a usage
monitoring report about usage of said downlink-direction SDFs, and (b) to utilize said
usage monitoring report to prevent over-charging.
16. The system of claim 14, wherein, if said downlink-direction SDFs belong to an application
that requires reporting to a charging system, then the PCRF is to adjust an Application Data
and Control (ADC) rule for said application in downlink direction, to match an
enforcement action defined in one or more PCC Rules for said SDFs belonging to said
detected.
17. The system of claim 14, wherein, if said downlink-direction SDFs belong to an application
that requires reporting to a charging system, then the TDF module is (a) to obtain Quality
of Service (QoS) information about said downlink-direction SDFs, and (b) to transfer said
QoS information about said downlink-direction SDFs to a charging system together with an
application ID corresponding to said downlink-direction SDFs.
18. A method of cellular traffic monitoring, the method comprising:
in a Traffic Detection Function (TDF) module, monitoring cellular traffic associated with a
cellular subscriber device, and generating application detection output indicative of an
application used by the cellular subscriber device;
in an application-based charging module, generating, based on the application detection
output of said TDF module, application-based charging data related to said cellular
subscriber device;
in a Policy Charging and Enforcement Function (PCEF) module, enforcing one or more
charging rules that are Service Data Flow (SDF) based and are related to said cellular
subscriber device;
in an SDF-based charging module, generating SDF-based charging data related to said
cellular subscriber device;
in a charging correlator module, identifying a potential over-charging due to an overlap
between the application-based charging data and the SDF-based charging data.