System and method for packet delay correction to remove jitter

Abstract

Disclosed is a method for execution by a PDC (Packet Delay Correction) device for periodic traffic. The method involves obtaining PDCAI (Packet Delay Correction Assistance Information) including (i) periodicity information and (ii) maximum delay already set for packet data. The method also involves receiving a data stream including data packets, wherein the data stream as received has jitter due to the data packets experiencing variable delay over a network to the PDC device. The method also involves performing PDC to correct for such variable delay in periodic traffic flows using the PDCAI thereby producing a new data stream without the jitter, and sending the new data stream to a target node. In accordance with an embodiment of the application, the PDC involves intentionally delaying a first packet of the data stream based on the maximum delay already set for packet data and scheduling subsequent packets based on the periodicity information.

Description

[0001] P111643WQ01

[0002] - 1 -

[0003] SYSTEM AND METHOD FOR

[0004] PACKET DELAY CORRECTION TO REMOVE JITTER

[0005] Field of the Disclosure

[0006] [1] This disclosure relates to communication systems, and more particularly to PDC (Packet Delay Correction).

[0007] Background

[0008] Per-Stream Filtering and Policing and Scheduled Traffic

[0009] [2] I EEE (Institute of Electrical and Electronics Engineers) has developed PSFP (Per-Stream Filtering and Policing), which is a mechanism that policies the ingress ports of the TSN (Time-Sensitive Networking) bridges. PSFP is defined per TSN stream. It defines the time window by which arriving packets of a stream are allowed to enter, while any packets outside of the window will be dropped. Instead, Qbv (Scheduled Traffic) defines similar windows for the egress port and on a per traffic class basis (i.e. for multiple TSN streams being belonging to the same traffic class). It defines the time window that packets stored in a Qbv queue (of an egress port for a traffic class) are allowed to be transmitted out to the next node. Both mechanisms are based on gates that open during the allowed time window and let pass corresponding packets either to be transmitted out of egress port or being received at ingress port. The gate closes at the end of the window. When the gate is closed PSFP drops packets, while Qbv queues them until they can be transmitted through an open gate again. Most TSN streams are periodic, which implies also periodic gating. See IEEE 802.1 Q-2022 entitled “IEEE Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks” published 2022-12-22.

[0010] Support for TSN and DetNet in 5G System

[0011] [3] 3GPP (3rd Generation Partnership Project) introduced TSC (Time-Sensitive Communications) framework in 5G in order to support deterministic type of communications that have been standardized in IEEE, namely TSN (Time-Sensitive P111643WQ01

[0012] - 2 -

[0013] Networking), and in IETF (Internet Engineering Task Force), namely DetNet (Deterministic Networking). The main enabler to support these technologies in the RAN is URLLC (Ultra Reliable Low Latency Communications) which guarantees a bounded delay, delay-critical type of QoS (quality of service), and reliable communication. See 3GPP TS 23.501 entitled “System architecture for the 5G System (5GS)”, version 19.0.0, uploaded 2024-06-26 (hereinafter “3GPP TS 23.501”).

