Patent Description:
Aspects of the present disclosure relate generally to wireless communication networks, and more particularly, to receiver-side buffering of received traffic data associated with time-aware scheduling across a cellular communication link.

Factory automation relies on ultra-reliable low latency communications (URLLC) for hard-real-time applications such as motion control, discrete manufacturing, etc. The present wireline solutions use Ethernet-based protocols over local area networks (LANs). Time-sensitive networking (TSN) summarizes a set of <NUM> features that support hard-real-time traffic for these use cases. Time-aware scheduling is one of the predominant features of TSN. It reserves absolute periodic time intervals for the transmission of a particular traffic class on a link.

One problem associated with time-aware-scheduling is that it increases buffer requirements on the transmitter side since traffic cannot be transmitted outside its designated time window, even if link capacity is available. This buffer requirement may create a burden on some devices, such as small sensors having constrained memory resources or devices with relatively large memory resources but transmitting traffic to a large number of receiving devices.

Thus, improvements in time-aware scheduling are desired. <CIT> entitled "Collision-free insertion and removal of circuit-switched channels in a packet-switched transmission structure" discloses a method and system for a collision free insertion and removal of circuit-switched channels in a self-adaptive transmission data structure carrying different classes of packet-switched traffic on a slotted Local Area Network (LAN).

<CIT> discloses a synchronous network with periodic transmission windows per traffic priority. Data received at a node outside their priority windows are buffered until the next occurrence of their respective priority window.

Advantageous embodiments are claimed in the dependent claims.

Additionally, the term "component" as used herein may be one of the parts that make up a system, may be hardware, firmware, and/or software stored on a computer-readable medium, and may be divided into other components.

The present disclosure generally relates to meeting the time-sensitive networking (TSN) time-aware schedule while preemptively transmitting frames over a cellular link. In particular, the disclosure includes receiver-side buffering of received traffic data associated with time-aware scheduling across a cellular communication link. In an implementation, for example, the described solutions may be used to replace wireline technologies with cellular technologies (e.g., <NUM>/LTE and <NUM>/new radio (NR)) in factory automation. As mentioned, time-aware scheduling reserves absolute periodic time intervals for the transmission of a particular traffic class on a link.

According to the present disclosure, in one implementation, a transmitting node informs a receiving node about designated time intervals, or a time indicator associated with a designated time interval (of which the receiving node may be unaware), and an associated traffic identifier so that the receiver can buffer preemptively arriving traffic data until an arrival of a next time interval (whether or not known to the receiving node) before the receiving node passes the traffic data on to upper layers. For instance, in order to avoid buffering an amount of traffic data beyond desired or available resources while waiting for arrival of a designated time window, or in order to efficiently use available bandwidth prior to the designated time window, the transmitting node may preemptively transmit traffic before its designated time window using a cellular interface supporting an Ethernet link. Sending traffic preemptively on the physical link, however, violates the time-aware schedule as traffic is transmitted outside its designated time interval. As such, the present disclosure enables the transmitting node to preemptively transmit the traffic data, while providing an indication to the receiving node to buffer the traffic data until an arrival of a next designated time interval to comply with the time-aware schedule. Depending on the scenario, the transmitting node can either a user equipment (UE) or an access node (AN), and the receiving node can be the opposite one of the UE or the AN.

Additional features of the present aspects are described in more detail below with respect to <FIG>.

Referring to <FIG>, in an example implementation, a system <NUM> may be configured to use Ethernet-based protocols over local area networks (LANs) <NUM> and <NUM>. In one implementation, a first LAN <NUM> may be interconnected with a second LAN <NUM> via a cellular interface <NUM>, e.g., a wireless communication link. The first LAN <NUM> and the second LAN <NUM> may refer to two different sections of the same LAN. In another example implementation, the first LAN <NUM> and the second LAN <NUM> may be different LANs. Either of the LANs may include a single Ethernet node. The cellular interface <NUM> may be supported between an Access Node (AN) <NUM> and User Equipment (UE) <NUM>.

At least one of the AN <NUM> or the UE <NUM> includes a data reception manager component <NUM> (in this case, the AN <NUM>) and at least the other one of the AN <NUM> or the UE <NUM> includes a data transmission manager component <NUM> (in this case, the UE <NUM>), each of which is configured in a complimentary manner to enable a receiving node to support receiver-side buffering of received traffic data associated with time-aware scheduling across the cellular interface <NUM>, e.g., the cellular communication link. It should be appreciated that both the AN <NUM> and the UE <NUM> may include both of the data reception manager component <NUM> and the data transmission manager component.

For example, a modem <NUM> of the AN <NUM> may execute the data reception manager component <NUM>, which includes a traffic controller <NUM> configured to identify whether received traffic data <NUM> having a traffic class associated with a traffic class identifier <NUM> is received in or was transmitted in a time interval <NUM> for receiving data based on timing information <NUM> received for the traffic class identifier <NUM>. For instance, the timing information <NUM> may include or otherwise explicitly or implicitly identify the time interval <NUM> for transmitting, or for not transmitting, or implicitly indicate a lack of a corresponding time interval <NUM>, associated with the received traffic data <NUM> having the traffic class. It should be understood that the time interval <NUM> may be periodic, arbitrary, or a single time interval. Further, it should be understood that the receiving node (e.g., the AN <NUM> in this example) may be aware of the time interval <NUM> or may be completely unaware of the time interval <NUM> (e.g., just receiving timing information <NUM> that identifies how much longer to buffer the received traffic data <NUM>).

The data reception manager component <NUM> may additionally include a timing determiner <NUM> in communication with the traffic controller <NUM> that identifies whether the received traffic data <NUM> was transmitted or received inside of time interval <NUM>. As used herein, the traffic data <NUM> being "received" may refer to a time associated with any receiving processing step, e.g. after first transmission of data, after retransmissions, decoding and CRC check, successful security checks, reordering, frame or packet reassembly, etc. For instance, the timing determiner <NUM> may be in communication with an internal clock <NUM> that is synchronized to an internal clock <NUM> of the transmitting device (the UE <NUM> in this case). As such, the timing determiner <NUM> may compare the timing information <NUM>, a value of the internal clock <NUM>, and a timing of transmission or receipt of the traffic data <NUM> to determine if it is inside or outside of the time interval <NUM> for the corresponding traffic class. The timing determiner <NUM> may notify the traffic controller <NUM> of its determination. In response, when inside of the time interval <NUM> or when no time interval applies, the traffic controller <NUM> may forward the received traffic data <NUM> to one or more higher protocol layers <NUM>. For example, the traffic controller <NUM> may be operating on the received traffic data <NUM> at a physical (PHY) protocol layer, and hence may pass the received traffic data <NUM> to a higher layer such as, but not limited to, a medium access control (MAC) protocol layer, a radio link control (RLC) protocol layer, etc. In contrast, when outside of the time interval <NUM>, the traffic controller <NUM> may cause such preemptively transmitted traffic data <NUM> to be stored in a traffic buffer <NUM>. Further, in this case, the traffic controller <NUM> may have the timing determiner <NUM> monitor for a next occurrence of the time interval <NUM>, upon which the traffic controller <NUM> may then forward the received traffic data <NUM> stored in the traffic buffer <NUM> to one or more higher protocol layers <NUM>. As such, the modem <NUM> operating the data reception manager component <NUM> and the traffic controller <NUM> can perform receiver-side buffering of the traffic data <NUM> received over the cellular interface <NUM> and associated with time-aware scheduling.

