Methods and devices for handling non-3GPP access with QUIC aware proxy

Abstract

Methods and devices in a wireless network enable maintaining a user equipment's (UE's) non-3GPP access to services provided by a 3GPP communication system, after a 3GPP access to the network core of the 3GPP communication system is no longer available. A UE method (900) includes receiving (910), from a network entity (NE) via the 3GPP access, a first indication of successful establishment of a multi-access protocol data unit session enabling multipath QUIC, sending (914) to the NE via the non-3GPP access, a request to establish a UDP tunnel on one of the multipath QUIC, and then exchanging (924) the control plane information related to the non-3GPP access via the UDP tunnel with the NE.

Description

METHODS AND DEVICES FOR HANDLING NON-3GPP ACCESS WITH QUIC AWARE PROXYFIELD OF THE DISCLOSURE

[0001] This document generally describes methods and devices operating in wireless communication systems such as (but not limited to) the ones described in Third Generation Partnership Project (3GPP) technical specifications (e.g., Fifth generation (5G) communication systems). More specifically, the methods and devices maintain user equipment’s (UE’s) non-3GPP access to services provided through such a 3GPP communication system, after a 3GPP access is no longer available.BACKGROUND

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

[0003] In the context of 3GPP wireless communication systems, a “non-3GPP access” refers to a user device connecting to a core network using a technology that is not defined in the 3GPP technical specification, for example, Wi-Fi, certain satellite communication, or a fixed-line network. An Access Traffic Steering, Switching, and Splitting (ATSSS) mechanism allows a core network of the 3GPP wireless communication system to control the manner in which traffic is sent across plural 3GPP and non-3GPP accesses. The figures in this document illustrate 5G communication systems but similar techniques are pertinent for other 3GPP wireless communication systems such as 6G, Long Term Evolution (LTE), etc.

[0004] The conventional ATSSS architectures supporting non-3GPP access using untrusted or trusted non-3GPP access (illustrated in Figs. 1 and 2, respectively)require the deployment of either a non-3GPP Interworking Function (N3IWF) 105 or a Trusted non-3GPP Gateway Function (TNGF) 109 for the UE 102 to receive data and services from a data network 1 19. In Figs. 1 and 2, the UE 102 accesses the 5G core network functions (e.g., the Access and Mobility Management Function (AMF) 112, the Session Management Function (SMF) 114, and the User Plane Function (UPF) 1 16) via the 3GPP access 103. Additionally, in Fig. 1 , the UE 102 accesses the 5G core network functions via the untrusted non-3GPP 107 and the N3IWF 105. In Fig. 2, the UE 102 accesses the 5G core network functions via the trusted non-3GPP access network (TNAN) that includes a trusted non-3GPP access point 108 and the TNGF 109.

[0005] The UE 102 in Figs. 1 and 2 includes a multipath transmission control protocol (MPTCP) functionality 102a, a multipath QUIC functionality (MPQUIC) 102b, an ATSSS lower layer (ATSSS-LL) functionality 102c, and a performance measurement function (PMF) 102d. Here, “QUIC” stands for Quick UDP Internet Connections and “UDP” is the User Datagram Protocol. The multipath TCP, which is an extension of the original TCP protocol, enables a device to utilize multiple network paths simultaneously within a single connection to maximize throughput and increase redundancy. The multipath QUIC similarly refers to an extension of the QUIC protocol that allows devices (e.g., the UE 102) to send and receive data over multiple network paths simultaneously.

[0006] The TCP relies on a connection-oriented approach with a three-way handshake to establish connections, while QUIC prioritizes faster connection establishment by utilizing UDP and a “zero-round-trip-time” (0-RTT) handshake, making it significantly quicker for initial data transfer, especially in scenarios where low latency is crucial. While TCP provides the basis for secure communication with the use of additional protocols like Transport Layer Security (TLS), QUIC includes encryption and authentication as inherent components, providing secure communication by default.

[0007] The ATSSS-LL supports 3GPP and non-3GPP user plane traffic between the UE 102 UE and the UPF 116 regardless of the specific protocol. In the multipathcontext, the ATSSS rules enable selecting a path (“Steering”), selecting a different path than the current path (“Switching”), and using multiple paths simultaneously (“Splitting”) for the user plane traffic. The PMF encapsulates a UE or NE ability to measure the performance of a network connection, which is then typically used to decide how to distribute traffic between different access points (3GPP or non-3GPP), based on latency and throughput.

