Patent Description:
Mobile devices or User Equipment (UE), such as a smart phone with data communication capabilities, can automatically establish a data session with telecommunication networks. A UE may have an "always-on" connection with the network, which means that one or more data sessions are activated. For a data session, an individual UE may initiate a large number of data services depending on the number of software applications executing thereon. A UE may attempt to establish data services when the network policy and charging control policy doesn't allow for establishment of the data services, which may lead to rejection of the data services. For example, a UE may request a data service when the billing account associated with the UE does not have a sufficient balance to support the requested service. Frequent requests or repeated attempts to initiate data services and rejections thereof may impose a significant burden on the resources of the network, as well as those of the UEs. For example, smart phones may initiate thousands (e.g. <NUM>-<NUM>) of service requests per day that result in denial of the data service. It is therefore desirable to control whether data services are available to a UE.

<CIT> discloses a process implemented by a proxy-based system for triggering an upper layer congestion control mechanism at a mobile device based on one or more access barring messages received from a host server. 3GPP standardization is provided in "<NPL>.

Embodiments described herein set forth a network-initiated Packet Switch (PS) Data off feature where the network activates a PS Data off feature for one or multiple UEs. A network element may monitor network traffic load, subscriber account status, location of the UE, and/or other network service conditions to determine when to activate a PS Data off feature for a UE. The network element then generates a PS Data off request that is sent to other devices, such as other network elements and the UE, to invoke the PS Data off feature for the UE. By initiating the PS Data off feature in the network, the network may save network resources and avoid unnecessary control signaling caused by repeated attempts to access data services that are not authorized for the UE.

One embodiment comprises a network element implemented in a network that provides one or more data services to a UE. The network element includes a processor (or multiple processors) and a memory that cause the network element to store a data off policy that triggers activation or deactivation of a PS Data off feature for the UE, to determine whether to activate the PS Data off feature for the UE based on the data off policy and one or more network service conditions, to generate a first PS Data off request to activate the PS Data off feature for the UE responsive to a determination to activate the PS Data off feature, and to initiate transmission of the first PS Data off request for receipt by a gateway of the network that acts as an entry point for downlink traffic for the UE.

In another embodiment, the processor and memory cause the network element to initiate transmission of the first PS Data off request for receipt by the UE.

In another embodiment, the processor and the memory cause the network element to determine whether to deactivate the PS Data off feature for the UE based on the data off policy and the network service conditions, to generate a second PS Data off request to deactivate the PS Data off feature for the UE responsive to a determination to deactivate the PS Data off feature, and to initiate transmission of the second PS Data off request for receipt by the gateway.

In another embodiment, the processor and the memory cause the network element to initiate transmission of the second PS Data off request for receipt by the UE.

In another embodiment, the processor and the memory cause the network element to generate (as part of the first PS Data off request) a NE-Initiated PS Data Off Status indicating whether the PS Data off feature is activated or deactivated, a NE-Initiated PS Data Off Exempt Service List indicating at least one data service that is exempt from the PS Data off feature, and a NE-Initiated PS Data Off Reason indicating a basis for activating or deactivating the PS Data off feature by the network element.

In another embodiment, the processor and the memory cause the network element to generate the NE-Initiated PS Data Off Exempt Service List based on the data off policy.

In another embodiment, the network element comprises an online charging system for the network.

In another embodiment, the network element comprises a policy control element for the network.

Another embodiment comprises a method of controlling a PS Data off feature at a network element of a network that provides one or more data services to a UE. The method comprises storing a data off policy that triggers activation or deactivation of the PS Data off feature for the UE, determining whether to activate the PS Data off feature for the UE based on the data off policy and one or more network service conditions, generating a first PS Data off request to activate the PS Data off feature for the UE responsive to a determination to activate the PS Data off feature, and initiating transmission of the first PS Data off request for receipt by a gateway of the network that acts as an entry point for downlink traffic for the UE.

In another embodiment, the method further comprises initiating transmission of the first PS Data off request for receipt by the UE.

In another embodiment, the method further comprises determining whether to deactivate the PS Data off feature for the UE based on the data off policy and the network service conditions, generating a second PS Data off request to deactivate the PS Data off feature for the UE responsive to a determination to deactivate the PS Data off feature, and initiating transmission of the second PS Data off request for receipt by the gateway.

In another embodiment, the method further comprises initiating transmission of the second PS Data off request for receipt by the UE.

In another embodiment, generating the first PS Data off request comprises generating a NE-Initiated PS Data Off Status indicating whether the PS Data off feature is activated or deactivated, generating a NE-Initiated PS Data Off Exempt Service List indicating at least one data service that is exempt from the PS Data off feature, and generating a NE-Initiated PS Data Off Reason indicating a basis for activating or deactivating the PS Data off feature by the network element.

In another embodiment, generating the NE-Initiated PS Data Off Exempt Service List comprises generating the NE-Initiated PS Data Off Exempt Service List based on the data off policy.

