Patent Description:
The Two-Way Active Measurement Protocol (TWAMP) defines two-way or roundtrip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles: a control client and a server. A common distribution of functions between the two hosts is illustrated in <FIG>, which illustrates a logical distribution of functionalities between TWAMP hosts, such as control client <NUM> and a server <NUM>. In certain aspects, the control-client <NUM> requests, and in some instances describes, a test session with a unique TWAMP-Control message. The server <NUM> responds with its acceptance and supporting information. More than one test session may be requested with additional messages. Typically, the control-client initiates all requested testing with a start-sessions message, and the server <NUM> acknowledges. The session-sender <NUM> and the session-reflector <NUM> can exchange test packets according to the TWAMP-Test protocol for each active session.

<CIT> discloses a method for measuring asymmetry in propagation delay of first and second links which connect a first node to a second node of a communications network. <CIT> discloses user performance adaptation to ensure fairness when relative performance between users exceeds a threshold disparity.

There currently exist certain challenges. For instance, current quality of service (QoS) measurements and decisions are largely made within the telecommunications infrastructure, which can leave the end-user out of the process.

Accordingly, in some embodiments, a method is provided that is performed by a user equipment (UE) for active network measurement. The method comprises sending one or more first test packets to a node, wherein the first test packets are not boosted; receiving one or more first reflected packets from the node; calculating preliminary results based at least in part on the received first reflected packets; sending one or more second test packets to the node, wherein the second test packets are boosted; receiving one or more second reflected packets from the node; and calculating test results based at least in part on the received second reflected packets and the preliminary results. In some embodiments, the method further comprises performing a QoS determination, a QoS request, or QoS reporting operation based at least in part on the test results. In some embodiments, the preliminary results comprise one or more time or delay values. The one or more time or delay values may be calculated based at least in part on timestamps of the received first reflected packets. The UE may be, for example, an end-user device connected to one or more of a cellular or wide area network, WAN, data path. In embodiments, the node may comprise a test head module.

According to embodiments, a method performed by a node is provided. The method may comprise receiving and reflecting one or more first test packets from an end-user device, wherein the first test packets are not boosted; receiving and reflecting one or more second test packets from an end-user device, wherein the second test packets are boosted; and receiving a message from the end-user device indicating one or more of a QoS test result, QoS determination, QoS request, or a boost request based at least in part on the first and second test packets. In some embodiments, the node comprises a test head.

According to embodiments, an apparatus, such as a UE, network node (e.g., comprising a test head), or host, is provided that is configured to perform one or more of the methods. For example, an apparatus may comprise a receiver/transmitter and a processor, wherein the processor is configured to perform one or more of the methods. In some embodiments, the apparatus may comprise various combinations of hardware and/or software, such as a server (e.g., a cloud-implemented or distributed server) or a virtual machine, container, or other processing resources configured to provide one or more services to one or more UEs.

According to embodiments, a computer program is provided that comprises instructions that when executed by processing circuitry of an apparatus causes the apparatus to perform one or more of the methods. The program can be contained on a carrier, where the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium.

Certain aspects of the disclosure and the described embodiments may provide solutions to one or more challenges, such as inclusion of the end user in QoS measurement and decision making, as well as improved use of active measurements. For instance, aspects of the disclosure and their embodiments may be built on top of existing active measurement technology, leveraging active measurements to output a recommendation and/or action to the end-user device. In particular, aspects of the disclosure and their embodiments can provide a mechanism to take active measurements over the <NUM>/<NUM> air interface in order to determine in real time if one or multiple designated traffic flows can benefit from a QoS upgrade. While the air interface is used as an example, embodiments may be applied in other networks, including a wireless access network (WAN) or other data path(s).

