WO2020141101A2

WO2020141101A2 - Ultra-reliable synchronized flow scheduling

Info

Publication number: WO2020141101A2
Application number: PCT/EP2019/086575
Authority: WO
Inventors: Jonathan Ling; Saeed Reza KHOSRAVIRAD; Ilija Hadzic
Original assignee: Nokia Technologies Oy
Priority date: 2019-01-04
Filing date: 2019-12-20
Publication date: 2020-07-09
Also published as: WO2020141101A3

Abstract

According to an embodiment, there is a method that comprises matching, by the network entity, data traffic flow. The method further includes merging, by the network entity, at least one flow schedule with an existing scheduled synchronization flow. The method further includes adjusting, by the network entity, at least one MCS to accommodate a minimum of at least one or all flow target PERs for TTI.

Description

TITLE:

ULTRA-RELIABLE SYNCHRONIZED FLOW SCHEDULING

BACKGROUND:

Field:

[0001] Various communication systems may benefit from scheduling support for isochronous URLLC traffic.

Description of the Related Art:

[0002] Sensors and video cameras are examples of traffic sources that produce data bursts isochronously. To minimize latency, a network may be synchronized to the device schedule. One problem is that the wireless network handles uplink traffic on an“on-demand” basis. Thus, either an uplink grant may be obtained via a dynamic scheduling request, or the data is transmitted immediately on a contention basis. Semi-persistent scheduling (SPS) is a third type of scheduling, where the UE may be granted periodic uplink resources for a certain time. SPS is suitable for services such as VoIP which follow a periodic arrival pattern, and can be configured (or reconfigured) by an eNB RRC upon dedication of a bearer to VoIP. Therefore, SPS may address the need for efficiency during periodic traffic, as the SPS grant is signalled once, but does not address synchronicity nor reliability.

SUMMARY:

[0003] According to an embodiment, there is a method that comprises registering, by an application device, at least one flow for URLLC support with a network entity. The method further includes transferring, by the application device, data to the network entity. The method further includes receiving, by the application device, at least one indication of acceptance or rejection of a service request from the network entity. [0004] According to an embodiment, an apparatus can include at least one processor, and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to at least register at least one flow for URLLC support with a network entity. The at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to transfer data to the network entity. The at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to receive at least one indication of acceptance or rejection of a service request from the network entity.

[0005] In accordance with an embodiment, an apparatus can include means for registering at least one flow for URLLC support with a network entity. The apparatus may further include means for transferring data to the network entity. The apparatus may further include means for receiving at least one indication of acceptance or rejection of a service request from the network entity.

[0006] According to an embodiment, there is a method that comprises matching, by the network entity, data traffic flow. The method further includes merging, by the network entity, at least one flow schedule with an existing scheduled synchronization flow. The method further includes adjusting, by the network entity, at least one MCS to accommodate a minimum of at least one or all flow target PERs for and/or within a TTI.

[0007] According to an embodiment, an apparatus can include at least one processor, and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to at least match data traffic flow. The at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to merge at least one flow schedule with an existing scheduled synchronization flow. The at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to adjust at least one MCS to accommodate a minimum of at least one or all flow target PERs for and/or within a TTI.

[0008] In accordance with an embodiment, an apparatus can include means for matching data traffic flow. The apparatus may further include means for merging at least one flow schedule with an existing scheduled synchronization flow. The apparatus may further include means for adjusting at least one MCS to accommodate a minimum of at least one or all flow target PERs for and/or within a TTI.

[0009] A non-transitory computer readable medium can, in certain embodiments, be encoded with instructions that, when executed in hardware, perform a process. The process can include a method according to any of the steps performed by any of the above discussed apparatuses.

[0010] A computer program product can, according to certain embodiments, encode instructions for performing a process. The process can include a method according to any of the steps performed by any of the above discussed apparatuses.

BRIEF DESCRIPTION OF THE DRAWINGS:

[0011] For proper understanding of this disclosure, reference should be made to the accompanying drawings, wherein:

[0012] FIG. 1 illustrates an example of an URLLC application according to certain embodiments

[0013] FIG. 2 illustrates an example of a signal flow diagram according to certain embodiments.

[0014] FIG. 3 illustrates an example of a method performed by an application device according to certain embodiments.

[0015] FIG. 4 illustrates an example of a method performed by a network entity according to certain embodiments. [0016] FIG. 5 illustrates an example of procedure and delay reduction according to some embodiments.

