Method and apparatus for data network name selection in mobile communications

Solutions for data network name (DNN) selection when user equipment (UE) route selection policy (URSP) rule is applied in evolved packet system (EPS) with respect to user equipment and network apparatus in mobile communications are described. An apparatus may start an application in an EPS network. The apparatus may select a URSP rule from one or more configured URSP rules by matching a traffic descriptor (TD) of the URSP rule with the application. The apparatus may determine whether a data network name (DNN) or access point name (APN) included in a route selection descriptor (RSD) is a local area data network (LADN) DNN or APN. The apparatus may skip the RSD in an event that the DNN or APN is the LADN DNN or APN. The apparatus may evaluate a next RSD or a next URSP rule in case that the next RSD or the next URSP rule is available.

TECHNICAL FIELD

The present disclosure is generally related to mobile communications and, more particularly, to data network name (DNN) selection when user equipment (UE) route selection policy (URSP) rule is applied in evolved packet system (EPS) with respect to user equipment and network apparatus in mobile communications.

BACKGROUND

The UE policies for 5thgeneration system (5GS) include URSP and access network discovery and selection policy (ANDSP). The UE policies can be delivered form a policy control function (PCF) to the UE. The PCF takes care of network policies to manage network behavior. The PCF gets the subscription information from unified data management (UDM). The PCF interfaces to both access and mobility function (AMF) to manage the mobility context and session management function (SMF) to manage the session contexts. The PCF also plays a crucial role in providing a schema for network slicing and roaming. The PCF triggers the URSP which enables the UE to determine how a certain application should be handled in the context of an existing or new protocol data unit (PDU) session. The UE policies can also be pre-configured in the UE. The pre-configured policy should be applied by the UE only when the UE has not received the same type of policy from the PCF.

A PDU session defines the association between the UE and the data network that provides a PDU connectivity service. Each PDU session is identified by a PDU session ID, and includes one or more quality of service (QoS) flows and QoS rules. When the upper layers request information of the PDU session via which to send a PDU of an application, the UE should evaluate the URSP rules, except the default URSP rule, with a traffic descriptor matching the application information in increasing order of their precedence values. If the UE finds the traffic descriptor in a non-default URSP rule matching the application information, and an established PDU session matching at least one of the route selection descriptors of the URSP rule, the UE then provides information on the PDU session that matches the route selection descriptor of the lowest precedence value to the upper layers. Otherwise the UE selects a route selection descriptor with the next smallest precedence value which has not been evaluated.

It is agreed in the 3GPP specification that the 5GS URSP rules may be applied to EPS PDN connection as well. When the UE is in EPS, after inter-system change from 5GS to EPS, the UE is allowed to use the URSP rules, to derive corresponding parameters for establishing PDN connections when UE is attached to Evolved Packet Core (EPC). However, the DNN included in the route selection descriptor might be a local area data network (LADN) DNN. The LADN DNN is not defined in the EPS and thus the UE handling for the LADN DNN is not specified. It is not clear to the UE how to handle the LADN DNN when it is detected. The UE behavior is undefined that could cause error or malfunction when performing the URSP matching procedure in EPS.

Accordingly, how to design clear procedures to avoid error or malfunction when the URSP rule is applied in EPS network becomes an important issue in the newly developed wireless communication network. Therefore, there is a need to provide proper schemes to proceed the URSP matching procedure when the LADN DNN is detected.

SUMMARY

An objective of the present disclosure is to propose solutions or schemes that address the aforementioned issues pertaining to DNN selection when URSP rule is applied in EPS with respect to user equipment and network apparatus in mobile communications.

In one aspect, a method may involve an apparatus starting an application in an EPS network. The method may also involve the apparatus selecting a URSP rule from one or more configured URSP rules by matching a traffic descriptor of the URSP rule with the application. The method may further involve the apparatus determining whether a DNN or access point name (APN) included in a route selection descriptor is a LADN DNN or APN. The method may further involve the apparatus skipping the RSD in an event that the DNN or APN is the LADN DNN or APN. Then, the method may involve the apparatus evaluating a next RSD or a next URSP rule in an event that the next RSD or the next URSP rule is available.

