WO2025212422A1

WO2025212422A1 - Methods for configuring access traffic steering switching and splitting (atsss) rules for a user equipment (ue) using a 3gpp access and a non-3gpp access without control signaling over the non-3gpp access

Info

Publication number: WO2025212422A1
Application number: PCT/US2025/022031
Authority: WO
Inventors: Ching-Yu Liao
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2024-04-05
Filing date: 2025-03-28
Publication date: 2025-10-09
Anticipated expiration: 2026-10-05

Abstract

Methods and wireless communication devices enable a user equipment to efficiently use a 3GPP access and a non-3GPP access with control signaling on the 3GPP Access (known as non-3GPP access Type 2, while the conventional non-3GPP access with control signaling is known as non-3GPP access Type 1). A network element (130) establishes (1058) a multi-access packet data unit session with a user equipment (102) the MA PDU session using a 3GPP access and a non-3GPP access Type 2 with control signaling on the 3GPP access only. The network element then transmits (1091), to the UE, traffic steering, switching or splitting rules including a first rule specific for the non-3GPP access Type 2.

Description

METHODS FOR CONFIGURING ACCESS TRAFFIC STEERING SWITCHING AND SPLITTING (ATSSS) RULES FOR A USER EQUIPMENT (UE) USING A 3GPP ACCESS AND A NON-3GPP ACCESS WITHOUT CONTROL SIGNALING OVER THE

NON-3GPP ACCESS

FIELD OF THE DISCLOSURE

[0001] This document generally describes methods and devices operating in wireless communication systems such as (but not limited to) fifth generation (5G) systems (5GS) described in 3^rd Generation Partnership Project (3GPP) technical specifications (TSs). More particularly, this document describes methods related to ATSSS rules for a UE using a 3GPP access and a non-3GPP access in the absence of control signaling over the non-3GPP access.

BACKGROUND

[0002] This background description is provided for the purpose of generally presenting the context of various embodiments later described, and the technical problems. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0003] Traditional 5G wireless communication systems that support multiple access packet data unit (MA PDU) sessions between a UE and a 5G core (5GC) via a 3GPP access and via a non-3GPP access simultaneously have individual control signaling (i.e. , independent non-access stratum (NAS) signaling) on each access. UEs using a single control signaling via the 3GPP access for managing both connections are under development. This approach simplifies network operation over non-3GPP access by: (i) eliminating the control (NAS) signaling connection over non-3GPP access (i.e., both 3GPP access and non-3GPP access have a common NAS signaling connection over 3GPP access, and the non-3GPP access relies on WiFi authentication as well as the UE being authenticated via 3GPP access); (ii) establishing the MA PDU session over 3GPP access first and then adding non-3GPP access; and (iii) supporting multipath quick user datagram protocol internet connection (MPQUIC) connectivity to the user plane via the 3GPP access, the non-3GPP access, or both, between the UE and user plane function (UPF) based on an existing user plane interface between UE (operated as an MPQUIC client) and PDU session anchor (PSA) UPF operated as an MPQUIC proxy, when both the UE and the network support the MPQUIC functionality. [0004] A non-3GPP access Type 1 refers to the traditional approach in which the non-3GPP access has its own control signaling (e.g., in-band NAS support as described in 3GPP TS 23.501 and 3GPP TS 23.502). In this case, the network supports non- 3GPP access integrated with a Non-3GPP InterWorking Function (N3IWF), which provides functionalities for next generation application protocol (NGAP) over N2 to deliver control signaling (e.g., an in-band NAS signaling message) sent between the access and mobility management function (AMF) and the UE over the non-3GPP access.

[0005] A non-3GPP access Type 2 refers to a non-3GPP access without its own control signaling. Instead, control signaling over the 3GPP access is used for the non- 3GPP access Type 2 (e.g., in-band NAS support as described in 3GPP TS 23.501 and 3GPP TS 23.502). This type of non-3GPP access is not integrated with the 5G core via N3IWF. Depending on the availability of 3GPP access for MA PDU-based session management, the UE may add a QUIC path in the QUIC connection over non-3GPP access Type 2 to the established MA PDU session.

[0006] According to access traffic steering, switching and splitting (ATSSS) rules specified in 3GPP TS 23.501 , after the establishment of a MA PDU Session, the UE receives a prioritized list of ATSSS rules from the session management function (SMF) in a PDU Session Establishment Accept message or a PDU Session Modification Command message. The structure of an ATSSS rule is specified in 3GPP TS 23.501. Currently (as indicated in 3GPP TS 23.501 and 3GPP TS 23.502), the ATSSS rules support only non-3GPP access Type 1. These conventional ATSSS rules are frequently not suitable for a non-3GPP access Type 2. SUMMARY

[0007] Methods and devices according to various embodiments employ ATSSS rules able to take into consideration presence of a non-3GPP access Type 2 may include one or more of (1 ) UE Route Selection Policy (URSP) enhancements, (2) ATSSS preferences for handling non-3GPP access Type 2 (e.g., a second list of ATSSS rules for non-3GPP access type 2, adding an indication of non-3GPP access type to value or component, etc.) (3) an ATSSS traffic descriptor (TD) for a non-3GPP access Type 2, (4) ATSSS rules specifically for multi path QUIC user datagram protocol internet connection (MPQUIC) functionality (for non-3GPP access either Type 1 or Type 2), or (5) a new ATSSS steering mode parameter for indicating a non-3GPP access Type 2.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments. The same or similar reference numbers may denote the same or similar functions.

[0009] Fig. 1 is a block diagram of a wireless communication system including a LIE and an NE able to perform methods according to various embodiments.

[0010] Fig. 2 illustrates 3GPP and non-3GPP access architecture with ATSSS support in the 5GC.

[0011] Fig. 3 is a signal diagram schematically illustrating an ATSSS procedure supporting non-3GPP access Type 2 according to an embodiment.

[0012] Fig. 4 is a signal diagram illustrating a negotiation between a UE and network functions related to a UE’s capabilities for non-3GPP access Type 2 according to an embodiment.

[0013] Fig. 5 is a flowchart of a UE method according to an embodiment.

[0014] Fig. 6 is a signal diagram illustrating the use of enhanced URSP rules according to an embodiment.

[0015] Fig. 7 is a signal diagram illustrating a procedure using enhanced ATSSS rules according to an embodiment.