Correspondingly, a modem <NUM> of the UE <NUM> (in this case) may execute the data transmission manager component <NUM> to obtain a time-aware schedule configuration <NUM>, generate the timing information <NUM>, and transmit the timing information <NUM>, the corresponding traffic class identifier <NUM>, and the traffic data <NUM> to the receiving node, e.g., the AN <NUM> in this case. For example, the data transmission manager component <NUM> may include a transmit configuration manager <NUM> configured to determine a set of one or more time intervals <NUM> for one or more traffic class identifiers <NUM> based on the time-aware schedule configuration <NUM>, and based thereon generate the timing information <NUM>. Additionally, the data transmission manager component <NUM> may include a transmit controller <NUM> configured to receive traffic data <NUM>, e.g., from an application or from another device, and store it in a transmit buffer <NUM> pending transmission according to the time-aware schedule configuration <NUM>, if applicable to the traffic class associated with the traffic data <NUM>. For example, the transmit buffer <NUM> may store the traffic data <NUM> until the traffic data <NUM> can be delivered to the receiver within a scheduled window.

In other aspects, the data reception manager component <NUM> and/or the data transmission manager component <NUM> may include additional functionalities and components related to performing receiver-side buffering of the traffic data <NUM> received over the cellular interface <NUM> and associated with time-aware scheduling, as discussed below.

In an implementation, the AN <NUM> may generally represent a gNB or an eNB, for instance. The AN <NUM> may reside on a first Ethernet node <NUM> connected to the first LAN <NUM> and the UE <NUM> may reside on a second Ethernet node <NUM> connected to the second LAN <NUM>. The first Ethernet node <NUM> in which the AN <NUM> resides may include a User-Plane Function (UPF) or Gateway (GW) and/or other cellular core-network nodes. In another implementation, for example, the first Ethernet node <NUM> may not include the UPF, GW, and other cellular core-network nodes. The cellular interface <NUM> may support a frame structure defining, for example, a System Frame Number (SFN), Hyper Frame Number (HFN), subframe number, or similar frame number for synchronizing communication.

The first Ethernet Node <NUM> and the second Ethernet Node <NUM> may each hold a respective one of the internal clocks <NUM>, <NUM>, referred to as, for example, a LAN clock. The LAN clocks <NUM>, <NUM> of each of the first Ethernet node <NUM> and the second Ethernet node <NUM> may be mutually synchronized via a synchronization procedure. Such synchronization may be performed, for example, by global navigation satellite system (GNSS) such as global positioning system (GPS), GLONASS, BeiDou Navigation Satellite System, or the like. In another example implementation, the synchronization may be performed via a Precision-Time-Protocol (PTP) such as defined by IEEE <NUM> or IEEE <NUM>. For example, in an implementation of a synchronization procedure using PTP via the cellular interface <NUM>, the frame structure enforced by cellular technologies as well as lower layer mechanisms may be used to time-synchronize UE <NUM> and AN <NUM> with respect to this frame structure.

A PTP synchronization message can be initiated by a network node, e.g., first Ethernet Node <NUM> such as AN <NUM>, to cross the cellular link toward the peer, e.g., second Ethernet Node <NUM> such as UE <NUM>, the following procedure may be conducted. The first Ethernet Node <NUM> maps the time of its internal clock to the cellular frame structure. The first Ethernet Node <NUM> transmits this mapping together with an indicator of the time-synchronization protocol and the message content pertaining to this control over a control channel of the cellular link. The second Ethernet Node <NUM> receiving this information uses the mapping to synchronize its internal clock based on the cellular frame structure. The second Ethernet Node <NUM> uses this synchronized internal clock as well as the protocol indicator and the message content to further propagate PTP on other links. Frame structure synchronization between UE <NUM> and AN <NUM> can use existing cellular synchronization signals such as PSS/SSS, PRS and SRS and Timing Advance signaling. Accuracy can be enhanced by leveraging methods developed for OTDOA or UTDOA. Further, the mapping between frame structure and internal clock can be based on the time value of a particular frame boundary defined by SFN and HFN.

According to an example implementation, the LAN clocks <NUM>, <NUM> of both of the Ethernet node <NUM> and Ethernet node <NUM> may optionally be time-synchronized with a master clock <NUM>. In another example implementation, other nodes <NUM>, <NUM> of the first LAN <NUM> and the second LAN <NUM> may be time-synchronized with the master clock <NUM>. By using time synchronization of Ethernet Nodes in a LAN, the system <NUM> may be configured to reserve periodic time resources along a path in the LAN for a specific traffic class. As such, real-time traffic with stringent latency constraints may be capable of traveling along this path. The time-based resource reservation scheme may generally be referred to as time-aware scheduling, which has been defined in IEEE <NUM>. 1Qbv-<NUM>. Time-aware scheduling may be used, for instance, for Time-Sensitive Networking (TSN).

Referring to <FIG>, an example implementation of the time-aware schedule configuration <NUM> may include time-aware scheduling of a high-priority traffic type (VLAN priority <NUM>) in a first time interval <NUM> of a periodic cycle Cn <NUM>. Other traffic of lower priority (VLAN priorities <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>) may be scheduled in the remaining time interval <NUM> of the cycle Cn <NUM>. Likewise, one or more subsequent periodic cycles Cn+<NUM> <NUM> may have the same arrangement of the first time interval <NUM> and the remaining time interval <NUM>.

Referring to <FIG>, in another example, the time-aware schedule configuration <NUM> may be configured on a cellular link, and may specify time intervals <NUM> for high priority traffic as they is derived from a TSN configuration as shown in <FIG>. For example, the time interval <NUM> may refer to an absolute time base used for reservation of resources for a specific type of traffic.

When using the cellular interface <NUM> to support an Ethernet link, the frame structure of the cellular link may be time-locked to the absolute time intervals defined by the time-aware schedule via a synchronization procedure, such as but not limited to using PTP as described above or via using channel estimation for per-tone continuous precoding in a downlink MIMO transmission.

