Patent Publication Number: US-11652719-B2

Title: Measuring round trip time in a mobile communication network

Description:
FIELD 
     The subject matter disclosed herein relates generally to wireless communications and more particularly relates to measuring round trip time (“RTT”). 
     BACKGROUND 
     The following abbreviations and acronyms are herewith defined, at least some of which are referred to within the following description. 
     Third Generation Partnership Project (“3GPP”), Fifth-Generation Core (“5GC”), Fifth-Generation QoS Indicator (“5QI”), Access and Mobility Management Function (“AMF”), Access Network Performance (“ANP”), Access Point Name (“APN”), Access Stratum (“AS”), Access Traffic Steering, Switching and Splitting (“ATSSS”), Allocation/Retention Policy (“ARP”), Application Programing Interface (“API”), Carrier Aggregation (“CA”), Clear Channel Assessment (“CCA”), Control Channel Element (“CCE”), Channel State Information (“CSI”), Common Search Space (“CSS”), Data Network Name (“DNN”), Data Radio Bearer (“DRB”), Differentiated Services Code Point (“DSCP”), Downlink Control Information (“DCI”), Downlink (“DL”), Enhanced Clear Channel Assessment (“eCCA”), Enhanced Mobile Broadband (“eMBB”), Encapsulating Security Payload (“ESP”), Evolved Node-B (“eNB”), Evolved Packet Core (“EPC”), Evolved UMTS Terrestrial Radio Access Network (“E-UTRAN”), European Telecommunications Standards Institute (“ETSI”), Echo Acknowledgement Indicator (“EAI”), Request Indicator (“ERI”, ERI-d refers to an ERI associated with a dummy payload and ERI-v refers to an ERI associated with a valid payload), Fixed Access Gateway Function (“FAGF”), Fixed Network Residential Gateway (“FN-RG”), Frame Based Equipment (“FBE”), Frequency Division Duplex (“FDD”), Frequency Division Multiple Access (“FDMA”), Generic Routing Encapsulation (“GRE”), Globally Unique Temporary UE Identity (“GUTI”), General Packet Radio Service (“GPRS”), GPRS Tunneling Protocol (“GTP”, GTP-C refers to control signal tunneling while GTP-U refers to user data tunneling), Hybrid Automatic Repeat Request (“HARQ”), Home Subscriber Server (“HSS”), Internet-of-Things (“IoT”), IP Multimedia Subsystem (“IMS,” aka “IP Multimedia Core Network Subsystem”), Internet Protocol (“IP”), Key Performance Indicators (“KPI”), Licensed Assisted Access (“LAA”), Load Based Equipment (“LBE”), Listen-Before-Talk (“LBT”), Long Term Evolution (“LTE”), LTE Advanced (“LTE-A”), Medium Access Control (“MAC”), Multiple Access (“MA”), Modulation Coding Scheme (“MCS”), Machine Type Communication (“MTC”), Massive MTC (“mMTC”), Mobility Management (“MM”), Mobility Management Entity (“MME”), Multiple Input Multiple Output (“MIMO”), Multipath TCP (“MPTCP”), Multi User Shared Access (“MUSA”), Non-Access Stratum (“NAS”), Narrowband (“NB”), Network Function (“NF”), Network Access Identifier (“NAI”), Next Generation (e.g., 5G) Node-B (“gNB”), Next Generation Radio Access Network (“NG-RAN”), New Radio (“NR”), Policy Control &amp; Charging (“PCC”), Policy Control Function (“PCF”), Policy Control and Charging Rules Function (“PCRF”), Packet Data Network (“PDN”), Packet Data Unit (“PDU”), PDN Gateway (“PGW”), Public Land Mobile Network (“PLMN”), Quality of Service (“QoS”), QoS Class Identifier (“QCI”), Quadrature Phase Shift Keying (“QPSK”), Registration Area (“RA”), Radio Access Network (“RAN”), Radio Access Technology (“RAT”), Radio Resource Control (“RRC”), Receive (“RX”), Reflective QoS Indicator (“RQI”), Single Network Slice Selection Assistance Information (“S-NSSAI”), Scheduling Request (“SR”), Secure User Plane Location (“SUPL”), Serving Gateway (“SGW”), Session Management Function (“SMF”), Stream Control Transmission Protocol (“SCTP”), System Information Block (“SIB”), Tracking Area (“TA”), Transport Block (“TB”), Transport Block Size (“TBS”), Transmission Control Protocol (“TCP”), Time-Division Duplex (“TDD”), Time Division Multiplex (“TDM”), Transmission and Reception Point (“TRP”), Transmit (“TX”), Trusted WLAN Interworking Function (“TWIF”), Uplink Control Information (“UCI”), Unified Data Management (“UDM”), User Entity/Equipment (Mobile Terminal) (“UE”), Uplink (“UL”), User Plane (“UP”), Universal Mobile Telecommunications System (“UMTS”), Ultra-reliability and Low-latency Communications (“URLLC”), User Datagram Protocol (“UDP”), UE Route Selection Policy (“URSP”), Wireless Local Area Network (“WLAN”), Wireless Local Area Network Selection Policy (“WLANSP”), and Worldwide Interoperability for Microwave Access (“WiMAX”). 
     There are many technologies known for measuring the packet delay in IP communication networks. However, none of them are optimized for 5G NR, where simplicity and efficiency are primary deciding factors. Even the simplest solution based on “Ping/Pong” is not very efficient, given that UEs may consume many radio and battery resources when they apply this solution for an extended period of time. 
     Further, sending frequent Echo Request messages (e.g. once every 5-10 sec) from the UE to the core network is very inefficient since it consumes lot of radio, network and battery resources. Moreover, it creates additional traffic, which can increase congestion and can result in much higher latency values. 
     BRIEF SUMMARY 
     Methods for measuring RTT are disclosed. Apparatuses and systems also perform the functions of the methods. 
     A first method for measuring RTT includes supporting a first interface (e.g., an N2 interface) that communicates with control-plane functions in a mobile core network (e.g., a 5GC) and a second interface that communicates with a remote unit over a non-3GPP access network. The first method includes receiving a request via the first interface to establish access resources for enabling data communication between the remote unit and the mobile core network via a data connection. Here, the data connection supports a plurality of QoS flows and the request includes a first indicator (e.g., a RTT Report Request) that requests RTT measurements using a first QoS flow. The first method includes transmitting a first message to the remote unit via the second interface and using the first QoS flow of the data connection, wherein the first message includes a first encapsulation header (e.g., GRE header) comprising an echo request indication. The first method includes receiving a second message via the second interface, wherein the second message includes a second encapsulation header (e.g., GRE header) comprising an echo response indication (e.g., an Echo Ack indication). The first method includes measuring the RTT for the first QoS flow of the data connection using the echo response indication. 
     A second method for measuring RTT includes communicating with an access network, the access network connected to a mobile core network (e.g., a 5GC) via an interworking function (e.g., TNGF or N3IWF). The second method includes transmitting a first request to establish a data connection between the remote unit and the mobile core network. Here, the first request includes a first indicator that the remote unit supports RTT measurements calculated using messages transmitted via the data connection and using an encapsulation header. The second method includes receiving a first message from the interworking function. Here, the first message includes a first encapsulation header (e.g., a GRE header) comprising an echo request indication. The second method includes transmitting a second message to the interworking function. Here, the second message includes a second encapsulation header (e.g., a GRE header) comprising an echo response indication (e.g., an Echo Ack indication). 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       A more particular description of the embodiments briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. Understanding that these drawings depict only some embodiments and are not therefore to be considered to be limiting of scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which: 
         FIG.  1    is a schematic block diagram illustrating one embodiment of a wireless communication system for measuring RTT; 
         FIG.  2 A  is a block diagram illustrating one embodiment of a procedure for measuring RTT; 
         FIG.  2 B  is a continuation of the procedure depicted in  FIG.  2 A ; 
         FIG.  2 C  is a continuation of the procedure depicted in  FIGS.  2 A-B ; 
         FIG.  3 A  is a block diagram illustrating another embodiment of a procedure for measuring RTT; 
         FIG.  3 B  is a continuation of the procedure depicted in  FIG.  3 A ; 
         FIG.  3 C  is a continuation of the procedure depicted in  FIGS.  3 A-B ; 
         FIG.  4    is a schematic block diagram illustrating one embodiment of a user equipment apparatus for measuring RTT; 
         FIG.  5    is a schematic block diagram illustrating one embodiment of a network equipment apparatus for measuring RTT; 
         FIG.  6    is a flow chart diagram illustrating one embodiment of a first method for measuring RTT; and 
         FIG.  7    is a flow chart diagram illustrating one embodiment of a second method for measuring RTT. 
     
    
    
     DETAILED DESCRIPTION 
     As will be appreciated by one skilled in the art, aspects of the embodiments may be embodied as a system, apparatus, method, or program product. Accordingly, embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects. 
     For example, the disclosed embodiments may be implemented as a hardware circuit comprising custom very-large-scale integration (“VLSI”) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code which may, for instance, be organized as an object, procedure, or function. 
     Furthermore, embodiments may take the form of a program product embodied in one or more computer readable storage devices storing machine readable code, computer readable code, and/or program code, referred hereafter as code. The storage devices may be tangible, non-transitory, and/or non-transmission. The storage devices may not embody signals. In a certain embodiment, the storage devices only employ signals for accessing code. 
     Any combination of one or more computer readable medium may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing the code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. 
     More specific examples (a non-exhaustive list) of the storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random-access memory (“RAM”), a read-only memory (“ROM”), an erasable programmable read-only memory (“EPROM” or Flash memory), a portable compact disc read-only memory (“CD-ROM”), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store, a program for use by or in connection with an instruction execution system, apparatus, or device. 
     Reference throughout this specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment, but mean “one or more but not all embodiments” unless expressly specified otherwise. The terms “including,” “comprising,” “having,” and variations thereof mean “including but not limited to,” unless expressly specified otherwise. An enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms “a,” “an,” and “the” also refer to “one or more” unless expressly specified otherwise. 
     Furthermore, the described features, structures, or characteristics of the embodiments may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however, that embodiments may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of an embodiment. 
     Aspects of the embodiments are described below with reference to schematic flowchart diagrams and/or schematic block diagrams of methods, apparatuses, systems, and program products according to embodiments. It will be understood that each block of the schematic flowchart diagrams and/or schematic block diagrams, and combinations of blocks in the schematic flowchart diagrams and/or schematic block diagrams, can be implemented by code. This code may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the schematic flowchart diagrams and/or schematic block diagrams. 
     The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions which implement the function/act specified in the schematic flowchart diagrams and/or schematic block diagrams. 
     The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer implemented process such that the code which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the schematic flowchart diagrams and/or schematic block diagram. 
     The schematic flowchart diagrams and/or schematic block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods, and program products according to various embodiments. In this regard, each block in the schematic flowchart diagrams and/or schematic block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions of the code for implementing the specified logical function(s). 
     It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, of the illustrated Figures. 
     The description of elements in each figure may refer to elements of proceeding figures. Like numbers refer to like elements in all figures, including alternate embodiments of like elements. 
     Methods, apparatuses, and systems are disclosed for measuring RTT. UEs may be required to monitor latency of multiple access networks in order to select a “best” access network. In a first use case, a UE capable of supporting Access Traffic Steering, Switching, Splitting (ATSSS), can simultaneously communicate over a 3GPP access network (e.g. NG-RAN) and over a non-3GPP access network (e.g. WLAN), where the traffic exchanged between the UE and a Remote Host can either be distributed over both accesses, or can be sent on the “best” access only, e.g. on the access characterized by the less latency, or the less Round Trip Time (RTT). In the uplink (UL) direction, the UE decides how to distribute the traffic across the two accesses based on policy rules (ATSSS rules) provided by the network. Similarly, in the downlink (DL) direction, a UPF at the edge of the 5G Core (5GC) network decides how to distribute the traffic across to the two accesses based on corresponding policy rules. 
     In many scenarios, where communication latency is important, the policy rules may indicate that specific traffic should be routed according to a latency-dependent condition. For example, the policy rules in the UE may indicate:
         “Route traffic to Remote Host over 3GPP access, if Latency over 3GPP access &lt;20 ms”; or   “Route IMS voice traffic to the access with the smallest Latency”       

     To enforce the above policy rules, the UE is required to measure the latency (or RTT) over 3GPP access and the latency (or RTT) over non-3GPP access. Similarly, the UPF is required to measure the latency (or RTT) over 3GPP access and the latency (or RTT) over non-3GPP access, in order to decide how to route the DL traffic in compliance with the policy rules. 
     The 3GPP specifications in Rel-16 indicate that a Performance Measurement Functionality (PMF) shall be supported in the UPF, which assists the UE (and the UPF itself) in taking RTT measurements over the two accesses. In particular, the Rel-16 3GPP specifications specify that RTT measurements can be taken by exchanging Echo Request/Echo Response messages between the UE and the PMF in the UPF. This way the UE can calculate a RTT over each access, which is tightly associated with the latency of each access. 
     However, sending frequent Echo Request messages (e.g. once every 5-10 sec) from the UE to PMF is very inefficient since it consumes lot of radio, network and battery resources. Furthermore, it creates additional traffic, which can increase congestion and can result to much higher latency values. 
     One purpose of this disclosure is to specify an alternative method for measuring the RTT in the UE and in the UPF, which does not require the exchange of dedicated Echo Request/Echo Response messages and thus it improves the efficiency of the measurement process. 
     A second use case is when the network needs to monitor the RTT between the UE and TNGF/N3IWF and take actions when the RTT exceeds specific thresholds. For example, in order to support an application that requires low latency, the network may want to monitor the RTT when the traffic of this application is transported over non-3GPP access, and possibly to transfer this traffic over 3GPP access, when the RTT over non-3GPP access cannot remain below e.g. 30 ms. 
     In this case, as opposed to the Use Case 1, there is no need for the UE and/or the UPF to measure the RTT. It is only needed by a control-plane entity in 5GC (e.g. by SMF) to receive a notification from TNGF/N3IWF when the RTT exceeds a certain threshold. Another purpose of this disclosure is to specify a method wherein the SMF can receive the RTT value measured by TNGF/N3IWF or a notification when this RTT value exceeds certain thresholds. 
     In general, there are many technologies known for measuring the packet delay in IP communication networks. However, none of them are suitably efficient for crowded air interfaces, where simplicity and efficiency are the primary deciding factors. Even the simplest solution based on Echo Request/Echo Response messages is not very efficient, given that UEs may consume many radio and battery resources when they apply this solution for an extended period of time. 
     Also, many known technologies for packet delay measurement are not applicable in 5G because they require some sort of proxy functionality in the 5G core network, which is not available and is unlikely to be introduced. For example, the UPF in 5GC could apply a SOCKS proxy that terminates all UDP and TCP flows of the UE and then creates corresponding outbound flows over the N6 interface. However, the proxy operation introduces a lot of overhead and can have a severe impact on the packet throughput and on the battery consumption of UEs. 
     Note that a proxy functionality is defined in 5GC but only to enable Multi-Path TCP (MPTCP) operation, nothing else. Because of this, the disclosed measurement method in this disclosure is not required when MPTCP is used. However, the disclosed measurement method is needed when the MPTCP protocol is not applied for traffic steering operations. 
       FIG.  1    depicts a wireless communication system  100  for measuring RTT, according to embodiments of the disclosure. In one embodiment, the wireless communication system  100  includes at least one remote unit  105 , a 5G-RAN  115 , and a mobile core network  140 . The 5G-RAN  115  and the mobile core network form a mobile communication network. The 5G-RAN  115  may be composed of a 3GPP access network  120  containing at least one cellular base unit  121  and/or a non-3GPP access network  130  containing at least one access point  131 . The remote unit communicates with the 3GPP access network  120  using 3GPP communication links  123  and communicates with the non-3GPP access network  130  using non-3GPP communication links  133 . Even though a specific number of remote units  105 , 3GPP access networks  120 , cellular base units  121 , 3GPP communication links  123 , non-3GPP access networks  130 , access points  131 , non-3GPP communication links  133 , and mobile core networks  140  are depicted in  FIG.  1   , one of skill in the art will recognize that any number of remote units  105 , 3GPP access networks  120 , cellular base units  121 , 3GPP communication links  123 , non-3GPP access networks  130 , access points  131 , non-3GPP communication links  133 , and mobile core networks  140  may be included in the wireless communication system  100 . 
     In one implementation, the wireless communication system  100  is compliant with the 5G system specified in the 3GPP specifications. More generally, however, the wireless communication system  100  may implement some other open or proprietary communication network, for example, LTE or WiMAX, among other networks. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol. 
     In one embodiment, the remote units  105  may include computing devices, such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), smart appliances (e.g., appliances connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle on-board computers, network devices (e.g., routers, switches, modems), or the like. In some embodiments, the remote units  105  include wearable devices, such as smart watches, fitness bands, optical head-mounted displays, or the like. Moreover, the remote units  105  may be referred to as UEs, subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, user terminals, wireless transmit/receive unit (“WTRU”), a device, or by other terminology used in the art. 
     The remote units  105  may communicate directly with one or more of the cellular base units  121  in the 3GPP access network  120  via uplink (“UL”) and downlink (“DL”) communication signals. Furthermore, the UL and DL communication signals may be carried over the 3GPP communication links  123 . Similarly, the remote units  105  may communicate with one or more access points  131  in the non-3GPP access network(s)  130  via UL and DL communication signals carried over the non-3GPP communication links  133 . Here, the access networks  120  and  130  are intermediate networks that provide the remote units  105  with access to the mobile core network  140 . 
     In some embodiments, the remote units  105  communicate with a remote host  155  via a network connection with the mobile core network  140 . For example, an application in a remote unit  105  (e.g., web browser, media client, telephone/VoIP application) may trigger the remote unit  105  to establish a PDU session (or other data connection) with the mobile core network  140  using the 5G-RAN  115  (e.g., a 3GPP access network  120  and/or a non-3GPP access network  130 ). The mobile core network  140  then relays traffic between the remote unit  105  and the data network  150  (e.g., remote host  155 ) using the PDU session. Note that the remote unit  105  may establish one or more PDU sessions (or other data connections) with the mobile core network  140 . As such, the remote unit  105  may have at least one PDU session for communicating with the data network  150 . The remote unit  105  may establish additional PDU sessions for communicating with other data network and/or other remote hosts. 
     The cellular base units  121  may be distributed over a geographic region. In certain embodiments, a cellular base unit  121  may also be referred to as an access terminal, a base, a base station, a Node-B, an eNB, a gNB, a Home Node-B, a relay node, a device, or by any other terminology used in the art. The cellular base units  121  are generally part of a radio access network (“RAN”), such as the 3GPP access network  120 , that may include one or more controllers communicably coupled to one or more corresponding cellular base units  121 . These and other elements of radio access network are not illustrated but are well known generally by those having ordinary skill in the art. The cellular base units  121  connect to the mobile core network  140  via the 3GPP access network  120 . 
     The cellular base units  121  may serve a number of remote units  105  within a serving area, for example, a cell or a cell sector, via a 3GPP communication link  123 . The cellular base units  121  may communicate directly with one or more of the remote units  105  via communication signals. Generally, the cellular base units  121  transmit DL communication signals to serve the remote units  105  in the time, frequency, and/or spatial domain. Furthermore, the DL communication signals may be carried over the 3GPP communication links  123 . The 3GPP communication links  123  may be any suitable carrier in licensed or unlicensed radio spectrum. The 3GPP communication links  123  facilitate communication between one or more of the remote units  105  and/or one or more of the cellular base units  121 . 
     The non-3GPP access networks  130  may be distributed over a geographic region. Each non-3GPP access network  130  may serve a number of remote units  105  with a serving area. Typically, a serving area of the non-3GPP access network  130  is smaller than the serving area of a cellular base unit  121 . An access point  131  in a non-3GPP access network  130  may communicate directly with one or more remote units  105  by receiving UL communication signals and transmitting DL communication signals to serve the remote units  105  in the time, frequency, and/or spatial domain. Both DL and UL communication signals are carried over the non-3GPP communication links  133 . The 3GPP communication links  123  and non-3GPP communication links  133  may employ different frequencies and/or different communication protocols. In various embodiments, an access point  131  may communicate using unlicensed radio spectrum. The mobile core network  140  may provide services to a remote unit  105  via the non-3GPP access networks  130 , as described in greater detail herein. 
     In some embodiments, anon-3GPP access network  130  connects to the mobile core network  140  via an interworking function  135 . The interworking function  135  provides interworking between the remote unit  105  and the mobile core network  140 . In some embodiments, the interworking function  135  is a Non-3GPP Interworking Function (“N3IWF”) and, in other embodiments, it is a Trusted Non-3GPP Gateway Function (“TNGF”). The N3IWF supports the connection of “untrusted” non-3GPP access networks to the mobile core network (e.g. 5GC), whereas the TNGF supports the connection of “trusted” non-3GPP access networks to the mobile core network. The interworking function  135  supports connectivity to the mobile core network  140  via the “N2” and “N3” interfaces, and it relays “N1” signaling between the remote unit  105  and the AMF  145 . As depicted, both the 3GPP access network  120  and the interworking function  135  communicate with the AMF  145  using a “N2” interface. The interworking function  135  also communicates with the UPF  143  using a “N3” interface. 
     The non-3GPP access network  130  may support three different types of interworking functions  135 . A first type (“Type 1”) supports connectivity to one or more 5GC networks for UEs which do not support the NAS protocol. A second type (“Type 2”) supports connectivity to one or more 5GC networks for UEs which do support the NAS protocol. A third type (“Type 3”) supports connectivity to one or more EPC networks using the existing S2a procedures (see 3GPP TS 23.402). Note that a non-3GPP access network  130  may support one, two, or all three types of interworking functions. 
     In certain embodiments, a non-3GPP access network  130  may be controlled by an operator of the mobile core network  140  and may have direct access to the mobile core network  140 . Such a non-3GPP AN deployment is referred to as a “trusted non-3GPP access network.” A non-3GPP access network  130  is considered as “trusted” when it is operated by the 3GPP operator, or a trusted partner, and supports certain security features, such as strong air-interface encryption. In contrast, a non-3GPP AN deployment that is not controlled by an operator (or trusted partner) of the mobile core network  140 , does not have direct access to the mobile core network  140 , or does not support the certain security features is referred to as a “non-trusted” non-3GPP access network. 
     In one embodiment, the mobile core network  140  is a 5G core (“5GC”) or the evolved packet core (“EPC”), which may be coupled to a data network (e.g., the data network  150 , such as the Internet and private data networks, among other data networks. A remote unit  105  may have a subscription or other account with the mobile core network  140 . Each mobile core network  140  belongs to a single public land mobile network (“PLMN”). The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol. 
     The mobile core network  140  includes several network functions (“NFs”). As depicted, the mobile core network  140  includes multiple user plane functions (“UPFs”). Here, the mobile core network  140  includes at least a UPF  143  that serves the 3GPP access network  120  and the non-3GPP access network  130 . Note that in certain embodiments, the mobile core network may contain one or more intermediate UPFs, for example a first intermediate UPF that serves the non-3GPP access network  130  and the second intermediate UPF that serves the 3GPP access network  120 . In such embodiments, the UPF  143  would be an anchor UPF receiving UP traffic of both intermediate UPFs. 
     The mobile core network  140  also includes multiple control plane functions including, but not limited to, an Access and Mobility Management Function (“AMF”)  145  that serves both the 3GPP access network  120  and the non-3GPP access network  130 , a Session Management Function (“SMF”)  146 , a Policy Control Function (“PCF”)  148 , and a Unified Data Management function (“UDM”)  149 . In certain embodiments, the mobile core network  140  may also include an Authentication Server Function (“AUSF”), a Network Repository Function (“NRF”) (used by the various NFs to discover and communicate with each other over APIs), or other NFs defined for the 5GC. In various embodiments, the mobile core network  140  may include a PMF (not shown) to assist the UE and/or the anchor UPF  143  in taking performance measurements over the two accesses, including latency measurements. In one embodiment, the PMF may be co-located with the anchor UPF  143 . 
     Although specific numbers and types of network functions are depicted in  FIG.  1   , one of skill in the art will recognize that any number and type of network functions may be included in the mobile core network  140 . Moreover, where the mobile core network  140  is an EPC, the depicted network functions may be replaced with appropriate EPC entities, such as an MME, S-GW, P-GW, HSS, and the like. 
     As depicted, a remote unit  105  (e.g., a UE) may connect to the mobile core network (e.g., to a 5G mobile communication network) via two types of accesses: (1) via 3GPP access network  120  and (2) via a non-3GPP access network  130 . The first type of access (e.g., 3GPP access network  120 ) uses a 3GPP-defined type of wireless communication (e.g., NG-RAN) and the second type of access (e.g., non-3GPP access network  130 ) uses a non-3GPP-defined type of wireless communication (e.g., WLAN). The 5G-RAN  115  refers to any type of 5G access network that can provide access to the mobile core network  140 , including the 3GPP access network  120  and the non-3GPP access network  130 . 
     In various embodiments, the mobile core network  140  supports different types of mobile data connections and different types of network slices, wherein each mobile data connection utilizes a specific network slice. The different network slices are not shown in  FIG.  1    for ease of illustration, but their support is assumed. 
     In many scenarios, where communication latency is important, the policy rules (e.g., of steering policy  110 ) may indicate that specific traffic should be routed according to a latency-dependent condition. In one example, the traffic steering rules in the remote unit  105  may indicate: “Route traffic to Remote Host over 3GPP access, if Latency over 3GPP access &lt;20 ms”. In another example, or the traffic steering rules in the remote unit  105  may indicate: “Route IMS voice traffic to the access with the smallest Latency”. 
     To enforce such policy rules, the remote unit  105  measures the latency over 3GPP access and the latency over non-3GPP access. In certain embodiments, the UPF  143  may measure the latency over 3GPP access and the latency over non-3GPP access, in order to decide how to route the DL traffic in compliance with the policy rules. In other embodiments, one of the UE  205  and the UPF  143  may report to the other the latency over 3GPP access and the latency over non-3GPP access, with the assumption of strong correlation between uplink latencies and downlink latencies. 
     In certain embodiments, the remote unit  105  transmit a request to establish a data connection (e.g., a PDU session) with the mobile core network  140  via the interworking function (“IWF”)  135  and may indicate in the request that it supports RTT measurements using encapsulation header (e.g., GRE headers). Thereafter, the remote unit  105  may occasionally receive a message from the IWF  135  having an encapsulation header that includes an echo request indicator. In response to the echo request indicator, the remote unit  105  may immediately send back and echo response (e.g., Echo ACK) message to the IWF  135 , wherein the IWF  135  measures RTT using the elapsed time between sending the message with the echo request and receiving the echo response. Additional details for measuring RTT are discussed below. 
       FIG.  2    depicts a first procedure  200  for measuring RTT of an access network, according to embodiments of the disclosure. In the first procedure  200 , the UE  205  does not take its own RTT measurements but can receive from the SMF the RTT measured by the network. Note that the first procedure  200  can support the Use Case 1 and the Use Case 2 described above. The first procedure  200  involves a UE  205 , the IWF  135 , the UPF  143 , the AMF  145 , and the SMF  146 . Recall that the UPF  143  can send user traffic over either the 3GPP access or the non-3GPP access. 
     At  FIG.  2 A , the first procedure  200  begins with the UE  205  establishing one or more IPsec Security Associations (SAs) for NAS signaling with the IWF  135  (see communication  210 ). In some embodiments, the IWF  135  is an TNGF. In other embodiments, the IWF  135  is a N3IWF. 
     At step  1 , the UE  205  requests a PDU Session, e.g., by sending a PDU Session Establishment Request message (see message  212 ). In this message, the UE  205  includes an indication (e.g., the new indication “support GRE-based RTT measurements”) that shows it can support RTT measurements over non-3GPP access by using the techniques specified below, which utilizes the GRE protocol. 
     In one example, the UE  205  requests a Multi-Access PDU (MA PDU) Session, i.e. a PDU Session that can support data communication over both 3GPP access and non-3GPP access. In this case, the UPF  143  in the network and the UE  205  may need to measure the RTT over each access, in order to determine how to route the downlink and the uplink traffic respectively of the MA PDU Session. The RTT over each access may be needed if, for example, some traffic should be routed based on a “Smallest Delay” steering mode. In this case, the RTT should be measured over each access so that the access with the smallest delay can be determined. This situation is one example of the Use Case 1, discussed above. 
     A PCF in the 5GC (not shown in the figure) creates PCC rules for the MA PDU Session, which are sent to SMF  146  and indicate (1) what QoS should be applied for selected data flows sent over the MA PDU Session, (2) what steering modes should be applied for selected data flows sent over the MA PDU Session, etc. 
     One example of PCC rules are as follows:
         A first PCC rule may indicate that (1) the traffic of App-1 should be transported by using 5QI-1 and (2) the traffic of App-1 should be steered to 3GPP access, if available, otherwise, to non-3GPP access.   A second PCC rule may indicate that (1) the traffic of App-2 should be transported by using 5QI-2 and (2) the traffic of App-2 should be steered to the access with the “smallest delay”.   A third PCC rule may indicate that (1) the traffic of App-3 should be transported by using 5QI-3, 200 Kbps guaranteed bandwidth in the uplink direction and 500 Kbps guaranteed bandwidth in the downlink direction, and (2) the traffic of App-3 should be steered to non-3GPP access, if available, otherwise, to 3GPP access.       

     Based on the received PCC rules for the MA PDU Session, the SMF  146  determines (1) access steering rules for the UE  205  (e.g., ATSSS rules), and (2) access steering rules for the UPF  143  (see block  213 ). In addition, the SMF  146  determines what QoS flows should be established for the MA PDU Session and creates the associated QoS rules for the UE  205  and the associated QoS Enforcement Rules (QER) for the UPF  143 . 
     Based on the second PCC rule considered above, the SMF  146  determines that (1) RTT measurements need to be obtained by the UE  205  and UPF  143  in order to determine which access has the “smallest delay” and (2) the RTT measurements should be obtained by using 5QI-2, i.e. the same 5QI applied for App-2, which should be steered with the “smallest delay” steering mode. The steps below specify how the UE  205  and UPF  143  obtain necessary RTT measurements. 
     At step  2 , the IWF  135  receives a PDU Session Resource Setup Request message  214 , which includes a PDU Session Establishment Accept message and a QoS Flow Setup Request List  216 , which includes a list of three different QoS flows, each one corresponding to one of the three PCC rules considered above. 
     Note that for the second QoS flow (identified by QFI-2), the SMF  146  includes, not only the associated QoS parameters (5QI-2, ARP-2, RQI-2), but also a new parameter called RTT Report Request, which indicates to the IWF  135  that it should measure the RTT over this QoS flow and it should report the measured RTT to the SMF  146  based on some reporting conditions. For example, this new parameter may indicate to the IWF  135  to report the measured RTT whenever it changes by +/−10% over the previously reported RTT value. In another case, associated with the Use Case 2 (see above), the reporting conditions may indicate to the IWF  135  to report the RTT, or to send a notification to the SMF  146 , only when the measured RTT value exceeds a certain threshold. In some other cases, the RTT Report Request may not include reporting conditions, which may indicate to the IWF  135  that the measured RTT should be reported whenever a new value is available. In yet some other cases, the RTT Report Request may include measurement parameters, for example, to indicate how often the RTT should be measured. 
     Note that the SMF  146  does not send the RTT Report Request parameter to the IWF  135  unless the UE  205  indicates it can “support GRE-based RTT measurements” (in step  1 ). If the UE  205  cannot “support GRE-based RTT measurements”, then RTT measurements can be taken as specified in Rel-16 of the 3GPP specifications, i.e. by exchanging PMF-Echo Request/Response messages between the UE  205  and the UPF  143 . 
     At step  3 , the IWF  135 , as normally, determines the number of child IPsec Security Associations (SAs) to be established, which one carrying one or more of the three QoS flows decided by the PCF for the MA PDU Session (see block  218 ). In the example depicted in  FIG.  2 A , the IWF  135  decides to establish two child IPsec SAs: the first carrying the traffic of QoS flow 1 and the traffic of QoS flow 2 (identified by QFI-1 and QFI-2 respectively), and the second carrying the traffic of QoS flow 3 (identified by QFI-3). 
     At step  4 , the IWF  135  sends messages to the UE  205  to establish the determined number of child IPsec SAs (see messaging  220  and  222 ). At step  5 , the IWF  135  forwards to the UE  205  the PDU Session Establishment Accept message received in step  2  (see messaging  224 ). 
     At step  6 , the IWF  135  responds to the request received in the step  2  with a PDU Session Resource Setup Response message, indicating that the radio access resources for the PDU Session have been successfully established over non-3GPP access (see messaging  226 ). 
     At step  7 , the UE  205  and the UPF  143  may start user-plane (UP) communication over the non-3GPP access of the PDU Session (see blocks  228  and  230 ). In addition to user-plane communication, the IWF  135  may start RTT measurements over the second QoS flow (QFI-2), as instructed in step  2  with the reception of the RTT Report Request parameter for this QoS flow. 
     Continuing at  FIG.  2 B , at step  8 , in the uplink (UL) direction, the UE  205  sends user-plane traffic (i.e. a series of PDU payloads) to the IWF  135 , encapsulated with GRE (see UL messages  232 ). The GRE header includes the QoS Flow Identifier (QFI) associated with the encapsulated PDU payload.  FIG.  2 B  shows only PDU payloads associated with QFI-2 for ease of illustration, however, PDU payloads associated with QFI-1 and QFI-3 will also be sent. 
     Note that the UE does not include any new indicators in the GRE header at this time because the UE is not instructed to perform RTT measurements in the first procedure  200 . The IWF  135  forwards every PDU payload received from the UE  205  to the UPF  143  over the N3 interface, which utilizes GTP-U encapsulation. 
     In the downlink (DL) direction, the UPF  143  sends user-plane traffic (i.e. a series of PDU payloads) to the IWF  135  over the N3 interface. In turn, the IWF  135  encapsulates these PDU payloads with GRE, and forwards them to the UE  205 . As normally, the GRE header includes the QoS Flow Identifier (QFI) associated with the encapsulated PDU payload. 
     However, when the IWF  135  wants to measure the RTT at step  10 , the IWF  135  includes a new indicator in the GRE header, referred to as an Echo Request Indication (ERI) (see messaging  234 ). When the UE  205  receives a GRE packet with the ERI in the header, it immediately responds with a GRE packet that contains an Echo Ack Indicator (EAI) (see block  236  and messaging  238 ). This GRE packet does not contain a PDU payload; it is only an acknowledgment that aids the IWF  135  measure the current RTT between the UE  205  and IWF  135 . The IWF  135  measures the RTT  240  by computing the time difference between the transmitted GRE packet with the ERI and the received GRE packet with the EAI. 
     At steps  11 - 12 , the IWF  135  does not include the ERI in all PDU payloads forwarded to the UE  205  (see messaging  242 ). The ERI is only included when the IWF  135  wants to take another RTT measurement and update the average RTT value. In one embodiment, the (average) RTT is the “cumulated moving average” of the round trip time of the first access. Here, after EAI(1), the RTT=rtt. After EAI(2), the RTT=(RTT+rtt)/2. After EAI(3) the RTT=(2*RTT+rtt)/3. After EAI(4) the RTT=(3*RTT+rtt)/4. In general, after EAI(n+1), RTT NEW =(n*RTT OLD +rtt)/(n+1). In other embodiments, the IWF  135  may use other types of averaging to calculate the (average) RTT of the RAN, such as a “weighted moving average” where recent rtt values have a bigger weight than older rtt values. 
     Continuing at  FIG.  2 C , step  13  shows the case where the IWF  135  does not receive DL traffic from UPF  143  for some time (see block  244 ). In order to take another RTT measurement when there is no DL traffic to deliver to the UE  205 , the IWF  135  may send a “Dummy” payload to the UE  205  and include the ERI indicator in the GRE header (see messaging  246 ). However, in this case, the IWF  135  needs also to instruct the UE  205  to discard the dummy payload. For this purpose, the IWF  135  includes a different ERI indicator, referred to as ‘ERI-d,’ which has a different value from the ERI indicator, called ‘ERI-v,’ that is included in step  10 . The ERI-v indicator is included when the PDU payload is valid and should be consumed by the UE  205 , whereas the ERI-d indicator is included when the PDU payload is dummy and should be discarded (ignored) by the UE  205  (see block  247 ). 
     The UE  205  transmits a GRE packet with the EAI indicator when it receives a GRE packet including either the ERI-v or the ERI-d indicator (see messaging  248 ) allowing the IWF  135  to measure the RTT  249 . Recall that this UE behavior is only possible when the UE  205  indicates in step  1  that is capable to “support GRE-based RTT measurements”. Otherwise, the UE  205  would ignore the ERI-v and ERI-d indicators in the GRE headers. 
     At steps  14 - 15 , more PDU payloads are forwarded by the IWF  135  to the UE  205  without an ERI indicator (see messages  250 ). At step  20 , the IWF  135  decides to report to SMF  146  the measured (and averaged) RTT (see block  252 ). Here the decision is made according to the reporting conditions in the received RTT Report Request parameter (see step  2 ). At step  21 , the IWF  135  sends to SMF  146 , via the AMF  145 , the measured (and averaged) RTT, e.g. within a PDU Session Resource Notify message (see messaging  254 ). Alternatively, the IWF  135  may send the measured RTT to UPF  143 . The UPF  143  may then add to the measured RTT received from IWF  135  (i.e., the RAN-RTT) a second RTT measured over the N3 interface (i.e. between the UPF  143  and the IWF  135 ), and forward the sum of these RTT values to SMF  146 . This way, the SMF  146  becomes aware of the total RTT between the UE  205  and the UPF  143 . The RTT over the N3 interface can be measured with procedures not specified in this document, e.g. by using the QoS Monitoring procedures defined in 3GPP TS 23.501. 
     The following two steps are required only to support the Use Case 1 (ATSSS), where both the UE  205  and the UPF  143  are to be aware of the RTT over non-3GPP access. To support the Use Case 2 (RTT monitoring), it is sufficient for the IWF  135  to send to SMF  146  (in step  21 ) the measured RTT or a notification when the RTT exceeds predefined thresholds. Alternatively, it may be sufficient for the IWF  135  to send to UPF  143  the measured RTT and then for the UPF  143  to send to SMF  146  the total RTT between the UE  205  and the UPF  143 . 
     At step  22 , the SMF  146  forwards the measured RTT received from the IWF  135  to the UPF  143  (see messaging  256 ). as discussed above, the UPF  143  may add the measured RAN-RTT received from SMF  146  to the N3-RTT (measured over the N3 interface) to obtain the total RTT between the UE  105  and the UPF  143 . The RTT over the N3 interface is measured with means not discussed in this document, e.g., by exchanging GTP-U Echo Request/Echo Response messages using the second QoS flow identified by QFI-2. 
     Finally, at step  23  the SMF  146  forwards also the measured RTT received from the IWF  135  to the UE  205 , again after adding the RTT over the N3 interface (see messaging  258 ). After this step, both the UE  205  and the UPF  143  have the same value of RTT that characterizes the entire path between the UE  205  and the UPF  143  over non-3GPP access. The UE  205  and UPF  143  can use this value of RTT for taking their ATSSS decisions and route the UL and DL traffic of App-2, respectively, to the access with the smallest delay (or, the smallest RTT), as required by the second PCC rule considered in step  2 . 
     In various embodiments, the ERI-v, ERI-d and EAI indicators discussed above may be contained within the Key field of the GRE header and encoded by using two bits as shown in Table 1. 
     
       
         
           
               
               
               
               
             
               
                   
                 TABLE 1 
               
               
                   
                   
               
               
                   
                 Bit 2 
                 Bit 1 
                   
               
               
                   
                   
               
             
            
               
                   
                 0 
                 0 
                 Indicates no ERI and no EAI are included 
               
               
                   
                 0 
                 1 
                 Indicates ERI-v (i.e., echo request with valid 
               
               
                   
                   
                   
                 payload) 
               
               
                   
                 1 
                 0 
                 Indicates ERI-d (i.e., echo request with a dummy 
               
               
                   
                   
                   
                 payload) 
               
               
                   
                 1 
                 1 
                 Indicates EAI (i.e., an echo ACK, no payload) 
               
               
                   
                   
               
            
           
         
       
     
     While the above example uses two bits in the GRE header to encode an echo request indicator (e.g., ERI-v or ERI-d), in other embodiments the IWF  135  and UE  205  may use different amounts of bits to communicate the echo request indicator. For example, a single bit in the GRE header may be used to indicate an echo request. Still further, the echo request indicator and/or echo acknowledgement indicator are not restricted to GRE headers, and in other embodiments there may be communicated in different encapsulation headers. 
       FIGS.  3 A- 3 C  depicts a second procedure  300  for measuring RTT of an access network, according to embodiments of the disclosure. In the second procedure  300 , the UE  205  takes its own RTT measurements and does not need to receive the RTT measured by the network. Note that the second procedure  300  primarily supports the Use Case 1 as the UE is aware of the RTT. The second procedure  300  involves a UE  205 , the IWF  135 , the UPF  143 , the AMF  145 , and the SMF  146 . Recall that the UPF  143  can send user traffic over either the 3GPP access or the non-3GPP access. 
     At  FIG.  3 A , the second procedure  300  begins with the UE  205  establishing one or more IPsec Security Associations (SAs) for NAS signaling with the IWF  135  (see communication  302 ). In some embodiments, the IWF  135  is an TNGF. In other embodiments, the IWF  135  is a N3IWF. 
     At step  1 , the UE  205  requests a PDU Session, e.g., by sending a PDU Session Establishment Request message (see message  304 ). In this message, the UE  205  includes an indication (e.g., the new indication “support GRE-based RTT measurements”) that shows it can support RTT measurements over non-3GPP access by using the techniques specified below, which utilizes the GRE protocol. 
     Based on the received PCC rules for the MA PDU Session, the SMF  146  determines (1) access steering rules for the UE  205  (e.g., ATSSS rules), and (2) access steering rules for the UPF  143  (see block  306 ). In addition, the SMF  146  determines what QoS flows should be established for the MA PDU Session and creates the associated QoS rules for the UE  205  and the associated QoS Enforcement Rules (QER) for the UPF  143 . 
     In the depicted embodiment, the SMF  146  determines that (1) RTT measurements need to be obtained by the UE  205  and UPF  143  in order to determine which access has the “smallest delay” and (2) the RTT measurements should be obtained by using 5QI-2, i.e. the same 5QI applied for App-2, which should be steered with the “smallest delay” steering mode. 
     At step  2 , the IWF  135  receives a PDU Session Resource Setup Request message  308 , which includes a PDU Session Establishment Accept message and a QoS Flow Setup Request List  310 , which includes a list of three different QoS flows, each one corresponding to one of the three PCC rules considered above. 
     Note that for the second QoS flow (identified by QFI-2), the SMF  146  includes the parameter RTT Report Request, discussed above, which indicates to the IWF  135  that it should measure the RTT over this QoS flow and it should report the measured RTT to the SMF  146  based on some reporting conditions. Note that the SMF  146  does not send the RTT Report Request parameter to the IWF  135  unless the UE  205  indicates it can “support GRE-based RTT measurements” (in step  1 ). 
     At step  3 , the IWF  135 , as normally, determines the number of child IPsec Security Associations (SAs) to be established, which one carrying one or more of the three QoS flows decided by the PCF for the MA PDU Session (see block  312 ). In the example depicted in  FIG.  3 A , the IWF  135  decides to establish two child IPsec SAs: the first carrying the traffic of QoS flow 1 and the traffic of QoS flow 2 (identified by QFI-1 and QFI-2 respectively), and the second carrying the traffic of QoS flow 3 (identified by QFI-3). 
     At step  4 , the IWF  135  sends messages to the UE  205  to establish the determined number of child IPsec SAs (see messaging  314  and  316 ). At step  5 , the IWF  135  forwards to the UE  205  the PDU Session Establishment Accept message received in step  2  (see messaging  318 ). Here, the UE  205  is also informed that it should take RTT measurements over the second QoS flow (QFI-2). This can be achieved by including either a new Information Element (IE) in the PDU Session Establishment Accept message, or by extending the existing Authorized QoS rules IE so that it can specify, not only the traffic that should be mapped to QFI-2, but only if RTT measurements should be taken using QFI-2. 
     At step  6 , the IWF  135  responds to the request received in the step  2  with a PDU Session Resource Setup Response message, indicating that the radio access resources for the PDU Session have been successfully established over non-3GPP access (see messaging  320 ). 
     At step  7 , the UE  205  and the UPF  143  may start user-plane (UP) communication over the non-3GPP access of the PDU Session (see blocks  322  and  324 ). In addition to user-plane communication, both the UE  205  and the IWF  135  may start RTT measurements over the second QoS flow (QFI-2). 
     Continuing at  FIG.  3 B , at step  8 , in the uplink (UL) direction, the UE  205  sends user-plane traffic (i.e. a series of PDU payloads) to the IWF  135  and encapsulates each PDU payload with GRE (see UL messages  326 ). As normally, the GRE header includes the QoS Flow Identifier (QFI) associated with the encapsulated PDU payload.  FIG.  3 B  shows only PDU payloads associated with QFI-2 for ease of illustration, however, PDU payloads associated with QFI-1 and QFI-3 will also be sent. The IWF  135  forwards every PDU payload received from the UE  205  to the UPF  143  over the N3 interface, which utilizes GTP-U encapsulation. 
     When the UE  205  wants to measure the RTT, the UE  205  includes an ERI indicator in the GRE header (either ERI-v or ERI-d, as discussed above with reference to  FIG.  2   ). At step  8   a , the UE  205  includes the ERI-v indicator. When the IWF  135  receives a GRE packet with the ERI in the header, it immediately responds with a GRE packet that contains an EAI (see block  327  and messaging  328 ). The UE  205  measures the RTT  330  by computing the time difference between the transmitted GRE packet with the ERI and the received GRE packet with the EAI. At step  9 , more PDU payloads are forwarded by the UE  205  to the IWF  135 , here without an ERI indicator (see messaging  332 ). 
     In the downlink (DL) direction, the UPF  143  sends user-plane traffic (i.e. a series of PDU payloads) to the IWF  135  over the N3 interface. In turn, the IWF  135  encapsulates these PDU payloads with GRE, and forwards them to the UE  205 . As normally, the GRE header includes the QoS Flow Identifier (QFI) associated with the encapsulated PDU payload. 
     However, at step  10  when the IWF  135  wants to measure the RTT  340 , the IWF  135  includes a new indicator in the GRE header, referred to as an Echo Request Indication (ERI) (see messaging  334 ). When the UE  205  receives a GRE packet with the ERI in the header, it immediately responds with a GRE packet that contains an Echo Ack Indicator (EAI) (see block  336  and messaging  338 ). This GRE packet does not contain a PDU payload; it is only an acknowledgment that aids the IWF  135  measure the current RTT between the UE  205  and IWF  135 . The IWF  135  measures the RTT  340  by computing the time difference between the transmitted GRE packet with the ERI and the received GRE packet with the EAI. As discussed above, not all DL traffic includes an ERI. At steps  11 - 12 , more PDU payloads are forwarded to the UE  205  from the IWF  135  without an ERI indicator (see messaging  342 ). 
     Although not depicted in  FIG.  3 B , the UE  205  may send a GRE packet with a dummy payload and the ERI-d indicator to the IWF  135  in order to take a RTT measurement when there is no UL traffic to deliver. Similarly, the IWF  135  may send a GRE packet with a dummy payload and the ERI-d indicator to the UE  205  in order to take a RTT measurement when there is no DL traffic to deliver. 
     Continuing at  FIG.  3 C , at step  20 , the UE  205  measures RTT (see block  344 ) and the IWF  135  measures RTT (see block  346 ), e.g., using the procedures described above. At step  20   b , the IWF  135  decides to report to SMF  146  the measured (and averaged) RTT (see block  348 ). Here the decision is made according to the reporting conditions in the received RTT Report Request parameter (see step  2 ). At step  21 , the IWF  135  sends to SMF  146 , via the AMF  145 , the measured (and averaged) RTT, e.g. within a PDU Session Resource Notify message (see messaging  350 ). Alternatively, the IWF  135  could send the measured RTT to UPF  143  and the UPF  143  may then forward it to SMF  146 . 
     In various embodiments, only the IWF  135  reports the RTT to the SMF  146 . This approach conserves radio resources by not requiring the UE  205  to report RTT to the SMF  146 . 
     At step  22 , the SMF  146  forwards the measured RTT received from the IWF  135  to the UPF  143  (see messaging  352 ). This step is only needed when, in step  21 , the IWF  135  sends the measured RTT to SMF  146  (i.e. it is not needed when, in step  21 , the IWF  135  sends the measured RTT to UPF  143 ). Note, however, that, in this case, the RTT over the N3 interface (between the IWF  135  and UPF  143 ) is not added. This is because the RTT received by the UPF  143  should be similar with the RTT calculated by the UE  205 , which does not include the RTT over the N3 interface. It is important that both the UE  205  and UPF  143  can take their traffic steering decisions based on similar RTT values. 
     If the UE  205  and UPF  143  need to know the RTT that characterizes the entire path between the UE  205  and UPF  143  over non-3GPP access (i.e., RTT between the UE  205  and the IWF  135  plus RTT over N3 interface), then they could increase the obtained RTT by a certain, fixed value. This value can be either preconfigured in the UE  205  and UPF  143  or could be signaled to UE  205  (e.g., in step  5 ) and to UPF  143  (e.g., in a step not shown in  FIGS.  4 A- 4 C ) during the PDU Session establishment procedure. 
       FIG.  4    depicts one embodiment of a user equipment apparatus  400  that may be used for measuring RTT, according to embodiments of the disclosure. The user equipment apparatus  400  may be one embodiment of the remote unit  105 . Furthermore, the user equipment apparatus  400  may include a processor  405 , a memory  410 , an input device  415 , an output device  420 , a transceiver  425 . In some embodiments, the input device  415  and the output device  420  are combined into a single device, such as a touch screen. In certain embodiments, the user equipment apparatus  400  does not include any input device  415  and/or output device  420 . 
     As depicted, the transceiver  425  includes at least one transmitter  430  and at least one receiver  435 . Here, the transceiver  425  communicates with a mobile core network (e.g., a 5GC) via an interworking function (e.g., TNGF or N3IWF) and over a non-3GPP access network. Additionally, the transceiver  425  may support at least one network interface  440 . Here, the at least one network interface  440  facilitates communication with an eNB or gNB (e.g., using the “Uu” interface). Additionally, the at least one network interface  440  may include an interface used for communications with an UPF, an SMF, and/or a P-CSCF. 
     The processor  405 , in one embodiment, may include any known controller capable of executing computer-readable instructions and/or capable of performing logical operations. For example, the processor  405  may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, the processor  405  executes instructions stored in the memory  410  to perform the methods and routines described herein. The processor  405  is communicatively coupled to the memory  410 , the input device  415 , the output device  420 , and the transceiver  425 . 
     In various embodiments, the processor  405  transmits a first request to establish a data connection between the apparatus and the mobile core network, wherein the first request includes a first indicator that the apparatus supports RTT measurements, the RTT measurements calculated using messages transmitted via the data connection and using an encapsulation header. The processor  405  receives a first message from the interworking function and transmits a second message to the interworking function, wherein the first message includes a first encapsulation header (e.g., a GRE header) comprising an echo request indication and the second message includes a second encapsulation header (e.g., a GRE header) comprising an echo response indication (e.g., an Echo Ack indication). 
     In some embodiments, the processor  405  further receives a first notification from the mobile core network (e.g., a DL NAS Transport message), wherein the first notification comprises an average RTT derived based on RTT measurements calculated by the interworking function. For example, the average RTT may be calculated by combining the RTT measurements calculated by the interworking function with an average RTT for the path between the interworking function and a user-plane function in the mobile core network. 
     In some embodiments, the first message contains a dummy PDU. In such embodiments, the processor  405  sends the second message while ignoring the dummy PDU. In some embodiments, the first message comprises a downlink PDU sent by a user-plane function in the mobile core network via the interworking function. In such embodiments, the downlink PDU is encapsulated by the first encapsulation header. 
     In various embodiments, the first encapsulation header is a packet header complying with the General Routing Encapsulation (“GRE”) protocol. In some embodiments, the echo request indication comprises a set of bits in the GRE header. In one embodiment, the set of bits comprises a single bit. In other embodiments, the set of bits comprises multiple bits. 
     In certain embodiments, the echo request indication uses a first value to indicate that a packet payload associated with the GRE header contains a PDU received from the mobile core network and uses a second value to indicate that the packet payload contains dummy PDU that is to be ignored. In such embodiments, the second encapsulation header also may be a packet header complying with the GRE protocol, with the echo response indication comprising a set of bits in the GRE header. In such embodiments, the echo response indication may use a third value to acknowledge the echo request. 
     In some embodiments, the processor  405  further transmits a third message to the interworking function by using the first QoS flow of the data connection, wherein the third message includes the first encapsulation header (e.g., GRE header) comprising a second echo request indication. Here, the processor  405  may receive a fourth message from the interworking function and measure the RTT for a first QoS flow of the data connection using the echo response indication, wherein the fourth message includes the second encapsulation header (e.g., GRE header) comprising a second echo response indication (e.g., an Echo Ack indication). In some such embodiments, the third message contains a dummy PDU, wherein the interworking function sends the fourth message while ignoring the dummy PDU. In other embodiments, the third message contains an uplink PDU encapsulated by the first encapsulation header, wherein the uplink PDU is to be forwarded to the mobile core network via the interworking function. 
     The memory  410 , in one embodiment, is a computer readable storage medium. In some embodiments, the memory  410  includes volatile computer storage media. For example, the memory  410  may include a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/or static RAM (“SRAM”). In some embodiments, the memory  410  includes non-volatile computer storage media. For example, the memory  410  may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory  410  includes both volatile and non-volatile computer storage media. In some embodiments, the memory  410  stores data relating to measuring RTT, for example storing a transmission table, and the like. In certain embodiments, the memory  410  also stores program code and related data, such as an operating system (“OS”) or other controller algorithms operating on the user equipment apparatus  400  and one or more software applications. 
     The input device  415 , in one embodiment, may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like. In some embodiments, the input device  415  may be integrated with the output device  420 , for example, as a touchscreen or similar touch-sensitive display. In some embodiments, the input device  415  includes a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and/or by handwriting on the touchscreen. In some embodiments, the input device  415  includes two or more different devices, such as a keyboard and a touch panel. 
     The output device  420 , in one embodiment, may include any known electronically controllable display or display device. The output device  420  may be designed to output visual, audible, and/or haptic signals. In some embodiments, the output device  420  includes an electronic display capable of outputting visual data to a user. For example, the output device  420  may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or similar display device capable of outputting images, text, or the like to a user. As another, non-limiting, example, the output device  420  may include a wearable display such as a smart watch, smart glasses, a heads-up display, or the like. Further, the output device  420  may be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like. 
     In certain embodiments, the output device  420  includes one or more speakers for producing sound. For example, the output device  420  may produce an audible alert or notification (e.g., a beep or chime). In some embodiments, the output device  420  includes one or more haptic devices for producing vibrations, motion, or other haptic feedback. In some embodiments, all or portions of the output device  420  may be integrated with the input device  415 . For example, the input device  415  and output device  420  may form a touchscreen or similar touch-sensitive display. In other embodiments, all or portions of the output device  420  may be located near the input device  415 . 
     As discussed above, the transceiver  425  communicates with one or more network functions of a mobile communication network via one or more access networks. The transceiver  425  operates under the control of the processor  405  to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor  405  may selectively activate the transceiver (or portions thereof) at particular times in order to send and receive messages. The transceiver  425  may include one or more transmitters  430  and one or more receivers  435 . In certain embodiments, the one or more transmitters  430  and/or the one or more receivers  435  may share transceiver hardware and/or circuitry. For example, the one or more transmitters  430  and/or the one or more receivers  435  may share antenna(s), antenna tuner(s), amplifier(s), filter(s), oscillator(s), mixer(s), modulator/demodulator(s), power supply, and the like. 
     In various embodiments, the transceiver  425  is configured to communication with 3GPP access network(s)  120  and the non-3GPP access network(s)  130 . In some embodiments, the transceiver  425  implements modem functionality for the 3GPP access network(s)  120  and/or the non-3GPP access network(s)  130 . In one embodiment, the transceiver  425  implements multiple logical transceivers using different communication protocols or protocol stacks, while using common physical hardware. For example, the transceiver  425  may include one application-specific integrated circuit (“ASIC”) which includes the function of first transceiver and second transceiver for accessing different networks. In other embodiments, the transceiver  425  comprises separate transceivers for the 3GPP access network(s) and for the non-3GPP access network(s). 
       FIG.  5    depicts one embodiment of a network equipment apparatus  500  that may be used for measuring RTT, according to embodiments of the disclosure. The network equipment apparatus  500  may be one embodiment of the IWF  135 , such as a TNGF or a N3IWF. Furthermore, network equipment apparatus  500  may include a processor  505 , a memory  510 , an input device  515 , an output device  520 , a transceiver  525 . In some embodiments, the input device  515  and the output device  520  are combined into a single device, such as a touch screen. In certain embodiments, the network equipment apparatus  500  does not include any input device  515  and/or output device  520 . 
     As depicted, the transceiver  525  includes at least one transmitter  530  and at least one receiver  535 . Here, the transceiver  525  communicates with one or more remote units  105  and with one or more interworking functions  135  that provide access to one or more PLMNs Additionally, the transceiver  525  may support at least one network interface  540 . In some embodiments, the transceiver  525  supports a first interface (e.g., an N2 interface) that communicates with control-plane functions (e.g., SMF) in a mobile core network (e.g., a 5GC) and a second interface that communicates with a remote unit (e.g., UE) over a non-3GPP access network. 
     The processor  505 , in one embodiment, may include any known controller capable of executing computer-readable instructions and/or capable of performing logical operations. For example, the processor  505  may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, the processor  505  executes instructions stored in the memory  510  to perform the methods and routines described herein. The processor  505  is communicatively coupled to the memory  510 , the input device  515 , the output device  520 , and the first transceiver  525 . 
     In various embodiments, the processor  505  receives a request via the first interface to establish access resources for enabling data communication between the remote unit and the mobile core network via a data connection. Here, the data connection supports a plurality of QoS flows and the request includes a first indicator (e.g., a RTT Report Request) that requests RTT measurements using a first QoS flow. The processor  505  transmits a first message to the remote unit via the second interface and using the first QoS flow of the data connection, wherein the first message includes a first encapsulation header (e.g., GRE header) comprising an echo request indication. The processor  505  receives a second message via the second interface, wherein the second message includes a second encapsulation header (e.g., GRE header) comprising an echo response indication (e.g., an Echo Ack indication) and measures the RTT for the first QoS flow of the data connection using the echo response indication. 
     In some embodiments, the processor  505  further determines whether an average RTT meets a reporting condition and transmits a first notification via the first interface in response to the average RTT meeting the reporting condition. In such embodiments, the average RTT may be based on the measured RTT. In certain embodiments, the processor  505  determines whether an average RTT meets a reporting condition by evaluating the one or more reporting conditions included in the first indicator. In further embodiments, the processor  505  may forward via the second interface a second notification received via the first interface, wherein the second notification comprises the average RTT. 
     In some embodiments, the network equipment apparatus  500  supports a third interface (e.g., N3) that communicates with a UPF in the mobile core network (e.g., UPF  143 ). Here, the first message may contain a PDU received via the third interface. In some embodiments, the first message contains a dummy PDU. In such embodiments, the remote unit sends the second message while ignoring the dummy PDU. In certain embodiments, the processor  505  determines whether an average RTT meets a reporting condition and controls the transceiver  525  to transmit a notification via the third interface in response to the average RTT meeting the reporting condition, wherein the average RTT is based on the measured RTT. Note that the UPF may forward the reported average RTT to the SMF. In one embodiment, the UPF adds the RTT of the third interface (e.g., N3 interface) to the RTT (e.g., RAN-RTT) reported by the network equipment apparatus  500 . 
     In some embodiments, the first encapsulation header is a packet header complying with the General Routing Encapsulation (“GRE”) protocol. In certain embodiments, the first message includes the GRE header comprising the echo request indication in response to receiving the first indicator requesting RTT measurements. In certain embodiments, the echo request indication comprises a set of bits in the GRE header. In one embodiment, the set of bits comprises a single bit. In other embodiments, the set of bits comprises multiple bits. 
     In various embodiments, the echo request indication uses a first value to indicate that a packet payload associated with the GRE header contains a PDU received via the third interface and uses a second value to indicate that the packet payload contains dummy PDU that is to be ignored by the remote unit. 
     In some embodiments, the second encapsulation header is a packet header complying with the GRE protocol, wherein the echo response indication comprises a set of bits in the GRE header. In one embodiment, the echo response indication comprises a single bit within the GRE header. In other embodiments, the echo response indication comprises multiple bits within the GRE header. In various embodiments, the echo response indication uses a third value to acknowledge the echo request. 
     In some embodiments, the processor  505  receives a third message from the remote unit via the second interface by using the first QoS flow of the data connection. Here, the third message includes the first encapsulation header (e.g., GRE header) comprising a second echo request indication. The processor  505  also transmits a fourth message via the second interface. Here, the fourth message includes the second encapsulation header (e.g., GRE header) comprising a second echo response indication (e.g., an Echo Ack indication), wherein the remote unit measures the RTT for the first QoS flow of the data connection using the echo response indication. 
     In certain embodiments, the third message contains a dummy PDU encapsulated by the first encapsulation header. In such embodiments, the processor  505  sends the fourth message while ignoring the dummy PDU. In certain embodiments, the third message contains an uplink PDU encapsulated by the first encapsulation header. In such embodiments, the processor  505  may send the fourth message and forward the uplink PDU to the mobile core network via the third interface. 
     The memory  510 , in one embodiment, is a computer readable storage medium. In some embodiments, the memory  510  includes volatile computer storage media. For example, the memory  510  may include a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/or static RAM (“SRAM”). In some embodiments, the memory  510  includes non-volatile computer storage media. For example, the memory  510  may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory  510  includes both volatile and non-volatile computer storage media. In some embodiments, the memory  510  stores data relating to measuring RTT, for example storing a transmission table, and the like. In certain embodiments, the memory  510  also stores program code and related data, such as an operating system (“OS”) or other controller algorithms operating on the network equipment apparatus  500  and one or more software applications. 
     The input device  515 , in one embodiment, may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like. In some embodiments, the input device  515  may be integrated with the output device  520 , for example, as a touchscreen or similar touch-sensitive display. In some embodiments, the input device  515  includes a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and/or by handwriting on the touchscreen. In some embodiments, the input device  515  includes two or more different devices, such as a keyboard and a touch panel. 
     The output device  520 , in one embodiment, may include any known electronically controllable display or display device. The output device  520  may be designed to output visual, audible, and/or haptic signals. In some embodiments, the output device  520  includes an electronic display capable of outputting visual data to a user. For example, the output device  520  may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or similar display device capable of outputting images, text, or the like to a user. As another, non-limiting, example, the output device  520  may include a wearable display such as a smart watch, smart glasses, a heads-up display, or the like. Further, the output device  520  may be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like. 
     In certain embodiments, the output device  520  includes one or more speakers for producing sound. For example, the output device  520  may produce an audible alert or notification (e.g., a beep or chime). In some embodiments, the output device  520  includes one or more haptic devices for producing vibrations, motion, or other haptic feedback. In some embodiments, all or portions of the output device  520  may be integrated with the input device  515 . For example, the input device  515  and output device  520  may form a touchscreen or similar touch-sensitive display. In other embodiments, all or portions of the output device  520  may be located near the input device  515 . 
     As discussed above, the transceiver  525  may communicate with one or more remote units and/or with one or more interworking functions that provide access to one or more PLMNs. The transceiver  525  may also communicate with one or more network functions (e.g., in the mobile core network  140 ). The transceiver  525  operates under the control of the processor  505  to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor  505  may selectively activate the transceiver (or portions thereof) at particular times in order to send and receive messages. 
     The transceiver  525  may include one or more transmitters  530  and one or more receivers  535 . In certain embodiments, the one or more transmitters  530  and/or the one or more receivers  535  may share transceiver hardware and/or circuitry. For example, the one or more transmitters  530  and/or the one or more receivers  535  may share antenna(s), antenna tuner(s), amplifier(s), filter(s), oscillator(s), mixer(s), modulator/demodulator(s), power supply, and the like. In one embodiment, the transceiver  525  implements multiple logical transceivers using different communication protocols or protocol stacks, while using common physical hardware. 
       FIG.  6    depicts a method  600  for measuring RTT, according to embodiments of the disclosure. In some embodiments, the method  600  is performed by an apparatus, such as the interworking function  135  and/or the network equipment apparatus  500 . In certain embodiments, the method  600  may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like. 
     The method  600  begins with supporting  605  a first interface (e.g., an N2 interface) that communicates with control-plane functions in a mobile core network (e.g., a 5GC) and a second interface that communicates with a remote unit over a non-3GPP access network. 
     The method  600  includes receiving  610  a request via the first interface to establish access resources for enabling data communication between the remote unit and the mobile core network via a data connection. Here, the data connection supports a plurality of QoS flows and the request includes a first indicator (e.g., a RTT Report Request) that requests RTT measurements using a first QoS flow. 
     The method  600  includes transmitting  615  a first message to the remote unit via the second interface and using the first QoS flow of the data connection, wherein the first message includes a first encapsulation header (e.g., GRE header) comprising an echo request indication. 
     The method  600  includes receiving  620  a second message via the second interface, wherein the second message includes a second encapsulation header (e.g., GRE header) comprising an echo response indication (e.g., an Echo Ack indication). 
     The method  600  includes measuring  625  the RTT for the first QoS flow of the data connection using the echo response indication. The method  600  ends. 
       FIG.  7    depicts a method  700  for measuring RTT, according to embodiments of the disclosure. In some embodiments, the method  700  is performed by an apparatus, such as the remote unit  105 , the UE  205 , and/or the user equipment apparatus  400 . In certain embodiments, the method  700  may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like. 
     The method  700  begins and communicates  705  with an access network, the access network connected to a mobile core network (e.g., a 5GC) via an interworking function (e.g., TNGF or N3IWF). 
     The method  700  includes transmitting  710  a first request to establish a data connection between the remote unit and the mobile core network. Here, the first request includes a first indicator that the remote unit supports RTT measurements calculated using messages transmitted via the data connection and using an encapsulation header. 
     The method  700  includes receiving  715  a first message from the interworking function. Here, the first message includes a first encapsulation header (e.g., a GRE header) comprising an echo request indication. 
     The method  700  includes transmitting  720  a second message to the interworking function. Here, the second message includes a second encapsulation header (e.g., a GRE header) comprising an echo response indication (e.g., an Echo Ack indication). The method  700  ends. 
     Disclosed herein is a first apparatus for measuring RTT, according to embodiments of the disclosure. The first apparatus may be implemented by an interworking function, such as a TNGF or N3IWF. The first apparatus includes a first interface (e.g., an N2 interface) that communicates with control-plane functions in a mobile core network (e.g., a 5GC) and a second interface that communicates with a remote unit over a non-3GPP access network. The first apparatus includes a processor that receives a request via the first interface to establish access resources for enabling data communication between the remote unit and the mobile core network via a data connection. Here, the data connection supports a plurality of QoS flows and the request includes a first indicator (e.g., a RTT Report Request) that requests RTT measurements using a first QoS flow. The processor transmits a first message to the remote unit via the second interface and using the first QoS flow of the data connection, wherein the first message includes a first encapsulation header (e.g., GRE header) comprising an echo request indication. The processor receives a second message via the second interface, wherein the second message includes a second encapsulation header (e.g., GRE header) comprising an echo response indication (e.g., an Echo Ack indication) and measures the RTT for the first QoS flow of the data connection using the echo response indication. 
     In some embodiments, the processor further determines whether an average RTT meets a reporting condition and transmits a first notification via the first interface in response to the average RTT meeting the reporting condition. In such embodiments, the average RTT may be based on the measured RTT. In certain embodiments, the processor determines whether an average RTT meets a reporting condition by evaluating the one or more reporting conditions included in the first indicator. In further embodiments, the processor may forward via the second interface a second notification received via the first interface, wherein the second notification comprises the average RTT. 
     In some embodiments, the apparatus includes a third interface (e.g., N3) that communicates with a user-plane function in the mobile core network. Here, the first message may contain a PDU received via the third interface. In some embodiments, the first message contains a dummy PDU. In such embodiments, the remote unit sends the second message while ignoring the dummy PDU. In certain embodiments, the processor determines whether an average RTT meets a reporting condition and transmits a notification via the third interface in response to the average RTT meeting the reporting condition, wherein the average RTT is based on the measured RTT. 
     In some embodiments, the first encapsulation header is a packet header complying with the General Routing Encapsulation (“GRE”) protocol. In certain embodiments, the first message includes the GRE header comprising the echo request indication in response to receiving the first indicator requesting RTT measurements. In certain embodiments, the echo request indication comprises a set of bits in the GRE header. In one embodiment, the set of bits comprises a single bit. In other embodiments, the set of bits comprises multiple bits. 
     In various embodiments, the echo request indication uses a first value to indicate that a packet payload associated with the GRE header contains a PDU received via the third interface and uses a second value to indicate that the packet payload contains dummy PDU that is to be ignored by the remote unit. 
     In some embodiments, the second encapsulation header is a packet header complying with the GRE protocol, wherein the echo response indication comprises a set of bits in the GRE header. In one embodiment, the echo response indication comprises a single bit within the GRE header. In other embodiments, the echo response indication comprises multiple bits within the GRE header. In various embodiments, the echo response indication uses a third value to acknowledge the echo request. 
     In some embodiments, the processor receives a third message from the remote unit via the second interface by using the first QoS flow of the data connection. Here, the third message includes the first encapsulation header (e.g., GRE header) comprising a second echo request indication. The processor also transmits a fourth message via the second interface. Here, the fourth message includes the second encapsulation header (e.g., GRE header) comprising a second echo response indication (e.g., an Echo Ack indication), wherein the remote unit measures the RTT for the first QoS flow of the data connection using the echo response indication. 
     In certain embodiments, the third message contains a dummy PDU encapsulated by the first encapsulation header. In such embodiments, the processor sends the fourth message while ignoring the dummy PDU. In certain embodiments, the third message contains an uplink PDU encapsulated by the first encapsulation header. In such embodiments, the processor may send the fourth message and forward the uplink PDU to the mobile core network via the third interface. In various embodiments, the processor further receives a measurement parameter via the first interface, wherein the measurement parameter indicates a frequency for measuring RTT. 
     Disclosed herein is a first method for measuring RTT, according to embodiments of the disclosure. The first method may be performed by an interworking function, such as a TNGF or N3IWF. The first method includes supporting a first interface (e.g., an N2 interface) that communicates with control-plane functions in a mobile core network (e.g., a 5GC) and a second interface that communicates with a remote unit over a non-3GPP access network. The first method includes receiving a request via the first interface to establish access resources for enabling data communication between the remote unit and the mobile core network via a data connection. Here, the data connection supports a plurality of QoS flows and the request includes a first indicator (e.g., a RTT Report Request) that requests RTT measurements using a first QoS flow. The first method includes transmitting a first message to the remote unit via the second interface and using the first QoS flow of the data connection, wherein the first message includes a first encapsulation header (e.g., GRE header) comprising an echo request indication. The first method includes receiving a second message via the second interface, wherein the second message includes a second encapsulation header (e.g., GRE header) comprising an echo response indication (e.g., an Echo Ack indication). The first method includes measuring the RTT for the first QoS flow of the data connection using the echo response indication. 
     In some embodiments, the first method includes determining whether an average RTT meets a reporting condition and transmitting a first notification via the first interface in response to the average RTT meeting the reporting condition. In such embodiments, the average RTT may be based on the measured RTT. In certain embodiments, determining whether the average RTT meets a reporting condition includes evaluating the one or more reporting conditions included in the first indicator. In further embodiments, the first method may include forwarding via the second interface a second notification received via the first interface, wherein the second notification comprises the average RTT. 
     In some embodiments, the first method includes supporting a third interface (e.g., N3) that communicates with a user-plane function in the mobile core network. Here, the first message may contain a PDU received via the third interface. In some embodiments, the first message contains a dummy PDU. In such embodiments, the remote unit sends the second message while ignoring the dummy PDU. In certain embodiments, the first method includes determining whether an average RTT meets a reporting condition and transmitting a notification via the third interface in response to the average RTT meeting the reporting condition, wherein the average RTT is based on the measured RTT. 
     In some embodiments, the first encapsulation header is a packet header complying with the General Routing Encapsulation (“GRE”) protocol. In certain embodiments, the first message includes the GRE header comprising the echo request indication in response to receiving the first indicator requesting RTT measurements. In certain embodiments, the echo request indication comprises a set of bits in the GRE header. In one embodiment, the set of bits comprises a single bit. In other embodiments, the set of bits comprises multiple bits. 
     In various embodiments, the echo request indication uses a first value to indicate that a packet payload associated with the GRE header contains a PDU received via the third interface and uses a second value to indicate that the packet payload contains dummy PDU that is to be ignored by the remote unit. 
     In some embodiments, the second encapsulation header is a packet header complying with the GRE protocol, wherein the echo response indication comprises a set of bits in the GRE header. In one embodiment, the echo response indication comprises a single bit within the GRE header. In other embodiments, the echo response indication comprises multiple bits within the GRE header. In various embodiments, the echo response indication uses a third value to acknowledge the echo request. 
     In some embodiments, the first method includes receiving a third message from the remote unit via the second interface by using the first QoS flow of the data connection. Here, the third message includes the first encapsulation header (e.g., GRE header) comprising a second echo request indication. The first method may also include transmitting a fourth message via the second interface. Here, the fourth message includes the second encapsulation header (e.g., GRE header) comprising a second echo response indication (e.g., an Echo Ack indication), wherein the remote unit measures the RTT for the first QoS flow of the data connection using the echo response indication. 
     In certain embodiments, the third message contains a dummy PDU encapsulated by the first encapsulation header. In such embodiments, transmitting the fourth message comprises sending the fourth message while ignoring the dummy PDU. In certain embodiments, the third message contains an uplink PDU encapsulated by the first encapsulation header. In such embodiments, the first method may include forwarding the uplink PDU to the mobile core network via the third interface in response to receiving the third message. In various embodiments, the first method includes receiving a measurement parameter via the first interface, wherein the measurement parameter indicates a frequency for measuring RTT. 
     Disclosed herein is a second apparatus for measuring RTT, according to embodiments of the disclosure. The second apparatus may be implemented by a remote unit, such as a UE. The second apparatus includes a transceiver that communicates with a mobile core network (e.g., a 5GC) via an interworking function (e.g., TNGF or N3IWF) and over a non-3GPP access network. The second apparatus includes a processor that transmits a first request to establish a data connection between the apparatus and the mobile core network, wherein the first request includes a first indicator that the apparatus supports RTT measurements, the RTT measurements calculated using messages transmitted via the data connection and using an encapsulation header. The processor receives a first message from the interworking function and transmits a second message to the interworking function, wherein the first message includes a first encapsulation header (e.g., a GRE header) comprising an echo request indication and the second message includes a second encapsulation header (e.g., a GRE header) comprising an echo response indication (e.g., an Echo Ack indication). 
     In some embodiments, the processor further receives a first notification from the mobile core network (e.g., a DL NAS Transport message), wherein the first notification comprises an average RTT derived based on RTT measurements calculated by the interworking function. For example, the average RTT may be calculated by combining the RTT measurements calculated by the interworking function with an average RTT for the path between the interworking function and a user-plane function in the mobile core network. 
     In some embodiments, the first message contains a dummy PDU. In such embodiments, the processor sends the second message while ignoring the dummy PDU. In some embodiments, the first message comprises a downlink PDU sent by a user-plane function in the mobile core network via the interworking function. In such embodiments, the downlink PDU is encapsulated by the first encapsulation header. 
     In various embodiments, the first encapsulation header is a packet header complying with the General Routing Encapsulation (“GRE”) protocol. In some embodiments, the echo request indication comprises a set of bits in the GRE header. In one embodiment, the set of bits comprises a single bit. In other embodiments, the set of bits comprises multiple bits. 
     In certain embodiments, the echo request indication uses a first value to indicate that a packet payload associated with the GRE header contains a PDU received from the mobile core network and uses a second value to indicate that the packet payload contains dummy PDU that is to be ignored. In such embodiments, the second encapsulation header also may be a packet header complying with the GRE protocol, with the echo response indication comprising a set of bits in the GRE header. In such embodiments, the echo response indication may use a third value to acknowledge the echo request. 
     In some embodiments, the processor further transmits a third message to the interworking function by using the first QoS flow of the data connection, wherein the third message includes the first encapsulation header (e.g., GRE header) comprising a second echo request indication. Here, the processor may receive a fourth message from the interworking function and measure the RTT for a first QoS flow of the data connection using the echo response indication, wherein the fourth message includes the second encapsulation header (e.g., GRE header) comprising a second echo response indication (e.g., an Echo Ack indication). In some such embodiments, the third message contains a dummy PDU, wherein the interworking function sends the fourth message while ignoring the dummy PDU. In other embodiments, the third message contains an uplink PDU encapsulated by the first encapsulation header, wherein the uplink PDU is to be forwarded to the mobile core network via the interworking function. 
     Disclosed herein is a second method for measuring RTT, according to embodiments of the disclosure. The second method may be performed by a remote unit, such as a UE. The second method includes communicating with an access network, the access network connected to a mobile core network (e.g., a 5GC) via an interworking function (e.g., TNGF or N3IWF). The second method includes transmitting a first request to establish a data connection between the remote unit and the mobile core network. Here, the first request includes a first indicator that the remote unit supports RTT measurements calculated using messages transmitted via the data connection and using an encapsulation header. The second method includes receiving a first message from the interworking function. Here, the first message includes a first encapsulation header (e.g., a GRE header) comprising an echo request indication. The second method includes transmitting a second message to the interworking function. Here, the second message includes a second encapsulation header (e.g., a GRE header) comprising an echo response indication (e.g., an Echo Ack indication). 
     In some embodiments, the second method includes receiving a first notification from the mobile core network (e.g., a DL NAS Transport message), wherein the first notification comprises an average RTT derived based on RTT measurements calculated by the interworking function. For example, the average RTT may be calculated by combining the RTT measurements calculated by the interworking function with an average RTT for the path between the interworking function and a user-plane function in the mobile core network. 
     In some embodiments, the first message contains a dummy PDU. In such embodiments, the second method includes sending the second message while ignoring the dummy PDU. In some embodiments, the first message comprises a downlink PDU sent by a user-plane function in the mobile core network via the interworking function. In such embodiments, the downlink PDU is encapsulated by the first encapsulation header. 
     In various embodiments, the first encapsulation header is a packet header complying with the General Routing Encapsulation (“GRE”) protocol. In some embodiments, the echo request indication comprises a set of bits in the GRE header. In one embodiment, the set of bits comprises a single bit. In other embodiments, the set of bits comprises multiple bits. 
     In certain embodiments, the echo request indication uses a first value to indicate that a packet payload associated with the GRE header contains a PDU received from the mobile core network and uses a second value to indicate that the packet payload contains dummy PDU that is to be ignored. In such embodiments, the second encapsulation header also may be a packet header complying with the GRE protocol, with the echo response indication comprising a set of bits in the GRE header. In such embodiments, the echo response indication may use a third value to acknowledge the echo request. 
     In some embodiments, the second method includes transmitting a third message to the interworking function by using the first QoS flow of the data connection, wherein the third message includes the first encapsulation header (e.g., GRE header) comprising a second echo request indication. Here, the second method may include receiving a fourth message from the interworking function and measuring the RTT for a first QoS flow of the data connection using the echo response indication, wherein the fourth message includes the second encapsulation header (e.g., GRE header) comprising a second echo response indication (e.g., an Echo Ack indication). In some such embodiments, the third message contains a dummy PDU, wherein the interworking function sends the fourth message while ignoring the dummy PDU. In other embodiments, the third message contains an uplink PDU encapsulated by the first encapsulation header, wherein the uplink PDU is to be forwarded to the mobile core network via the interworking function. 
     Embodiments may be practiced in other specific forms. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.