Patent ID: 12238634

DETAILED DESCRIPTION OF THE DRAWINGS

FIG.1illustrates an example communication system100in which the routing techniques of this disclosure can be implemented. The communication system100includes a user equipment (UE)102, which can be any suitable device capable of wireless communications with a core network (CN)110via a base station104.

Generally speaking, the UE102can determine that certain traffic descriptors associated with rules that specify route selection for outgoing traffic at the UE102are proscribed (or “forbidden”), and that the UE102should 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 UE102can 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 UE102can determine that a rule contains both proscribed and non-proscribed, or permissible, traffic descriptors. The UE102then 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 UE102is allowed to prioritize a local configuration over URSP rules received from the CN110. For instance, the UE102can 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 CN110.

Still further, the UE102can preemptively request that the CN110not supply the UE102with any URSP rules that include the proscribed traffic descriptors. For example, the UE102can determine that a certain traffic descriptor is proscribed and transmit a corresponding indication to the CN110. To this end, the UE102can 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 UE102sends an indication of a proscribed traffic descriptor to the CN110, but the CN110nevertheless responds with URSP rules containing proscribed traffic descriptors (for example, due to a race condition or because the CN110does not support the message from the UE102), the UE102can apply the other techniques discussed above to prevent application of any rules that contain forbidden traffic descriptors. As another example, the UE102can 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 UE102can consider the rules that reference one or more proscribed traffic descriptors as inapplicable.

As illustrated inFIG.1, the base station104is communicatively connected to a core network (CN)110via an NG interface, for example. In some implementations, the base station104is a 5G New Radio (NR) base station operating as a g Node B (gNB), and the CN110is a 5G core network (5GC). In other implementations, however, the communication system100can 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 UE102also may have direct access via a radio interface to other types of access networks, such as a wireless local area network (WLAN)112(via an access point (AP)114, for example).

The base station104is associated with a RAN108and provides coverage to a cell116. WhileFIG.1depicts the base station104as associated with only one cell116, it is understood that the base station104may also cover one or more additional cells not shown inFIG.1. Further, the RAN108can include any suitable number of base stations that collectively support one or more RATs. The UE102can communicatively connect with the RAN108via base station104when operating within cell116, and in turn can communicatively connect with the CN110via the RAN108.

The UE102is equipped with processing hardware130, which can include one or more general-purpose processors (e.g., CPUs) and at least one non-transitory computer-readable memory132storing instructions executable on the one or more general processors and/or special-purpose processing units. The memory132stores an operating system (OS)140of the UE102, which can be any type of suitable mobile or general-purpose operating system. In addition, the memory132may also store one or more applications142. In operation, the one or more applications142generate 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 station104, the CN110, and various remote hosts, the UE102implements a communication protocol stack that includes an upper layer136and an NAS/URSP handling layer134. The layers134and136can be implemented using any suitable combination of hardware, software, and firmware. In one example implementation, the layers134and136are a set of instructions that the processing hardware130executes to perform the rule application techniques discussed herein.

The upper layer136can identify outgoing traffic at the UE and provide outgoing traffic to the NAS/URSP handling layer134for routing. The NAS/URSP handling layer134can 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 layer134can manage the application of rules for routing outgoing traffic at the UE102, as described in further detail below. When the upper layer136determines that an application142executing on the UE102has queued outgoing data for transmission, the upper layer136can direct the NAS/URSP handling layer134to apply one or more URSP rules and route the outgoing application traffic accordingly.

The NAS/URSP handling layer134in an example implementation includes a UE rule controller138configured to manage or control application of rules for routing outgoing traffic, and prevent application of proscribed traffic descriptors.

The CN110can be, for example, a 5G core network (5GC), a less advanced core network (e.g., an evolved packet core (EPC)) or, conversely, a more advanced core network. The CN110may be equipped with a mobility management entity such as Access and Mobility Management Function (AMF)122configured to manage authentication, registration, mobility, and other related functions, and a policy control entity such as Policy Control Function (PCF)124for providing policies for mobility and session management. The CN110also may include a CN rule controller128configured to manage, modify, and transmit to the UE102(and other UEs) various rules for routing outgoing traffic at the UE102, such as a set of rules associated with an URSP. The CN rule controller128can operate as a separate entity or as a component of the PCF124, depending on the implementation. In some scenarios, the PCF124provides to the UE102a policy in accordance with which the UE102should route outgoing traffic. This policy can be include a set of rules that conform to the URSP, discussed in more detail below with reference toFIG.2.