In one aspect, an apparatus may comprise a transceiver which, during operation, wirelessly communicates with a network node of a wireless network. The apparatus may also comprise a processor communicatively coupled to the transceiver. The processor, during operation, may perform operations comprising starting an application in an EPS network. The processor may also perform operations comprising selecting a URSP rule from one or more configured URSP rules by matching a traffic descriptor of the URSP rule with the application. The processor may further perform operations comprising determining whether a DNN or APN included in a route selection descriptor is a LADN DNN or APN. The processor may further perform operations comprising skipping the RSD in an event that the DNN or APN is the LADN DNN or APN. Then, the processor may perform operations comprising evaluating a next RSD or a next URSP rule in an event that the next RSD or the next URSP rule is available.

It is noteworthy that, although description provided herein may be in the context of certain radio access technologies, networks and network topologies such as Long-Term Evolution (LTE), LTE-Advanced, LTE-Advanced Pro, 5th Generation (5G), New Radio (NR), Internet-of-Things (IoT), Narrow Band Internet of Things (NB-IoT) and Industrial Internet of Things (IIoT), the proposed concepts, schemes and any variation(s)/derivative(s) thereof may be implemented in, for and by other types of radio access technologies, networks and network topologies. Thus, the scope of the present disclosure is not limited to the examples described herein.

DETAILED DESCRIPTION OF PREFERRED IMPLEMENTATIONS

Overview

Implementations in accordance with the present disclosure relate to various techniques, methods, schemes and/or solutions pertaining to DNN selection when URSP rule is applied in EPS with respect to user equipment and network apparatus in mobile communications. According to the present disclosure, a number of possible solutions may be implemented separately or jointly. That is, although these possible solutions may be described below separately, two or more of these possible solutions may be implemented in one combination or another.

FIG. 1illustrates an exemplary 5G network100supporting URSP rule matching in accordance with implementations of the present disclosure. 5G NR network100may comprise a UE101, a base station gNB102, an access and mobility management function (AMF)103, a session management function (SMF)104, a policy control function (PCF)105, and a unified data management (UDM)106. In the example ofFIG. 1, UE101and its serving base station gNB102belong to part of a radio access network (RAN)120. In the access stratum (AS) layer, RAN120may provide radio access for UE101via a radio access technology (RAT). In non-access stratum (NAS) layer, AMF103may communicate with gNB102, SMF104, PCF105and UDM106for access and mobility management of wireless access devices in 5G network100. UE101may be equipped with a radio frequency (RF) transceiver or multiple RF transceivers for different application services via different RATs/core networks (CNs). UE101may be implemented as a smart phone, a wearable device, an Internet of Things (IoT) device, a tablet, a vehicle, etc.

5GS networks are packet-switched (PS) Internet Protocol (IP) networks. This means that the networks deliver all data traffic in IP packets, and provide users with always-on IP connectivity. When the UE joins a 5GS network, a packet data network (PDN) address (i.e., the one that can be used on the PDN) is assigned to the UE for its connection to the PDN. In 4G, EPS has defined a default EPS bearer to provide the IP connectivity that is always-on. In 5G, a PDU session establishment procedure is a parallel procedure of a PDN connection procedure in 4G. A PDU session (e.g.,130) defines the association between the UE and the data network that provides a PDU connectivity service. Each PDU session is identified by a PDU session ID, and may include multiple QoS flows and QoS rules.

The UE policies for 5GS include URSP and ANDSP. The URSP may be used by the UE to determine how to route outgoing traffic. For example, traffic can be routed to an established PDU Session, can be offloaded to non-3GPP access outside a PDU Session, or can trigger the establishment of a new PDU Session. The ANDSP may be used by the UE for selecting non-3GPP accesses network. The UE policies can be delivered form the PCF to the UE. The PCF takes care of network policies to manage network behavior. The PCF gets the subscription information from the UDM. PCF interfaces to both the AMF to manage the mobility context and the SMF to manage the session contexts. The PCF also plays a crucial role in providing a scheme for network slicing and roaming. The PCF triggers the URSP which enables the UE to determine how a certain application should be handled in the context of an existing or new PDU session. The UE policies may also be pre-configured in UE. The pre-configured policy should be applied by UE only when UE has not received the same type of policy from the PCF.

When the UE starts an application, UE upper layers may trigger URSP rule matching. The UE may evaluate the URSP rules, except the default URSP rule, with a traffic descriptor (TD) matching the application information in increasing order of their precedence values. In an event that the UE finds the TD in a non-default URSP rule matching the application information, and an established PDU session matching at least one of the route selection descriptors (RSDs) of the URSP rule, the UE may provide information of the PDU session that matches the route selection descriptor of the lowest precedence value to the upper layers. Otherwise the UE may select an route selection descriptor with the next smallest precedence value which has not been evaluated.