[0016] Fig. 8 is a signal diagram illustrating a procedure using ATSSS rules corresponding to the access type, according to an embodiment.

[0017] Fig. 9 is a flowchart of a UE method according to an embodiment.

[0018] Fig. 10 is a flowchart of an NE method according to an embodiment.

DETAILED DESCRIPTION

[0019] Methods and devices described in this section embody solutions to providing ATSSS for different types of non-3GPP access (e.g. Type 1 , Type 2, or both). These solutions overcome the following issues: (A) whether and how can the ATSSS rule be enhanced to support different types of non-3GPP access, (B) how can the ATSSS rule be enhanced to support applicable steering mode when the UE loses 3GPP access and only has non-3GPP access Type 2 or when the UE loses 3GPP access and only has non- 3GPP access Type 2 for a retention time period, (C) how can the ATSSS rule be enhanced to support the MPQUIC functionality that can add an additional QUIC path for non-3GPP access Type 2.

[0020] Prior to discussing various ATSSS rule-related methods, Fig.1 schematically illustrates a wireless communication system 100 including an NE 130 and a UE 102, which are able and configured to perform these methods. The UE 102 can access the 5GC 110 via a first radio access network (RAN) node 104. A RAN 105 connects RAN node 104 and other RAN nodes to the 5GC 110. For the sake of simplicity and clarity, the following description refers mostly to 5G radio access technology (RAT), but this RAT is an illustration and should not be interpreted as a limitation; other RATs such as a sixth generation (6G) RAT may be employed. Thus, the RAN node 104 in Fig. 1 is an NG-RAN node and the RAN 105 is a 5G RAN.

[0021] The first RAN node 104 serves (i.e. , intermediates communication with UEs located within) a first cell as service area 107 and a second cell as service area 108.

These cells are New Radio (NR) cells and may be in the same Radio Access Network Notification Areas (RNA) or different RNAs. In general, the RAN 105 can include any number of RAN nodes, and each of the RAN node can serve one, two, three, or any other suitable number of cells. The UE 102 can support a 5G NR (or simply, “NR”) air interface to communicate with the RAN node 104 and other RAN nodes. Each of the RAN nodes may connect to 5GC NEs (i.e., physical devices hosting 5G core network functions) via a 5GC-based interface (e.g., an S1 or an Ng interface). The RAN node 104 and other RAN nodes may also be interconnected via other specific interfaces (e.g., an X2 or an Xn interface).

[0022] Non-3GPP access point 203 will be discussed in more detail in FIG. 2. A UE 102 equipped with a non-3GPP transceiver (e.g., a WiFi transceiver) can communicate with a data network (e.g., the Internet) via the Non-3GPP access when within service area 109 of the access point 203.

[0023] The UE 102 is equipped with processing hardware 120 that includes one or more general-purpose processors and/or special-purpose processing units. The processing hardware 120 illustrated in Fig. 1 includes a processor 122 configured to process uplink (UL) data that the UE 102 transmits to the 5GC 110 via a RAN node, and/or downlink (DL) data the UE receives from or via a RAN node. The processing hardware 120 also includes a transmitter 124 configured to transmit UL data and a receiver 126 configured to receive DL data (or, alternatively, a transceiver performing both transmitting and receiving data) and non-3GPP communications (e.g., WiFi, Bluetooth). The UE may include (although not shown) communication hardware for other 3GPP RAT(s) besides 5G (e.g., LTE, 6G). The processing hardware 120 may also include a non- transitory computer-readable medium 128 (e.g., a memory) storing machine-readable instructions executable on the one or more general-purpose processors, and/or specialpurpose processing units.

[0024] The RAN node 104 is equipped with processing hardware 140 that may include one or more general-purpose processors and/or special-purpose processing units. The processing hardware 140 illustrated in Fig. 1 includes a processor 142 configured to process data that the first RAN node 104 transmits in DL direction (i.e., to a UE), or receives in the UL direction (i.e., from a UE). The processing hardware 140 also includes a transmitter 144 configured to transmit data in the DL direction and a receiver 146 configured to receive data in the UL direction (or, alternatively, a transceiver performing both transmitting and receiving data). The processing hardware 140 may also include a non-transitory computer-readable medium 148 (e.g., a memory) storing instructions that the one or more processors execute.

[0025] As illustrated in Fig. 1 , the 5GC 110 includes an AMF 112, an SMF 114, a user plane function (UPF) 116, a policy control function (PCF) 118, a unified data management (UDM) 115, and a binding support function (BSF) 117. The 5GC 110 may include other functions not illustrated in Fig. 1 . Each of the 5GC functions may be hosted by an NE 130 (i.e., processing hardware) that typically includes a processor 132, a transmitter 134, a receiver 136, and a memory 138 (which may store executable instructions for the processor to perform various methods described hereinafter). The same NE may execute one or more 5GC functions or instances of 5GC functions. For example, the 5GC 110 may have a plurality of PCF instances running on the same NE or on different NEs. [0026] The AMF 112 is configured to manage authentication, registration, paging, and other related functions. The SMF 114 is configured to manage PDU sessions, and the UPF 116 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., between the UE and a data network. The UDM 115 is a cloud-based entity managing information for access authorization, user registration, data network profiles, generating credentials used during authentication, and sending credentials to other network functions based on user subscription. The BSF 117 is a control plane network function that binds sessions that share common criteria but originate from different network interfaces. The PCF 118 is a network function that provides policy control and charging rules for 5G services and applications thereby facilitating network behavior control, network slicing, UE activities, and communication with other 5GC functions.

[0027] The current 3GPP TSs describe a 5GS architecture reference model (e.g. 3GPP TS 23.501 ), a 5GS architecture reference model of policy and charging control framework for the 5GS (e.g., 3GPP TS 23.503), features of network functions (e.g., 3GPP TS 23.501 ), and network function services and descriptions (e.g., in 3GPP TS 23.501 ). The control and user plane protocol stacks are listed in 3GPP TS 23.501 , and procedures for the 5GS including 5GS mobility management and 5GS session management are described in 3GPP TS 23.502.

