WO2024114962A1

WO2024114962A1 - Multiaccess data session

Info

Publication number: WO2024114962A1
Application number: PCT/EP2023/073087
Authority: WO
Inventors: Apostolis Salkintzis; Emmanouil Pateromichelakis; Dimitris DIMOPOULOS
Original assignee: Lenovo (Singapore) Pte. Ltd.
Priority date: 2023-08-03
Filing date: 2023-08-23
Publication date: 2024-06-06

Abstract

Various aspects of the present disclosure relate to a User Equipment, UE, for wireless communication. The UE comprises at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to perform steps of a method. The method includes sending a first request to a first application-layer function to establish an application-layer multiaccess data session, the multiaccess data session supporting data transmission over a plurality of access paths between the UE and a second application-layer function; receiving a response from the first application-layer function containing first information including information about the second application-layer function and a list of steering rules for steering uplink data from the UE across the plurality of access paths of the application-layer multiaccess data session; establishing the plurality of access paths between the UE and the second application-layer function using the first information; identifying a first uplink data flow generated by one or more applications residing on the UE that matches one of the steering rules from the list of steering rules; and transmitting the first uplink data flow to the second application-layer function over one or more of the access paths selected based on the steering rule matching the first uplink data flow.

Description

MULTIACCESS DATA SESSION

TECHNICAL FIELD

[0001] The present disclosure relates to wireless communications, and more specifically to multiaccess data sessions.

BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, such as base stations, which may be otherwise known as an eNodeB (eNB), a next-generation NodeB (gNB), or other suitable terminology. Each network communication devices, such as a base station may support wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE), or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers). Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G)).

[0003] An Access Traffic Steering, Switching, Splitting (ATSSS) feature, as defined in the 3 GPP specifications, provides a way for data traffic to be exchanged over multiple access networks between the User Equipment (UE) and a User Plane Function (UPF). This is typically carried out over one or more 3 GPP access networks, such as terrestrial or nonterrestrial Next Generation - Radio Access Networks (NG-RAN), as well as a non-3GPP access network like WLAN.

SUMMARY [0004] The present disclosure relates to methods, apparatuses, and systems that support an application layer multi-access data session.

[0005] Some implementations of the method and apparatuses described herein may further include a User Equipment, UE, for wireless communication and comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: send a first request to a first application-layer function to establish an application-layer multiaccess data session, the multiaccess data session supporting data transmission over a plurality of access paths between the UE and a second application-layer function; receive a response from the first application-layer function containing first information including information about the second application-layer function and a list of steering rules for steering uplink data from the UE across the plurality of access paths of the application-layer multiaccess data session; establish the plurality of access paths between the UE and the second application-layer function using the first information; identify a first uplink data flow generated by one or more applications residing on the UE that matches one of the steering rules from the list of steering rules; and transmit the first uplink data flow to the second application-layer function over one or more of the access paths selected based on the steering rule matching the first uplink data flow.

[0006] The first and second application-layer functions may reside at a node or nodes of a data network or in the core network of a PLMN. The UE may be further configured to send a session modification request or a session release request to the first application-layer function to modify a multiaccess data session or end a multiaccess data session respectively. All of the access paths may traverse a wireless access path portion. The first request may comprise at least one of: an identity of the multiaccess data session; an identity of a steering unit of the UE and its traffic steering capabilities; and a present location of the UE. The first information may comprise: a Proxy IP address; a Proxy UDP port; a Client IP address; and Measurement Assistance Information. A steering rule may define, for a given traffic type and application source, an access path of the plurality of access paths. The one or each application residing on the UE may be an application client or a vertical layer application, VAL, client.

[0007] Some implementations of the method and apparatuses described herein may further include a processor configured to operable to support a means for receiving, at a first application-layer function of the network node, a first request from a User Equipment, UE, to establish an application-layer multiaccess data session, the multiaccess data session supporting data transmission over a plurality of access paths between the UE and a second application-layer function; selecting a second application-layer function; sending a session establishment request to the second application-layer function; receiving a session establishment confirmation from the second application-layer function; and sending a response to the UE containing first information including information about the second application-layer function and a list of steering rules for steering uplink data across the plurality of access paths of the application-layer multiaccess data session. The first information may comprises: a Proxy IP address; a Proxy UDP port; a Client IP address; and Measurement Assistance Information. The second application-layer function may reside on the network node. The network node may be a Service Enabler Architecture Layer, SEAL, server.

[0008] Some implementations of the method and apparatuses described herein may further include a network node configured to: receive, at a first application-layer function of the network node, a first request from a User Equipment, UE, to establish an applicationlayer multiaccess data session, the multiaccess data session supporting data transmission over a plurality of access paths between the UE and a second application-layer function; select a second application-layer function; send a session establishment request to the second application-layer function; receive a session establishment confirmation from the second application-layer function; and send a response to the UE containing first information including information about the second application-layer function and a list of steering rules for steering uplink data across the plurality of access paths of the application-layer multiaccess data session. The first information about the second application-layer function may comprise: a Proxy IP address; a Proxy UDP port; a Client IP address; and Measurement Assistance Information. The second application-layer function may reside on the network node. The network node may be a Service Enabler Architecture Layer, SEAL, server.

[0009] Some implementations of the method and apparatuses described herein may further include a network node configured to receive, from a User Equipment, UE, a first uplink data flow to a second application-layer function of the network node over an access path selected based on a first steering rule sent to the UE from a first application-layer function. The network node may be a SEAL-Data Delivery server.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 illustrates an example of a wireless communications system that supports a multiaccess data session in accordance with aspects of the present disclosure.

[0011] Figure 2 illustrates a wireless network architecture that supports a multiaccess data session in accordance with aspects of the present disclosure.

[0012] Figure 3 illustrates a wireless network architecture that supports a multiaccess data session in accordance with aspects of the present disclosure.

[0013] Figure 4 illustrates an alternative wireless network architecture that supports a multiaccess data session in accordance with aspects of the present disclosure.

[0014] Figure 5 shows a method of establishing a multiaccess data session.

[0015] Figure 6 illustrates two examples of steering rules for a multiaccess data session.

[0016] Figure 7 is a functional diagram of a UE and an ATPS according to aspects of the present disclosure.

[0017] Figure 8 is shows a method of triggering establishment of a multiaccess data session according to aspects of the present disclosure.

[0018] Figure 9 shows a method of a UE initiating a multiaccess data session according to aspects of the present disclosure.

[0019] Figure 10 illustrates a SEAL architecture.

[0020] Figure 11 illustrates a wireless network architecture that supports a multiaccess data session in accordance with aspects of the present disclosure.

[0021] Figure 12 shows a method of establishing a multiaccess data session according to aspects of the present disclosure.

[0022] F igures 13, 14, and 15 illustrate an example of a device that supports a multiaccess data session in accordance with aspects of the present disclosure. [0023] Figures 16 through 18 illustrate flowcharts of methods that support a multiaccess data session in accordance with aspects of the present disclosure.

DETAILED DESCRIPTION

[0024] The present application relates to an application-layer Access Traffic Steering, Switching and Splitting (ATSSS) configuration. ATSSS may be used in a multiaccess data session.

[0025] Figure 1 illustrates an example of a wireless communications system 100 that supports a multiaccess data session in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more network entities 102 (also referred to as network equipment (NE)), one or more UEs 104, a core network 106, and a packet data network 108. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE- Advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a 5G network, such as an NR network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA), frequency division multiple access (FDMA), or code division multiple access (CDMA), etc.

[0026] The one or more network entities 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the network entities 102 described herein may be or include or may be referred to as a network node, a base station, a network element, a radio access network (RAN), a base transceiver station, an access point, a NodeB, an eNodeB (eNB), a next-generation NodeB (gNB), or other suitable terminology. A network entity 102 and a UE 104 may communicate via a communication link 110, which may be a wireless or wired connection. For example, a network entity 102 and a UE 104 may perform wireless communication (e.g., receive signaling, transmit signaling) over a Uu interface.