If no non-default matching URSP rule can be found and if UE local configuration for the application is available, the UE should perform the association of the application to a PDU session accordingly. If no matching PDU session exists, the UE NAS layer should attempt to establish a PDU session using UE local configuration. If the PDU session establishment is successful, the UE NAS layer should provide information of the successfully established PDU session to the upper layers. Otherwise, if no non-default matching URSP rule can be found and if either UE local configuration for the application is not available or the PDU session establishment based on UE local configuration for the application fails, the UE should perform the association of the application to a PDU session or to non-seamless non-3GPP offload according to the default URSP rule with the “match-all” TD. If the association is unsuccessful, the UE may inform the upper layers of the failure.

FIG. 2illustrates the content of a URSP rule as defined in 3GPP specification. The URSP is defined as a set of one or more URSP rules. As depicted by Table200, each URSP rule is composed of: 1) a precedence value of the URSP rule (e.g., Rule Precedence) identifying the precedence of the URSP rule among all the existing URSP rules; 2) a traffic descriptor; and 3) one or more route selection descriptors. The traffic descriptor includes at least one of the following components: A) one or more application identifiers; B) one or more IP3tuples (i.e., the destination IP address, the destination port number, and the protocol used above the IP); C) one or more domain descriptors (i.e., destination fully qualified domain name (FQDN)); D) one or more non-IP descriptors (i.e., destination information of non-IP traffic); E) one or more DNNs; and F) one or more connection capabilities. Only one URSP rule in the URSP can be a default URSP rule and the default URSP rule should contain a match-all traffic descriptor. If a default URSP rule and one or more non-default URSP rules are included in the URSP, any non-default URSP rule should have lower precedence value (i.e., higher priority) than the default URSP rule.

FIG. 3illustrates the content of a route selection descriptor as defined in 3GPP specification. The route selection descriptor is defined as a set of one or more route selection descriptors. As depicted by Table300, each route selection descriptor includes a precedence value of the route selection descriptor (e.g., Route Selection Descriptor Precedence) and one or more of the followings: A) SSC mode; B) one or more Single Network Slice Selection Assistance Information (S-NSSAIs); C) one or more DNNs; D) one PDU session type; E) non-seamless offload indication; F) preferred access type; and G) route selection validation criteria.

FIG. 4illustrates different layers inside a UE for supporting URSP rule matching in accordance with implementations of the present disclosure. The URSP is used by the UE to determine if a detected application can be associated to an established PDU session, can be offload to non-3GPP access outside a PDU session, or can trigger the establishment of a new PDU session. A URSP rule may include one traffic descriptor that specifies the matching criteria and one or more of the following components: SSC mode selection policy to associated the matching application with SSC mode, network slice selection policy to associated the matching application with S-NSSAI, DNN selection policy to associated the matching application with DNN, PDU session type policy to associated the matching application with a PDU session type, non-seamless offload policy to determine that the matching application should be non-seamlessly offloaded to non-3GPP access (i.e., out of a PDU session), and access type preference indicating a preferred access (3GPP or non-3GPP) when UE needs to establish a new PDU session for the matching application.

In the embodiment ofFIG. 4, to determine association between an application and a PDU session or non-seamless non-3GPP offload, UE upper layers may proceed with URSP rule matching. In step411, in increasing order of their precedence values, the UE may evaluate the URSP rules, except the default URSP rule, with a traffic descriptor matching the application information. For example, an application identifier included in the traffic descriptor matches with an application ID of the application. Is should be noted that if the traffic descriptor contains more than one component, then all of them need to be matched with the application information.

In an event that the UE finds the traffic descriptor in a non-default URSP rule matching the application information, in step421, UE may try to determine whether one or more PDU sessions that match at least one of the route selection descriptors of the URSP rule can be found. If the answer is yes, then UE may reuse the existing PDU session in step422and provide information on the PDU session that matches the route selection descriptor of the lowest precedence value to the upper layers. If the answer is no, then the UE may go to step431and the UE 5GSM layer may try to setup PDU with the same route selection descriptors. If the PDU session is successfully established, then the UE may go to step432and provides information on the newly established PDU session. Specifically, the UE NAS layer may indicate the attributes of the established PDU session (e.g., PDU session ID, SSC mode, S-NSSAI, DNN, PDU session type, access type, PDU address) to the URSP handling layer, and provides information (e.g., PDU address) of the established PDU session to the upper layers.