For instance, in one implementation of a synchronization procedure using channel estimation for per-tone continuous precoding in a downlink MIMO transmission, as an example, when the AN has a layer (or stream) to transmit in the downlink, the AN may select a UE receive antenna. At the chosen UE receive antenna, there may be one dominant path in the channel impulse response (CIR) of the precoded channel. Further, the location of the dominant path of the precoded channel may be at the center of the time support of the PDP of the precoded channel. In an aspect, the center location may be more or less the same in the precoded channels for this layer at all of the UE receive antennas. Accordingly, the UE may estimate the location of the dominant path by applying IFFT-based channel estimation to the DMRS for the layer received at the UE receive antenna chosen for the layer. That is, the UE may receive signals from the AN and perform an FFT to extract the DMRS. Subsequently, the UE may perform an IFFT on the DMRS extracted from the FFT result to obtain the channel impulse response of the precoded channel. Based on the channel impulse response, the UE may determine the location of the dominant path. The UE may use the location of the dominant path to determine the time support of the PDPs of the precoded channel for this layer at all of the UE receive antennas. Via downlink control information (DCI), the AN may indicate to the UE the index of the UE receive antenna for the layer, where the measurement of the dominant path may take place. The UE may measure the delay spread, τd,CRS, of the underlying propagation channel from the CRS, and use a value proportional to τd,CRS as the delay spread of the precoded channel. In an aspect, the value may be <NUM>, such that the delay spread of the precoded channel may be assumed to be <NUM>τd,CRS. Alternatively, using the SRS received in the UL, the AN may determine the delay spread of the precoded channel for each layer and indicate the delay spread information to the UE. By knowing the delay spread and the location of the dominant path, the UE may determine the time support of the PDP of the precoded channel. For example, the UE may determine that the location of the dominant path is at -<NUM>, and may determine that the delay spread for the propagation channel is <NUM>. The delay spread for the precoded channel is <NUM> (<NUM>*<NUM>). Assuming -<NUM> is at the center of the PDP, then the time support of the precoded channel may be in the approximate range of [-<NUM>, <NUM>]. The UE may then use the determined time support of the precoded channel for performing channel estimation.

Aside from performing channel estimation of the uplink propagation channel using the SRS, the AN may use the SRS to determine the location of the first arriving path (FAP) of the UL propagation channel with respect to the start of the FFT window used by the AN for the demodulation of uplink signals. For example, the channel matrix observed at the k-th tone from the SRS may be given by: <MAT>.

Referring to the above equation, Δf may refer to the tone spacing in Hertz (Hz) (e.g., <NUM>), TFAP,UL may refer to the FAP location in seconds with respect to the start of the FFT window used by the AN for uplink signals, and Hk may be the Nr x Nt matrix of the propagation channel with TFAP,UL = <NUM> (as such, the term e-j<NUM>πkΔfTFAP,UL is a phase rotation/ramp that may arise when the FAP is not aligned with the start of the FFT window used by the AN; Hk corresponds to the channel matrix when the FAP is aligned with the start of the FFT window). Regarding the Nr x Nt matrix, Nr corresponds to the number of receive antennas at the UE, and Nt corresponds to the number of transmit antennas at the AN. If TFAP,UL > <NUM>, then the dominant path of the precoded channel may appear TFAP,UL seconds earlier than the FAP of the downlink propagation channel, when observed by the UE. If TFAP,UL < <NUM>, then the dominant path of the precoded channel may appear |TFAP,UL| seconds later than the FAP of the downlink propagation channel, when observed by the UE. If TFAP,UL = <NUM>, then the dominant path of the precoded channel may be aligned with the FAP of the downlink propagation channel.

At the output of the precoder, the AN may compensate for phase ramp on the precoded symbols, which may be caused by a non-zero TFAP,UL. In an aspect, the precoded symbols for the k-th tone may be multiplied by e-i<NUM>πkΔfTFAP,UL for purposes of phase ramp compensation. For example, by performing phase ramp compensation, the dominant path of the precoded channel may be aligned with the FAP of the DL propagation channel, instead of the dominant path preceding the FAP of the DL propagation channel. In this aspect, the dominant path of the precoded channel may become more aligned with the FAP of the downlink propagation channel, when the dominant path is received by the UE. As a result, the UE may use the location of the dominant path for downlink timing synchronization (e.g., use the location of the dominant path to determine the FAP of the DL propagation channel, which in turn is used in adjusting the position of the receiver FFT window in order to maximize the tone signal to interference and noise ratio (SINR)). For example, the FAP of the propagation channel may be difficult to locate because the strength of the FAP may be weak. Therefore, the location of the FAP may alternatively be determined using the location of the dominant path of the precoded channel, if the dominant path is aligned with the FAP.

As mentioned above, various problems exist with time-aware scheduling over a cellular interface. One problem, for example, is that time-aware scheduling increases buffer requirements on the transmitter side since traffic cannot be transmitted outside its designated time window. This problem exists even if link capacity is available. As such, the increased buffer requirements may create a burden for small sensors, for instance. To avoid one or more of these issues, the transmitting node may preemptively transmit data traffic, via a cellular interface supporting an Ethernet link, before its designated time window or time interval. When sending traffic preemptively on the physical link, however, the time-aware schedule is violated as traffic is forwarded outside its designated time interval.

As such, according to an example implementation of the present disclosure, a transmitting node may be configured to inform a receiving node about designated time intervals and an associated traffic identifier so that the receiver buffers preemptively arriving traffic until a next time interval arrives before passing the preemptively arriving traffic on to upper layers. Accordingly, the apparatus and methods off the present disclosure may satisfy the time-aware schedule, yet can utilize available bandwidth outside of the time interval to improve efficiency. As described herein, the transmitting node may be the UE or the AN, while the receiving node may be the opposite one of the UE or AN as compared to the transmitting node.

Referring to <FIG>, in operation, one example implementation of a receiver-side buffering method <NUM> may be performed by a transmitter <NUM> (e.g., transmitting node such as UE <NUM> in <FIG>) and a receiver <NUM> (e.g., a receiving node such as AN <NUM> in <FIG>) sustaining a cellular interface <NUM> therebetween. Either of the nodes may be the AN <NUM> and the corresponding peer the UE <NUM>. It may be appreciated that the transmitter <NUM> refers to the time-aware schedule, which is typically defined for a unidirectional traffic flow of a specific traffic class. Moreover, the below-described functions of the transmitter <NUM> may be performed by the data transmission manager component <NUM>, or one of its subcomponents, operated by the modem <NUM> of UE <NUM> or the modem <NUM> of AN <NUM>. Further, the below-described functions of the receiver <NUM> may be performed by the data reception manager component <NUM>, or one of its subcomponents, operated by the modem <NUM> of UE <NUM> or the modem <NUM> of AN <NUM>.

At step <NUM>, the transmitter and receiver may sustain a cellular link with a synchronized frame structure. In an implementation, the internal clock and the frame structure of each node may be mutually locked, such as via a synchronization procedure as described herein.

At step <NUM>, the transmitter may request capabilities about the buffering capabilities of the receiver.

At step <NUM>, the receiver may provide such capabilities with or without request.

At step <NUM>, the transmitter may request receiver-side buffering with respect to the time-aware schedule.

At step <NUM>, the receiver may acknowledge this request or reject the request.

At step <NUM>, the transmitter may receive a configuration of the time-aware schedule defining time intervals with respect to the clock of the transmitter for a designated traffic class.

At step <NUM>, the transmitter extracts relevant information from the time-aware schedule and sends the information, e.g., timing information, to the receiver. The information may include at least one or a set of time intervals and a traffic class identifier. The information may also include a buffer size value. The information may further provide information that maps the time intervals defined by the time-aware schedule to equivalent intervals in the frame structure.

At step <NUM>, the receiver may be configured to allocate a buffer for traffic transmitted outside a designated time interval. For example, the transmitter may send the receiver a request for receiver-side buffering including, for example, a requested buffer size.

At step <NUM>, first data traffic of the designated traffic class may arrive at the transmitter side, e.g. arrives at a lower cellular protocol layer.