[0008] Complementary to the UE 102, the UPF 116 includes MPTCP Proxy functionality 116a, MPQUIC Proxy functionality 116b, ATSSS-LL functionality 116c, and a PMF 116d. Various 3GPP reference points (e.g., N1 , N6, N11 ) as well as reference points related to the non-3GPP access (e.g., Y2, Y1 , etc.) are described in detail in the current 3GPP technical specifications.

[0009] A recent alternative architecture illustrated in Fig. 3 provides system-level enhancements for ATSSS, no longer requiring the non-3GPP interworking / gateway functions (i.e., N3IWF or TNGF) for the non-3GPP access 308 (e.g., an WiFi access point such as hardware. This alternative architecture simplifies the network operation by eliminating the non-access stratum (NAS) signaling connection (i.e., control plane message exchange via an N1 reference point) over the non-3GPP access. Here, both 3GPP access and non-3GPP access have a common NAS signaling connection (e.g., an N4 reference point) over 3GPP access. The UE 102 in Fig. 3 establishes a multiple access (MA) protocol data unit (PDU) session over 3GPP access before adding the non-3GPP access. This arrangement supports multipath QUIC (MPQUIC) connectivity using the user plane of the 3GPP access, the non-3GPP access, or both between the UE 102 and the UPF 116. The UE 102 operates as an MPQUIC client and PDU Session Anchor (PSA) UPF 116 operates as an MPQUIC proxy.

[0010] However, the existing architectures are unable to maintain the MA PDU Session via non-3GPP access when the UE loses the 3GPP access (i.e., the UE is deregistered from the UE access). For example, the arrangement in Fig. 3 can maintain the MA PDU Session via the non-3GPP access without the 3GPP access only for ashort (limited) time, because the control information for the non-3GPP access is exchanged via the 3GPP access.SUMMARY

[0011] Methods and devices according to various embodiments support non-3GPP access without NAS (i.e. , control information exchanged via 3GPP) by using a tunnel setup after establishing a MA PDU session enabling MPQUIC. The tunnel having as end points the UE and the UPF enables exchanging the non-3GPP-related control information over the non-3GPP access.

[0012] In one embodiment, a UE receives a first indication of successful establishment of an MA PDU session over its 3GPP access and non-3GPP access from a network entity (NE) that executes at least one core network function. The MA PDU session enables MPQUIC. The UE then sends, to the NE, a request to establish a user datagram protocol (UDP) tunnel on a QUIC path, for exchanging control plane information related to traffic over the non-3GPP access. The UE then exchanges the control plane information related to the non-3GPP access via the UDP tunnel with the NE. The request may be a Hypertext Transfer Protocol, HTTP, datagram, and may include a context identifier and / or a “connect-udp” upgrade token. The exchanging of the control plane information related to the non-3GPP access via the UDP tunnel may continue without a connection of the UE over the 3GPP access.

[0013] According to another embodiment, an NE, which executes at least one core network function, transmits, to a UE, via a 3GPP access, a first indication of successful establishment of an MA PDU session enabling multipath QUIC. The NE then receives from the UE via a non-3GPP access, a request to establish a UDP tunnel on one of the multipath QUIC, for exchanging control plane information related to traffic over the non- 3GPP access. Further, the NE exchanges the control plane information related to the non-3GPP access via the UDP tunnel with the UE.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0015] Fig. 1 illustrates a conventional ATSSS architectures supporting untrusted non-3GPP access using an N3IWF.

[0016] Fig. 2 illustrates a conventional ATSSS architectures supporting trusted non-3GPP access using a TNGF.

[0017] Fig. 3 illustrates an ATSSS architecture supporting non-3GPP access without NAS over the non-3GPP access.

[0018] Fig. 4 illustrates a wireless communication system including a UE and a network entity (NE) operating according to methods for handling non-3GPP access with QUIC-aware proxy according to various embodiments.

[0019] Fig. 5 illustrates a user plane protocol stack for Nx interface.

[0020] Fig. 6 illustrates a MA PDU session with 3GPP access and non-3GPP access.