With continued reference toFIG.1, the CN110communicatively connects UE102, via the RAN108including the base station104(and typically multiple other base stations), to various communication networks including a wide area network such as the Internet150. More specifically, the CN110can directly connect to a data network via an access point name (APN) or data network name (DNN) gateway152. The UE102can include outgoing traffic with a traffic descriptor that identifies the gateway152, and the CN110can provide a rule that references the gateway152. When the UE102determines that the traffic descriptor referencing the gateway152is permissible, the UE rule controller138applies the rule and routes the outgoing traffic in accordance with the rule. Otherwise, when the UE102determines that the traffic descriptor referencing the gateway152is proscribed, the UE rule controller138ignores 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 domain156, a particular host154(e.g., by host name or Internet Protocol (IP) address), type of traffic (e.g., Ethernet), etc.

FIG.2is a block diagram of an example rule200for route selection which the UE102ofFIG.1can apply to outgoing traffic to determine how the UE102should route outgoing traffic. A route selection policy, such as a URSP received from CN110or a local configuration stored at the UE102, includes one or more rules that conform to the format ofFIG.2. The example rule200includes a rule precedence212, a traffic descriptor214, and a route selection descriptor216. In general, rules may include one or more traffic descriptors and one or more route selection descriptors.

The rule precedence field212specifies the order in which the UE102applies the rule200relative to other rules. In some implementations, the rule precedence212of each rule is different from the rule precedence of every other rule within the URSP. Traffic descriptors specify how the UE102should match outgoing traffic to the rule. For example, if the traffic descriptor214of rule200matches the parameters of outgoing traffic, then the UE102would apply rule200to the outgoing traffic. A URSP can include a rule with lowest precedence that has a “match all” traffic descriptor that UE102can apply to any outgoing traffic.

Traffic descriptors may include, for example, application identifiers of applications142executing on the OS140of the UE102. As another example, traffic descriptors may also correspond to IP descriptors such as an IP destination and/or an IP 3 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 gateway152. Traffic descriptors also may correspond to various connection capabilities of the UE102, 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 domain156), a hostname (e.g., of host154), or a fully qualified domain name (FQDN) made up of a domain name and a hostname.

The route selection descriptor214specifies how the UE102should route the traffic if the rule applies. For example, the route selection descriptor216may specify that the UE102should route traffic matching the traffic descriptor214of the rule200to an already-established communication session, such as an established Protocol Data Unit (PDU) session. As another example, the route selection descriptor216may instruct the UE102to establish a new PDU session for outgoing traffic matching the rule200. As yet another example, the route selection descriptor216may instruct the UE102to offload outgoing traffic matching the rule200to a wireless local area network (WLAN) such as a WiFi® network.

In an example scenario, a URSP includes three rules. Rule R1may have a rule precedence of 1 and a traffic descriptor corresponding to application identifier App1. Rule R2may have a rule precedence of 2 and traffic descriptor corresponding to application identifier App2. Rule R3may have a rule precedence of 3 and traffic descriptor corresponding to the “match all” option. When the UE102has outgoing traffic, the UE102evaluates the rules in the order of rule precedence. Thus, the UE102in this scenario first determines whether it should apply rule R1to the outgoing traffic by determining whether the outgoing traffic matches the traffic descriptor of rule R1, i.e., if the outgoing traffic corresponds to traffic of App1. If the outgoing traffic corresponds to traffic of App1, the UE102applies rule R1to the outgoing traffic and routes the traffic in accordance with the one or more route selection descriptors of rule App1. If the outgoing traffic does not match the traffic descriptor of rule R1, the UE102determines whether it should apply rule R2, and so on.