According to embodiments, a real time evaluation engine is provided that allows an end user to control and explicitly request a QoS boost when it is needed or available. In order to enable such capability, the engine processes measurements and outputs an estimation on whether a boost of a particular traffic flow can help improve the user's quality of experience. The measurements may be, for example, obtained from running TWAMP. In certain aspects, such evaluation can occur periodically, for instance, at a rate that can be pre-configured at the backend. In some situations, the boost cannot improve the overall performance because of additional parameters that are not affected when a boost is implemented. However, when a boost is considered useful, a signaling messages flow can take place between the end user device requesting the boost and a network exposure function (NEF). On the user's device, the signaling messages may be generated by a specialized agent. For example, when implemented on The One Network (TON), it may be referred to as a TON agent.

In some embodiments, a configurable number of active measurement packets (e.g., TWAMP packets) are sent first in an un-boosted state, and then, the same number of packets are sent in a boosted state. If a difference is detected it can be attributed to congestion in the cellular network default bearer (or other measured path). This can indicate that a boost of application traffic from the device would be effective in decreasing packet latency. Aspects of the disclosure leverage QoS management capabilities exposed by a 3GPP interface (e.g., T8), where packets are sent from a client mobile device to a reflector service running in the public cloud. In this respect, certain aspects of measurement protocol run "over the top" where the network is not necessarily aware of the test taking place.

Certain embodiments may provide technical advantages, including real-time (e.g., continuous) evaluation of whether a boost or other service upgrade is beneficial over one or more radio interfaces. Additional advantages may include that the clocks on the client and reflector (e.g., a UE and test head) do not need to be synchronized. In certain aspects, a boost adds a new dimension for detecting congestion in the cellular domain. This may comprise, for example, comparing default congestion or time values (e.g., with standard QoS class identifiers or <NUM>/<NUM> QoS identifiers (QCI/5QI)) with non-default values (e.g., with improved Guaranteed Bit Rate (GBR) or non-Guaranteed Bit Rate (non-GBR) values based on improved priority).

Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

According to embodiments, a mechanism is provided with respect to two endpoints. One end point may be, for instance, an end-user device (e.g., iOS, Android, or other device) connected to a network (e.g., a <NUM>/<NUM> network). The device may be running an agent, such as a software developer kit (SDK), or other dedicated agent, with a TWAMP control-client and comprising a session-sender. The second end point may be, for instance, a test head module (e.g., implemented in software). For example, it may be a TON test head. This may be running in the cloud alongside specific types of apps servers, such as gaming apps, where the test head runs or otherwise comprises a TWAMP server and/or a session-reflector.

An overview of an architecture that may be used according to embodiments is provided in <FIG>. In this example, an active measurement <NUM> is performed between a user device <NUM> and a test head <NUM>. The active measurement <NUM> may be, according to embodiments, a boost enhanced active measurement (BEAM). The user device <NUM> may be, for example, a UE running an iOS or Android platform. In certain aspects, the device may have one or more of a software development kit (SDK) <NUM>, a Domain Name System (DNS) module <NUM>, and/or modules for one or more TCP/IP protocols <NUM>. Additionally, aspects of user device <NUM> may be implemented in firmware <NUM>, hardware <NUM>, or both. The test head <NUM> may be in cloud <NUM>, and in some embodiments, is running alongside one or more applications <NUM>. In some embodiments, application <NUM> is accessed by a user of user device <NUM> (e.g., the user is connecting to application <NUM> or using one or more of its services). The user device <NUM> may be used by a portal user <NUM> accessing a portal <NUM>.

According to embodiments, a user may be accessing an application <NUM>, or other node or service, via a data path <NUM>. In this example, the portion 208a is boostable while portion 208b is not boostable. In certain aspects, a QoS on data path 208a can be improved by request from the user device while the QoS on data path 208b cannot be improved in such a manner. Additionally, in this example, the 208a data path is in the cellular domain <NUM> and the 208b data path is in the WAN domain <NUM>. Other domains may be used. In some embodiments, the cellular domain may include a <NUM>/<NUM> network <NUM> (e.g., with a network exposure application programming interface (API) <NUM> and one or more boost services <NUM>), and the WAN domain is an Internet WAN <NUM>. A User Plane Function (UPF) gateway <NUM> may be used.

<FIG> and <FIG> illustrate processes and signaling that can be used to trigger a boost request or evaluate the potential benefit of a boost according to embodiments. The examples illustrated and described with respect to <FIG> and <FIG> may be implemented, for instance, using the architecture of <FIG>.

