Patent Description:
This background description is provided for the purpose of generally presenting the context of the disclosure.

In fifth-generation (<NUM>) wireless communication systems, a user equipment (UE) can apply a so-called UE Route Selection Policy (URSP) to outgoing traffic to determine how the UE should route traffic for a certain application executing on an operating system (OS), a certain domain, a certain network host, etc. As defined by the current <NUM> standards, an URSP rule includes (<NUM>) a rule precedence value, (<NUM>) one or more traffic descriptors, and (<NUM>) one or more route selection descriptors. Rule precedence values determine the order in which the UE applies the URSP rules, traffic descriptors specify how the UE should match outgoing traffic to the rule to determine whether the rule applies, and route selection descriptors specify how the UE should route the traffic if the rule applies.

For example, according to a first URSP rule, a UE should route traffic related to network domain D to the already-established Protocol Data Unit (PDU) session; according to a second USRP rule, the UE should establish a new PDU session for outgoing traffic addressed to host H; and according to a third URSP rule, the UE should offload all Ethernet traffic to a wireless local area network (WLAN) such as a WiFi® network. If the first rule in this example has a higher rule precedence value than the second rule, the UE should apply the first rule rather than the second rule to the outgoing traffic that matches the respective traffic descriptors of the first and second rules (i.e., the traffic relates to domain D and is addressed to host H).

A UE can locally store pre-provisioned URSP rules and also receive URSP rules from the core network (CN). According to the current <NUM> standards, when the UE has both pre-provisioned rules and CN-specified rules, the UE applies the CN-specified rules.

Generally speaking, URSP techniques provide significant flexibility to the CN. However, the existing techniques also require that UEs support multiple types of traffic descriptors to execute the corresponding URSP rules. This is difficult in some cases because a UE may not always have access to all of the traffic parameters of outgoing traffic. For example, if different vendors implement different components of the UE, the entity executing the URSP may be unable to determine the traffic parameters for all the applications and services relying on data connectivity at the UE. As a result, the UE cannot always match outgoing traffic to an URSP rule, and therefore may fail to apply a URSP rule that would have been applicable had all the traffic parameters been known by the UE.

3GPP S2-<NUM> relates to clarification on UE capability to support URSP. If any of parameters in traffic descriptor cannot be identified or supported by UE, but the network has provisioned those, then a misalignment exists and needs to be resolved. It is proposed that the UE shall ignore the URSP rule if the parameter in traffic descriptor cannot be identified or supported. 3GPP TS <NUM> v16. <NUM> states that if the network provides URSP rules including any new component in the traffic descriptor or in the route selection descriptor which is not recognized by the UE, such URSP rules are unknown or unexpected to the UE. In this case, the UE shall ignore the unknown or unexpected URSP rules when evaluating URSP rules to associate an application either with a PDU session or with non-seamless non-3GPP offload.

Further embodiments are set forth in the dependent claims.

<FIG> illustrates an example communication system <NUM> in which the routing techniques of this disclosure can be implemented. The communication system <NUM> includes a user equipment (UE) <NUM>, which can be any suitable device capable of wireless communications with a core network (CN) <NUM> via a base station <NUM>.

Generally speaking, the UE <NUM> can determine that certain traffic descriptors associated with rules that specify route selection for outgoing traffic at the UE <NUM> are proscribed (or "forbidden"), and that the UE <NUM> should not use these proscribed descriptors when matching the outgoing traffic to the rules. Although the disclosure refers primarily to URSP rules, these techniques also can apply to other rule-based routing mechanisms.

As discussed in more detail below, the UE <NUM> can determine that a rule includes a proscribed traffic descriptor and subsequently ignore the rule when applying the set of rules of an URSP. As another example, the UE <NUM> can determine that a rule contains both proscribed and non-proscribed, or permissible, traffic descriptors. The UE <NUM> then can apply the rule by ignoring the proscribed traffic descriptors and using only the permissible traffic descriptors for matching the outgoing traffic.