[0014] [4] With TSC the 5G system is modelled as a node which mimics the behavior of a regular fixed node that supports time-sensitive communication. Figure 5 shows an example how a 5G logical TSN bridge 300 is placed in a TSN network. Specifically, the 5G logical TSN bridge 300 is connected to other TSN bridges 301 a-c or TSN end stations (such as Talker 302 or Listener 303). The 5G logical bridge 300 also interfaces an external control plane management entity, in this case the TSN controller 305 (aka CNC (Centralized Network Configuration)). Note that in the case of a fully centralized architecture in TSN, applications in the Talker 302 or Listener 303 (aka TSN end stations) communicate with a CUC (Centralized User Configuration) 306 which oversees user configurations, which then is passed in terms of communication requirements to the CNC 305, the network controller. After the CNC 305 has collected all TSN flows’ requirements from the CUC 306 and all bridge components’ capabilities, the CNC 305 sets the configuration for all the bridge components (TSN bridges 301 a-c and TSN end station NIC (Network Card Interface) using a configuration protocol such as NETCONF (Network Configuration Protocol) or RESTCONF (Representational State Transfer Configuration).

[0015] [5] To interface 5G system with the other TSN nodes, 3GPP introduced TSN translators (TT) at the device side 310 (DS-TT) and at the network side 311 (NW-TT), as shown in Figure 6. The translators 310-311 provide the TSN Ethernet interface and mimic the expected behavior of a number of TSN features (such as Qbv and PSFP), without the need to radically modify the functionalities of the 5G nodes and functions. To interface with the CNC 305, a TSN application function 312 (TSN AF) was defined. The TSN AF 312 obtains the 5G bridge capabilities and provides them to the CNC 305, while the CNC 305 configures the 5G bridge 300 via the TSN AF 312. This configuration may include the control information to be able to support features such as PSFP and Qbv. The TSN AF 312 translates the capabilities to the parameters that the CNC 305 handles and translates the configuration from the CNC 305 into a flow set up in the 5G system. Finally, the TSN AF 312 also handles the typical time synchronization data sets that can be configured by the CNC 305. All the specific port configuration from CNC 305 and other relevant information is exchanged between TSN AF 312 and DS-TT 310 or between TSN AF 312 and NW-TT 311 using a PMIC (Port Management Information Container) that is transferred via a number of 5G / 6G NFs.

[0016] [6] Note that TSN is a specific case of TSC. In general, TSC would involve the use of a similar entity to the TSN AF, known as the TSC and TSCTSF (Time Synchronization Function). TSCTSF performs similar tasks as the TSN AF but with a generalized exposure interface that is proxied via the NEF (Network Exposure Function) as shown in Figure 7, unless the external AF (Application Function) is a trusted entity for the 5G system, in which case the NEF is not needed. TSCTSF, like the TSN AF, exchanges PMIC with DS-TTs and NW-TT. In the general case, any AF can request a deterministic service via 5G and the 5G system is considered a node.

[0017] [7] A similar technology to TSN has been standardized in IETF, namely DetNet, which is implemented in layer 3 of the OSI reference model supporting IP-based communications. Similarly, 3GPP has modeled 5G system as a logical DetNet node 400, just as illustrated in Figure 8.

[0018] [8] In the case of DetNet, the general TSC framework was reused where the TSCTSF 402 interacts with the DetNet controller 401 (instead of AF) without the need for NEF since the controller 401 is considered a trusted entity. The information used in this interface between the TSCTSF 402 and the DetNet controller 401 uses the defined YANG models for DetNet. The TSCTSF 402 translates the configuration from the DetNet controller 401 into requirements towards the 5G system, similarly as in the case of TSN AF. With DetNet there is no requirement for a DS-TT since the interface is IP-based which is already supported in 5G, and no additional translation is needed. If a time synchronization service or any other port configuration / information is required, then the DS-TT will be required. UE-to-UE communications

[0019] [9] For TSN, DetNet and TSC in general, it is possible to have UE-to-UE communications, as shown in Figure 9, which is a block diagram of a 5G Virtual Bridge 420 enabling UE-to-UE communication. As per clause 5.28.2, 3GPP TS 23.501 :

[0020] If the TSN AF determines that the TSN stream is for UE-UE communication (i.e. ingress and egress ports are in DS-TTs), the TSN AF divides the stream into one uplink stream and one or more downlink streams and provides the streams on AF Session basis to the PCF(s). The SMF applies local switching as specified in clause 5.8.2.13 or clause 5.8.2.5.3 in order to enable UPF locally forward uplink stream from one PDU session as downlink stream in another PDU session.

[0021]

[0010] As per clause 5.27.5, 3GPP TS 23.501 :

[0022] TSN AF deduces the port pair(s) consisting of two DS-TT ports connecting to the same 5GS bridge and determines the 5GS bridge delay as sum of bridge delays related to PDU Sessions of two DS-TT ports.

[0023]

[0011] The per-traffic class bridge delays between the UE (User Equipment) and the UPF / NW-TT are pre-configured in the TSN AF in its pre-configured QoS tables. Usually a bridge delay (or 5GS delay in the case of TSC) is the sum of PDB (Packet Delay Budget) + DS-TT residence time. In the case of UE-to-UE communication, then it will be the summation of PDB and DS-TT residence time for one PDU session leg, and PDB and DS- TT residence time for the other PDU session leg.

[0024]

[0012] As per clause 5.28.5.3, 3GPP TS 23.501 :

[0025] If the flow is UE-to-UE, two PDU Sessions will be affected for the flow, and the TSCTSF breaks up the requirements to individual requirements for the PDU Sessions. P111643WQ01

[0026] - 5 -

[0027] QoS requirements and TSC assistance container

[0028]

[0013] For the case of TSC, TSCAC (TSC assistance container) can be generated based on information provided in the AF session request with QoS.

[0029]

[0014] Assuming that all requests are authorized and individual QoS parameters are provided, a simplified procedure is shown in Figure 10, which is a flowchart of a procedure for QoS requirements and TSC assistance container.

[0030]

[0015] At step 1 , the AF sends a request to the NEF and provides its traffic pattern as assistance parameters. According to clause 4.15.6.6 “Setting up an AF session with required QoS procedure”:

[0031] If the TSCTSF receives a Requested 5GS Delay, the TSCTSF calculates a Requested PDB by subtracting the UE-DS-TT Residence Time (either provided by the PCF or pre-configured at TSCTSF) from the Requested 5GS Delay and sends the Requested PDB to the PCF instead of the Requested 5GS Delay. If the TSCTSF receives any of the following parameters: flow direction, Burst Arrival Time, Periodicity, Time domain, Survival Time, Capability for BAT adaptation or BAT Window, Periodicity Range from the NEF, the TSCTSF determines the TSC Assistance Container and sends it to the PCF instead of these parameters.

[0032]

[0016] At step 2, the NEF forwards the received individual QoS params to the TSCTSF.

[0033]

[0017] At step 3, the TSCTSF calculates a Requested PDB = Requested 5G Delay - UE-DS-TT Residence Time.

[0034]

[0018] At step 4, the TSCTSF sends a Requested PDB, TSC Assistance Container and other received individual QoS params to the PCF (Policy Control Function). TSCTSF specified parameter values are used to over-ride default values for the 5QI corresponding to the TSCTSF provided QoS Reference. P111643WQ01

[0035] - 6 -

[0036]

[0019] At step 5, the PCF derives the required QoS parameters and determines whether this QoS is allowed, (if) It derives the Alternative QoS parameters set(s).

[0037]

[0020] At step 6, the PCF sets the PBD and MDBV according to the Requested PDB, priority, and Burst Size received from the TSCTSF.

[0038]

[0021] At step 7, after the message exchange between the PCF, the TSCTSF and the NEF, the NEF sends the AF a message indicating whether the request is granted or not.

[0039] {22} In the case of TSN, TSN AF has a preconfigured QoS mapping table to translate TSN QoS parameters into 5G QoS parameters. Among these parameters, there is the PDB (Packet Delay Budget). With this, the TSN AF then sends a request to the PCF. TSC Assistance container is also generated by the TSN AF based on PSFP information or via preconfiguration, as also described in next section.

[0040] Derivation of TSC Assistance Information

[0041]

[0023] The derivation of TSCAI (TSC Assistance Information) for TSN AF or TSCTSF is as follows:

[0042] 1) TSC Assistance Container:

[0043] • TSCTSF determines the TSC Assistance Container including Burst Arrival Time, Periodicity, Flow Direction, Survival Time, and Time Domain.

[0044] • Time domain refers to the time domain for these parameters. It might be needed to perform correct conversion from time domain clock to the 5G clock in the SMF (Session Management Function).

[0045] • (for TSN case) TSN AF determines the TSC Assistance Container using the IEEE PSFP configuration parameters provided by the CNC to extract the traffic characteristics, yet the Survival Time may be pre-configured.

[0046] 2) TSCTSF / TSN AF provides the TSC Assistance container to the PCF. 3) PCF forwards the container to the SMF as a part of PCC (Policy and Charging Control) rules.

[0047] 4) SMF binds the PCC rules with the container and use it to derive TSCAI on a per QoS Flow basis.

[0048] • Converting the BAT (Burst Arrival Time), Periodicity and Survival Time from an external clock to the 5G clock using the latest time offset and cumulative rateRatio from the UPF (relative to the given Time domain).

[0049] 5) SMF sends the mapped TSCAI to the NG-RAN (Next Generation Radio Access Network).

[0050] Background on PDC (Packet Delay Correction)

[0051]

[0024] TSN, DetNet, and 5G technologies are seen today as complementary technologies in deterministic communication networks, paving the way towards future advanced manufacturing systems and other verticals areas. These technologies are important for network convergence, i.e., the support of all kinds of communication services via the same network infrastructure. Furthermore, interworking and integration of these technologies is key to supporting the deterministic communication services over heterogeneous infrastructure and multiple application domains for network convergence.

[0052]

[0025] E2E (End-to-End) Deterministic communication over integrated 5G / 6G-TSN network may require deterministic transmission latency between ingress and egress. This is mainly described as the upper bound / maximum allowed or packet delay (maximum delay) together with maximum tolerated PDV (Packet Delay Variation). Today in wired Ethernet-based TSN network, packet delay variation is inherently very small.

[0053]

[0026] However, in today’s 5G system, one of the key challenges lies in enabling deterministic transmission is PDV. PDV of the 5G system today remains considerable higher and it is 1-2 orders of magnitude larger compared to regular wired TSN bridges where latencies can be controlled at the level of 10’s microsecond. Some of TSN P111643WQ01