[0028] The interaction between network functions may be understood based on a service-based architecture or a reference point representation. Fig. 2 illustrates a UE 102 that supports an N1 interface over 3GPP access 105 (which corresponds to RAN 105 and communication cells 107-108 illustrated in Fig. 1) and an IP network -WiFi/IP access 203 (enabling UE’s Internet access) as the non-3GPP access. The UE 102 is configured to provide steering functionality 225 and the UPF 116 (i.e. , the NE executing the UPF) has embedded the 5GC steering functionality 235.

[0029] The PDU session management employs a PDU session attributes as listed in Table 1 (based on 3GPP TS 23.501 ). Table 1 : Attributes of a PDU Session

[0030] If the UE supports ATSSS and wants to activate an MA PDU Session, the UE provides a Request Type as "MA PDU Request" and indicates the supported ATSSS capabilities. The UE evaluates the ATSSS rules in priority order. Each ATSSS rule contains a Traffic Descriptor (TD). The UE determines the applicable ATSSS rule when every component in the ATSSS rule’s TD matches the considered service data flow (SDF). An MA PDU session is a PDU session which can use one 3GPP access network or one non-3GPP access network at a time, or simultaneously one 3GPP access network and one non-3GPP access network as defined in 3GPP TS 23.501 . Table 2 (on following page) illustrates structure of an ATSSS rule.

[0031] According to 3GPP TS 24.193, a steering functionality may be set to: (A) MPTCP functionality (i.e. , the UE steers the SDF by using the MPTCP functionality); (B) MPQUIC functionality (i.e., the UE steers the SDF by using the MPQUIC functionality); (C) ATSSS-LL functionality (i.e., the UE steers the SDF by using the ATSSS-LL functionality); or (D) UE's supported steering functionality. If the UE supports multiple steering functionalities, the UE selects a steering functionality by using the ATSSS rules to apply for a specific packet flow (e.g., as described in 3GPP TS 23.503).

[0032] Further, the steering mode may be: (A) active-standby; (B) smallest delay; (C) load balancing; (D) priority based; or (E) redundant. For steering mode A (i.e., active-standby), the UE steers the SDF by using the active access if the active access is available. If the active access is not available and the standby access is available, the UE steers the SDF by using the standby access.

[0033] For steering mode B (i.e., smallest delay), the UE steers the SDF by using the access network with the smallest round-trip time (RTT). If there is only one access available, the UE steers the SDF by using the available access. This steering mode is only applicable to non-GBR SDF (here GBR means “guaranteed bit rate”).

[0034] For steering mode C (i.e., load balancing), the UE steers the SDF across both the 3GPP access and the non-3GPP access with a given precentage if both accesses are available. If there is only one access available, the UE steers the SDF by using the available access. This steering mode is only applicable to non-GBR SDF.

[0035] For steering mode D (i.e., priority based), the UE steers the SDF over the access with high priority unless the access with high priority is congested or unavailable, when the UE steers the SDF over both the access with high priority and the access with low priority. This steering mode is only applicable to non-GBR SDF.

[0036] For steering mode E (i.e. , redundant), the UE duplicates the traffic of an SDF on both the 3GPP access and the non-3GPP access according to the following rules when there are no threshold values provided in the access selection descriptor:

- if both accesses are available and the steering mode information field in the access selection descriptor is set to "Primary access is not provided", the UE duplicates all the traffic of the SDF on both accesses;

- if both accesses are available and the steering mode information field in the access selection descriptor is set to "Primary access is 3GPP" or set to "Primary access is non-3GPP", the UE sends all the traffic of an SDF on the indicated primary access (3GPP access or non-GPP access) and may duplicate the traffic on the other access, where how many and which data packets are duplicated by UE on the other access are implementation dependent; or

- if there is only one access available, the UE shall send the traffic of the SDF on the available access.

[0037] The redundant steering mode is applicable to both GBR SDF and non-GBR SDF when there is no threshold value provided in the access selection descriptor. If threshold value is provided in the access selection descriptor, the redundant steering mode is applicable to only non-GBR SDF. If the steering functionality is set to ATSSS-LL functionality, the steering mode shall not be set to redundant.

[0038] 3GPP TS 23.503 describes UE Route Selection Policy (URSP). The URSP includes a prioritized list of URSP rules corresponding to a UE context. The structure of the URSP rules is presented in table 3 (starting on next page). The URSP rule includes a list of route selection descriptors (RSDs). Table 4 then lists information included in an RSD. Table 3: UE Route Selection Policy Rule

Table 4 (starting on the next page) illustrates Route Selection Descriptor information

[0039] Fig. 3 is a signal diagram of an enhanced ATSSS procedure supporting non- 3GPP access Type 2 according to an embodiment. The UE 102 interacts with 5G network functions (i.e. , AMF 112, UDM 115, SMF or UPF 314, and PCF 318 and a next generation radio access network (NG-RAN) node 104) to perform steering, switching, and splitting of traffic over a 3GPP access and a non-3GPP access.

[0040] The UE 102 initiates a registration procedure 350, which is similar to the one described in 3GPP TS 23.502 and employs the NG-RAN 104, the AMF 112, and the UDM 115. The AMF 112 may then select a PCF 318 for the UE and create a PCF-UE association 352. When deciding to update UE policy based on triggering conditions, the PCF 118 initiates a UE configuration update procedure 354 (e.g., similar to the one described in 3GPP TS 23.502) to provide session management (SM) UE policies. Further, the UE 102 evaluates 356 the URSP rules, determines to enforce a URSP rule for the traffic, and determines whether to perform a PDU session establishment/modification request procedure. Then, the UE 102 initiates a PDU session establishment/modification procedure 358 (e.g., similar with one described in 3GPP TS 23.502). The SMF 314 may then select a PCF-PS (here PS stands for PDU session) and create a PCF-PS association 359 to retrieve/update SM UE policies of the PDU Session. The PCF-UE and the PCF-PS may be the same or different PCF instances.

[0041] Fig. 4 is a signal diagram illustrating a negotiation between a UE and network functions related to UE’s capabilities for non-3GPP access Type 2 according to an embodiment. This negotiation of the non-3GPP access Type 2 occurs during registration procedure 450 (similar to Fig. 3 element 350) to enable support of the NAS signaling over 3GPP access and support with handling UE states over non-3GPP access Type 2, which lacks in-band NAS signaling over non-3GPP access.