[0021] Fig. 7 illustrates an HTTP datagram for use over non-3GPP access to exchange control plane information with the 5G core network.

[0022] Fig. 8 is a signal diagram illustrating messages and procedures for establishing a UDP tunnel between the UE as HTTP client and an NE hosting the UPF as HTTP server according to an embodiment.

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

[0024] Fig. 10 is a flowchart of a NE method according to an embodiment.DETAILED DESCRIPTION

[0025] Methods and devices described in this section embody techniques that enable the UE to maintain a non-3GPP access to 3GPP wireless communication services after the UE’s 3GPP access is lost. The embodiment descriptions in this section refer to the accompanying drawings. The same reference numbers in different drawingsidentify the same or similar elements. The detailed descriptions do not preclude other embodiments within the scope of the appended claims. The embodiments are not limited to the described configuration but may be extended to other arrangements.

[0026] Before describing various embodiments, Fig. 4 illustrates a wireless communication system 100 that includes a UE 102, a base station (BS) 104, a BS 106, and a core network (CN) 110. The BSs 104 and 106 are connected to the CN 110 via a 3GPP access (i.e. , radio access network) 103. The CN 110 illustrated in Fig. 4 is a 5G network core, but it may also be or include other network core(s) such as a sixth generation (6G) network core.

[0027] For the sake of illustration not intending to be limiting, the BS 104 covers a terrestrial cell 124, and the BS 106 covers a non-terrestrial cell 126. If the BS 104 is a gNB, the cell 124 is an NR cell. If the BS 104 is an ng-eNB or eNB, the cell 124 is an evolved universal terrestrial radio access (E-UTRA) cell. Similarly, if the BS 106 is a gNB, the cell 126 is an NR cell, and if the BS 106 is an ng-eNB or eNB, the cell 126 is an E-UTRA cell. In general, a RAN such as the RAN 103 may include any number of BSs, and each of the BSs may cover one, two, three, or any other suitable number of terrestrial or non-terrestrial cells. Each of the BSs 104 and 106 connect to the CN 110 via an interface (e.g., a next generation (NG) interface). The BSs 104 and 106 may be interconnected via an interface (e.g., an Xn interface). The cells 124 and 126 partially overlap, so that the UE 102 can select, reselect, or hand over from one of the cells 124 and 126 to the other.

[0028] The CN 110 typically includes at least one instance of the Access and Mobility Management Function (AMF) 112, a Session Management Function (SMF) 114, and a User Plane Function (UPF) 116. The AMF 112 is configured to manage authentication, registration, paging, and other related functions, the SMF 114 is configured to manage PDU sessions, and the UPF 116 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc. The CN 110 can connect to any suitable number of BSs supporting NR cells. The CN function run on hardware of at least one network entity (NE) 140. The NE 140 is typically equipped with a processor 142 (e.g.,one or more central processing units (CPUs) and / or special-purpose processing units (SPUs)), a transceiver 144, a non-transitory computer-readable memory 146, and non- 3GPP communication hardware 148. The processor 132 processes data that the NE 140 transmits and / or data that the NE 140 receives. The transceiver 144 (which is a combination of a transmitter and a receiver that may be separate components) is configured to transmit and / or receive the data. The memory 146 stores instructions (e.g., executable codes) for the processor to perform various methods described hereinafter, in collaboration with the transceiver and the non-3GPP communication hardware. The non-3GPP communication hardware 148 enables the NE 140 to communicate via non-3GPP access 308 with the UE 102 using a communication technique (e.g., Wi-Fi, via cable, etc.) other than the radio access technology described in the 3GPP technical specifications. The UE 102 has similar components, that is: a processor 132, a transceiver 134, a memory 136, and non-3GPP communication hardware 138.

[0029] Fig. 5 illustrates a user plane protocol stack for Nx interface as illustrated in Fig. 3. The lowest level of this protocol stack is the non-3GPP layer implemented in both UE 102 and the PSA UPF 116 hosted by an NE (such as NE 140 in Fig. 4). The Internet Protocol (IP) layer implemented in the UE 102 and the UPF 116 across the non-3GPP access 308 routes data packets using the Internet Protocol. Between the UE 102 and the UPF 116, outside the non-3GPP access, the UDP layer implements the user datagram protocol, the MPQUIC layer enables multiple QUIC paths for communications, and the HTTP / 3 layer implements the latest generation of Hypertext Transport Protocol established over QUIC. The PDU layer is the layer of the protocol stack where protocol data units (PDUs) are encapsulated (with information like addressing and control details) and transmitted. The application layer is established directly between the UE 102 and the application server (e.g., the data network 119). The N6 protocol layer, which is an interface between the UPF 116 and the data network 119, operates as a connection point where user data from the UE is exchanged with the outside external internet (i.e., N6 is considered the demarcation point for traffic between the 5G network and the external internet).