In another example implementation, the UE <NUM> is allowed to prioritize a local configuration over URSP rules received from the CN <NUM>. For instance, the UE <NUM> can apply local rules over those rules that include proscribed traffic descriptors, or can prioritize a local set of rules in its entirety over the URSP rules received from the CN <NUM>.

Still further, the UE <NUM> can preemptively request that the CN <NUM> not supply the UE <NUM> with any URSP rules that include the proscribed traffic descriptors. For example, the UE <NUM> can determine that a certain traffic descriptor is proscribed and transmit a corresponding indication to the CN <NUM>. To this end, the UE <NUM> can use an existing protocol for managing URSP rules or use a dedicated message for indicating proscribed traffic descriptors.

The UE also can combine at least some of these techniques. For example, if the UE <NUM> sends an indication of a proscribed traffic descriptor to the CN <NUM>, but the CN <NUM> nevertheless responds with URSP rules containing proscribed traffic descriptors (for example, due to a race condition or because the CN <NUM> does not support the message from the UE <NUM>), the UE <NUM> can apply the other techniques discussed above to prevent application of any rules that contain forbidden traffic descriptors. As another example, the UE <NUM> can ignore rules that reference only proscribed traffic descriptors, but still apply rules that reference both proscribed and permissible traffic descriptors by utilizing only the permissible traffic descriptors. In at least some of the implementations, the UE <NUM> can consider the rules that reference one or more proscribed traffic descriptors as inapplicable.

As illustrated in <FIG>, the base station <NUM> is communicatively connected to a core network (CN) <NUM> via an NG interface, for example. In some implementations, the base station <NUM> is a <NUM> New Radio (NR) base station operating as a g Node B (gNB), and the CN <NUM> is a <NUM> core network (5GC). In other implementations, however, the communication system <NUM> can include one or more base stations that operate according to radio access technologies (RATs) of types other than NR, and these base stations can be connected to CNs of other types. Further, the UE <NUM> also may have direct access via a radio interface to other types of access networks, such as a wireless local area network (WLAN) <NUM> (via an access point (AP) <NUM>, for example).

The base station <NUM> is associated with a RAN <NUM> and provides coverage to a cell <NUM>. While <FIG> depicts the base station <NUM> as associated with only one cell <NUM>, it is understood that the base station <NUM> may also cover one or more additional cells not shown in <FIG>. Further, the RAN <NUM> can include any suitable number of base stations that collectively support one or more RATs. The UE <NUM> can communicatively connect with the RAN <NUM> via base station <NUM> when operating within cell <NUM>, and in turn can communicatively connect with the CN <NUM> via the RAN <NUM>.

The UE <NUM> is equipped with processing hardware <NUM>, which can include one or more general-purpose processors (e.g., CPUs) and at least one non-transitory computer-readable memory <NUM> storing instructions executable on the one or more general processors and/or special-purpose processing units. The memory <NUM> stores an operating system (OS) <NUM> of the UE <NUM>, which can be any type of suitable mobile or general-purpose operating system. In addition, the memory <NUM> may also store one or more applications <NUM>. In operation, the one or more applications <NUM> generate outgoing traffic and receive incoming traffic. These applications can include web browsers, mailing applications, messaging applications, video and audio players, gaming applications, etc..

To communicate with the base station <NUM>, the CN <NUM>, and various remote hosts, the UE <NUM> implements a communication protocol stack that includes an upper layer <NUM> and an NAS/URSP handling layer <NUM>. The layers <NUM> and <NUM> can be implemented using any suitable combination of hardware, software, and firmware. In one example implementation, the layers <NUM> and <NUM> are a set of instructions that the processing hardware <NUM> executes to perform the rule application techniques discussed herein.