[0017] FIG. 6 illustrates a table of a schedule for multiple flows describing three services according to some embodiments.

[0018] FIG. 7 illustrates how multiple flows may be selected according to some embodiments.

[0019] FIG. 8 illustrates synchronized scheduling and grant submission for reliable UL delivery within a hard deadline according to some embodiments.

[0020] FIG. 9 illustrates another example of a system according to certain embodiments.

DETAILED DESCRIPTION:

[0021] Certain embodiments may have various benefits and/or advantages. For example, certain embodiments provide procedure and delay reductions. Thus, certain embodiments are directed to improvements in computer-related technology, specifically, conserving network resources and reducing power consumption of network entities and/or user equipment located within the network.

[0022] Ultra-Reliable Synchronous Flow Scheduling (URSF-Sch) may provide a framework and network support of URLLC applications. URSF-Sch may consist of five inter-connected components. First, URSF-Sch may include an application interface via NEF, whereby applications may specify/modify flow characteristics, receive feedback on transmission, and/or receive up-coming grant size information so that the application may appropriately source code/pack. Second, URSF-Sch may include at least one programmable message de/packer, where high reliability may be associated with low over-the-air efficiency. To compensate and fit the essential data, overhead introduced into the packetization process and data common between sources may be removed. For example, this may be accomplished by application programmable packer/de-packer that can operate over all packets received, and reconstitute application specific timestamps, sequence numbers, identifiers, etc.

[0023] The URSF-Sch may also include auto parameterization of flow size & schedule. For example, the network may determine the interval, offset, and size from traffic measurements. This may relieve the burden of the application from completely specifying the flow, and its schedule, and may allow some flexibility without notifying the network. Furthermore, there may be no need for explicit clocking between the source & network.

[0024] Furthermore, the URSF-Sch may include flow reliability on a single radio bearer. In some embodiments, the eNB MAC scheduler may receive flow characteristics & auto-determined parameters. As a flow appears during certain TTI & bearers, the flow reliability target may be addressed by modifying the MCS or invoking other diversity techniques, such as PRB allocation, multi modem, and relaying. If efficiency of scheduling dissimilar flows on the same bearer and TTI is not acceptable, then they may be separated.

[0025] URSF-Sch may also include single transmission and truncation. For example, due to the variable RF & traffic conditions, allocated grant TBS may be less than the data waiting to be sent. Thus, the application may either wait for all of it (dynamic grant necessary on uplink), or allow truncation. Truncation may allow the network to maintain low latency by transmitting partial priority data since the application packed the data in priority order). The application may allow truncation receiving important date on time, and accept entire message later.

[0026] FIG. 1 illustrates an example of an URLLC application which may connect at least one sensor, video camera, and main control unit wirelessly to an automation controller. The area bounded by the dashed line depicts a new entity called a user-gateway (U-GW) residing between an IP routing layer and the modem. The U-GW may intercept the data plane traffic to estimate flow parameters, packet at least one message, and truncate the messages, if necessary. IP layer duplication may also be available for multi-path functionality. The U- GW may support an application which provides control functionality such as registration, notification, and size of upcoming grants to variable rate traffic sources. In some embodiments, registration of flows occur through the at least one of NEF, SMF, and AMF to configure the eNB and UE with a synchronization bearer (a new QoS bearer for URFFC traffic). Configuration information may be forwarded to the eNB scheduler, the U-GW, and/or functions on the UPF. The eNB scheduler may communicate time packet releases to the U-GW so that they may be transmitted in the desired TTI. Similar functionality may reside on the UPF. Data traffic flow may be also supported in both UF and DF directions, as indicated by the solid large arrows.

[0027] FIG. 2 illustrates an example of a signal flow diagram according to certain embodiments. A system may include at least one or more of at least one application device 220, such as application device 910 in FIG. 9, and network entity 230, such as network entity 920 in FIG. 9. As illustrated in step 201, application device 910 may register at least one traffic flow for URFFC support to network entity 230. In some embodiments, the at least one traffic flow may include one or more of at least one flow identification characteristic, such as source, destination, protocol, and/or DSCP; at least one nominal interval in uS; at least one size, such as last size and/or maximum size; at least one activity timeout, such as in seconds; at least one target PER; at least priority; at least one indication for allowance of truncation, such as true and/or false; and at least one failure notification, such as sender/receiver/both/none.

