Patent Description:
These systems may be capable of supporting communication with multiple users by sharing available system resources (e.g., time, frequency, and power). Examples of such multiple-access systems include fourth generation (<NUM>) systems such as LongTerm Evolution (LTE) systems, LTE-Advanced (LTE-A) systems, or LTE-A Pro systems, and fifth generation (<NUM>) systems which may be referred to as New Radio (NR) systems. These systems may employ technologies such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (OFDMA), or discrete Fourier transform-spread-OFDM (DFT-S-OFDM). A wireless multiple-access communications system may include a number of base stations or network access nodes, each simultaneously supporting communication for multiple communication devices, which may otherwise be known as user equipment (UE). Multi-Access Edge Servers (MEC) may also be deployed.

Resources such as power may become limited when there is a high demand for such resources. In some cases, there is a need to simultaneously support multiple devices competing for the same resources in a wireless communication system. In some cases, user requirements may involve complex computations resulting in slower processing, high power use and latency. Techniques for resource optimization in a wireless communication system are needed.

<NPL>" and <NPL>" suggest that knowledge of TSN traffic pattern is useful for the gNB to allow it more efficiently schedule traffic.

Section <NUM> of 3GPP TR <NUM> v16. <NUM> discloses solutions for QoS negotiation between 3GPP and TSN networks.

The following summarizes some aspects of the present disclosure to provide a basic understanding of the discussed technology. Its sole purpose is to present some concepts of one or more aspects of the disclosure in summary form as a prelude to the more detailed description that is presented later.

The present disclosure provides a method for wireless communication according to claim <NUM>, a non-transitory computer-readable medium according to claim <NUM>, and an apparatus according to claim <NUM>. Specific embodiments are subject of the dependent claims.

While aspects and embodiments are described in this application by illustration to some examples, those skilled in the art will understand that additional implementations and use cases may come about in many different arrangements and scenarios. Innovations described herein may be implemented across many differing platform types, devices, systems, shapes, sizes, packaging arrangements. For example, embodiments and/or uses may come about via integrated chip embodiments and other non-module-component based devices (e.g., end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail/purchasing devices, medical devices, AI-enabled devices, etc.). While some examples may or may not be specifically directed to use cases or applications, a wide assortment of applicability of described innovations may occur. Implementations may range in spectrum from chip-level or modular components to non-modular, non-chip-level implementations and further to aggregate, distributed, or OEM devices or systems incorporating one or more aspects of the described innovations. In some practical settings, devices incorporating described aspects and features may also necessarily include additional components and features for implementation and practice of claimed and described embodiments. For example, transmission and reception of wireless signals necessarily includes a number of components for analog and digital purposes (e.g., hardware components including antenna, RF-chains, power amplifiers, modulators, buffer, processor(s), interleaver, adders/summers, etc.). It is intended that innovations described herein may be practiced in a wide variety of devices, chip-level components, systems, distributed arrangements, end-user devices, etc. of varying sizes, shapes, and constitution.

The availability of computation resources on a user equipment (UE) may become limited due to restrictions in form-factor, cost, power, etc. To better manage resources or increase system capacity, computations may be shared among devices and servers. In examples, computations may be shared between a device and a server (or multiple servers). One such server may be an edge server, such as a multi-access server (MEC). The UE and edge server may be connected to each other via a low latency transport link. The server may be located near the low-latency transport system to reduce latency. The server may additionally be coupled to one or more Data Networks (DN), such as may comprise local and/or central data networks, to facilitate the computations and/or other functions provided through server operation.

For example, virtual reality (VR) split rendering (VRSR) provides for offloading to a server, a portion of computations required to display an interactive virtual reality scene on a display device (e.g., UE providing display of VR content, such as through a head mounted display (HMD) connected thereto). Thus, instead of running a game engine on a display device, the game engine may be run on a server to free up resources on the display device. Splitting computations between user devices (e.g., display devices) and servers may relieve devices of unnecessary power and resource use while improving user experience. The server may be connected to a display device (e.g., HMD) via a transport system (e.g., <NUM>).

Disclosed examples provide techniques for improving communications in wireless communication systems, particularly, where user devices are simultaneously supported. The wireless communication system may comprise a <NUM> system, a plurality of user devices and one or more edge servers. In examples, techniques are provided for optimized traffic flow in a communication system. In examples, information may be signaled between a <NUM> system, edge servers, and/or user devices to improve system capacity. As used herein, capacity may refer to the number of user devices that may be simultaneously supported by the communication system.

In examples, techniques are provided for time synchronization (e.g., transmissions offset timing) between devices, e.g., between display devices, server(s) and parts of the communication system (e.g., <NUM> system) to improve system capacity. For example, in a VRSR system, techniques for time synchronization between display devices, a server and a <NUM> system may be employed to improve the number of virtual reality devices that may be simultaneously supported by the <NUM> system. Techniques for time synchronization according to aspects of the disclosure are not limited to application with respect to VR systems, and thus may additionally or alternatively be utilized with respect to various other systems such as augmented reality (AR) and extended reality (XR) for which time synchronization between devices may be utilized. Moreover, techniques in accordance with aspects herein may be utilized in applications in addition to or in the alternative to various hyperreality implementations (e.g., the aforementioned VR, AR, and XR), and thus may be utilized in various additional and/or alternative implementations (e.g., ultra-reliable and low-latency communication (URLLC)).

According to the invention, an indication of a traffic flow to be served by a wireless communication system is received, time offset information for transmissions of the traffic flow (e.g., a time offset for scheduling traffic originating from or destined to the edge server, such as to provide a desired packet arrival characteristic with respect to the traffic flow) is determined based at least on part on the indication, and the time offset information is transmitted in response to the indication. A Radio Access Network (RAN) device (e.g., a base station, a gNB, a Central Unit (CU), a Distributed Unit (DU), etc.) or its components (e.g., a Session Management Function (SMF), a Policy Control Function (PCF), etc.) receives the indication of the traffic flow, determines the time offset information, and transmits the time offset information to an Application Entity (AE) (an Application Function (AF) of an edge server and/or an application on a user device), such as for use in timing communication of packets of the traffic flow to avoid network congestion. In some examples, a UE may receive an indication of traffic flow to be served by a wireless communication system, receive time offset information for transmissions of the traffic flow, and transmit the time offset information in response to the indication to a higher layer (e.g., an application on the UE), such as for use in timing communication of packets of the traffic flow to avoid network congestion. In some aspects, a RAN device may also receive time offset information (e.g., Time Sensitive Communication Assistance Information (TSCAI)) from a node or function in the core network.

