Real-time quality of experience optimization through metadata cross-layer awareness

Abstract

Systems and methods disclosed herein relate to generation and use of enhanced cross-layer metadata for a quality of experience (QoE) awareness mechanism within a network (e.g., wireless) device (e.g., user equipment (UE)). Examples of related mechanisms include a link selection mechanism, a link differentiation mechanism, a traffic or packet prioritization mechanism, and a packet queuing mechanism. A device may be understood according to a functional layer at the device used to communicate over a network. The QoE-based metadata may be transmitted in a southern (layer-down) direction to enable decisions at layers in the southern direction. Similarly, lower layer metadata may be communicated in a northbound (layer-up) direction to enable decisions at layers in the northbound direction. Various novel aspects of the type, generation, transmission, and temporal correlation of such enhanced metadata for QoE-aware environments are discussed.

Description

Technical Field

[0001] This application relates in general to wireless and wired communication systems, including wireless communication systems that use enhanced metadata for cross-layer awareness. Background Technology

[0002] Wireless mobile communication technologies use various standards and protocols to transmit data between base stations and wireless communication devices. For example, wireless communication system standards and protocols may include, for instance, 3GPP Long Term Evolution (LTE) (e.g., 4G), 3GPP New Radio (NR) (e.g., 5G), and the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard for Wireless Local Area Networks (WLANs) (often referred to as Wi-Fi within the industry organization). ® ).

[0003] As envisioned by 3GPP, different wireless communication system standards and protocols can use various radio access networks (RANs) for communication between RAN base stations (sometimes referred to as RAN nodes, network nodes, or simply nodes) and wireless communication equipment called user equipment (UEs). 3GPP RANs can include, for example, Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), and / or Next Generation Radio Access Network (NG-RAN).

[0004] Each RAN can use one or more Radio Access Technologies (RATs) to perform communication between the base station and the UE. For example, GERAN implements the GSM and / or EDGE RAT, UTRAN implements the Universal Mobile Telecommunications System (UMTS) RAT or other 3GPP RATs, E-UTRAN implements the LTE RAT (sometimes simply referred to as LTE), and NG-RAN implements the NR RAT (this NR RAT is sometimes referred to herein as the 5G RAT, 5G NR RAT, or simply NR). In some deployments, E-UTRAN may also implement the NR RAT. In some deployments, NG-RAN may also implement the LTE RAT.

[0005] The base stations used by a RAN can correspond to that RAN. An example of an E-UTRAN base station is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly referred to as Evolved Node B, Enhanced Node B, eNodeB, or eNB). An example of an NG-RAN base station is a Next Generation Node B (sometimes also called gNode B or gNB).

[0006] The RAN provides communication services to external entities through its connection with the core network (CN). For example, E-UTRAN can utilize the evolved packet core (EPC), while NG-RAN can utilize the 5G core network (5GC). Attached Figure Description

[0007] To facilitate the identification of any particular element or action in the discussion, one or more of the most significant digits in the figure reference numerals refer to the figure number in which the element was first introduced.

[0008] Figure 1 An example of the OSI model is given.

[0009] Figure 2 A graph illustrating the implementation scheme discussed herein corresponds to the use of enhanced metadata or awareness messages to optimize the application's real-time QoE via link selection.

[0010] Figure 3 A diagram illustrating the use of enhanced metadata for API-driven handshakes for cellular link selection purposes is shown according to an implementation of this paper.

[0011] Figure 4 A table illustrating enhanced metadata for cellular link selection for applications using enhanced metadata, according to the implementation scheme discussed herein, is provided.

[0012] Figure 5 An example is shown of a time-related graph of enhanced metadata across different time scales for the purpose of link selection, based on the implementation scheme discussed in this paper.

[0013] Figure 6 A graph illustrating the implementation scheme discussed herein corresponds to link selection using enhanced metadata in a QoE-aware context.

[0014] Figure 7 An example of a UE method based on the implementation scheme discussed herein is illustrated.

[0015] Figure 8 An example of a UE method based on the implementation scheme discussed herein is illustrated.

[0016] Figure 9 An example of a UE method based on the implementation scheme discussed herein is illustrated.

[0017] Figure 10 An example architecture of a wireless communication system according to the implementation scheme disclosed herein is illustrated.

[0018] Figure 11 A system for performing signaling between a wireless device and a network device according to an embodiment disclosed herein is illustrated. Detailed Implementation

[0019] Various implementations are described with respect to the UE. However, references to the UE are provided for illustrative purposes only. The example implementations can be used with any electronic component capable of establishing a connection to a network and configured with hardware, software, and / or firmware for exchanging information and data with the network. Therefore, the UE as described herein is used to represent any suitable electronic component. Open Systems Interconnection (OSI) model

[0020] Figure 1 The Open Systems Interconnection (OSI) model 100 is illustrated. The OSI model 100 illustrates the various layers that can be used by networked electronic devices to communicate on a network.

[0021] OSI model 100 includes an application layer 102, which may be referred to as layer 7 (L7). Application layer 102 may represent the operation of software applications on the device, including aspects related to application inputs / outputs from / to the user interface.

[0022] OSI model 100 includes a presentation layer 104, which may be referred to as layer 6 (L6). Presentation layer 104 includes functionality for formatting and presenting data to application layer 102 in a desired manner.

[0023] The OSI model 100 includes a session layer 106, which may be referred to as layer 5 (L5). Session layer 106 may represent the connection, session, and / or port management functions of electronic devices regarding network communication.

[0024] OSI model 100 includes a transport layer 108, which may be referred to as layer 4 (L4). Transport layer 108 may represent the use of transmission protocols for network communication of electronic devices.

[0025] OSI model 100 includes a network layer 110, which may be referred to as layer 3 (L3). Network layer 110 includes elements related to routing of network communication across the network.

[0026] OSI model 100 includes a data link layer 112, which may be referred to as layer 2 (L2). Data link layer 112 includes functionality for data transfer between a pair of nodes in a network.

[0027] OSI model 100 includes a physical layer 114, which may be referred to as layer 1 (L1). Physical layer 114 may include hardware and / or corresponding functionality for the physical transmission and / or reception of data through physical channels of the network.

[0028] It should be understood that, within the context of OSI model 100, incoming data from the network for applications of electronic devices is interpreted in the "North" direction 116 (in the direction from L1 to L7). Furthermore, outgoing data from the applications is prepared to be transmitted on the network in the "South" direction 118 (in the direction from L7 to L1).

[0029] In this paper, various implementations are discussed based on specific layers of the OSI model 100, which are understood in a general sense as being implemented at electronic devices communicating over a network (e.g., UEs communicating within a 3GPP wireless communication system). With respect to any particular network communication system, it is understood that the OSI model 100 is represented in one or more generalized ways (e.g., a particular wireless communication system may use a more specific model to which the elements of the OSI model 100 can be conceptually mapped). In such cases, it should be understood that the principles discussed herein will remain applicable even under such more specific layered models. The lack of real-time QoE "glitch" and cross-layer sensing

[0030] As used herein, the term "metric" can sometimes refer to a measured value corresponding to the state of a system. Furthermore, "metric" can be used in some cases to indicate (e.g., binary or enumerated) a state corresponding to the system (e.g., an indication of an event that has occurred within the system). The appropriate application of any particular metric described herein will be apparent to the reader, depending on the context.

[0031] This paper discusses various aspects of the Quality of Experience (QoE) perceived by users when using software applications on a device (e.g., UE). In the context of this discussion, QoE describes the relationship between the ideal performance of the application (or alternatively, the user's expectation of the application's performance) and the user's perception of the application's performance in the context of the user's real-world use cases. Applications may monitor one or more metrics reflecting the current QoE and / or base decisions on one or more metrics reflecting the current QoE. In this paper, these are referred to as "QoE metrics".

[0032] In some wireless systems, such as video conferencing applications (like Zoom) that can be presented within the context of the user equipment's (UE) operating system,... ® WebEx ® (etc.) Any pauses can occur during cellular mobility or indoor-to-outdoor Wi-Fi / cell handover. Such pauses may negatively impact the user's perceived QoE for such video conferencing applications.