Otherwise, if step431fails, and if there are more route selection descriptors, UE may select a route descriptor with the next smallest precedence value which has not been evaluated and go to step421. If no more route selection descriptors for the URSP rule, then the UE may go back to step411and try to find a next non-default URSP rule having the next smallest precedence value, and with a traffic descriptor that matches the application information. The UE then continues with step421and step431to find the suitable PDU session for the next non-default URSP rule. If step431fails for all non-default URSP rule, then the UE may inform the upper layers of the failure in step441. If all non-default URSP rules cannot be matched with the application, then the UE may try the default URSP rule, which includes a match-all traffic descriptor.

It is agreed in the 3GPP specification that the 5G URSP rules may be applied to 4G PDN connection as well. When the UE is in EPS, after inter-system change from 5GS to EPS, the UE is allowed to use the URSP rules, to derive corresponding parameters for establishing PDN connections when UE is attached to EPC. However, the DNN included in the route selection descriptor might be a LADN DNN. The LADN DNN is not defined in the EPS and thus the UE handling for the LADN DNN is not specified. It is not clear to the UE how to handle the LADN DNN when it is detected. Therefore, the present disclosure proposes a number of schemes pertaining to DNN selection when the URSP rule is applied in EPS with respect to the UE and the network apparatus. According to the schemes of the present disclosure, the UE may be able to properly proceed the URSP matching procedure in EPS.

Specifically, when the UE starts an application in the EPS network, the UE may be configured to select a URSP rule from one or more configured URSP rules by matching a traffic descriptor of the URSP rule with the application. Then, the UE may determine whether a DNN or APN included in a route selection descriptor is a LADN DNN or APN. In an event that the DNN or APN is the LADN DNN or APN, the UE may be configured to skip the current route selection descriptor. Then, the UE may be configured to a next route selection descriptor or a next URSP rule in an event that the next route selection descriptor or the next URSP rule is available. In an event that no more route selection descriptor or URSP rule is available, the UE may further be configured to inform a failure to the upper layer.

In some implementation, the UE may select the route selection descriptor by taking UE's registration status into consideration. In matching a traffic descriptor of the URSP rule with the application, the UE may match application information of the application with the traffic descriptor in the URSP rule. In determining whether a DNN or APN is a LADN DNN or APN, the UE may determine whether a DNN selection parameter included in the route selection descriptor contains at least one LDAN DNN or APN. After matching one of route selection descriptors of the URSP rules, the UE may further associating the application with the PDU session or PDN connection and provide the information of the PDU session or PDN connection to the upper layer.

Alternatively, after detecting that a DNN/APN is a LADN DNN/APN, the UE may determine whether it is in the LADN service area. The UE may use this LADN DNN/APN to establish a PDN connection when the UE is in the LADN service area. The network may provide the LADN information to the UE in corresponding NAS messages.

In some implementations, the UE may be configured to determine whether a preferred access type included in the route selection descriptor is identical to an access type currently registered. In an event that the preferred access type is not the access type currently registered, the UE may be configured to skip this route selection descriptor or take this route selection descriptor as not available. The UE may try to evaluate a next route selection descriptor or URSP rule in an event that the next route selection descriptor or the next URSP rule is available. Alternatively, when the preferred access type is not the access type currently registered, the UE may try to register over the preferred access type and try to establish the PDU session/PDN connection. For example, the UE may be configured to select the route selection descriptor where a preferred access type is included. Then, the UE may try to register over the preferred access type and establish a PDU session or PDN connection. In an event that both the registration and the establishment are successful, the UE may provide information of the PDU session or PDN connection to the upper layer. In an event that the registration is failed or the registration is successful but the establishment is failed, the UE may inform the failure to the upper layer. Optionally, the UE may further deregister from the preferred access type in an event that the PDU session or PDN connection cannot be established successfully.

Illustrative Implementations

FIG. 5illustrates an example communication apparatus510and an example network apparatus520in accordance with an implementation of the present disclosure. Each of communication apparatus510and network apparatus520may perform various functions to implement schemes, techniques, processes and methods described herein pertaining to DNN selection when URSP rule is applied in EPS with respect to user equipment and network apparatus in wireless communications, including schemes described above as well as process600described below.