In some examples, a change in time offset value determined relative to a current packet arrival offset (also referred to herein as a delta time offset) for a new or existing traffic flow may be determined relative to a time offset of packet arrivals of the traffic flow. For example, a first node (e.g., a User Plane Function (UPF), a Session Management Function (SMF), a Policy Control Function (PCF), a RAN device, a base station, a gNB, a Central Unit (CU), a Distributed Unit (DU), etc.) may determine time offsets of packet arrivals of a traffic flow in a second node (e.g., a gNB, cell, DU, etc.), determine a delta time offset for the traffic flow relative to a time offset of the time offsets, and indicate to a third node (e.g., AE, AF of an edge server, user device, application on a user device, etc.) the delta time offset. The delta time offset may be utilized, for example, in timing transmission of packets of the traffic flow so as to avoid network congestion.

Aspects of the disclosure are initially described in the context of a wireless communications system. Aspects of the disclosure are further illustrated by a process flow. Aspects of the disclosure are further illustrated by and described with reference to apparatus diagrams, system diagrams, and flowcharts that relate to techniques signaling offset from a wireless communication system to a server.

<FIG> illustrates an example of a system <NUM> for wireless communications in accordance with various aspects of the present disclosure. The system <NUM> includes base stations <NUM>, UEs <NUM>, and a core network <NUM>. In some examples, the system <NUM> may be a Long Term Evolution (LTE) network, an LTE-Advanced (LTE-A) network, an LTE-A Pro network, or a New Radio (NR) network. In some cases, the system <NUM> may support enhanced broadband communications, ultra-reliable (e.g., mission critical) communications, low latency communications, or communications with low-cost and low-complexity devices.

The system <NUM> may include base stations <NUM> of different types (e.g., macro or small cell base stations).

Each base station <NUM> may provide communication coverage for a respective geographic coverage area <NUM> via communication links <NUM>. Communication links <NUM> between a base station <NUM> and a UE <NUM> may utilize one or more carriers. Communication links <NUM> shown in the system <NUM> may include uplink transmissions from a UE <NUM> to a base station <NUM>, or downlink transmissions from a base station <NUM> to a UE <NUM>.

A geographic coverage area <NUM> for a base station <NUM> may be divided into sectors making up only a portion of the geographic coverage area <NUM>. Each sector may be associated with a cell.

The system <NUM> may include, for example, a heterogeneous LTE/LTE-A/LTE-A Pro or NR network in which different types of base stations <NUM> provide coverage for various geographic coverage areas <NUM>.

UEs <NUM> may be dispersed throughout the system <NUM>, and each UE <NUM> may be stationary or mobile.

In some examples, half-duplex communications may be performed at a reduced peak rate. In some cases, UEs <NUM> may be designed to support critical functions (e.g., mission critical functions), and the system <NUM> may be configured to provide ultra-reliable communications for these functions.

<FIG> illustrates an example of a wireless communication system <NUM> for wireless communications in accordance with various aspects of the present disclosure. The system <NUM> includes base stations <NUM>, UEs <NUM>, a core network <NUM> and edge server systems <NUM> (e.g., multi-edge computing (MEC) systems). One or more of base stations <NUM> may correspond to base stations <NUM> of <FIG>, one or more of UEs <NUM> may correspond to UEs <NUM> of <FIG>, and/or core network <NUM> may correspond to core network <NUM> of <FIG> in accordance with some aspects of the present disclosure. In some examples, the system <NUM> may be an LTE network, an LTE-A network, an LTE-A Pro network, an NR or <NUM> network. In some cases, the system <NUM> may support enhanced broadband communications, ultra-reliable communications, low latency communications, or communications with low-cost and low complexity devices.

Base stations <NUM> may be associated with particular coverage areas <NUM> in which communications with various UEs <NUM> and edge servers <NUM> is supported. Each base station <NUM> may communicate with UEs <NUM> via communication link <NUM>. Each base station may communicate with edge server or edge server <NUM> via communication link <NUM>. Communication links <NUM> shown in the system may include uplink transmissions from an edge server <NUM> to a base station <NUM>, or downlink transmissions from a base station <NUM> to an edge server <NUM>. Edge server <NUM> may be located close to or integrated with base station <NUM>. In examples, mobile users <NUM> may reduce cost and power by offloading latency driven or computation intensive tasks (e.g., various VR, AR, XR, etc. processing involving appreciable processing resource utilization) to edge servers <NUM> located near the network edge. Processing closer to a UE <NUM> results in improved application performance and a reduction in network congestion.

<NUM> (NR) networks are positioned to manage traffic more efficiently by integrating edge server <NUM>. In examples, the transport layer between user devices <NUM> and edge server <NUM> may be a RAN such as a <NUM> base station. In examples, the ultra-reliable and low-latency communication (URLLC) feature of <NUM> provides a low-latency transport system between the edge server <NUM> and the user devices <NUM>. This transport layer between user device <NUM> and an edge server <NUM> may transmit the output of computations from an edge server <NUM> to UE <NUM>.

In certain scenarios, network congestion increases when edge server <NUM> computations for multiple user devices <NUM> are transmitted in overlapping timeframes. Thus, a time offset may be introduced in a wireless communication system to reduce or prevent overlap and ultimately de-congest communication networks. As used herein, time offset may refer to a pre-determined time offset value or a change in time offset value determined relative to a current packet arrival offset, or delta time offset, for traffic transmissions between a user device <NUM> and edge server <NUM>.