[0054] - 8 - mechanisms such as Qbv on the E2E path require very deterministic latency behavior in every node on the transmission path for it to work properly.

[0055]

[0027] The high packet delay variation of a 5G system is too large to practically apply Qbv for some time-schedule configurations, even though support for Qbv has been targeted in the 5G standard. Therefore, to ensure integration and interworking with wired deterministic technology such as TSN and DetNet, it is desirable to guarantee a bounded packet delay variation. H&F (Hold and Forward) buffering mechanism was conceived in 3GPP (3GPP TS 23.501 ) with the purpose to hold the packets for a time, before forwarding out of the system.

[0056]

[0028] Some previous approaches for PDC mechanisms to be applied with H&F may involve the use of metadata within every single packet in order to apply the mechanism of PDC (metadata can be e.g., a timestamp). This might be a drawback in terms of overhead. It is important to note that how H&F works was up to implementation and no PDC was standardized. However, PDC is still required for multiple deterministic applications.

[0057]

[0029] It is an object of some embodiments to improve upon the previous approaches in a manner that addresses, solves or mitigates some or all of the deficiencies.

[0058] Summary of the Disclosure

[0059]

[0030] 5G / 6G have an intrinsic PDV (Packet Delay Variation) which is not acceptable to several use cases, and especially for periodic traffic. There is no current support in the specifications to perform a PDC (Packet Delay Correction) in order to compensate for the intrinsic 5G / 6G PDV. Available PDC proposals either require metadata to be added to every single packet or can only be applied to TSN (Time-Sensitive Networking).

[0060]

[0031] The invention proposes a new PDC mechanism by using periodicity information of the traffic flow. The proposed mechanisms do not add overhead in all packets in a flow and can guarantee stable periodic delivery of packets. That is, this PDC is targeted for periodic traffic flows, which cannot tolerate the 5G / 6G-introduced PDV. The mechanism can be applied when 5G / 6G integrates with TSN, DetNet, or for the generic 5G / 6G TSC framework (without TSN or DetNet).

[0061]

[0032] Note that how H&F is implemented is not specified in 3GPP. Due to disagreements in 3GPP SA2, H&F was left as a way to deliver the behavior of Qbv, but the de-jittering functionality remains an open issue. A PDC mechanism can be applied using the H&F feature in order to minimize the PDV (de-jitter), and guarantee delivery that is neither early nor late, but just on time. This is a key issue for periodic traffic. For example, if now all packets spend the same time between ingress and egress of the 5G / 6G before being forwarded, then the PDV is zero (i.e. , no variation in the delay).

[0062]

[0033] Disclosed is a PDC mechanism that can compensate (remove) PDV such that it does not affect the delivery of periodic traffic. A variation of the PDC for periodic flows that include more than one packet per period is also disclosed. Also, various ways to obtain the inputs for PDC are disclosed.

[0063]

[0034] Disclosed is a method for execution by a PDC (Packet Delay Correction) device for periodic traffic. The method involves obtaining PDCAI (Packet Delay Correction Assistance Information), which can be called PDC-specific assistance information or PDCAI for short). The PDCAI includes (i) periodicity information and (ii) maximum delay already set for the packet data. The method also involves receiving a data stream including data packets, wherein the data stream as received has jitter due to the data packets experiencing variable delay over a network to the PDC device. The method also involves performing PDC (Packet Delay Correction) to correct for such variable delay using the PDCAI thereby producing a new data stream without the jitter, and sending the new data stream to a target node. In accordance with an embodiment of the application, the PDC involves intentionally delaying a first packet of the data stream based on the maximum delay already set for packet data and scheduling subsequent packets based on the periodicity information.

[0064]

[0035] In this way, jitter can be removed for periodic traffic flows without the overhead of including metadata in every single packet as in some previous approaches. This can be an easier implementation than using regular timestamping PDC method, since packets in H&F buffer are already in the right order. Some embodiments correct jitter introduced by previous bridges / nodes since this PDC enforces a constant periodicity. In case of TSN, there is no need for the complexity of Qbv, priority queueing is enough.

[0065] {36} In some implementations, the first packet is delayed enough so that the first packet consumes 75% to 100% of the maximum delay for packet data. In specific implementations, the first packet is delayed enough so that it consumes 100% of the maximum delay for packet data. This can increase the chances that the jitter is completely removed.

[0066]

[0037] In some implementations, obtaining the PDCAI involves generating at least some of the PDCAI and / or accessing at least some of the PDCAI from preconfiguration. In other implementations, obtaining the PDCAI comprises receiving the PDCAI. In some implementations, receiving the PDCAI involves receiving the PDCAI from an AF (Application Function) using a PMIC (Port Management Information Container). However, other implementations are possible.

[0067]

[0038] A non-transitory CRM (computer readable medium) and a PDC device configured to implement the method summarized above are also disclosed.

[0068]

[0039] Also disclosed is a method for execution by a network node. The method involves determining PDCAI (Packet Delay Correction Assistance Information) including (i) periodicity information and (ii) maximum delay already set for packet data. In accordance with an embodiment of the application, the method also involves sending the PDCAI to a TSN (Time-Sensitive Networking) translator using a PMIC (Port Management Information Container).

[0069]

[0040] In some implementations, the periodicity information is measured or determined based on application or configuration.

[0070]

[0041] A non-transitory CRM (computer readable medium) and a network node configured to implement the method summarized above are also disclosed.

[0042] Other aspects and features of the present disclosure will become apparent, to those ordinarily skilled in the art, upon review of the following description of the various embodiments of the disclosure.

[0071] Brief Description of the Drawings

[0072]

[0043] Embodiments will now be described with reference to the attached drawings in which:

[0073] Figure 1 is a block diagram of a communication system, in accordance with an embodiment of the disclosure;

[0074] Figure 2 is a sequence drawing of a method of compensating for variable delay using PDCAI (Packet Delay Correction Assistance Information) to avoid or mitigate jitter;

[0075] Figure 3 is a schematic showing operation of periodicity-based PDC (Packet Delay Correction);

[0076] Figure 4 is a block diagram of a system showing operation of PDCAI being transferred to DS-TT and NW-TT ;

[0077] Figure 5 is a block diagram of a 5G logical TSN (Time-Sensitive Networking) bridge in a TSN network;

[0078] Figure 6 is a block diagram of a 5G system acting as a TSN bridge;

[0079] Figure 7 is a block diagram showing TSN as a special case of 5G TSC;

[0080] Figure 8 is a block diagram of a 5G logical DetNet node;

[0081] Figure 9 is a block diagram of a 5G Virtual Bridge enabling UE-to-UE communication;

[0082] Figure 10 is a flowchart of a procedure for QoS requirements and TSC assistance container;