Another embodiment comprises a network element of a network that provides one or more data services to a UE. The network element comprises a means for storing a data off policy that triggers activation or deactivation of a PS Data off feature for the UE, a means for determining whether to activate the PS Data off feature for the UE based on the data off policy and one or more network service conditions, a means for generating a first PS Data off request to activate the PS Data off feature for the UE responsive to a determination to activate the PS Data off feature, and a means for initiating transmission of the first PS Data off request for receipt by a gateway of the network that acts as an entry point for downlink traffic for the UE.

In another embodiment, the network element includes a means for initiating transmission of the first PS Data off request for receipt by the UE.

In another embodiment, the network element includes a means for determining whether to deactivate the PS Data off feature for the UE based on the data off policy and the network service conditions, a means for generating a second PS Data off request to deactivate the PS Data off feature for the UE responsive to a determination to deactivate the PS Data off feature, and a means for initiating transmission of the second PS Data off request for receipt by the gateway.

In another embodiment, the network element includes a means for initiating transmission of the second PS Data off request for receipt by the UE.

Other embodiments may include computer readable media, other systems, or other methods as described below.

The above summary provides a basic understanding of some aspects of the specification. This summary is not an extensive overview of the specification. It is intended to neither identify key or critical elements of the specification nor delineate any scope of the particular embodiments of the specification, or any scope of the claims. Its sole purpose is to present some concepts of the specification in a simplified form as a prelude to the more detailed description that is presented later.

Some embodiments of the invention are now described, by way of example only, and with reference to the accompanying drawings.

The figures and the following description illustrate specific exemplary embodiments. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the embodiments and are included within the scope of the embodiments. Furthermore, any examples described herein are intended to aid in understanding the principles of the embodiments, and are to be construed as being without limitation to such specifically recited examples and conditions. As a result, the inventive concept(s) is not limited to the specific embodiments or examples described below, but by the claims and their equivalents.

<FIG> illustrates a communication network <NUM>. Communication network <NUM> is a cellular network or mobile network where the last link is wireless, and provides voice and/or data services to a plurality of devices. Communication network <NUM> may be a Third Generation (<NUM>) network, a Fourth Generation (<NUM>) network (e.g., Long-Term Evolution (LTE)), or a next generation network (e.g., <NUM>).

Communication network <NUM> is illustrated as providing communication services (i.e., voice and/or data services) to UE <NUM> and other UEs not shown. UE <NUM> is enabled for voice and/or data services. For example, UE <NUM> may be an end user device such as a mobile phone (e.g., smartphone), a tablet or PDA, a computer with a mobile broadband adapter, etc..

Communication network <NUM> includes one or more Radio Access Networks (RAN) <NUM> that communicate with UE <NUM> over radio signals. RAN <NUM> may support Evolved-UMTS Terrestrial Radio Access Network (E-UTRAN) access, Wireless Local Area Network (WLAN) access, fixed access, satellite radio access, new Radio Access Technologies (RAT), etc. As an example, RAN <NUM> may comprise an E-UTRAN or Next Generation RAN (NG-RAN) <NUM> that includes one or more base stations <NUM>. Base station <NUM> comprises an entity that uses radio communication technology to communicate with a UE on the licensed spectrum, and interface the UE with a core network. Base stations <NUM> in an E-UTRAN are referred to as Evolved-NodeBs (eNodeB). Base stations <NUM> in an NG-RAN are referred to as gNodeBs (NR base stations) and/or ng-eNodeBs (LTE base stations supporting a <NUM> Core Network). As another example, RAN <NUM> may comprise a WLAN <NUM> that includes one or more Wireless Access Points (WAP) <NUM>. WLAN <NUM> is a network in which a UE is able to connect to a Local Area Network (LAN) through a wireless (radio) connection. WAP <NUM> is a node that uses radio communication technology to communicate with a UE over the unlicensed spectrum, and provides the UE access to a core network. One example of WAP <NUM> is a WiFi access point that operates on the <NUM> or <NUM> radio bands.

UE <NUM> is able to attach to RAN <NUM> to access a core network <NUM>. In other words, RAN <NUM> represents the air interface between UE <NUM> and core network <NUM>. Core network <NUM> is the central part of communication network <NUM> that provides various services to customers who are connected by RAN <NUM>. One example of core network <NUM> is the Evolved Packet Core (EPC) network as suggested by the 3GPP for LTE. Another example of core network <NUM> is a <NUM> core network as suggested by the 3GPP. Core network <NUM> includes one or more network elements <NUM>, which comprise a server, device, apparatus, or equipment (including hardware) that provides or supports services accessible to UE <NUM>. Network elements <NUM>, in an EPC network, may comprise a Mobility Management Entity (MME), a Serving Gateway (S-GW), a Packet Data Network Gateway (P-GW), an Online Charging System (OCS), etc. Network elements <NUM>, in a <NUM> network, may comprise an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Policy Control Function (PCF), an Application Function (AF), an OCS, etc..