This is explained further with reference to <FIG>. As illustrated in <FIG>, computations corresponding to a first device <NUM> may be completed on an edge server at a time t1. In order to reduce latency experienced by a user, it may be desirable to transmit the output of edge server computations as soon as this information is available. The output of the edge server <NUM> may be transmitted on an exemplary <NUM> system <NUM> to user device <NUM>. Assume <NUM> transport time is the time taken to transport the output of computations for user devices <NUM>, and <NUM>. Thus, <NUM> transport time for device <NUM> may be the time calculated from t1 to t3 (or time at t3 - time at t1). Edge server <NUM> may complete computations for a second device <NUM> at time t2. Similarly, the <NUM> transport time for device <NUM> may be calculated as the time between t2 and t4 (or time t4-t2).

As illustrated in <FIG>, timeframe t3-t1 and t4-t2 overlap during timeframe t2-t3. Thus, in timeframe t2-t3, and in similar scenarios with even more users, the wireless communication system (e.g., the <NUM> transport system) may experience congestion and it may be necessary to make provisions for more spectrum resources on the <NUM> system.

Similarly, the start and end transmission times for computations on different devices communicating with an edge server <NUM> may be un-coordinated. For instance, in <FIG>, device <NUM> computation time (after buffer time <NUM>) may be calculated as t7-t5 and device <NUM> computation time (after buffer time <NUM>) may be calculated as t8-t6. As shown, there may be overlap in traffic transmission from device <NUM> and <NUM> during timeframe t7-t6, causing network congestion. In other words, an exemplary <NUM> system may try to transmit traffic from different devices <NUM> to the edge server <NUM> server on the uplink within overlapping timeframes and this would also result in network congestion.

In examples, edge servers <NUM> may share the same <NUM> system as transport. If the edge servers <NUM> fail to communicate with each other (e.g., where servers are owned/deployed by different entities), then the traffic associated with different edge servers <NUM> may be un-coordinated, and transmission times may overlap.

In exemplary scenarios, transmission time overlap results in congestion and the need for <NUM> systems to be provisioned with more spectrum resources to handle traffic requirements. In some examples, it may be determined to deploy fewer edge servers <NUM>. In some examples, it may become necessary to simultaneously support fewer user devices <NUM> with given spectrum resources resulting in reduced network capacity.

The present disclosure provides for optimized resource usage in such scenarios and techniques to increase system capacity. In examples, techniques are provided for signaling offset in a communication systems. In accordance with aspects of the present disclosure, systems and methods provide for signaling time offsets from <NUM> systems to edge servers and user applications. The time offsets may, for example, comprise pre-determined time offset information (e.g., a start time value based upon a common clock shared between nodes of a traffic flow) and/or delta time offset information relative to packet arrivals of one or more existing traffic flows (e.g., determined without reference to a common clock shared between nodes of a traffic flow).

In examples, transmission times associated with different edge server <NUM> and user devices <NUM> may be coordinated such that traffic transmission is staggered on the RAN (e.g., on the <NUM> transport system). In some examples, time offsets may be predetermined by a scheduler in a RAN. A time offset is determined by a radio access component. In aspects, a time offset may be determined by a <NUM> system. Time offsets are determined based on a common or shared clock, or time offsets are determined by one or more nodes in a traffic flow based upon packet arrivals of existing traffic flows. In aspects, a delta time offset for a new or existing traffic flow may be determined relative to a time offset of packet arrivals of one or more existing traffic flows. In aspects, delta time offsets may be determined without reference to a common or shared clock. In examples, time offset information (e.g., time offsets, delta time offsets, etc.) may be dynamically determined based on traffic requirements.

<FIG> illustrates an example block diagram that supports techniques for signaling time offsets in a wireless communication system in accordance with aspects of the present disclosure. In some examples, the block diagram may implement aspects of the wireless communication system <NUM> and <NUM>. Base station <NUM>, edge server <NUM> and UE <NUM> may be examples of the corresponding devices described with reference to <FIG> and <FIG>.

In some examples, systems and methods that leverage a common clock in a wireless communication system may be provided to optimize system resources and reduce system latency. For example, in <FIG>, a common clock <NUM> may be configured between edge server <NUM>, RAN system or device such as a <NUM> system <NUM> and user devices <NUM>. A common clock as used herein may also be referred to as a shared clock and may be a clock that is synchronized to a common time (e.g., when connected to a common time standard or source such as an atomic clock). In some examples, common clock <NUM> may be an automatically set clock.

In some examples, edge server <NUM>, <NUM> system <NUM> and the user devices <NUM> may all acquire a global clock such as GPS time, via GPS units attached to each device.

In some examples, the edge server <NUM> may maintain a "local" clock, which may be transferred to the <NUM> system <NUM> and user devices <NUM>.

In some examples, the <NUM> system <NUM> may provide the <NUM> system <NUM> clock to the edge server <NUM> and the user devices <NUM>, where the <NUM> clock is a clock on which symbols, slots, sub-frames, radio-frames of the <NUM> system are defined.

In some examples, common clock <NUM> may be utilized in determining time offset information for a traffic flow to be served by a wireless communication system. In other examples, common clock <NUM> may be omitted or otherwise remain unutilized (e.g., not referenced) in determining time offset information for a traffic flow to be served by a wireless communication system.

<FIG> illustrates an example <NUM> and edge server architecture. The <NUM> service-based architecture (as specified in 3GPP TS <NUM>) contains several control plane functional entities including a Policy Control Function (PCF) <NUM>, Session Management Function (SMF) <NUM>, Application Function (AF) <NUM>, Access and Mobility Management Function (AMF) <NUM>, Authentication Server Function (AUSF) <NUM>, etc. User Plane Function (UPF) <NUM> is a data plane functional entity. The user plane carries user traffic and the control plane carries signaling in the network. A UE <NUM> is connected to a RAN as well as AMF <NUM>. The Network Exposure Function (NEF) may be used as the entry point in the <NUM> network for authorized third parties. Using NEF, users may configure how appropriate application traffic in the user plane is directed towards edge server applications. NEF may also be used for exposing network information such as radio resource element, mobility, etc., to the edge server system. In other words, the NEF may handle control plane functions for third party service providers to manage edge server operations.