[0030] Fig. 6 illustrates an MA PDU session with an MPQIIIC 621 including a first path 623 employing the 3GPP access 103 (and, optionally, another UPF) and a second path 625 employing the non-3GPP access 308.

[0031] Fig. 7 is a block diagram illustrating a UDP datagram 770 that uses QUIC aware UDP proxying (MPQUIC functionalities) of the UE and UPF to encapsulate a QUIC packet 772. The QUIC packet 772 has an HTTP datagram format 774 including a Quarter Stream ID 776, a Context identifier (ID) 777, and a payload 778. When the context ID is a specific Context ID, the UDP datagram 770 that encapsulates the HTTP datagram 774 carries the control plane information. In other words, the specific context ID indicates that the packet (i.e., the UDP datagram 770) transported via an UDP tunnel on a path of the MPQUIC is used for communicating the control plane information.

[0032] The control information may be PDU session handling information including an access token for authorization to use an MA PDU Session over non-3GPP access, retention timer over non-3GPP access when losing 3GPP access, required information for PDU Session establishment / modification request as indicated in the 3GPP technical specifications, or other control information. Typically, an HTTP datagram includes at least one of the following information: (i) authentication / authorization parameters (e.g., a public key as identification for non-3GPP access for authentication, an access token for authorization, a periodic authentication / authorization time period) or (ii) information elements required for PDU Session Establishment / Modification (e.g., a PDU Session ID, MA session information as specified in the 3GPP technical specifications).

[0033] Fig. 8 is a signal diagram illustrating messages and procedures for establishing a UDP tunnel between the UE as HTTP client and an NE hosting the UPF as UDP proxy and HTTP server according to an embodiment. Note that the actors sending or receiving messages and involved in the procedures are the UE 102, the non-3GPP access 308, the 3GPP access 103, the AMF 112, the SMF 114, the UPF 116, the Policy Control Function (PCF) 120, and the Unified Data Management (UDM) 122. The PCF and the UDM are 5G core network functions described in the 3GPP technical specifications. The 5G core network functions are hosted by (i.e., executed on) one or more NEs similarto the NE 140 illustrated and discussed relative to Fig. 4. In this signal diagram, the time flows from the top to the bottom, with messages and procedures illustrated higher occurring before messages and procedures illustrated lower.

[0034] The UE 102 and the UPF 116 have dual roles. The UE 102 is (A) a UDP client that sends UDP datagrams to the UPF 116 acting as a UDP proxy and (B) an HTTP client that establishes HTTP connections with the UPF 116 acting as an HTTP server.The UPF 116 is (A) a UDP proxy that intercepts and forwards UDP packets between the UE 102 and the destination server (e.g., data network 119) and (B) an HTTP server that handles HTTP requests from the UE 102. The communication flow would work as follows: (1 ) the UE 102 initiates a QUIC connection with the UPF116 , which acts as an HTTP server; (2) over this QUIC connection, the UE 102 sends a CONNECT-UDP request to the UPF 116 to establish a UDP tunnel; (3) the UPF 116, acting as a UDP proxy, sets up the requested UDP tunnel; and (4) the UE 102 is then able to send UDP datagrams through this tunnel, the UPF then forwarding the UDP datagrams to the intended destination. Return traffic follows the reverse path: (1 ) the UPF 116 receives UDP packets from the destination, encapsulates them in the QUIC connection, and forwards the encapsulated UDP packets to the UE 102. This setup allows the UE 102 to leverage the UPF 116's proxy capabilities for UDP traffic while maintaining a secure and multiplexed QUIC connection for control signaling and data transfer. The UPF 116's dual role enables efficient handling of both UDP tunneling and HTTP-based control communications within the same connection.