The upper layer <NUM> can identify outgoing traffic at the UE and provide outgoing traffic to the NAS/URSP handling layer <NUM> for routing. The NAS/URSP handling layer <NUM> can be a combined layer including both a NAS layer and a URSP handling layer. The NAS layer can manage the establishment and maintenance of communication sessions, such as protocol data unit (PDU) sessions. Further, the NAS layer can receive URSP rules from the CN and configure the URSP handling layer with the received URSP rules. The combined NAS/URSP handling layer <NUM> can manage the application of rules for routing outgoing traffic at the UE <NUM>, as described in further detail below. When the upper layer <NUM> determines that an application <NUM> executing on the UE <NUM> has queued outgoing data for transmission, the upper layer <NUM> can direct the NAS/URSP handling layer <NUM> to apply one or more URSP rules and route the outgoing application traffic accordingly.

The NAS/URSP handling layer <NUM> in an example implementation includes a UE rule controller <NUM> configured to manage or control application of rules for routing outgoing traffic, and prevent application of proscribed traffic descriptors.

The CN <NUM> can be, for example, a <NUM> core network (5GC), a less advanced core network (e.g., an evolved packet core (EPC)) or, conversely, a more advanced core network. The CN <NUM> may be equipped with a mobility management entity such as Access and Mobility Management Function (AMF) <NUM> configured to manage authentication, registration, mobility, and other related functions, and a policy control entity such as Policy Control Function (PCF) <NUM> for providing policies for mobility and session management. The CN <NUM> also may include a CN rule controller <NUM> configured to manage, modify, and transmit to the UE <NUM> (and other UEs) various rules for routing outgoing traffic at the UE <NUM>, such as a set of rules associated with an URSP. The CN rule controller <NUM> can operate as a separate entity or as a component of the PCF <NUM>, depending on the implementation. In some scenarios, the PCF <NUM> provides to the UE <NUM> a policy in accordance with which the UE <NUM> should route outgoing traffic. This policy can be include a set of rules that conform to the URSP, discussed in more detail below with reference to <FIG>.

With continued reference to <FIG>, the CN <NUM> communicatively connects UE <NUM>, via the RAN <NUM> including the base station <NUM> (and typically multiple other base stations), to various communication networks including a wide area network such as the Internet <NUM>. More specifically, the CN <NUM> can directly connect to a data network via an access point name (APN) or data network name (DNN) gateway <NUM>. The UE <NUM> can include outgoing traffic with a traffic descriptor that identifies the gateway <NUM>, and the CN <NUM> can provide a rule that references the gateway <NUM>. When the UE <NUM> determines that the traffic descriptor referencing the gateway <NUM> is permissible, the UE rule controller <NUM> applies the rule and routes the outgoing traffic in accordance with the rule. Otherwise, when the UE <NUM> determines that the traffic descriptor referencing the gateway <NUM> is proscribed, the UE rule controller <NUM> ignores the rule, modifies the rule, or otherwise processes the rule in accordance with the techniques of this disclosure. In other example scenarios, outgoing traffic and/or one or more rules can reference a domain <NUM>, a particular host <NUM> (e.g., by host name or Internet Protocol (IP) address), type of traffic (e.g., Ethernet), etc..

<FIG> is a block diagram of an example rule <NUM> for route selection which the UE <NUM> of <FIG> can apply to outgoing traffic to determine how the UE <NUM> should route outgoing traffic. A route selection policy, such as a URSP received from CN <NUM> or a local configuration stored at the UE <NUM>, includes one or more rules that conform to the format of <FIG>. The example rule <NUM> includes a rule precedence <NUM>, a traffic descriptor <NUM>, and a route selection descriptor <NUM>. In general, rules may include one or more traffic descriptors and one or more route selection descriptors.