In the example of <FIG>, UE <NUM> connects to AMF <NUM> which provides UE-based authentication, authorization, mobility management, registration management, UE mobility event notification, security context management etc. The 3GPP interface between AMF <NUM> and UE <NUM> is referred to as N1. SMF <NUM> is responsible for session management and allocates IP addresses to UEs <NUM>. SMF <NUM> also controls and selects the UPF for data transfer. The 3GPP interface between AMF and SMF is referred to as N11 and the 3GPP interface between RAN <NUM> and AMF <NUM> is referred to as N2. Exemplary AF <NUM> may provide information on packet flow to PCF <NUM>. PCF <NUM> is responsible for policy control and determines policies about mobility and session management. The 3GPP interface between the SMF <NUM> and PCF <NUM> is referred to as N7, and the 3GPP interface between the AF and PCF is referred to as N5. AUSF <NUM> stores data for authentication of UE <NUM>.

In some examples, a scheduler at the RAN of a <NUM> system may have knowledge of traffic demands on a <NUM> system including traffic from edge server <NUM> to different user devices <NUM> on the downlink and from different user devices <NUM> to edge server <NUM> on the uplink. In aspects, a scheduler may receive an indication of traffic flow to be served by a wireless communication system for instance, an SMF may indicate to RAN, via AMF, a new Quality of Service (QoS) flow as part of protocol data unit (PDU) session establishment. Time offset information for transmissions of the traffic flow (e.g., a time offset for scheduling traffic originating from or destined to the edge server, such as to provide a desired packet arrival characteristic with respect to the traffic flow) may be determined based at least on part on the indication, and the time offset information may be transmitted by the RAN in response to the indication.

Scheduling information determined by a scheduler may comprise one or more of a reliability requirement for traffic data, a minimum throughput of delivery of data traffic for traffic flow, one or more of a time offset based on a common or shared clock, etc. In examples, if traffic between edge server <NUM> and UEs <NUM> is periodic, transmission times for traffic between edge server <NUM> and user-devices <NUM> may be offset on the <NUM> system to reduce transmission overlap. In aspects, time offset(s) are signaled to suggest start times at which corresponding traffic is least likely to face an overlapping transmission.

Time offsets are signaled to an application entity (AE) in a wireless communication system (e.g., for use by the AE and/or for providing to the DN). An application entity may refer to an application function (AF) of an edge server <NUM> or an application on a user-device <NUM>. An application function may be implemented as a network element on dedicated hardware or as a software instance running on hardware or as a virtualized function instantiated on a corresponding platform such as a cloud infrastructure.

In examples, if the AE is an AF on an edge server, the time offset information (e.g., one or more pre-determined time offset value, delta time offset value, etc.) may be sent from the RAN to the AF associated with the edge server via the AMF, SMF and PCF. For instance, as illustrated in <FIG>, time offset information may be transmitted from RAN <NUM> to AF <NUM> via AMF <NUM>, SMF <NUM>, and PCF <NUM>. This transmission path of the time offset information from the RAN to the AF is shown schematically in <FIG> as the dotted line of transmission path <NUM> from RAN <NUM> to AF <NUM> via AMF <NUM>, SMF <NUM>, and PCF/NEF <NUM>/<NUM>. The time offset information may, for example, be transmitted via transmission path <NUM> in new fields (e.g., one or more fields defined for transmission of time offset information in accordance with aspects herein) of existing messages, new messages (e.g., one or more messages defined for transmission of time offset information in accordance with aspects herein), or in reinterpreted fields of existing messages (e.g., pre-existing message fields reinterpreted for transmission of time offset information in accordance with aspects herein).

Transmission paths for transmission of time offset information from the RAN may be provided in addition to or in the alternative to that of the example above. In examples, of transmission of time offset information from the RAN to an AE that is an AF on an edge server, the time offset information (e.g., one or more pre-determined time offset value, delta time offset value, etc.) may be sent from the RAN to the AF associated with the edge server via the UPF and a DN. For instance, as illustrated in <FIG>, time offset information may be transmitted from RAN <NUM> to AF <NUM> via UPF <NUM> and DN <NUM>, as shown by the dotted line of transmission path <NUM> in <FIG>. In examples, of transmission of time offset information from the RAN to a DN that is in communication with an AE that is an AF on an edge server, the time offset information may be sent from the RAN to the DN via the UPF (e.g., using an interface for control information) and/or from the RAN to the DN via the UPF, DN, AF, and DN (e.g., using a server network interface between the edge server and DN). For instance, as illustrated in <FIG>, time offset information may be transmitted from RAN <NUM> to DN <NUM> via UPF <NUM> and/or from RAN <NUM> to DN <NUM> via UPF <NUM>, DN <NUM>, and AF <NUM> (e.g., where the time offset information is carried in a data packet directed to the AF), as shown by the dotted line of transmission path <NUM> in <FIG>. The time offset information may, for example, be transmitted via transmission path <NUM> in a data packet (e.g., IP data packet) of the UPF, such as using new messages (e.g., one or more messages defined for transmission of time offset information in accordance with aspects herein) and/or new interfaces (e.g., AF message interface defined for transmission of time offset information in accordance with aspects herein).

If the AE is an application on the UE, the offset information may additionally or alternatively be sent from the RAN to a UE <NUM> which conveys the offset information to an application on UE <NUM> either directly or indirectly via an operating system (OS) on the device. Accordingly, in some examples, if the AE is an application on the user device, the time offset information (e.g., one or more start time value, delta time offset value, etc.) may be sent from the RAN to the application on the user device via the user device. For instance, as illustrated in <FIG>, time offset information may be transmitted from RAN <NUM> to application client <NUM> via UE <NUM>. This transmission path of the time offset information from the RAN to the application client is shown schematically in <FIG> as the dotted line of transmission path <NUM> from RAN <NUM> to application client <NUM> via UE <NUM> (e.g., UE <NUM> conveying the offset information to application client <NUM> on UE <NUM> either directly or indirectly via an operating system (OS) on the device). The time offset information may, for example, be transmitted via transmission path <NUM> in new fields (e.g., one or more fields defined for transmission of time offset information in accordance with aspects herein) of existing messages, new messages (e.g., one or more messages defined for transmission of time offset information in accordance with aspects herein), or in reinterpreted fields of existing messages (e.g., pre-existing message fields reinterpreted for transmission of time offset information in accordance with aspects herein).