[0035] As illustrated in Fig. 8, the UE 102, the 3GPP access 103, the AMF 112, the SMF 114, the UPF 116, the PCF 120, and the UDM 122 perform 802 a UE-initiated PDU establishment procedure as described in the 3GPP technical specifications (e.g., 3GPP Technical Specification 23.502). During the procedure, the UE 102 acquires a target UDP proxy address, and UDP proxy port information related to the UPF 116 that terminates the MA PDU Session. The UDP proxy port information may be an Internet Protocol (IP) 5-tuple including: source IP address, source port, destination IP address, destination port and transport protocol. The IP 5-tuple uniquely identifies UDP / TCPsession. The UE 102 may also receive an indication from the SMF prompting the UE to establish a UDP tunnel to exchange control plane information related to the non- 3GPP access.

[0036] The UE 102 then establishes 804 one or multiple QUIC connections for the MA PDU session and the UPF 116. The multipath QUIC connection is initially operating via the 3GPP access (as suggested by the small circle) but later (at 810) adds QUIC path(s) over the non-3GPP access. A specific QUIC connection can be established or used among the multiple established QUIC connections later for establishing an UDP tunnel for exchanging control information and may be handled with high priority to ensure the timely transfer of control plane information.

[0037] The UE 102 then obtains 806 local IP information (e.g., UE’s IP address assigned by non-3GPP access) after connecting to non-3GPP access 308 and adds 810 one or more QUIC path(s) over the non-3GPP access 308. The UE and the UPF may then route user plane traffic related to the MA PDU session over non-3GPP access using these QUIC path(s) over the non-3GPP access 308. Thus, the UE 102 has 812 a functional QUIC connection with multiple QUIC paths over the 3GPP access 103 and / or the non-3GPP access 308 (as suggested by the dashed circles).

[0038] The UE 102 then initiates 814 establishing the UDP tunnel over a specific QUIC connection for exchanging the non-3GPP control information. The UE initiates this procedure by sending a http request to the UDP proxy at the UPF to establish a UDP tunnel for UDP proxying in HTTP datagrams. The request includes the 'connect-udp' upgrade token as specified in RFC 9298. The UPF acting as UDP proxy can determine whether to enable the UDP tunnel requested by the UE based on N4 rules configured by the SMF or based on predefined configuration by the operator’s policy. During 802 PDU session establishment / modification request procedure over 3GPP access, the N4 rules configured by the SMF 114 include one or more report filters for the UPF to report to the SMF 116 when receiving an UDP datagram like the one illustrated in Fig. 7 (with the specific context ID indicated in the http datagram payload) via the UDP tunnel. The UPF 116 then sends the N4 session report 816 including indication of UDP tunnelestablishment for exchanging control plane information via UPF to the SMF 114. Then the SMF 114 stores the indication and replies 818, to the UPF 116, with an N4 session report acknowledgement. The SMF then starts to communicate with the UPF for exchanging control plane information (as in 825 and 826) via the UPF which manages the UDP tunnel with the UE.

[0039] In another embodiment of UDP tunnel establishment, the UE 102 sends an http request with connect-udp upgrade token and information of Context ID(s) to be used in UDP tunnel. The UPF 116 then sends the N4 session report including information of Context ID(s) to be used in the UDP tunnel to the SMF 114. The SMF 114 then determines whether to enable the UDP tunnel requested by the UE and replies 818, to the UPF 116, with an N4 session report acknowledgement. Assuming that the N4 session report acknowledgement indicated that the UDP tunnel requested by the UE was supported for enabling, the SMF 114 also configures 820 one or more report filters for the UPF to report to the SMF 116 when receiving an UDP datagram like the one illustrated in Fig. 7 (with the specific context ID indicated in the http datagram payload) via the UDP tunnel.

[0040] After the tunnel is established, the UE can send HTTP datagrams with different Context IDs, allowing the UE and network to multiplex various streams, including control plane information, over the same UDP tunnel. One or more Context IDs may be further specified and used to differentiate different control plane information and purpose (e.g. for authentication / authorization, PDU Session management over non- 3GPP access, etc.). The UDP proxy of the UPF 116 then sends 816, to the SMF 114, an N4 session report (i.e. , a report sent over the N4 interface between the UPF and the SMF). The N4 session report includes information included in http datagram payload which contains context ID and control plane information of the non-3GPP access corresponding to the context ID). The SMF can then determine how to handle the UDP datagram (e.g. at SMF or forward it to the corresponding network function) based on the context ID. In another embodiment, the UDP proxy of the UPF 116 is configured with amultiple access rule (MAR) used for distributing downlink traffic between 3GPP access and non-3GPP access.