[0033] It has been observed that such QoE degradation may be at least partly caused by the relatively slow (e.g., second-level) response of upper-layer applications to changes or resource switching of lower-layer radio links / RATs (which may occur on the order of 100 milliseconds (ms)). In this paper, "link" refers to radio connections such as Wi-Fi bands, Wi-Fi channels, cellular connections (e.g., Protocol Data Units (PDUs), Packet Data Networks (PDNs), session, traffic, and / or Radio Resource Control (RRC) connections), carriers, slices, bearers, etc.

[0034] It was also observed that such QoE degradation may be caused at least in part by the lack of proactive or timely changes in the lower-layer radio links in response to upper-layer QoE degradation (including but not limited to codec rate degradation).

[0035] In some wireless communication systems, the root cause of such degradation may include user-perceived QoE degradation that may not be directly related to radio link optimization. Furthermore, random radio resources may not be adequately incorporated into application and codec adaptation mechanisms. There may be a lack of top-down, immediate indication of real-time QoE events (such as short-duration video impulse interference, codec rate degradation, etc.) from the application / transport / codec layer down to the lower layers (e.g., L1-L2). There may be a lack of bottom-up (active) L1-L2 indications at the application or transport / codec layer, such as the “readiness” status of new links as additional available resources, and / or the removal of existing links. There may be a lack of QoE-triggered or QoE-aware link adaptation mechanisms (e.g., mechanisms for QoE adaptation to cellular carrier addition and / or mobility modifications, etc.), and vice versa. Metadata Design

[0036] In some implementations discussed herein, enhanced cross-layer metadata can be used for QoE-aware link selection. Furthermore, in some implementations, link-state-aware QoE adaptation can be used.

[0037] It has been recognized that existing designs and / or definitions for metadata use across various wireless communication systems vary considerably and / or have scenario-specific use cases. For example, such designs and definitions do not adequately consider real-time QoE-oriented metadata for applications such as User Datagram Protocol (UDP) and / or Quick UDP Internet Connection (QUIC). Specifically, they may not adequately consider QoE-aware applications for purposes such as assisting or controlling link-level radio optimization, such as adjustments or changes to data link configurations (including, for example, carrier addition / removal / modification).

[0038] Furthermore, the use of radio link state-aware applications that can achieve QoE adaptation (including, for example, codec layer rate adaptation) may not have been adequately considered.

[0039] For example, existing application programming interfaces (APIs) may not have southbound QoE instructions to baseband for the purposes described above in various contexts. Enhanced metadata for optimizing real-time QoE and baseband / link selection

[0040] Therefore, the implementation scheme described in this paper relates to optimizing QoE performance by using enhanced metadata via baseband link optimization for the application. In some cases, the application may be an external or third-party application that accesses / uses metadata through a large-scale metadata API (an application not integrated into the device manufacturer's default operating environment but later installed on the device from another source). The application may be, for example, a real-time conversational application (e.g., a video conferencing application, a chatbot application, etc.).

[0041] The use of enhanced metadata as disclosed herein can facilitate or enable more direct and immediate information transmission, and / or more direct and immediate interaction between the device's application layer (where the application is operating) and one or more lower layers of the device (e.g., the device's transport / codec layer, data link layer, media access control (MAC) layer, and / or some combination thereof). Therefore, an application that uses enhanced metadata in this way (e.g., via an API) to communicate with lower layers (relative to the application layer) can be termed a "cross-layer aware" application. Furthermore, in this context, one or more lower layers that provide, receive, and / or use such enhanced metadata can also be understood as "cross-layer aware." In this context, a message including enhanced metadata can be termed a "aware message."

[0042] In some implementations, enhanced metadata can be understood as “large timescale” metadata. This refers to the fact that the metrics reported in the metadata can correspond to a relatively larger timescale than those applied in other contexts (e.g., the timescale used regarding physical data received from the channel, data packetization, etc.).

[0043] Cross-layer awareness can be provided through the use of enhanced metadata mechanisms as disclosed herein for the purpose of radio link awareness at / at the application’s QoE adaptive functionality, and / or for QoE (e.g., application-level QoE, codec-level QoE) awareness at one or more lower layers of the device’s radio link selection functionality.

[0044] In one example, cross-layer awareness can be provided through the use of enhanced metadata, allowing deteriorating applications (such as real-time session applications) to request immediate RAT or carrier changes.

[0045] In another example, cross-layer awareness achieved through enhanced metadata can be provided by a hybrid top-down / bottom-up instruction (e.g., southbound or northbound) API oriented towards QoE. In some cases, such APIs use, for example, “fast” signaling channels, which can exist between L7 or application layers with L1-L2 or one or more lower layers (e.g., radio link layer). Such signaling channels can carry directly cross-layer enhanced metadata (where such metadata is not explicitly processed, controlled, or used at intermediate layers) to enable rapid responses to rare events, large-scale dynamics, etc.

[0046] In other cases, the exchanged metadata / aware messages can be traversed across all protocol layers, for example, by being piggybacked onto existing data packets. In such cases, the API can be used for any corresponding message encoding / decoding that occurs.

[0047] It is explicitly envisioned that metadata other than the metadata that directly and / or formally represents QoE aspects as described above (e.g., some types of metadata from modules such as sensing, Global Navigation Satellite System (GNSS) or cameras) can be transmitted or processed in the same manner as QoE sensing messages (and for the same purpose).

[0048] It should also be noted that the cross-level awareness implementation scheme discussed in this article extends to / extends to the case of Access Service Bootstrapping, Switching and Splitting (ATSSS) and / or Non-3GPP Interoperability Functions (N3IWF) with L2 multipath support (because in such cases, L2 can still use enhanced / QoE metadata to make optimization decisions).

[0049] Figure 2 Figure 200 illustrates a real-time QoE of an application optimized via link selection using enhanced metadata or awareness messages, according to the implementation discussed herein. Figure 200 illustrates (e.g., at the application layer) a real-time application 202 that communicates with one or more lower layers 204 using a southbound metadata API 206 (for metadata from real-time application 202 to one or more lower layers 204) and a northbound metadata API 208 (for metadata from one or more lower layers 204 to real-time application 202).

[0050] Southbound metadata API 206 and Northbound metadata API 208 are used to transmit bidirectional awareness messages 210, as illustrated in the figure. These bidirectional awareness messages can be associated with RTP / UDP / QUICK session metrics 212.

[0051] Real-time application 202 can monitor QoE events and metrics (in some cases, including codec events related to QoE) as illustrated in the figure, and use the southbound metadata API 206 to pass information about these events / metrics to one or more lower layers 204.