The rule precedence field <NUM> specifies the order in which the UE <NUM> applies the rule <NUM> relative to other rules. In some implementations, the rule precedence <NUM> of each rule is different from the rule precedence of every other rule within the URSP. Traffic descriptors specify how the UE <NUM> should match outgoing traffic to the rule. For example, if the traffic descriptor <NUM> of rule <NUM> matches the parameters of outgoing traffic, then the UE <NUM> would apply rule <NUM> to the outgoing traffic. A URSP can include a rule with lowest precedence that has a "match all" traffic descriptor that UE <NUM> can apply to any outgoing traffic.

Traffic descriptors may include, for example, application identifiers of applications <NUM> executing on the OS <NUM> of the UE <NUM>. As another example, traffic descriptors may also correspond to IP descriptors such as an IP destination and/or an IP <NUM> tuple including destination IP address or IPv6 network, port number, and protocol ID. Traffic descriptors may also be non-IP descriptors such as descriptors for Ethernet traffic. In some embodiments, a traffic descriptor may refer to a specific type of network traffic. Further, as discussed above, traffic descriptors may correspond to an APN or DNN gateway <NUM>. Traffic descriptors also may correspond to various connection capabilities of the UE <NUM>, such as IP Multimedia Subsystem (IMS) capabilities, Multimedia Message Service (MMS) capabilities, or other internet-related capabilities. Still further, traffic descriptors may be domain descriptors such as a domain name (e.g., of domain <NUM>), a hostname (e.g., of host <NUM>), or a fully qualified domain name (FQDN) made up of a domain name and a hostname.

The route selection descriptor <NUM> specifies how the UE <NUM> should route the traffic if the rule applies. For example, the route selection descriptor <NUM> may specify that the UE <NUM> should route traffic matching the traffic descriptor <NUM> of the rule <NUM> to an already-established communication session, such as an established Protocol Data Unit (PDU) session. As another example, the route selection descriptor <NUM> may instruct the UE <NUM> to establish a new PDU session for outgoing traffic matching the rule <NUM>. As yet another example, the route selection descriptor <NUM> may instruct the UE <NUM> to offload outgoing traffic matching the rule <NUM> to a wireless local area network (WLAN) such as a WiFi® network.

In an example scenario, a URSP includes three rules. Rule R<NUM> may have a rule precedence of <NUM> and a traffic descriptor corresponding to application identifier App<NUM>. Rule R<NUM> may have a rule precedence of <NUM> and traffic descriptor corresponding to application identifier App<NUM>. Rule R<NUM> may have a rule precedence of <NUM> and traffic descriptor corresponding to the "match all" option. When the UE <NUM> has outgoing traffic, the UE <NUM> evaluates the rules in the order of rule precedence. Thus, the UE <NUM> in this scenario first determines whether it should apply rule R<NUM> to the outgoing traffic by determining whether the outgoing traffic matches the traffic descriptor of rule R<NUM>, i.e., if the outgoing traffic corresponds to traffic of App<NUM>. If the outgoing traffic corresponds to traffic of App<NUM>, the UE <NUM> applies rule R<NUM> to the outgoing traffic and routes the traffic in accordance with the one or more route selection descriptors of rule App<NUM>. If the outgoing traffic does not match the traffic descriptor of rule R<NUM>, the UE <NUM> determines whether it should apply rule R<NUM>, and so on.

<FIG> is a messaging diagram of an example scenario <NUM> in which the UE <NUM> of <FIG> determines that it should not apply a certain traffic descriptor for routing outgoing traffic at the UE <NUM>, and ignores a rule received from the CN <NUM> that references only this proscribed (or "forbidden") traffic descriptor TDF. For simplicity, this discussion refers to the forbidden traffic descriptor TDF in the singular. However, the UE <NUM> in general can identify any suitable number of forbidden descriptors.