[0041] The UPF 116 then sends 822, to the UE 102, an HTTP response to the HTTP request indicating successful UDP tunnel setup. The UE 102 then starts 824 exchanging http datagrams using the UDP tunnel over the non-3GPP access 308 (as suggested by the small circle) with a specific Context ID(s) indicating control plane information related to the non-3GPP access, with the UDP proxy at the UPF 116. The UE 102 also exchanges 827 user plane data traffic over 3GPP access and non-3GPP access (as suggested by the circles therein) on the QUIC connections with the UPF 116.

[0042] In one scenario, the UPF 116 receiving an http datagram reports with Context ID and the corresponding control plane information included in the http datagram payload for authorization of the non-3GPP access to the SMF 114. The SMF 114 then triggers an authorization procedure with an Authentication, Authorization, and Accounting (AAA) server or with the UDM 122 or with Authentication Server Function AUSF.

[0043] In another scenario, the UPF 116 receiving an http datagram reports with Context ID and the corresponding control plane information included in the http datagram payload for PDU Session handling to the SMF 114. The SMF 114 then determines to handle the PDU Session accordingly and may interact with other network functions, e.g.:(i) the PCF 120 for session management (SM) Policy Session Establishment / Modification,(ii) the UDM 122 for subscription request / update, (iii) the AMF 112 for triggering N1 / N2 communication for access and mobility management to obtain UE's reachability over 3GPP access.

[0044] Fig. 9 is a flowchart of a UE method 900 according to an embodiment. The method 900 includes receiving 910 a PDU Session Establishment Accept or PDU Session Modification Command message over 3GPP access with the UDP proxy address and port information of an UPF that terminates the MA PDU Session, and an indication for establishing UDP tunnel for exchanging control plane information. The method further includes sending 914 an HTTP request with the “connect-udp” upgrade token to the UDP proxy at the UPF for establishing UDP tunnel for UDP proxying in httpdatagram, as specified in IETF RFC 9298. Once established, this UDP tunnel is used to transport http datagrams. The http datagram payload includes a specific Context ID which can be used to identify different types of control plane information. This is for enabling the capability to exchange control plane information included in dedicated HTTP datagrams. The method 900 may include (i.e. , optionally) receiving 922 an HTTP response indicating a successful UDP tunnel set-up. Alternatively, the success of setting up the UDP tunnel is implicit when a failure indication is not received within a predefined time interval after transmitting the request. The method 900 then includes exchanging control plane information related to the non-3GPP access with UDP proxy of the UPF using an HTTP datagram with the specific Context ID(s).

[0045] Fig. 10 is a flowchart of a NE method 1000 according to an embodiment. The method 1000 includes transmitting 1010 a PDU Session Establishment Accept or PDU Session Modification Command message over 3GPP access with the UDP proxy address and port information of an UPF that terminates the MA PDU Session, and an indication for establishing a UDP tunnel for exchanging control plane information of the non-3GPP access. The method then includes receiving 1014 an HTTP request with the “connect-udp” upgrade token to the UDP proxy at the UPF for establishing UDP tunnel for UDP proxying in http datagram, as specified in IETF RFC 9298. Once established, this UDP tunnel is used to transport http datagrams. The http datagram payload includes a specific Context ID which can be used to identify different types of control plane information associated to the non-3GPP access. This is for enabling the capability to exchange control plane information in dedicated HTTP datagrams. The method 1000 may include transmitting 1022 an HTTP response indicating a successful UDP tunnel set-up. The method 1000 also includes exchanging control plane information related to the non-3GPP access with the UE using an HTTP datagram with the specific Context ID(s).

[0046] The embodiment descriptions in this section refer to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The detailed descriptions do not preclude other embodiments within the scopeof the appended claims. The embodiments are not limited to the configurations described above but may be extended to other arrangements.

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