[0028] In step 203, network entity 230 may set up at least one synchronization bearer, if not aheady configured. In some embodiments, network entity 230 may set up at least one synchronization bearer by transmitting one or more of at least one configured resource and at least one selected parameter associated with operation of at least one synchronization bearer. Alternatively or additionally, application device 220 may use at least one parameter to setup at least one synchronization bearer, if required to support at least one new service and associated PER. In step 205, application device 220 may transmit data to network entity 230. In some embodiments, at least one network carrier may serve as a default radio bearer.

[0029] In step 207, network entity 230 may perform flow matching, and/or may determine flow frequency and alignment to at least one LTE TTI structure. In step 209, network entity 230 may merge at least one flow schedule with an existing sync scheduled flows. For example, network entity 230 may perform the merging on the current bearer. In step 211, network entity 230 may transmit at least one indication of acceptance or rejection of a service request to application device 220. In step 213, network entity 230 may perform traffic flow for at least one synchronization bearer.

[0030] In step 215, network entity 230 may adjust at least one MCS to accommodate a minimum of all flow target packet error rates (PERs) for transmission time interval (TTI). In certain embodiments, at least one PER may be associated with TTI size, TTI transmission, and/or TTI size. In some embodiments, where a variable-sized flow is set to a maximum, network entity 230 may communicate in advance of a grant size. Thus, application device 220 may source code, such as matching data sent with the capacity of network entity 230.

[0031] In some embodiments, network entity 230 may provide at least one uplink grant according to at least one frequency and/or at least one alignment of the traffic flow. If the at least one uplink grant is not large enough to accommodate all messages, the message may be packed according to at least one priority. Alternative or additionally, at least one message may be truncated, if possible. In the event of packet loss, the sender, receiver, or both may receive at least one notification.

[0032] In some embodiments, data generated by at least one source received at the U-GW after a threshold and/or missing a provided UL grant may either be dropped or scheduled dynamically. Furthermore, a notification may be provided to the sender. Payload size changes may be integrated into the schedule according to at least one selected policy. For example, at least one policy may use at least one last known burst size as a corrected size, while a second policy may attempt to give a maximum capacity of the flow, based upon at least one competing variable-sized flow.

[0033] FIG. 3 illustrates an example of a method performed by an application device, such as application device 910 in FIG. 9. In step 301, the application device may register at least one traffic flow for URLLC support to a network entity, such as network entity 920 in FIG. 9. In some embodiments, the at least one traffic flow may include one or more of at least one flow identification characteristic, such as source, destination, protocol, and/or DSCP; at least one nominal interval in uS; at least one size, such as last size and/or maximum size; at least one activity timeout, such as in seconds; at least one target PER; at least priority; at least one indication for allowance of truncation, such as true and/or false; and at least one failure notification, such as sender/receiver/both/none.

[0034] In step 303, the application device may transmit data to the network entity. In some embodiments, at least one network carrier may service as a default radio bearer. In step 305, the application device may receive at least one indication of acceptance or rejection of a service request from the network entity.

[0035] FIG. 4 illustrates an example of a method performed by a network entity, such as network entity 920 in FIG. 9. In step 401, the network entity may receive at least one flow registration associated with URLLC support from at least one application device, such as application device 910 in FIG. 9. In some embodiments, the at least one traffic flow may include one or more of at least one flow identification characteristic, such as source, destination, protocol, and/or DSCP; at least one nominal interval in uS; at least one size, such as last size and/or maximum size; at least one activity timeout, such as in seconds; at least one target PER; at least priority; at least one indication for allowance of truncation, such as true and/or false; and at least one failure notification, such as sender/receiver/both/none.

[0036] In step 403, the network entity may set up at least one synchronization bearer, if not already configured. In some embodiments, application device 220 may set up at least one synchronization bearer by transmitting one or more of at least one configured resource and at least one selected parameter associated with operation of at least one synchronization bearer. Alternatively or additionally, application device 220 may use at least one parameter to setup at least one synchronization bearer, if required to support at least one new service and associated PER. In step 405, the network entity may receive data from the application device. In some embodiments, at least one network carrier may service and/or serve as a default radio bearer.

[0037] In step 407, the network entity may perform flow matching. In step 409, the network entity may determine flow frequency and alignment to at least one LTE TTI structure. In step 411, the network entity may merge at least one flow schedule with an existing sync scheduled flows. For example, the network entity may perform the merging on the current bearer.