Communication apparatus510may be a part of an electronic apparatus, which may be a UE such as a portable or mobile apparatus, a wearable apparatus, a wireless communication apparatus or a computing apparatus. For instance, communication apparatus510may be implemented in a smartphone, a smartwatch, a personal digital assistant, a digital camera, or a computing equipment such as a tablet computer, a laptop computer, a notebook computer or a vehicle. Communication apparatus410may also be a part of a machine type apparatus, which may be an IoT, NB-IoT, or IIoT apparatus such as an immobile or a stationary apparatus, a home apparatus, a wire communication apparatus or a computing apparatus. Alternatively, communication apparatus510may be implemented in the form of one or more integrated-circuit (IC) chips such as, for example and without limitation, one or more single-core processors, one or more multi-core processors, one or more reduced-instruction set computing (RISC) processors, or one or more complex-instruction-set-computing (CISC) processors. Communication apparatus510may include at least some of those components shown inFIG. 5such as a processor512, for example. Processor512may further comprise protocol stacks and a set of system modules and circuits which may be implemented and configured by software, firmware, hardware, and/or combination thereof. The function modules and circuits, when executed by the processors via program instructions contained in memory514, interwork with each other to allow communication apparatus510to perform embodiments and functional tasks and features in the network. For example, system modules and circuits may comprise a PDU session handling circuit that performs PDU session establishment and modification procedures with network apparatus520, a policy control circuit that performs URSP rule matching, and a configuration and control circuit that handles configuration and control parameters for mobility management and session management. Communication apparatus510may further include one or more other components not pertinent to the proposed scheme of the present disclosure (e.g., internal power supply, display device and/or user interface device), and, thus, such component(s) of communication apparatus510are neither shown inFIG. 5nor described below in the interest of simplicity and brevity.

Network apparatus520may be a part of an electronic apparatus, which may be a network node such as a base station, a small cell, a router or a gateway. For instance, network apparatus520may be implemented in an eNodeB in an LTE, LTE-Advanced or LTE-Advanced Pro network or in a gNB in a 5G, NR, IoT, NB-IoT, IIoT or V2X network. Alternatively, network apparatus520may be implemented in the form of one or more IC chips such as, for example and without limitation, one or more single-core processors, one or more multi-core processors, or one or more RISC or CISC processors. Network apparatus520may include at least some of those components shown inFIG. 5such as a processor522, for example. Processor522may further include protocol stacks and a set of control functional modules and circuit. For example, a PDU session handling circuit may handle PDU session establishment and modification procedures. A policy control circuit may configure policy rules for communication apparatus510. A configuration and control circuit may provide different parameters to configure and control communication apparatus510of related functionalities including mobility management and session management. Network apparatus520may further include one or more other components not pertinent to the proposed scheme of the present disclosure (e.g., internal power supply, display device and/or user interface device), and, thus, such component(s) of network apparatus520are neither shown inFIG. 5nor described below in the interest of simplicity and brevity.

In some implementations, communication apparatus510may also include a transceiver516coupled to processor512and capable of wirelessly transmitting and receiving data. In some implementations, communication apparatus510may further include a memory514coupled to processor512and capable of being accessed by processor512and storing data therein. In some implementations, network apparatus520may also include a transceiver526coupled to processor522and capable of wirelessly transmitting and receiving data. In some implementations, network apparatus520may further include a memory524coupled to processor522and capable of being accessed by processor522and storing data therein. Accordingly, communication apparatus510and network apparatus520may wirelessly communicate with each other via transceiver516and transceiver526, respectively. To aid better understanding, the following description of the operations, functionalities and capabilities of each of communication apparatus510and network apparatus520is provided in the context of a mobile communication environment in which communication apparatus510is implemented in or as a communication apparatus or a UE and network apparatus520is implemented in or as a network node of a communication network.

In some implementations, when processor512starts an application in the EPS network, processor512may be configured to select a URSP rule from one or more configured URSP rules by matching a traffic descriptor of the URSP rule with the application. Then, processor512may determine whether a DNN or APN included in a route selection descriptor is a LADN DNN or APN. In an event that the DNN or APN is the LADN DNN or APN, processor512may be configured to skip the current route selection descriptor. Then, processor512may be configured to a next route selection descriptor or a next URSP rule in an event that the next route selection descriptor or the next URSP rule is available. In an event that no more route selection descriptor or URSP rule is available, processor512may further be configured to inform a failure to the upper layer.

In some implementation, processor512may select the route selection descriptor by taking a registration status into consideration.

In some implementation, processor512may match application information of the application with the traffic descriptor in the URSP rule.

In some implementation, processor512may determine whether a DNN selection parameter included in the route selection descriptor contains at least one LDAN DNN or APN.