[0027] A network entity 102 may provide a geographic coverage area 112 for which the network entity 102 may support services (e.g., voice, video, packet data, messaging, broadcast, etc.) for one or more UEs 104 within the geographic coverage area 112. For example, a network entity 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc.) according to one or multiple radio access technologies. In some implementations, a network entity 102 may be moveable, for example, a satellite associated with a non-terrestrial network. In some implementations, different geographic coverage areas 112 associated with the same or different radio access technologies may overlap, but the different geographic coverage areas 112 may be associated with different network entities 102. Information and signals described herein may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0028] The one or more UEs 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a mobile device, a wireless device, a remote device, a remote unit, a handheld device, or a subscriber device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an Intemet-of- Things (loT) device, an Internet-of-Everything (loE) device, or machine-type communication (MTC) device, among other examples. In some implementations, a UE 104 may be stationary in the wireless communications system 100. In some other implementations, a UE 104 may be mobile in the wireless communications system 100.

[0029] The one or more UEs 104 may be devices in different forms or having different capabilities. Some examples of UEs 104 are illustrated in Figure 1. A UE 104 may be capable of communicating with various types of devices, such as the network entities 102, other UEs 104, or network equipment (e.g., the core network 106, the packet data network 108, a relay device, an integrated access and backhaul (IAB) node, or another network equipment), as shown in Figure 1. Additionally, or alternatively, a UE 104 may support communication with other network entities 102 or UEs 104, which may act as relays in the wireless communications system 100.

[0030] A UE 104 may also be able to support wireless communication directly with other UEs 104 over a communication link 114. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to- everything (V2X) deployments, or cellular-V2X deployments, the communication link 114 may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0031] A network entity 102 may support communications with the core network 106, or with another network entity 102, or both. For example, a network entity 102 may interface with the core network 106 through one or more backhaul links 116 (e.g., via an SI, N2, N2, or another network interface). The network entities 102 may communicate with each other over the backhaul links 116 (e.g., via an X2, Xn, or another network interface). In some implementations, the network entities 102 may communicate with each other directly (e.g., between the network entities 102). In some other implementations, the network entities 102 may communicate with each other or indirectly (e.g., via the core network 106). In some implementations, one or more network entities 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC). An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs).

[0032] In some implementations, a network entity 102 may be configured in a disaggregated architecture, which may be configured to utilize a protocol stack physically or logically distributed among two or more network entities 102, such as an integrated access backhaul (IAB) network, an open RAN (O-RAN) (e.g., a network configuration sponsored by the O-RAN Alliance), or a virtualized RAN (vRAN) (e.g., a cloud RAN (C-RAN)). For example, a network entity 102 may include one or more of a central unit (CU), a distributed unit (DU), a radio unit (RU), a RAN Intelligent Controller (RIC) (e.g., a Near-Real Time RIC (Near-RT RIC), a Non-Real Time RIC (Non-RT RIC)), a Service Management and Orchestration (SMO) system, or any combination thereof.

[0033] An RU may also be referred to as a radio head, a smart radio head, a remote radio head (RRH), a remote radio unit (RRU), or a transmission reception point (TRP). One or more components of the network entities 102 in a disaggregated RAN architecture may be co-located, or one or more components of the network entities 102 may be located in distributed locations (e.g., separate physical locations). In some implementations, one or more network entities 102 of a disaggregated RAN architecture may be implemented as virtual units (e.g., a virtual CU (VCU), a virtual DU (VDU), a virtual RU (VRU)).

[0034] Split of functionality between a CU, a DU, and an RU may be flexible and may support different functionalities depending upon which functions (e.g., network layer functions, protocol layer functions, baseband functions, radio frequency functions, and any combinations thereof) are performed at a CU, a DU, or an RU. For example, a functional split of a protocol stack may be employed between a CU and a DU such that the CU may support one or more layers of the protocol stack and the DU may support one or more different layers of the protocol stack. In some implementations, the CU may host upper protocol layer (e.g., a layer 3 (L3), a layer 2 (L2)) functionality and signaling (e.g., Radio Resource Control (RRC), service data adaption protocol (SDAP), Packet Data Convergence Protocol (PDCP)). The CU may be connected to one or more DUsor RUs, and the one or moreDUs or RUs may host lower protocol layers, such as a layer 1 (LI) (e.g., physical (PHY) layer) or an L2 (e.g., radio link control (RLC) layer, medium access control (MAC) layer) functionality and signaling, and may each be at least partially controlled by the CU 160.

[0035] Additionally, or alternatively, a functional split of the protocol stack may be employed between a DU and an RU such that the DU may support one or more layers of the protocol stack and the RU may support one or more different layers of the protocol stack. The DU may support one or multiple different cells (e.g., via one or more RUs). In some implementations, a functional split between a CU and a DU, or between a DU and an RU may be within a protocol layer (e.g., some functions for a protocol layer may be performed by one of a CU, a DU, or an RU, while other functions of the protocol layer are performed by a different one of the CU, the DU, or the RU).

[0036] A CU may be functionally split further into CU control plane (CU-CP) and CU user plane (CU-UP) functions. A CU may be connected to one or more DUs via a midhaul communication link (e.g., Fl, Fl-c, Fl-u), and a DU may be connected to one or more RUs via a fronthaul communication link (e.g., open fronthaul (FH) interface). In some implementations, a midhaul communication link or a fronthaul communication link may be implemented in accordance with an interface (e.g., a channel) between layers of a protocol stack supported by respective network entities 102 that are in communication via such communication links.

[0037] The core network 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The core network 106 may be an evolved packet core (EPC), or a 5G core (5GC), which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME), an access and mobility management functions (AMF)) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW), a Packet Data Network (PDN) gateway (P-GW), or a user plane function (UPF)). In some implementations, the control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc.) for the one or more UEs 104 served by the one or more network entities 102 associated with the core network 106.

[0038] The core network 106 may communicate with the packet data network 108 over one or more backhaul links 116 (e.g., via an SI, N2, N2, or another network interface). The packet data network 108 may include an application server 118. In some implementations, one or more UEs 104 may communicate with the application server 118. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the core network 106 via a network entity 102. The core network 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server 118 using the established session (e.g., the established PDU session). The PDU session may be an example of a logical connection between the UE 104 and the core network 106 (e.g., one or more network functions of the core network 106).

[0039] In the wireless communications system 100, the network entities 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communications). In some implementations, the network entities 102 and the UEs 104 may support different resource structures. For example, the network entities 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the network entities 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5G and among other suitable radio access technologies, the network entities 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures). The network entities 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0040] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., /r=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., /r=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., /r=l) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., /r=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., /r=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., /r=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0041] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames). Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0042] Additionally or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., /r=0, jU=l, /r=2, jU=3, /r=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing), a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., /i =0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0043] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designations FR1 (410 MHz - 7.125 GHz), FR2 (24.25 GHz - 52.6 GHz), FR3 (7.125 GHz - 24.25 GHz), FR4 (52.6 GHz - 114.25 GHz), FR4a or FR4-1 (52.6 GHz - 71 GHz), and FR5 (114.25 GHz - 300 GHz). In some implementations, the network entities 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the network entities 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data). In some implementations, FR2 may be used by the network entities 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0044] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies). For example, FR1 may be associated with a first numerology (e.g., /r=0), which includes 15 kHz subcarrier spacing; a second numerology (e.g., /r=l), which includes 30 kHz subcarrier spacing; and a third numerology (e.g., /r=2), which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies). For example, FR2 may be associated with a third numerology (e.g., /r=2), which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., /r=3), which includes 120 kHz subcarrier spacing.

[0045] A simplified ATSSS architecture, as defined in the present 3GPP specifications, is depicted in Figure 2.

[0046] Figure 2 shows a UE 104 comprising an Application client 108 and an ATSSS client 110. The Application client 108 is configured to send and receive data to and from a User Plane Function (UPF) 112 in an external data network 106. The UPF 112 interacts with an Application Server 114 in the same or a different external data network 116 to provide data transfer between the UE 104 and the Application Server 114.