A network element <NUM> may also be implemented in RAN <NUM>, such as in the case of Mobile Edge Computing (MEC). MEC is an edge computing technology that enables the deployment of services (e.g., IT services and cloud services) within the (R)AN to more effectively provide latency-sensitive services and improve user experience. MEC may also be referred to as Mini Cloud, Cloudlet, Mobile Edge Cloud, Multi-access Edge Computing, or Fog Computing. To implement MEC, compute capabilities are implemented at one or more base stations or other functionalities of the RAN so that services are deployed closer to the UEs. For example, a MEC server <NUM> may be implemented at a base station of a (R)AN to provide MEC services to UEs in range of the base station. When referred to as being implemented "at" the base station, a MEC server may be part of the base station (i.e., part of the controller of the base station) or may be an external server deployed between the base station and the core network. A MEC server may alternatively be implemented at a WiFi server of the (R)AN or another wireless server.

A network element <NUM> as described herein may be implemented in <NUM> and/or <NUM> networks. <FIG> illustrate <NUM> and <NUM> networks, respectively, to show environments where a network element <NUM> may be implemented.

<FIG> illustrates an Evolved Packet Core (EPC) network <NUM>, which is the core network for LTE. EPC network <NUM> includes a Mobility Management Entity (MME) <NUM>, a Serving Gateway (S-GW) <NUM>, a Packet Data Network Gateway (P-GW) <NUM>, a Home Subscriber Server (HSS) <NUM>, a Policy and Charging Rules Function (PCRF) <NUM>, and an Online Charging System (OCS) <NUM>, but may include other elements not shown, such as IP Multimedia Subsystem (IMS) Application Servers. Within the EPC network <NUM>, the user data (also referred to as the "user plane") and the signaling (also referred to as the "control plane") are separated. MME <NUM> handles the control plane within EPC network <NUM>. For instance, MME <NUM> handles the signaling related to mobility and security for E-UTRAN access. MME <NUM> is responsible for tracking and paging UE <NUM> in idle-mode. S-GW <NUM> and P-GW <NUM> handle the user plane. S-GW <NUM> and P-GW <NUM> transport data traffic between UE <NUM> and external data networks <NUM> (DN or Packet Data Network (PDN)). S-GW <NUM> is the point of interconnect between the radio-side and EPC network <NUM>, and serves UE <NUM> by routing incoming and outgoing IP packets. S-GW <NUM> is also the anchor point for the intra-LTE mobility (i.e., in case of handover between eNodeBs), and between LTE and other 3GPP accesses. P-GW <NUM> is the point of interconnect between EPC network <NUM> and external data networks <NUM> (i.e., point of ingress or egress for data network <NUM>), and routes packets to and from data network <NUM>. HSS <NUM> is a database that stores user-related and subscriber-related information. PCRF <NUM> provides a Policy and Charging Control (PCC) solution in EPC network <NUM>. PCRF <NUM> is a node or entity of EPC network <NUM> that formulates PCC rules for services requested by an end user.

OCS <NUM> comprises a server, device, apparatus, or equipment (including hardware) that provides online charging for services provided in EPC network <NUM>. Online charging is a charging mechanism where charging information can affect, in real-time, the service rendered and therefore a direct interaction of the charging mechanism with session/service control is required. Online charging can be of two types: session-based or event-based. In event-based charging, a charging event is reported for a single operation. In session-based charging, multiple charging events are reported for a session. A further discussion of charging principles is described in 3GPP TS <NUM> (v15. <NUM>), which is incorporated by reference as if fully included herein. Although the charging domain is referred to herein as an OCS, it may be a combined online and offline charging system.

MME <NUM> connects to S-GW <NUM> through the S11 interface, and connects to HSS <NUM> through the S6a interface. The S6a interface enables transfer of subscription and authentication data for authenticating or authorizing user access between MME <NUM> and HSS <NUM>. PCRF <NUM> connects to P-GW <NUM> through the Gx interface. The Gx interface provides transfer of policy and charging rules from PCRF <NUM> to a Policy and Charging Enforcement Function (PCEF) in P-GW <NUM>. PCRF <NUM> connects to S-GW <NUM> through the Gxx interface. The Gxx interface resides between PCRF <NUM> and a Bearer Binding and Event Reporting Function (BBERF) integrated within S-GW <NUM>. S-GW <NUM> connects to P-GW <NUM> through the S5 interface. OCS <NUM> connects with PCRF <NUM> through an Sy interface.