In examples, a UE may receive an indication of traffic flow to be served in a wireless communication system. In examples, the SMF may, via the AMF, indicate a new QoS flow to a UE. This may be as part of PDU session establishment. The UE may receive scheduling information for the traffic flow, along with the received indication. The scheduling information received by the UE may comprise one or more of a reliability, a minimum throughput of delivery of data traffic for the traffic flow, time offset information, etc. In aspects, in response to the received indication, the UE may provide the scheduling information to a higher layer (e.g., Higher Layer Operating System (HLOS) to media codec, such as gini bu media codec) to allow the higher layer to adjust the frames to minimize the delay experienced by a user.

The time offset information conveyed to the AF associated with the server may correspond to traffic originating at the server (downlink traffic), or to traffic destined to the server (uplink traffic). In the latter case, it is up to the server and device to exchange information that will allow the traffic destined to the server to arrive at the <NUM> system at the time indicated by the offset.

The time offset information may be in response to a session establishment request from the AE. Additionally or alternatively, the time offset information may be in response to determining a preferred characteristic of packet arrival for an existing flow.

In some examples, the <NUM> system (e.g., RAN) may indicate multiple time offset values to the AE, and the AE may select one time offset value among the multiple time offset values. In examples, if none of the offset values indicated by the <NUM> system is acceptable to the AE, the AE may suggest alternative values, and the <NUM> system may determine if any of the suggested values are acceptable, allowing negotiation of the offset values between the <NUM> system and AE.

In examples, assuming the AE is an AF on an edge server, on the interfaces (e.g., N2, N5, N7, N11) between the RAN and the AF, the time offset information may be carried in new fields of existing messages, or in new messages, or by reinterpretation of existing fields in existing messages.

On an N5 3GPP interface (i.e., between the AF and PCF), the time offset information may be carried or transmitted in a notification message. In examples, such a notification message may be indicative of data flow (e.g., of data flow quality of service). Such notification may be used by an AF to receive notifications regarding quality of service targets. In some examples, such a message may comprise a QosNotificationControlInfo data structure type, and time offset information may be carried as part of this message (e.g., as part of Npcf_PolicyAuthorization_Notify service).

On an N2 3GPP interface (i.e., between the RAN and AMF) the time offset information may be carried or transmitted in a notification message. In examples, such a notification message may be indicative of or correlated to an established quality of service flow or packet data unit (PDU) session(s) for a UE. In examples, the offset value may be carried or transmitted in a PDU SESSION RESOURCE NOTIFY message.

In examples, assuming the AE is an AF on an edge server, on the interface (e.g., UPF interface) between the RAN and the AF, the time offset information may be carried in new messages.

In examples, assuming the AE is an application on the user-device, on each of the interfaces between the RAN and the application on the device, the offset values may be carried in new fields of existing messages, or in new messages, or by reinterpretation of existing fields in existing messages.

<FIG> illustrates an example block diagram that supports techniques for signaling time offset. Wireless device <NUM> may be an example of aspects of a user equipment (UE) <NUM> as described herein. Wireless device <NUM> may include receiver <NUM>, UE communications manager <NUM>, and transmitter <NUM>. Wireless device <NUM> may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses).

Receiver <NUM> may receive information such as packets, user data, or control information, time offset information, a plurality of time offsets, time offset values, delta time offset values, etc. Received information may be passed on to other components of the device. The receiver <NUM> may be an example of aspects of the transceiver <NUM> described with reference to <FIG>. The receiver <NUM> may utilize a single antenna or a set of antennas.

UE communications manager <NUM> and/or at least some of its various sub-components may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions of the UE communications manager <NUM> and/or at least some of its various sub-components may be executed by a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described in the present disclosure.

The UE communications manager <NUM> and/or at least some of its various sub-components may be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations by one or more physical devices. In some examples, UE communications manager <NUM> and/or at least some of its various sub-components may be a separate and distinct component in accordance with various aspects of the present disclosure. In other examples, UE communications manager <NUM> and/or at least some of its various sub-components may be combined with one or more other hardware components, including but not limited to an I/O component, a transceiver, a network server, another computing device, one or more other components described in the present disclosure, or a combination thereof in accordance with various aspects of the present disclosure.

UE communications manager <NUM> may receive an indication of traffic flow to be served in a wireless communication system, receive scheduling information for the traffic flow along with the indication. UE communications manager <NUM> may additionally or alternatively receive scheduling information for an existing traffic flow. The scheduling information may include time offset information, a plurality of time offsets, time offset values, delta time offset values, etc..

Transmitter <NUM> may transmit the scheduling information in response to the indication, to a higher layer. For example, transmitter <NUM> may transmit time offset information of the scheduling information to an application on the UE.

<FIG> shows a block diagram <NUM> of a wireless device <NUM> that supports techniques for signaling time offset. Wireless device <NUM> may be an example of aspects of a wireless device <NUM> and/or a UE <NUM> as described with reference to <FIG> or <FIG>. Wireless device <NUM> may include receiver <NUM>, UE communications manager <NUM>, and transmitter <NUM>. Wireless device <NUM> may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses).

Receiver <NUM> may receive information such as packets, user data, or control information, time offset information, a plurality of time offsets, time offset values, delta time offset values, an indication of traffic flow, scheduling information etc. Received information may be passed on to other components of the device. The receiver <NUM> may be an example of aspects of the transceiver <NUM> described with reference to <FIG>. The receiver <NUM> may utilize a single antenna or a set of antennas.

UE communications manager <NUM> may be an example of aspects of the UE communications manager <NUM> described with reference to <FIG>. UE communications manager <NUM> may also include determining component <NUM>.

Determining component <NUM> may determine a time offset value or one time offset value from a plurality of time offset values.

<FIG> shows a system including a UE, and edge server device and a base station that supports techniques for signaling offset. Device <NUM> may be an example of or include the components of wireless device <NUM>, wireless device <NUM>, and/or a UE <NUM> as described above (e.g., with reference to <FIG> and <FIG>). Device <NUM> may include components for bi-directional voice and data communications including components for transmitting and receiving communications, including UE communications manager <NUM>, processor <NUM>, memory <NUM>, software <NUM>, transceiver <NUM>, antenna <NUM>, and I/O controller <NUM>. These components may be in electronic communication via one or more buses (e.g., bus <NUM>). Device <NUM> may communicate wirelessly with one or more base stations <NUM>.