At step <NUM>, according to an implementation, all or some of the first data traffic may be transmitted during one of the designated time intervals defined by the time-aware schedule.

At step <NUM>, the receiver may decode the first data traffic, recognize that the first data traffic was sent during the designated time interval, and forward the first data traffic to upper layers. In an aspect, the forwarding may occur in response to recognizing that the first data traffic was sent during the designated time interval. The first data traffic may be forwarded without buffering, or without waiting for a particular time to forward the data.

Further, at step <NUM>, second data traffic of the designated traffic class may arrive at the transmitter side.

At step <NUM>, according to an implementation, all or some of the second data traffic may be transmitted outside the designated time intervals defined by the time-aware schedule.

At step <NUM>, the receiver may decode the second data traffic sent outside the designed time interval, recognize that the second data traffic was sent outside the designated time interval, and therefore buffer the second data traffic.

At step <NUM>, when the next designated time interval arrives for the designated traffic class, the receiver may forward the buffered second data traffic to the upper layers.

According to the above described example method <NUM>, a determination of data buffering may be based on the transmission of the data with respect to a designated time interval. Alternatively, the determination of data buffering may also be based on the reception of the data with respect to the designated time interval. Other example implementations may be provided without losing generality.

In performing method <NUM>, the procedural actions or functions and/or components performing such actions or functions on each of the transmitter <NUM> and receiver <NUM> may be summarized below.

For example, the transmitter <NUM> may be configured with the data transmission manager component <NUM>, or one of its subcomponents, operated by the modem <NUM> of UE <NUM> or the modem <NUM> of AN <NUM> to perform one or more of these actions or functions.

The transmitter <NUM> may be configured to support a clock synchronized to a frame structure of a cellular link.

The transmitter <NUM> may be configured to receive information about buffering capabilities from the receiver and to determine that buffer capabilities are sufficient for receiver-side buffering.

The transmitter <NUM> may be configured to receive a time-aware schedule, including an indicator for the receiver <NUM>, and time intervals referenced to a first clock together with a traffic class identifier referring to the respective time intervals. The indicator for the receiver <NUM> may be indicated via an IMSI, TMSI, RNTI, EMEI or a radio-network identifier. The traffic class identifier may be one of DRB, EPS bearer, PDN connection, PDU session, flow identifier (QFI), <NUM> QoS Identifier (5QI), Ethernet source or destination address, Ethernet type, VLAN tag, VLAN id, VLAN PCP, IP source or destination address, DSCP entry, UDP or TCP source or destination port number. Also, transmitter <NUM> may be configured to receive information about the traffic load associated with the traffic class identifier.

The transmitter <NUM> may be configured to determine that frame-preemption is supported for the wireless link.

The transmitter <NUM> may be configured to forward timing information related to the time-aware schedule to the receiver <NUM> indicated, together with the request for receiver-side buffering. The timing information may include a buffer side estimate, a traffic class identifier related to the cellular link such as a DRB Id, a QFI or 5QI, and translations of the time intervals of the time-aware schedule to another time base, e.g. such as the frame structure (where the transmitter <NUM> may be configured to generate such translations). The timing information may only include a subset of time intervals.

The transmitter <NUM> may be configured to receive an acknowledgement or a rejection to the request for receiver-side buffering.

If an acknowledgement was received, the transmitter <NUM> may be configured to send traffic data of the indicated traffic class outside the time intervals. The transmitter <NUM> may be configured to match traffic data sent outside the time intervals to the buffering capabilities sent by the receiver <NUM>. The traffic data may be a MAC-layer transport block, a MAC-layer code block, an RLC PDU, a PDCP PDU, an Ethernet frame or an IP packet. The transmitter <NUM> may be configured to match the traffic data to the buffering capabilities on the receiver <NUM>.

Correspondingly, the receiver <NUM> may be configured to support a clock synchronized to a frame structure of a cellular link.

The receiver <NUM> may be configured to send information about buffering capabilities to a peer, e.g., the transmitter <NUM>, on the cellular link. The peer on the cellular link may be an AN <NUM> and the information may be sent based on a request by the peer.

The receiver <NUM> may be configured to receive timing information related to a time-aware schedule from the peer including time intervals referenced to a time base together with a traffic class identifier referring to the time intervals and an indicator for receiver-side buffering. The receiver side buffering requirements may be included in the receiver-side buffering request. The traffic class identifier may be related to the cellular link such as a DRB Id, a QFI or 5QI. The time base may refer to the frame structure or the first clock. In an aspect, the time base of the first clock may be referred to as a factory time master clock. Further, the timing information may only include a subset of time intervals.

The receiver <NUM> may be configured to acknowledge the receiver-side buffering request or reject the request, e.g., in a case where the receiver-side buffering requirements cannot be met.

The receiver <NUM> may be configured to receive traffic data of the traffic class outside the time intervals indicated, buffer the traffic, and forward the traffic to upper layers within the time intervals indicated in the timing information related to the time-aware schedule. The traffic data may include, but is not limited to, a MAC-layer transport block, a MAC-layer code block, an RLC PDU, a PDCP PDU, an Ethernet frame or an IP packet. The traffic data received may be matched to the buffering capabilities on the receiver <NUM>.

Referring to <FIG>, in operation, another example implementation of a receiver-side buffering method <NUM> between the transmitter <NUM> and the receiver <NUM> sustaining the cellular interface <NUM> includes either of the nodes being the AN <NUM>, and the corresponding peer being the UE <NUM>. It may be appreciated that the transmitter <NUM> refers to the time-aware schedule, which is typically defined for a unidirectional traffic flow of a specific traffic class.

At step <NUM>, the transmitter <NUM> and receiver <NUM> may sustain a cellular link with a synchronized frame structure. In an implementation, the internal clock and the frame structure of each node may be mutually locked, such as via a synchronization procedure as described herein.

At step <NUM>, the transmitter <NUM> may request capability information about the buffering capabilities of the receiver <NUM>.

At step <NUM>, the receiver <NUM> may provide such capabilities with or without request.

At step <NUM>, the transmitter <NUM> may request receiver-side buffering with respect to the time-aware schedule.

At step <NUM>, the receiver <NUM> may acknowledge this request or reject it.

At step <NUM>, the transmitter <NUM> may receive a configuration of the time-aware schedule defining time intervals with respect to the clock of the transmitter <NUM> for a designated traffic class.

At step <NUM>, the transmitter <NUM> may extract relevant information from the time-aware schedule and sends the information to the receiver <NUM>. The information includes at least a traffic class identifier and may also include a buffer size value.

At step <NUM>, the receiver <NUM> may be configured to allocate a buffer for traffic received outside a designated time interval. For example, the transmitter <NUM> may send the receiver a request for receiver-side buffering including, for example, a requested buffer size.

At step <NUM>, first data traffic of the designated traffic class arrives at the transmitter side, e.g., arrives at a lower cellular layer.

At step <NUM>, according to an example implementation, all or some of the first data traffic may be transmitted during one of the designated time intervals defined by the time-aware schedule. The transmitter <NUM> may include a no-buffering-required indicator into the transmission.

At step <NUM>, the receiver <NUM> may decode the first data traffic, recognize that the data was sent during the designated time interval since a no-buffering-required indicator is found or since no time-indicator is included, and forward the first data traffic to upper layers.