[0047] ATSSS provides a way for data traffic to be exchanged over multiple access networks between the UE 104 and the UPF 112. In order to enable ATSSS, a Multiaccess Packet Data Unit (MA PDU) Session must be established. The MA PDU Session creates multiple "access paths" between the UE 104 and UPF 112, each path using either a 3GPP access network or a non-3GPP access network. The data traffic from the MA PDU Session is then distributed across these paths. This distribution relies on steering policies provided by the 5G core (5GC) network 106 to the UE 104 and the UPF 112 for distributing traffic in the uplink and downlink directions, respectively. The steering policies are created by a Policy Control Function (PCF) 118 during the MA PDU Session establishment procedure and are employed by the Session Management Function (SMF) 120 to create "ATSSS rules" for the UE 104 and "Multiaccess Rules (MAR)" for the UPF 112.

[0048] A problem in implementing ATSSS in real-world mobile networks results from the broad network-wide impact it has. Specifically, ATSSS affects many network functions within the 3 GPP architecture, including the UE 104, UPF 112, an Access and Mobility Management Function (AMF) 122, SMF 120, PCF 118, etc. Moreover, it demands non-3GPP interworking functions, such as a Non-3GPP Interworking Function (N3IWF) 124 and a Trusted Non-3GPP Gateway Function (TNGF) 124, to support access paths over non-3GPP access networks. Therefore, implementing ATSSS in practice means carrying out substantial and complex changes to many 5G network functions and supporting non-3GPP interworking functions and the associated procedures in the UE 104 for communicating with these functions.

[0049] Provided in the present application is a simplified ATSSS solution. This solution offers the same benefits as the existing ATSSS solution defined in the 3 GPP specifications, e.g., in 3GPP TS 23.501, 3GPP TS 23.502, and 3GPP TS 24.193, allowing data traffic to be exchanged over multiple access networks, but is also (a) more easily implementable in practice and (b) supports more use cases, e.g. , it allows access paths to traverse or not traverse a 5G core network, or to traverse different 5G core networks. Therefore, access paths using non-3GPP access may be supported without the need of an interworking function, like N3IWF or TNGF shown in Figure 2. In other words, it offers the advantages of existing ATSSS functions without the implementation drawbacks and with expanded scope. In particular, this disclosure defines an “Application-layer ATSSS solution”, i.e., an ATSSS solution that operates in the application layer and, therefore, does not require any changes in the underlying 5G core network and, consequently, is based on different architectural elements, such as network functions and interfaces to existing ATSSS method.

[0050] Aspects of the present disclosure are described in the context of a wireless communications system.

[0051] The reference architecture of the “Application-layer ATSSS” solution introduced in this disclosure is illustrated in Figure 3. The architecture introduces the following new application-layer functions: o ATSSS Enablement Client (ATEC) 126: An application-layer function on the UE 104 side, which triggers the establishment of an Application-Layer ATSSS (AL-ATSSS) Session and then transmits data traffic to an ATSSS Proxy Server (ATPS) 128 over multiple access paths. The ATEC 126 decides how to transmit the data traffic over the multiple access paths by using received ATSSS client rules. The ATEC 126 is an example of a Steering function of the UE 104; o ATSSS Configuration Server (ATCS) 130: An application-layer function on the network side (e.g., inside a Data Network DN 116)), which supports the establishment of AL-ATSSS Session between an ATEC 126 and an ATPS 128. The ATCS 130 handles control-plane signaling required to establish, modify, and release an AL-ATSSS Session. For each AL-ATSSS Session, the ATCS 130 selects an ATPS 128 and creates the appropriate ATSSS rules for the ATEC 126 and for the ATPS 128. The ATCS 130 may communicate with other application-layer enablement servers defined in 3 GPP, such as SEAL servers (see TS 23.434). Alternatively, the ATCS 130 can be called an “ATSSS Session Management Server”. The ATCS 130 is an example of a first application-layer function; o ATSSS Proxy Server (ATPS) 128: An application-layer function on the network side (e.g., inside a Data Network DN 116)), which handles the userplane aspects of an AL-ATSSS Session. An ATPS 128 is responsible for receiving user-plane data traffic from the ATEC 126 across multiple access paths, to aggregate this data traffic and forward it to the final destination (e.g., an Application Server 114). An ATPS 128 is also responsible for receiving user-plane data traffic from the final destination and forwarding this data traffic to the ATEC 126 across the multiple access paths. The ATPS 128 decides how to transmit the data traffic over the multiple access paths by using the received ATSSS proxy rules.

[0052] The interfaces marked with ATSSS-1/-2/-3/-U/-P enable communication between different components of the architecture. For example, as will be presented later, the interface ATSSS-1 is used by the ATEC 126 to request and establish an App-layer ATSSS (AL- ATSSS) Session.

[0053] The Command API Framework (CAPIF) core function (CAPIF CF) 132 illustrated in Figure 3 is an existing function which can be used (a) by the ATCS 130 to register its supported services (e.g., to register the support of a new ATCS API) and (b) by the Application Server 114 to discover and consume the services registered by ATCS 130. As an example, the ATCS 130 may provide a service (via the new ATCS API) that allows an Application Server 114 to define the preferred ATSSS client and proxy rules for the traffic associated with an application. This way, the Application Server 114 can effectively indicate how the application traffic between the Application 108 Client and the Application Server 114 should preferably be distributed across multiple accesses.

[0054] The Network Exposure Function (NEF) 134 illustrated in Figure 3 is another existing function that enables network functions in the 5G core network to interact with Application Functions (AFs), like the ATCS 130 and ATPS 128. As an example, a Network Data Analytics Function in the 5G core network (NWDAF) may subscribe with the ATPS 128, via the NEF 134, in order to receive performance data for the application running between the Application Client 104 and the Application Server 114 and apply this data to derive performance analytics or predictions.

[0055] The architecture shown in Figure 3 illustrates functional elements in the architecture. In practice, every functional element can be implemented in a server dedicated to host this functional element only or can be implemented in a server that hosts multiple different functional elements. In addition, a functional element can be incorporated in another functional element, enhancing the capabilities of the latter functional element. For example, the ATPS function can be incorporated in a UPF function, thus, enhancing the capabilities of the UPF function.

[0056] The reference architecture shown in Figure 3 illustrates a scenario where there are two access paths between the ATEC 126 and the ATPS 128. One access path using 3GPP access (e.g., NG-RAN) that goes through a 5G core network 106, and another access path using non-3GPP access (e.g., WiFi or Satellite) that bypasses the 5G core network 106. The first access path is created after establishing a PDU Session in the 5G core network 106. In another scenario, however, the access paths between the ATEC 126 and the ATPS 128 may all go through a single 5G core network 106 or multiple 5G core networks 106. In addition, there might be more than two access paths, for example, one using 3GPP access that goes through a first 5G core network 106, another using 3GPP access that goes through a second 5G core network 106 and another using WiFi access that does not go through a 5G core network 106. [0057] Figure 4 shows an architecture according to another embodiment of the present disclosure. In the architecture shown in Figure 4, the ATCS 130 and the ATPS 128 are combined into an application-layer function called ATSSS Enablement Server (ATES) 136. The ATES 136 may communicate with other app-layer enablement servers defined in 3 GPP, such as SEAL servers (see TS 23.434).

[0058] A proposed procedure using the reference architecture shown in Figure 3 is described. However, the same procedure can be used with the reference architecture shown in Figure 4, where the ATES 136 performs the functions of both the ATCS 130 and the ATPS 128.

[0059] Before data traffic (e.g. user-plane data traffic) can be distributed across multiple access paths between the ATEC 126 and ATPS 128, an Application layer ATSSS (AL- ATSSS) Session must be established. The purpose of establishing this session is to configure the ATEC 126 and the ATPS 128 with the necessary parameters before they can start exchanging data traffic. The method for establishing an Application layer ATSSS Session is illustrated in Figure 5 and is discussed below.

[0060] It is assumed that the ATEC 126 has created multiple IP connections and therefore it possesses multiple IP addresses. For example, the ATEC 126 has established a PDU Session over a 5G core network and has received the address IP@1, and has connected to a public WiFi hotspot and has received the address IP@2. The ATEC 126 decides to: create an AL- ATSSS Session with an ATPS 128; and utilize its multiple IP connections for multiaccess communication with the ATPS 128.