[0038] In step 413, the network entity may transmit at least one indication of acceptance or rejection of a service request to the application device. In step 415, the network entity may carry the traffic flow to at least one synchronization bearer, which may be dedicated to URLLC traffic. In some embodiments, traffic flow may include user data/network traffic on the sync bearer or traffic flow on sync bearer for sync signals. In step 417, the network entity may adjust at least one MCS to accommodate a minimum of all flow target PERs for TTI.

[0039] In some embodiments, where a variable-sized flow is set to a maximum, the network entity may communicate in advance of a grant size. Thus, application device 220 may source code, such as matching data sent with the capacity of the network entity. [0040] In some embodiments, the network entity may provide at least one uplink grant according to at least one frequency and/or at least one alignment of the traffic flow. If the at least one uplink grant is not large enough to accommodate all messages, the message may be packed according to at least one priority. Alternative or additionally, at least one message may be truncated, if possible. In the event of packet loss, the sender, receiver, or both may receive at least one notification about the packet loss and/or at least one truncated message.

[0041] In some embodiments, data generated by at least one source received at the U-GW after a threshold and/or missing a provided UL grant may either be dropped or scheduled dynamically. Furthermore, a notification may be provided to the sender. Payload size changes may be integrated into the schedule according to at least one selected policy. For example, at least one policy may use at least one last known burst size as a corrected size, while a second policy may attempt to give a maximum capacity of the flow, based upon at least one competing variable-sized flow.

[0042] FIG. 5 illustrates an example of procedure and delay reduction according to some embodiments. For example, FIG. 5 depicts three lines: (1) data bursts P_n arriving at the U-GW as shown by diamonds, (2) messages passing over the air between the UE and eNB, and (3) data exiting the EPC from the P-GW. 3 ms processing time at the UE, 1 ms transmission from UE to eNB, and 1 ms processing at the eNB is assumed. The scheduling interval, offset, and size are calculated after Pi arrives, and signaled to the eNB in message Co. A 22 ms delay may be incurred as Co is transmitted to the eNB over at least one regular data bearer with dynamic scheduling, which may be reduced through the use of RRC messaging. The eNB may send back an acknowledgement, and in message Ci for a configuration delay of 24 ms. Subsequent arrivals, such as P4 onward, may be directed to the synchronization bearer, and may incur a 5 ms one-way delay. This is the minimum possible delay associated with the processing delay and TTI assumptions. [0043] FIG. 6 illustrates a table of a schedule for multiple flows describing three services, while FIG. 7 illustrates how these multiple flows may be selected. The traffic interval values may be single, fixed, and/or arbitrary value, such as not needing not be related to network frame boundaries. Schedules may be merged on to the same radio bearer.

[0044] In some embodiments, the network may need to determine at least one interval, time offset, and jitter margin for each uplink or downlink flow. Data burst reception time may be modelled as isochronous signal plus“noise” and the least squares estimator used to determine the parameters from the packet arrivals. Data burst reception time may be modelled as isochronous signal plus “noise” according to:

r„ = t₀ + (n - 1)5 + t_h

, where t_h is exponentially distributed with mean l/l. Since the“noise” is not white Gaussian, a least squares estimation may produce a bias. The RMS error of the offset may be calculated according to:

, where N is the number of samples. The error may be an approximate mean of the exponential noise process. The schedule from the estimated parameters may be calculated as:

S_n = \t'f + F-¹ (.99) + (n - 1)5“]

, where sample empirical distribution P is obtained from the random variables:

The mean square error £(15 - 5“|²) decrease in relation to 1/N³, which may be slower than the maximum likelihood estimator which decreases as 1/M. Recursive least squares may be used which may have improved good convergence properties.

[0045] FIG. 8 illustrates synchronized scheduling and grant submission for reliable UL delivery within a hard deadline, in particular, an uplink scheduling for two UEs: one close to the eNB, and other requiring relaying. In some embodiments, ultra-reliability may be triggered at different layers, where multi connectivity at PDCP layer, radio bearer split, such as duplication at PDCP, in case of CA, RLC layer ARQ, MAC layer HARQ, and proper MCS selection at scheduling are among the possible arrangements for enhanced reliability. URSF-SCH may enhance reliability of delay-sensitive data by propagating the target PER for triggering proper MCS selection. The timing and resources for UL scheduling may then be chosen for all physical channels in case of NR multi connectivity or CA to match the required PER.

[0046] Ultra-reliable communication with hard-deadlines, such as two-hop relaying may also benefit from the propagated PER to identify weak users among a plurality of devices which require two-hop relaying for guaranteed level of reliability. The propagated PER may be picked up at the scheduling to identify those weak nodes and trigger two-hop relaying in the UL for them.