According to embodiments, <FIG> and <FIG> show systems and methods for leveraging a QoS boost and active measurement techniques to sectionalize one-way latency (e.g., in end-to-end or exchange-to-exchange (E2E) networks), for instance, in real-time. In some embodiments, the boost may be a TON Boost and the active measurement may use TWAMP techniques. In the examples of <FIG> and <FIG>, the values T1, T2, T3, and T4 may be timestamps collected in test packets. Such packets are initiated by the user device, such as an SDK <NUM>, <NUM>, <NUM> and "reflected" by a test head (e.g., in the cloud) or vice versa. The number, size, and DNN for test packets to be used can be specified by the user of the user device (e.g., portal user <NUM>) making a test request. According to embodiments, the timestamps in the packets (T1,T2,T3,T4) are recorded by the user device or UE (T1,T4) and a reflector or test head (T2,T3) located in the public cloud. By comparing the timestamps in the un-boosted packet set against the boosted packets, it is possible to measure the boost effect on latency on both the uplink and downlink directions. In some embodiments, the method measures the effect of a QoS boost on packet latency in the cellular domain where QoS boost is possible using T8 QoS APIs.

With respect to the example of <FIG>, a boost may be available on a cellular data path 308a in the cellular domain <NUM>, but not necessarily on a WAN data path 308b in the WAN domain <NUM>. In this example, packets may be transmitted as part of active measurement <NUM> of data path <NUM> between a user device <NUM> and test head <NUM>, which may be implemented in the cloud <NUM>. In certain aspects, the user device <NUM> may have one or more of a software development kit (SDK) <NUM>, a DNS module <NUM>, and/or modules for one or more TCP/IP protocols <NUM>. Additionally, aspects of user device (e.g., UE) <NUM> may be implemented in firmware <NUM>, hardware <NUM>, or both.

With further respect to <FIG>, the relative time values that are measured <NUM> on the data path <NUM> include the following when a boost is not used: <MAT> and <MAT>.

That is, a measured time from user device <NUM> to test head <NUM> may be given by Δ1 + X1 + γ1, where Δ and X relate to the data path 308a in the cellular domain <NUM> and γ relates to the data path 308b in the WAN domain <NUM>. The descriptor "<NUM>" indicates the uplink direction and "<NUM>" indicates the downlink direction. When a boost is applied, the time values are given by the following: <MAT> and <MAT> where the boost is indicated by a "B" superscript. In this respect, the values of X and γ indicate time on the cellular and WAN paths, respectively, in each of the uplink and downlink directions and the boost effect is given by: <MAT> and <MAT> where Δ1 is the uplink boost effect and Δ2 is the downlink boost effect. In certain aspects, a particular segment of the network (e.g., a data path in the cellular domain) can be evaluated in both the uplink and downlink direction for congestion and to determine the potential benefit of a QoS boost in the segment.

For congestion detection and evaluation, one or more of the following may be considered. For instance, if Δ1 > Ω ((T4-T1)B - (T3-T2) B), then the cell is congested on the uplink and boost will help. If Δ2 > Ω' ((T4-T1)B - (T3-T2) B), then the cell is congested on the downlink and boost will help. In these examples, Ω and Ω' are ratios that may be derived from lab testing and net modeling. An example value may be between approximately <NUM>-<NUM>%. Additionally, specific values for Ω and Ω' may be derived at run time (e.g., by the network service).

According to embodiments, and for the calculations described herein, the clocks of the client and reflector (e.g., user device <NUM> and test head <NUM>) need not be synchronized.

With respect to <FIG>, boost is available on both the cellular path 408a of cellular domain <NUM> and WAN data path 408b of WAN domain <NUM>. In this example, packets may be transmitted as part of active measurement <NUM> of data path <NUM> between a user device <NUM> and test head <NUM>, which may be implemented in the cloud <NUM>. In certain aspects, the device <NUM> may have one or more of an SDK <NUM>, a DNS module <NUM>, and/or modules for one or more TCP/IP protocols <NUM>. Additionally, aspects of user device (e.g., UE) <NUM> may be implemented in firmware <NUM>, hardware <NUM>, or both. In certain aspects, the user device <NUM> may be in the Wi-Fi domain <NUM>, and the test head <NUM> and cloud <NUM> may be in the Data Center (DC) domain <NUM>.