[0042] The UE 102 sends 462, to AMF 112 via the NG-RAN 104, a registration request message including UE capabilities of non-3GPP access Type 2. The AMF 112 stores the UE capabilities of non-3GPP access Type 2 and then retrieves 463 UE’s subscription from the UDM 115. The UDM 115 stores UE’s subscription with session management subscription data including ATSSS information that indicates whether MA PDU establishment is allowed and whether MA PDU session is allowed for non-3GPP access type 1 , non-3GPP access Type 2, or both.

[0043] When the UE capabilities support non-3GPP access Type 2 and the UE subscription is allowed to use non-3GPP access Type 2 (as assumed for the scenario illustrated here), the AMF 112 selects a PCF-UE 418 and creates a PCF-UE association for the UE to handle and control UE policies. Thus, the AMF 112 sends 464 an NpcfJJEPolicyControl Create Request message including a subscription permanent identifier (SUPI) of the UE 102 and an indication of UE capability of non-3GPP access Type 2 to the selected PCF-UE 418.

[0044] In response, the PCF-UE 418 sends 466 an NpcfJJEPolicyControl Create Response message indicating network support for non-3GPP access Type 2. The AMF 112 sends 468, to the UE 102, a registration accept message indicating the network support for non-3GPP access Type 2 (i.e. , including the respective indication). Further, the PCF-LIE 418 registers 470 its address information to the BSF 117.

[0045] The PCF-UE 418 then initiates a UE configuration update procedure 454 (similar to 354 in Fig. 3) to provide UE policy information including URSP rules to the UE 102. Based on triggering conditions, the UE 102 evaluates 456 URSP rules (similar to 356), enforces a URSP rule whose traffic descriptor (TD) matches current traffic, and initiates a PDU Session Establishment/Modification procedure 458 (similar to 358) based on the Route Selection Descriptor (RSD) of the enforced URSP rules for the PDU session (e.g., DNN, S-NSSAI), Access Type preference (e.g. 3GPP access, Non-3GPP access or Multi-Access), etc.

[0046] Thus, based on the enforced URSP rule, the UE 102 initiates the PDU session establishment/modification request procedure 458 (which is similar to 358 in Fig. 3). If the RSD indicates Multi-Access preference, the UE provides a Request Type as "MA PDU Request" and indicates the supported ATSSS capabilities. At the end of this procedure, the UE 102 may receive a list of ATSSS rules (e.g., in a PDU session establishment accept message or PDU session modification command). The list of ATSSS rules may provide policies based on non-3GPP access types if both network and UE supports ATSSS for non-3GPP access Type 1 and/or non-3GPP access Type 2. Based on the list of ATSSS rules, the UE 102 handles 472 MA PDU session traffic over the 3GPP access and the non-3GPP access Type 1 or the non-3GPP access Type 2.

[0047] Fig. 5 is a flowchart of a UE method for establishing and handling an MA PDU Session over a 3GPP access and one of the two types of non-3GPP access (i.e., non-3GPP access Type 1 or non-3GPP access Type 2).

[0048] The UE receives 554 URSP rules from the PCF and then evaluates 556 the URSP rules to determine whether to establish a PDU Session for a launched application. Assuming the URSP rules allow, the UE then establishes 556 an MA PDU Session for a 3GPP access and a non-3GPP access by enforcing a matched URSP rule with a TD matching the application traffic, and the RSD including an Access Type preference components type with component value indicating MA PDU Session. Then, the UE receives 568 a list of ATSSS rules in priority order from the PDU Session Establishment Access message or PDU Session modification Command message. The UE then enforces 572 a matched ATSSS rule from a list of ATSSS rules for the established MA PDU Session and manages matched traffic for steering, switching, and splitting over 3GPP access and non-3GPP access by applying the access selection description (ASD) for the matched traffic which matches a TD of the ATSSS rule.

[0049] Thus, some embodiments enhance URSP rules by enabling at least one of new component value for the existing Access Type preference component type such as: (i) non-3GPP access Type 2 (i.e., non-3GPP access without NAS over non-3GPP access, also known as non-integrated non-3GPP access), and/or (ii) multiple access (MA) for non- 3GPP access Type 2. Thus, the Access type preference of the RSD may indicate “non- 3GPP access Type 2” and “Multiple-Access Type 2” in addition to 3GPP or non-3GPP or Multi-Access specified in Table 4, to guide the UE in establishing a PDU session for matched application traffic. In view of the above new Access Type preference values, in step 572 the UE establishes an MA PDU Session for a 3GPP access and a non-lntegrated non-3GPP access Type 2 by enforcing a matched URSP rule when the TD matches the application traffic, and the RSD includes an Access Type preference that has a value indicating MA PDU Session with non-3GPP access Type 2.

[0050] Fig. 6 is a signal diagram illustrating the use of enhanced URSP rules according to an embodiment. After the registration procedure 650 (which is similar to 450) with UE capability specified and network support negotiated, the PCF 118 initiates a UE configuration update procedure 654 (similar to Fig. 3 element 354) which is an enhancement of the UE Configuration update procedure described in 3GPP TS 23.502. The PCF 118 decides 680 to initiate the UE configuration update procedure based on triggering conditions such as an initial registration, need for updating UE policy, etc. The PCF 118 sends 681 an Namf_Communication_N1 N2MessageTransfer message to the AMF 112, the message including UE’s SUPI, and a UE policy container with the enhanced URSP rules for non-3GPP access Type 2. The AMF 112 transfers 682 (with 683 confirmation) the UE Policy container (UE policy information including enhanced URSP rules for non-3GPP access type (type 1 , type 2, or both)) received from the PCF 118 to the UE 102. The UE Policy container may include the list of Policy Sections as described in 3GPP TS 23.503. The UE 102 then updates the UE policy information including enhanced URSP rules for non-3GPP access type (Type 1 , Type 2, or both) provided by the PCF 118.

[0051] The UE 102 stores and handles 656 (which is similar to 456) the enhanced UE policies and initiates 684 a PDU session establishment/modification procedure 658 (which is similar to 458 and it is an enhanced version of the PDU session establishment procedure), or the PDU session modification procedure described in 3GPP TS 23.502. At the end of procedure 658, the SMF 114 sends 691 , to the UE 102 via the AMF 112, a PDU session establishment access message or a PDU Session modification command message. This last message includes a list of ATSSS rules.