[0061] In step 600, an optional trigger procedure may take place, which triggers the ATEC 126 to initiate the AL-ATSSS Session establishment with the following steps. This trigger procedure can be initiated either by the Application Server 113 or by an Application Client 108 in the UE 104. In general, the ATEC 126 may decide to initiate an AL-ATSSS establishment procedure, either by using its own implementation-specific triggers, or after a trigger procedure takes place. Further description of the trigger procedure is provided below. [0062] In step 601, the ATEC creates a Transmission Control Protocol (TCP) connection with the ATCS 130 and a Transport Layer Security (TLS) is applied for mutual authentication and activation of data integrity and confidentiality (using the TLS profiles specified in Technical Specification (TS) 33.210). The particular method applied for mutual authentication can be any applicable method known in the prior art. Alternatively, the ATEC 126 may use User Datagram Protocol (UDP) and the Datagram Transport Layer Security (DTLS) protocol for mutual authentication and activation of data integrity and confidentiality. The ATEC 126 is either configured with the IP address of ATCS 130 (IP@4), or it discovers this IP address with known methods (e.g., using the DNS protocol).

[0063] The messages cited below, which are exchanged between the ATEC 126 and ATCS 130, are either transported over the HTTP protocol (when TCP & TLS are used) or over the Constrained Application Protocol (CoAP) (when UDP & DTLS are used).

[0064] In step 602, the ATEC 126 sends an ATSSS Session Establishment Request message to the ATCS 130. Alternatively, this message can be called an AL- ATSSS Session Establishment Request. This message contains an identity of the AL-ATSSS session (selected by ATEC 126), the identity of the ATEC 126 and its ATSSS capabilities, which indicate, for example, what type of steering functionalities are supported by the ATEC 126, such as Multipath TCP (MPTCP), Multipath Quick UDP Internet Connections (MPQUIC), etc., what type of steering modes are supported by the ATEC 126, etc. This message may also contain the present location of the ATEC 126.

[0065] In step 603, the ATCS 130 decides to accept or reject the request from ATEC 126 based on, for example, a local configuration or subscription information. If the request is not rejected, the ATCS 130 selects an ATPS 128 to serve the requested AL-ATSSS Session. This selection can take into account the ATSSS capabilities provided by the ATEC 126 (to select an ATPS 128 that can support these capabilities) and can take into account the present location of ATEC 126 (to select an ATPS 128 close to the ATEC 126).

[0066] In step 604, the ATCS 130 creates two sets of ATSSS rules: (a) ATSSS client rules for the ATEC 126 and (b) ATSSS proxy rules for the selected ATPS 128. The ATSSS client rules indicate how the uplink data traffic transmitted from ATEC 126 to ATPS 128 should be distributed across the access paths of the AL-ATSSS Session, while the ATSSS proxy rules indicate how the downlink data traffic transmitted from ATPS 128 to ATEC 126 should be distributed across the access paths of the AL-ATSSS Session.

[0067] The structure of the ATSSS client and proxy rules can be the same or similar with the structure ofthe ATSSS rules defined in TS 23.503. An example oftwo ATSSS rules are shown in Figure 6. [0068] The first ATSSS rule specifies that the matched traffic should be routed using load-balance traffic steering and indicates that the traffic should be load balanced in a way that maximizes the aggregated throughput (as indicated by the “autonomous load-balance operation” parameter). The rule also indicates that the MPTCP steering functionality should be applied in the ATEC 126 and in the ATPS 128 for steering the matched traffic across the available access paths.

[0069] The second ATSSS rule specifies that the matched traffic should be routed using smallest-delay traffic steering, i.e., data should be transmitted across the access path that provides the smallest delay. The rule also indicates that the MPQUIC steering functionality should be applied in the ATEC 126 and in the ATPS 128 for steering the matched traffic across the available access paths.

[0070] Referring back to Figure 5, in step 605a, the ATCS 130 sends a Proxy Session Establishment Request message to the selected ATPS 128 to configure the ATPS 128 with the necessary information for supporting the requested AL- ATSSS Session and for reserving the necessary resources at the ATPS 128. This message contains the identity of the ATEC 126, its ATSSS capabilities and the created ATSSS proxy rules.

[0071] If the ATPS 128 can support the requested AL-ATSSS Session, the ATPS 128 accepts the request and responds to ATCS 130 with a Proxy Session Establishment Accept message (step 605b). This message contains the Proxy IP address (i.e., the address where the ATEC 126 should send data traffic to), the Proxy port (e.g., the destination UDP port that should be used by the ATEC 126 for sending data traffic to the ATPS 128), a Client IP address (i.e., the address allocated to ATEC 126 for sending data traffic via the ATPS 128) and Measurement Assistance Information (i.e., parameters that assist the ATEC 126 in communicating with ATPS 128 for taking delay and/or loss rate measurements over each of the access paths). For taking these measurements, the existing Performance Measurement Function Protocol (PMFP) can be used (as defined in TS 24.193). The message in step 605b may alternatively contain multiple UDP ports (instead of one UDP port), each one to be used over a different access path.

[0072] Alternatively, the Measurement Assistance Information may not be provided by the ATPS 128 in step 605b but may be created by the ATCS 130 and provided to the ATEC 126 in the following step 606. [0073] In step 606, the ATCS 130 responds to ATEC’s 126 request (in step 602) by sending an ATSSS Session Establishment Accept message, which contains all of the parameters provided by the ATPS 128 is step 5b, plus the ATSSS client rules created by the ATCS 130 in step 604.

[0074] In step 607, the AL-ATSSS Session is established and the ATEC 126 and the ATPS 128 can start exchanging user-plane data traffic over the available access paths of this session (steps 607a and 607b), i.e., using the different IP connections available at the ATEC 126. In addition, the ATEC 126 and the ATPS 128 can start exchanging PMFP messages over the available access paths in order to take delay (or RTT) measurements and loss rate measurements. These measurements are necessary when the ATSSS rules indicate that some data traffic should be routed to the access path with the smallest delay, for example.

[0075] Figure 7 illustrates an example architecture that enables user-plane data communication between the ATEC 126 and the ATPS 128 after the establishment of the AL- ATSSS Session. On the ATEC 126 side, the ATSSS client rules are applied to select, for each data flow provided by the Application Client 108, a steering functionality (MPTCP, MPQUIC, ATSSS Low Layer Functionality (ATSSS-LL)) and a steering mode, which determines how the packets of the data flow should be distributed over the access paths. The PMFP protocol is also implemented for sending packets across the access paths to measure performance characteristics, such as delay, loss rate, jitter, etc. On the ATPS 128 side, the ATSSS proxy rules are applied to select, for each data flow received from the Application Server 114, a steering functionality (MPTCP, MPQUIC, ATSSS-LL) and a steering mode, which determines how the packets of the data flow should be distributed over the access paths. Again, the PMFP protocol is implemented for sending packets across the access paths to measure their performance characteristics.

[0076] The ATEC 126 may also send an ATSSS Session Modification Request message to the ATCS 130 or an ATSSS Session Release Request message to the ATCS 130 to modify and release an existing AL-ATSSS Session respectively.

[0077] Figure 8 shows how an AL-ATSSS Session Establishment can be triggered by an Application Server 114. In some scenarios, the Application Server 114 can be a Vertical Application Layer (VAL) Server or an Edge Application Server (EAS). [0078] In this procedure, the Application Server 114 sends a request to the ATCS 130 to manage an AL-ATSSS Session and to configure the AL-ATSSS Session parameters used for a specific ATEC 126. Figure 8 illustrates the procedure using a request-response model. However, according to an alternative embodiment, a subscribe-notify model may be used.

[0079] In Step 900, the application server discovers the ATCS 130 (e.g., via the Common Application Programming Interface Framework (CAPIF) Core Function 132).

[0080] In step 901, the application server sends to the ATCS 130 an “AL-ATSSS session management request” message for managing an AL-ATSSS session and optionally to subscribe for AL-ATSSS related notifications (e.g., when AL-ATSSS session is established or modified). This message may include at least one of the following: the Application Server ID; the UE ID (for which the management applies, it can be for example an external ID e.g. a Generic Public Subscription Identifier (GPSI)); a Public Land Mobile Network (PLMN) ID, Non-Public Network (NPN) ID, or Wireless Local Area Network (WLAN) ID; information on the VAL UE capabilities; Application type or service ID (this can be used if the ATSSS is for a certain application type e.g. V2X), Application session requirements (end to end QoS requirements); and time and area of validity for the request.