[0048] Numerical adjectives “first”, “second”, and “third” do not imply any order (are not ordinals) but are markers to distinguish separate instances of similar elements.References to the singular (e.g., “a” or “an”, “the”) should include the plural unless clearly indicated otherwise.

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

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

Claims

WHAT IS CLAIMED IS:1 . A wireless communication method (900) performed by a user equipment, UE, (102) able to communicate using a 3GPP access and using a non-3GPP access, the method comprising: receiving (910), from a network entity, NE, (140) via the 3GPP access, a first indication of successful establishment of a multi-access, MA, protocol data unit, PDU, session enabling multipath Quick User Data Protocol, UDP, Internet Connections, QUIC; sending (914), to the NE via the non-3GPP access, a first request to establish a UDP tunnel on a new QUIC connection or one of the multipath QUIC connection, for exchanging control plane information related to traffic over the non-3GPP access; and exchanging (924) the control plane information related to the non-3GPP access in http datagrams via the UDP tunnel with the NE.

2. The wireless communication method of claim 1 , wherein the first request is a first Hypertext Transfer Protocol, HTTP, datagram and includes a “connect-udp” upgrade token for establishing a UDP tunnel between the UE and an NE terminating the MA PDU Session.

3. The wireless communication method of claim 1 or 2, wherein the http datagram over the established UDP tunnel includes a context identifier, and the control plane information, is associated with the context identifier.

4. The wireless communication method of any of claims 1 to 3, wherein the receiving includes receiving a UDP proxy address and port number associated with a user plane function, UPF, executed by the NE, and receiving a second indication for establishing the UDP tunnel between a UE and the UDP proxy at the UPF.

5. The wireless communication method of any of claims 1 to 4, further comprising: exchanging user plane data over the non-3GPP access using an MPQIIIC path other than the UDP tunnel for exchanging the control plane information.

6. The wireless communication method of any of claims 1 to 5, wherein the exchanging the control plane information related to the non-3GPP access via the UDP tunnel continues without a UE to NE connection over the 3GPP access.

7. A wireless communication method (1000) performed by a network entity, NE, (140) executing a network core function, the method comprising: transmitting (1010), to a user equipment, UE, (102) via a 3GPP access, a first indication of successful establishment of a multi-access, MA, protocol data unit, PDU, session enabling multipath Quick User Data Protocol, UDP, Internet Connections, QUIC; receiving (1014) a request to use a UDP tunnel or to establish the UDP tunnel on one of the multipath QUIC, for exchanging control plane information related to traffic over a non-3GPP access with the UE; and exchanging (1024) the control plane information related to the non-3GPP access via the UDP tunnel with the UE.

8. The wireless communication method of claim 7, wherein the network core function executed by the NE is a user plane function, UPF, and the request is a first Hypertext Transfer Protocol, HTTP, request including a “connect-udp” upgrade token to establish the UDP tunnel.

9. The wireless communication method of any of claim 7 or 8, further comprising:receiving, from the UE via the UDP tunnel a second HTTP datagram that includes a context identifier and the control plane information associated with the context identifier.

10. The wireless communication method of claim 9, wherein the NE operating as a UDP proxy is configured with a multiple access rule used for distributing downlink traffic between 3GPP access and non-3GPP access.11 . The wireless communication method of claim 8, further comprising: sending, to a session management function, SMF, a session report with information included in a payload of the first HTTP datagram including a context identifier; and in response to the session report, receiving an indication that the SMF enables the UDP tunnel.

12. The wireless communication method of claim 11 , further comprising: receiving, from the SMF, a filter for triggering the UPF to report, to the SMF, when the context identifier is included in a payload of any HTTP datagram received via the UDP tunnel.

13. The wireless communication method of any of claims 7 to 12, further comprising: exchanging user plane data over the non-3GPP access using an MPQUIC path other than the UDP tunnel for exchanging the control plane information.

14. The wireless communication method of any claims 7 to 13, wherein the exchanging the control plane information related to the non-3GPP access via the UDP tunnel continues without a connection of the UE over the 3GPP access.

15. A wireless communication device (102, 140) comprising a processor (132, 142), a transceiver (134, 144), non-3GPP communication hardware (138,148), and computer readable recording medium (136, 146) storing executable codes that, when executed by the processor in collaboration with the transceiver, make the wireless communication device perform any of the methods recited in claims 1 to 14.

Images