[0052] In more detail, procedure 658 starts with the UE 102 sending 684, to the AMF 112, a PDU session establishment request message including MA PDU session info, in view of the enforced URSP rules of the matched traffic. The MA PDU session info includes an associated non-3GPP access type (Type 1 , Type 2, or both) based on the URSP rule. The procedure 658 then includes the AMF 112 selecting an SMF able to support the indicated non-3GPP access type and sending 685, to the selected SMF 116, an Nsmf_PDUSession_CreateSMContext Request including the MA PDU Session info or response. Further, the SMF 116 interacts 686 with the UDM 115 indicating the MA PDU session info with associated non-3GPP access type indication to the UDM 115. The UDM 115 checks the UE subscription based on indicated associated non-3GPP access type indication. Based on response from the UDM (in the illustrated scenario it is assumed positive), the SMF 114 replies 687 to the AMF 112 with an Nsmf_PDUSession_Create Response message. The SMF 114 then initiates 688 an SM policy session establishment indicating the MA PDU Session info with associated non-3GPP access type indication; in return, the PCF 118 provides policy charging and control (PCC) rules for the MA PDU session with the associated non-3GPP access type. The SMF 114 selects a UPF 116 based on MA PDU session info with the associated non-3GPP access type for using the corresponding MPQUIC functionalities. The SMF 114 may discover the UPF capabilities via the network repository function (NRF) or the N4 association establishment. The SMF 114 then sends 689 an N4 session establishment/modification request message to the UPF 116 and includes the N4 rules with information of required ATSSS features over one 3GPP access and one non-3GPP access type (Type 1 , Type 2, or both) that need specific MPQUIC functionalities activated in the UPF. The SMF 114 determines a list of ATSSS rules based on the PCC rules for the MA PDU session info with the associated non-3GPP access type and sends 690 a PDU session establishment accept (with a list of ATSSS rules) message to the UE 102 via AMF 112 (see element 691 ). Block 658 illustrates a PDU Establishment procedure but same technique is applicable for PDU Session Modification procedure.

[0053] Based on the list of ATSSS rules, the UE 102 then handles 672 traffic for the MA PDU session over 3GPP access and associated non-3GPP access type (Type 1 , Type 2, or both).

[0054] In some embodiments, the UE provides a second list of ATSSS rules specifically for non-3GPP access Type 2. The structure of an ATSSS rule in the second list is substantively the same as the one illustrated in Table 2. The UE accessing non- 3GPP access Type 2 applies the second list of ATSSS rule for the established MA PDU Session.

[0055] When using a second list of ATSSS rules specifically for non-3GPP access Type 2, the UE receives a first list of ATSSS rules for non-3GPP access supporting NAS and/or a second list of ATSSS rules for non-3GPP access without NAS over non-3GPP access from the PDU Session Establishment Access message or PDU Session Modification Command message. Then, the UE uses the second list of ATSSS rules in an additional step, when the UE uses non-3GPP access Type 2. The UE determines to enforce a matched ATSSS rule in a second list of ATSSS rules for the established MA PDU Session and manage matched traffic for steering, switching, and splitting over 3GPP access and non-3GPP access Type 2 by applying the access selection description (ASD) for the matched traffic which matches a TD of the ATSSS rule.

[0056] Fig. 7 is a signal diagram illustrating a procedure using enhanced ATSSS rules according to an embodiment. After a Registration procedure 750 (which is similar to 450), a UE configuration update procedure 754 follows (similar to 454). The procedure 754 is the same as the UE configuration update procedure described in 3GPP TS 23.502 in which the PCF 168 sends, to the UE, a list of URSP rules in prioritized order. The structure of the URSP rule is substantially similar with the one described in TS23.503 and TS24.526. The procedure 754 starts when PCF 118 decides 780 (which is similar to 680) to update UE policy based on triggering conditions such as an initial registration, need for updating UE policy, etc. The PCF 118 then sends 781 , to the SMF 114, an Namf_Communication_N1 N2MessageTransfer message that includes UE’s SUPI and a UE policy container (that includes UE policy information such as the list of Policy Sections as described in 3GPP TS 23.503). The SMF 114 transfers 782 transparently the UE Policy container received from the PCF 118 to the UE 102. The UE 102 updates the UE policy provided by the PCF and sends 783 the result to the SMF 114.

[0057] The UE 102 then stores and handles 756 the enhanced UE policies. The conventional PDU session establishment procedure or PDU Session modification procedure described in 3GPP TS 23.502 are improved because the SMF 114 sends, to the UE 102, a PDU session establishment access message or PDU Session modification command message including a first list of ATSSS rules for non-3GPP access Type 1 and/or a second list of ATSSS rules for non-3GPP access Type 2.

[0058] Based on the enforced URSP rules of the matched traffic, the UE 102 then initiates a PDU session establishment procedure 758 by sending 784, to the AMF 112, a PDU session establishment request message including MA PDU Session info. The MA PDU Session info includes UE capabilities for supported non-3GPP access type(s): Type 1 or Type 2, or both. The AMF 112 selects an SMF (i.e., SMF 114) capable to support the indicated non-3GPP access type and sends 785, to the selected SMF, an Nsmf_PDUSession_CreateSMContext request message. The SMF 114 interacts 786 with the UDM 115 and indicates the MA PDU Session info to the UDM, enabling the UDM 115 to check the UE subscription based on UE capabilities for supported non-3GPP access type(s). Based on the response from the UDM 115 (assumed positive on the illustrated scenario), the SMF 114 replies 787 to the AMF 112, with an Nsmf_PDUSession_Create Response which indicates allowed non-3GPP access type(s). [0059] The SMF 114 initiates an SM policy session establishment 788 and indicates the MA PDU Session info and network allowed non-3GPP access type(s) to the PCF 118. The PCF 118 thus provides, to the SMF 114, PCC rules for the MA PDU Session. The SMF 114 then selects a UPF based on the PCC rules per allowed non- 3GPP access type(s) for using the corresponding MPQUIC functionalities. The SMF 114 may discover the UPF 116 capabilities via NRF or the N4 Association establishment. The SMF 114 sends 789 an N4 session establishment/modification request message to the UPF 116 and provides the N4 rules with required ATSSS features over one 3GPP access and one non-3GPP access type that needs specific MPQUIC functionalities activated in the UPF 116. The SMF 114 determines a list of ATSSS rules based on the PCC rules for allowed non-3GPP access type(s) and sends 790 a PDU session establishment accept message including a list of ATSSS rules to the UE 102 via AMF 112 (i.e. , 791 ). Based on the list of ATSSS rules per non-3GPP access type, the UE 102 selects the non-3GPP access type and handles 772 traffic for the MA PDU Session over 3GPP access and one selected non-3GPP access type (Type 1 or Type 2).