[0083] Figure 11 is a schematic of an example cellular communications system in which some embodiments of the present disclosure may be implemented; Figures 12A and 12B are block diagrams of a wireless communication system represented as a 5G network architecture in which some embodiments of the present disclosure may be implemented; and

[0084] Figure 13 is a schematic of an example communication system according to some embodiments of the present disclosure.

[0085] Detailed Description of Embodiments

[0086]

[0044] It should be understood at the outset that although illustrative implementations of one or more embodiments of the present disclosure are provided below, the disclosed systems and / or methods may be implemented using any number of techniques. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended embodiment along with their full scope of equivalents.

[0087] Introduction

[0088]

[0045] Referring first to Figure 1 , shown is a block diagram of a communication system 100, in accordance with an embodiment of the disclosure. The communication system 100 has a first communication node 111 operatively coupled to a network 132. The first communication node 111 can for example be a UE (User Equipment) configured to communicate with the network 132. Such communication could involve a user plane node 133 of the network 132 and / or a second communication node 121.

[0089]

[0046] In the case that the first communication node 111 is receiving packet data over the network 132, for example from the user plane node 133 and / or the second communication node 121 , there may be variable delay applied to the packet data during transit, especially if the network 132 is a wireless network. In other words, the packet data as received is not perfectly periodic due to some packets being delayed more than others. Unfortunately, such variable delay may be unacceptable for some applications. In accordance with an embodiment of the disclosure, the communication system 100 has a PDC (Packet Delay Correction) device 114 that sets out to correct or compensate for such variable delay using PDCAI (Packet Delay Correction Assistance Information) to avoid or mitigate jitter as described in further detail below.

[0090]

[0047] The PDC device 114 has a network interface 115 configured to communicate with the network 132, a CRM 119, and PDC circuitry 116 coupled to the network interface 115 and the CRM 119. In some implementations, the PDC circuitry 106 includes a processor 117 that executes software, which can stem from a memory 118. However, other implementations are possible and are within the scope of this disclosure. The PDC device 114 can have additional components, but these are not shown for simplicity.

[0091]

[0048] In some implementations, the PDC device 114 is separate from the first communication node 111 as shown. For such implementations, the PDC device 114 may be a TSN (Time Sensitive Networking) translator. In other implementations, the PDC device 114 is part of the first communication node 111 (e.g. UE). For such implementations, the PDC device 114 may have functionality of a TSN translator but may be referred to as a PDC device. The term “PDC device” as used herein generally refers to a device that implements PDC functionality as described herein, regardless of whether the PDC device is part of another apparatus such as a UE or base station, or separate from such apparatus in which case the PDC device may be a TSN translator.

[0092]

[0049] In some implementations, the network has a network node 134 having PDCAI generation circuitry 136 configured to generate the PDCAI for the PDC device 114. Such network node 134 also has a network interface 135 configured to communicate with the network 132, and a CRM 139. In some implementations, the PDCAI generation circuitry 136 includes a processor 137 that executes software, which can stem from a memory 138. However, other implementations are possible and are within the scope of this disclosure. The network node 134 can have additional components, but these are not shown for simplicity.

[0093]

[0050] The PDC circuitry 116 of the PDC device 114 operates to implement a method of compensating for the variable delay using the PDCAI to avoid or mitigate jitter, and the PDCAI generation circuitry 136 of the network node 134 operates to implement a method of generating the PDCAI for the PDC device 114. Such operation will be described below with reference to Figure 2. Although the method of Figure 2 is described below with reference to the communication system 100 shown in Figure 1 , it is to be understood that the method of Figure 2 is applicable to other communication systems. In general, the method of Figure 2 is applicable to any appropriately configured communication system.

[0094]

[0051] The method of Figure 2 assumes that the first node 111 is receiving data from the second communication node 121. Similar processing would occur if the first node 111 were to receive data from the user plane node 133 or other node. For such scenarios, as will be described below, PDC is applied at an egress point of the communication system 100, and more specifically by the PDC device 114. Unlike previous PDCs, there is no need to perform any task at an ingress point. It is to be understood that the opposite scenario (not shown) in which the first node 111 is sending data is also possible. In such opposite scenario, PDC could be applied by a PDC device (now shown) coupled to the second communication node 121 , the user plane node 133, or other node. For two-way communication, there would normally be two PDC devices.

[0095]

[0052] In some implementations, the network node 134 generates the PDCAI at step 2-1 and sends, over the network interface 135, the PDCAI to the PDC device 114 at step 2-2. Details of how the network node 134 can generate the PDCAI are provided later. In other implementations, the PDC device 114 obtains the PDCAI through other means or generates the PDCAI itself. The PDCAI can be called PDC-specific assistance information or PDCAI for short, and includes information from which the PDC device 114 can use to remove jitter, including both (i) periodicity information and (ii) maximum delay already set for packet data. In some implementations, the PDCAI includes additional information.

[0096]

[0053] At step 2-3, the PDC device 114 receives, over the network interface 115, packet data PD2, which was transmitted by a source (e.g. the second communication node 121). Note that the source transmits packet data PD1 , which upon traversing the network can experience some variable delay, such that the packet data PD2 includes some packets that are delayed more than other packets, thereby resulting in jitter in the packet data PD2 that is received.

[0054] Unfortunately, such variable delay may be unacceptable for some applications. Therefore, at step 2-4 the PDC device 114 performs PDC to correct or compensate for such variable delay using the PDCAI to avoid or mitigate jitter in the packet data PD3 that is provided to the first node 111 at step 2-5. Further explanation of the PDC performed by the PDC device 114 is provided below with reference to Figure 3.

[0097]

[0055] Referring now to Figure 3, shown is a schematic showing operation of periodicity-based PDC. The periodicity-based PDC is applied at an egress point of the communication system. For TSC, TSN, that usually means DS-TT or NW-TT (depending on whether it is DL or UL, respectively). For DetNet that means DS-TT and NW-TT, meaning that now DS-TT is required for DetNet. However, since most of jitter contributions are in the RAN segment, the PDC can be applied in this segment and the egress point could be UE or gNB (NR base station), depending on whether it is DL or UL, respectively. In the case of Figure 3, the egress point is a DS-TT 113, and the periodic traffic flow is DL as shown.

[0098]

[0056] Consider the following definition:

[0099] • FT(n): forwarding time for packet n

[0100] For a packet n:

[0101] • FT(n) = FT(n-1) + periodicity

[0102] FT(1) is the calculated forwarding time for the first packet.

[0103]

[0057] In some implementations, the egress point (UE 113 in this example) must know: (i) periodicity and (ii) “maximum delay” per periodic flow. The first packet is either forwarded immediately upon arrival to the egress point (if periodicity > (maximum delay)) or it is delayed at egress point for maximum delay, before forwarding (if periodicity <= (maximum delay)). The reason for these conditions is explained below.