FIG.3Ais a messaging diagram of an example scenario300in which the UE102ofFIG.1determines that it should not apply a certain traffic descriptor for routing outgoing traffic at the UE102, and ignores a rule received from the CN110that references only this proscribed (or “forbidden”) traffic descriptor TDF. For simplicity, this discussion refers to the forbidden traffic descriptor TDFin the singular. However, the UE102in general can identify any suitable number of forbidden descriptors.

The NAS/URSP handling layer134identifies or determines302the 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 UE102may 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 layer134or a connection manager of the UE102, 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 OS140may inform the NAS/URSP handling layer134of the outgoing traffic parameters the UE102should not use when applying the URSP rules.

The UE102also may determine that certain traffic parameters are forbidden based on instructions stored on or received at the UE102. Such instructions may originate for example from the manufacturer of the UE102, a hardware component of the UE102, a firmware or software component of the UE102, the OS140, etc. AlthoughFIG.3Adepicts event302as occurring prior to event310, in other implementations or scenarios event302can occur after event310. In other words, the UE102may make the determination302after receiving310the URSP rules from the CN.

With continued reference toFIG.3A, the UE102receives310a message including URSP rules from the CN110. 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 RCNwith at least one forbidden traffic descriptor TDF. In some implementations, all of the traffic descriptors of rule RCNmay be forbidden. In general, the message of event310can 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 layer136provides320outgoing traffic to the NAS/URSP handling layer134. In response, the NAS/URSP handling layer134applies330the URSP rules to the outgoing traffic, subject to the restriction that the UE102cannot match outgoing traffic to the traffic descriptor TDF. More specifically, in this implementation, the NAS/URSP handling layer134prevents the application of TDFto the outgoing traffic by ignoring rule RCN.

FIG.3Bis a messaging diagram of an example scenario350in which the UE102ofFIG.1receives 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 toFIG.3A, the UE102determines302forbidden traffic descriptor TDFprior to or after receiving the URSP rules from the CN110. However, the UE102in this scenario receives311a message with URSP rules that include a rule RCNthat includes both a forbidden traffic descriptor TDFand a permissible traffic descriptor TDP, from the CN110. After the UE102detects320outgoing traffic, the UE102does not use TDFfor matching the outgoing traffic to the URSP rules. More particularly, the UE102ignores332TDFand uses only TDPfor matching the outgoing traffic to RCN. Thus, the UE102still applies RCNto the outgoing traffic, but does so based on the permissible traffic descriptor TDPrather than the forbidden traffic descriptor TDF.

Now referring toFIG.4A, in an example scenario400the UE102notifies the CN110of a forbidden traffic descriptor using a message of a protocol for delivering a route selection policy. Events402and410are similar to events302and310, respectively. In response to receiving a RCN(TDF) including only a forbidden traffic descriptor (or several forbidden traffic descriptors), the UE102transmits412a message to the CN110notifying the CN110of the forbidden traffic descriptor TDF. Alternatively, the message can identify rule RCN. The UE102in this example includes412an indication of TDFand/or RCNin a cause information element (IE) of a Manage UE Policy Command Reject message.

In response to receiving412the Manage UE Policy Command Reject message, the CN110may modify the URSP rules and transmit414updated URSP rules to the UE110as another instance of the Manage UE Policy Command message for example. In some implementations, the CN110removes rule RCNfrom the URSP before transmitting414the updated URSP to the UE102. Alternatively, the CN110may modify RCNby removing TDFbut retaining one or more permissible traffic descriptors. The CN110similarly can remove or modify other URSP rules that reference the forbidden traffic descriptor. After the UE102receives414the updated URSP rules and detects420outgoing traffic, the UE102can apply434the received updated URSP rules, which no longer reference TDF. In this manner, the UE102prevents the use of a traffic descriptor to application to URSP rules.

FIG.4Bis a messaging diagram of an example scenario450in which the UE102ofFIG.1notifies the CN110of 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 UE102determines402a forbidden traffic descriptor TDFand transmits404a 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 UE102can include traffic descriptor TDFin the Policy Classmark IE of the UE State Indication message. In other implementations, the message the UE102transmits414may be a of message defined specifically for reporting forbidden traffic descriptors.