[0060] Yet some other embodiments use ATSSS rules enhanced by the addition of a new indication of non-3GPP access type. When this new indication has an “active” value, the UE considers the ATSSS rule applicable for a specific non-3GPP access type. The indication of the non-3GPP access can be provided in the ATSSS rule in two ways. According to Option 1 , the indication refers to the non-3GPP access Type 2; when this new indication specifies that the non-3GPP access Type 2 is active, the ATSSS rule is for non-3GPP access Type 2 only. According to Option 2, the indication explicitly specifies the non-3GPP access types (e.g., the indication has as values Type 1 , Type 2, or both). When the indication has a specific value (Type 1 or Type 2 or both), the ATSSS rule is for non-3GPP access Type 1 or non-3GPP access Type 2 or both.

[0061] The ATSSS rule structure illustrated in Table 2 may be enhanced by adding a new component named, for example, “Indication of Non-3GPP access type,” which may be Type 1 or Type 2. This is an optional field that the SMF may modify in a PDU context. According to this approach, the UE determines to enforce a matched ATSSS rule in a list of ATSSS rules for the established MA PDU Session and manage matched traffic for steering, switching, and splitting over 3GPP access and non-3GPP access Type 2 by applying the access selection description (ASD) for the matched traffic which matches a TD of the ATSSS rule if the matched ATSSS rule includes the indication of the non-3GPP access type set to non-3GPP Type 2.

[0062] Fig. 8 is a signal diagram illustrating a procedure using ATSSS rules corresponding to the access type, according to an embodiment. After a Registration procedure 850 (which is similar with 450) with the UE capability and network support negotiation, the UE 102 initiates a UE configuration update procedure 854, which is substantively similar to 754 and 454, and enhances the UE Configuration Update procedure described in 3GPP TS 23.502. The UE 102 then stores and handles 856 (similar to 356) the list of URSP rules in prioritized order received from the PCF 118 at the end of procedure 854. The session establishment/modification procedure 858 is also substantively similar to procedure 758 (i.e. , steps 884-891 are the same as steps 784-791 ) except the SMF 114 sends, to the UE via the AMF (i.e., 890, 891 ), a PDU Session Establishment Accept message or a PDU Session Modification Command message including a list of enhanced ATSSS rules with information of applicable non-3GPP access type(s) to the UE.

[0063] In other words, based on the enforced URSP rules of the matched traffic, the UE 102 sends 884, to the AMF 112, a PDU Session Establishment request message including MA PDU Session info which contains UE capability of the selected non-3GPP access type. The AMF 112 then selects an SMF instance (e.g., 114) able to support the indicated non-3GPP access type. The AMF 112 sends 885, to the selected SMF, an Nsmf_PDUSession_CreateSMContext request including MA PDU session info. Further, the SMF 116 interacts 886 with the UDM 115. The UDM 115 verifies the UE subscription based on the MA PDU session info provided by the SMF 114. In view of the confirmation received from the UDM 115, the SMF 114 replies 887 to the AMF’s request 885 with an Nsmf_PDUSession_Create Response.

[0064] The SMF 114 initiates 888 an SM Policy Session Establishment (or Modification) and indicates the MA PDU Session info to the PCF 118. In return, the PCF 118 provides PCC rules for the MA PDU Session. The SMF 114 determines a list of enhanced ATSSS rules based on the PCC rules and selects a UPF instance (i.e., UPF 116) based on MA PDU session info thereby enabling the use of the corresponding MPQUIC functionalities. The SMF 114 may discover the UPF’s capabilities via NRF or the N4 association establishment. The SMF 114 sends 889 an N4 Session Establishment/Modification Request message to the UPF 116 and includes the required ATSSS features over one 3GPP access and one non-3GPP access type that needs specific MPQUIC functionalities activated in the UPF. As previously mentioned, the SMF 114 sends the PDU Session Establishment Accept message that includes including a list of enhanced ATSSS rules to the UE 102 via AMF 112 (i.e., 890 and 891 ). Based on the selected non-3GPP access type and the list of enhanced ATSSS rules, the UE 102 handles 872 traffic of the MA PDU session.

[0065] In some embodiments, the ATSSS rules are enhanced by adding a new component, for example, named “non-3GPP access preferences” in the access selection descriptor (ASD) portion of the ATSSS rule. This new component indicates the preferred non-3GPP Access Type (i.e., non-3GPP Type 1 or non-3GPP Type 2) for the application. Thus, in view of the ATSSS rule structure listed in Table 2, a Non-3GPP access optional component, which can be modified by the SMF and is related to the PDU context, is added to the ASD portion of the ATSSS rule.

[0066] According to this approach, the UE 102 determines 872 to enforce a matched ATSSS rule in a list of ATSSS rules for the established MA PDU Session and manage matched traffic for steering, switching, and splitting over 3GPP access and non- 3GPP access Type 2 by applying the access selection description (ASD) for the matched traffic which matches a TD of the ATSSS rule if the matched ATSSS rule indicating in the ASD with a new component type of non-3GPP access preferences and the component value indicated as non-3GPP access Type 2.

[0067] In some other embodiments, the ATSSS rule is enhanced by adding another new component, for example named “Indication of Local IP descriptor”, in the TD part of the ATSSS rule. This new component includes one or more 5-tuples that identify the source of IP traffic (i.e., of local IP traffic via non-3GPP access Type 2). When indicated, the UE accessing to the non-3GPP access Type 2 with a specific local IP address can evaluate its traffic against the “Indication of Local IP descriptor” in the TD of the ATSSS rule. If matched, the UE applies the ATSSS rule for the MA PDU Session over 3GPP access and non-3GPP access Type 2. Thus, in view of the ATSSS rule structure listed in Table 2, the TS portion of the rules includes a new component, which can be named “Indication of Local IP descriptor”, that includes one or more 5-tuples that identify the source of IP traffic (i.e., local IP traffic via non-3GPP access Type 2 (without control signaling such as in-band NAS)). This new component is optionally used when the non- 3GPP access is Type 2 and can be modified by an SMF related to the PDU context. [0068] According to this approach, the UE 102 determines 872 that UE’s local IP address over Non-3GPP access Type 2 matches “Indication of Local IP descriptor” indicated in the TD of an ATSSS rule, and enforces a matched ATSSS rule in a list of ATSSS rules for the established MA PDU Session and manages matched traffic for steering, switching, and splitting over 3GPP access and non-3GPP access Type 2 by applying the access selection description (ASD) for the matched traffic which matches a TD of the ATSSS rule.