<FIG> illustrates a non-roaming architecture <NUM> of a next generation network. The architecture in <FIG> is a reference point representation, as is further described in 3GPP TS <NUM> (v1. <NUM>), which is incorporated by reference as if fully included herein. Architecture <NUM> is comprised of Network Functions (NF) for a core network, which may be implemented either as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on an appropriate platform (e.g., a cloud infrastructure). The network functions for the control plane are separated from the user plane. The control plane of the core network includes an Authentication Server Function (AUSF) <NUM>, a Unified Data Management (UDM) <NUM>, a Network Slice Selection Function (NSSF) <NUM>, an Access and Mobility Management Function (AMF) <NUM>, a Session Management Function (SMF) <NUM>, a Policy Control Function (PCF) <NUM>, an Application Function (AF) <NUM>, and an OCS <NUM>. The user plane of the core network includes one or more User Plane Functions (UPF) <NUM> that communicate with data network <NUM>. UE <NUM> is able to access the control plane and the user plane of the core network through (R)AN <NUM>.

AUSF <NUM> is configured to support authentication of UE <NUM>. UDM <NUM> is configured to store subscription data/information for UE <NUM>. UDM <NUM> may store three types of user data: subscription, policy, and session-related context (e.g., UE location). AMF <NUM> is configured to provide UE-based authentication, authorization, mobility management, etc. SMF <NUM> is configured to provide the following functionality: session management (SM), UE Internet Protocol (IP) address allocation and management, selection and control of UPF(s), termination of interfaces towards PCF <NUM>, control part of policy enforcement and Quality of Service (QoS), lawful intercept, termination of SM parts of NAS messages, Downlink Data Notification (DNN), roaming functionality, handle local enforcement to apply QoS for Service Level Agreements (SLAs), charging data collection and charging interface, etc. If UE <NUM> has multiple sessions, different SMFs may be allocated to each session to manage them individually and possibly provide different functionalities per session. PCF <NUM> is configured to support a unified policy framework to govern network behavior, and to provide policy rules to control plane functions for QoS enforcement, charging, access control, traffic routing, etc. AF <NUM> provides information on a packet flow to PCF <NUM>. Based on the information, PCF <NUM> is configured to determine policy rules about mobility and session management to make AMF <NUM> and SMF <NUM> operate properly.

UPF <NUM> supports various user plane operations and functionalities, such as packet routing and forwarding, traffic handling (e.g., QoS enforcement), an anchor point for Intra-RAT/Inter-RAT mobility (when applicable), packet inspection and policy rule enforcement, lawful intercept (UP collection), traffic accounting and reporting, etc. Data network <NUM> is not part of the core network, and provides Internet access, operator services, 3rd party services, etc. For instance, the International Telecommunication Union (ITU) has classified <NUM> mobile network services into three categories: Enhanced Mobile Broadband (eMBB), Ultra-reliable and Low-Latency Communications (uRLLC), and Massive Machine Type Communications (mMTC) or Massive Internet of Things (MIoT). eMBB focuses on services that have high bandwidth requirements, such as HD videos, Virtual Reality (VR), and Augmented Reality (AR). uRLLC focuses on latency-sensitive services, such as automated driving and remote management. mMTC and MloT focuses on services that include high requirements for connection density, such as smart city and smart agriculture. Data network <NUM> may be configured to provide these and other services.

Architecture <NUM> includes the following reference points. The N1 reference point is implemented between UE <NUM> and AMF <NUM>. The N2 reference point is implemented between (R)AN <NUM> and AMF <NUM>. The N3 reference point is implemented between (R)AN <NUM> and UPF <NUM>. The N4 reference point is implemented between the SMF <NUM> and UPF <NUM>. The N5 reference point is implemented between PCF <NUM> and AF <NUM>. The N6 reference point is implemented between UPF <NUM> and data network <NUM>. The N7 reference point is implemented between the SMF <NUM> and PCF <NUM>. The N8 reference point is implemented between UDM <NUM> and AMF <NUM>. The N9 reference point is implemented between two UPFs <NUM>. The N10 reference point is implemented between UDM <NUM> and SMF <NUM>. The N11 reference point is implemented between AMF <NUM> and SMF <NUM>. The N12 reference point is implemented between AMF <NUM> and AUSF <NUM>. The N13 reference point is implemented between UDM <NUM> and AUSF <NUM>. The N14 reference point is implemented between two AMFs. The N15 reference point is implemented between PCF <NUM> and AMF <NUM> in the case of a non-roaming scenario. The N22 reference point is implemented between NSSF <NUM> and AMF <NUM>.

In the embodiments described herein, a network element is configured to initiate a PS Data off feature for a UE. The 3GPP has set forth the concept of a PS Data off feature in 3GPP TS <NUM> (v16. <NUM>), which is incorporated by reference as if fully included herein. According to the 3GPP, PS Data Off is a feature which, when configured by the Home Public Land Mobile Network (HPLMN) and activated by the user, prevents transport via PDN connections in 3GPP access networks of all data packets except IP packets required by 3GPP PS Data Off Exempt Services. The 3GPP system provides a mechanism by which an operator can configure which operator services are defined as the 3GPP PS Data Off Exempt Services for their subscribers.