Processor <NUM> may include an intelligent hardware device (e.g., a general-purpose processor, a DSP, a central processing unit (CPU), a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof). In some cases, processor <NUM> may be configured to operate a memory array using a memory controller. In other cases, a memory controller may be integrated into processor <NUM>. Processor <NUM> may be configured to execute computer-readable instructions stored in a memory to perform various functions (e.g., functions or tasks supporting network aided power saving techniques).

Software <NUM> may include code to implement aspects of the present disclosure, including code to support determining signaling offsets, communication of time offset information, etc. in a wireless communication system. Software <NUM> may be stored in a non-transitory computer-readable medium such as system memory or other memory. In some cases, the software <NUM> may not be directly executable by the processor but may cause a computer (e.g., when compiled and executed) to perform functions described herein.

<FIG> shows a block diagram <NUM> of a wireless device <NUM> that supports techniques for signaling time offset in accordance with aspects of the present disclosure. Wireless device <NUM> may be an example of aspects of a base station <NUM> and/or <NUM> as described with reference to <FIG> or <FIG>, etc. Wireless device <NUM> may include receiver <NUM>, base station communications manager <NUM>, and transmitter <NUM>. Wireless device <NUM> may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses).

Receiver <NUM> may receive information such as packets, user data, throughput indicators, control information, clock information, timing information, indication of traffic flow, etc. associated with various information channels or users in a wireless communication system. Information may be passed on to other components of the device. The receiver <NUM> may be an example of aspects of the transceiver <NUM> described with reference to <FIG>. The receiver <NUM> may utilize a single antenna or a set of antennas.

Receiver <NUM> may receive information such as packets, user data, throughput indicators, control information, clock information, timing information, indication of traffic flow, etc. Base station communications manager <NUM> may be an example of aspects of the base station communications manager <NUM> described with reference to <FIG>. Base station communications manager <NUM> and/or at least some of its various sub-components may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions of the base station communications manager <NUM> and/or at least some of its various sub-components may be executed by a general-purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described in the present disclosure. The base station communications manager <NUM> and/or at least some of its various sub-components may be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations by one or more physical devices. In some examples, base station communications manager <NUM> and/or at least some of its various sub-components may be a separate and distinct component in accordance with various aspects of the present disclosure. In other examples, base station communications manager <NUM> and/or at least some of its various sub-components may be combined with one or more other hardware components, including but not limited to an I/O component, a transceiver, a network server, another computing device, one or more other components described in the present disclosure, or a combination thereof in accordance with various aspects of the present disclosure.

Base station communications manager <NUM> may receive clock information, timing information, traffic information, indication of traffic flow etc., from a device or other devices in a communication system.

Transmitter <NUM> may transmit a message such as scheduling information in accordance with received information.

<FIG> shows a block diagram <NUM> of a wireless device <NUM> that supports techniques for signaling time offset in accordance with aspects of the present disclosure. Wireless device <NUM> may be an example of aspects of a wireless device <NUM> or a base station <NUM> as described with reference to <FIG> and <FIG>, respectively. Wireless device <NUM> may include receiver <NUM>, base station communications manager <NUM>, and transmitter <NUM>. Wireless device <NUM> may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses).

BS communications manager <NUM> and/or at least some of its various sub-components may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions of the BS communications manager <NUM> and/or at least some of its various sub-components may be executed by a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described in the present disclosure.

The BS communications manager <NUM> and/or at least some of its various sub-components may be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations by one or more physical devices. In some examples, BS communications manager <NUM> and/or at least some of its various sub-components may be a separate and distinct component in accordance with various aspects of the present disclosure. In other examples, BS communications manager <NUM> and/or at least some of its various sub-components may be combined with one or more other hardware components, including but not limited to an I/O component, a transceiver, a network server, another computing device, one or more other components described in the present disclosure, or a combination thereof in accordance with various aspects of the present disclosure.

BS communications manager <NUM> may determine time offsets, time offset information, time offset values, delta time offset values, etc. BS communications manager <NUM> may include determining component <NUM>. Determining component <NUM> may determine base station algorithms (e.g., scheduling algorithms to adjust or change based on received information).

Transmitter <NUM> may transmit to a receiving device in accordance with received timing or traffic information.

<FIG> shows a system <NUM> including a device <NUM> that supports techniques for signaling timing offset in accordance with aspects of the present disclosure. Device <NUM> may be an example of or include the components of wireless device <NUM>, wireless device <NUM>, and/or a UE <NUM> as described above (e.g., with reference to <FIG> and <FIG>). Device <NUM> may include components for bi-directional voice and data communications including components for transmitting and receiving communications, including base station communications manager <NUM>, processor <NUM>, memory <NUM>, software <NUM>, transceiver <NUM>, antenna <NUM>, and Network Communications Manager <NUM>. These components may be in electronic communication via one or more buses (e.g., bus <NUM>). Device <NUM> may communicate wirelessly with one or more UEs <NUM>.

Processor <NUM> may include an intelligent hardware device, (e.g., a general-purpose processor, a DSP, a central processing unit (CPU), a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof). In some cases, processor <NUM> may be configured to operate a memory array using a memory controller. In other cases, a memory controller may be integrated into processor <NUM>. Processor <NUM> may be configured to execute computer-readable instructions stored in a memory to perform various functions (e.g., functions or tasks supporting network aided power saving techniques).

Software <NUM> may include code to implement aspects of the present disclosure, including code to support determining scheduling information (e.g., including time offset information), communicating scheduling information, etc. in a wireless communication system. Software <NUM> may be stored in a non-transitory computer-readable medium such as system memory or other memory. In some cases, the software <NUM> may not be directly executable by the processor but may cause a computer (e.g., when compiled and executed) to perform functions described herein.

The edge server <NUM> may transmit communications to device <NUM> via RAN device <NUM>.