[0047] In some embodiments, the network may deliver messages in a single transmission, which may be prevented due to RF conditions and loading by other users. In such cases, grant size may be less than the message resulting in an additional delay due to segmentation and transmission in a subsequent attempt. One solution with application layer support is for the application pack to the data burst in priority order from the front. The truncator may receive the grant size, and may generate a message that will fit. The message header may indicate that it is truncated. The remainder of the message may be scheduled later, reconstituted, and delivered late. In addition, truncation may be indicated in a header field and/or header option of a transport layer message, such as in an IP option header. Separate notifications may be sent to the application, and to an OAM entity that tracks performance.

[0048] FIG. 9 illustrates an example of a system according to certain embodiments. In one embodiment, a system may include multiple devices, such as, for example, application device 910 and network entity 920.

[0049] Application device 910 may include one or more of a mobile device, such as a mobile phone, smart phone, personal digital assistant (PDA), tablet, or portable media player, digital camera, pocket video camera, video game console, navigation unit, such as a global positioning system (GPS) device, desktop or laptop computer, single-location device, such as a sensor or smart meter, or any combination thereof.

[0050] Network entity 920 may be one or more of a base station, such as an evolved node B (eNB) or next generation node B (gNB), a next generation radio access network (NG RAN), a serving gateway, a server, and/or any other access node or combination thereof

[0051] In some embodiments, application device 910 and network entity 920 may be a part of a relay node. Multiple relays may be chained together to form a multi-hop-relay network in a relay deployment. Furthermore, a citizens broadband radio service (CBRS) device (CBSD) may include one or more serving cells, such as application device 910 and network entity 920.

[0052] One or more of these devices may include at least one processor, respectively indicated as 911 and 921. At least one memory may be provided in one or more of devices indicated at 912 and 922. The memory may be fixed or removable. The memory may include computer program instructions or computer code contained therein. Processors 911 and 921 and memory 912 and 922 or a subset thereof, may be configured to provide means corresponding to the various blocks of FIGS. 1-8. Although not shown, the devices may also include positioning hardware, such as global positioning system (GPS) or micro electrical mechanical system (MEMS) hardware, which may be used to determine a location of the device. Other sensors are also permitted and may be included to determine location, elevation, orientation, and so forth, such as barometers, compasses, and the like.

[0053] As shown in FIG. 9, transceivers 913 and 923 may be provided, and one or more devices may also include at least one antenna, respectively illustrated as 914 and 924. The device may have many antennas, such as an array of antennas configured for multiple input multiple output (MIMO) communications, or multiple antennas for multiple radio access technologies. Other configurations of these devices, for example, may be provided.

[0054] Transceivers 913 and 923 may be a transmitter, a receiver, or both a transmitter and a receiver, or a unit or device that may be configured both for transmission and reception.

[0055] Processors 911 and 921 may be embodied by any computational or data processing device, such as a central processing unit (CPU), application specific integrated circuit (ASIC), or comparable device. The processors may be implemented as a single controller, or a plurality of controllers or processors.

[0056] Memory 912 and 922 may independently be any suitable storage device, such as a non-transitory computer-readable medium. A hard disk drive (HDD), random access memory (RAM), flash memory, or other suitable memory may be used. The memories may be combined on a single integrated circuit as the processor, or may be separate from the one or more processors. Furthermore, the computer program instructions stored in the memory and which may be processed by the processors may be any suitable form of computer program code, for example, a compiled or interpreted computer program written in any suitable programming language. Memory may be removable or non-removable.

[0057] The memory and the computer program instructions may be configured, with the processor for the particular device, to cause a hardware apparatus such as user equipment to perform any of the processes described below (see, for example, FIGS. 1-8). Therefore, in certain embodiments, a non-transitory computer-readable medium may be encoded with computer instructions that, when executed in hardware, perform a process such as one of the processes described herein. Alternatively, certain embodiments may be performed entirely in hardware.

[0058] In certain embodiments, an apparatus may include circuitry configured to perform any of the processes or functions illustrated in FIGS. 1-8. For example, circuitry may be hardware-only circuit implementations, such as analog and/or digital circuitry. In another example, circuitry may be a combination of hardware circuits and software, such as a combination of analog and/or digital hardware circuit(s) with software or firmware, and/or any portions of hardware processor(s) with software (including digital signal processor(s)), software, and at least one memory that work together to cause an apparatus to perform various processes or functions. In yet another example, circuitry may be hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that include software, such as firmware for operation. Software in circuitry may not be present when it is not needed for the operation of the hardware.