At step <NUM>, according to an implementation, all or some of the second data traffic may be transmitted outside the designated time intervals defined by the time-aware schedule. The transmitter <NUM> may include a time indicator with the transmission of the traffic data. In this case, the time indicator may have a value based on the time until the next designated time interval.

At step <NUM>, the receiver <NUM> may decode the second data traffic sent outside the designed time interval, recognize that the second data traffic was sent outside the designated time interval since the time-indicator is included, and buffer the data for a time frame that is derived from the time indicator.

At step <NUM>, when the time frame indicated by the time indicator expires, the receiver <NUM> may forward the buffered second data traffic to upper layers.

According to this example implementation, a determination of data buffering may be based on the transmission of the data with respect to a designated time interval. Alternatively, the determination of data buffering may also be based on the reception of the data with respect to the designated time interval. Other example implementations may be provided without losing generality.

For example, the transmitter <NUM> may be configured to synchronize an internal clock to a frame structure of a cellular link.

The transmitter <NUM> may be configured to receive information about buffering capabilities from the receiver <NUM> and determine that the buffer capabilities are sufficient for receiver-side buffering.

The transmitter <NUM> may be configured to receive a time-aware schedule configuration, including an indicator for the receiver <NUM>, a set of one or more time intervals referenced to a first clock together with one or more respectively correspondingly traffic class identifiers (identifying a traffic class) referring to the respective time intervals. The receiver <NUM> may be indicated via an IMSI, TMSI, RNTI, EMEI or a radio-network identifier. The traffic class identifier may be one of DRB, EPS bearer, PDN connection, PDU session, flow identifier (QFI), <NUM> QoS Identifier (5QI), Ethernet source or destination address, Ethernet type, VLAN tag, VLAN id, VLAN PCP, IP source or destination address, DSCP entry, UDP or TCP source or destination port number. Also, the transmitter <NUM> may be configured to receive information about the traffic load associated with the traffic class identifier.

The transmitter <NUM> may be configured to determine that frame-preemption or preemptive transmission of traffic data is supported for the wireless link, e.g., cellular interface <NUM>, and by the receiver <NUM>.

The transmitter <NUM> may be configured to forward timing information related to the time-aware schedule to the receiver <NUM> indicated together with a request for receiver-side buffering of preemptively-transmitted traffic data. The timing information may include a buffer size estimate, and/or a traffic class identifier, such as a DRB Id, a QFI or 5QI, related to the cellular interface <NUM>.

The transmitter <NUM> may be configured to receive an acknowledgement or a rejection to the request for receiver-side buffering. If an acknowledgement was received, the transmitter <NUM> may be configured to send or wireless transmit the data traffic of the indicated traffic class outside the time intervals for the traffic class, where the transmission of the traffic data includes a time indicator (e.g., an absolute value or a relative value relative to internal clock <NUM>) that identifies when the traffic data, e.g., data frame, must be buffered before forwarding to higher protocol layers. The time indicator may be sent on a control channel such as the PDCCH or PUCCH, or may be included in a MAC Control Element or another header. The transmitter <NUM> may be configured to match an amount of the traffic data sent outside the time intervals to the buffering capabilities sent by the receiver <NUM>. The traffic data may include, but is not limited to, a MAC-layer transport block, a MAC-layer code block, an RLC PDU, a PDCP PDU, an Ethernet frame or an IP packet.

The transmitter <NUM> may be configured to send the traffic data of the indicated traffic class inside the time intervals with a no-buffering-required indicator. The no-buffering-required indicator may be implicit such as by omitting the time-indicator for buffering, or explicit such as by inserting a time-indicator where the time is set to zero.

The receiver <NUM> may be configured to support a clock synchronized to a frame structure of a cellular link.

The receiver <NUM> may be configured to send information about buffering capabilities to a peer, e.g., transmitter <NUM>, on the cellular interface <NUM>. The peer on the cellular link may be the AN <NUM> and the information may be sent based on a request by the peer.

The receiver <NUM> may be configured to receive timing information related to a time-aware schedule from the peer with a corresponding traffic class identifier, and optionally with an indicator or request for receiver-side buffering. The receiver-side buffering requirements may be included in the request and the traffic class identifier, such as a DRB Id, a QFI or <NUM> QI, may be related to the cellular interface <NUM>.

The receiver <NUM> may be configured to acknowledge the receiver-side buffering request or reject the request, e.g. in case the receiver-side buffering requirements cannot be met.

Further, the receiver <NUM> may be configured to receive traffic data of a traffic class, determine if buffering is required based on an indicator included in the traffic data, such as a time-indicator or a no-buffering-required indicator. The indicator may be retrieved from a control channel such as the PDCCH or PUCCH, or from MAC Control Element or another header.

The receiver <NUM> may be configured to buffer the traffic data for the time indicated by the time indicator, and then forward the traffic data to higher protocol layers. The traffic data may include but is not limited to a MAC-layer transport block, a MAC-layer code block, an RLC PDU, a PDCP PDU, an Ethernet frame or an IP packet. An amount of the traffic data receiving may be matched to the buffering capabilities on the receiver <NUM>.

According to another example implementation of the present invention, the receiver <NUM> may receive the configuration containing information related to the time-aware schedule from a third node, such as an SDN-controller or a Centralized Network Controller. In another example implementation, the time-aware schedule may specify time intervals where transmissions should not occur rather than where transmissions should occur.

Referring to <FIG>, one example of a method <NUM> of wireless communication may be performed by a receiver node, such as receiver <NUM> include one of AN <NUM> or UE <NUM> acting as a receiving device. In particular, the actions of method <NUM> may be performed by data reception manager component <NUM>, and/or one or more subcomponents or associated components describe herein, which may be executed by a processor or a modem one of AN <NUM> or UE <NUM>. Portions of example implementation architectures for AN <NUM> and UE <NUM> are described above, and additional description is provided in the below discussion of method <NUM> in the context of an implementation on AN <NUM> based on the architecture described below and in the subsequent description of AN <NUM> in <FIG>.

At <NUM>, method <NUM> may optionally include performing a synchronization procedure to synchronize the synchronized clock with a clock of a node transmitting the traffic data. In this case, the node transmitting the traffic data may be considered a master clock <NUM>. For example, in a factory scenario, the node transmitting the traffic data may maintain a factory time master clock. In another example, the transmitter may be synchronized with a UE (e.g., UE <NUM>) and the UE may receive the offset between the clock of the node transmitting the data and the transmitter which allows the UE <NUM> to be synchronized with the master clock <NUM>. Hence the time aware schedule can be in reference to either the factory time master clock or the transmitter. For example, in an aspect, AN <NUM> and/or processor <NUM> and/or modem <NUM> and/or data reception manager component <NUM> may execute a synchronization component <NUM> to perform a synchronization procedure to synchronize the synchronized clock with a clock of the node transmitting the traffic data, as described herein. In an aspect, performing the synchronization procedure may include establishing a cellular link having a synchronized frame structure, and locking an internal clock with the frame structure to define the synchronized clock.