[0104]

[0058] A maximum delay is needed for the PDC. When used, the first packet waits the maximum delay before being forwarded by the egress point. To understand the reason, let’s assume a first packet is sent immediately without waiting maximum delay. If (in the worst case) that packet had an actual residence time in 5G / 6G system close to zero (few microseconds), and if (in the worst case) the next packet experienced maximum delay, then the time between the first two packets is (maximum delay). If the periodicity is smaller than this value, then the PDC will not be successful (time between packet 1 and packet 2 is larger than required periodicity). If periodicity is larger than (maximum delay), then even if the time between the first two packets is (in the worst case) (maximum delay), the second packet still needs to wait until reaching the required value of the periodicity.

[0105]

[0059] Hence:

[0106] • If periodicity > (maximum delay), then the egress point does not need to know and use maximum delay.

[0107] • Otherwise, if periodicity <= (maximum delay), then the egress point needs to know and use maximum delay.

[0108]

[0060] Although there is an added delay for the very first packet (when periodicity <= (maximum delay)), the rest of packets show no jitter as delay is constant. This is not obvious relative to conventional approaches which often seek to minimize latency. However, by permitting a greater latency for the very first packet, it becomes possible to mitigate or eliminate jitter for subsequent packets. For some applications which do not tolerate jitter, this can be especially advantageous, and such advantage is accomplished in a non-obvious manner.

[0109]

[0061] The amount by which the first packet is delayed is implementation specific. In some implementations, the first packet is delayed enough so that the first packet consumes 75% to 100% of the maximum delay for packet data. In specific implementations, the first packet is delayed enough so that it consumes 100% of the maximum delay for packet data. This can increase the chances that the jitter is completely removed.

[0110]

[0062] Synchronization (in frequency) may be needed, such that 5GS / 6GS and application use same time scale for the periodic time value. Unless the application tolerates a little range of variation in the periodicity (i.e. , periodicity provided by 5G / 6G is not identical to the application’s, but still within a tolerance range).

[0111]

[0063] In some implementations, the data packets are from an OTT (Over-the-Top) connection. Example details for an OTT connection are provided later with reference to Figure 13. However, other implementations are possible beyond OTT, for example UE- UE connection as described herein.

[0112]

[0064] According to another embodiment of the disclosure, there is provided a non- transitory CRM having recorded thereon statements and instructions that, when executed by the processor 117 of the PDC device 114, implement a method as described herein. The non-transitory computer readable medium can be the memory 118 and / or the CRM 119 of the PDC device 114 shown in Figure 1 , or some other non-transitory CRM.

[0113]

[0065] According to another embodiment of the disclosure, there is provided a non- transitory CRM having recorded thereon statements and instructions that, when executed by the processor 137 of the network node 134, implement a method as described herein. The non-transitory computer readable medium can be the memory 138 and / or the CRM 139 of the network node 134 shown in Figure 1 , or some other non-transitory CRM.

[0114]

[0066] Examples of a non-transitory CRM include memory, an SSD (Solid State Drive), a hard disk drive, a CD (Compact Disc), a DVD (Digital Video Disc), a BD (Blu-ray Disc), a memory stick, etc. Other non-transitory CRMs are also possible.

[0115]

[0067] The illustrated examples described herein focus on software implementations. However, other implementations are possible and are within the scope of this disclosure. Other implementations can include additional or alternative hardware components, such as any appropriately configured FPGA (Field-Programmable Gate Array), ASIC (Application-Specific Integrated Circuit), and / or microcontroller, for example. Thus, the PDC circuitry 116 of PDC device 114 and the PDCAI generation circuitry 136 of the network node 134 can instead be implemented with any suitable combination of hardware, software and / or firmware.

[0068] There are many possibilities for the network 102. In some implementations, the network 102 includes a 6G (Sixth Generation) network. Even if we refer to the existing 5G parameters, such as “Requested 5GS delay”, the intended application is for 6G, and that is assuming that 6G will be backwards compatible with the TSC features in 5G. In other implementations, the network 102 includes a 5G (Fifth Generation) network. Example details of a 5G network are provided later. Other implementations are possible beyond 5G and 6G.

[0116]

[0069] Further example details are provided in the following sections. It is to be understood that the following sections are very specific and are provided merely for exemplary purposes, such that other implementations are possible and within the scope of the disclosure.

[0117] Obtaining PDCAI

[0118]

[0070] As noted above, the PDC device 114 uses PDCAI to remove jitter. The PDCAI includes both (i) periodicity information and (ii) maximum delay. Some embodiments define how to obtain such input information, which may involve standardization

[0119] • on how to get maximum delay and periodicity, and

[0120] • on how to get parameter indicating that there can be more than one packet per period

[0121]

[0071] It is noted that the maximum delay can depend on whether it is a UE-UPF communication or a UE-UE communication.

[0122] • maximum delay = PDB + DS-TT residence time (for UE-UPF communication)

[0123] • maximum delay = 2xPDB + DS-TT(@UE1) residence time + DS-TT(@UE2) residence time (for UE-UE communication) P111643WQ01

[0124] - 19 -

[0125] How to get this input at egress point? Other PDCs assume maximum delay is available at TTs, but that is not the case, unless the value is preconfigured for every traffic flow, or for every traffic class / priority .

[0126]

[0072] Even if PCF sends PDB in 5QI (included PCC rules) to SMF, SMF distributes QoS profile to gNB (available for gNB). However, how does UE and UPF get maximum delay?

[0127]

[0073] QoS rules sent to UE via N1 are for UL traffic, but we need PDB for DL traffic (egress DL); and QoS information / filters to UPF via N4 is for DL traffic, but we need PDB for UL traffic (egress UL). This means that PDB is not really available, and even if it is available there are two issues:

[0128] • DS-TT residence time is still required at NW-TT.

[0129] • UE-to-UE communications are managed and know only to TSN AF and TSCTSF, and the association of two PDU sessions may not be readily available at other NFs. UE-to-UE communications certainly have a totally different maximum delay = 2xPDB + DS-TT(1 ) residence time + DS-TT(2) residence time.

[0130]

[0074] TSN AF and TSCTSF already know DS-TT residence times (as they are reported from the system) and they already build a TSC Assistance container that includes Periodicity. In some implementations, TSN AF or TSCTSF may include the value of maximum delay in this container.

[0131]

[0075] The next issue is that TSC Assistance container is delivered to SMF, and then SMF (after time conversions) sends TSCAI to the NG-RAN node. A next step would be that SMF also delivers the TSCAI (or a part of it, or another container e.g., in PDCAI including maximum delay, and the TSCAI’s periodicity) to the UE (via e.g., AMF, N1) and UPF (via e.g., N4). Then UE and UPF transfers the information to their respective TTs. However, the TSCAI periodicity has 5G clock as reference, which is not correct to use at the TTs as it is needed to keep same reference time as the external TSN clock. Therefore, the periodicity to be included in PDCAI should be the one before time conversion in SMF (i.e. , the one in the TSC Assistance container).