[0069] In yet some other embodiments, the ATSSS rule is enhanced by adding yet another new value (e.g., named “MPQUIC with non-3GPP Type 2”) for steering functionality component of the ASD part of the ATSSS rule. In view of Table 2, the steering functionality (which is optionally used and can be modified by SMF being related to the PDU context) may take the following values: (a) the MPTCP functionality, (b) the MPQUIC functionality, or (c) the ATSSS-LL functionality, (a)-(c) being usable for non-3GPP access Type 1 , and (d) the MPQUIC functionality usable for non-3GPP access Type 2.

[0070] According to this approach, the UE 102 determines 872 to enforce a matched ATSSS rule in a list of ATSSS rules for the established MA PDU Session and manage matched traffic for steering, switching, and splitting over 3GPP access and non- 3GPP access Type 2 by applying the access selection description (ASD) for the matched traffic as indicated in the TD of the ATSSS rule if the component value of steering functionalities indicates the MPQUIC functionality for Non-3GPP access Type 2 in the ASD of the matched ATSSS rule.

[0071] Some embodiments enhance the ATSSS rule for the component parameter of the steering mode component type to handle the case when the UE loses 3GPP access. According to a first option, when the steering mode information in the ASD portion of the ATSSS rule is set to “Active non-3GPP access and no standby”, the ATSSS rule is not applicable for the UE handling the MA PDU Session over non-3GPP access Type 2. According to a second option, the steering mode information may be set to a new value, for example named “non-3GPP access Type 2 active with retention and no standby.” When the steering mode has the new value (e.g., “non-3GPP access Type 2 active with retention and no standby”), the UE is able to continue using a matched traffic over non- 3GPP access Type 2 during a retention period without having 3GPP access. Thus, in view of Table 2, the Steering mode component of the ASD portion of the ATSSS rule may take a new value (e.g., “non-3GPP access type 2 active with retention and no standby”) enabling the UE to continue using the non-3GPP access without control signaling over 3GPP access, for a retention period after losing the 3GPP access.

[0072] According to this approach, the UE 102 determines 872 to enforce a matched ATSSS rule in a list of ATSSS rules for the established MA PDU Session and manage matched traffic over non-3GPP access Type 2 during a retention period duration without available 3GPP access by applying the access selection description (ASD) for the matched traffic as indicated in the TD of the ATSSS rule if the component parameter of the steering functionalities indicates “non-3GPP access Type 2 active with retention and no standby” in the ASD of the matched ATSSS rule.

[0073] Fig. 9 is a flowchart of a UE method 900 according to an embodiment. The method 900 includes establishing 958 an MA PDU session with an NE (e.g., 130) of a wireless communication system (e.g., 100), the MA PDU session using a 3GPP access (e.g., 105) and a non-3GPP access Type 2 (e.g., 203). The NE executes a 5GC function. The method 900 further includes performing 972 traffic steering, switching or splitting over the 3GPP access and the non-3GPP access Type 2 based on an ATSSS rule specific for the non-3GPP access Type 2.

[0074] Step 958 may include enforcing a URSP rule corresponding to a traffic descriptor that matches a target application traffic, the URSP indicating applicability for the non-3GPP access Type 2 via an access type preference component. The method may further include receiving ATSSS rules including a first set of ATSSS rules for the non- 3GPP access Type 2 with the control signaling on the 3GPP access only, and a second set of ATSSS rules for a non-3GPP access Type 1 , with a non-3GPP access control signaling on the non-3GPP access as well as the control signaling on the 3GPP access (here the first ATSSS rule pertains to the first set of ATSSS rules). Each of ATSSS rules may include an indication of non-3GPP access type (type 1 or type 2). Alternatively, the ASD portion of each of the ATSSS rules may include a non-3GPP access preference indication (type 1 or type 2). The steering functionality information of the first ATSSS rule may indicate a multi-path quick user datagram protocol internet connection, MPQUIC, functionality for non-3GPP access Type 2. When a steering mode component of the ATSSS rule indicates a non-3GPP Type 2 with retention and no standby, the UE may maintain the non-3GPP access a retention time after the 3GPP access is lost (and consequently the control signaling for the non-3GPP access Type 2). The method may further include transmitting, to the NE, an indication of UE capability for the non-3GPP access Type 2 during a UE registration procedure for connecting the UE to the wireless communication system and receiving in response an indication of network support for the non-3GPP access Type 2.

[0075] Fig. 10 is a flowchart of an NE method 1000 according to an embodiment. The method 1000 includes establishing 1058 an MA PDU session with a UE (e.g., 102) in a wireless communication system (e.g., 100) according to an enforced URSP rule (e.g. 654, 754, 854), the MA PDU session using a 3GPP access and a non-3GPP access Type 2 (i.e., with control signaling on the 3GPP access only). The method 1000 further includes transmitting 1091 , to the UE, ATSSS rules including a first ATSSS rule specific for the non- 3GPP access Type 2. For an embodiment, the ATSSS rules may include a first set of ATSSS rules for the non-3GPP access Type 2 (i.e., with a non-3GPP access control signaling relying on 3GPP access control signaling on the 3GPP access), and a second set of ATSSS rules for a non-3GPP access Type 1 (i.e., with a non-3GPP access control signaling on the non-3GPP access and 3GPP access control signaling on the 3GPP access), the first IE includes ATSSS rules pertaining to the first set of ATSSS rules. For another embodiment, each of the ATSSS rules may include an indication of non-3GPP type. For example, an ASD portion of each of the ATSSS rules may include a non-3GPP access preference indication. For another example, an TD portion of the ATSSS rule may include a local internet protocol, IP, descriptor identifying a source of IP traffic. For another embodiment, the steering functionality information of the ATSSS rule in ASD may indicate a multi-path quick user datagram protocol internet connection, MPQUIC, functionality for non-3GPP access Type 2.