At <NUM>, method <NUM> may optionally include transmitting buffering capability information to the node transmitting the traffic data. For example, in an aspect, AN <NUM> and/or processor <NUM> and/or modem <NUM> and/or data reception manager component <NUM> may execute a buffer manager component <NUM> to transmit buffering capability information to the node transmitting the traffic data, e.g., transmitter <NUM> or UE <NUM>. In an aspect, transmitting the buffering capability information may be in response to receiving a buffering capability request. Moreover, the buffering capability information may describe an amount of buffer available, e.g., a value of space in a memory, and/or a rate of buffering that may be accommodated by receiver <NUM> or AN <NUM>.

At <NUM> and <NUM>, method <NUM> may optionally include receiving a receiver-side buffering request, and transmitting an acknowledgement or a rejection of the receiver-side buffering request, respectively. For example, in an aspect, AN <NUM> and/or processor <NUM> and/or modem <NUM> and/or data reception manager component <NUM> may execute buffer manager component <NUM> to receive a receiver-side buffering request, and to generate and transmit an acknowledgement or a rejection of the receiver-side buffering request, respectively, e.g., based on whether the parameters of the receiver-side buffering request are within or exceed the buffering capability of the receiver <NUM> or AN <NUM>. For example, the receiver-side buffering request may include a request to buffer preemptively transmitted traffic data <NUM>, and may further include a requested buffer size. Correspondingly, AN <NUM> and/or processor <NUM> and/or modem <NUM> and/or data reception manager component <NUM> and/or traffic controller <NUM> and/or buffer manager component <NUM> may setup and allocate traffic buffer <NUM> having the requested buffer size.

Referring now to <FIG>, at <NUM>, method <NUM> may include receiving timing information corresponding to a traffic class identifier, wherein the timing information is associated with a time interval for communicating data of a traffic class corresponding to the traffic class identifier. For example, in an aspect, AN <NUM> and/or processor <NUM> and/or modem <NUM> and/or data reception manager component <NUM> and/or traffic controller <NUM> may receive timing information corresponding to a traffic class identifier, wherein the timing information is associated with a time interval for communicating data of a traffic class corresponding to the traffic class identifier, as described herein.

In a non-claimed aspect relating to method <NUM>, at 610a, receiving the timing information may optionally include receiving identification of the time interval referenced to a synchronized clock prior to receiving the traffic data.

Relating to method <NUM>, at 610b, receiving the timing information includes receiving a time indicator included with the traffic data, wherein the time indicator identifies the next occurrence of the time interval.

At <NUM>, method <NUM> may optionally include allocating a traffic data buffer in a memory in response to receiving the timing information corresponding to the traffic class identifier. For example, in an aspect, AN <NUM> and/or processor <NUM> and/or modem <NUM> and/or data reception manager component <NUM> and/or traffic controller <NUM> and/or buffer manager component <NUM> may allocate a traffic buffer <NUM> in a memory in response to receiving the timing information corresponding to the traffic class identifier, as described herein. In some cases, the traffic buffer <NUM> may be partitioned into a plurality of different, independently-sized traffic class-specific buffers. For example, in some cases, AN <NUM> and/or processor <NUM> and/or modem <NUM> and/or data reception manager component <NUM> and/or traffic controller <NUM> and/or buffer manager component <NUM> may allocate a traffic buffer <NUM> in response to receiving a request for receiver-side buffering including, for example, a requested buffer size.

At <NUM>, method <NUM> includes receiving traffic data pertaining to the traffic class. For example, in an aspect, AN <NUM> and/or processor <NUM> and/or modem <NUM> and/or data reception manager component <NUM> and/or traffic controller <NUM> may receive traffic data pertaining to the traffic class, such as via antennae <NUM>, RF front end <NUM>, transceiver <NUM>, and/or processor(s) <NUM>. In an aspect, receiving the traffic data comprises receiving at a first protocol layer, such as a PHY protocol layer.

At <NUM>, method <NUM> includes determining that the traffic data was transmitted or is received outside the time interval. For example, in an aspect, AN <NUM> and/or processor <NUM> and/or modem <NUM> and/or data reception manager component <NUM> and/or traffic controller <NUM> and/or timing determiner <NUM> may determine that the traffic data was transmitted or is received outside the time interval.

In a non-claimed aspect relating to method <NUM>, at 616a, determining that the traffic data was transmitted or is received outside the time interval may optionally be based on a value of the synchronized clock not matching a value of the time interval;.

In method <NUM>, at 616b, determining that the traffic data was transmitted or is received outside the time interval is based on a value of the time indicator relative to a value of a synchronized clock that is synchronized to the time interval. Further, in this aspect, the value of the time indicator may be a relative time value or a specific time value. Also, in this aspect, receiving the timing information may further comprise receiving time-aware schedule information separate from and prior to receiving the time indicator and the traffic data, wherein the time-aware schedule information identifies at least the traffic class identifier of data subject to the time interval.

At <NUM>, method <NUM> may include buffering the traffic data in response to the traffic data being transmitted or received outside the time interval. For example, in an aspect, AN <NUM> and/or processor <NUM> and/or modem <NUM> and/or data reception manager component <NUM> and/or traffic controller <NUM> and/or buffer manager component <NUM> may buffer the traffic data in response to the traffic data being transmitted or received outside the time interval.

At <NUM>, method <NUM> optionally may include determining the next occurrence of the time interval. For example, in an aspect, AN <NUM> and/or processor <NUM> and/or modem <NUM> and/or data reception manager component <NUM> and/or traffic controller <NUM> and/or timing determiner <NUM> may determine the next occurrence of the time interval, as described herein. In an aspect relating to method <NUM>, determining the next occurrence of the time interval may be based on the value of the synchronized clock matching the value of the time interval. In an aspect related to method <NUM>, determining the next occurrence of the time interval may be based on the value of a synchronized clock and the value of the time indicator.

At <NUM>, method <NUM> includes forwarding the traffic data in response to a next occurrence of the time interval. For example, in an aspect, AN <NUM> and/or processor <NUM> and/or modem <NUM> and/or data reception manager component <NUM> and/or traffic controller <NUM> and/or timing determiner <NUM> and/or buffer manager component <NUM> may forward the traffic data in response to a next occurrence of the time interval, as described herein. In an aspect, forwarding the traffic data includes forwarding the traffic data to a second protocol layer, wherein the second protocol layer (e.g., a MAC protocol layer or other higher layer) is relatively higher in a protocol stack as compared to the first protocol layer (e.g., PHY layer).

At <NUM>, method <NUM> optionally includes receiving additional traffic data pertaining to the traffic class. For example, in an aspect, AN <NUM> and/or processor <NUM> and/or modem <NUM> and/or data reception manager component <NUM> and/or traffic controller <NUM> may receive the additional traffic data pertaining to the traffic class, as described herein. In an aspect relating to method <NUM>, receiving the additional traffic data further comprises receiving the additional traffic data with an indicator. The indicator may be an implicit indicator or an explicit indicator. The indicator may indicate that the additional traffic data was transmitted or is received inside the respective occurrence of the time interval.