[0081] In step 902, the ATCS 130 sends to the application server an AL-ATSSS session management response with a positive or negative acknowledgement of the request, based on a capability of ATCS 130 to undertake the task.

[0082] In step 903, the ATCS 130 may send an “AL-ATSSS configuration command” to the ATEC 126 to provide the configuration of information such as the PLMN, NPN, or WLAN ID and addresses (if not already known), the Application session requirements and the time and/or area of validity for the configuration of the multiaccess session.

[0083] In step 904, the ATEC 126 initiates the AL-ATSSS Session establishment procedure as described above.

[0084] In step 905, after execution of AL-ATSSS session establishment, the ATCS notifies the application server with an “AL-ATSSS session management complete” message. [0085] Figure 9 shows a procedure where the Application Client in the UE sends a request to the ATEC to manage an AL-ATSSS Session. Figure 9 illustrates the procedure using a request-response model. However, a subscribe-notify model may alternatively be used. [0086] The steps of this method are performed under the pre-condition that the ATEC 126 has discovered the ATCS 130.

[0087] In step 1001, the application client sends an AL-ATSSS session management request message to the ATEC 126 for managing the AL-ATSSS sessions and optionally to subscribe for AL-ATSSS related notifications (e.g. when the AL-ATSSS session is established or modified). This message includes at least one of: an Application ID; an Application Server ID and address; a PLMN, NPN, or WLAN ID; the VAL UE capabilities; Application type/service ID (this can be used if the ATSSS is for a certain app type e.g. V2X); and optionally the Application session requirements (end to end QoS requirements), and time and area of validity for the request.

[0088] In step 1002, the ATEC 126 sends an AL-ATSSS session management response to the application client with a positive or negative acknowledgement of the request, based on capability of the ATEC 126 to undertake the task.

[0089] In step 1003, the ATEC 126 executes AL-ATSSS session establishment as described above.

[0090] In step 1004, after execution of AL-ATSSS session establishment, the ATEC 126 notifies the application client with an AL-ATSSS session management complete message.

[0091] In step 1005, the ATCS 130 may also notify the Application Server 114 on the AL-ATSSS session establishment.

[0092] According to another embodiment, a solution is provided based on the Service Enabler Architecture Layer (SEAL) standard.

[0093] 3 GPP SA6 is the application enablement and critical communications applications group for vertical markets and provides application layer architecture specifications for verticals, including architecture requirements and functional architecture for supporting the integration of verticals to 3GPP systems. Vertical Applications, hosted by Vertical Application Layer (VAL) Servers, include applications from automotive sector, factory of the future, UAS, massive loT, eHealth etc.

[0094] Support for multiaccess sessions (including non-3GPP access) is not considered yet; nevertheless SA6 considers the following features which may be relevant to or impact the introduction of the proposed solution: [0095] SEAL layer (3 GPP TS 23.434) is an “umbrella” framework which comprises a set of common services and/or capabilities (Group Management, Location Management, Identity Management, Key Management, Network Resource Management, Configuration Management, Slice Capability Enablement, Notification Management, Application Data Analytics Enablement) which can be consumed by most verticals. From these enablers, some of the enablers that are relevant to the present disclosure are the following:

• A Location Management Server (LMS) monitors the location of the VAL UEs and provides location reports to verticals. LMS acquires location reports either from a Core Network (via NEF) or from VAL UEs using either 3 GPP access or non-3GPP access links (or both in fused location services). However, in Rel-18 specifications the non-3GPP access for obtaining location reports are not specified.

• A Configuration Management Server (CMS) configures one or more vertical applications with 3 GPP system-related vertical applications’ provisioning information and configures data on the configuration management client. Such data can be for instance VAL service specific data and VAL UE profile data.

• A SEAL-Data Delivery (SEALDD) server provides support for the data delivery of vertical application traffic. The SEALDD server functional entity acts as the application server for the data delivery enablement. The SEALDD server supports the following capabilities: i. Supporting the transmission for application signalling data and application media/data, by using the 3GPP network. ii. Providing the application data/media handling capabilities (e.g. storage, management, transmission). iii. Interacting with 5GC via N33/N5 (i.e. send control plane requirements or receive control plane notification) with usage of capability exposed by 3 GPP network. [0096] The SEALDD layer provides capabilities related to transport optimization, support for e2e path redundancy, data caching at the DN, and application layer quality assurance, etc. A high level architecture is illustrated in Figure 10 (from TS 23.433). One of the capabilities in SEALDD is a regular connection management which is used for establishing an SEALDD enabled end-to-end connection between a VAL client 1108 and a VAL server 1114.

[0097] Figure 11 shows an architecture for a SEAL-based solution which can be implemented in the case when the ATSSS enabler layer has an enhanced capability to use existing SEAL/SEAL-DD services.

[0098] The following functionalities according to the present embodiment:

• An ATCS 1130, which is part of SEAL server, implemented either as a new server or as enhancement of an existing server (e.g. a Configuration Management Server)

• An ATCC 1126 as a client counterpart of the ATCS 1130, which is part of SEAL and implemented either as a new client or as enhancement of an existing client (e.g., Configuration Management client)

• An ATPS 1128 which can be part of a SEALDD server implemented as a new capability or as a new type of SEALDD server

• An ATPC 1140 which the client counterpart of the ATPS 1128 and supports multiaccess data delivery

The ATCS 1130 and ATPS 1128 can interact via a SEAL-X API, or they can be co-located.

• An ATC-C is an interface for enabling the configuration of ATSSS rules to the VAL UE, and an ATPC-UU is the user plane access via multiple access paths

• A CAPIF CF 1132 may be used to allow the ATCS 1130 to discover ATPS 1128 information as well as to allow the VAL server to discover the ATCS 1130. [0099] For the capability initiation, the steps are similar to those of the previous embodiment, with the following assumptions, based on existing entities as defined in TS 23.434:

• The ATCS 1130 is a service or functionality of a SEAL server 1130, and in particular is a Configuration Management Server (or alternatively it can be a new or enhanced other SEAL server which supports AL-ATSSS management)

• The ATEC is logically deployed as two services, an ATCC 1126 and an ATPC1140. ATEC services as described in the previous embodiment are deployed as part of SEAL clients (as a Configuration Management Client or as other new or enhanced SEAL client which supports AL-ATSSS management)

• The Application Server and Client are the VAL server 1114 and Client 1108 respectively (for example a VAL server can be a V2X server or an IIOT server).

[0100] Figure 12 shows the steps of a procedure according to the present embodiment.

[0101] In step 1, the VAL server or the SEAL server including the ATCS selects a proxy and creates ATSSS rules (assuming that the capability initiation has been performed as in the previous embodiment).

[0102] In step 2, the VAL server or the SEAL server including the ATCS decides to use a SEALDD service for application traffic transfer for the AL-ATSSS sessions, and allocates an address or port as SEALDD-S Data transmission connection information for receiving the data packets from the SEALDD server. The ATCS sends an Sdd ATSSS session management request to the SEALDD server which is going to act as a proxy (ATPS) discovered by the CAPIF.

[0103] In step 3, upon receiving the request, the SEALDD server performs an authorization check. If authorization is successful, the SEALDD server agrees on acting as the ATPS and allocates an address/port of the SEALDD server to receive data packets from the VAL server for application data transfer. The allocation of the address/port represents SEALDD-S data transmission connection information of the SEALDD server. The SEALDD server allocates a specific address or port used for SEALDD traffic transfer with a specific UE. The specific address or port may be used by the VAL server over multiple access paths (both 3GPP access and non-3GPP access). The SEALDD server responds to the request with a SEALDD service response (including SEALDD-S data transmission connection information of the SEALDD server side).

[0104] In step 4, data transmission session information (including configuration parameters and the created rules for the AL-ATSSS sessions) is sent to the VAL client by the VAL server via application signalling (via SEAL (e.g. VAL server- ATCS-ATCC-V AL client or directly via application specific signaling)).

[0105] In step 5, the VAL client sends a SEALDD service request for an AL-ATSSS type of session to the SEALDD client. The VAL client receives a SEALDD service response from the SEALDD client. The response indicates whether the SEALDD service request is successful or not.