When 3GPP PS Data Off is activated in the UE, in order to preserve charging consistency, the UE informs the network that 3GPP PS Data Off is activated, the UE ceases the sending of uplink IP Packets of all services that are not 3GPP PS Data Off Exempt Services, the network ceases the sending of downlink IP Packets to the UE for all services that are not 3GPP PS Data Off Exempt Services, the UE ceases the sending of uplink traffic over non-IP PDN types, and the network ceases the sending of downlink traffic over non-IP PDN types. Disabling of traffic on both the uplink and downlink is needed in order to provide consistency of charging between the HPLMN and a Visited PLMN (VPLMN), as well as consistency between what the user expects and what the user may be billed for.

Each of the following operator services are configurable by the HPLMN operator to be part of the 3GPP PS Data Off Exempt Services: MMTel Voice, SMS over IMS, USSD over IMS (USSI), MMTel Video, Particular IMS services not defined by 3GPP, where each such IMS service is identified by an IMS communication service identifier, Device Management over PS, Management of USIM files over PS (e.g. via Bearer Independent Protocol), and IMS Supplementary Service configuration via the Ut interface using XCAP.

According to the 3GPP, a PS Data Off feature is activated in the UE by a user. However, a PS Data Off feature initiated by end user through the UE may be insufficient. Core networks, sub-networks (like edge computing), local cloud, network elements (NEs), and applications in the network should have a capability to initiate a PS Data Off feature to save network resources and data service speed. For example, unnecessary data flows in MEC will impact throughput, latency, and reliability such as for <NUM> use cases. To address these and other problems, the embodiments herein set forth a mechanism in one or more network elements to activate a PS Data Off feature for a UE.

<FIG> is a block diagram of a network element <NUM> in an illustrative embodiment. Network element <NUM> may represent a network element <NUM>, such as shown in <FIG>. However, it should be noted that network element <NUM> is intended as an example of one possible implementation of a network element. As described above, network element <NUM> is a server, device, apparatus, equipment (including hardware), system, means, etc., that provides or supports services accessible to UEs. Some examples of network element <NUM> are S-GW <NUM>, OCS <NUM>, a policy control element (e.g., a PCRF <NUM>), or another network element of an EPC network <NUM>, an SMF <NUM>, AF <NUM>, OCS <NUM>, a policy control element (e.g., PCF <NUM>), or another network element of a next generation network, a MEC server <NUM>, a Mobile Device Management (MDM) server, or another network element within the network and distinct from a UE. A policy control element is defined as a network element configured to determine policy rules to support a unified policy framework to govern network behavior, and to provide the policy rules to control plane elements/functions for QoS enforcement, charging, access control, traffic routing, etc..

In this embodiment, network element <NUM> includes the following subsystems: policy manager <NUM>, a data off controller <NUM>, and a network interface component <NUM> that operate on one or more platforms. Policy manager <NUM> may comprise circuitry, logic, hardware, means, etc., configured to store and/or maintain a data off policy <NUM> or multiple data off policies. Data off policy <NUM> is criteria defined for triggering activation/deactivation of PS Data off features for a UE or multiple UEs, generating a NE-Initiated PS Data Off Exempt Service List for an activated PS Data off feature, etc. Data off policy <NUM> may be specific to UE <NUM> (and/or its associated user), may be specific to network element <NUM>, may apply to multiple UEs, may apply to a geographic area, etc. Policy manager <NUM> may provide an interface, portal, or other mechanism that allows a network operator (i.e., an entity that manages the network) to define, modify, or update data off policy <NUM>. Policy manager <NUM> may also provide an interface, portal, or other mechanism that allows a user of a UE to define, modify, or update data off policy <NUM>.

Data off controller <NUM> may comprise circuitry, logic, hardware, means, etc., configured to determine whether to activate/deactivate a PS Data off feature for a UE. Determinations by data off controller <NUM> may be based on data off policy <NUM> and one or more network service conditions. A network service condition comprises a state of the network or a UE for a data service. For example, network service conditions may include time-of-day (ToD), day-of-week (DoW), location of a UE, user spending limit associated with a UE, home/roaming, remaining balance or data allowance, parental control options, operator/government regulations, network traffic load, Quality of Service (QoS) requirements, UE density, access technology, etc. Data off controller <NUM> may further comprise circuitry, logic, hardware, means, etc., configured to generate a PS Data off request that is used to activate/deactivate a PS Data off feature for a UE. Data off controller <NUM> may further comprise circuitry, logic, hardware, means, etc., configured to initiate transmission of the PS Data off request for receipt by a gateway of the network, the UE, or another entity. Data off controller <NUM> may transmit the PS Data off request through network interface component <NUM>. Network interface component <NUM> may comprise circuitry, logic, hardware, means, etc., configured to exchange control plane messages, signaling, or packets with other elements. Network interface component <NUM> may operate using a variety of protocols or reference points.