At <NUM>, method <NUM> optionally includes determining that the additional traffic data was transmitted or is received inside a respective occurrence of the time interval. For example, in an aspect, AN <NUM> and/or processor <NUM> and/or modem <NUM> and/or data reception manager component <NUM> and/or traffic controller <NUM> and/or timing determiner <NUM> may determine that the additional traffic data was transmitted or is received outside the time interval. In the aspect relating to method <NUM>, determining that the additional traffic data was transmitted or is received inside the respective occurrence of the time interval may be based on the indicator.

At <NUM>, method <NUM> optionally includes forwarding the additional traffic data. For example, in an aspect, AN <NUM> and/or processor <NUM> and/or modem <NUM> and/or data reception manager component <NUM> and/or traffic controller <NUM> and/or timing determiner <NUM> may forward the additional traffic data, e.g., to a relatively higher protocol layer without buffering based on the transmission or receipt being inside the time interval for the traffic class associated with the additional traffic data.

Referring to <FIG>, one example of a method <NUM> of wireless communication may be performed by a transmitter node, such as transmitter <NUM> including one of UE <NUM> or AN <NUM> acting as a transmitting device. In particular, the actions of method <NUM> may be performed by data transmission manager component <NUM>, and/or one or more subcomponents or associated components described herein, which may be executed by a processor or a modem one of UE <NUM> or AN <NUM>. Portions of example implementation architectures for UE <NUM> and AN <NUM> are described above, and additional description is provided in the below discussion of method <NUM> in the context of an implementation on AN <NUM> based on the architecture described below and in the subsequent description of UE <NUM> in <FIG>. In an implementation, a synchronization component <NUM> may perform the synchronization actions described below. Also, in an implementation, the transmit configuration manager may perform the buffering capability-related procedures and/or the receiver-side buffering request procedures and/or the generation and transmission of the timing information discussed herein.

At <NUM>, method <NUM> may optionally include performing a synchronization procedure to synchronize an internal clock with a clock of a node receiving the traffic data. In some implementations, for example, performing the synchronization procedure may include establishing a cellular link having a synchronized frame structure, and locking the internal clock with the frame structure to define a synchronized clock.

At <NUM> and <NUM>, method <NUM> may optionally include transmitting a buffering capability request to a node that will be receiving traffic data, and/or receiving buffering capability information from the node receiving the traffic data. In some cases, the transmitter <NUM> may not request the buffering capability information but may receive the buffering capability information unprompted or based on other communications with the receiver <NUM>. In other cases, receiving the buffering capability information is in response to receiving a buffering capability request.

At <NUM> and <NUM>, method <NUM> may optionally include transmitting a receiver-side buffering request, and receiving an acknowledgement or a rejection of the receiver-side buffering request. In an aspect, for instance, the transmit configuration manager <NUM> may transmit the receiver-side buffering request and receive the acknowledgement or the rejection of the receiver-side buffering request. For example, the receiver-side buffering request may include a request to buffer preemptively transmitted traffic data <NUM> and may further include a requested buffer size, which may cause the receiving node to allocate traffic buffer <NUM> having the requested buffer size.

At <NUM>, method <NUM> may optionally include receiving a time-aware schedule configuration. In an aspect, for example, the data transmission manager component <NUM> may receive the time-aware schedule configuration.

At <NUM>, method <NUM> includes transmitting timing information corresponding to a traffic class identifier, wherein the timing information is associated with a time interval for communicating data of a traffic class corresponding to the traffic class identifier. In an aspect, for example, the transmit configuration manager <NUM> may transmit the timing information corresponding to the traffic class identifier <NUM>. The timing information is associated with the time interval <NUM> for communicating data of a traffic class corresponding to the traffic class identifier <NUM>. In an aspect, transmitting the timing information is based on the time-aware schedule information received at <NUM>.

At 912a, in a non-claimed aspect, transmitting the timing information may optionally include transmitting identification of the time interval referenced to a synchronized clock prior to transmitting the traffic data. At 912b, transmitting the timing information includes transmitting a time indicator with the traffic data when transmitting the traffic data, wherein the time indicator identifies the next occurrence of the time interval. In an aspect, the value of the time indicator may be a relative time value or a specific time value.

In an aspect, transmitting the timing information may further include transmitting time-aware schedule information separate from and prior to transmitting the time indicator and the traffic data, wherein the time-aware schedule information identifies at least the traffic class identifier of data subject to the time interval.

In an aspect, transmitting the timing information corresponding to the traffic class identifier is configured to cause a node receiving the timing information to allocate a traffic data buffer in a memory. For example, the transmitter <NUM> may send the receiver <NUM> a request for receiver-side buffering including, for example, the timing information and a requested buffer size.

At <NUM>, method <NUM> includes receiving traffic data pertaining to the traffic class. For example, the transmit controller <NUM> may receive the traffic data pertaining to the traffic class from a hardware component (e.g., a sensor), an application, or another device.

At <NUM>, method <NUM> includes determining that the traffic data is received outside the time interval. For example, the transmit configuration manager <NUM> may compare a time that the traffic data is received to the time interval <NUM> for the traffic class identifier <NUM> to determine that the traffic data is received outside the time interval <NUM>.

At <NUM>, method <NUM> includes transmitting the traffic data outside of the time interval based on the transmitting of the timing information corresponding to the traffic class identifier. For example, the transmit controller <NUM> may transmit the traffic data <NUM> outside of the time interval <NUM> based on transmitting the timing information <NUM> corresponding to the traffic class identifier <NUM> at <NUM>. In some aspects, transmitting the traffic data pertaining to the traffic class outside the time interval is in response to receiving the acknowledgement at <NUM>.

At <NUM>, method <NUM> may optionally include receiving additional traffic data pertaining to the traffic class. For example, the transmit controller <NUM> may receive the additional traffic data pertaining to the traffic class from a hardware component (e.g., a sensor), an application, or another device.

At <NUM>, method <NUM> may optionally include determining that the additional traffic data is received inside a respective occurrence of the time interval. For example, the transmit configuration manager <NUM> may compare a time that the traffic data is received to the time interval <NUM> for the traffic class identifier <NUM> to determine that the traffic data is received inside the time interval <NUM>.

At <NUM>, method <NUM> may optionally include transmitting the additional traffic data inside of a respective time interval. For example, the transmit controller <NUM> may transmit the additional traffic data <NUM> inside of the respective time interval <NUM>. In an aspect relating to method <NUM>, for example, transmitting the additional traffic data may optionally include transmitting the additional traffic data with an indicator, the indicator being an implicit indicator or an explicit indicator that identifies that the additional traffic data was transmitted inside the respective time interval.

Referring to <FIG>, one example of an implementation of UE <NUM> may include a variety of components, some of which have already been described above, but including components such as one or more processors <NUM> and memory <NUM> and transceiver <NUM> in communication via one or more buses <NUM>, which may operate in conjunction with modem <NUM> and data transmission manager component <NUM> to enable one or more of the functions described herein. Further, the one or more processors <NUM>, modem <NUM>, memory <NUM>, transceiver <NUM>, RF front end <NUM> and one or more antennas <NUM>, may be configured to support voice and/or data calls (simultaneously or non-simultaneously) in one or more radio access technologies.