[0106] In step 6, the SEALDD client (optionally with the support of the SEAL client acting as an ATCC) discovers and selects the proper SEALDD server who is selected to act as the ATPS for the VAL application. After this step, the VAL server is discovered and selected along with the associated SEALDD server, and the SEALDD client can acquire the SEALDD server's address.

[0107] There may be more than one ATPS/ SEALDD server for the AL-ATSSS session, and according to SA6, a SEALDD client may connect to more than one SEALDD servers. This step is based on the existing step for regular connection management in SEALDD and is enhanced for multiaccess sessions.

[0108] In step 7, the SEALDD client allocates a SEALDD flow ID mapping to the identifiers of the application traffic, and sends an AL-ATSSS connection establishment request.

[0109] In step 8, the SEALDD server responds to the SEALDD client with the SEALDD traffic descriptor of the SEALDD server side (e.g. address/port allocated in step 3, transport layer protocol) mapping to the application traffic.

[0110] In step 9, if the connection between the VAL server and the SEALDD server is not established in step 3, the SEALDD server establishes a multiaccess connection with the VAL server for the VAL client to transmit application traffic mapping to the SEALDD traffic according to the SEALDD-S information negotiated in steps 2 and 3.

[0111] In step 10, the SEALDD client uses the SEALDD traffic descriptor of SEALDD server side for the multiaccess SEALDD connection establishment.

[0112] Figure 13 illustrates an example of a device 1400 that supports a multiaccess data session in accordance with aspects of the present disclosure. The device 1400 may be an example of a UE 104 as described herein. The device 1400 may support wireless communication with one or more network entities 102, UEs 104, or any combination thereof. The device 1400 may include components for bi-directional communications including components for transmitting and receiving communications, such as a processor 1402, a memory 1404, a controller 1406, a transceiver 1408, and, optionally, an I/O controller. These components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses).

[0113] The processor 1402, the memory 1404, the controller 1406, the transceiver 1408, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. For example, the processor 1402, the memory 1404, the controller 1406, the transceiver 1408, or various combinations or components thereof may support a method for performing one or more of the operations described herein.

[0114] In some implementations, processor 1402, the memory 1404, the controller 1406, the transceiver 1408, or various combinations or components thereof may be implemented in hardware (e.g., in communications management circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic, discrete hardware components, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure. In some implementations, the processor 1402 and the memory 1404 coupled with the processor 1402 may be configured to perform one or more of the functions described herein (e.g., executing, by the processor 1402, instructions stored in the memory 1404). [0115] For example, the processor 1402 may support wireless communication at the device 1400 in accordance with examples as disclosed herein. The processor 1402 may be configured to operable to support a means for sending a first request to a first applicationlayer function to establish an application-layer multiaccess data session, the multiaccess data session supporting data transmission over a plurality of access paths between the UE and a second application-layer function; receiving a response from the first application-layer function containing first information including information about the second applicationlayer function and a list of steering rules for steering uplink data from the UE across the plurality of access paths of the application-layer multiaccess data session; establishing the plurality of access paths between the UE and the second application-layer function using the first information; identifying a first uplink data flow generated by one or more applications residing on the UE that matches one of the steering rules from the list of steering rules; and transmitting the first uplink data flow to the second application-layer function over one or more of the access paths selected based on the steering rule matching the first uplink data flow. The first and second application-layer functions may reside at a node or nodes of a data network or in the core network of a PLMN. The processor may be further configured to send a session modification request or a session release request to the first application-layer function to modify a multiaccess data session or end a multiaccess data session respectively. All of the access paths may traverse a wireless access path portion. The first request may comprise at least one of: an identity of the multiaccess data session; an identity of a steering unit of the UE and its traffic steering capabilities; and a present location of the UE. The first information may comprise: a Proxy IP address; a Proxy UDP port; a Client IP address; and Measurement Assistance Information. A steering rule may define, for a given traffic type and application source, an access path of the plurality of access paths. The one or each application residing on the UE may be an application client or a vertical layer application, VAL, client.

[0116] The processor 1402 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof). In some implementations, the processor 1402 may be configured to operate a memory array using a memory controller. In some other implementations, a memory controller may be integrated into the processor 1402. The processor 1402 may be configured to execute computer-readable instructions stored in a memory (e.g., the memory 1404) to cause the device 1400 to perform various functions of the present disclosure.

[0117] The memory 1404 may include random access memory (RAM) and read-only memory (ROM). The memory 1404 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1402 cause the device 1400 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. In some implementations, the code may not be directly executable by the processor 1402 but may cause a computer (e.g., when compiled and executed) to perform functions described herein. In some implementations, the memory 1404 may include, among other things, a basic I/O system (BIOS) which may control basic hardware or software operation such as the interaction with peripheral components or devices.

[0118] The I/O controller may manage input and output signals for the device 1400. The I/O controller may also manage peripherals not integrated into the device M02. In some implementations, the I/O controller may represent a physical connection or port to an external peripheral. In some implementations, the I/O controller may utilize an operating system such as iOS®, ANDROID®, MS-WINDOWS®, OS/2®, UNIX®, LINUX®, or another known operating system. In some implementations, the TO controller may be implemented as part of a processor, such as the processor 1402. In some implementations, a user may interact with the device 1400 via the I/O controller or via hardware components controlled by the TO controller.

[0119] In some implementations, the device 1400 may include a single antenna 1410. However, in some other implementations, the device 1400 may have more than one antenna 1410 (i.e., multiple antennas), including multiple antenna panels or antenna arrays, which may be capable of concurrently transmitting or receiving multiple wireless transmissions. The transceiver 1408 may communicate bi-directionally, via the one or more antennas 1410, wired, or wireless links as described herein. For example, the transceiver 1408 may represent a wireless transceiver and may communicate bi-directionally with another wireless transceiver. The transceiver 1408 may also include a modem to modulate the packets, to provide the modulated packets to one or more antennas 1410 for transmission, and to demodulate packets received from the one or more antennas 1410. The transceiver 1408 may include one or more transmit chains, one or more receive chains, or a combination thereof.

[0120] A transmit chain may be configured to generate and transmit signals (e.g., control information, data, packets). The transmit chain may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmit chain may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmit chain may also include one or more antennas 1410 for transmitting the amplified signal into the air or wireless medium.

[0121] A receive chain may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receive chain may include one or more antennas 1410 for receive the signal over the air or wireless medium. The receive chain may include at least one amplifier (e.g., a low-noise amplifier (LN A)) configured to amplify the received signal. The receive chain may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receive chain may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0122] Figure 14 illustrates an example of a processor 1500 that supports a multiaccess data session in accordance with aspects of the present disclosure. The processor 1500 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 1500 may include a controller 1502 configured to perform various operations in accordance with examples as described herein. The processor 1500 may optionally include at least one memory 1504, such as L1/L2/L3 cache. Additionally, or alternatively, the processor 1500 may optionally include one or more arithmetic-logic units (ALUs) 1506. One or more of these components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses).

[0123] The processor 1500 may be a processor chipset and include a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) in accordance with examples as described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to or included in the processor chipset (e.g., the processor 1500) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase change memory (PCM), and others).

[0124] The controller 1502 may be configured to manage and coordinate various operations (e.g., signaling, receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) of the processor 1500 to cause the processor 1500 to support various operations in accordance with examples as described herein. For example, the controller 1502 may operate as a control unit of the processor 1500, generating control signals that manage the operation of various components of the processor 1500. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.

[0125] The controller 1502 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 1504 and determine subsequent instruction(s) to be executed to cause the processor 1500 to support various operations in accordance with examples as described herein. The controller 1502 may be configured to track memory address of instructions associated with the memory 1504. The controller 1502 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 1502 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 1500 to cause the processor 1500 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 1502 may be configured to manage flow of data within the processor 1500. The controller 1502 may be configured to control transfer of data between registers, arithmetic logic units (ALUs), and other functional units of the processor 1500.