Here, Δ + X relate to the data path 408a in the cellular domain <NUM>, and δ and γ relate to the data path 408b in the WAN domain <NUM>, which can be boosted in this example. When a boost is applied, the time values are given by the following for the cellular boost: <MAT> and <MAT>.

The WAN boost is given by the following: <MAT> and <MAT>.

As such, the boost effect(s) of the different segments may be given as follows: <MAT> <MAT> <MAT> and <MAT> where Δ1 is the cell uplink boost effect, Δ2 is the cell downlink boost effect, δ1 is the WAN uplink boost effect, and δ2 is the WAN downlink boost effect. With this segmented congestion detection approach, different segments of the network can be independently evaluated, such as the cellular and WAN segments. Additionally, and in embodiments, the segments can be evaluated in both the uplink in downlink direction. While δ indicates the boost effect measurement on a WAN in this example, the measurement techniques described herein can be extended to any boostable network domain using the same principles. Examples include WiFi indoor, wireline WAN, etc. This may be further described with respect to <FIG>.

For congestion detection and evaluation, the following may be considered. For instance, if Δ1 > Ω ((T4-T1)B - (T3-T2)B), then the cell is congested on the uplink and cell boost will help. If Δ2 > Ω' ((T4-T1)B - (T3-T2)B), then the cell is congested on the downlink and cell boost will help. If δ1 > ω ((T4-T1)B' - (T3-T2)B'), then the WAN is congested on the uplink and WAN boost will help. If δ2 > ω' ((T4-T1)B' - (T3-T2)B'), then the WAN is congested on the downlink and WAN boost will help. In these examples, Ω, Ω', ω, and ω' are ratios that may be derived from lab testing and net modeling. An example value may be between approximately <NUM>-<NUM>%. Additionally, specific values for Ω, Ω', ω, and ω' may be derived at run time (e.g., by the network service).

<FIG> illustrates an extension of the devices and measurement techniques described herein to a device <NUM> behind customer premise equipment (CPE) <NUM> and using WiFi access in the WiFi domain <NUM>. That is, the device <NUM> may be in a WiFi domain <NUM>. In such a scenario, the CPE <NUM> is connected to another network <NUM>, such as a <NUM>/<NUM> network (mobile broadband, with network exposure <NUM> and a boost aspect <NUM>) in the cellular domain <NUM>. In this example, the cellular domain interfaces with an Internet WAN <NUM> in the WAN domain <NUM> via a UPF gateway <NUM>. In this embodiment, a boost can be requested for both the air interface as well as the WiFi link and/or WAN portion. As shown in <FIG>, real-time network sectionalization can be achieved from any connected device according to embodiments. The data path <NUM> contains a WiFi portion 508d, a cellular portion 508a, and a WAN portion 508c, which each may be evaluated by measurement <NUM>. As with other embodiments, the device <NUM> may include an SDK <NUM>, and the test head <NUM> may be implemented in the cloud <NUM> along with one or more end user applications <NUM>. According to embodiments, the same equations and values illustrated with respect to the cellular and WAN domains in <FIG> and <FIG> may be applied with respect to the WiFi domain <NUM> in the example of <FIG>.

Referring now to <FIG>, a flow diagram of a process <NUM> is provided according to embodiments. In certain aspects, the process <NUM> combines call flows from active measurements (dashed lines), and boost signaling messages (solid lines) between an SDK or other agent or app on an end-user device and the NEF, including any intermediate test heads and/or services. According to embodiments, one or more aspects may be performed by a software agent running on an end-user device and/or a backend running in the cloud. In some embodiments, aspects may be performed by one or more of the devices illustrated with respect to <FIG>.