In an aspect, the one or more processors <NUM> can include a modem <NUM> that uses one or more modem processors. The various functions related to data transmission manager component <NUM> may be included in modem <NUM> and/or processors <NUM> and, in an aspect, can be executed by a single processor, while in other aspects, different ones of the functions may be executed by a combination of two or more different processors. For example, in an aspect, the one or more processors <NUM> may include any one or any combination of a modem processor, or a baseband processor, or a digital signal processor, or a transmit processor, or a receiver processor, or a transceiver processor associated with transceiver <NUM>. In other aspects, some of the features of the one or more processors <NUM> and/or modem <NUM> associated with data transmission manager component <NUM> may be performed by transceiver <NUM>.

Also, memory <NUM> may be configured to store data used herein and/or local versions of applications <NUM> or data transmission manager component <NUM> and/or one or more of its subcomponents being executed by at least one processor <NUM>. Memory <NUM> can include any type of computer-readable medium usable by a computer or at least one processor <NUM>, such as random access memory (RAM), read only memory (ROM), tapes, magnetic discs, optical discs, volatile memory, non-volatile memory, and any combination thereof. In an aspect, for example, memory <NUM> may be a non-transitory computer-readable storage medium that stores one or more computer-executable codes defining data transmission manager component <NUM> and/or one or more of its subcomponents, and/or data associated therewith, when UE <NUM> is operating at least one processor <NUM> to execute data transmission manager component <NUM> and/or one or more of its subcomponents.

Receiver <NUM> may include hardware, firmware, and/or software code executable by a processor for receiving data, the code comprising instructions and being stored in a memory (e.g., computer-readable medium). Additionally, receiver <NUM> may process such received signals, and also may obtain measurements of the signals, such as, but not limited to, Ec/Io, SNR, RSRP, RSSI, etc. Transmitter <NUM> may include hardware, firmware, and/or software code executable by a processor for transmitting data, the code comprising instructions and being stored in a memory (e.g., computer-readable medium).

Referring to <FIG>, one example of an implementation of AN <NUM> may include a variety of components, some of which have already been described above, but including components such as one or more processors <NUM> and memory <NUM> and transceiver <NUM> in communication via one or more buses <NUM>, which may operate in conjunction with modem <NUM> and data reception manager component <NUM> to enable one or more of the functions described herein.

Referring to <FIG>, in accordance with various aspects of the present disclosure, aspect of receiver-side preemptive data buffering may be performed by one or more devices in an example wireless communication access network <NUM> that includes at least one UE <NUM> with a modem <NUM> having data transmission manager component <NUM> as described herein. Further, wireless communication access network <NUM>, also referred to as a wireless wide area network (WWAN), includes at least one base station <NUM> with a modem <NUM> having data reception manager component <NUM> as described herein. UE <NUM> and base station <NUM> may be the same as or similar to or may include Ethernet node <NUM> / UE <NUM> / transmitter <NUM> and Ethernet node <NUM> / AN <NUM> / receiver <NUM> described above.

The one or more UEs <NUM> and/or the one or more base stations <NUM> may communicate with other UEs and/or other base stations via a core network such as an Evolved Packet Core (EPC) <NUM> or a <NUM> Core (5GC). The base stations <NUM> (collectively referred to as Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN)) interface with the core network (e.g., EPC <NUM> or 5GC) through backhaul links <NUM> (e.g., S1 interface). The base stations <NUM> may communicate directly or indirectly (e.g., through the EPC <NUM> and/or 5GC) with each other over backhaul links <NUM> (e.g., X2 interface).

A network that includes both small cell and macro cells may be known as a heterogeneous network. The base stations <NUM> / UEs <NUM> may use spectrum up to Y MHz (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) bandwidth per carrier allocated in a carrier aggregation of up to a total of Y*x MHz (where x is a number of component carriers) used for transmission in each direction. The carriers may or may not be adjacent to or contiguous with each other. Allocation of carriers may be asymmetric with respect to DL and UL (e.g., more or less carriers may be allocated for DL than for UL).

When the gNB <NUM> operates in mmW or near mmW frequencies, the gNB <NUM> may be referred to as a mmW base station.

The base station may also be referred to as a gNB, Node B, evolved Node B (eNB), an access point, a base transceiver station, a radio base station, a radio transceiver, a transceiver function, a basic service set (BSS), an extended service set (ESS), or some other suitable terminology. The base station <NUM> provides an access point to the EPC <NUM> and/or 5GC for one or more UEs <NUM>. Examples of UEs <NUM> include a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a laptop, a personal digital assistant (PDA), a satellite radio, a global positioning system, a multimedia device, a video device, a digital audio player (e.g., MP3 player), a camera, a game console, a tablet, a smart device, a wearable device, a vehicle, an electric meter, a gas pump, a large or small kitchen appliance, a healthcare device, an implant, a display, or any other similar functioning device.

It should be noted that the techniques described herein may be used for various wireless communication networks such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and other systems. The terms "system" and "network" are often used interchangeably. IS-<NUM> Releases <NUM> and A are commonly referred to as CDMA2000 1X, 1X, etc. IS-<NUM> (TIA-<NUM>) is commonly referred to as CDMA2000 1xEV-DO, High Rate Packet Data (HRPD), etc. UTRA includes Wideband CDMA (WCDMA) and other variants of CDMA. An OFDMA system may implement a radio technology such as Ultra Mobile Broadband (UMB), Evolved UTRA (E-UTRA), IEEE <NUM> (Wi-Fi), IEEE <NUM> (WiMAX), IEEE <NUM>, Flash-OFDM™, etc. UTRA and E-UTRA are part of Universal Mobile Telecommunication System (UMTS). 3GPP Long Term Evolution (LTE) and LTE-Advanced (LTE-A) are new releases of UMTS that use E-UTRA. UTRA, E-UTRA, UMTS, LTE, LTE-A, and GSM are described in documents from an organization named "3rd Generation Partnership Project" (3GPP). The techniques described herein may be used for the systems and radio technologies mentioned above as well as other systems and radio technologies, including cellular (e.g., LTE) communications over a shared radio frequency spectrum band. The description below, however, describes an LTE/LTE-A system for purposes of example, and LTE terminology is used in much of the description below, although the techniques are applicable beyond LTE/LTE-A applications (e.g., to <NUM> networks or other next generation communication systems).

Claim 1:
A method of wireless communications at a receiving node, comprising:
receiving (<NUM>) timing information corresponding to a traffic class identifier, wherein the timing information is associated with a time interval for communicating traffic data of a traffic class corresponding to the traffic class identifier;
receiving (<NUM>) the traffic data pertaining to the traffic class;
determining (<NUM>) that the traffic data was transmitted or is received outside and after a first occurrence of the time interval;
buffering (<NUM>) the traffic data in response to the traffic data being transmitted or received outside the time interval; and
forwarding (<NUM>) the traffic data in response to a next occurrence of the time interval;
wherein receiving the timing information comprises receiving (610b) a time indicator included with the traffic data, wherein the time indicator identifies the next occurrence of the time interval;
wherein determining that the traffic data was transmitted or is received outside the time interval is based (616b) on a value of the time indicator relative to a value of a synchronized clock that is synchronized to the time interval;
and further comprising:
determining the next occurrence of the time interval based on the value of the synchronized clock and the value of the time indicator.