[0126] The memory 1504 may include one or more caches (e.g., memory local to or included in the processor 1500 or other memory, such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementation, the memory 1504 may reside within or on a processor chipset (e.g., local to the processor 1500). In some other implementations, the memory 1504 may reside external to the processor chipset (e.g., remote to the processor 1500).

[0127] The memory 1504 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1500, cause the processor 1500 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. The controller 1502 and/or the processor 1500 may be configured to execute computer-readable instructions stored in the memory 1504 to cause the processor 1500 to perform various functions. For example, the processor 1500 and/or the controller 1502 may be coupled with or to the memory 1504, and the processor 1500, the controller 1502, and the memory 1504 may be configured to perform various functions described herein. In some examples, the processor 1500 may include multiple processors and the memory 1504 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiple memories, which may, individually or collectively, be configured to perform various functions herein.

[0128] The one or more ALUs 1506 may be configured to support various operations in accordance with examples as described herein. In some implementation, the one or more ALUs 1506 may reside within or on a processor chipset (e.g., the processor 1500). In some other implementations, the one or more ALUs 1506 may reside external to the processor chipset (e.g., the processor 1500). One or more ALUs 1506 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 1506 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 1506 be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process and manipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 1506 may support logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not- AND (NAND), enabling the one or more ALUs 1506 to handle conditional operations, comparisons, and bitwise operations.

[0129] The processor 1500 may support wireless communication in accordance with examples as disclosed herein. The processor 1500 may be configured to or operable to support a means for means for sending a first request to a first application-layer function to establish an application-layer multiaccess data session, the multiaccess data session supporting data transmission over a plurality of access paths between a UE and a second application-layer function; receiving a response from the first application-layer function containing first information including information about the second application-layer function and a list of steering rules for steering uplink data from the UE across the plurality of access paths of the application-layer multiaccess data session; establishing the plurality of access paths between the UE and the second application-layer function using the first information; identifying a first uplink data flow generated by one or more applications residing on the UE that matches one of the steering rules from the list of steering rules; and transmitting the first uplink data flow to the second application-layer function over one or more of the access paths selected based on the steering rule matching the first uplink data flow. The first and second application-layer functions may reside at a node or nodes of a data network or PLMN core network. All of the access paths may traverse a wireless access path portion. The processor may be further configured to send a session modification request or a session release request to the first application-layer function to modify a multiaccess data session or end a multiaccess data session respectively. The first request may comprise at least one of: an identity of the multiaccess data session; an identity of a steering unit of the UE and its traffic steering capabilities; and a present location of the UE. The first information may comprise: a Proxy IP address; a Proxy UDP port; a Client IP address; and Measurement Assistance Information. A steering rule may define, for a given traffic type and application source, an access path of the plurality of access paths. The one or each application residing on the UE may be an application client or a vertical layer application, VAL, client.

[0130] Figure 15 illustrates an example of a device 1600 that supports a multiaccess data session in accordance with aspects of the present disclosure. The device 1600 may be an example of network node 102 as described herein. The device 1600 may support wireless communication with one or more network entities 102, UEs 104, or any combination thereof. The device 1600 may include components for bi-directional communications including components for transmitting and receiving communications, such as a processor 1602, a memory 1604, a controller 1606, a transceiver 1608, and, optionally, an I/O controller. These components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses).

[0131] The processor 1602, the memory 1604, the controller 1606, the transceiver 1608, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. For example, the processor 1602, the memory 1604, the controller 1606, the transceiver 1608, or various combinations or components thereof may support a method for performing one or more of the operations described herein.

[0132] In some implementations, processor 1602, the memory 1604, the controller 1606, the transceiver 1608, or various combinations or components thereof may be implemented in hardware (e.g., in communications management circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic, discrete hardware components, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure. In some implementations, the processor 1602 and the memory 1604 coupled with the processor 1602 may be configured to perform one or more of the functions described herein (e.g., executing, by the processor 1602, instructions stored in the memory 1604).

[0133] For example, the processor 1602 may support wireless communication at the device 1600 in accordance with examples as disclosed herein. The processor 1602 may be configured to operable to support a means for receiving, at a first application-layer function of the network node, a first request from a User Equipment, UE, to establish an applicationlayer multiaccess data session, the multiaccess data session supporting data transmission over a plurality of access paths between the UE and a second application-layer function; selecting a second application-layer function; sending a session establishment request to the second application-layer function; receiving a session establishment confirmation from the second application-layer function; and sending a response to the UE containing first information including information about the second application-layer function and a list of steering rules for steering uplink data across the plurality of access paths of the application-layer multiaccess data session. The first information may comprises: a Proxy IP address; a Proxy UDP port; a Client IP address; and Measurement Assistance Information. The second application-layer function may reside on the network node. The network node may be a Service Enabler Architecture Layer, SEAL, server.

[0134] In another example, the processor 1602 may support wireless communication at the device 1600 in accordance with examples as disclosed herein. The processor 1602 may be configured to operable to support a means for receiving, from a User Equipment, UE, a first uplink data flow to a second application-layer function of the network node over an access path selected based on a first steering rule sent to the UE from a first application-layer function. The the network node may be a SEAL-Data Delivery server.

[0135] The processor 1602 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof). In some implementations, the processor 1602 may be configured to operate a memory array using a memory controller. In some other implementations, a memory controller may be integrated into the processor 1602. The processor 1602 may be configured to execute computer-readable instructions stored in a memory (e.g., the memory 1604) to cause the device 1600 to perform various functions of the present disclosure.

[0136] The memory 1604 may include random access memory (RAM) and read-only memory (ROM). The memory 1604 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1602 cause the device 1600 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. In some implementations, the code may not be directly executable by the processor 1602 but may cause a computer (e.g., when compiled and executed) to perform functions described herein. In some implementations, the memory 1604 may include, among other things, a basic I/O system (BIOS) which may control basic hardware or software operation such as the interaction with peripheral components or devices.

[0137] The I/O controller may manage input and output signals for the device 1600. The I/O controller may also manage peripherals not integrated into the device M02. In some implementations, the I/O controller may represent a physical connection or port to an external peripheral. In some implementations, the I/O controller may utilize an operating system such as iOS®, ANDROID®, MS-WINDOWS®, OS/2®, UNIX®, LINUX®, or another known operating system. In some implementations, the TO controller may be implemented as part of a processor, such as the processor 1602. In some implementations, a user may interact with the device 1600 via the I/O controller or via hardware components controlled by the TO controller.

[0138] In some implementations, the device 1600 may include a single antenna 1610. However, in some other implementations, the device 1600 may have more than one antenna 1610 (i.e., multiple antennas), including multiple antenna panels or antenna arrays, which may be capable of concurrently transmitting or receiving multiple wireless transmissions. The transceiver 1608 may communicate bi-directionally, via the one or more antennas 1610, wired, or wireless links as described herein. For example, the transceiver 1608 may represent a wireless transceiver and may communicate bi-directionally with another wireless transceiver. The transceiver 1608 may also include a modem to modulate the packets, to provide the modulated packets to one or more antennas 1610 for transmission, and to demodulate packets received from the one or more antennas 1610. The transceiver 1608 may include one or more transmit chains, one or more receive chains, or a combination thereof.

[0139] A transmit chain may be configured to generate and transmit signals (e.g., control information, data, packets). The transmit chain may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmit chain may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmit chain may also include one or more antennas 1610 for transmitting the amplified signal into the air or wireless medium.

[0140] A receive chain may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receive chain may include one or more antennas 1610 for receive the signal over the air or wireless medium. The receive chain may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. The receive chain may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receive chain may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0141] Figure 16 illustrates a flowchart of a method 1700 that supports a multiaccess data session in accordance with aspects of the present disclosure. The operations of the method 1700 may be implemented by a device or its components as described herein. For example, the operations of the method 1700 may be performed by a UE 104 as described herein. In some implementations, the device may execute a set of instructions to control the function elements of the device to perform the described functions. Additionally, or alternatively, the device may perform aspects of the described functions using special-purpose hardware.

[0142] At step 1702, the method may include sending a first request to a first applicationlayer function to establish an application-layer multi-access data session, the multi-access data session supporting data transmission over a plurality of access paths between a UE and a second application-layer function. The operations of 1702 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1702 may be performed by a device as described with reference to Figure 1.

[0143] At step 1704, the method may include receive a response from the first application-layer function containing first information including information about the second application-layer function and a list of steering rules for steering uplink data from the UE across the plurality of access paths of the application-layer multi-access data session. The operations of 1704 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1704 may be performed by a device as described with reference to Figure 1.

