Patent Application
20210235399
Some example embodiments may generally relate to mobile or wireless telecommunication systems, such as Long Term Evolution (LTE) or fifth generation (5G) radio access technology or new radio (NR) access technology, or other communications systems. For example, certain embodiments may relate to time sensitive communication (TSC).
Examples of mobile or wireless telecommunication systems may include the Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), Long Term Evolution (LTE) Evolved UTRAN (E-UTRAN), LTE-Advanced (LTE-A), MulteFire, LTE-A Pro, and/or fifth generation (5G) radio access technology or new radio (NR) access technology. 5G wireless systems refer to the next generation (NG) of radio systems and network architecture. A 5G system is mostly built on a 5G new radio (NR), but a 5G (or NG) network can also build on the E-UTRA radio. It is estimated that NR provides bitrates on the order of 10-20 Gbit/s or higher, and can support at least service categories such as enhanced mobile broadband (eMBB) and ultra-reliable low-latency-communication (URLLC) as well as massive machine type communication (mMTC). NR is expected to deliver extreme broadband and ultra-robust, low latency connectivity and massive networking to support the Internet of Things (IoT). With IoT and machine-to-machine (M2M) communication becoming more widespread, there will be a growing need for networks that meet the needs of lower power, low data rate, and long battery life. The next generation radio access network (NG-RAN) represents the RAN for 5G, which can provide both NR and LTE (and LTE-Advanced) radio accesses. It is noted that, in 5G, the nodes that can provide radio access functionality to a user equipment (i.e., similar to the Node B, NB, in UTRAN or the evolved NB, eNB, in LTE) may be named next-generation NB (gNB) when built on NR radio and may be named next-generation eNB (NG-eNB) when built on E-UTRA radio.
For proper understanding of example embodiments, reference should be made to the accompanying drawings, wherein:
According some aspects, there is provided the subject matter of the independent claims. Some further aspects are defined in the dependent claims. The embodiments that do not fall under the scope of the claims are to be interpreted as examples useful for understanding the disclosure.
In a first aspect thereof the exemplary embodiments of this invention provide an apparatus that comprises at least one memory comprising computer program code; at least one processor; wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus at least to monitor packet delivery status for at least one time sensitive network application in a system using at least one of survival time state information, time sensitive communication assistance information, and a quality of service profile; and select link layer configurations based on at least one of the survival time state information, the time sensitive communication assistance information, and the quality of service profile.
In a further aspect thereof the exemplary embodiments of this invention provide an apparatus in the first aspect, wherein the at least one memory and the computer program code are further configured, with the at least one processor, cause the apparatus at least to receive a message from a source network node initiating handover of a user equipment wherein the message comprises the survival time state information; and determine, based at least on the survival time state information, a required link layer configuration so that the survival time is not exceeded.
In another aspect thereof the exemplary embodiments of this invention provide an apparatus that comprises at least one memory comprising computer program code; at least one processor; wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus at least to receive a reconfiguration message from a serving network node to trigger handover to a target network node; switch to a new cell of the target network node; and transmit a reconfiguration complete message to the target network node wherein the message comprises a survival time state information for packet delivery status of at least one of sent uplink packets or received downlink packets.
It will be readily understood that the components of certain example embodiments, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of some example embodiments of systems, methods, apparatuses, and computer program products for survival time monitoring and status transfer for TSC, is not intended to limit the scope of certain embodiments but is representative of selected example embodiments.
The features, structures, or characteristics of example embodiments described throughout this specification may be combined in any suitable manner in one or more example embodiments. For example, the usage of the phrases “certain embodiments,” “some embodiments,” or other similar language, throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment. Thus, appearances of the phrases “in certain embodiments,” “in some embodiments,” “in other embodiments,” or other similar language, throughout this specification do not necessarily all 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 example embodiments.
Additionally, if desired, the different functions or procedures discussed below may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the described functions or procedures may be optional or may be combined. As such, the following description should be considered as illustrative of the principles and teachings of certain example embodiments, and not in limitation thereof.
Industrial communication, such as time sensitive communication (TSC), is one of the new services supported in 3GPP Release 16 for 5G. TSC is a communication service that supports deterministic communication and/or isochronous communication with high reliability and availability. TSC is capable of providing packet transport with quality of service (QoS) characteristics, such as bounds on latency, loss, and reliability, in which end systems and relay/transmit nodes can be strictly synchronized. The 5G system has been extended in 3GPP Release-16 to support TSC.
Some relevant terminology relating to TSC includes: communication service availability (CSA), end-to-end latency, survival time, transfer interval, and update time. CSA refers to the ability of the communication service to perform as required for a given time interval, under given conditions. end-to-end latency is the time to transfer a given piece of information from a source to a destination, measured at the communication interface, from the moment it is transmitted by the source to the moment it is successfully received at the destination. Survival time refers to the time that an application consuming a communication service may continue without an anticipated message. Transfer interval is the time difference between two consecutive transfers of application data from an application via the service interface to 3GPP system. Update time indicates the time interval between any two consecutive messages delivered from the egress (of the communication system) to the application.
Certain embodiments described herein can improve TSC for a service where a survival time is given. Knowledge of the survival time of the application increases the CSA because one or more failed message deliveries within the survival time interval are not considered an unavailability. In some embodiments, survival time may be leveraged to improve the spectral efficiency of the deterministic 5G System (5GS) (e.g., for industrial or non-public use cases) to avoid the situation where the 5GS needs to over-provision the packet error rate (PER) targets by assuming that each application has survival time equal to zero, which may result in a significant reduction in system capacity and/or reduction in the communication service reliability.
As one example, when CSA=1−1e-8, and survival time is greater than 0 and known in the 5G system, the 5G system could use a target PER of=1e-3 most of the time, and only if packet errors are detected adjust to PER=1e-8 to avert a failure. In other words, according to this example, the 5G system could use PER=1e-3 for ˜99.9% of the time, and PER=1e-8 for ˜0.1% of the time. Currently, no mechanisms are specified for how to leverage survival time in RAN and how to monitor packet success status to dynamically select link layer configurations. Table 5.2-1 of 3GPP Technical Specification (TS) 22.104 provides some typical values for the survival time.
Survival time is specified in several uses cases for periodic deterministic communication in 3GPP specifications, but there is currently no solution specified for how the 5GS can make use of the survival time. Certain embodiments are able to address at least this issue.
In some use cases that demand deterministic communication with high reliability, it may be permissible to lose a single or a few consecutive messages without endangering the application. This is captured, as introduced above, by the concept of survival time as the time that an application consuming a communication service may continue without an anticipated message.
For example, if a message is anticipated to be received with a periodicity of Tp at a defined latest point in time, a survival time of Ts would allow for a maximum permissible consecutive loss of m messages according to: m=└Ts/Tp┘, with └x┘ denoting the rounding to the greatest integer less than or equal to x, and thus Ts>=m*Tp for the application service to stay available. More than m consecutive losses and the application will consider a communication system unavailability and change into a failsafe state (e.g., a robot moving in safe position and stopping).
A message in the application sense may be an application message, which could be a single Ethernet frame and therefore a QoS flow packet of the Ethernet protocol data unit (PDU) session in the 5GS. In many TSN use cases, message size is small and messages are mapped into one packet data convergence protocol (PDCP) or medium access control (MAC) PDU. However, there may also be cases where messages are segmented into multiple MAC PDUs. For the sake of simplicity, this description may describe mainly the former case, but should be considered to be applicable to both cases.
Some problems to be solved in this scenario may include to leverage survival time in RAN for a relaxation of the QoS requirement. In certain embodiments, this may include monitoring of packet delivery status and dynamically adapting the link layer configuration per packet to avoid that the time interval between successful message deliveries exceeds the survival time. This monitoring of packet delivery may be carried out within the serving radio cell. According to some embodiments, since the application is not aware of a UE movement, the above procedure should be extended in case of a handover, i.e., when UEs are switching between NG-RAN cells or nodes. In this case, the handover-target NG-RAN node may be made aware of the packet delivery status.
Time sensitive services were introduced in 3GPP Release-16 with basic support for IEEE TSN or other deterministic applications. With time sensitive communication assistance information (TSCAI), a set of parameters complementary to 5G QoS indicators (5QI) of the QoS model was introduced to describe periodic, deterministic traffic (i.e., PDU transport). TSCAI defines the arrival time of a time critical packet on the 5GS ingress and thus the packet delay budget (PDB) of the respective 5QI QoS profile yields the scheduled time the packet must leave 5GS egress (e.g., in DL UE to application interface and, respectively, in UL user plane function (UPF) to DN interface). TSCAI may be provided from session management function (SMF) to 5G access network (5G-AN), e.g., upon QoS flow establishment. The TSCAI parameters may be set according to corresponding parameters obtained from the application function. Table 1 below illustrates an example of TSCAI.
TSC QoS flows use a delay critical guaranteed bit rate (GBR) resource type, standardized 5QIs and TSCAI. Within each period (defined by periodicity), TSC QoS flows may transmit one burst of maximum size maximum data burst volume (MDBV) within the AN-PDB. Known QoS flow traffic characteristics provided in the TSCAI may be used to optimize scheduling in the 5GS.
The PDB may be explicitly divided into 5G-AN PDB and core network (CN) PDB. The 5G-AN PDB is the packet delay budget applicable to the radio interface, including AN processing. The CN PDB is the delay between a UPF terminating N6 and a 5G-AN. Separate delay budgets may be needed for calculation of expected packet transmit times on 5GS interfaces.
According to certain embodiments, with the assumption that the survival time itself will be available in the 5GS as a QoS parameter (e.g., in the TSCAI), 5GS can dynamically monitor the status of packet delivery with respect to a survival time window since one or more unsuccessful message deliveries. One embodiment may be configured to monitor the failure to deliver packets within the PDB and to define for this a new QoS flow context information. This stateful context information may be applied, for example, to select the link layer parameters for the transmission following a failure. In an embodiment, the state may be maintained close to the air interface, e.g., in the UE or in the gNB (depending on UL and DL direction of packets). Further example embodiments may be configured to handle mobility, which should be transparent to the application. Thus, when a handover occurs, this state information may be transferred to the target gNB.
Therefore, certain embodiments may introduce survival time state (STS) information, e.g., as a PDU session/QoS flow functionality, may leverage the STS in the AN for QoS enhancement, and may introduce STS in the handover context (among QoS Context).
In certain embodiments, the survival time, together with the TSCAI information as described above and the QoS profile (e.g., the PDB value), can be used to characterize and monitor the communication service availability on application level in the 5GS, such as in 5G-RAN nodes. Within a PDU session, QoS flows may be used to transport the PDUs with a given QoS, as specified in the QoS profile of the flow. QoS flows may be identified by QoS flow identifiers (QFI). The QFI may be used to link QoS profile and additional information on the QoS flow, and thus the survival time may also be associated to a QoS flow. The QoS profile for a QFI may also be provided by the SMF via access and mobility management function (AMF) to NG-RAN nodes over the N2 interface, for example.
The QoS flow characteristics (e.g., as defined by 5QI, TSCAI and survival time) describe the QoS flow treatment on the PDU session between UPF and UE. The QoS flow characteristics may be understood as guidelines to set node specific behaviour, e.g., link layer configurations. For TSC traffic, the QoS performance of the 5GS is expected to be strictly monitored and met. Very low packet error rates, as expected by TSN applications, may require robust transmission with low code rate and/or duplications, and therefore a limited spectral efficiency. The survival time concept allows to reduce the effort for most of the messages and to provide better service to critical messages. This increases the system capacity (e.g., the number of served sensors and actors) and reduces the spectrum requirement and system cost. In order to leverage the survival time in this way, the packet losses and their timing relations are of interest. A limited number of messages may be lost as long as at least one message was successfully delivered. This implies that, within a time window equal to the survival time, each lost message increases the urgency of successful delivery of the next message. After m losses the next message must not be lost. Thus, according to certain embodiments, 5GS/NG-RAN can monitor losses to introduce a dynamic state change for the targeted message delivery reliability. This dynamic state context information may be introduced or provided to the 5GS/NG-RAN nodes. It is noted that the distribution of the 5GS internal system clock as well as a gPTP based clock (e.g., application domain clock, TSN clock) and their relation has been introduced into the 5GS in Release-16 to enable synchronized time relations.
According to certain embodiments, the survival time requirement of industrial control applications may be provided as a time interval. Given the message periodicity, the survival time can be translated into the form of a count of messages or traffic periods, as described in terms of TSC deterministic traffic TSCAI parameters. For example, where a message is anticipated to be received with a periodicity of Tp (e.g., as shown in Table 1) at a defined latest point in time, a survival time of Ts would allow for a maximum permissible consecutive loss of m messages according to: m=└Ts/Tp┘, with └x┘ denoting the rounding to the greatest integer less than or equal to x, and thus Ts>=m*Tp.
In some embodiments, a survival timer, Ts,timer, may define a countdown timer that is set to the survival time triggered by a message loss and defines the maximum window to successfully deliver a message of the periodic message sequence before the communication service is deemed unavailable. After such successful delivery, the survival timer may be stopped. If the survival timer reaches zero, the communication service is considered unavailable.
According to certain embodiments, the survival time can be related to the transmission time of the messages in the NG-RAN (e.g., on PDCP layer) or the time the message is supposed to have left the 5GS egress (e.g., DS-TT to application). In an embodiment, after receiving a negative acknowledgement (NACK) for a message, the survival timer may be set to the survival time corrected for the time between the expected delivery at the UE egress (DS-TT) or RAN ingress (NW-TT) and the time the survival timer is started according to the following: TPDCPtimedelta=Starting time of Survival Timer−Expected Arrival Time of the Lost Packet. Thus, the survival timer may be set to: Ts,timer, PDCP=Ts−TPDCPtimedelta. Alternatively, the survival time for a transmission may be expressed (triggered with a packet loss indication to, e.g., PDCP) as an absolute point in time for latest delivery of the next message as the survival time end: Ts,end=Expected Arrival Time of the Lost Packet+Ts.
In an embodiment, the “expected arrival time of lost packet” for the given period can be calculated from the TSCAI and the feedback from lower layers to the PDCP on the (un)successful delivery of the packet. If the delivery of another packet of this TSC QoS Flow is later than the survival timer end, the service is considered unavailable. The benefit of an absolute time value is that a possible time delay in a handover does not have to be explicitly considered, since the nodes (e.g., NG-RAN nodes) are time synchronized to an absolute global time for the TSC deterministic traffic. Alternatively or additionally, the number of consecutive lost packets may be counted for TSC periodic traffic. According to certain embodiments, the survival time state can be expressed in different ways, e.g., by an up- or down-counter. For example, a survival time state up-counter=consecutive packet loss count, and/or a survival time state down-counter=m−consecutive packet loss count. In the latter example, a survival time state of 0 may indicate the last possible chance to deliver a packet without exceeding the application's survival time. This may also hold for applications without survival capability (Ts=0). In this example, when the survival time has been exceeded, the survival time state becomes negative.
Alternatively or additionally, in an embodiment, the state can be expressed as a fraction or percentage of the maximum tolerable packet loss counter. For example, where survival time state %=100%*consecutive packet loss count/(m−1) with m=└Ts/Tp┘. For services without survival time, m=0 and the survival time state may always be set to 100%.
In this version of the survival time state, the state is zero if the previous packet was successfully received. In an embodiment, this state information may be increased for every PDCP packet that is expected for the periodic TSC traffic but is signaled as error (because of late delivery or data error) to PDCP. The state of 100% indicates that m-1 successive packets have been lost and the next packet may be sent with the lowest possible PER, because there is no further chance to deliver a packet without exceeding the application's survival time. In this example, if the state is larger than 100%, the service is unavailable. It should be noted that, according to certain embodiments, there are other possibilities to express the state. For example, the percentage scale can be inverted, i.e., such that best availability may be expressed as state information 1 or 100% and unavailability as 0 or 0% for example as follows: Survival Time State %=100%*(m−Consecutive Packet Loss Count)/m.
For some applications, such as audio/visual data, a packet loss within the survival time does not break the application, but nevertheless may impact the user experience. In such applications, a minimum time between packet losses may be used. For this, in certain embodiments, information on “last survival time packet” can be included. This may again be expressed in a time value based on the periodicity value, or a number of periods.
According to certain embodiments, survival time state information, such as the survival timer, survival time end or survival time state counters, can be used when delivering packets from UPF to gNB and/or within RAN to lower layers to express a level of urgency. This survival time state information may be used in PDCP layer to invoke PDCP duplication or multi-connectivity and passed through the stack, preferably to the radio resource management (RRM) and scheduler to select the modulation and coding scheme (MCS). In an embodiment, to carry the information, new information elements may be provided at the interfaces and state machines, e.g., in the UPF or PDCP layer.
Typically, the QoS performance would be monitored by the policy control function (PCF), with information delivered from SMF, AMF and/or UPF. However, for time critical, deterministic traffic, the monitoring should likely occur closer to the radio stack, e.g., in the gNB.
In an embodiment, the acknowledgement of the PDCP message may include information about meeting of the PDB (e.g., NACK if the AN-PDB had not been achieved). As a result, on PDCP layer, the applications requirements become visible.
As introduced above, it has not yet been specified in 3GPP how to monitor the survival state and how to adapt the link configuration to it. Furthermore, UE mobility introduces an additional problem in which, during handover, undelivered messages or PDCP packets may be forwarded from the source gNB buffer to the target gNB. However, currently, there is no transfer of the time of last successful packet delivery or survival state information. Therefore, after a handover, the RAN may lose the state information if the information is stored in the gNB. Certain embodiments may address this issue by providing for survival time state information transfer on handover.
For example, in an embodiment, at least the target gNB may be informed by a new information element about the remaining time for the next successful transmission in terms of survival time end or a survival time state counter. The format of the information transfer may depend on the synchronization of the base stations (e.g., gNBs) and the scheduling scheme.
In one embodiment, for a fully synchronized system, the survival time end may contain the full information together with the 5QI QoS and TSCAI. The target gNB may then deduce the urgency and required link layer configuration so that survival time is not exceeded. According to an embodiment, in case of semi-persistent scheduling (SPS), the survival time end can be used to select a slot that is suited to maintain the PDB and receive the messages exactly at the expected deterministic timing (or shortly before when using the hold-and-forward-buffer).
In a further embodiment, if the gNBs are not synchronized, it may not be meaningful to forward a survival time end. Nevertheless, the survival time state may provide an indication of the level of urgency and thus for the configuration of the link layer.
When a handover latency occurs, this may hinder the target gNB from transmitting at the next due transmission time, creating additional packet loss to the application. In an embodiment, this latency may be added on top of the transferred survival time state counter.
According to some embodiments, for UL flows, the survival time state information may be maintained or stored in the UE. Nevertheless, the information may be transferred to the target gNB because the UE may need transmission grants and the timing requirement and the MCS of the grants may depend on the survival time state or survival time end.
According to certain embodiments, in case of a handover between NG-RAN nodes, QoS context may also be transferred from the serving gNB to the target network node (e.g., gNB or eNB). To this QoS context, in an embodiment, the above-mentioned dynamic state information on survival time may be added, e.g., in order to support deterministic traffic and allow for dynamic adaptation. According to an embodiment, this information may be added as one or more information element(s) within the HANDOVER REQUEST message in the handover procedure (e.g., via Xn or NG). It is noted that, additionally in an embodiment, the TSCAI information may be transferred between the gNBs in case of handover.
Furthermore, the IE included in the HANDOVER REQUEST may also contain the additional survival time state information for the respective TSC QoS flow. Additionally, in an embodiment, the IE may also include the TSCAI, which may also be transferred in the HANDOVER REQUEST message and thus added to it. Table 2 below illustrates an example of the GBR QoS flow information with added TSCAI & survival time state information, according to one example embodiment.
In UL direction, the survival time end or survival time status counters may not be available in the source gNB, but rather in the UE. In this case, according to an embodiment, the information may be transferred to the target gNB, at 4, in the RRC Reconfiguration Complete Message.
In one embodiment, a time critical handover clause may be included within the HANDOVER REQUEST message, e.g., as shown in Table 3 below. According to an embodiment, a new cause value of “Time Sensitive Communication Handover” may also be included in the HANDOVER REQUEST message indicating a request for a dedicated scheduling of the next message or for the forwarded PDCP packet within a dedicated time limit.
It is noted that, while some embodiments described herein may assume periodic messages that are delivered by a single PDCP packet, example embodiments may be applied to larger messages that are fragmented into several PDCP packets. However, in this case, the counters may need to consider receiving status of all PDCP packets of a message for changing the survival time interval, end or state. Furthermore, in certain embodiments, monitoring of packet delivery status may be taken at a different level in the RAN stack, e.g., at UPF, SDAP, MAC, etc.
As illustrated in the example of
In one embodiment, the QoS profile of a QoS flow may specify the QoS that should be used to transport the PDUs within a PDU session. QoS flows may be identified by a QFI that can be used to link a QoS profile with additional information on the QoS flow. In an embodiment, the survival time may also be associated with a QoS flow. According to some embodiments, the method may include receiving the QoS profile for a QFI from a SMF via an AMF over the N2 interface, for example.
In an embodiment, the method of
As introduced above, for TSC traffic, the QoS performance of the 5GS may need to be strictly monitored and met. Low packet error rates, such as that needed by TSN applications, may require robust transmission with low code rate and/or duplications, and therefore a limited spectral efficiency. The use of survival time allows for a reduction in effort for most of the packets and may provide better service to critical packets or messages. Therefore, in an embodiment, the monitoring 600 may include monitoring the packet losses over a certain time window. Since a limited number of packets may be lost as long as at least one packet was successfully delivered, within a time window equal to the survival time, each lost message increases the urgency of successful delivery of the next message. After m packet losses the next packet should be successfully received. It is noted that synchronized time relations between nodes in the 5GS may be enabled by the distribution of the 5GS internal system clock and/or a gPTP based clock and their relation.
As mentioned above, in some embodiments, the STS information may include a survival time, survival timer, survival time end, and/or survival time state counters, for example. According to certain embodiments, given the packet periodicity, the monitoring 600 may include translating a survival time into the form of a count of packets or traffic periods, as described in terms of TSC deterministic traffic TSCAI parameters. For example, where a message is anticipated to be received with a periodicity of Tp (e.g., as shown in Table 1) at a defined latest point in time, a survival time of Ts would allow for a maximum permissible consecutive loss of m messages according to: m=└Ts/Tp┘, with └x┘ denoting the rounding to the greatest integer less than or equal to x, and therefore the survival time may be: Ts>=m*Tp.
In some embodiments, a survival timer, Ts,timer, may define a countdown timer that is set to the survival time triggered by a message loss. According to an embodiment, the survival timer may define the maximum window to successfully deliver a packet of the periodic message sequence before the communication service is considered unavailable. In other words, the window for successfully delivering a packet is during the time that the survival timer is running. After such successful delivery of a packet, the survival timer may be stopped. If the survival timer reaches zero, then the communication service is considered unavailable. Therefore, according to an embodiment, the monitoring 600 may include starting a survival timer, stopping the survival timer when a packet is successfully delivered or considering the communication service as unavailable when the survival timer reaches zero.
According to certain embodiments, the survival time may be related to the transmission time of the packets in the NG-RAN (e.g., on PDCP layer) or the time the packet is supposed to have left the 5GS egress (e.g., DS-TT to an application). In an embodiment, after receiving a negative acknowledgement (NACK) for a packet, the method may include setting the survival timer to the survival time corrected for the time between the expected delivery at the UE egress (DS-TT) or RAN ingress (NW-TT) and setting the time that the survival timer is started according to the following: TPDCPtimedelta=Starting time of Survival Timer−Expected Arrival Time of the Lost Packet. Thus, the method may include setting the survival timer to: Ts,timer, PDCP=Ts−TPDCPtimedelta. In a further embodiment, the method may include expressing the survival time for a transmission (triggered with a packet loss indication to, e.g., PDCP) as an absolute point in time for latest delivery of the next message as the survival time end: Ts,end=Expected Arrival Time of the Lost Packet+Ts.
In an embodiment, the “expected arrival time of lost packet” for the given period can be calculated from the TSCAI and the feedback from lower layers to the PDCP on the (un)successful delivery of the packet. If the delivery of another packet of this TSC QoS flow is later than the survival timer end, the service is considered unavailable. Alternatively or additionally, the number of consecutive lost packets may be counted for TSC periodic traffic.
According to certain embodiments, a survival time state may be expressed, for example, as an up-counter or down-counter. For instance, a survival time state up-counter=consecutive packet loss count, and/or a survival time state down-counter=m−consecutive packet loss count. In the latter example, a survival time state of zero may indicate the last possible chance to deliver a packet without exceeding the application's survival time. Alternatively or additionally, in an embodiment, the survival time state may be expressed as a fraction or percentage of the maximum tolerable packet loss counter. For example, where survival time state %=100%*consecutive packet loss count/(m−1) with m=└Ts/Tp┘. For applications without survival time, m=0 and the survival time state may always be set to 100%. In this version of the survival time state, the state is zero if the previous packet was successfully received. In an embodiment, the method may include increasing the survival time state for every PDCP packet that is expected for periodic TSC traffic but is signaled as error (because of late delivery or data error) to PDCP. A state of 100% indicates that m-1 successive packets have been lost and the next packet may be sent with the lowest possible PER, because there is no further chance to deliver a packet without exceeding the application's survival time. In this example, if the state is larger than 100%, the service is considered unavailable.
In certain embodiments, a minimum time between packet losses may be used. For this, in certain embodiments, STS information may include information on “last survival time packet”. As an example, this may be expressed in a time value based on the periodicity value, or a number of periods.
According to some embodiments, the method may include using the STS information, such as the survival timer, survival time end or survival time state counters, when delivering packets from UPF to gNB and/or within RAN to lower layers to express a level of urgency. For example, this STS information may be used in PDCP layer to invoke PDCP duplication or multi-connectivity and passed through the stack, such as to the radio resource management (RRM) and scheduler to select the MCS. In an embodiment, the method may include carrying the STS information via new information elements that may be provided at the interfaces and state machines, e.g., in the UPF or PDCP layer. In an embodiment, the method may include receiving an acknowledgement of receipt of a packet, which may also include information about meeting of the PDB (e.g., NACK if the AN-PDB had not been achieved).
In some embodiments, the method of
According to an embodiment, for a fully synchronized system, the survival time end may contain the full information together with the 5QI QoS and TSCAI. The target network node may then deduce the urgency and required link layer configuration so that survival time is not exceeded. According to an embodiment, in case of SPS, the survival time end can be used to select a slot that is suited to maintain the PDB and receive the messages exactly at the expected deterministic timing (or shortly before when using the hold-and-forward-buffer). In another embodiment, if the network nodes are not synchronized then it may not be meaningful to forward a survival time end, but the STS information may still provide an indication of the level of urgency and thus for the configuration of the link layer.
When a handover latency occurs, this may hinder the target network node from transmitting at the next due transmission time, creating additional packet loss to the application. In an embodiment, the providing 620 may include providing this handover latency to be added on top of the provided survival time state counter.
According to certain embodiments, in case of a handover between network nodes, the providing 620 may also include transferring QoS context to the target network node. To this QoS context, in an embodiment, the above-mentioned dynamic state information on survival time may be added, e.g., in order to support deterministic traffic and allow for dynamic adaptation. According to an embodiment, the providing 620 may include providing this information in one or more information element(s) within a HANDOVER REQUEST message in a handover procedure (e.g., via Xn or NG). Additionally, in an embodiment, the providing 620 may further include transferring the TSCAI information in the information element(s) to the target network node in case of handover.
In an embodiment, the information element(s) may include a PDU Session Resources To Be Setup List, that contains an item per PDU session, PDU Session Resources To Be Setup Item. Each of these items may contain the QoS Flows To Be Setup List, which itself has one item per QoS flow: QoS Flows To Be Setup Item. These items may contain, among other elements, the QCI and the QoS Flow Level QoS Parameters IE. For GBR QoS flows, this IE may also contain the GBR QoS Flow Information with detailed information on the QoS parameters like the guaranteed flow bitrate uplink/downlink Alternatively, in an embodiment, the information may be exchanged from to the target network node via the UPF. Furthermore, in one embodiment, the IE included in the HANDOVER REQUEST may also contain the additional survival time state information for the respective TSC QoS flow. Additionally, in an embodiment, the IE may also include the TSCAI, which may also be transferred in the HANDOVER REQUEST message and thus added to it.
As illustrated in the example of
According to certain embodiments, in case of a handover of the UE from the source network node, the receiving 630 may also include receiving QoS context from the source network node. To this QoS context, in an embodiment, the above-mentioned dynamic state information on survival time may be added, e.g., in order to support deterministic traffic and allow for dynamic adaptation. According to an embodiment, the receiving 630 may include receiving this information in one or more information element(s) within a HANDOVER REQUEST message in a handover procedure (e.g., via Xn or NG). Additionally, in an embodiment, the receiving 630 may further include receiving the TSCAI information in the information element(s) from the source network node in case of handover.
In an embodiment, the information element(s) may include a PDU Session Resources To Be Setup List, that contains an item per PDU session, PDU Session Resources To Be Setup Item. Each of these items may contain the QoS Flows To Be Setup List, which itself has one item per QoS flow: QoS Flows To Be Setup Item. These items may contain, among other elements, the QCI and the QoS Flow Level QoS Parameters IE. For GBR QoS flows, this IE may also contain the GBR QoS Flow Information with detailed information on the QoS parameters like the guaranteed flow bitrate uplink/downlink Alternatively, in an embodiment, the information may be exchanged from to the target network node via the UPF. Furthermore, in one embodiment, the IE included in the HANDOVER REQUEST may also contain the additional survival time state information for the respective TSC QoS flow. Additionally, in an embodiment, the IE may also include the TSCAI, which may also be transferred in the HANDOVER REQUEST message.
In an embodiment, the method of
In an embodiment, the method of
It should be understood that, in some example embodiments, apparatus 10 may be comprised of an edge cloud server as a distributed computing system where the server and the radio node may be stand-alone apparatuses communicating with each other via a radio path or via a wired connection, or where they may be located in a same entity communicating via a wired connection. For instance, in certain example embodiments where apparatus 10 represents a gNB, it may be configured in a central unit (CU) and distributed unit (DU) architecture that divides the gNB functionality. In such an architecture, the CU may be a logical node that includes gNB functions such as transfer of user data, mobility control, radio access network sharing, positioning, and/or session management, etc. The CU may control the operation of DU(s) over a front-haul interface. The DU may be a logical node that includes a subset of the gNB functions, depending on the functional split option. It should be noted that one of ordinary skill in the art would understand that apparatus 10 may include components or features not shown in
As illustrated in the example of
Processor 12 may perform functions associated with the operation of apparatus 10, which may include, for example, precoding of antenna gain/phase parameters, encoding and decoding of individual bits forming a communication message, formatting of information, and overall control of the apparatus 10, including processes related to management of communication resources.
Apparatus 10 may further include or be coupled to a memory 14 (internal or external), which may be coupled to processor 12, for storing information and instructions that may be executed by processor 12. Memory 14 may be one or more memories and of any type suitable to the local application environment, and may be implemented using any suitable volatile or nonvolatile data storage technology such as a semiconductor-based memory device, a magnetic memory device and system, an optical memory device and system, fixed memory, and/or removable memory. For example, memory 14 can be comprised of any combination of random access memory (RAM), read only memory (ROM), static storage such as a magnetic or optical disk, hard disk drive (HDD), or any other type of non-transitory machine or computer readable media. The instructions stored in memory 14 may include program instructions or computer program code that, when executed by processor 12, enable the apparatus 10 to perform tasks as described herein.
In an embodiment, apparatus 10 may further include or be coupled to (internal or external) a drive or port that is configured to accept and read an external computer readable storage medium, such as an optical disc, USB drive, flash drive, or any other storage medium. For example, the external computer readable storage medium may store a computer program or software for execution by processor 12 and/or apparatus 10.
In some embodiments, apparatus 10 may also include or be coupled to one or more antennas 15 for transmitting and receiving signals and/or data to and from apparatus 10. Apparatus 10 may further include or be coupled to a transceiver 18 configured to transmit and receive information. The transceiver 18 may include, for example, a plurality of radio interfaces that may be coupled to the antenna(s) 15. In certain embodiments, the radio interfaces may correspond to a plurality of radio access technologies including one or more of GSM, NB-IoT, LTE, 5G, WLAN, Bluetooth, BT-LE, NFC, radio frequency identifier (RFID), ultrawideband (UWB), MulteFire, and/or the like. According to an example embodiment, the radio interface may include components, such as filters, converters (for example, digital-to-analog converters and the like), mappers, a Fast Fourier Transform (FFT) module, and/or the like, e.g., to generate symbols for transmission via one or more downlinks and to receive symbols (for example, via an uplink).
As such, transceiver 18 may be configured to modulate information on to a carrier waveform for transmission by the antenna(s) 15 and demodulate information received via the antenna(s) 15 for further processing by other elements of apparatus 10. In other example embodiments, transceiver 18 may be capable of transmitting and receiving signals or data directly. Additionally or alternatively, in some embodiments, apparatus 10 may include an input and/or output device (I/O device).
In an embodiment, memory 14 may store software modules that provide functionality when executed by processor 12. The modules may include, for example, an operating system that provides operating system functionality for apparatus 10. The memory may also store one or more functional modules, such as an application or program, to provide additional functionality for apparatus 10. The components of apparatus 10 may be implemented in hardware, or as any suitable combination of hardware and software.
According to some embodiments, processor 12 and memory 14 may be included in or may form a part of processing circuitry or control circuitry. In addition, in some embodiments, transceiver 18 may be included in or may form a part of transceiver circuitry.
As used herein, the term “circuitry” may refer to hardware-only circuitry implementations (e.g., analog and/or digital circuitry), combinations of hardware circuits and software, combinations of analog and/or digital hardware circuits with software/firmware, any portions of hardware processor(s) with software (including digital signal processors) that work together to case an apparatus (e.g., apparatus 10) to perform various functions, and/or hardware circuit(s) and/or processor(s), or portions thereof, that use software for operation but where the software may not be present when it is not needed for operation. As a further example, as used herein, the term “circuitry” may also cover an implementation of merely a hardware circuit or processor (or multiple processors), or portion of a hardware circuit or processor, and its accompanying software and/or firmware. The term circuitry may also cover, for example, a baseband integrated circuit in a server, cellular network node or device, or other computing or network device.
As introduced above, in certain embodiments, apparatus 10 may be a network node or RAN node, such as a base station, access point, Node B, eNB, gNB, WLAN access point, or the like. For example, in some embodiments, apparatus 10 may be configured to perform one or more of the processes depicted in any of the flow charts or signaling diagrams described herein, such as those illustrated in
In one embodiment, apparatus 10 may be a current or source network node (e.g., gNB). According to this embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to monitor communication service availability for one or more TSN applications in a 5GS using at least one of STS information, TSCAI, and/or a QoS profile. In an embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to select link layer configurations based on the at least one of the STS information, TSCAI, and/or the QoS profile.
According to one embodiment, the STS information may include survival time, survival timer, survival time end, and/or survival time state counters, for example. In an embodiment, the QoS profile may include 5QI and/or a PDB value. In some embodiments, the monitoring may include using the survival time, the TSCAI and the QoS profile (e.g., the PDB value), to characterize the communication service availability on the application level in the 5GS. In a variant, the monitoring may include dynamically monitoring the status of packet delivery with respect to the survival time window since a previous unsuccessful packet delivery.
According to an embodiment, given a packet periodicity, apparatus 10 may be controlled by memory 14 and processor 12 to translate a survival time into the form of a count of packets or traffic periods, as described in terms of TSC deterministic traffic TSCAI parameters. In an embodiment, where a message is anticipated to be received with a periodicity of Tp at a defined latest point in time, a survival time of Ts would allow for a maximum permissible consecutive loss of m messages according to: m=└Ts/Tp┘, with └x┘ denoting the rounding to the greatest integer less than or equal to x, and therefore the survival time may be: Ts>=m*Tp.
In some embodiments, a survival timer, may define a countdown timer that is set to the survival time triggered by a packet loss. According to an embodiment, the survival timer may define the maximum window to successfully deliver a packet of the periodic message sequence before the communication service is considered unavailable. In an embodiment, after such successful delivery of a packet, apparatus 10 may be controlled by memory 14 and processor 12 to stop the survival timer. According to an embodiment, when the survival timer reaches zero, then apparatus 10 may be controlled by memory 14 and processor 12 to consider the communication service unavailable. Therefore, according to an embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to start a survival timer, stop the survival timer when a packet is successfully delivered or to consider the communication service as unavailable when the survival timer reaches zero.
In an embodiment, after receiving a negative acknowledgement (NACK) for a packet, apparatus 10 may be controlled by memory 14 and processor 12 to set the survival timer to the survival time corrected for the time between the expected delivery at the UE egress (DS-TT) or RAN ingress (NW-TT) and to set the time that the survival timer is started according to the following formula: TPDCPtimedelta=Starting time of Survival Timer−Expected Arrival Time of the Lost Packet. Thus, in some embodiments, apparatus 10 may be controlled by memory 14 and processor 12 to set the survival timer to: Ts,timer, PDCP=Ts−TPDCPtimedelta. In a further embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to express the survival time for a transmission as an absolute point in time for latest delivery of the next message as the survival time end: Ts,end=Expected Arrival Time of the Lost Packet+Ts.
In an embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to calculate the expected arrival time of a lost packet for a given period from the TSCAI and the feedback from lower layers to the PDCP on the unsuccessful delivery of the packet. According to an embodiment, when the delivery of another packet of this TSC QoS flow is later than the survival timer end, the service is considered unavailable. Alternatively or additionally, in a variant, the number of consecutive lost packets may be counted for TSC periodic traffic.
According to certain embodiments, apparatus 10 may be controlled by memory 14 and processor 12 to express a survival time state, for example, as an up-counter or down-counter. For instance, in an embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to set a survival time state up-counter to be equal to consecutive packet loss count, and/or to set a survival time state down-counter to be equal to m−consecutive packet loss count. In another embodiment, the survival time state may be expressed as a fraction or percentage of the maximum tolerable packet loss counter.
In certain embodiments, a minimum time between packet losses may be used where, for example, STS information may include information on last survival time packet. In one embodiment, this minimum time may be expressed as a time value based on the periodicity value or a number of periods.
According to certain embodiments, apparatus 10 may be controlled by memory 14 and processor 12 to use the STS information, such as the survival timer, survival time end or survival time state counters, when delivering packets from a UPF to a gNB and/or within RAN to lower layers to express a level of urgency. For example, in an embodiment, the level of urgency may be used to perform possible actions or determine whether to perform certain actions, such as configuring MCS, duplication, retransmission, etc. In an embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to transmit the STS information via new information elements that may be provided at the interfaces and state machines, e.g., in the UPF or PDCP layer. In one embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to receive an acknowledgement of receipt of a packet, which may also include information about meeting of the PDB.
In some embodiments, apparatus 10 may be controlled by memory 14 and processor 12 to, for example when initiating a handover of a UE to a target network node, provide the STS information to the target network node. For example, in an embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to inform at least the target network node using a new information element about the remaining time for the next successful transmission in terms of a survival time end or a survival time state counter. In one embodiment, the format of the provision of information to the target network node may depend on the synchronization of the network nodes and the scheduling scheme. For example, in an embodiment, the STS information may be provided as an additional parameter within the TSCAI information element provided to the target network node. In another embodiment, the STS information may be provided as a separate parameter or information element from the TSCAI and/or other QoS parameter.
According to an embodiment, for a fully synchronized system, the survival time end may contain the full information together with the 5QI QoS and TSCAI. In an embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to provide a handover latency to be added on top of the provided survival time state counter.
According to certain embodiments, in case of a handover, apparatus 10 may be controlled by memory 14 and processor 12 to transfer QoS context to the target network node. In some embodiments, apparatus 10 may be controlled by memory 14 and processor 12 to add, to the QoS context, the state information on survival time. According to one embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to provide the information in one or more information element(s) within a HANDOVER REQUEST message in a handover procedure. Additionally, in a variant, apparatus 10 may be controlled by memory 14 and processor 12 to transfer the TSCAI information in the information element(s) to the target network node in case of handover.
In an embodiment, the information element(s) may include a PDU Session Resources To Be Setup List, that contains an item per PDU session, PDU Session Resources To Be Setup Item. According to a variant, each of these items may contain, among other elements, the QCI and the QoS flow level QoS parameters IE and, for GBR QoS flows, the IE may also contain the GBR QoS flow information with detailed information on the QoS parameters like the guaranteed flow bitrate uplink/downlink In a further embodiment, the IE included in the HANDOVER REQUEST may also contain the additional survival time state information for the respective TSC QoS flow. Additionally, in an embodiment, the IE may also include the TSCAI, which may also be transferred in the HANDOVER REQUEST message.
In another embodiment, apparatus 10 may be a target network node (e.g., gNB). According to this embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to receive a message, for example, from a source gNB initiating handover of a UE. The message may include at least STS information. According to one embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to determine, based at least on the received STS information, the urgency and required link layer configuration so that survival time is not exceeded. In an embodiment, the STS information may include survival time, survival timer, survival time end, and/or survival time state counters, for example.
According to an embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to receive a new information element about the remaining time for the next successful transmission in terms of survival time end or a survival time state counter. In an embodiment, for a fully synchronized system, the message may include the STS information together with the 5QI QoS and/or TSCAI. In another embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to receive a handover latency, which may be added on top of the provided survival time state counter.
According to certain embodiments, in case of a handover of the UE from the source network node, apparatus 10 may be controlled by memory 14 and processor 12 to receive QoS context from the source network node. According to an embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to receive the information in one or more information element(s) within a HANDOVER REQUEST message in a handover procedure. Additionally, in an embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to receive the TSCAI information in the information element(s) from the source network node in case of handover.
In an embodiment, the information element(s) may include a PDU Session Resources To Be Setup List, that contains an item per PDU session, PDU Session Resources To Be Setup Item. According to one embodiment, each of these items may contain the QoS Flows To Be Setup List, which itself has one item per QoS flow: QoS Flows To Be Setup Item.
In an embodiment, for example in case of SPS, apparatus 10 may be controlled by memory 14 and processor 12 to select a slot that is suited to maintain the PDB and receive the messages exactly at the expected deterministic timing using the survival time end.
In some example embodiments, apparatus 20 may include one or more processors, one or more computer-readable storage medium (for example, memory, storage, or the like), one or more radio access components (for example, a modem, a transceiver, or the like), and/or a user interface. In some embodiments, apparatus 20 may be configured to operate using one or more radio access technologies, such as GSM, LTE, LTE-A, NR, 5G, WLAN, WiFi, NB-IoT, Bluetooth, NFC, MulteFire, and/or any other radio access technologies. It should be noted that one of ordinary skill in the art would understand that apparatus 20 may include components or features not shown in
As illustrated in the example of
Processor 22 may perform functions associated with the operation of apparatus 20 including, as some non-limiting examples, precoding of antenna gain/phase parameters, encoding and decoding of individual bits forming a communication message, formatting of information, and overall control of the apparatus 20, including processes related to management of communication resources.
Apparatus 20 may further include or be coupled to a memory 24 (internal or external), which may be coupled to processor 22, for storing information and instructions that may be executed by processor 22. Memory 24 may be one or more memories and of any type suitable to the local application environment, and may be implemented using any suitable volatile or nonvolatile data storage technology such as a semiconductor-based memory device, a magnetic memory device and system, an optical memory device and system, fixed memory, and/or removable memory. For example, memory 24 can be comprised of any combination of random access memory (RAM), read only memory (ROM), static storage such as a magnetic or optical disk, hard disk drive (HDD), or any other type of non-transitory machine or computer readable media. The instructions stored in memory 24 may include program instructions or computer program code that, when executed by processor 22, enable the apparatus 20 to perform tasks as described herein.
In an embodiment, apparatus 20 may further include or be coupled to (internal or external) a drive or port that is configured to accept and read an external computer readable storage medium, such as an optical disc, USB drive, flash drive, or any other storage medium. For example, the external computer readable storage medium may store a computer program or software for execution by processor 22 and/or apparatus 20.
In some embodiments, apparatus 20 may also include or be coupled to one or more antennas 25 for receiving a downlink signal and/or for transmitting via an uplink from apparatus 20. According to certain embodiments, apparatus 20 may further include a transceiver 28 configured to transmit and receive information. In one example, the transceiver 28 may also include a radio interface (e.g., a modem) coupled to the antenna 25. In some embodiments, the radio interface may correspond to a plurality of radio access technologies including one or more of GSM, LTE, LTE-A, 5G, NR, WLAN, NB-IoT, Bluetooth, BT-LE, NFC, RFID, UWB, and the like. In further example embodiments, the radio interface may include other components, such as filters, converters (for example, digital-to-analog converters and the like), symbol demappers, signal shaping components, an Inverse Fast Fourier Transform (IFFT) module, and the like, to process symbols, such as OFDMA symbols, carried by a downlink or an uplink.
For instance, transceiver 28 may be configured to modulate information on to a carrier waveform for transmission by the antenna(s) 25 and demodulate information received via the antenna(s) 25 for further processing by other elements of apparatus 20. In other example embodiments, transceiver 28 may be capable of transmitting and receiving signals or data directly. Additionally or alternatively, in some embodiments, apparatus 20 may include an input and/or output device (I/O device). In certain embodiments, apparatus 20 may further include a user interface, such as a graphical user interface or touchscreen.
In an embodiment, memory 24 stores software modules that provide functionality when executed by processor 22. The modules may include, for example, an operating system that provides operating system functionality for apparatus 20. The memory may also store one or more functional modules, such as an application or program, to provide additional functionality for apparatus 20. The components of apparatus 20 may be implemented in hardware, or as any suitable combination of hardware and software. According to an example embodiment, apparatus 20 may optionally be configured to communicate with apparatus 10 via a wireless or wired communications link 70 according to any radio access technology, such as NR.
According to some embodiments, processor 22 and/or memory 24 may be included in or may form a part of processing circuitry or control circuitry. In addition, in some embodiments, transceiver 28 may be included in or may form a part of transceiving circuitry.
As discussed above, according to some embodiments, apparatus 20 may be a UE, mobile device, mobile station, ME, IoT device and/or NB-IoT device, for example. According to certain embodiments, apparatus 20 may be controlled by memory 24 and processor 22 to perform the functions associated with example embodiments described herein. For example, in some embodiments, apparatus 20 may be configured to perform one or more of the processes depicted in any of the flow charts or signaling diagrams described herein, such as those illustrated in
In certain embodiments, apparatus 20 may be controlled by memory 24 and processor 22 to receive a message from a serving network node to trigger handover to a target network node. According to one example, the message may include a RRC reconfiguration message. In an embodiment, apparatus 20 may be controlled by memory 24 and processor 22 to switch to the new cell of the target network node. According to an embodiment, apparatus 20 may be controlled by memory 24 and processor 22 to transmit a reconfiguration complete message to the target network node, which may include the STS information, such as the survival time end and/or survival time status counters.
Therefore, certain example embodiments provide several technological improvements, enhancements, and/or advantages over existing technological processes and constitute an improvement at least to the technological field of wireless network control and management. For example, certain embodiments provide mechanisms to introduce survival time state (STS) information, e.g., as a PDU session/QoS flow functionality, to leverage the STS in the AN for QoS enhancement, and to introduce STS in the handover context (among QoS Context). One embodiment may be configured to monitor the failure to deliver packets within the PDB and to define for the monitoring new QoS flow context information. This context information may be applied, for example, to select the link layer parameters for the transmission following a failure. Accordingly, the use of certain example embodiments results in improved functioning of communications networks and their nodes, such as base stations, eNBs, gNBs, and/or UEs or mobile stations.
In some example embodiments, the functionality of any of the methods, processes, signaling diagrams, algorithms or flow charts described herein may be implemented by software and/or computer program code or portions of code stored in memory or other computer readable or tangible media, and executed by a processor.
In some example embodiments, an apparatus may be included or be associated with at least one software application, module, unit or entity configured as arithmetic operation(s), or as a program or portions of it (including an added or updated software routine), executed by at least one operation processor. Programs, also called program products or computer programs, including software routines, applets and macros, may be stored in any apparatus-readable data storage medium and may include program instructions to perform particular tasks.
A computer program product may include one or more computer-executable components which, when the program is run, are configured to carry out some example embodiments. The one or more computer-executable components may be at least one software code or portions of code. Modifications and configurations for implementing the functionality of an example embodiment may be performed as routine(s), which may be implemented as added or updated software routine(s). In one example, software routine(s) may be downloaded into the apparatus.
As an example, software or computer program code or portions of code may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, distribution medium, or computer readable medium, which may be any entity or device capable of carrying the program. Such carriers may include a record medium, computer memory, read-only memory, photoelectrical and/or electrical carrier signal, telecommunications signal, and/or software distribution package, for example. Depending on the processing power needed, the computer program may be executed in a single electronic digital computer or it may be distributed amongst a number of computers. The computer readable medium or computer readable storage medium may be a non-transitory medium.
In other example embodiments, the functionality may be performed by hardware or circuitry included in an apparatus, for example through the use of an application specific integrated circuit (ASIC), a programmable gate array (PGA), a field programmable gate array (FPGA), or any other combination of hardware and software. In yet another example embodiment, the functionality may be implemented as a signal, such as a non-tangible means, that can be carried by an electromagnetic signal downloaded from the Internet or other network.
According to an example embodiment, an apparatus, such as a node, device, or a corresponding component, may be configured as circuitry, a computer or a microprocessor, such as single-chip computer element, or as a chipset, which may include at least a memory for providing storage capacity used for arithmetic operation(s) and/or an operation processor for executing the arithmetic operation(s).
One having ordinary skill in the art will readily understand that the example embodiments as discussed above may be practiced with procedures in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although some embodiments have been described based upon these example embodiments, 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 example embodiments.
A first embodiment may be directed to a method may include monitoring communication service availability for one or more TSN applications in a 5GS using at least one of STS information, TSCAI, and/or a QoS profile. The method may also include selecting link layer configurations based on the at least one of the STS information, TSCAI, and/or the QoS profile.
In a variant, the STS information may include survival time, survival timer, survival time end, and/or survival time state counters, for example. According to a variant, the QoS profile may include 5QI and/or a PDB value. In some variants, the monitoring may include using the survival time, the TSCAI and the QoS profile (e.g., the PDB value), to characterize the communication service availability on the application level in the 5GS. In a variant, the monitoring may include dynamically monitoring the status of packet delivery with respect to the survival time window since one or more previous unsuccessful packet deliveries.
According to a variant, given a packet periodicity, the monitoring may include translating a survival time into the form of a count of packets or traffic periods, as described in terms of TSC deterministic traffic TSCAI parameters. In a variant, where a message is anticipated to be received with a periodicity of Tp at a defined latest point in time, a survival time of Ts would allow for a maximum permissible consecutive loss of m messages according to: m=└Ts/Tp┘, with └x┘ denoting the rounding to the greatest integer less than or equal to x, and therefore the survival time may be: Ts>=m*Tp.
In some variants, a survival timer, Ts,timer, may define a countdown timer that is set to the survival time triggered by a packet loss. According to a variant, the survival timer may define the maximum window to successfully deliver a packet of the periodic message sequence before the communication service is considered unavailable. In a variant, after such successful delivery of a packet, the survival timer may be stopped. According to another variant, when the survival timer reaches zero, then the communication service is considered unavailable. Therefore, according to a variant, the monitoring may include starting a survival timer, stopping the survival timer when a packet is successfully delivered or considering the communication service as unavailable when the survival timer reaches zero.
In a variant, after receiving a negative acknowledgement (NACK) for a packet, the method may include setting the survival timer to the survival time corrected for the time between the expected delivery at the UE egress (DS-TT) or RAN ingress (NW-TT) and setting the time that the survival timer is started according to the following formula: TPDCPtimedelta=Starting time of Survival Timer−Expected Arrival Time of the Lost Packet. Thus, in some variants, the method may include setting the survival timer to: Ts,timer, PDCP=Ts−TPDCPtimedelta. In a further variant, the method may include expressing the survival time for a transmission as an absolute point in time for latest delivery of the next message as the survival time end: Ts,end=Expected Arrival Time of the Lost Packet+Ts.
In a variant, the expected arrival time of a lost packet for a given period can be calculated from the TSCAI and the feedback from lower layers to the PDCP on the unsuccessful delivery of the packet. According to a variant, when the delivery of another packet of this TSC QoS flow is later than the survival timer end, the service is considered unavailable. Alternatively or additionally, in a variant, the number of consecutive lost packets may be counted for TSC periodic traffic.
According to certain variants, a survival time state may be expressed, for example, as an up-counter or down-counter. For instance, in a variant, a survival time state up-counter may be set to be equal to consecutive packet loss count, and/or a survival time state down-counter may be set to be equal to m−consecutive packet loss count. In another variant, the survival time state may be expressed as a fraction or percentage of the maximum tolerable packet loss counter. For example, in a variant, the survival time state %=100%*consecutive packet loss count/(m−1) with m=└Ts/Tp┘. In a variant, the method may include increasing the survival time state for every PDCP packet that is expected for periodic TSC traffic but is signaled as error to PDCP. In one variant, if the state is larger than 100%, the service is considered unavailable.
In certain variants, a minimum time between packet losses may be used where, for example, STS information may include information on last survival time packet. In one variant, this minimum time may be expressed as a time value based on the periodicity value or a number of periods.
According to certain variants, the method may include using the STS information, such as the survival timer, survival time end or survival time state counters, when delivering packets from a UPF to a gNB and/or within RAN to lower layers to express a level of urgency. For example, in one variant, the level of urgency may be used to perform possible actions or determine whether to perform certain actions, such as configuring MCS, duplication, retransmission, etc. In a variant, the method may include carrying the STS information via new information elements that may be provided at the interfaces and state machines, e.g., in the UPF or PDCP layer. In one variant, the method may include receiving an acknowledgement of receipt of a packet, which may also include information about meeting of the PDB.
In some variants, the method may also include, for example when initiating a handover of a UE to a target network node, providing the STS information to the target network node. For example, in a variant, the providing may include informing at least the target network node using a new information element about the remaining time for the next successful transmission in terms of a survival time end or a survival time state counter. In one variant, the format of the providing procedure may depend on the synchronization of the network nodes and the scheduling scheme.
According to a variant, for a fully synchronized system, the survival time end may contain the full information together with the 5QI QoS and TSCAI.
In a variant, the providing may include providing a handover latency to be added on top of the provided survival time state counter.
According to certain variants, in case of a handover, the providing may also include transferring QoS context to the target network node. In some variants, to the QoS context, the state information on survival time may be added. According to one variant, the providing may include providing the information in one or more information element(s) within a HANDOVER REQUEST message in a handover procedure. Additionally, in a variant, the providing may further include transferring the TSCAI information in the information element(s) to the target network node in case of handover.
In a variant, the information element(s) may include a PDU Session Resources To Be Setup List, that contains an item per PDU session, PDU Session Resources To Be Setup Item. According to a variant, each of these items may contain, among other elements, the QCI and the QoS flow level QoS parameters IE and, for GBR QoS flows, the IE may also contain the GBR QoS flow information with detailed information on the QoS parameters like the guaranteed flow bitrate uplink/downlink. In a further variant, the IE included in the HANDOVER REQUEST may also contain the additional survival time state information for the respective TSC QoS flow. Additionally, in a variant, the IE may also include the TSCAI, which may also be transferred in the HANDOVER REQUEST message.
A second embodiment is directed to a method that may include receiving a message, for example, from a source gNB initiating handover of a UE. The message may include at least STS information. The method may also include determining, based at least on the received STS information, the urgency and required link layer configuration so that survival time is not exceeded.
In a variant, the STS information may include survival time, survival timer, survival time end, and/or survival time state counters, for example.
According to a variant, the receiving may include receiving a new information element about the remaining time for the next successful transmission in terms of survival time end or a survival time state counter. In a variant, for a fully synchronized system, the message may include the STS information together with the 5QI QoS and/or TSCAI. In another variant, the receiving may include receiving a handover latency, which may be added on top of the provided survival time state counter.
According to certain variants, in case of a handover of the UE from the source network node, the receiving may also include receiving QoS context from the source network node. According to a variant, the receiving may include receiving the information in one or more information element(s) within a HANDOVER REQUEST message in a handover procedure. Additionally, in a variant, the receiving may further include receiving the TSCAI information in the information element(s) from the source network node in case of handover.
In a variant, the information element(s) may include a PDU Session Resources To Be Setup List, that contains an item per PDU session, PDU Session Resources To Be Setup Item. According to a variant, each of these items may contain the QoS Flows To Be Setup List, which itself has one item per QoS flow: QoS Flows To Be Setup Item.
In a variant, for example in case of SPS, the method may include selecting a slot that is suited to maintain the PDB and receive the messages exactly at the expected deterministic timing using the survival time end.
A third embodiment is directed to a method that may include receiving a message from a serving network node to trigger handover to a target network node. According to one example, the message may include a RRC reconfiguration message. The method may then include switching to the new cell of the target network node. The method may also include transmitting a reconfiguration complete message to the target network node, which includes the STS information, such as the survival time end and/or survival time status counters
A fourth embodiment is directed to an apparatus including at least one processor and at least one memory comprising computer program code. The at least one memory and computer program code may be configured, with the at least one processor, to cause the apparatus at least to perform the method according to the first embodiment, the second embodiment, the third embodiment, and/or any other embodiments discussed herein, or any of the variants described above.
A fifth embodiment is directed to an apparatus that may include circuitry configured to perform the method according to the first embodiment, the second embodiment, the third embodiment, and/or any other embodiments discussed herein, or any of the variants described above.
A sixth embodiment is directed to an apparatus that may include means for performing the method according to the first embodiment, the second embodiment, the third embodiment, and/or any other embodiments discussed herein, or any of the variants described above.
A seventh embodiment is directed to a non-transitory computer readable medium comprising program instructions stored thereon for performing at least the method according to the first embodiment, the second embodiment, the third embodiment, and/or any other embodiments discussed herein, or any of the variants described above.
This application claims priority from U.S. Provisional Application No. 62/964,820, filed on Jan. 23, 2020. The entire contents of this earlier filed application are hereby incorporated by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62964820 | Jan 2020 | US |