One or more of the subsystems of network element <NUM> may be implemented on a hardware platform comprised of analog and/or digital circuitry. One or more of the subsystems of network element <NUM> may be implemented on a processor <NUM> that executes instructions stored in memory <NUM>. Processor <NUM> comprises an integrated hardware circuit configured to execute instructions, and memory <NUM> is a non-transitory computer readable storage medium for data, instructions, applications, etc., and is accessible by processor <NUM>.

Network element <NUM> may include various other components not specifically illustrated in <FIG>.

<FIG> is a block diagram of UE <NUM> in an illustrative embodiment. UE <NUM> includes a radio interface component <NUM>, one or more processors <NUM>, a memory <NUM>, and a user interface component <NUM>. Radio interface component <NUM> is a hardware component that represents the local radio resources of UE <NUM>, such as transceivers and antennas, used for wireless communications with a base station, access point, etc., via radio or "over-the-air" signals. Processor <NUM> represents the internal circuitry, logic, hardware, software, etc., that provides the functions of UE <NUM>. Memory <NUM> is a computer readable storage medium for data, instructions, applications, etc., and is accessible by processor <NUM>. User interface component <NUM> is a hardware component for interacting with an end user. For example, user interface component <NUM> may include a screen or touch screen (e.g., a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display, etc.), a keyboard or keypad, a tracking device (e.g., a trackball or trackpad), a speaker, and a microphone. UE <NUM> may include various other components not specifically illustrated in <FIG>.

Processor <NUM> is configured to implement a PS Data off feature <NUM> in UE <NUM>. PS Data off feature <NUM> may be activated by the user through UE <NUM> as described by the 3GPP. In the embodiments described herein, PS Data off feature <NUM> may also be activated by the network. When PS Data off feature <NUM> is activated in UE <NUM>, it ceases the sending of uplink traffic for all services that are not exempt services.

The following description provides further details regarding network-initiated activation of PS Data off features for UEs. <FIG> is a flow chart illustrating a method <NUM> of activating a PS Data off feature at a network element in an illustrative embodiment. The steps of method <NUM> will be described with reference to network element <NUM> in <FIG>, but those skilled in the art will appreciate that method <NUM> may be performed in other network elements or network functions. Also, the steps of the flow charts described herein are not all inclusive and may include other steps not shown, and the steps may be performed in an alternative order.

In this embodiment, network element <NUM> is the entity that initiates a PS Data off feature for one or multiple UEs, instead of the UE(s) initiating the PS Data off feature as suggested by the 3GPP. Policy manager <NUM> of network element <NUM> stores and/or maintains data off policy <NUM> (step <NUM>). Data off policy <NUM> may be pre-provisioned by a network operator, and may be modified or updated based on input from the network operator, the user of UE <NUM>, or another entity.

Data off controller <NUM> collects or monitors network service conditions (step <NUM>). Data off controller <NUM> determines whether to activate the PS Data off feature for UE <NUM> (step <NUM>). In one embodiment, data off controller <NUM> may determine whether to activate the PS Data off feature based on data off policy <NUM> and one or more of the network service conditions. In another embodiment, data off controller <NUM> may determine whether to activate the PS Data off feature based on a request from another network element. For example, an OCS may request activation of the PS Data Off feature based on an account status associated with UE <NUM>, such as in a Diameter Credit Control Request (CCR).

Responsive to a determination to activate the PS Data off feature, data off controller <NUM> generates a PS Data off request to activate the PS Data off feature for UE <NUM> (step <NUM>). The PS Data off request comprises a message, signaling, command, etc., used to convey information for a PS Data off feature initiated by a network element (NE). A PS Data off request may include the following parameters or information: a NE-Initiated PS Data Off Status, a NE-Initiated PS Data Off Exempt Service List, and a NE-Initiated PS Data Off Reason. The NE-Initiated PS Data Off Status indicates whether the PS Data off feature is activated or deactivated for a UE. The NE-Initiated PS Data Off Status may also indicate other options, such as a time period for activating/deactivating the PS Data off feature as pre-configured by a network operator, a time period for activating/deactivating the PS Data off feature as dynamically determined by network element <NUM> based on data off policy <NUM>, a start/stop time for activating/deactivating, etc..

The NE-Initiated PS Data Off Exempt Service List is a set of operator services that are allowed even if the PS Data off feature has been activated for a UE. The NE-Initiated PS Data Off Exempt Service List may be dynamically determined by network element <NUM> based on data off policy <NUM>. The NE-Initiated PS Data Off Exempt Service List may be mapped to a list of "exempt" data filters (e.g., Traffic Flow Template (TFT)). A data filter (or packet filter) allows a gateway in the core network to classify packets received from an external data network into the correct Packet Data Protocol (PDP) context. When incoming data packets arrive from the external data network, the gateway maps the incoming data packets to a PDP context based on the data filters. Based on the NE-Initiated PS Data Off Exempt Service List, the gateway is able to distinguish incoming data packets for an exempt data service(s) from incoming data packets for a non-exempt data service(s). The NE-Initiated PS Data Off Exempt Service List may include the following information:.