The NAS/URSP handling layer <NUM> identifies or determines <NUM> the forbidden traffic descriptor TDF. The forbidden traffic descriptor may correspond to a type of traffic descriptor (e.g., any traffic descriptor that is an application identifier), or to a particular parameter of a traffic descriptor (e.g., a particular application). The UE <NUM> may determine that a certain traffic descriptor is forbidden because the entity operating within the UE and executing the URSP rules, such as the NAS/URSP handling layer <NUM> or a connection manager of the UE <NUM>, does not have access to the forbidden traffic descriptor or to the type of parameter of the outgoing traffic to which the traffic descriptor corresponds. In some cases, the OS <NUM> may inform the NAS/URSP handling layer <NUM> of the outgoing traffic parameters the UE <NUM> should not use when applying the URSP rules.

The UE <NUM> also may determine that certain traffic parameters are forbidden based on instructions stored on or received at the UE <NUM>. Such instructions may originate for example from the manufacturer of the UE <NUM>, a hardware component of the UE <NUM>, a firmware or software component of the UE <NUM>, the OS <NUM>, etc. Although <FIG> depicts event <NUM> as occurring prior to event <NUM>, in other implementations or scenarios event <NUM> can occur after event <NUM>. In other words, the UE <NUM> may make the determination <NUM> after receiving <NUM> the URSP rules from the CN.

With continued reference to <FIG>, the UE <NUM> receives <NUM> a message including URSP rules from the CN <NUM>. The message can be associated with a protocol for delivering a route selection policy. In this example, the message is a Manage UE Policy Command. The URSP rules in this scenario include a rule RCN with at least one forbidden traffic descriptor TDF. In some implementations, all of the traffic descriptors of rule RCN may be forbidden. In general, the message of event <NUM> can include one or more rules with only one or several forbidden descriptors, one or more rules with only one or several permissible descriptors, and one or more rules with one or several forbidden descriptors as well as one or several permissible descriptors.

Next, the upper layer <NUM> provides <NUM> outgoing traffic to the NAS/URSP handling layer <NUM>. In response, the NAS/URSP handling layer <NUM> applies <NUM> the URSP rules to the outgoing traffic, subject to the restriction that the UE <NUM> cannot match outgoing traffic to the traffic descriptor TDF. More specifically, in this implementation, the NAS/URSP handling layer <NUM> prevents the application of TDF to the outgoing traffic by ignoring rule RCN.

According to the claimed invention, a method of routing outgoing traffic in a user equipment, UE, that communicates with a core network, CN, via a radio access network, RAN, is provided, the method comprising:
receiving, by the UE from the CN, a set of rules specifying route selection for outgoing traffic at the UE; and preventing, by the UE, application of a first rule of the set of rules to the outgoing traffic in response to determining that the first rule references a proscribed traffic descriptor and does not reference any other traffic descriptors.

<FIG> is a messaging diagram of an example scenario <NUM> in which the UE <NUM> of <FIG> receives a rule that references a forbidden traffic descriptor as well as a permissible traffic descriptor, and applies the rule to the outgoing traffic using only the permissible traffic descriptor. As discussed above with reference to <FIG>, the UE <NUM> determines <NUM> forbidden traffic descriptor TDF prior to or after receiving the URSP rules from the CN <NUM>. However, the UE <NUM> in this scenario receives <NUM> a message with URSP rules that include a rule RCN that includes both a forbidden traffic descriptor TDF and a permissible traffic descriptor TDP, from the CN <NUM>. After the UE <NUM> detects <NUM> outgoing traffic, the UE <NUM> does not use TDF for matching the outgoing traffic to the URSP rules. More particularly, the UE <NUM> ignores <NUM> TDF and uses only TDP for matching the outgoing traffic to RCN. Thus, the UE <NUM> still applies RCN to the outgoing traffic, but does so based on the permissible traffic descriptor TDP rather than the forbidden traffic descriptor TDF.

Now referring to <FIG>, in an example scenario <NUM> the UE <NUM> notifies the CN <NUM> of a forbidden traffic descriptor using a message of a protocol for delivering a route selection policy. Events <NUM> and <NUM> are similar to events <NUM> and <NUM>, respectively. In response to receiving a RCN(TDF) including only a forbidden traffic descriptor (or several forbidden traffic descriptors), the UE <NUM> transmits <NUM> a message to the CN <NUM> notifying the CN <NUM> of the forbidden traffic descriptor TDF. Alternatively, the message can identify rule RCN. The UE <NUM> in this example includes <NUM> an indication of TDF and/or RCN in a cause information element (IE) of a Manage UE Policy Command Reject message.