In response to receiving404a message indicating the forbidden traffic descriptor TDF, the CN110transmits414URSP rules to the UE102using a Manage UE Policy Command message or another suitable message. The UE102later detects420outgoing traffic and applies434the URSP rules to the detected outgoing traffic. Because the URSP rules do not reference TDFin view of event404, the UE102has prevented the use of a traffic descriptor to application to URSP rules.

In some cases, the CN110may ignore or may not support the message or IE the UE102uses to specify the forbidden traffic descriptors, or the CN110may transmit an URSP policy with rules that reference TDFprior to receiving an indication that TDFis forbidden, effectively creating a race condition between events404and414. The UE102in some implementations can apply the techniques discussed above with reference toFIGS.3A-BorFIG.5discussed below in combination with the technique ofFIG.4AorFIG.4B, so as to prevent application of a rule received from the CN110and referencing a forbidden traffic descriptor.

FIG.5is a messaging diagram of an example scenario500in which the UE102ofFIG.1prioritizes a local rule that references a range of traffic descriptors that includes a forbidden traffic descriptor over a rule received from the CN110. As indicated above, URSP rules in general may originate at the UE102(e.g., from the manufacturer) or the PCF124of the CN110. Local URSP rules, when available, can be stored in the memory132of the UE102.

The UE102in this scenario determines502a forbidden descriptor TDF, similar to events302and402. The UE102also retrieves503a local rule RLthat does not explicitly reference the forbidden traffic descriptor but applies to traffic that includes the forbidden traffic descriptor. For example, local rule RLmay reference a rangeTDof traffic descriptors, where TDFbelongs to rangeTD(i.e. TDF∈TD). In one scenario, TDFmay correspond to a particular application identifier, whereas rangeIDmay correspond to multiple application identifiers. The UE102then receives510from the CN110one or more URSP rules including a rule RCN(TDF). In this implementation, the UE102receives a Manage UE Policy Command message, but in general can receive any suitable indication. Also, although events502and503occur prior to event510in this scenario, events502and503alternatively may occur after event510.

After the UE102detects520outgoing traffic, the UE102determines which URSP rules the UE102should apply to the outgoing traffic. The UE102prioritizes533rule RLover rule RCNreceived from the CN110. The UE102can prioritize RLby modifying the rule precedence field (seeFIG.2) of rule RLor rule RCNso that rule RLhas a higher priority than rule RCN. If the UE102raises the priority of rule RLrelative to rule RCN, the UE102applies536rule RLprior to applying rule RCN, thereby masking out rule RCNwhen rule RCNreferences only one or more forbidden traffic descriptors. In other words, by applying 536 rule RLto the outgoing traffic, the UE102ignores rule RCN. When RCNadditionally references one or more other, permissible traffic descriptors, the UE102still applies rule RLprior to rule RCN, but does not mask out the entirety of rule RCN. The UE102still applies rule RCNbased on the one or more permissible traffic descriptors.

Further, in some implementations, the UE102identifies and retrieves a local configuration including one or more local rules and prioritizes each of these local rules over all rules received from the CN110. In other implementations, the UE102prioritizes local rules over only those rules received from the CN110that include a forbidden traffic descriptor.

In some cases, the techniques discussed with reference toFIGS.3A-3BandFIG.5can be combined. For example, the UE102may receive from the CN110a set of URSP rules including rule RA(TDF, TDP), with both a forbidden traffic descriptor TDFand a permissible traffic descriptor TDP, as well as rule RB(TDF), which includes only a forbidden traffic descriptor. The UE102may apply rule RAin the manner discussed with reference toFIG.3B, i.e., by applying RAbased on permissible traffic descriptor TDPand not using forbidden traffic descriptor TDF. Instead of applying RB, the UE102may ignore RB, as inFIG.3A, or may prioritize a local rule RLover rule RBso that the UE102applies RLbefore applying rule RB, as occurs in the scenario ofFIG.5.