<FIG> shows a flowchart illustrating a method <NUM> that supports techniques for signaling time offsets. The operations of method <NUM> may be implemented by a UE <NUM> or its components as described herein. For example, the operations of method <NUM> may be performed by a UE communications manager as described with reference to <FIG> and <FIG>. In some examples, a UE <NUM> may execute a set of codes to control the functional elements of the device to perform the functions described below.

At <NUM> the UE <NUM> may receive an indication of a traffic flow to be served by a wireless communication system. The operations of <NUM> may be performed according to the methods described herein. For example, an application on the UE may initiate a request via an operating system of UE <NUM> to establish a session (e.g., a session establishment request) with an AF of an edge server, wherein an indication of a traffic flow for the session is provided by the RAN to the UE in response to the session establishment request. As another example, an AF of an edge server may initiate a request to establish a session (e.g., a session establishment request) with UE <NUM> via the wireless communication system, wherein an indication of a traffic flow for the session is provided by the RAN to the UE in response to the session establishment request. In certain examples, aspects of the operations of <NUM> may be performed by a determining component as described with reference to <FIG> or <FIG>.

At <NUM> the UE <NUM> receives scheduling information for the traffic flow along with the indication, wherein the scheduling information comprises one or more of a time offset information, a reliability, and a minimum throughput delivery of data traffic for the flow. The time offset information may, for example, comprise a pre-determined time offset (e.g., a start time value determined based on a common clock), a delta time offset (e.g., a time offset value relative to one or more existing time offsets of packet arrivals of one or more existing traffic flows), etc. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a transmitter as described with reference to <FIG> or <FIG>.

At <NUM> the UE <NUM> may transmit at least a portion of the scheduling information in response to the indication, to a higher layer. For example, an operating system of UE <NUM> may transmit the time offset information and/or other portions of the scheduling information to an application on the UE, such as for use in timing transmission of packets of the traffic flow so as to avoid network congestion. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a transmitting component as described with reference to <FIG> or <FIG>.

At <NUM> the UE <NUM> receives delta time offset information for the traffic flow. The delta time offset information may, for example, be received along with the indication, such as where the traffic flow is a new traffic flow being established (e.g., between the UE and an AF of an edge server via the wireless communication system). As another example, the delta time offset information may be received independent of the indication, such as where the traffic flow is an existing traffic flow previously established (e.g., between the UE and an AF of an edge server via the wireless communication system). The delta time offset information may, for example, comprise a time offset value relative to one or more existing time offsets of packet arrivals of one or more existing traffic flows. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a transmitter as described with reference to <FIG> or <FIG>.

At <NUM> the UE <NUM> may transmit at least a portion of the delta time offset information, to a higher layer. For example, an operating system of UE <NUM> may transmit a time offset value of the delta time offset information and/or other portions of scheduling information to an application on the UE (e.g., in response to the indication, independent of the indication, etc.), such as for use in timing transmission of packets of the traffic flow so as to avoid network congestion. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a transmitting component as described with reference to <FIG> or <FIG>.

<FIG> shows a flowchart illustrating a method <NUM> that supports techniques for signaling time offsets in accordance with aspects of the present disclosure. The operations of method <NUM> may be implemented by a RAN device (e.g., a base station, a gNB, a Central Unit (CU), a Distributed Unit (DU), etc.) or its components (e.g., a Session Management Function (SMF), a Policy Control Function (PCF), etc.) as described herein. For example, the operations of method <NUM> may be performed by a base station communications manager as described with reference to <FIG> and <FIG>.

At <NUM> the RAN device receives an indication of a traffic flow to be served by a wireless communication system. The operations of <NUM> may be performed according to the methods described herein. For example, an AF of an edge server or an application on a UE may initiate a request to establish a session (e.g., a session establishment request) with a corresponding AE, wherein an indication of a traffic flow for the session provided by the RAN in response to the session establishment request is received by the RAN device. As another example, an AF of an edge server or an application on the UE may initiate a request to establish a session (e.g., a session establishment request) with a corresponding AE, wherein the session establishment request may be interpreted as an indication of a traffic flow by the RAN device. In certain examples, aspects of the operations of <NUM> may be performed by a receiver as described with reference to <FIG> or <FIG>.

At <NUM> the RAN device determines scheduling information for the traffic flow based on the indication, wherein the scheduling information comprises one or more of a time offset information, a reliability, and a minimum throughput of delivery of data traffic for the flow. The time offset information may, for example, comprise a pre-determined time offset (e.g., a start time value determined based on a common clock), a delta time offset (e.g., a time offset value relative to one or more existing time offsets of packet arrivals of one or more existing traffic flows), etc. The operations of <NUM> may be performed according to the methods described herein.

At <NUM> the RAN device transmits the scheduling information in response to the indication. The RAN device transmits the time offset information to an AE (an AF of an edge server and/or an application on a user device), such as for use in timing communication of packets of the traffic flow to avoid network congestion. In certain examples, aspects of the operations of <NUM> may be performed by a transmitter as described with reference to <FIG> or <FIG>.

<FIG> shows a flowchart illustrating a method <NUM> that supports techniques for signaling time offsets in accordance with aspects of the present disclosure. The operations of method <NUM> may be implemented by various nodes within the wireless communication system, such as a RAN device (e.g., a base station, a gNB, a Central Unit (CU), a Distributed Unit (DU), etc.), its components (e.g., a Session Management Function (SMF), a Policy Control Function (PCF), etc.), or a component in communication therewith (e.g., a User Plane Function (UPF)) as described herein. For example, the operations of method <NUM> may be performed by a base station communications manager as described with reference to <FIG> and <FIG> and/or a UE communications manager as described with reference to <FIG> and <FIG>.