[0132]

[0076] A second approach is directly transferring maximum delay and periodicity (as PDCAI) to DS-TT and NW-TT using the a PMIC (Port Management Information Container) for the transfer between TSN AF(or TSCTSF) and UE / DS-TT, and between TSN AF(or TSCTSF) and UPF / NW-TT.

[0133]

[0077] To apply periodicity-based PDC it is needed to know / measure the value of periodicity. Figure 4 is a block diagram of a system showing operation of the PDCAI being transferred to DS-TT 114 and NW-TT 124.

[0134] • At DS-TT 114 and NW-TT 124 o Included in the PMIC sent from TSN AF 134 (or TSCTSF) to the TTs 114 and 124. o TSC assistance container (containing periodicity of the flow) will be extended to include maximum delay for the traffic flow. SMF 141 will generate PDCAI and deliver it to UE 113 (via e.g., AMF 142, N1) and to UPF 133 (via e.g., N4). The SMF shall not convert the time reference for PDCAI. Then UE 113 transfers to DS-TT 114, and UPF 133 transfers to NW-TT 124. See Figure 4. Note that TSC Assistance container is generated by TSN AF 134 or TSCTSF. o TTs may know periodicity value via preconfiguration. o Ingress TT can measure periodicity continuously for some first periods, and then transfers the periodicity value to egress TT (e.g., as metadata in one packet). o Egress TT measures periodicity if only the first (two or more) packets are timestamped (may require some metadata for timestamping a few packets). o At UE 113 and gNB 144 o This segment is also interesting, since it gives the largest contribution to packet delay variation in the 5GS / 6GS. o Today gNB 144 gets periodicity from control plane (e.g., TSCAI), but then the UE 113 needs to get it by SMF 141 also forwarding TSCAI to UE 113 (via AMF 142, N1). In this case, since PDC is applied within the 5G / 6G system, it is correct to use the time-converted TSCAI periodicity. o UE 113 may know periodicity value via preconfiguration. o Ingress point (gNB 144 or UE 113) measures periodicity and transfer to egress point (UE 113 or gNB 144) (e.g., via metadata in one packet). o Egress point measures periodicity if first packets are timestamped (may require some metadata for timestamping a few packets). o RAN delay max (instead of maximum delay) is in this case: RAN-PDB. o AMF 142 can extract AN-PDB (Access Network Packet Delay Budget) value from the QoS profile and 5QI and distribute to gNB 144 and connected UEs 113 that need this mechanism (ex. because they are using the TSC or TSN service).

[0135]

[0078] In some implementations, the PDC device is part of a base station (e.g. gNB) receiving the data stream via uplink, and the maximum delay already set for packet data is the AN-PDB. In other implementations, the PDC device is part of a UE receiving the data stream via downlink, and the maximum delay already set for packet data is the AN-PDB.

[0136]

[0079] In some implementations, as noted above, the PDCAI is sent to the TSN translators via PMIC. In other implementations, the maximum delay parameter is added to a TSC assistance container, which may already contain the periodicity information, and then at the SMF these two values are included in PDCAI that then is sent to the TSN translators. Lost Packet

[0137]

[0080] In some implementations, a mechanism shall be applied to handle the case when a packet is lost. Otherwise, the next FT will be wrong, and the PDC will stop working properly. One possible solution is as follows:

[0138] • The egress point knows when the next transmission should be, i.e. FT(n) = FT(n- 1)+ periodicity.

[0139] • If next packet n does not arrive within the periodicity window (before FT(n)), then egress point assumes the packet as lost and calculates next forwarding time FT(n+1), just as if the packet n was transmitted. Then it expects packet n+1 .

[0140] • After a (predefined) number of periods without packets, then UE simply waits for next packet and starts as if it is the first packet.

[0141] When Periods Include Multiple Packets

[0142]

[0081] Note in one case the ingress point needed to add a timestamp to every packet of the flow. For this, some information should be available at the egress point:

[0143] (i) the maximum delay (maximum delay that a packet can experience in the 5GS / 6GS) and

[0144] (ii) the periodicity of this flow.

[0145]

[0082] The invention adds a case to consider when there are multiple packets per period. This may require different treatment and some metadata. This variation may require input on whether the traffic flow can have multiple packets per period. Also, the ingress point (which will be the entity adding the extra metadata) can determine packets belonging to the same period (i.e., when there are multiple packets in a period). It is important to mention that this would be a rare case. For example, in smart factory scenarios (see 3GPP TS 22.104 entitled “Service requirements for cyber-physical control applications in vertical domains”, version 19.2.0, uploaded 2024-06-28, hereinafter “3GPP TS 22.104”) the survival time for cyclic traffic can be equally expressed in terms of number of periods, or in terms of number of messages, meaning that the expectation in to have a single message per period.

[0083] In 3GPP TS 22.104, description of e.g., Survival Time is used assuming single message per period. Without this assumption (i.e., single packet per period), it is needed to know whether there are multiple packets per period. Information could be provided by CNC (TSN), DetNet controller, or from an AF, or it can be simply deducted by the ingress point by observation.

[0146]

[0084] A similar mechanism as described before can be applied, but the periodicity goes on a per burst of packets. Packets within the burst in a single period need to be sent consecutively. A flag can be added (minimum overhead, 1 bit) to packets (in their headers) belonging to a period - inserted by the ingress point.

[0147]

[0085] Use of the flag: frames from burst in period 1 have flag=0, frames from burst in period 2 flag swaps to 1 , and in the next period it swaps back to 0, and so on. The flag is added to the packet by the ingress point. The egress point shall remove the flag before forwarding to the target next node.

[0148] First Burst (frame x with first flag): o First packet treated exactly as in previous mechanism (for single packet per period) o Definitions: o Last Forwarding Time (LFT), and initial LFT = FT(1) (Forwarding Time FT of first packet). o previous_packet_Txtime: it is the transmission time of the previous packet. o inter_packet_gap: it is a predefined (small) time between packets to avoid any sort of overlap. o For all subsequent packets with same flag (while end of this period “LFT+periodicity” is not reached):

[0149] FT(x)= LFT + previous_packet_Txtime + inter_packet_gap o Then, we plan the forwarding time for the first packet with next flag: FT(y) = LFT + periodicity

[0150] Next Burst (frame y with next flag): o For all subsequent packets with same flag (while end of this period “LFT+periodicity” is not reached):

[0151] FT(y) = LFT + previous_packet_Txtime + inter_packet_gap o Then, we plan the forwarding time for the first packet with next flag: FT(x) = LFT + periodicity.