Generally speaking, the techniques discussed above with reference toFIGS.3A-5can provide different advantages. For example, by preventively notifying the CN110of one or more forbidden traffic descriptors as illustrated inFIGS.4A and4B, the UE102in some implementations can reduce the size of a rule policy (e.g., URSP) the CN110provides to the UE102as well as simplify rule processing at the UE102. On the other hand, the techniques ofFIGS.3A,3B, and5do not require that the UE102and the CN110exchange a message404or412, and thus reduce the amount of messaging during configuration. The UE102and/or the CN110can selectively apply these techniques in view of network conditions, for example.

For further clarity,FIG.6illustrates a flow diagram of an example method600for routing outgoing traffic, which can be implemented in the UE102ofFIG.1. The method600begins at block602, where the UE102determines a proscribed or forbidden traffic descriptor in outgoing traffic which the UE102is to match to the rules received from the CN102(see, e.g., events302inFIGS.3A and3B, event402inFIGS.4A and4B, or event502inFIG.5).

The method600in at least some of the implementations includes block604, where the UE102receives from the CN110one or more rules specifying route selection for outgoing traffic (see, e.g., event310inFIG.3A, event311inFIG.3B, event410inFIG.4A, event414inFIG.4B, or event510inFIG.5). The UE102can execute blocks602and604in either order.

At block606, the UE102prevents the use of the proscribed traffic descriptor for application of one or more rules to outgoing traffic. To this end, the UE102can receive URSP rules from the CN110and ignore URSP rules that include a forbidden traffic descriptor (see, e.g., event330inFIG.3A). Additionally or alternatively, the UE102can apply a received URSP rule based only on the permissible traffic descriptor(s) the rule includes (see, e.g., event332inFIG.3B). Additionally or alternatively, the UE102can request that the CN110modify the policy in view of a forbidden traffic descriptor and receive a set of updated rules (see, e.g., events412and414inFIG.4A) or preempt transmission of rules referencing a forbidden traffic descriptor from the CN110(see, e.g., event404inFIG.4B). Additionally or alternatively, the UE102can prioritize a local configuration or local rule over a rule received from the CN110(see, e.g., event533inFIG.5).

FIG.7is a flow diagram of an example method700for facilitating the outgoing traffic at a UE, which can be implemented in the CN110ofFIG.1. The method700begins at step702, where the CN receives from a UE102an indication of a proscribed traffic descriptor which the UE102matches to rules that specify route selection for outgoing traffic (see, e.g., event412inFIG.4Aor event404inFIG.4B). In general, the CN110can receive a message that conforms to a protocol for providing a routing policy to the UE102, a message that indicates the current state of the UE102, or a dedicated message defined specifically for the purpose of indicating forbidden traffic descriptors to the CN110.

At block704, the CN110prevents the use of the traffic descriptor for application of a rule specifying route selection to outgoing traffic at the UE102. The CN110may prevent the use of the traffic descriptor by modifying one or more URSP rules for the UE102to remove the forbidden traffic descriptor (see, e.g., event414inFIG.4AorFIG.4B). As discussed above, the CN110can remove from the URSP all rules that reference the forbidden traffic descriptor prior to transmitting the rules to the UE102, and/or the CN110can 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.

By way of example, and not limitation, the disclosure herein contemplates at least the following aspects:

Aspect 1. A method of routing outgoing traffic in a user equipment (UE) that communicates with a core network (CN) via a radio access network (RAN), the method comprising: determining, by processing hardware, 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 processing hardware, use of the proscribed traffic descriptor for application of a rule of a set of rules specifying route selection to the outgoing traffic.

Aspect 2. The method of aspect 1, wherein the rule is a first rule, and wherein preventing the application of the first rule includes: receiving, by the processing hardware, the first rule from the core network; and preventing the application of the first rule at the UE.

Aspect 3. The method of aspect 2, wherein preventing the application of the first rule further includes: ignoring the first rule in response to determining that the first rule references the proscribed traffic descriptor and does not reference any other traffic descriptors.

Aspect 4. The method of aspect 2 or 3, further comprising preventing use of the proscribed traffic descriptor for application of a second rule, wherein: the proscribed traffic descriptor is a first traffic descriptor; and preventing the application of the second rule includes: determining that the second rule references the first traffic descriptor and a second traffic descriptor; and applying the second rule to the outgoing traffic based on the second traffic descriptor and without using the first traffic descriptor.