[0144] At step 1705, the method may include establishing the plurality of access paths between the UE and the second application-layer function using the first information. The operations of 1705 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1705 may be performed by a device as described with reference to Figure 1.

[0145] At step 1706, the method may include identifying a first uplink data flow generated by one or more applications residing on the UE that matches one of the steering rules from the list of steering rules. The operations of 1706 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1706 may be performed by a device as described with reference to Figure 1.

[0146] At step 1708, the method may include transmitting the first uplink data flow to the second application-layer function over one or more of the access paths selected based on the steering rule matching the first uplink data flow. The operations of 1708 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1708 may be performed by a device as described with reference to Figure 1.

[0147] Figure 17 illustrates a flowchart of a method 1800 that supports a multiaccess data session in accordance with aspects of the present disclosure. The operations of the method 1800 may be implemented by a device or its components as described herein. For example, the operations of the method 1800 may be performed by a network node 102 as described herein. In some implementations, the device may execute a set of instructions to control the function elements of the device to perform the described functions. Additionally, or alternatively, the device may perform aspects of the described functions using specialpurpose hardware.

[0148] At 1802, the method may include receiving, at a first application-layer function of the network node, a first request from a User Equipment, UE, to establish an applicationlayer multiaccess data session, the multiaccess data session supporting data transmission over a plurality of access paths between the UE and a second application-layer function. The operations of 1802 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1802 may be performed by a device as described with reference to Figure 1.

[0149] At 1804, the method may include selecting a second application-layer function. The operations of 1804 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1804 may be performed by a device as described with reference to Figure 1.

[0150] At 1806, the method may include sending a session establishment request to the second application-layer function. The operations of 1806 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1806 may be performed by a device as described with reference to Figure 1.

[0151] At 1808, the method may include receiving a session establishment confirmation from the second application-layer function. The operations of 1808 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1808 may be performed by a device as described with reference to Figure 1.

[0152] At 1810, the method may include sending a response to the UE containing first information including information about the second application-layer function and a list of steering rules for steering uplink data across the plurality of access paths of the applicationlayer multiaccess data session. The operations of 1810 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1810 may be performed by a device as described with reference to Figure 1.

[0153] Figure 18 illustrates a flowchart of a method 1900 that supports a multiaccess data session in accordance with aspects of the present disclosure. The operations of the method 1900 may be implemented by a device or its components as described herein. For example, the operations of the method 1900 may be performed by a network node 102 as described herein. In some implementations, the device may execute a set of instructions to control the function elements of the device to perform the described functions. Additionally, or alternatively, the device may perform aspects of the described functions using specialpurpose hardware.

[0154] At 1902, the method may include receiving, from a User Equipment, UE, a first uplink data flow to a second application-layer function of the network node over an access path selected based on a first steering rule sent to the UE from a first application-layer function. The operations of 1902 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1902 may be performed by a device as described with reference to Figure 1.

[0155] It should be noted that the methods described herein describes possible implementations, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible. Further, aspects from two or more of the methods may be combined.

[0156] The various illustrative blocks and components described in connection with the disclosure herein may be implemented or performed with a general-purpose processor, a DSP, an ASIC, a CPU, an FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0157] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Other examples and implementations are within the scope of the disclosure and appended claims. For example, due to the nature of software, functions described herein may be implemented using software executed by a processor, hardware, firmware, hardwiring, or combinations of any of these. Features implementing functions may also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations.

[0158] Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer. By way of example, non-transitory computer-readable media may include RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory, compact disk (CD) ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that may be used to carry or store desired program code means in the form of instructions or data structures and that may be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor.

[0159] As used herein, including in the claims, an article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of’ or “one or more of’ or “one or both of’) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an example step that is described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. Further, as used herein, including in the claims, a “set” may include one or more elements.

[0160] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

Claims

What is claimed is:

1. A User Equipment, UE, for wireless communication and comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: send a first request to a first application-layer function to establish an applicationlayer multiaccess data session, the multiaccess data session supporting data transmission over a plurality of access paths between the UE and a second application-layer function; receive a response from the first application-layer function containing first information including information about the second application-layer function, and a list of steering rules for steering uplink data from the UE across the plurality of access paths of the application-layer multiaccess data session; establish the plurality of access paths between the UE and the second applicationlayer function using the first information; identify a first uplink data flow generated by one or more applications residing on the UE that matches one of the steering rules from the list of steering rules; and transmit the first uplink data flow to the second application-layer function over one or more of the access paths selected based on the steering rule matching the first uplink data flow.

2. The UE of claim 1 , wherein the first and second application-layer functions reside at a node or nodes of a data network or in the core network of a PLMN.

3. The UE of any preceding claim, wherein the UE is further configured to send a session modification request or a session release request to the first application-layer function to modify a multiaccess data session or end a multiaccess data session respectively.

4. The UE of any preceding claim, wherein the first request comprises at least one of: an identity of the multiaccess data session; an identity of a steering function of the UE and its traffic steering capabilities; and a present location of the UE.

5. The UE of any preceding claim, wherein the first information comprises at least one of: a Proxy IP address; a Proxy UDP port; a Client IP address; and

Measurement Assistance Information.

6. The UE of any preceding claim, wherein a steering rule defines, for a given traffic type and application source, an access path of the plurality of access paths.

7. The UE of any preceding claim, wherein the application residing on the UE is an application client or a vertical layer application, VAL, client.

8. A processor for wireless communication, comprising at least one controller coupled with at least one memory and configured to cause the processor to: send a first request to a first application-layer function to establish an applicationlayer multiaccess data session, the multiaccess data session supporting data transmission over a plurality of access paths between a UE and a second application-layer function; receive a response from the first application-layer function containing first information including information about the second application-layer function, and a list of steering rules for steering uplink data from the UE across the plurality of access paths of the application-layer multiaccess data session; establish the plurality of access paths between the UE and the second applicationlayer function using the first information; identify a first uplink data flow generated by one or more applications residing on the UE that matches one of the steering rules from the list of steering rules; and transmit the first uplink data flow to the second application-layer function over one or more of the access paths selected based on the steering rule matching the first uplink data flow.

9. The processor of claim 8, wherein the first and second application-layer functions reside at a node or nodes of a data network or in the core network of a PLMN.

10. The processor of any of claims 8 or 9, wherein the processor is further configured to send a session modification request or a session release request to the first applicationlayer function to modify a multiaccess data session or end a multiaccess data session respectively.

11. The processor of any of claims 8 to 10, wherein the first request comprises at least one of: an identity of the multiaccess data session; an identity of a steering unit of the UE and its traffic steering capabilities; and a present location of the UE.

12. The processor of any of claims 8 to 11, wherein the first information comprises at least one of: a Proxy IP address; a Proxy UDP port; a Client IP address; and

Measurement Assistance Information.

13. The processor of any of claims 8 to 12, wherein a steering rule defines, for a given traffic type and application source, an access path of the plurality of access paths.

14. The processor of any of claims 8 to 13, wherein the application residing on the UE is an application client or a vertical layer application, VAL, client.

15. A network node configured to: receive, at a first application-layer function of the network node, a first request from a User Equipment, UE, to establish an application-layer multiaccess data session, the multiaccess data session supporting data transmission over a plurality of access paths between the UE and a second application-layer function; select a second application-layer function; send a session establishment request to the second application-layer function; receive a session establishment confirmation from the second application-layer function; and send a response to the UE containing first information including information about the second application-layer function, and a list of steering rules for steering uplink data across the plurality of access paths of the application-layer multiaccess data session.

16. The network node of claim 15, wherein the first information comprises at least one of: a Proxy IP address; a Proxy UDP port; a Client IP address; and

Measurement Assistance Information.

17. The network node of claim 15 or claim 16, wherein the second application-layer function resides on the network node.

18. The network node according to any one of claims 15 to 17, wherein the network node is a Service Enabler Architecture Layer, SEAL, server.

19. A network node configured to: receive, from a User Equipment, UE, a first uplink data flow to a second application-layer function of the network node over an access path selected based on a first steering rule sent to the UE from a first application-layer function.

20. A network node of claim 19, wherein the network node is a SEAL-Data Delivery server.