[0059] The features, structures, or characteristics of certain embodiments described throughout this specification maybe combined in any suitable manner in one or more embodiments. For example, the usage of the phrases“certain embodiments,”“some embodiments,”“other embodiments,” or other similar language, throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present invention. Thus, appearance of the phrases“in certain embodiments,”“in some embodiments,”“in other embodiments,” or other similar language, throughout this specification does not necessarily refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0060] One having ordinary skill in the art will readily understand that certain embodiments discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention. In order to determine the metes and bounds of the invention, therefore, reference should be made to the appended claims.

[0061] Partial Glossary

[0062] 3 GPP 3rd Generation Partnership Project

[0063] AMF Authentication Management Field

[0064] ARQ Automatic Repeat Request

[0065] CA Carrier Aggregation

[0066] CU Centralized Unit

[0067] DU Distributed Unit

[0068] eNB Evolved Node B

[0069] EPC Evolved Packet Core

[0070] gNB Next Generation eNB

[0071] GNSS Global Navigation Satellite Systems

[0072] GPS Global Positioning System

[0073] GSMA Global System for Mobile Communications Association [0074] HARQ Hybrid Automatic Repeat Request

[0075] IP Internet Protocol

[0076] LTE Long-Term Evolution

[0077] MAC Medium Access Control

[0078] MCS Modulation Coding Scheme

[0079] MME Mobility Management Entity

[0080] MTC Machine-Type Communications

[0081] NEF Network Exposure Function

[0082] NR New Radio

[0083] OTT Over-the-Top Communications

[0084] OAM Operation, Administration, and Management

[0085] PER Packet Error Rate

[0086] PDCP Packet Data Convergence Protocol [0087] PRB Physical Resource Block

[0088] QoS Quality of Service

[0089] RAN Radio Access Network

[0090] RLC Radio Link Control

[0091] SMF Session Management Function

[0092] TBS Transport Block

[0093] TTI Transmission Time Interval

[0094] UE User Equipment

[0095] U-GW User-Gateway

[0096] UPF User Plane Function

[0097] URLLC Ultra-Reliable Low-Latency Communication [0098] URSF-Sch Ultra-Reliable Synchronous Flow Scheduling [0099] uS Microseconds

Claims

WE CLAIM:

1. A method, comprising:

registering, by an application device, at least one flow for URLLC support with a network entity;

transferring, by the application device, data to the network entity; and receiving, by the application device, at least one indication of acceptance or rejection of a service request from the network entity.

2. A method, comprising:

matching, by the network entity, data traffic flow;

merging, by the network entity, at least one flow schedule with an existing scheduled synchronization flow; and

adjusting, by the network entity, at least one MCS to accommodate a minimum of at least one or all flow target packet error rates for and/or within a TTI.

3. The method according to claim 2, further comprising:

receiving, by the network entity, at least one flow registration associated with URLLC support from at least one application.

4. The method according to any of claims 2 and 3, further comprising: transmitting, by the network entity, one or more of at least one configured resource and at least one selected parameter associated with operation of at least one synchronization bearer to the at least one synchronization bearer.

5. The method according to any of claims 2-4, further comprising: receiving, by the UE, at least one first level synchronization message from the serving network node.

6. The method according to any of claims 2-5, further comprising: receiving, by the network entity, at least one transfer of data from the at least one application.

7. The method according to any of claims 2-6, further comprising: determining, by the network entity, flow frequency and alignment to

LTE TTI structure.

8. The method according to any of claims 2-7, further comprising: transmitting, by the network entity, at least one indication of acceptance or rejection of a service request to application.

9. The method according to any of claims 2-8, further comprising: carrying, by the network entity, network traffic associated with a synchronization bearer.

10. An apparatus, comprising:

at least one processor; and

at least one memory including computer program code,

wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to at least perform a process, the process comprising the method any of claims 1-9.

11. A non-transitory computer-readable medium encoding instructions that, when executed in hardware, perform a process according to any of claims 1-9.

12. An apparatus comprising means for performing a process according to any of claims 1-9.

13. A computer program product encoding instructions for performing a process according to any of claims 1-9.

14. A computer program product embodied in a non-transitory computer-readable medium and encoding instructions that, when executed in hardware, perform a process, the process according to claim 1-9.

15. An apparatus comprising circuitry configured to perform any of the processes or functions according to any of claims 1-9.