[0052] In some implementations, one or more lower layers 204 may monitor, for example, L2 link events 214 (such as, for example, addition, failure, or modification of secondary cell groups (SCGs), radio carriers, logical channels, traffic, sessions, slices, link-specific buffers, bandwidth portions (BWPs), or bearers), L2 allocation events 216 (such as, for example, changes in time-frequency (TF) resource allocation or occupancy) and / or L1 events 218 (such as changes in coexistence, changes in transport block size (TBS), changes in average throughput (e.g., in megabits per second (Mbps)), changes in reference signal received power (RSRP), and / or changes in signal-to-interference-and-noise ratio (SINR), as illustrated in the figure. One or more lower layers 204 may use the Northbound Metadata API 208 to transmit information about these events / metrics to the real-time application 202. Implementation of a bidirectional metadata exchange method for QoE and link selection

[0053] In some implementations, the cross-layer metadata approach via API at the device (e.g., UE), as described herein, can be used to optimize QoE and radio link selection for real-time applications (e.g., UDP, QUIC applications) operating on the device.

[0054] In some such implementations, real-time metadata exchange can be bidirectional. In some cases, it is possible that top-down application-level (or alternatively, transport / codec layer) QoE metrics, events, and application (category) identifiers (IDs) are transmitted as metadata. These cases may correspond to defining states or configuration commands (such as “video stagnation” states and / or “link change request” commands) to the baseband in a southbound manner to facilitate real-time connectivity. Furthermore, bottom-up radio link state indications may be indicated northbound to applications in the application layer (and / or to codecs in the transport layer). Such link changes, indicated northbound to applications or codecs, can allow for predictive or responsive smoother service scaling up or down (as appropriate).

[0055] APIs that expose or provide cross-layer awareness as described herein may include one or more functionalities. For example, such APIs may allow metadata generation. It is conceivable that this metadata may be generated as periodic metadata, single-trigger metadata, random metadata, metadata corresponding to rare events, and / or metadata for state updates (predictively or reactively).

[0056] The APIs discussed in this article can be used to report metadata proactively, chronologically, aggregately, and / or during polling commands.

[0057] The APIs discussed in this article can be used for receiving metadata.

[0058] The APIs discussed in this article can be used for metadata consumption. In some such cases, it is conceivable that metadata can be consumed by external applications and used by those applications to take responsive, predictive, or proactive actions on an immediate basis.

[0059] Real-time / enhanced metadata exchange can be used to reflect or trigger large-scale QoE session adaptation and radio link selection based on access-specific constraints (e.g., rather than solely based on CN congestion). Such adaptation can include application-layer or codec rate adaptation (e.g., on timescales of hundreds of milliseconds to seconds); UDP / QUIC session or Quality of Service (QoS) traffic modifications (e.g., on timescales corresponding to round-trip time (RTT); and / or underlying radio changes, such as changes to the serving WiFi band or channel, serving cell link, applicable PDU / PDN session, carrier, slice, RRC state, carrier, and / or bearer (e.g., on timescales of hundreds of milliseconds).

[0060] Real-time / enhanced metadata exchange can be used to reflect or trigger changes in QoE key performance indicators (KPIs) or radio quality (e.g., on a timescale of tens of milliseconds (for WiFi) or hundreds of milliseconds (for cellular)). These can include, for example, changes in cellular channel and source allocation status and / or WiFi channel occupancy (e.g., provided at a rate of tens of milliseconds), channel switching, and multi-band operation. In some cases, such KPIs or radio quality changes can include traffic-specific transient queuing delays, per-packet queue management, rapid channel fading, etc. Public metadata API for applying specific link selection optimization

[0061] As discussed in this paper, the API for enhanced metadata can be used by external applications (e.g., at OSI L7) to communicate directly (by skipping intermediate protocol layers) with one or more lower layers (e.g., at OSI L1-L2, at OSI L4).

[0062] In some implementations, in order to select the best link at the host or baseband, the specific requirements and / or QoE status of the (real-time, external) application can be used as input or output in real time.

[0063] For example, one or more APIs may allow a device to: signal to lower layers one or more of the following: southbound category ID, QoE events, time series of video stagnation, severe resolution degradation, and / or frame loss; poll or receive changes in the state of the major northbound radio links, such as changes in resource addition, modification, and / or removal; trigger, request, or configure southbound radio link changes responsively or predictively; configure periodic, event-driven, or proactive reporting or link selection policies (such as, for example, the use of link aggregation and link switching, the use of WiFi and cellular communications, the use of 4G and 5G, etc.); configure application-based (e.g., category) receive (RX) / transmit (TX) services and / or buffer priorities for specific links; and / or configure application-based (e.g., category) service-specific radio link resource expectations.

[0064] Figure 3 Figure 300 illustrates the use of enhanced metadata for API-driven handshakes for cellular link selection purposes, according to the implementation described herein. It can be noted that, regarding... Figure 3 The metadata discussed is provided in an illustrative rather than restrictive manner. Discussion will be based on application layer 302 and one or more lower layers 304 (e.g., corresponding to the host central processing unit (CPU) and / or baseband circuitry). Figure 3 The implementation plan is illustrated in the example.

[0065] It is possible that the configuration 306 for application-specific settings (e.g., via a graphical user interface (GUI) or via an API) can occur at the device. This can signal the device to operate in a cross-layer-aware mode (e.g., using an API for enhanced metadata, as described herein).

[0066] Application layer 302 may transmit first metadata 308 to one or more lower layers 304. The first metadata 308 may be one or more of the following: application (category) identifier (ID) type metadata, QoE event metadata (including, for example, application layer QoE event metadata and / or transport / codec layer QoE event metadata); sampled time-series metadata; and / or link state polling metadata.

[0067] One or more lower layers 304 may transmit second metadata 310 to the application layer 302. The second metadata 310 may be, for example, metadata used to report link status based on registration and / or polling.

[0068] One or more lower layers 304 may also (e.g., at the host CPU or baseband) perform 312 QoE-aware link selection. This link selection may be based on or in response to a problem indicated in the first metadata 308 (e.g., link selection at one or more lower layers 304 may be in response to a situation where the QoE of the service being applied, as indicated by the value reported in the first metadata 308, is degraded, to select a new, replacement, or additional network link for use at the device).

[0069] One or more lower layers 304 may transmit third metadata 314 to the application layer 302. The third metadata 314 may be one or more of the metadata that provides a suggestion or identifier for a new link to the application layer 302 and / or an identifier for a link state change that has been performed (and the corresponding newly prepared link).

[0070] Application layer 302 may send fourth metadata 316 to one or more lower layers 304. The fourth metadata 316 may indicate one or more application-preferred links selected by the application at application layer 302. As described, these one or more preferred links may be links identified in third metadata 314 previously received at application layer 302 from one or more lower layers 304.

[0071] One or more lower layers 304 may transmit fifth metadata 318 to application layer 302. The fifth metadata 318 may provide application layer 302 with confirmation of the link selected by one or more lower layers 304 (e.g., in response to an indication of the application-preferred link in fourth metadata 316). Alternatively or additionally, the fifth metadata 318 may include link state updates. Examples of enhanced metadata

[0072] The following section discusses various examples of metadata. This metadata can be used as “enhanced metadata” as discussed in this article.

[0073] Real-time metadata used by the API in the southbound direction can include application-level QoE metrics for the application's services (e.g., on a timescale of hundreds of milliseconds to several seconds). These application-level QoE metrics can relay information about one or more of the following: video lag in the service (e.g., on a timescale of greater than 500 ms), severe short-duration burst interference in the service, (e.g., perceptible) resolution degradation in the service, indoor / outdoor handover latency in the service (e.g., on a timescale of greater than one second); session dropouts in the service; severe frame loss in the service, etc.

[0074] Real-time metadata used by the API in the southbound direction may optionally or additionally include, for example, transport layer QoE metrics on an RTT timescale (e.g., regarding codec rate adjustments). These transport layer QoE metrics can relay information about sudden codec rate changes (which can be used at baseband to distinguish them from CN or access congestion situations). Note that in some cases, these southbound transport layer QoE metrics may be relayed from the transport layer to one or more lower layers by the application layer, while in other cases, these southbound transport layer QoE metrics may be provided directly from the transport layer to one or more lower layers.

[0075] It should be understood that, in the context of using transport layer or codec layer QoE metrics, the relevant “lower layer” described can be understood as one or more layers below the transport / codec layer. This is in contrast to the case of using application layer QoE metrics, where any one or more layers below the application layer (including, for example, the transport / codec layer) can be understood as part of a “lower layer” that can receive southbound metadata, as discussed herein.

[0076] Real-time metadata used by the API in the southbound direction may optionally or additionally include RTP / UDP / QUIC streams or related Internet Protocol (IP) session state changes.

[0077] In some implementations, the best-effort southbound metadata that can be used in the system includes TCP / IP / Explicit Congestion Notification (ECN) session metrics, including those related to one or more of the following: RTT (change), slow start, multipath TCP (MPTCP) status, low-latency low-loss scalable throughput (L4S) ECN (congestion level, etc.). The best-effort southbound metadata used in the system may also include best-effort QoE metrics, including data stagnation indicators, network thrashing indicators (e.g., indicators of actual throughput versus throughput), etc.

[0078] For link selection purposes, other southbound metadata that may be used in the system includes cellular carrier information and / or WiFi channel information selected by the application; application (category) ID or priority ordering attributes; and / or the following user configurations: low-rate mode configuration, high-rate application configuration, screen on / off indication, power-saving mode indication, and / or static policies for RAT or link preferences, etc.

[0079] Real-time metadata used by the API in the northbound direction can include cellular link state changes (e.g., on a timescale of hundreds of milliseconds). These can include, for example: indications of PDU sessions, PDN sessions, RRC connections, traffic and / or MAC link state changes; indications of sudden changes in throughput or time-frequency resource allocation or occupancy; indications of state switching latency (e.g., on a timescale of 100ms); and / or indications of RRC or RAT state changes between 4G Standalone (SA), 5G Standalone (SA), and / or 5G Non-Standalone (NSA) (e.g., with LTE and NR SCG).

[0080] Real-time metadata used by the API in the northbound direction can include information about radio state changes of cellular links (e.g., on timescales of hundreds of milliseconds or longer). These indications can include, for example: indications about carriers, such as carrier addition, carrier modification, carrier removal, carrier aggregation, and / or changes in radio resources covered; and / or indications about slicing, (split) bearers, BWPs, etc., that are similar to or analogous to those state changes described about carriers.

[0081] Real-time metadata used by the API in the northbound direction can include information about changes in WiFi link state (e.g., on a timescale of tens of milliseconds). These can include, for example: sudden changes in throughput or idle channel assessment (CCA) occupancy results; indications about channel bonding or multi-band operation (MBO); indications about channel / band additions, modifications, etc.; and / or indications about state transition latency (e.g., on a timescale of 100ms), etc.

[0082] Real-time metadata used by the API in the northbound direction may include information about changes in the radio state of the WiFi link. These may include, for example: changes in WiFi connection state (such as between connecting (after registration) and disconnecting); indications of changes in radio state of the 2.4 GHz, 5 GHz, 6 GHz and / or 60 GHz bands and / or channels; and / or indications of changes in persistent coexistence interference state.

[0083] Other northbound metadata that may be used in the system for the purpose of filtering the radio link quality (e.g., WiFi or cellular) includes indications of active link IDs and corresponding statuses (e.g., as serving carriers, serving slices, serving bearers, serving band-channel pairs, etc.); indications of candidate (ready-to-serve) link IDs and corresponding statuses (e.g., as serving carriers, serving slices, serving bearers, or serving band-channel pairs, etc.); indications of filtered RSRP, SINR, and / or Reference Signal Strength Indicator (RSSI), etc., for per-link or multi-link aggregation; and / or indications of maximum delay, packet loss rate (PLR), (WiFi) CCA (for channel occupancy purposes), etc., or their converted or corresponding metric application (category) IDs. Example of metadata used for QoE-aware link selection

[0084] Some implementation schemes for the target design of QoE-aware applications involve cellular (or for cellular-WiFi) link selection (e.g., as discussed in this paper).

[0085] Figure 4 Table 400 illustrates enhanced metadata for cellular link selection for application 402 using enhanced metadata, according to the implementation scheme discussed herein. As illustrated, applications 402 that can use enhanced and real-time metadata include (but are not limited to): video streaming applications; video conferencing applications; IP Multimedia Subsystem (IMS) Multimedia Telephony Service (MTSI) applications; Voice over Internet Protocol (VoIP) applications; and / or hybrid, enhanced, or virtual reality applications.

[0086] Furthermore, as shown in Table 400, various exemplary metadata types 404 are possible. Exemplary metadata type 404 can be based on three separate groups (in... Figure 1 The metadata is arranged into a first metadata group 406, a second metadata group 408 and a third metadata group 410 for consideration.

[0087] The first metadata group 406 corresponds to southbound QoE metadata (e.g., on a timescale of hundreds of milliseconds to several seconds, corresponding to or relating to application layer or codec / transport layer QoE metadata). As illustrated, examples of such metadata may include: average throughput or actual throughput (e.g., in megabits per second (mbps); maximum buffer size (e.g., in megabytes (MB)); video lag duration (e.g., on a timescale greater than 500 ms); corruption duration; inter-frame latency indication; jitter information (in ms); frame loss rate (as a percentage); and codec rate (in mbps).

[0088] The second metadata group 408 corresponds to northbound link state metadata (e.g., on a timescale of tens to hundreds of milliseconds, and corresponding to radio channels or carriers, etc.). As illustrated, examples of such metadata may include: packet loss rate (as a percentage); channel quality (e.g., as SINR, RSRP, a measurement in decibels (dB) or in decibel-milliwatts (dBm); and / or L1 / L2 link or channel resource allocation or occupancy (as a percentage).

[0089] The third metadata group 410 includes one-way metadata corresponding to the event trigger. Such metadata may include, for example: indications of RAT or radio link changes; indications of codec rate adjustments; and / or indications of QoE violations (e.g., frame loss rate (FLR) greater than 1 percent, number of stalls greater than a threshold, and occupancy greater than 80 percent).

[0090] In this context, exemplary metadata type 404 can be signaled within the device across different layers in a dedicated signaling control channel. Alternatively, they can be piggybacked onto southbound or northbound (as the case may be) data packets in a non-dedicated signaling channel.

[0091] In addition, the exemplary metadata type 404 can reflect the current state or represent a prediction of the upcoming state, and is used for proactive radio link changes (e.g., indicating that a radio carrier or channel is “ready” for a link addition, indicating link modification, indicating link removal, indicating link switching, etc.).

[0092] Therefore, in some examples, the baseband should be provided with an indication of the application's QoE metric in real time. This can allow for faster response or link selection in cases of relatively rare events such as video lag. Use enhanced metadata as time correlation across multiple time scales

[0093] In various implementations, it may be beneficial to perform link selection or RAT selection at the baseband based on enhanced metadata as QoE metadata (e.g., application layer QoE metadata arriving on a timescale of seconds and / or transport or codec layer metadata, such as states arriving on a timescale of RTT) and further based on L1-L2 metrics (arriving on a timescale of tens to hundreds of milliseconds).

[0094] Due to the different timescales of each metadata / metric set, correlation can be beneficial in ensuring that temporally corresponding / similar information is used as the basis for determining the relevance of link selection. Appropriate temporal correlations among these various metrics can be achieved by using timestamp-based cross-layer metrics or event matching across different (or common) timescales of various metrics.

[0095] For example, when QoE is compromised (e.g., video lag or short-duration pulse interference), the device can rule out core congestion by checking codec rate and L1-L2 metrics. The device then triggers a link selection mechanism when it detects both QoE and L1-L2 issues (rather than core network congestion). Therefore, this process takes into account the fact that a decrease in codec rate could be due to a last-hop bottleneck at L1-L2 (for which the link selection mechanism can be advantageously invoked), or due to CN-side congestion (a situation where link selection or link configuration reconfiguration procedures will not resolve).

[0096] The device may recognize a decrease in QoE metric (e.g., corresponding to throughput) and an occurrence of L1 / L2 congestion that subsequently decreases (e.g., due to codec rate backoff). In such cases, where the QoE event (e.g., video quality degradation or stagnation) or codec rate degradation corresponds temporally to an instance of L1 / L2 congestion (e.g., occurring exactly after that instance) (in other words, packet dropping or buffer building occurring at / in L1 / L2 exactly before the QoE event), the device can trigger a link selection mechanism. In this way, the device accordingly excludes CN congestion situations and knows that the link selection mechanism can be advantageously used.

[0097] It is conceivable that this process could be used, for example, in situations where high-definition (HD) streaming uses codec rate adaptation to respond to L1-L2 problems.

[0098] When L1-L2 QoS is compromised (e.g., when packet loss or queue accumulation occurs), it is conceivable that mobility, handover (HO), radio link control (RLC), or hybrid automatic repeat request (HARQ) retransmissions can cover the relevant issues on smaller timescales (e.g., exceeding tens of milliseconds). Regarding issues on such smaller timescales, note that overall QoE can still be acceptable considering larger timescales exceeding 100 ms or several seconds. Therefore, QoE-related mechanisms as discussed herein can be configured to operate about / on (e.g., only) these larger timescales (although this is not strictly required).

[0099] Figure 5 Figure 500 illustrates a time-related method for enhancing metadata across different time scales for the purpose of link selection, according to the implementation scheme discussed herein. Figure 500 illustrates examples of time-related cross-layer metadata or events 502 (e.g., the enhanced metadata discussed herein) that can be used in link selection determination, and time scales 504 corresponding to the elements of the time-related cross-layer metadata or events 502.

[0100] At the host application layer 506, the device can be configured to implement application-specific link selection or RAT selection 508 (e.g., in response to issues such as Evolved Packet System (EPS) fallback (EPSFB) and / or video stagnation, as illustrated). As shown, the timescale of this behavior can be from 0.5 seconds to 3 seconds. For example, the link or RAT selection timescale information 510 illustrates a RAN determination of 500ms in an example case corresponding to EPSFB, which can extend to approximately three seconds, taking CN latency into account. Furthermore, in an example case corresponding to SCG fault detection, the relevant determination might take approximately two seconds.

[0101] Furthermore, the device can be configured to implement codec rate adaptation 512 on an end-to-end basis. As illustrated, this behavior can correspond to an RTT of approximately 200ms to 300ms and can be considered to encompass aspects of the host application layer 506 and aspects of the medium / channel 514 (e.g., when considering congestion and / or video frame loss at the transport / IP layer).

[0102] At L2 / L3 layer 516, the device can be configured to implement L2 link selection 518. As illustrated, this functionality can involve the switching, addition, and modification of carriers, slices, etc., as described herein. As shown, the timescale of this behavior can range from approximately 45 ms to 200 ms. For example, L2 link selection timescale information 520 illustrates an example where the HO dwell time (ToS) timer is set to one second in an example corresponding to an SCG release triggered by the UE but responded to by the CN / network. As another example, the RAT-inter-A2+B1 measurement gap (MGAP) can run for approximately 6 ms within a synchronization signal block (SSB) (e.g., 5 ms every 20 ms, 40 ms, or 80 ms). As another example, the trigger time (TTT) can last between 160 ms and 500 ms. As another example, the measurement timing (MO) can be configured within 3 seconds of a 60-second period.

[0103] Furthermore, the device's L2 / L3 layer 516 can be configured to implement L2 UE-UPF resource scheduling 522. As shown in the figure, the timescale of such behavior can be in the range of approximately 10 ms.

[0104] At L1 layer 524, the device can be configured to implement BWP or beam switching 526. As illustrated, the timescale for such behavior can range from 3ms to 20ms. As an example, BWP or beam switching timescale information 528 illustrates that the BWP switching latency can be approximately 16ms (for RRC-based cases), or approximately 3ms to 5ms (for downlink control information (DCI-based cases) (excluding one-second disable timers). Triggers can be the presence of a data rate of less than 15 Mbps for 15 seconds during NR screen off indication activity, and / or UE assistance information (UAI) corresponding to a signaling latency of approximately 8ms. Given these typical timescales at L1, the application of QoE-aware L1 control or L1-aware QoE adaptation may be significantly more difficult than at larger timescales (e.g., approximately 500ms), and therefore in some implementations, it may be adopted (e.g., only) in cases corresponding to critical real-time metadata exchange.

[0105] Furthermore, the L1 layer 524 of the device can be configured to implement rate adaptation / HARQ / channel state information (CSI) 530. As illustrated, the timescale for such behavior can be four milliseconds or less. For example, the rate adaptation / HARQ / CSI timescale information 532 illustrates the case for CSI compression and feedback (as opposed to the sounding reference signal (SRS) case), where a channel quality indicator (CQI) plus an acknowledgment (ACK) / negative acknowledgment (NACK) plus a scheduling request (SR) reporting interval can be used, the predecoder matrix indicator (PMI) can appear once per subframe, and the rank indicator can correspond to 10 ms. In contrast, these timescales are also much smaller than link adaptation or QoE measurements, and therefore, in some implementations, QoE awareness can be combined (e.g., only) in cases corresponding to technical warnings and critical real-time metadata exchanges.

[0106] Figure 500 illustrates the use of enhanced metadata 534 as described herein (e.g., QoE metadata (whether from the application layer and / or transport / codec layer) and link state / lower layer metadata, as illustrated). Using this enhanced metadata ensures that the correspondence between the host application layer 506 and the L2 / L3 layer 516 for relevant QoE link event detection 536 (e.g., for link selection purposes) conforms to the discussion herein.

[0107] Note that while the various examples in this article involve link selection, it is conceivable that QoE-aware applications could use the enhanced metadata for other purposes, such as QoE-based traffic control, traffic service prioritization, queuing differentiation, and data packet prioritization. Examples of logs, traces, and timestamped events

[0108] In some implementations, the use of the implementations disclosed herein may correspond to logs / traces / events that match the definition of enhanced metadata and their use via the API.

[0109] An example is now provided in the context of link selection. Figure 6 Figure 600 illustrates a corresponding implementation of link selection using enhanced metadata in a QoE-aware context, based on the scheme discussed herein. In such examples, applicable data analytics tools (e.g., Apple Wireless Analytics) can be used, and RAT or link selection refers to an L1-L2 RAT / link change triggered by an SCG failure or release rather than a HO command issued by the network. Figure 600 can be understood as corresponding to / a simplified version of Figure 500 previously discussed herein, which illustrates various aspects that can be logged / tracked.

[0110] In some implementations, L1-L2 logs can be viewed as snapshots or statistics (e.g., counts).

[0111] In addition, for specific directional metrics, (time-based) event-driven logs (snapshots or time series / traces) can be collected. These metrics span multiple layers, such as at the host or modem. Events can be visible to the modem or host (e.g., changes in RAT or cellular carrier).

[0112] In this context, various tools can be used to log one or more event types. The first event type that can be logged is the link or RAT selection event type. For example, changes between WiFi and LTE and 5G, changes between PSCell and SCell, changes between PCell and SCell, and / or cases of split bearer addition and / or removal can be logged. Other examples of events that can be logged may include internal (algorithm) triggers, UE-triggered SCG failures or SCG releases, etc.

[0113] The second type of event that can be recorded is a video or audio freeze event. For example, a video freeze time longer than yms can be recorded (where, for example, y=350ms).

[0114] The third type of event that can be recorded is the video / audio frame loss event type. For example, a video and / or audio frame loss rate greater than x% can be recorded (where, for example, x=2).

[0115] In addition, the tool can be used to record one or more timestamped traces (time series) around an event within a range of +X / -X seconds (e.g., around +5 / -5 seconds). Some examples of time-related traces for L1-L2 (e.g., lower layer) metrics include: traces corresponding to the RSRP and / or SINR of the channel; traces of PDU loss rate (e.g., as a percentage, averaged over a sliding window, (e.g., a size of 2-10 X in seconds)); TBS traces or (sampled, Xs-) filtered / averaged throughput traces; and traces corresponding to TF resource allocation (e.g., as a percentage of physical resource blocks (PRBs) allocated over the bandwidth (BW) and over a 10ms to 25ms window).

[0116] Some examples of time-related tracking of QoE metrics include: tracking of applied I-frame or P-frame loss rates, represented by an estimate of L_E over a specific time window (e.g., greater than two percent); tracking of changes in Real-Time Transport Protocol (RTP) level recording and / or codec rates (e.g., given Hypertext Transfer Protocol (HTTP) Dynamic Adaptive Streaming (DASH) or HTTP Real-Time Streaming (HLS) codec adaptation); tracking of video stagnation periods; (sampled, Xs-)filtering / average throughput tracking; and traffic tracking (e.g., video I-frame size and inter-frame interval).

[0117] Furthermore, these tools can be used to record timestamped snapshots of metrics such as those described in this article. These snapshots can represent immediate samples of metrics corresponding to the occurrence of an event.

[0118] Figure 7 A method 700 for a UE according to the embodiments discussed herein is illustrated. Method 700 includes identifying 702 at the application layer of the UE that a QoE metric for a service of an application operating on the UE at the application layer has corresponded to a first-time degradation. Method 700 further includes receiving 704 first metadata from one or more lower layers below the application layer of the UE at the application layer, the first metadata including a value for a lower-layer metric corresponding to the first time, wherein the value for the lower-layer metric indicates service degradation corresponding to one or more lower layers at the first time. Method 700 further includes receiving 706 second metadata from one or more lower layers at the application layer, the second metadata identifying a new data link configuration that can be used to better satisfy the QoE metric for the service. Method 700 further includes transmitting 708 third metadata from the application layer to one or more lower layers based on the degradation corresponding to the first-time QoE metric and the service degradation corresponding to one or more lower layers at the first time, the third metadata indicating that a new data link configuration should be used for the service at one or more lower layers.

[0119] In some implementations of method 700, the QoE metric includes an application-layer QoE metric.

[0120] In some implementations of method 700, identifying a degraded QoE metric for a service includes identifying one or more of the following based on the value of the QoE metric: video lag or short bursts of interference in the service; reduced resolution in the service; latency in the service; session drops in the service; and frame loss in the service.

[0121] In some embodiments of method 700, the QoE metric includes a transport layer QoE metric, and also includes fourth metadata received at the application layer from the UE's transport layer, which includes the value of the QoE metric.

[0122] In some implementations of method 700, the QoE metric of the identity service has degraded due to sudden codec rate changes at the identity transport layer.

[0123] In some embodiments of method 700, one or more of the first metadata, second metadata, and third metadata are transmitted between the application layer and one or more lower layers on a dedicated control channel that operates directly between the application layer and one or more lower layers.

[0124] In some embodiments, method 700 further includes: transmitting fourth metadata from the application layer to one or more lower layers, the fourth metadata identifying one or more application-preferred data links preferred by the application. In some such embodiments, method 700 further includes: transmitting fifth metadata from the application layer to one or more lower layers, the fifth metadata requesting identification of one or more identified data links from one or more lower layers; receiving sixth metadata at the application layer from one or more lower layers indicating one or more identified data links; and at the application layer, identifying one or more application-preferred data links preferred by the application from among the one or more identified data links.

[0125] In some implementations of method 700, the application includes a real-time session application.

[0126] In some implementations of method 700, one or more lower layers include a data link layer.

[0127] In some implementations of method 700, the new data link configuration includes a new data link.

[0128] In some implementations of method 700, the new data link configuration includes a new codec rate.

[0129] In some implementations of method 700, the new data link configuration includes a new flow priority ordering of traffic on the existing data link.

[0130] In some implementations of method 700, the new data link configuration includes a new packet queuing priority for the existing data link.

[0131] Figure 8 A method for a UE according to the implementation scheme discussed herein is illustrated. Method 800 includes: receiving 802 first metadata at one or more lower layers of the UE below the application layer of the UE, the first metadata including a value of a QoE metric corresponding to a service of an application operating on the UE at a first time in the application layer. Method 800 further includes: identifying 804 that the QoE metric has corresponded to a first-time degradation based on the value of the QoE metric at one or more lower layers. Method 800 further includes: identifying 806 that service degradation corresponds to one or more lower layers at the first time at one or more lower layers. Method 800 further includes: selecting 808 a new data link configuration for service based on the degradation of the QoE metric corresponding to the first time and the service degradation corresponding to one or more lower layers at the first time.

[0132] In some implementations of method 800, the QoE metric includes an application-layer QoE metric.

[0133] In some implementations of method 800, identifying a degraded QoE metric for the service includes identifying one or more of the following based on the value of the QoE metric: video stagnation or short bursts of interference in the service; resolution degradation in the service; latency in the service; session dropouts in the service; and frame loss in the service.

[0134] In some implementations of method 800, the QoE metric includes a transport layer QoE metric.

[0135] In some implementations of method 800, identifying service QoE metric degradation includes identifying sudden codec rate changes at the transport layer based on the value of the QoE metric found in the first metadata.

[0136] In some implementations of method 800, the first metadata is transmitted over a dedicated control channel that operates directly between the application layer and one or more lower layers.

[0137] In some implementations, method 800 further includes transmitting second metadata identifying the new data link from one or more lower layers to the application layer.

[0138] In some embodiments, method 800 further includes: receiving, at one or more lower layers, second metadata identifying one or more application-preferred data links preferred by the application from the application layer, wherein the new data link is configured to use a new data link selected from the one or more application-preferred data links. In some such embodiments, method 800 further includes: receiving, at one or more lower layers, third metadata requesting identification of one or more identified data links from the one or more lower layers; and transmitting, from the one or more lower layers to the application layer, fourth metadata indicating the one or more identified data links; wherein the one or more application-preferred data links originate from the one or more identified data links.

[0139] In some implementations of method 800, the application includes a real-time session application.

[0140] In some implementations of method 800, one or more lower layers include a data link layer.

[0141] In some implementations of method 800, the new data link configuration includes a new data link.

[0142] In some implementations of method 800, the new data link configuration includes a new codec rate.

[0143] In some implementations of method 800, the new data link configuration includes a new flow priority ordering of traffic on the existing data link.

[0144] In some implementations of method 800, the new data link configuration includes a new packet queuing priority for the existing data link.

[0145] Figure 9 A method 900 for a UE according to the implementation discussed herein is illustrated. Method 900 includes identifying 902, at the application layer of the UE, that the QoE metric of a service operated on the UE by an application at the application layer has degraded. Method 900 also includes determining 904 that lower-layer optimizations can be applied at one or more lower layers below the application layer of the UE to better meet the QoE metric of the service. Method 900 further includes transmitting 906, metadata from the application layer to one or more lower layers indicating that lower-layer optimizations should be applied at one or more lower layers.

[0146] In some implementations of method 900, the lower-level optimization is traffic priority ranking optimization.

[0147] In some implementations of method 900, the lower-level optimization is grouping priority sorting optimization.

[0148] In some implementations of method 900, the lower-layer optimization is link configuration optimization.

[0149] In some embodiments of method 900, metadata is transmitted between the application layer and one or more lower layers over a dedicated control channel that operates directly between the application layer and one or more lower layers.

[0150] In some implementations of method 900, the application includes a real-time session application.

[0151] In some implementations of method 900, one or more lower layers include a data link layer.

[0152] Figure 10 An example architecture of a wireless communication system 1000 according to an embodiment disclosed herein is illustrated. The following description is for an example wireless communication system 1000 operating in conjunction with LTE system standards and / or 5G or NR system standards provided by 3GPP technical specifications.

[0153] like Figure 10 As shown, the wireless communication system 1000 includes UE 1002 and UE 1004 (but any number of UEs may be used). In this example, UE 1002 and UE 1004 are exemplified as smartphones (e.g., handheld touchscreen mobile computing devices capable of connecting to one or more cellular networks), but may also include any mobile or non-mobile computing device configured for wireless communication.

[0154] UE 1002 and UE 1004 can be configured to be communicatively coupled to RAN 1006. In an implementation, RAN 1006 can be NG-RAN, E-UTRAN, etc. UE 1002 and UE 1004 utilize connections (or channels) with RAN 1006 (shown as connection 1008 and connection 1010, respectively), where each connection includes a physical communication interface. RAN 1006 may include one or more base stations (such as base station 1012 and base station 1014) implementing connection 1008 and connection 1010.

[0155] In this example, Connection 1008 and Connection 1010 are air interfaces that implement this type of communication coupling and can conform to the RAT used by RAN 1006, such as LTE and / or NR, for example.

[0156] In some implementations, UE 1002 and UE 1004 may also exchange communication data directly via sidelink interface 1016. UE 1004 is shown configured to access an access point (shown as AP 1018) via connection 1020. By way of example, connection 1020 may include a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, wherein AP 1018 may include Wi-Fi. ®Router. In this example, AP 1018 can connect to another network (e.g., the Internet) without going through CN 1024.

[0157] In the implementation, UE 1002 and UE 1004 may be configured to communicate with each other or with base station 1012 and / or base station 1014 on a multi-carrier communication channel using orthogonal frequency division multiplexing (OFDM) communication signals according to various communication technologies, such as but not limited to orthogonal frequency division multiple access (OFDMA) communication technology (e.g., for downlink communication) or single-carrier frequency division multiple access (SC-FDMA) communication technology (e.g., for uplink and ProSe or sidelink communication), but the scope of the implementation is not limited in this respect. The OFDM signal may include multiple orthogonal subcarriers.

[0158] In some implementations, all or some of the base stations in base station 1012 or base station 1014 may be implemented as one or more software entities running on a server computer as part of a virtual network. Furthermore, or in other implementations, base station 1012 or base station 1014 may be configured to communicate with each other via interface 1022. In implementations where the wireless communication system 1000 is an LTE system (e.g., when CN 1024 is an EPC), interface 1022 may be an X2 interface. The X2 interface may be defined between two or more base stations (e.g., two or more eNBs, etc.) connected to the EPC and / or between two eNBs connected to the EPC. In implementations where the wireless communication system 1000 is an NR system (e.g., when CN 1024 is a 5GC), interface 1022 may be an Xn interface. The Xn interface is defined between two or more base stations (e.g., two or more gNBs, etc.) connected to the 5GC, between base station 1012 (e.g., a gNB) connected to the 5GC and an eNB, and / or between two eNBs connected to the 5GC (e.g., CN 1024).

[0159] RAN 1006 is shown communicatively coupled to CN 1024. CN 1024 may include one or more network elements 1026 configured to provide various data and telecommunications services to customers / subscribers (e.g., users of UE 1002 and UE 1004) connected to CN 1024 via RAN 1006. Components of CN 1024 may be implemented in a single physical device or a separate physical device including components for reading and executing instructions from machine-readable or computer-readable media (e.g., non-transitory machine-readable storage media).

[0160] In this implementation, CN 1024 may be an EPC, and RAN 1006 may be connected to CN 1024 via S1 interface 1028. In this implementation, S1 interface 1028 may be divided into two parts: an S1 user plane (S1-U) interface, which carries service data between base station 1012 or base station 1014 and the serving gateway (S-GW); and an S1-MME interface, which is the signaling interface between base station 1012 or base station 1014 and the mobility management entity (MME).

[0161] In this implementation, CN 1024 may be a 5GC, and RAN 1006 may be connected to CN 1024 via NG interface 1028. In this implementation, NG interface 1028 may be divided into two parts: an NG user plane (NG-U) interface, which carries service data between base station 1012 or base station 1014 and the User Plane Function (UPF); and an S1 control plane (NG-C) interface, which is the signaling interface between base station 1012 or base station 1014 and the Access and Mobility Management Function (AMF).

[0162] Generally, application server 1030 may be an element that provides Internet Protocol (IP) bearer resources (e.g., packet-switched data services) for use with CN 1024. Application server 1030 may also be configured to support one or more communication services (e.g., VoIP sessions, group communication sessions, etc.) for UE 1002 and UE 1004 via CN 1024. Application server 1030 can communicate with CN 1024 via IP communication interface 1032.

[0163] Figure 11 A system 1100 for performing signaling 1132 between a wireless device 1102 and a network device 1118, according to an embodiment disclosed herein, is illustrated. System 1100 may be part of a wireless communication system as described herein. Wireless device 1102 may be, for example, a UE of a wireless communication system. Network device 1118 may be, for example, a base station (e.g., an eNB or gNB) of a wireless communication system.

[0164] Wireless device 1102 may include one or more processors 1104. Processor 1104 is executable instructions that enable various operations of wireless device 1102 to be performed as described herein. Processor 1104 may include one or more baseband processors, which are implemented using, for example, a CPU, digital signal processor (DSP), application-specific integrated circuit (ASIC), controller, field-programmable gate array (FPGA) device, another hardware device, firmware device, or any combination thereof configured to perform the operations described herein.

[0165] Wireless device 1102 may include memory 1106. Memory 1106 may be a non-transitory computer-readable storage medium that stores instructions 1108, which may include, for example, instructions executed by processor 1104. Instructions 1108 may also be referred to as program code or a computer program. Memory 1106 may also store data used by processor 1104 and results calculated by the processor.

[0166] Wireless device 1102 may include one or more transceivers 1110, which may include radio frequency (RF) transmitter circuitry and / or receiver circuitry that use antenna 1112 of wireless device 1102 to facilitate signaling (e.g., signaling 1132) to and / or from wireless device 1102 and other devices (e.g., network device 1118) according to the corresponding RAT.

[0167] Wireless device 1102 may include one or more antennas 1112 (e.g., one, two, four or more). In embodiments with multiple antennas 1112, wireless device 1102 may utilize spatial diversity of such multiple antennas 1112 to transmit and / or receive multiple different data streams on the same time-frequency resource. This behavior may be referred to as, for example, multiple-input multiple-output (MIMO) behavior (referring to multiple antennas used at each of the transmitting and receiving devices to implement this aspect). MIMO transmission by wireless device 1102 may be achieved according to pre-decoding (or digital beamforming) applied at wireless device 1102, which multiplexes data streams across antennas 1112 based on known or assumed channel characteristics, such that each data stream is received with appropriate signal strength relative to the other streams at a desired location in the spatial domain (e.g., the location of the receiver associated with that data stream). Some implementations may use a single-user MIMO (SU-MIMO) approach (where all data streams are directed to a single receiver) and / or a multi-user MIMO (MU-MIMO) approach (where individual data streams may be directed to individual (different) receivers at different locations in the spatial domain).

[0168] In some implementations with multiple antennas, wireless device 1102 may implement analog beamforming technology, whereby the phase of the signal transmitted by antenna 1112 is relatively adjusted so that the (joint) transmission of antenna 1112 can be directed (this is sometimes referred to as beam control).

[0169] Wireless device 1102 may include one or more interfaces 1114. Interfaces 1114 can be used to provide input to or output to wireless device 1102. For example, wireless device 1102 as a UE may include interfaces 1114, such as microphones, speakers, touchscreens, and buttons, to allow users of the UE to make inputs and / or outputs to the UE. Other interfaces of such UEs may consist of transmitters, receivers, and other circuitry that allow the UE to communicate with other devices (e.g., in addition to the transceiver 1110 / antenna 1112 already described), and may be based on known protocols (e.g., Wi-Fi). ® and Bluetooth ® (etc.) to perform the operation.

[0170] Wireless device 1102 may include an enhanced metadata module 1116. The enhanced metadata module 1116 may be implemented via hardware, software, or a combination thereof. For example, the enhanced metadata module 1116 may be implemented as a processor, circuitry, and / or instructions 1108 stored in memory 1106 and executed by processor 1104. In some examples, the enhanced metadata module 1116 may be integrated within processor 1104 and / or transceiver 1110. For example, the enhanced metadata module 1116 may be implemented via a combination of software components (e.g., executed by a DSP or general-purpose processor) and hardware components (e.g., logic gates and circuitry) within processor 1104 or transceiver 1110.

[0171] The enhanced metadata module 1116 can be used in various aspects of this disclosure, for example, Figures 1 to 9 In all aspects. Wireless device 1102 may use enhanced metadata module 1116 to, for example, generate, transmit and / or use enhanced metadata (e.g., having QoE metadata with QoE state information and / or lower-layer metadata with lower-layer (e.g., link state) information), as discussed herein.

[0172] Network device 1118 may include one or more processors 1120. Processor 1120 is executable instructions that cause various operations of network device 1118 to be performed as described herein. Processor 1120 may include one or more baseband processors, which are implemented using, for example, a CPU, DSP, ASIC, controller, FPGA device, another hardware device, firmware device, or any combination thereof configured to perform the operations described herein.

[0173] Network device 1118 may include memory 1122. Memory 1122 may be a non-transitory computer-readable storage medium that stores instructions 1124, which may include, for example, instructions executed by processor 1120. Instructions 1124 may also be referred to as program code or a computer program. Memory 1122 may also store data used by processor 1120 and results calculated by the processor.

[0174] Network device 1118 may include one or more transceivers 1126, which may include RF transmitter circuitry and / or receiver circuitry that uses the antenna 1128 of network device 1118 to facilitate signaling (e.g., signaling 1132) to and / or from network device 1118 and other devices (e.g., wireless device 1102) according to the corresponding RAT.

[0175] Network device 1118 may include one or more antennas 1128 (e.g., one, two, four or more). In embodiments having multiple antennas 1128, network device 1118 may perform MIMO, digital beamforming, analog beamforming, beam control, etc., as described.

[0176] Network device 1118 may include one or more interfaces 1130. Interface 1130 can be used to provide input to or output to network device 1118. For example, network device 1118 as a base station may include interface 1130 consisting of transmitters, receivers and other circuitry (e.g., in addition to the transceiver 1126 / antenna 1128 already described), which enable the base station to communicate with other equipment in the core network and / or enable the base station to communicate with external networks, computers and databases, etc., for the purpose of performing operations, management and maintenance of the base station or other equipment operatively connected to the base station.

[0177] The embodiments contemplated herein include an apparatus comprising components for performing one or more elements of one or more of methods 700, 800, and 900. The apparatus may be, for example, a UE (such as wireless device 1102 as a UE, as described herein).

[0178] The embodiments contemplated herein include one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of one or more of methods 700, 800, and 900. The non-transitory computer-readable medium may, for example, be a memory of a UE (such as memory 1106 of a wireless device 1102 serving as a UE, as described herein).

[0179] The embodiments contemplated herein include an apparatus comprising logic components, modules, or circuitry for performing one or more elements of one or more of methods 700, 800, and 900. The apparatus may be, for example, a UE (such as wireless device 1102 as a UE, as described herein).

[0180] The embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of one or more of methods 700, 800, and 900. The apparatus may be, for example, a UE (such as wireless device 1102 as a UE, as described herein).

[0181] The implementation schemes envisioned herein include signals as described in or associated with one or more elements of one or more of methods 700, 800, and 900.

[0182] The embodiments contemplated herein include a computer program or computer program product comprising instructions, wherein execution by a processor causes the processor to perform one or more elements of one or more of methods 700, 800, and 900. The processor may be a processor of the UE (such as processor 1104 as a wireless device 1102 of the UE, as described herein). These instructions may, for example, reside in the processor and / or in the memory of the UE (such as memory 1106 as a wireless device 1102 of the UE, as described herein).

[0183] For one or more embodiments, at least one of the components illustrated in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, and / or methods as described herein. For example, a baseband processor as described herein in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples illustrated herein. Similarly, circuitry associated with a UE, base station, network element, etc., as described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples illustrated herein.

[0184] Unless otherwise expressly stated, any of the embodiments described above may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific embodiments provides illustrative and descriptive information, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. In light of the teachings above, modifications and variations are possible, or modifications and variations may be derived from practice with various embodiments.

[0185] Implementations and specific embodiments of the systems and methods described herein may include various operations embodied in machine-executable instructions to be executed by a computer system. The computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system may include hardware components, including specific logical parts for performing the operations; or may include a combination of hardware, software, and / or firmware.

[0186] It should be recognized that the systems described herein include descriptions of specific implementations. These implementations may be combined into a single system, partially integrated into other systems, divided into multiple systems, or otherwise partitioned or combined. Furthermore, it is conceivable to use parameters, attributes, aspects, etc., of one implementation in one implementation. For clarity, these parameters, attributes, aspects, etc., are described only in one or more implementations, and it should be recognized that, unless expressly stated herein, these parameters, attributes, aspects, etc., may be combined with or replace parameters, attributes, aspects, etc., of another implementation.

[0187] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0188] Although the foregoing has been described in considerable detail for the purpose of clarity, it will be apparent that certain changes and modifications may be made without departing from the principles of the invention. It should be noted that there are many alternative ways to implement both the processes and apparatus described herein. Therefore, embodiments of the invention should be considered illustrative rather than restrictive, and this specification is not limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims

1. A method for a user equipment (UE), the method comprising: At the application layer of the UE, the quality of experience (QoE) metric of the service of the application operating on the UE in the application layer has already corresponded to the first-time degradation; At the application layer, the UE receives first metadata from one or more lower layers below the application layer, the first metadata including a value for a lower layer metric corresponding to the first time, wherein the value for the lower layer metric indicates service degradation at the one or more lower layers corresponding to the first time; At the application layer, second metadata is received from one or more lower layers, the second metadata identifying a new data link configuration that can be used to better satisfy the QoE metric of the service; as well as Based on the degradation of the QoE metric corresponding to the first time and the service degradation at the one or more lower layers corresponding to the first time, third metadata is transmitted from the application layer to the one or more lower layers, the third metadata indicating that the new data link configuration should be used for the service at the one or more lower layers.

2. The method according to claim 1, wherein the QoE metric includes an application-layer QoE metric.

3. The method of claim 1, wherein identifying that the QoE metric of the service has deteriorated includes identifying one or more of the following based on the value of the QoE metric: Video freezes or short-duration pulse interference in the service; The resolution is reduced in the service; Delays in the service; The session in the service was disconnected; and Frame loss occurred in the service.

4. The method of claim 1, wherein the QoE metric includes a transport layer QoE metric, and the method further comprises: At the application layer, fourth metadata, including the value of the QoE metric, is received from the transport layer of the UE.

5. The method of claim 1, wherein identifying that the QoE metric of the service has deteriorated includes identifying a sudden change in codec rate at the transport layer.

6. The method of claim 1, wherein one or more of the first metadata, the second metadata, and the third metadata are transmitted between the application layer and the one or more lower layers on a dedicated control channel operating directly between the application layer and the one or more lower layers.

7. The method according to claim 1, further comprising: A fourth metadata is transmitted from the application layer to the one or more lower layers, the fourth metadata identifying one or more application-preferred data links preferred by the application.

8. The method according to claim 7, further comprising: Fifth metadata is transmitted from the application layer to the one or more lower layers, the fifth metadata requesting identification of one or more identified data links from the one or more lower layers; At the application layer, sixth metadata indicating the one or more identified data links is received from the one or more lower layers; as well as At the application layer, the application-preferred data link is identified from the one or more identified data links.

9. The method of claim 1, wherein the application includes a real-time session application.

10. The method of claim 1, wherein the one or more lower layers include a data link layer.

11. The method of claim 1, wherein the new data link configuration includes a new data link.

12. The method of claim 1, wherein the new data link configuration includes a new codec rate.

13. The method of claim 1, wherein the new data link configuration includes a new flow priority ordering of traffic on the existing data link.

14. The method of claim 1, wherein the new data link configuration includes a new packet queuing priority for the existing data link.

15. A method for a user equipment (UE), the method comprising: The first metadata is received at one or more lower layers of the UE below the application layer of the UE. The first metadata includes a value of the quality of experience (QoE) metric of the service of the application operating on the UE in the application layer at a first time. At one or more lower layers, the value of the QoE metric is used to identify whether the QoE metric has corresponded to the first time-deterioration; At one or more lower layers, identify the service degradation corresponding to the first time at one or more lower layers; as well as A new data link configuration for the service is selected based on the degradation of the QoE metric corresponding to the first time and the service degradation at one or more lower layers corresponding to the first time.

16. The method of claim 15, wherein the QoE metric includes an application-layer QoE metric.

17. The method of claim 15, wherein identifying that the QoE metric of the service has deteriorated includes identifying one or more of the following based on the value of the QoE metric: Video freezes or short-duration pulse interference in the service; The resolution is reduced in the service; Delays in the service; The session in the service was disconnected; and Frame loss occurred in the service.

18. The method of claim 15, wherein the QoE metric includes a transport layer QoE metric.

19. The method of claim 15, wherein identifying that the QoE metric of the service has deteriorated comprises: The sudden codec rate change at the transport layer is identified based on the value of the QoE metric found in the first metadata.

20. The method of claim 15, wherein the first metadata is transmitted on a dedicated control channel operating directly between the application layer and the one or more lower layers.

21. The method according to claim 15, further comprising: Secondary metadata identifying the new data link is transmitted from one or more lower layers to the application layer.

22. The method according to claim 15, further comprising: At one or more lower layers, second metadata identifying one or more application-preferred data links preferred by the application is received from the application layer, wherein the new data link is configured to use a new data link selected from the one or more application-preferred data links.

23. The method according to claim 22, further comprising: Receive third metadata from the application layer at one or more lower layers, the third metadata requesting an identification of one or more identified data links from the one or more lower layers; as well as Transmit fourth metadata indicating the one or more identified data links from the one or more lower layers to the application layer; The preferred data link for the one or more applications is derived from the one or more identified data links.

24. The method of claim 22, wherein the application includes a real-time session application.

25. The method of claim 22, wherein the one or more lower layers include a data link layer.

26. The method of claim 22, wherein the new data link configuration includes the new data link.

27. The method of claim 22, wherein the new data link configuration includes a new codec rate.

28. The method of claim 22, wherein the new data link configuration includes a new flow priority ordering of traffic on the existing data link.

29. The method of claim 22, wherein the new data link configuration includes a new packet queuing priority for the existing data link.

30. A method for a user equipment (UE), the method comprising: At the application layer of the UE, the quality of experience (QoE) metric for the services of the applications operating on the UE in the application layer has deteriorated; Determine that lower-layer optimizations can be applied at one or more lower layers below the application layer of the UE to better meet the QoE metric of the service; as well as The application layer transmits metadata indicating that the lower-level optimizations should be applied at the one or more lower layers.

31. The method of claim 30, wherein the lower-level optimization is traffic priority ranking optimization.

32. The method of claim 30, wherein the lower-level optimization is a grouping priority sorting optimization.

33. The method of claim 30, wherein the lower-layer optimization is link configuration optimization.

34. The method of claim 30, wherein the metadata is transmitted between the application layer and the one or more lower layers on a dedicated control channel operating directly between the application layer and the one or more lower layers.

35. The method of claim 30, wherein the application includes a real-time session application.

36. The method of claim 30, wherein the one or more lower layers include a data link layer.

37. An apparatus comprising components for performing the method according to any one of claims 1 to 36.

38. A computer-readable medium comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform the method according to any one of claims 1 to 36.

39. An apparatus comprising a logic component, module, or circuit for performing the method according to any one of claims 1 to 36.

40. A baseband processor for a user equipment (UE), the baseband processor being configured to cause the UE to perform one or more elements according to any one of claims 1 to 36.

Images