According to embodiments, the process <NUM> may begin with an end-user device (e.g., with an iOS/Android application or network portal <NUM>) making a test request. The request may include, for instance, one or more parameters of the test, such as number of test packets, packet size, a boost type, and/or DNN). The request may be made to an SDK <NUM>. The SDK <NUM> may then send test packets to a Test Head <NUM>. In this example, these initial packets are un-boosted. In certain aspects, one or more of the portal <NUM>, SDK <NUM>, and Test Head <NUM> may be part of the The One Network (TON). While the example uses calls between a portal and SDK, active measurement may be performed by software that is part of an app running on the device, such as a UE, or as part of a stand-alone program for evaluating and/or requesting a QoS boost. In some embodiments, the functions of portal <NUM> and SDK <NUM> are performed by a single device, such as a UE, and/or single module.

According to embodiments, Test Head <NUM> will then optimize tags and reflect the test packets back to the SDK <NUM>. The SDK <NUM> may then calculate preliminary results based on the collected packets, and send a boost request. The boost request may be sent, for instance, to a Boost Service <NUM>. The request may contain, in some embodiments, one or more of Boost Type, Short Boost, and/or DNN. In certain aspects, the request indicates what network(s) should be boosted, and for how long. For instance, a Short Boost may be a boost request for only the length of the test. The Boost Type may indicate one or more attributes of a traffic flow for which a boost is requested. Upon receipt of the request (e.g., with a Special Gatekeeper Check), the Boost Service <NUM> can send a boost (e.g., a T8 Boost) to the appropriate network function (NEF) <NUM>. After receiving a response from the NEF <NUM>, the Boost Service <NUM> then sends an OK message to the SDK <NUM>. The message may indicate, for instance, boost. According to embodiments, the messaging associated with a request for and/or acceptance of a boost is in accordance with 3GPP TS <NUM>, which may govern the exposure of the boost functionality by the network, for instance, by NEF <NUM>. In certain aspects, 3GPP TS <NUM> may specify API exposure over T8, including for QoS. For example, T8 may be the interface exposed by the NEF <NUM>, which can indicate if a boost is accept, cancelled, or timed out. When accepted, a user device (e.g., UE <NUM>, <NUM>, <NUM>, <NUM>) can boost all packets associated with applicable traffic flows, or can boost specific packets associated with an application. According to embodiments, the boosted traffic flow may be specified by one or more attributes. For instance, the traffic flow may be indicated by five tuples: (<NUM>) Source IP Address, (<NUM>) Source Port, (<NUM>) Destination IP Address, (<NUM>) Destination Port, (<NUM>) Protocol. These parameters can be passed to a QoS API identifying the traffic flow. A new dedicated bearer may then be generated for the boosted traffic flow and the traffic flow template loaded onto the user device, which directs the packets onto that bearer. According to embodiments, this bearer will have improved QoS relative to the default bearers. For instance, it may have a lower 5QI value (i.e., higher priority). For <NUM> networks, the value may be a QoS Class Identifier (QCI). In certain aspects, there may be an improved bit rate associated with the 5QI/QCI, including guaranteed and/or non-guaranteed bit rate. There may also be provided the ability to preempt other traffic for the improved bearer.

According to embodiments, the process <NUM> further comprises sending boosted test packets (e.g., from the SDK to the Test Head). The Test Head <NUM> will then optimize tags and reflect the test packets back to the SDK <NUM>. The SDK may then calculate test results based on the collected packets and the previously calculated preliminary results, and send an un-boost request (e.g., to the Boost Service <NUM>). The Boost Service may then send an un-boost (e.g., T8 Un-Boost) to the NEF <NUM>, and an OK message is sent to the SDK <NUM>. In some embodiments, an SDK <NUM> may also provide the test results to the iOS/Android application or network portal <NUM>, for instance, in the form of a callback. The SDK <NUM> may similarly provide a congestion estimation, and estimation regarding the potential benefit of a boost, a boost instruction or request message, or one or more QoS metrics.