[0076] The embodiment descriptions in this section refer to the accompanying drawings. The detailed descriptions do not preclude other embodiments within the scope of the appended claims.

[0077] Reference throughout this section to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification are not necessarily all referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.

[0078] Numerical adjectives “first”, “second”, and “third” do not imply any order (are not ordinals) but are markers to distinguish separate instances of similar elements.

References to the singular (e.g., “a” or “an”, “the”) should include the plural unless clearly indicated otherwise.

[0079] As used herein, a phrase referring to “at least one of’ or “one or more of’ a list of items refers to any combination of those items, including single members. For example, “at least one of: a, b, or c” is intended to cover the possibilities of: a only, b only, c only, a combination of a and b, a combination of a and c, a combination of b and c, and a combination of a and b and c.

[0080] Although the features and elements of the present embodiments are described in the embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the embodiments or in various combinations with or without other features and elements disclosed herein. The methods or flowcharts may be implemented in a computer program, software or firmware tangibly embodied in a computer-readable storage medium for execution by a specifically programmed computer or processor.

Claims

WHAT IS CLAIMED IS:

1 . A wireless communication method (900) performed by a user equipment, UE, (102), the method comprising: establishing (958) a multi-access packet data unit, MA PDU, session with a network entity, NE, (130) of a wireless communication system (100), the MA PDU session using a 3GPP access (105) and a non-3GPP access Type 2 (203), with control signaling on the 3GPP access only; and performing (972) traffic steering, switching or splitting over the 3GPP access and the non-3GPP access Type 2 based on a first access, steering, switching and splitting, ATSSS, rule specific for the non-3GPP access Type 2.

2. The wireless communication method of claim 1, wherein the establishing of the MA PDU comprises: enforcing a UE route selection policy, URSP, rule corresponding to a traffic descriptor that matches a target application traffic, the URSP indicating applicability for the non-3GPP access Type 2 via an access type preference component.

3. The wireless communication method of claims 1 or 2, further comprising: receiving ATSSS rules including a first set of ATSSS rules for the non-3GPP access Type 2 with control signaling on the 3GPP access only, and a second set of ATSSS rules for a non-3GPP access Type 1 , with a non-3GPP access control signaling on the non-3GPP access as well as the control signaling on the 3GPP access, and the first ATSSS rule pertains to the first set of ATSSS rules.

4. The wireless communication method of claim 1 or 2, wherein each of the ATSSS rules includes an indication of non-3GPP access type.

5. The wireless communication method of claim 3, wherein an access selection descriptor portion of each of the ATSSS rules includes a non-3GPP access preference indication.

6. The wireless communication method of claim 3, wherein a traffic descriptor portion of the first ATSSS rule includes an indication of local Internet protocol, IP, descriptor identifying a source of IP traffic.

7. The wireless communication method of any of claims 1 to 6, wherein a steering functionality information of the first ATSSS rule indicates a multi-path quick user datagram protocol internet connection, MPQIIIC, functionality for non-3GPP access Type 2.

8. The wireless communication method of any of claims 1 to 7, further comprising: when a steering mode component of the ATSSS rule indicates a non-3GPP Type 2 with retention and no standby, maintaining the non-3GPP access a retention time after the 3GPP access is lost.

9. The wireless communication method of any of claims 1 to 8, further comprising: transmitting (462), to the NE, an indication of UE capability for the non-3GPP access Type 2 to the NE during a UE registration procedure (450) for connecting the UE to the wireless communication system; and receiving (468) an indication of network support for the non-3GPP access Type 2 during the registration procedure (450).

10. A user equipment, UE, (102, 120) comprising a processor (122), a transceiver (122, 124), and computer readable recording medium (128) storing executable codes that, when executed by the processor in collaboration with the transceiver, make the UE to perform any of the methods recited in claims 1 to 9.

11 . A wireless communication method (1000) performed by a network entity, NE, (130), the method comprising: establishing (1058) a multi-access packet data unit, MA PDU, session with a user equipment, UE, (102) in a wireless communication system, the MA PDU session using a 3GPP access and a non-3GPP access Type 2 with control signaling on the 3GPP access only; and transmitting (1091 ), to the UE, traffic steering, switching or splitting, ATSSS, rules including a first ATSSS rule specific for the non-3GPP access Type 2.

12. The wireless communication method of claim 11 , wherein the ATSSS rules fulfill one or more of: the ATSSS rules includes a first set of ATSSS rules for the non-3GPP access Type 2, and a second set of ATSSS rules for a non-3GPP access Type 1 , with a non- 3GPP access control signaling on the non-3GPP access as well as the control signaling on the 3GPP access, the first ATSSS rule pertaining to the first set of ATSSS rules, each of the ATSSS rules include an indication of non-3GPP type, an access selection descriptor portion of each of the ATSSS rules includes a non-3GPP access preference indication, the first ATSSS rule includes a local internet protocol, IP, descriptor identifying a source of IP traffic, a steering functionality information of the ATSSS rule indicates a multi-path quick user datagram protocol internet connection, MPQUIC, functionality for non-3GPP access Type 2, a steering mode component of the ATSSS rule indicates a non-3GPP Type 2 with retention and no standby to enable the UE to maintain the non-3GPP access a retention time after the 3GPP access is lost.

13. The wireless communication method of claim 11 or 12, further comprising at least one of: transmitting (682, 782), to the UE, a set of URSP rules during a UE configuration procedure (654, 754), at least one of the URSP rules indicating applicability for the non- 3GPP access Type 2; receiving (462), from the UE, an indication of UE capability for the non-3GPP access Type 2 to the NE during a UE registration procedure (450, 650, 750) for connecting the UE to the wireless communication system, and transmitting (468), to the UE, an indication of network support for the non-3GPP access Type 2 during the registration procedure; and transmitting (691 , 791 , 891 ), to the UE, ATSSS rules including the first ATSSS rule.

14. A network entity, NE, (104, 130) comprising a processor (132), a transceiver (132, 134), and computer readable recording medium (138) storing executable codes that, when executed by the processor in collaboration with the transceiver, make the NE to perform a wireless communication functionality and any of the methods recited in claims 11 to 13.