At <NUM> delta time offset information is determined for a first traffic flow relative to an existing time offset of packet arrivals of the first traffic flow for scheduling transmissions of one or more other traffic flows and the first traffic flow in the wireless communication system. As shown in the example of <FIG>, the arrival time of packets of a traffic flow associated with UE-<NUM> and a traffic flow associated with UE-<NUM> may overlap with respect to one or more nodes (e.g., Node <NUM> and Node <NUM>) of the wireless communication system. Accordingly, delta time offset information comprising a time offset value (e.g., delta time offset <NUM> shown in <FIG>) determined relative to a current packet arrival offset may be determined relative to a time offset of packet arrivals of the first traffic flow. The delta time offset information may, for example, be determined for applying to an pre-determined or existing time offset of the first traffic flow for providing better packet arrival offset (e.g., non-overlapping packet arrival) for the first traffic flow and the one or more other traffic flows. In some examples, determining the delta time offset information maybe be performed by logic (e.g., instructions of software <NUM> executed by processor <NUM> to provide functionality of BS communications manager <NUM> and/or instructions of software <NUM> executed by processor <NUM> to provide functionality of UE communications manager <NUM>) of a node (e.g., a RAN device, its components, or a component in communication therewith) of the wireless communication system.

Determining the delta time offset information may be initiated variously with respect to a traffic flow to which it may be applied. For example, delta time offset information may be determined and applied with respect to a new traffic flow. Accordingly, a node operating to determine the delta time offset information may receive an indication of a traffic flow to be served by a wireless communication system (e.g., operation according to block <NUM> of <FIG> may be performed prior to block <NUM> of <FIG>). Additionally or alternatively, the occurrence of an event (e.g., network congestion is detected, communication performance degrades below a threshold level, quality of service metrics are not met or at risk of not being met, etc.) may be detected by the node operating to determine the delta time offset information and result in initiation of the determination. In some aspects of the present disclosure, the determining the delta time offset information may be performed in part based on one or more mobility event (e.g., one or more of a mobility event associated with a UE of the first traffic flow, a mobility event associated with a UE of the one or more other traffic flows, a change detected in packet arrival offset of the first traffic flow, or a change detected in packet arrival offset of the one or more other traffic flows).

Determining the delta time offset information may comprise various operations and/or determinations. For example, as shown in <FIG>, determining the delta time offset information may comprise determining time offsets of packet arrivals of one or more existing traffic flows and/or the first traffic flow, wherein delta time offset information for one or more traffic flows (e.g., the existing one or more traffic flows, a new traffic flow, and/or one or more other existing traffic flows) may be determined relative to a time offset of the time offsets. At <NUM> a first node of the wireless communication system determines time offsets of packet arrivals of one or more traffic flows in a second node of the wireless communication system. In examples, a first node (e.g., Node <NUM> of <FIG>) may determine the current packet arrival offset for one or more existing traffic flows in a second node (e.g., Node <NUM> of <FIG>). A determination with respect to current packet arrival offset may, for example, be based on learning of offsets (after flow establishment), based on traffic pattern information (e.g., TSCAI) provided to the first node (e.g., during flow establishment), etc..

The first node may utilize one or more of the determined current packet arrival offset for the one or more existing traffic flows to determine the delta time offset information (e.g., a time offset value relative to a current packet arrival offset). At <NUM> the first node determines the delta time offset information for the first traffic flow relative to a time offset of the time offsets. The delta time offset may, for example, be determined so that the application of the delta time offset eliminates or reduces overlap between packet arrivals of the first traffic flow and the one or more other traffic flows (e.g., as illustrated in the example of <FIG>). Reduction of such overlaps reduces peak resources required for transmissions to support the packet arrivals and thus enable supporting more UEs with such packet arrivals.

In examples, determining the delta time offset information may provide for determining various desired or preferred characteristics of packet arrival of a new or existing traffic flow. For example, the delta time offset information determined according to some examples may comprise a time offset value determined relative to a current packet arrival offset. Additionally or alternatively, determining the delta time offset information according to some examples may comprise determining a period of packet arrival.

Referring again to <FIG>, at <NUM> the delta time offset information is transmitted to a node of the first traffic flow for modifying packet arrivals of the first traffic flow in the wireless communication system. For example, the first node (e.g., Node <NUM> of <FIG>) may transmit the delta time offset information to a third node (e.g., Node <NUM> of <FIG>) for modifying packet arrival characteristics based at least in part on the delta time offset information. In examples, the third node may apply a time offset value relative to a current packet arrival offset (e.g., delta time offset <NUM> of <FIG>) of the delta time offset information with respect to transmission of packets of the first traffic flow to provide offset of packet arrival. As shown in the example of <FIG>, application of delta time offset <NUM> results in a new arrival time of packets of a traffic flow associated with UE-<NUM> (e.g., as shown by arrival time <NUM>) being non-overlapping with respect to the arrival time of packets of a traffic flow associated with UE-<NUM>. In certain examples, aspects of the operations of <NUM> may be performed by a transmitter as described with reference to <FIG> or <FIG> and/or a UE communications manager as described with reference to <FIG> and <FIG>.

The traffic flow for which delta time offset information is determined and/or to which delta time offset information is applied may comprise various types of traffic flows. In examples, the traffic flow may comprise a QoS flow, a Data Radio Bearer (DRB) or PDU session associated with a UE, etc. The traffic flow may, for example, comprise a flow between an AF of an edge server and an application on a user device (e.g., traffic originating from and/or destined to the edge server), wherein the third node may comprise an AE (e.g., the AF or the user device application) that modifies the packet arrival characteristics using the delta time offset information. the such as for use in timing communication of packets of the traffic flow to avoid network congestion.

The system <NUM> or systems described herein may support synchronous or asynchronous operation.

Claim 1:
A method for wireless communication, comprising:
receiving (<NUM>), by a radio access network, RAN, device (<NUM>; <NUM>; <NUM>; <NUM>; <NUM>; <NUM>) of a wireless communication system (<NUM>), an indication of a traffic flow to be served by the wireless communication system (<NUM>);
determining (<NUM>), by the RAN device, time offset information for transmissions of the traffic flow based at least in part on the indication; and
transmitting (<NUM>), by the RAN device to at least one application entity in the wireless communication system, the time offset information in response to the indication,
wherein the at least one application entity includes an Application Function, AF (<NUM>), on an edge server (<NUM>; <NUM>; <NUM>) and/or an application on a user device (<NUM>; <NUM>, <NUM>; <NUM>; <NUM>); and
wherein the time offset is based on a common clock (<NUM>) shared between nodes (<NUM>, <NUM>, <NUM>) communicating the traffic flow or based on packet arrivals of one or more existing traffic flows.