In response to receiving <NUM> the Manage UE Policy Command Reject message, the CN <NUM> may modify the URSP rules and transmit <NUM> updated URSP rules to the UE <NUM> as another instance of the Manage UE Policy Command message for example. In some implementations, the CN <NUM> removes rule RCN from the URSP before transmitting <NUM> the updated URSP to the UE <NUM>. Alternatively, the CN <NUM> may modify RCN by removing TDF but retaining one or more permissible traffic descriptors. The CN <NUM> similarly can remove or modify other URSP rules that reference the forbidden traffic descriptor. After the UE <NUM> receives <NUM> the updated URSP rules and detects <NUM> outgoing traffic, the UE <NUM> can apply <NUM> the received updated URSP rules, which no longer reference TDF. In this manner, the UE <NUM> prevents the use of a traffic descriptor to application to URSP rules.

According to the claimed invention, a method in a core network, CN, for facilitating routing of outgoing traffic at a user equipment, UE, is provided, the method comprising:receiving, by the CN, an indication of a proscribed traffic descriptor to be excluded from application of rules defined by the CN that specify route selection for outgoing traffic at the UE; and preventing, by the CN, use of the proscribed traffic descriptor for application of a rule of a set of rules specifying route selection to the outgoing traffic at the UE.

<FIG> is a messaging diagram of an example scenario <NUM> in which the UE <NUM> of <FIG> notifies the CN <NUM> of a forbidden traffic descriptor using an indication of the current state of the UE or a dedicated message defined specifically for reporting forbidden traffic descriptors. The UE <NUM> determines <NUM> a forbidden traffic descriptor TDF and transmits <NUM> a message indicating the forbidden traffic descriptor TDF. The message may be for example a UE State Indication message with a field specifying the traffic descriptor TDF. As a more particular example, the UE <NUM> can include traffic descriptor TDF in the Policy Classmark IE of the UE State Indication message. In other implementations, the message the UE <NUM> transmits <NUM> may be a of message defined specifically for reporting forbidden traffic descriptors.

In response to receiving <NUM> a message indicating the forbidden traffic descriptor TDF, the CN <NUM> transmits <NUM> URSP rules to the UE <NUM> using a Manage UE Policy Command message or another suitable message. The UE <NUM> later detects <NUM> outgoing traffic and applies <NUM> the URSP rules to the detected outgoing traffic. Because the URSP rules do not reference TDF in view of event <NUM>, the UE <NUM> has prevented the use of a traffic descriptor to application to URSP rules.

In some cases, the CN <NUM> may ignore or may not support the message or IE the UE <NUM> uses to specify the forbidden traffic descriptors, or the CN <NUM> may transmit an URSP policy with rules that reference TDF prior to receiving an indication that TDF is forbidden, effectively creating a race condition between events <NUM> and <NUM>. The UE <NUM> in some implementations can apply the techniques discussed above with reference to <FIG> or <FIG> discussed below in combination with the technique of <FIG> or <FIG>, so as to prevent application of a rule received from the CN <NUM> and referencing a forbidden traffic descriptor.

<FIG> is a messaging diagram of an example scenario <NUM> in which the UE <NUM> of <FIG> prioritizes a local rule that references a range of traffic descriptors that includes a forbidden traffic descriptor over a rule received from the CN <NUM>. As indicated above, URSP rules in general may originate at the UE <NUM> (e.g., from the manufacturer) or the PCF <NUM> of the CN <NUM>. Local URSP rules, when available, can be stored in the memory <NUM> of the UE <NUM>.