[0152]

[0086] If no packet arrives within a period, the PDC skips the part on “For all subsequent packets with same flag” and moves on to the next period. If some periods (predefined) are missed, then PDC jumps back to the beginning by waiting for the next packet and treating it as first packet.

[0153] Additional Details

[0154]

[0087] Additional details are provided below with reference to Figures 11 through 13. It is to be understood that these details are very specific for exemplary purposes only.

[0155]

[0088] Figure 11 illustrates one example of a cellular communications system 500 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 500 is a 5GS (5G system) including a NG-RAN (Next Generation RAN) and a 5GC (5G Core). In this example, the RAN includes base stations 102-1 and 502-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC), controlling corresponding (macro) cells 504-1 and 504-2. The base stations 502-1 and 502-2 are generally referred to herein collectively as base stations 502 and individually as base station 502. Likewise, the (macro) cells 504-1 and 504-2 are generally referred to herein collectively as (macro) cells 504 and individually as (macro) cell 504. The RAN may also include a number of low power nodes 506-1 through 506-4 controlling corresponding small cells 508-1 through 508-4. The low power nodes 506-1 through 506-4 can be small base stations (such as pico or femto base stations) or RRHs (Remote Radio Heads), or the like. Notably, while not illustrated, one or more of the small cells 508-1 through 508-4 may alternatively be provided by the base stations 502. The low power nodes 506-1 through 506-4 are generally referred to herein collectively as low power nodes 506 and individually as low power node 506. Likewise, the small cells 508-1 through 508-4 are generally referred to herein collectively as small cells 508 and individually as small cell 508. The cellular communications system 500 also includes a core network 510, which in the 5G System (5GS) is referred to as the 5GC. The base stations 502 (and optionally the low power nodes 506) are connected to the core network 510.

[0156]

[0089] The base stations 502 and the low power nodes 506 provide service to wireless communication devices 512-1 through 512-5 in the corresponding cells 504 and 508. The wireless communication devices 512-1 through 512-5 are generally referred to herein collectively as wireless communication devices 512 and individually as wireless communication device 512. In the following description, the wireless communication devices 512 are oftentimes UEs, but the present disclosure is not limited thereto.

[0157]

[0090] Referring now to Figure 12A, shown is a block diagram of a wireless communication system represented as a 5G network architecture composed of core NFs (Network Functions), where interaction between any two NFs is represented by a point-to- point reference point / interface. Figure 12A can be viewed as one particular implementation of the system 500 of Figure 11 .

[0158]

[0091] Seen from the access side the 5G network architecture shown in Figure 12A includes a plurality of UEs 613 connected to either a RAN 607 or an (Access Network) as well as an AMF 600. Typically, the R(AN) 607 comprises base stations, e.g. such as eNBs or gNBs or similar. Seen from the core network side, the 5GC NFs shown in Figure 12A include a NSSF 602, an AUSF 604, a UDM 606, the AMF 600, a SMF 608, a PCF 610, and an AF (Application Function) 612.

[0092] Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between the UE 613 and AMF 600. The reference points for connecting between the AN 607 and AMF 600 and between the AN 607 and U PF 614 are defined as N2 and N3, respectively. There is a reference point, N11 , between the AMF 600 and SMF 608, which implies that the SMF 608 is at least partly controlled by the AMF 600. N4 is used by the SMF 608 and UPF 614 so that the UPF 614 can be set using the control signal generated by the SMF 608, and the UPF 614 can report its state to the SMF 608. N9 is the reference point for the connection between different UPFs 614, and N14 is the reference point connecting between different AMFs 600, respectively. N15 and N7 are defined since the PCF 610 applies policy to the AMF 600 and SMF 608, respectively. N12 is utilized for the AMF 600 to perform authentication of the UE 613. N8 and N10 are defined because the subscription data of the UE 613 is utilized for the AMF 600 and SMF 608.

[0159]

[0093] The 5GC network aims at separating UP and CP. The UP carries user traffic while the CP carries signaling in the network. In Figure 12A, the UPF 614 is in the UP and all other NFs, i.e., the AMF 600, SMF 608, PCF 610, AF 612, NSSF 602, AUSF 604, and UDM 606, are in the CP. Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the RTT (Round Trip Time) between UEs and data network for some applications involving low latency.

[0160]

[0094] The core 5G network architecture is composed of modularized functions. For example, the AMF 600 and SMF 608 are independent functions in the CP. Separated AMF 600 and SMF 608 allow independent evolution and scaling. Other CP functions like the PCF 610 and AUSF 604 can be separated as shown in Figure 12A. Modularized function design enables the 5GC network to support various services flexibly.

[0161]

[0095] Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF. In the CP, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity. The UP supports interactions such as forwarding operations between different UPFs.

[0162]

[0096] Referring now to Figure 12B, shown is a block diagram of a 5G network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points / interfaces used in the 5G network architecture of Figure 12A. However, the NFs described above with reference to Figure 12B correspond to the NFs shown in Figure 12A. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In Figure 12B, the service based interfaces are indicated by the letter “N” followed by the name of the NF, e.g. Namf for the service based interface of the AMF 600 and Nsmf for the service based interface of the SMF 608, etc. The NEF 603 and the NRF 601 in Figure 12B are not shown in Figure 12A discussed above. However, it should be clarified that all NFs depicted in Figure 12A can interact with the NEF 603 and the NRF 601 of Figure 12B as necessary, though not explicitly indicated in Figure 12A.

[0163]

[0097] Some properties of the NFs shown in Figures 12A and 12B may be described in the following manner. The AMF 600 provides UE-based authentication, authorization, mobility management, etc. A UE 613 even using multiple access technologies is basically connected to a single AMF 600 because the AMF 600 is independent of the access technologies. The SMF 608 is responsible for session management and allocates IP (Internet Protocol) addresses to UEs. It also selects and controls the UPF 614 for data transfer. If a UE 613 has multiple sessions, different SMFs 608 may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF 612 provides information on the packet flow to the PCF 610 responsible for policy control in order to support QoS. Based on the information, the PCF 610 determines policies about mobility and session management to make the AMF 600 and SMF 608 operate properly. The AUSF 604 supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM 606 stores subscription data of the UE 613. The DN (Data Network), not part of the 5GC network, provides Internet access or operator services and similar.

[0098] An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

[0164]

[0099] The communication system of Figure 13 as a whole enables connectivity between the connected UEs 1112, 1114 and the host computer 1116. The connectivity may be described as an OTT (Over-the-Top) connection 1124. The host computer 1116 and the connected UEs 1112, 1114 are configured to communicate data and / or signaling via the OTT connection 1124, using the access network 1102, the core network 1104, any intermediate network 1122, and possible further infrastructure (not shown) as intermediaries. The OTT connection 1124 may be transparent in the sense that the participating communication devices through which the OTT connection 1124 passes are unaware of routing of uplink and downlink communications. For example, the base station 1106 may not or need not be informed about the past routing of an incoming downlink communication with data originating from the host computer 1116 to be forwarded (e.g., handed over) to a connected UE 1112. Similarly, the base station 1106 need not be aware of the future routing of an outgoing uplink communication originating from the UE 1112 towards the host computer 1116.