In some implementation, after matching one of route selection descriptors of the URSP rules, processor512may further associating the application with the PDU session or PDN connection and provide the information of the PDU session or PDN connection to the upper layer.

In some implementation, after detecting that a DNN/APN is a LADN DNN/APN, processor512may determine whether it is in the LADN service area. Processor512may use this LADN DNN/APN to establish a PDN connection when the UE is in the LADN service area. Network apparatus520may provide the LADN information to communication apparatus510in corresponding NAS messages.

In some implementations, processor512may be configured to determine whether a preferred access type included in the route selection descriptor is identical to an access type currently registered. In an event that the preferred access type is not the access type currently registered, processor512may be configured to skip this route selection descriptor or take this route selection descriptor as not available. Processor512may try to evaluate a next route selection descriptor or URSP rule in an event that the next route selection descriptor or the next URSP rule is available.

In some implementations, when the preferred access type is not the access type currently registered, processor512may try to register over the preferred access type and try to establish the PDU session/PDN connection. For example, processor512may be configured to select the route selection descriptor where a preferred access type is included. Then, processor512may try to register over the preferred access type and establish a PDU session or PDN connection. In an event that both the registration and the establishment are successful, processor512may provide information of the PDU session or PDN connection to the upper layer. In an event that the registration is failed or the registration is successful but the establishment is failed, processor512may inform the failure to the upper layer. Optionally, processor512may further deregister from the preferred access type in an event that the PDU session or PDN connection cannot be established successfully.

Illustrative Processes

FIG. 6illustrates an example process600in accordance with an implementation of the present disclosure. Process600may be an example implementation of above scenarios/schemes, whether partially or completely, with respect to DNN selection when URSP rule is applied in EPS with the present disclosure. Process600may represent an aspect of implementation of features of communication apparatus510. Process600may include one or more operations, actions, or functions as illustrated by one or more of blocks610,620,630,640and650. Although illustrated as discrete blocks, various blocks of process600may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process600may executed in the order shown inFIG. 6or, alternatively, in a different order. Process600may be implemented by communication apparatus510, any suitable UE or machine type devices. Solely for illustrative purposes and without limitation, process600is described below in the context of n communication apparatus510. Process600may begin at block610.

At610, process600may involve processor512of apparatus510starting, by a processor of an apparatus, an application in an EPS network. Process600may proceed from610to620.

At620, process600may involve processor512selecting a URSP rule from one or more configured URSP rules by matching a traffic descriptor of the URSP rule with the application. Process600may proceed from620to630.

At630, process600may involve processor512determining whether a DNN or APN included in a route selection descriptor is a LADN DNN or APN. Process600may proceed from630to640.

At640, process600may involve processor512skipping the route selection descriptor in an event that the DNN or APN is the LADN DNN or APN. Process600may proceed from640to650.

At650, process600may involve processor512evaluate a next route selection descriptor or a next URSP rule in an event that the next route selection descriptor or the next URSP rule is available.

In some implementations, process600may involve processor512performing an inter-system change from a 5G system to the EPS network.

In some implementations, process600may involve processor512selecting the route selection descriptor by taking a registration status into consideration.

In some implementations, process600may involve processor512informing a failure to an upper layer in an event that no more route selection descriptor or URSP rule is available.

In some implementations, process600may involve processor512determining whether a DNN selection parameter included in the route selection descriptor contains at least one LDAN DNN or APN.

In some implementations, process600may involve processor512associating the application with a PDU session or PDN connection matching one of route selection descriptors of the URSP rules. Process600may further involve processor512providing information of the PDU session or PDN connection to an upper layer.

In some implementations, process600may involve processor512determining whether a preferred access type included in the route selection descriptor is identical to an access type currently registered. Process600may further involve processor512skipping the route selection descriptor in an event that the preferred access type is not the access type currently registered.

In some implementations, process600may involve processor512selecting the route selection descriptor where a preferred access type is included. Process600may also involve processor512registering over the preferred access type. Process600may further involve processor512establishing a PDU session or PDN connection.

In some implementations, process600may involve processor512providing information of the PDU session or PDN connection to an upper layer in an event that both the registering and the establishing are successful.

In some implementations, process600may involve processor512informing a failure to an upper layer in an event that the registering is failed or the registering is successful but the establishing is failed. Process600may further involve processor512deregistering from the preferred access type in an event that the establishing is failed.

Additional Notes