The UE <NUM> in this scenario determines <NUM> a forbidden descriptor TDF, similar to events <NUM> and <NUM>. The UE <NUM> also retrieves <NUM> a local rule RL that does not explicitly reference the forbidden traffic descriptor but applies to traffic that includes the forbidden traffic descriptor. For example, local rule RL may reference a range <MAT> of traffic descriptors, where TDF belongs to range <MAT> (i.e. <MAT>). In one scenario, TDF may correspond to a particular application identifier, whereas range <MAT> may correspond to multiple application identifiers. The UE <NUM> then receives <NUM> from the CN <NUM> one or more URSP rules including a rule RCN(TDF). In this implementation, the UE <NUM> receives a Manage UE Policy Command message, but in general can receive any suitable indication. Also, although events <NUM> and <NUM> occur prior to event <NUM> in this scenario, events <NUM> and <NUM> alternatively may occur after event <NUM>.

After the UE <NUM> detects <NUM> outgoing traffic, the UE <NUM> determines which URSP rules the UE <NUM> should apply to the outgoing traffic. The UE <NUM> prioritizes <NUM> rule RL over rule RCN received from the CN <NUM>. The UE <NUM> can prioritize RL by modifying the rule precedence field (see <FIG>) of rule RL or rule RCN so that rule RL has a higher priority than rule RCN. If the UE <NUM> raises the priority of rule RL relative to rule RCN, the UE <NUM> applies <NUM> rule RL prior to applying rule RCN, thereby masking out rule RCN when rule RCN references only one or more forbidden traffic descriptors. In other words, by applying <NUM> rule RL to the outgoing traffic, the UE <NUM> ignores rule RCN. When RCN additionally references one or more other, permissible traffic descriptors, the UE <NUM> still applies rule RL prior to rule RCN, but does not mask out the entirety of rule RCN. The UE <NUM> still applies rule RCN based on the one or more permissible traffic descriptors.

Further, in some implementations, the UE <NUM> identifies and retrieves a local configuration including one or more local rules and prioritizes each of these local rules over all rules received from the CN <NUM>. In other implementations, the UE <NUM> prioritizes local rules over only those rules received from the CN <NUM> that include a forbidden traffic descriptor.

In some cases, the techniques discussed with reference to <FIG> and <FIG> can be combined. For example, the UE <NUM> may receive from the CN <NUM> a set of URSP rules including rule RA(TDF, TDP), with both a forbidden traffic descriptor TDF and a permissible traffic descriptor TDP, as well as rule RB(TDF), which includes only a forbidden traffic descriptor. The UE <NUM> may apply rule RA in the manner discussed with reference to <FIG>, i.e., by applying RA based on permissible traffic descriptor TDP and not using forbidden traffic descriptor TDF. Instead of applying RB, the UE <NUM> may ignore RB, as in <FIG>, or may prioritize a local rule RL over rule RB so that the UE <NUM> applies RL before applying rule RB, as occurs in the scenario of <FIG>.

Generally speaking, the techniques discussed above with reference to <FIG> can provide different advantages. For example, by preventively notifying the CN <NUM> of one or more forbidden traffic descriptors as illustrated in <FIG> and <FIG>, the UE <NUM> in some implementations can reduce the size of a rule policy (e.g., URSP) the CN <NUM> provides to the UE <NUM> as well as simplify rule processing at the UE <NUM>. On the other hand, the techniques of <FIG>, <FIG>, and <FIG> do not require that the UE <NUM> and the CN <NUM> exchange a message <NUM> or <NUM>, and thus reduce the amount of messaging during configuration. The UE <NUM> and/or the CN <NUM> can selectively apply these techniques in view of network conditions, for example.

For further clarity, <FIG> illustrates a flow diagram of an example method <NUM> for routing outgoing traffic, which can be implemented in the UE <NUM> of <FIG>. The method <NUM> begins at block <NUM>, where the UE <NUM> determines a proscribed or forbidden traffic descriptor in outgoing traffic which the UE <NUM> is to match to the rules received from the CN <NUM> (see, e.g., events <NUM> in <FIG> and <FIG>, event <NUM> in <FIG> and <FIG>, or event <NUM> in <FIG>).