Aspect 5. The method of aspect 2, wherein preventing the application of the first rule at the UE is in response to determining, by the processing hardware, that a memory of the UE stores a local configuration referencing a range that includes the proscribed traffic descriptor.

Aspect 6. The method of aspect 5, wherein preventing the application of the first rule includes assigning a higher priority to the local configuration than to the first rule received from the core network.

Aspect 7. The method of aspect 1, wherein preventing the application of the rule includes: sending, by the processing hardware, an indication of the proscribed traffic descriptor to the CN, wherein the CN, in response to the indication, excludes the rule from the set of rules sent to the UE, or modifies the rule to remove the proscribed traffic descriptor prior to sending the rule to the UE.

Aspect 8. The method of aspect 7, wherein sending the indication to the CN includes sending a message that conforms to a protocol for delivering a route selection policy between the CN and the UE, the message indicating that the UE has rejected the rule.

Aspect 9. The method of aspect 8, wherein the message includes an information element (IE) that specifies a cause for rejecting the rule at the UE.

Aspect 10. The method of aspect 7, wherein sending the indication to the CN includes sending a message that indicates a current state of the UE.

Aspect 11. The method of aspect 10, wherein the message includes an IE that specifies the proscribed traffic descriptor.

Aspect 12. The method of aspect 1, wherein determining the proscribed traffic descriptor includes determining that an entity operating within the UE and applying rules that specify route selection cannot access a type of parameter of the outgoing traffic to which the proscribed traffic descriptor corresponds.

Aspect 13. The method of any of the preceding aspects, wherein the rule includes a rule precedence to specify precedence of the rule relative to other rules that specify route selection, at the UE.

Aspect 14. The method of any of the preceding aspects, wherein the rule includes a route selection descriptor that indicates whether outgoing traffic to which the rule applies should be (i) offloaded to a wireless local area network, (ii) routed to an existing Protocol Data Unit (PDU) session, or (iii) routed to a new PDU session.

Aspect 15. The method any of the preceding aspects, wherein the proscribed traffic descriptor refers to one or more of: (i) an identifier of an application executing on an operating system (OS) of the UE, (ii) an Internet Protocol (IP) destination; (iii) a type of network traffic, (iv) a data network name (DNN), (v) connection capabilities of the UE, or (vi) a domain descriptor.

Aspect 16. The method of any of the preceding aspects, wherein the rule conforms to a UE Route Selection Policy (URSP) format.

Aspect 17. A user equipment (UE) comprising processing hardware and configured to execute a method according to any of the preceding aspects.

Aspect 18. A method in a core network (CN) for facilitating routing of outgoing traffic at a user equipment (UE), the method comprising: receiving, by processing hardware, 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 processing hardware, 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.

Aspect 19. The method of aspect 18, wherein receiving the indication includes receiving a message that conforms to a protocol for delivering a route selection policy between the CN and the UE, the message indicating that the UE has rejected the rule.

Aspect 20. The method of aspect 19, wherein the message includes an information element (IE) that specifies a cause for rejecting the rule at the UE.

Aspect 21. The method of aspect 18, wherein the indication to the CN includes receiving a message that indicates a current state of the UE.

Aspect 22. The method of aspect 21, wherein the message includes an IE that specifies the proscribed traffic descriptor.

Aspect 23. The method of aspect 18, wherein the rule is a first rule, and wherein the preventing includes not sending the first rule to the UE, wherein the first rule references the proscribed traffic descriptor and does not reference any other traffic descriptors.

Aspect 24. The method of aspect 18 or 23, wherein: a second rule of the set of rules references the proscribed traffic descriptor and at least one other traffic descriptor; and the preventing includes preventing use of the proscribed traffic descriptor for application of the second rule by: modifying the second rule so that the second rule does not reference the proscribed traffic descriptor, and sending the modified second rule to the UE.

Aspect 25. The method of any of aspects 18-24, wherein the rule conforms to a UE Route Selection Policy (URSP) format.

Aspect 26. A system comprising processing hardware and configured to execute a method according to any of aspects 18-25.

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 UE102) 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. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software 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.

When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more special-purpose processors.