The NE-Initiated PS Data Off Exempt Service List may be provisioned or updated based on input from the end user and/or the network operator. For example, a parent may add and remove exempt data services from the NE-Initiated PS Data Off Exempt Service List based on a child's age.

The NE-Initiated PS Data Off Reason indicates a basis or motive for activating or deactivating a PS-Data Off feature. For example, a NE-Initiated PS Data Off Reason may indicate the motive as QoS control, device density control, balance usage, ToD, DoW, parental control, location, etc..

After generating the PS Data off request, data off controller <NUM> initiates transmission (through network interface component <NUM>) of the PS Data off request for receipt by a gateway of the network that acts as an entry point for downlink traffic for UE <NUM> (step <NUM>). For example, a gateway that acts as an entry point for downlink traffic destined for UE <NUM> may be a P-GW <NUM> in EPC network <NUM>, or a UPF <NUM> in a <NUM> network. The PS Data off request may be its own control message, or may be encapsulated in another control message. The Protocol Configuration Option (PCO) in a GTP parameter may be extended to include the PS Data off request including the NE-Initiated PS Data Off Exempt Service List. The NE-Initiated PS Data Off Exempt Service List may be in GTP-Control Protocol to have the NE-Initiated PS Data Off Exempt Service List applied at the start of a data connection, during the data connection, and at the end of the data connection.

The gateway processes the PS Data off request, and identifies that network element <NUM> has activated the PS Data off feature for UE <NUM> based on the NE-Initiated PS Data Off Status. Because the gateway is the entry point for downlink traffic, it is able to filter the downlink traffic destined for UE <NUM> based on the NE-Initiated PS Data Off Exempt Service List. Thus, the gateway allows packets mapped to an exempt service to pass to UE <NUM>, and blocks packets mapped to a non-exempt service from UE <NUM>.

Data off controller <NUM> may also initiate transmission (through network interface component <NUM>) of the PS Data off request for receipt by UE <NUM> (optional step <NUM>). For example, network element <NUM> may format the PS Data off request for transmission over the network, or encode/encapsulate the PS Data off request in another control message. Network element <NUM> may transmit the PS Data off request to RAN <NUM> (e.g., to a base station or access point), or to an intermediate element that forwards the PS Data off request to RAN <NUM>. RAN <NUM> then forwards the PS Data off request to UE <NUM> via radio signals. UE <NUM> processes the PS Data off request to activate the PS Data off feature locally within UE <NUM>, which is further described in <FIG>.

<FIG> is a flow chart illustrating a method <NUM> of activating a NE-initiated PS Data off feature in a UE in an illustrative embodiment. The steps of method <NUM> will be described with reference to UE <NUM> in <FIG>, but those skilled in the art will appreciate that method <NUM> may be performed in other UEs or mobile devices.

Radio interface component <NUM> of UE <NUM> receives the PS Data off request from the network via radio signals (step <NUM>). Again, the PS Data off request may be its own control message, or may be encapsulated in another control message. Processor <NUM> processes the PS Data off request to determine that the PS Data off feature has been activated by network element <NUM> (step <NUM>). Processor <NUM> also processes the PS Data off request to identify the NE-Initiated PS Data Off Exempt Service List specified by network element <NUM> (step <NUM>). Processor <NUM> then activates PS Data off feature <NUM> in UE <NUM> (step <NUM>) based on the NE-Initiated PS Data Off Exempt Service List. When PS Data off feature <NUM> is activated in UE <NUM>, processor <NUM> ceases the sending of uplink traffic of all services that are not specified in the NE-Initiated PS Data Off Exempt Service List. Processor <NUM> may also provide a notification (optional step <NUM>) to the user via user interface component <NUM> indicating that the PS Data off feature has been activated, indicating the exempt services that are allowed according to the NE-Initiated PS Data Off Exempt Service List, or other information.

When network element <NUM> activates the PS Data off feature, the gateway (e.g., P-GW or UPF) will directly bar/reject a downlink traffic request from an application server, an application function, etc. Also, UE <NUM> will directly bar/reject an uplink traffic request triggered by an application(s) running on UE <NUM>. This advantageously avoids "ping" traffic that can cause congestion and waste network resources in the network.

The PS Data off feature as initiated by network element <NUM> may deactivate automatically based on information provided in the PS Data off request (e.g., after a time period). Alternatively, network element <NUM> may dynamically deactivate the PS Data off feature. <FIG> is a flow chart illustrating a method <NUM> of deactivating a PS Data off feature at a network element in an illustrative embodiment. The steps of method <NUM> will be described with reference to network element <NUM> in <FIG>, but those skilled in the art will appreciate that method <NUM> may be performed in other network elements or network functions.