Following the message exchange, the SDK <NUM> or other functionality of the user device may send a message to the Test Head <NUM>, for instance, to update status. This may be in the form of a POST message (e.g., including one or more of the Test Results, Lot, Long, cellID, etc.). The Test Head <NUM> can then archive one or more aspects/results of the process <NUM>. This could include, for instance, one or more of Timestamp, Lot, Long, Test Result, cellID.

While un-boosted test signals are sent first in process <NUM>, in some embodiments, the order may be changed such that the boosted test signals are sent first. Additionally, one or more of <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM> may be comprised in a single unit, module, device, and/or node. For example, both Portal <NUM> and SDK <NUM> may be co-located in embodiments (e.g., in a UE).

In certain aspects, <FIG> describes a full BEAM protocol call flow where a user of the user device using the SDK <NUM> or other application requests a BEAM test for execution given certain parameters, such as packet size, number of packets, boost type, and DNN. According to embodiments, the protocol runs the test with a batch of un-boosted packets followed by a batch of boosted packets, calculates the test result, which is returned asynchronously to the user of the user device and/or stored (e.g., in cloud services).

Referring now to <FIG>, a method <NUM> is provided according to embodiments. The method may be performed, for instance, by an end-user device. In some embodiments, the device comprises SDK functionality. In some embodiments, aspects may be performed by one or more of the devices or modules illustrated with respect to <FIG>.

The process may begin, for instance, with step s702, which comprises sending a first set of test packets to a network node, wherein the first set of test packets are un-boosted. In step s704, first reflected packets are received from the network node. In step s706, preliminary results are calculated based at least in part on the received first reflected packets (e.g., one or more time/delay values, for instance, based on timestamps). In step s708, the device sends a second set of test packets to the network node. According to embodiments, the second set of test packets are sent boosted. In step s710, the device receives second reflected packets from the network node. In step s712, the device calculates test results based at least in part on the received second reflected packets and the preliminary results. In certain aspects, this may comprise deriving one or more congestion metrics. In step s714, which may be optional, a QoS determination (or QoS request) is performed based at least in part on the test results. In some embodiments, the end-user may request a QoS boost and/or output an estimation of whether a boost of a particular traffic flow could help improve the user's quality of experience or other performance metric.

Referring now to <FIG>, a method <NUM> is provided according to embodiments. The method may be performed, for instance, by a network node or host. In some embodiments, the node comprises a test head, which may in turn be in communication with an NEF for the appropriate functions. In some embodiments, the node may comprise NEF functionality itself. In some embodiments, aspects may be performed by one or more of the devices illustrated with respect to <FIG>.

The process may begin, for instance, with step s752, which comprises receiving and reflecting a first set of test packets sent from an end-user device, wherein the first set of test packets are un-boosted. In step s754, the node receives and reflects a second set of test packets from the end-user device, wherein the second set of test packets are boosted. In step s756, the node receives a message from the end-user device indicating QoS test results or an estimation, which are based at least in part on the first and second test packets. The message may be received, for instance, as a POST message. In some embodiments, a boost request is received.

According to embodiments, one or more of the methods described with respect to <FIG> and <FIG> may be performed as part of fine tuning network sectionalizing.

<FIG> shows an example of a communication system <NUM> in accordance with some embodiments. According to embodiments, one or more of the systems described with respect to <FIG> can be implemented as shown in <FIG>.

In the example of <FIG>, the communication system <NUM> includes a telecommunication network <NUM> that includes an access network <NUM>, such as a radio access network (RAN), and a core network <NUM>, which includes one or more core network nodes <NUM>. The access network <NUM> includes one or more access network nodes, such as network nodes 810a and 810b (one or more of which may be generally referred to as network nodes <NUM>), or any other similar <NUM>rd Generation Partnership Project (3GPP) access node or non-3GPP access point. The network nodes <NUM> facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 812a, 812b, 812c, and 812d (one or more of which may be generally referred to as UEs <NUM>) to the core network <NUM> over one or more wireless connections.

In some examples, the UEs <NUM> are configured to transmit and/or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network <NUM> on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network <NUM>. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