The method <NUM> in at least some of the implementations includes block <NUM>, where the UE <NUM> receives from the CN <NUM> one or more rules specifying route selection for outgoing traffic (see, e.g., event <NUM> in <FIG>, event <NUM> in <FIG>, event <NUM> in <FIG> , event <NUM> in <FIG>, or event <NUM> in <FIG>). The UE <NUM> can execute blocks <NUM> and <NUM> in either order.

At block <NUM>, the UE <NUM> prevents the use of the proscribed traffic descriptor for application of one or more rules to outgoing traffic. To this end, the UE <NUM> can receive URSP rules from the CN <NUM> and ignore URSP rules that include a forbidden traffic descriptor (see. , e.g., event <NUM> in <FIG>). Additionally or alternatively, the UE <NUM> can apply a received URSP rule based only on the permissible traffic descriptor(s) the rule includes (see, e.g., event <NUM> in <FIG>). Additionally or alternatively, the UE <NUM> can request that the CN <NUM> modify the policy in view of a forbidden traffic descriptor and receive a set of updated rules (see, e.g., events <NUM> and <NUM> in <FIG>) or preempt transmission of rules referencing a forbidden traffic descriptor from the CN <NUM> (see, e.g., event <NUM> in <FIG>). Additionally or alternatively, the UE <NUM> can prioritize a local configuration or local rule over a rule received from the CN <NUM> (see, e.g., event <NUM> in <FIG>).

<FIG> is a flow diagram of an example method <NUM> for facilitating the outgoing traffic at a UE, which can be implemented in the CN <NUM> of <FIG>. The method <NUM> begins at step <NUM>, where the CN receives from a UE <NUM> an indication of a proscribed traffic descriptor which the UE <NUM> matches to rules that specify route selection for outgoing traffic (see, e.g., event <NUM> in <FIG> or event <NUM> in <FIG>). In general, the CN <NUM> can receive a message that conforms to a protocol for providing a routing policy to the UE <NUM>, a message that indicates the current state of the UE <NUM>, or a dedicated message defined specifically for the purpose of indicating forbidden traffic descriptors to the CN <NUM>.

At block <NUM>, the CN <NUM> prevents the use of the traffic descriptor for application of a rule specifying route selection to outgoing traffic at the UE <NUM>. The CN <NUM> may prevent the use of the traffic descriptor by modifying one or more URSP rules for the UE <NUM> to remove the forbidden traffic descriptor (see, e.g., event <NUM> in <FIG> or <FIG>). As discussed above, the CN <NUM> can remove from the URSP all rules that reference the forbidden traffic descriptor prior to transmitting the rules to the UE <NUM>, and/or the CN <NUM> can modify one or more rules that reference the forbidden traffic descriptor by removing the forbidden traffic descriptor or replacing the forbidden traffic descriptor with a permissible traffic descriptor.

The following additional considerations apply to the foregoing discussion.

A user device in which the techniques of this disclosure can be implemented (e.g., the UE <NUM>) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media-streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of-things (IoT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc..

Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may can be software modules (e.g., code, or machine-readable instructions stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.) to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

Claim 1:
A method (<NUM>) of routing outgoing traffic in a user equipment, UE (<NUM>), that communicates with a core network, CN (<NUM>), via a radio access network, RAN (<NUM>), the method comprising:
receiving (<NUM>), by the UE (<NUM>) from the CN (<NUM>), a set of rules specifying route selection for outgoing traffic at the UE (<NUM>); and
preventing (<NUM>), by the UE (<NUM>), application of a first rule of the set of rules to the outgoing traffic in response to determining that the first rule references a proscribed traffic descriptor and does not reference any other traffic descriptors.