As described above, policy manager <NUM> stores and/or maintains data off policy <NUM> (step <NUM>), and data off controller <NUM> collects or monitors network service conditions (step <NUM>). It is assumed that the PS Data off feature has previously been activated for UE <NUM>, such as according to method <NUM> above. Data off controller <NUM> determines whether to deactivate the PS Data off feature for UE <NUM> (step <NUM>). In one embodiment, data off controller <NUM> may determine whether to deactivate the PS Data off feature based on data off policy <NUM> and one or more of the network service conditions. In another embodiment, data off controller <NUM> may determine whether to deactivate the PS Data off feature based on a request from another network element. For example, an OCS may request deactivation of the PS Data Off feature responsive to replenishment of an account associated with UE <NUM>.

Responsive to a determination to deactivate the PS Data off feature, data off controller <NUM> generates a PS Data off request to deactivate the PS Data off feature for UE <NUM> (step <NUM>). Data off controller <NUM> initiates transmission (through network interface component <NUM>) of the PS Data off request for receipt by a gateway of the network that acts as an entry point for downlink traffic for UE <NUM> (step <NUM>). The gateway processes the PS Data off request, and identifies that network element <NUM> has deactivated the PS Data off feature for UE <NUM> based on the NE-Initiated PS Data Off Status. The gateway then ceases to filter packets according to the NE-Initiated PS Data Off Exempt Service List.

Data off controller <NUM> may also initiate transmission (through network interface component <NUM>) of the PS Data off request for receipt by UE <NUM> (optional step <NUM>). UE <NUM> then processes the PS Data off request to deactivate the PS Data off feature locally in UE <NUM>, which is further described in <FIG>.

<FIG> is a flow chart illustrating a method <NUM> of deactivating a NE-initiated PS Data off feature in a UE in an illustrative embodiment. The steps of method <NUM> will be described with reference to UE <NUM> in <FIG>, but those skilled in the art will appreciate that method <NUM> may be performed in other UEs or mobile devices.

Radio interface component <NUM> of UE <NUM> receives the PS Data off request from the network via radio signals (step <NUM>). Processor <NUM> processes the PS Data off request to determine that the PS Data off feature has been deactivated by network element <NUM> (step <NUM>). Processor <NUM> then deactivates PS Data off feature <NUM> in UE <NUM> (step <NUM>). When PS Data off feature <NUM> is deactivated in UE <NUM>, processor <NUM> may send uplink traffic for all services subscribed to by the user. Processor <NUM> may also provide a notification (optional step <NUM>) to the user via user interface component <NUM> indicating that the PS Data off feature has been deactivated.

According to the above embodiments, different network elements are able to initiate PS Data Off requests with different NE-Initiated Data Off Exempt Service Lists for UEs. For example, OCS <NUM> (see <FIG>) may initiate a PS Data off request for a UE. If a user associated with a UE has no balance in their account, the OCS may send a request to an MDM server to activate a PS Data off feature for the UE with one NE-Initiated Data Off Exempt Service List. After the user has recharged the balance, the OCS may send a request to the MDM server to deactivate PS Data off feature. In another example, PCRF <NUM> (see <FIG>) may generate a PS Data off request for a UE based on a data off policy and network service conditions (e.g., ToD, DoW, location, etc.), to activate a PS Data off feature with another NE-Initiated Data Off Exempt Service List. An Application Server may enable a user to define when to activate and deactivate a PS Data off feature with another NE-Initiated Data Off Exempt Service List, such as activating the Data off feature during sleeping hours, and deactivating the PS Data off feature during non-sleeping hours. Thus, there is flexibility in how/when a PS Data off feature is activated in a network.

Any of the various elements or modules shown in the figures or described herein may be implemented as hardware, software, firmware, or some combination of these.

Also, an element may be implemented as instructions executable by a processor or a computer to perform the functions of the element.

Claim 1:
A network element, NE, (<NUM>) implemented in a network (<NUM>) that provides at least one data service to User Equipment, UE, (<NUM>), the network element comprising:
a means for storing a data off policy (<NUM>) that triggers activation or deactivation of a Packet Switch, PS, Data off feature initiated by the network element for the UE;
a means for determining whether to activate the PS Data off feature for the UE based on the data off policy and one or more network service conditions;
a means for generating a first PS Data off request to activate the PS Data off feature for the UE responsive to a determination to activate the PS Data off feature, wherein the first PS Data off request includes a NE-Initiated PS Data Off Exempt Service List that is a set of operator services that are allowed even if the PS Data off feature is activated for a UE; and
a means for initiating transmission of the first PS Data off request for receipt by a gateway of the network that acts as an entry point for downlink traffic for the UE to cause the gateway to filter the downlink traffic for the UE based on the NE-Initiated PS Data Off Exempt Service List.