In the example, the hub <NUM> communicates with the access network <NUM> to facilitate indirect communication between one or more UEs (e.g., UE 812c and/or 812d) and network nodes (e.g., network node 810b). In some examples, the hub <NUM> may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub <NUM> may be a broadband router enabling access to the core network <NUM> for the UEs. As another example, the hub <NUM> may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes <NUM>, or by executable code, script, process, or other instructions in the hub <NUM>. As another example, the hub <NUM> may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub <NUM> may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub <NUM> may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub <NUM> then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub <NUM> acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy IoT devices.

The hub <NUM> may have a constant/persistent or intermittent connection to the network node 810b. The hub <NUM> may also allow for a different communication scheme and/or schedule between the hub <NUM> and UEs (e.g., UE 812c and/or 812d), and between the hub <NUM> and the core network <NUM>. In other examples, the hub <NUM> is connected to the core network <NUM> and/or one or more UEs via a wired connection. Moreover, the hub <NUM> may be configured to connect to an M2M service provider over the access network <NUM> and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes <NUM> while still connected via the hub <NUM> via a wired or wireless connection. In some embodiments, the hub <NUM> may be a dedicated hub - that is, a hub whose primary function is to route communications to/from the UEs from/to the network node 810b. In other embodiments, the hub <NUM> may be a nondedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 810b, but which is additionally capable of operating as a communication start and/or end point for certain data channels.

<FIG> shows a UE <NUM> in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle-mounted or vehicle embedded/integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE.

The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as `SIM card.

A UE, when in the form of an Internet of Things (IoT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door/window sensor, a flood/moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an IoT device comprises circuitry and/or software in dependence of the intended application of the IoT device in addition to other components as described in relation to the UE <NUM> shown in <FIG>.

In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone's speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone's speed. The first and/or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

<FIG> shows a network node <NUM> in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a UE and/or with other network nodes or equipment, in a telecommunication network.

Applications <NUM> (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.

Hardware <NUM> includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers <NUM> (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1208a and 1208b (one or more of which may be generally referred to as VMs <NUM>), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer <NUM> may present a virtual operating platform that appears like networking hardware to the VMs <NUM>.

Hardware <NUM> may be implemented in a standalone network node with generic or specific components. Hardware <NUM> may implement some functions via virtualization. Alternatively, hardware <NUM> may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration <NUM>, which, among others, oversees lifecycle management of applications <NUM>. In some embodiments, hardware <NUM> is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system <NUM> which may alternatively be used for communication between hardware nodes and radio units.

<FIG> shows a communication diagram of a host <NUM> communicating via a network node <NUM> with a UE <NUM> over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE 812a of <FIG> and/or UE <NUM> of <FIG>), network node (such as network node 810a of <FIG> and/or network node <NUM> of <FIG>), and host (such as host <NUM> of <FIG> and/or host <NUM> of <FIG>) discussed in the preceding paragraphs will now be described with reference to <FIG>.

One or more of the various embodiments improve the performance of OTT services provided to the UE <NUM> using the OTT connection <NUM>, in which the wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments may improve QoS decisions and measurement techniques, and thereby provide benefits such as allowing an end user to control and explicitly request a QoS boost, improving the user's experience.

In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection <NUM> between the host <NUM> and UE <NUM>, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host <NUM> and/or UE <NUM>. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection <NUM> passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection <NUM> may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node <NUM>. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host <NUM>. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or 'dummy' messages, using the OTT connection <NUM> while monitoring propagation times, errors, etc..

Claim 1:
A method (<NUM>) performed by a user equipment, UE, for active network measurement, the method comprising:
sending (<NUM>) one or more first test packets to a node, wherein the first test packets are not boosted for improved Quality of Service, QoS;
receiving (<NUM>) one or more first reflected packets from the node;
calculating (<NUM>) preliminary results based at least in part on the received first reflected packets;
sending (<NUM>) one or more second test packets to the node, wherein the second test packets are boosted for improved QoS;
receiving (<NUM>) one or more second reflected packets from the node; and
calculating (<NUM>) test results based at least in part on the received second reflected packets and the preliminary results.