[0165]

[0100] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include DSPs (Digital Signal Processor), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as ROM (Read Only Memory), RAM (Random Access Memory), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

[0166]

[0101] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0167]

[0102] Numerous modifications and variations of the present disclosure are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended embodiments, the disclosure may be practised otherwise than as specifically described herein.

Claims

Claims:

1. A method for execution by a PDC (Packet Delay Correction) device for periodic traffic, comprising: obtaining PDCAI (Packet Delay Correction Assistance Information) comprising (i) periodicity information and (ii) maximum delay already set for packet data; and receiving a data stream comprising data packets, wherein the data stream as received has jitter due to the data packets experiencing variable delay over a network to the PDC device; and performing PDC to correct for such variable delay using the PDCAI thereby producing a new data stream without the jitter; and sending the new data stream to a target node; wherein the PDC comprises intentionally delaying a first packet of the data stream based on the maximum delay already set for packet data and scheduling subsequent packets based on the periodicity information.

2. The method of claim 1 , wherein the first packet is delayed enough so that the first packet consumes 75% to 100% of the maximum delay for packet data.

3. The method of claim 1 or claim 2, wherein obtaining the PDCAI comprises generating at least some of the PDCAI and / or accessing at least some of the PDCAI from preconfiguration.

4. The method of any one of claims 1 to 3, wherein obtaining the PDCAI comprises receiving the PDCAI.

5. The method claim 4, wherein receiving the PDCAI comprises receiving the PDCAI from an AF (Application Function) using a PMIC (Port Management Information Container).

6. The method of any one of claims 1 to 5, wherein the PDC device is a TSN translator for a UE (User Equipment) receiving the data stream via downlink for UE-UPF (User Equipment to User Plane Function) communication, and the maximum delay already set for packet data is a PDB (Packet Delay Budget) plus a residence time for the TSN translator.

7. The method of any one of claims 1 to 5, wherein the PDC device is a first TSN translator for a first UE (User Equipment) receiving the data stream via downlink for UE-UE (User Equipment to User Equipment) communication involving a second UE, and the maximum delay already set for packet data is two times a PDB (Packet Delay Budget) plus a first residence time for the first TSN translator plus a second residence time for a second TSN translator for the second UE.

8. The method of any one of claims 1 to 5, wherein the PDC device is a TSN translator for a UPF (User Plane Function) receiving the data stream via uplink, and the maximum delay already set for packet data is a PDB (Packet Delay Budget) plus a residence time for the TSN translator.

9. The method of any one of claims 1 to 5, wherein the PDC device is part of a base station receiving the data stream via uplink, and the maximum delay already set for packet data is an AN-PDB (Access Network Packet Delay Budget).

10. The method of any one of claims 1 to 5, wherein the PDC device is part of a UE (User Equipment) receiving the data stream via downlink, and the maximum delay already set for packet data is an AN-PDB (Access Network Packet Delay Budget).11 . The method of any one of claims 1 to 10, wherein the initial stream comprises multiple streams of data packets such that there are multiple data packets per period, and each data packet comprises a flag identifying which stream the data packet belongs to, and wherein the PDC is performed for each stream to produce multiple new data streams that are provided to the target node.

12. The method of any one of claims 1 to 11 , wherein scheduling subsequent packets based on the periodicity information comprises: for each subsequent packet that does not arrive within a periodicity window, assuming the subsequent packet to be lost and calculating a next forwarding time as though the subsequent packet was timely transmitted; and if a predefined number of periods lapse without any subsequent packets, waiting for a next packet and starting over as though the next packet is the first packet.

13. The method of any one of claims 1 to 12, wherein the data packets are from an OTT (Over-the-Top) connection.

14. A non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a PDC device, configure the PDC device to implement a method according to any one of claims 1 to 13.

15. A PDC (Packet Delay Correction) device for periodic traffic, comprising: a network interface configured to communicate with other network nodes;PDC device circuitry configured to: obtain PDCAI (Packet Delay Correction Assistance Information) comprising (i) periodicity information and (ii) maximum delay already set for packet data; and receive, over the network interface, a data stream comprising data packets, wherein the initial data stream as received has jitter due to the data packets experiencing variable delay over a network to the PDC device; and perform PDC (Packet Delay Correction) to correct for such variable delay using the PDCAI thereby producing a new data stream without the jitter; and send the new data stream to a node;wherein the PDC comprises intentionally delaying a first packet of the data stream based on the maximum delay already set for packet data and scheduling subsequent packets based on the periodicity information.

16. The PDC device of claim 15, wherein the PDC device circuitry is further configured to implement a method according to any one of claims 2 to 13.

17. A method for execution by a network node, comprising: determining PDCAI (Packet Delay Correction Assistance Information) comprising (i) periodicity information and (ii) maximum delay already set for packet data; and sending the PDCAI to a TSN (Time-Sensitive Networking) translator using a PMIC (Port Management Information Container).

18. The method of claim 17, wherein the periodicity information is measured or determined based on application or configuration.

19. The method of claim 17, wherein if the TSN translator is for a UE (User Equipment) receiving the data stream via downlink for UE-UPF (User Equipment to User Plane Function) communication, then the maximum delay already set for packet data is a PDB (Packet Delay Budget) plus a residence time for the TSN translator.

20. The method of claim 17, wherein if the TSN translator is a first TSN translator for a first UE (User Equipment) receiving the data stream via downlink for UE-UE (User Equipment to User Equipment) communication involving a second UE, then the maximum delay already set for packet data is two times a PDB (Packet Delay Budget) plus a first residence time for the first TSN translator plus a second residence time for a second TSN translator for the second UE.

21. The method of claim 17, wherein if the TSN translator is for a UPF (User Plane Function) receiving the data stream via uplink, then the maximum delay already setfor packet data is a PDB (Packet Delay Budget) plus a residence time for the TSN translator.

22. A non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a network node, configure the network node to implement a method according to any one of claims 17 to 21 .

23. A network node, comprising: a network interface configured to communicate with other network nodes;PDCAI (Packet Delay Correction Assistance Information) generation circuitry configured to: determine PDCAI comprising (i) periodicity information and (ii) maximum delay already set for packet data; and send, over the network interface, the PDCAI to a TSN translator using a PMIC (Port Management Information Container).

24. The network node of claim 23, wherein the PDCAI generation circuitry is further configured to implement a method according to any one of claims 18 to 21.

Images