US20210105213A1 - Opportunistic packet retransmissions - Google Patents
Opportunistic packet retransmissions Download PDFInfo
- Publication number
- US20210105213A1 US20210105213A1 US16/594,961 US201916594961A US2021105213A1 US 20210105213 A1 US20210105213 A1 US 20210105213A1 US 201916594961 A US201916594961 A US 201916594961A US 2021105213 A1 US2021105213 A1 US 2021105213A1
- Authority
- US
- United States
- Prior art keywords
- retransmission
- busy level
- channel busy
- message
- minimum
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000004891 communication Methods 0.000 claims abstract description 57
- 230000007423 decrease Effects 0.000 claims abstract description 12
- 230000005540 biological transmission Effects 0.000 claims description 33
- 238000000034 method Methods 0.000 claims description 29
- 238000013459 approach Methods 0.000 description 13
- 230000001413 cellular effect Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 238000004088 simulation Methods 0.000 description 3
- 238000004422 calculation algorithm Methods 0.000 description 2
- 230000001351 cycling effect Effects 0.000 description 2
- 238000012886 linear function Methods 0.000 description 2
- 230000001133 acceleration Effects 0.000 description 1
- 230000003466 anti-cipated effect Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000005094 computer simulation Methods 0.000 description 1
- 230000001143 conditioned effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/12—Avoiding congestion; Recovering from congestion
- H04L47/127—Avoiding congestion; Recovering from congestion by using congestion prediction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1809—Selective-repeat protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1887—Scheduling and prioritising arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1896—ARQ related signaling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/24—Multipath
- H04L45/245—Link aggregation, e.g. trunking
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/12—Avoiding congestion; Recovering from congestion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/823—Prediction of resource usage
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0289—Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
- H04L47/741—Holding a request until resources become available
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/83—Admission control; Resource allocation based on usage prediction
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
In an opportunistic packet retransmission strategy, responsive to determining that a retransmission mode is set, a retransmission probability is calculated using minimum and maximum channel busy level retransmission thresholds, such that if a channel busy level of a communication channel is less than a minimum channel busy level retransmission threshold then a retransmission probability is set to 100%, if the channel busy level is greater than the maximum channel busy level then the retransmission probability is set to 0%, and within the minimum and maximum channel busy level retransmission thresholds the retransmission probability is set to decrease from 100% to 0% as a channel busy level of the communication channel rises from the minimum channel busy level retransmission threshold to the maximum channel busy level retransmission threshold. The message is retransmitted responsive to randomly determining whether to retransmit according to the retransmission probability.
Description
- Aspects of the disclosure generally relate to opportunistic packet retransmissions.
- In data communications, whether wireless or cabled, a communication channel inevitably introduces corruption and errors into the received packets, such that a recipient network node may not correctly receive the original message transmitted by the source network node. Retransmission of an original message is a technique that may help improve communication reliability. However, retransmission also increases the congestion on the channel and therefore reduces the transmission opportunity for other sender network nodes.
- In one or more illustrative examples, a system for opportunistic packet retransmission comprises a network node, including a processor and a network transceiver configured to perform network communication over a communication channel. The processor programmed to transmit a message over the communication channel, verify that a count of transmissions of the message is within a maximum retransmission limit for the message, determine a channel busy level for the communication channel, responsive to determining that a retransmission mode is set, calculate a retransmission probability using minimum and maximum channel busy level retransmission thresholds, such that if the channel busy level is less than the minimum channel busy level retransmission threshold then the probability of retransmission is set to 100%, if the channel busy level is greater than the maximum channel busy level then the probability of retransmission is set to 0%, and within the minimum and maximum channel busy level retransmission thresholds the probability of retransmission is set to decrease from 100% to 0% as the channel busy level rises from the minimum channel busy level retransmission threshold to the maximum channel busy level retransmission threshold, update the retransmission mode by randomly determining whether to retransmit according to the retransmission probability, and if the retransmission mode indicates to continue with retransmission, perform retransmission of the message over the communication channel and update the count of transmissions of the message.
- In one or more illustrative examples, a method for opportunistic packet retransmission by a network node includes verifying that a count of transmissions of a message over a communication channel is within a maximum retransmission limit for the message; when verified, and responsive to determining that a retransmission mode is set, calculating a retransmission probability using minimum and maximum channel busy level retransmission thresholds, such that if the channel busy level is less than the minimum channel busy level retransmission threshold then the retransmission probability is set to 100%, if the channel busy level is greater than the maximum channel busy level then the retransmission probability is set to 0%, and within the minimum and maximum channel busy level retransmission thresholds the retransmission probability is set to decrease from 100% to 0% as a channel busy level of the communication channel rises from the minimum channel busy level retransmission threshold to the maximum channel busy level retransmission threshold; and responsive to randomly determining whether to retransmit according to the retransmission probability indicating to retransmit, retransmitting the message over the communication channel and updating the count of transmissions of the message.
- In one or more illustrative examples, a non-transitory computer-readable medium comprises instructions for opportunistic packet retransmission, the instructions including retransmission rules that, when executed by a processor of a network node having a network interface to a communication channel, cause the processor to compute a channel busy level for the communication channel as a percentage of time that the communication channel is busy, including time that the network transceiver of the network node has spent transmitting over the channel; verify that a count of transmissions of a message over the communication channel is within a maximum retransmission limit for the message; when verified, and responsive to determining that a retransmission mode is set, calculate a retransmission probability using minimum and maximum channel busy level retransmission thresholds, such that if the channel busy level is less than the minimum channel busy level retransmission threshold then the retransmission probability is set to 100%, if the channel busy level is greater than the maximum channel busy level then the retransmission probability is set to 0%, and within the minimum and maximum channel busy level retransmission thresholds the retransmission probability is set to decrease from 100% to 0% as a channel busy level of the communication channel rises from the minimum channel busy level retransmission threshold to the maximum channel busy level retransmission threshold; and responsive to randomly determining whether to retransmit according to the retransmission probability indicating to retransmit, retransmit the message over the communication channel and updating the count of transmissions of the message
-
FIG. 1 illustrates an example of communication of messages between network nodes over a communication channel; -
FIG. 2 illustrates an example detail of a network node; -
FIG. 3 illustrates an example process for the implementation of an opportunistic packet retransmission policy; -
FIG. 4 illustrates an example graph of transmission probability according to channel busy level; -
FIG. 5 illustrates an example graph of a simulation illustrating control of fluctuations in the channel busy level; and - As required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention.
-
FIG. 1 illustrates an example 100 of communication ofmessages 102 betweennetwork nodes 104 over acommunication channel 106. Amessage 102 includes data that is represented in a digital form and intended for transmission from onenetwork node 104 to anothernetwork node 104. Amessage 102 may be formatted as a set of packets for transmission. Each packet may include a portion of data encapsulated by a packet header which contains information about the packet. This information may include a destination address of thenetwork node 104 to which themessage 102 is intended, a source address of thenetwork node 104 providing the packet for transmission, and other information about the data being sent, such as length or a description. -
FIG. 2 illustrates an example detail of anetwork node 104. Thenetwork nodes 104 are computing devices that may serve as sources and destinations formessages 102. As shown, thenetwork node 104 includes anapplication processor 202, astorage 204, anetwork interface 206, andretransmission rules 208 installed to thestorage 204. - The
network nodes 104 may be any of various types of portable computing device, such as cellular phones, tablet computers, smart watches, laptop computers, portable music players, or other devices having processing and communications capabilities. Thenetwork nodes 104 may include one ormore processors 202 configured to execute computer instructions, and astorage 204 on which the computer-executable instructions and/or data may be maintained. Thenetwork nodes 104 may further include anetwork interface 206 which may be used to connect thenetwork nodes 104 to thecommunication channel 106. - Referring back to
FIG. 1 , thecommunication channel 106 is a path for themessages 102 to traverse between communicatingnetwork nodes 104. Examples ofcommunication channels 106 may include twisted pair wire, coaxial cable, fiber optic cable, or wireless such as via Wi-Fi, cellular, microwave, or satellite transmissions. Thecommunication channel 106 may include intermediate nodes that forward packets to the next node, and a link may refer to a discrete segment of thecommunication channel 106 such as a connection between two nodes. - The
communication channel 106 may also be indicated as having a particular bandwidth, which refers to a bit rate that may be transmitted over thecommunication channel 106. Thecommunication channel 106 may also have a level of busy-ness, which may be referred to herein as channel busy level (CBL). The CBL may be indicated as a percentage of the potential bandwidth of thechannel 106 that is being used for the transmission ofmessages 102. - In data communications, whether wireless or cabled, the
communication channel 106 inevitably introduces corruption and errors into the received packets, such that arecipient network node 104 may not correctly receive theoriginal message 102 transmitted by thesource network node 104. Retransmission of theoriginal message 102 is a technique that may help improve communication reliability. However, retransmission also increases the congestion on thechannel 106 and therefore also reduces the transmission opportunity for othersender network nodes 104. - An opportunistic approach for packet retransmission may be performed in which each
sender network node 104 assesses a busy load of thechannel 106 and then retransmits one or more times depending on whether the busy load of thechannel 106 is sufficiently low. The approach may take into account various factors, including: (i) critical or sharp vehicle maneuver events, (ii) congestion control being inactive and (iii) availability of thechannel 106. Regarding availability, a probabilistic rule may be used where the retransmission probability decreases as thechannel 106 busy level becomes higher so as to have fairness for other senders. This probabilistic rule ensures that the fluctuation and variability in thechannel 106 busy level can be managed to prevent senders from cycling between retransmitting and not retransmitting. This approach may be especially useful for vehicle-to-everything (V2X) applications (that may use hybrid-automatic repeat request (ARQ)) where reliability and fairness for all senders may be critical. - Retransmissions improve the reliability of a
sender network node 104 communicating with areceiver network node 104. When the channel busy level is low (for example when relatively few users are occupying thechannel 106 as compared to the capacity of the channel 106), retransmissions naturally help improve reliability and extend the range of communication for a sender. However, as the number of senders increases, the accumulative impact of their retransmissions amplify the congestion level of the channel and may cause downfall in the communication reliability due to higher chance of concurrent transmissions (i.e., packet errors). - The
messages 102 may have different priority levels, and the amount of retransmit retries for a givenmessages 102 may depend on its priority. In an example, acritical event message 102 in V2X due to a hard braking event may necessitate the sender to send more retransmissions of themessage 102 than when the sender is sending thesame message 102 under default non-critical circumstances. Additionally, V2X communication may use a congestion control algorithm (such as the algorithm specified in “On-Board System Requirements for V2V Safety Communications,” document J2945/1, published by the Society of Automotive Engineers (SAE)), where each sender decreases the frequency of its nominal transmissions as the number of similar senders is detected to increase. In such a situation, due to congestion and to avoid unfairness to others, it may be determined that no sender will retransmit itsmessages 102. - In general, retransmission (e.g., hybrid-ARQ in the cellular V2X context) may be made on a packet-by-packet (or BSM-by-BSM) basis. The BSM messages, as defined in SAE J2735 “Dedicated Short Range Communications (DSRC) Message Set Dictionary,” may be used for indicating the position of the vehicle. Reliably in communicating such information may accordingly be important for traffic participants. When determining whether to retransmit data, it may be relevant whether the data is related to driving or vehicle operation, or whether the data is related to entertainment or other aspects that are not related to driving or vehicle operation. In an example, it may be desirable to prefer retransmission of BSM or other driving-related data when a vehicle makes a sharp maneuver, where retransmission would be a less relevant factor during a sharp maneuver for other transmissions such as the streaming of entertainment media files. The retransmission policy may thus be driven by various factors. A first factor may be that the number of allowed retransmissions is based on priority. In one example implementation, (i) a critical event may have four maximum retransmissions, (ii) an alternative high priority message for sharp vehicle maneuvers (such as hard braking or hard acceleration (e.g., due to high tracking error) that is not a critical event may have a maximum of three retransmissions, and (iii) a default number of retransmissions for any
other message 102 may be limited to two retransmissions. These allowed maximum values are merely examples, and variations are possible. Moreover, these values may be set by the system operator as desired. - A second factor for the retransmission policy may be the critical nature or priority of the
message 102. To explain, regardless of whether congestion control is active or inactive and also regardless ofchannel 106 busy level, the maximum number of allowed retransmissions are always made for amessage 102 for a critical or high-priority event. These minimum number of retransmissions may aid in the probability of receipt ofsuch messages 102 over that ofother messages 102 over thechannel 106. - A third factor for the retransmission policy may be the operation of congestion control. To explain, retransmissions may not be made when congestion control is active, since the
channel 106 may already be experiencing too many transmissions (which caused congestion control to activate). Specifically, if the transmissions frequency of asender network node 104 is set at higher than the default value of an InterTransmitTime variable (e.g., more than 100 milliseconds in V2X situations), no retransmission is allowed. An exception in the congestion control active state may be when themessage 102 is critical or high priority, which then override the other factors and dictates the number of retransmissions. - A fourth factor to consider in the retransmission policy may be the channel busy level in default situations. For instance, the probability of retransmissions decreases as the
channel 106 occupancy increases while congestion control is inactive (e.g., when vInterTransmitTime=100 milliseconds). -
FIG. 3 illustrates anexample process 300 for the implementation of an opportunistic packet retransmission policy. In an example, the opportunistic packet retransmission policy may be implemented by the retransmission rules 208 installed to thestorage 204 of thenetwork node 104 and executed by theprocessor 202 of thenetwork node 104. - At
operation 302, theprocess 300 may begin with initialization of CBL thresholds and retransmission variables. For instance, the maximum number of retransmissions may be reset to a predefined maximum, a retransmission mode variable may be initialized to retransmission mode being set, a current retransmission may be set to the first retransmission, the actual number of transmissions may be set to one, and the minimum CBL and maximum CBL thresholds may be set to desired values. Further aspects of the settings of the minimum CBL and maximum CBL thresholds are discussed in further detail below. - Retransmissions in the default case represent when there is no critical or high priority event in V2X traffic applications and congestion control is inactive. In this default case, the first data packet (original message) is always sent with 100% probability; a retransmission, however, is sent opportunistically based on how busy the
channel 106 appears. - This channel occupancy is determined in terms of CBL. Thus, at
operation 304, the current CBL is determined. In an example, the CBL may be measured by asender network node 104 that continuously monitors thechannel 106 over a predefined duration of time (this duration of time may be retrieved from a variable). For example, a CBL of 50% indicates that the channel is occupied byusers 50% of the time. In the context of V2X, without loss of generality, CBL denotes both channel busy ratio (CBR) (as described in 3GPP C-V2X) or channel busy percentage (CBP) (as described in IEEE 802.11p or DSRC). The CBL also includes the percentage of time that the sender has spent on its own transmissions. The self-counting for CBL is already included in V2X standards such as SAE J2945/1. The duration of time variable denotes the interval in milliseconds that a sender monitors the channel. In V2X settings, nominally this variable may be set to 100 milliseconds, as BSMs may be broadcast at least every 100 milliseconds. - At
operation 306, it is determined whether the current retransmission is less than or equal to the maximum allowable number of retransmissions plus one, and also that the retransmission mode is set to allow for retransmission. If so, control passes tooperation 308. Otherwise, further retransmission will not be attempted and theprocess 300 ends. - Next, at 308, if the retransmission mode is set, control passes to
operation 310 to calculate the retransmission probability. If the retransmission mode is not set, control passes tooperation 316, which is discussed in detail below. - With respect to
operation 310, the retransmission probability is computed according to the CBL minimum and maximum thresholds. In an example, if the current load on the channel (e.g., the CBL) is below a minimum threshold (e.g., CBL<vCBLmin), retransmissions are always made. Moreover, if the current CBL is higher than the maximum threshold (e.g., CBL>vCBLmax), no retransmission is made. However, if the CBL is between these two thresholds, a retransmission is made with a certain probability. In one implementation, this probability decreases from 100% to zero as the CBL rises from vCBLmin to vCBLmax as a linear function. For example, if the CBL equals (vCBMmin+vCBLmax)/2, the retransmission probability is 50% (meaning there is a half and half chance that the original packet's retransmitted version is sent). However, it should be noted that use of a linear function is only one possibility, and that other functions having a monotonic decrease in retransmission probability with the rise in channel busy-ness may be used, such as exponential, quadratic, or other functions. - At
operation 312, it is determined whether or not to retransmit, according to random change using the retransmission probability determined atoperation 310. This may include, for example, generating a random value, and determining whether or not the random value indicates that retransmission should take place scaled according to the retransmission probability. - The determination results of
operation 312 are utilized atoperation 314 to update the retransmission mode to allow retransmission if the probability is met, and to update the retransmission mode to disallow retransmission if random value probability is not met. - At
operation 316, the retransmission probability is updated to account for message priority. In some implementations, if the message to be retransmitted refers to a critical event or a high-priority event (but not a default level event), then control passes tooperation 318 to set the retransmission mode to allow for retransmission, after which control passes tooperation 320. If the message is not deemed critical or high-priority atoperation 316, then control passes tooperation 320. Criticality or high-priority of the message may be determined from fields in the message itself, and/or from content of the message transmission, such as due to presence of a hard-braking event or other criteria as discussed above. It should be noted that these are just examples, and various other approaches to providing additional retransmission effort for higher priority messages may be used. - Next, at
operation 320 the retransmission is performed. Responsive to retransmission, the count of retransmissions is increased. Additionally, atoperation 322, the minimum CBL and maximum CBL thresholds may be updated, as discussed in detail below. Afteroperation 322, control returns tooperation 304 to calculate an updated CBL. In other examples, it should be noted that CBL may be recalculated asynchronously from the flow of theprocess 300, andoperation 304 may not be present in theprocess 300. In such an example, control may pass fromoperation 302 tooperation 306, and fromoperation 322 tooperation 306. - It should be noted that when using the
process 300, even with a default priority message, the sender may send more than just one retransmission. A subsequent retransmission (e.g., second or third retransmission) may be made (i) if the prior retransmission has already been made or (ii) if the maximum number of retransmissions permitted by the implementer is not reached. In each subsequent retransmission, however, the thresholds set for vCBLmin and vCBLmax are decreased to ensure that the overall system always remains stable. Stability in the occupancy of the channel is an important requirement for a communication network. If the senders were to naively retransmit and switch off their retransmissions if the CBL was large, then their communication performance may become unpredictable and the overall network data rate may be degraded. - Table 1 illustrates an example implementation of the
process 300, coded for MATLAB: -
TABLE 1 Example MATLAB Implementation of Opportunistic Packet Retransmissions Maximum number of retransmissions = Nmax RetransmissionMode = 1; CurrentRetransmission = 1; actualNumtransmissions = 1; set vCBLmin and vCBLmax to desired values (see Proposed Thresholds section below) while CurrentRetransmission <= Nmax+1 && RetransmissionMode == 1 if RetransmissionMode == 1 if CBL <= vCBLmin Prob_retransmit = 100; elseif CBL >= vCBLmax Prob_retransmit = 0; else Prob_retransmit = 100*(vCBLmax − CBL )/(vCBLmax − vCBLmin); end % (uniform random number between 0-1) retransmit = rand( )<Prob_retransmit/100; if retransmit==0 RetransmissionMode =0; end end if Exceptional_event == 1 %Critical event or high priority event RetransmissionMode =1; end % Make retransmission and add to counter CurrentRetransmission = CurrentRetransmission + 1; update vCBLmin; update vCBLmax; end - The choice of vCBLmin and vCBLmax are dictated by a need to balance stability with opportunistically using the channel 106 (e.g., a sender performs retransmissions for reliability but without causing unfairness for other senders). Moreover, the value of vCBLmin must be less than half of vCBLmax to reduce the chance of instability, since doing so may ensure that senders do not switch from retransmitting (high CBL) to not retransmitting (low CBL) in an endless cycle. The
process 300, accordingly, presumes that the retransmitted data packets are almost the same size as the original packet. -
FIG. 4 illustrates an example graph 400 of transmission probability according to channel busy level (CBL). The example graph 400 shows the retransmission policy for a sender that can make three retransmissions. The first line denotes the likelihood of transmission of first packet and retransmission in critical/high tracking error situations. The first retransmission is made based on the second probability function. The second retransmission is made if the first retransmission has been made with probability denoted by the third line. The third retransmission is made if the second retransmission was made with the probability denoted by the black line. - With respect to recommended thresholds, a 50% retransmission probability of the first retransmission creates maximum uncertainty or fluctuation in the CBL by the sender. The CBL at this level is referred to as CBL_maximum_uncertainty. In example graph 400, the vCBLmax is set to 24% and the vCBLmin is set to 8%. The mid-point CBL is therefore (24+8)/2=16% at 50% retransmission probability. Note that vCBLmin is at least half of vCBLmax, to prevent cycling between retransmitting and not retransmitting.
- The second retransmission probability is set to zero at CBLs of 16% or higher depending on whether the first retransmission was made. The variable vCBLmax on the second retransmission is 16% (e.g., which at the mid-point of the vCBLmax and vCBLmin of the first retransmission), where vCBLmin is 8% (which is half of that). The third retransmission is then conditioned on whether the second retransmission is made and with vCBLmax set to 8% (e.g., half of the vCBLmax of 16%) and vCBLmin set to 4% (e.g., half of the vCBLmin of 8%).
- More generally, for a first retransmission vCBLmax and vCBLmin are set according to Equations 1:
-
(vCBLmax + vCBLmin) / 2 = CBL at 50% retransmission probability (1) (CBL_maximum_uncertainty); and vCBLmin < vCBLmax. - For second or further retransmissions, vCBLmax and vCBLmin are set according to Equations 2:
-
vCBLmax < CBL_maximum_uncertainty (2) vCBLmin < vCBLmax / 2 CBL_maximum_uncertainty = (vCBLmax + vCBLmin) / 2 - The above operations may be repeated until the number of retransmissions reaches the maximum allowed Nmax.
-
FIG. 5 illustrates an example graph 500 of a simulation illustrating control of fluctuations in the channel busy level. In the example graph 500, computer simulations for a Cellular V2X (C-V2X) setup are used to illustrate that fluctuations in CBL can be controlled. The simulation is set with (i) 100 milliseconds channel busy monitoring time, (ii) Nmax=3, and (iii) 0.5 milliseconds per transmission with over 3000 random trials each with 20 iterations per trial. The setup is therefore designed to simulate a C-V2X scenario in which each sender is assigned unique and non-overlapping slot as other senders. Thus, all transmissions and retransmissions of each sender do not concurrently transmit with other users. The appropriate choice of vCBLmin and vCBLmax can be determined to optimize the CBL fluctuations with more retransmissions. In the example graph 500, the fluctuations are illustrated in terms of standard deviation of the CBL for a few thresholds of vCBLmin and vCBLmax under the default policy. No critical or high tracking error events were assumed. - In sum, the aforementioned approach to opportunistic packet retransmission works with various types of retransmission techniques (e.g., wireline, wireless, ARQ, HARQ etc.). The approach balances a need for better communication reliability with the additional congestion created by retransmissions, especially in V2X environments. When congestion levels are low, the senders can opportunistically retransmit to improve lower Packet Error Rate (PER) performance. When the congestion level is high, the likelihood of retransmission is reduced to alleviate congestion (e.g., for fairness to other senders). The approach also balances congestion control, critical/high priority events, and channel utilization in a stable manner as the number of V2X senders increases. For instance, when determining whether to retransmit data, BDM or other data transmitted in the context of critical/high priority events related to the driving task may be higher priority for retransmission above other data that is unrelated to driving or vehicle operation. The approach does not require the receiver to know whether a retransmission was made or not. The approach also does not require any cooperation or coordination between the senders, instead the approach only requires senders to know the current level of channel congestion. The approach does not require senders to store a history or have a memory of previous packet transmissions. The approach is fair for all senders, as it does not grant privilege or prioritize one sender over others. Finally, the approach provides all senders a chance to send some packets with retransmissions.
- Computing devices described herein, such as the
network nodes 104, generally include computer-executable instructions where the instructions may be executable by one or more computing devices such as those listed above. Computer-executable instructions, such as those of the retransmission rules 208, may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, JAVA, C, C++, C#, VISUAL BASIC, JAVASCRIPT, PYTHON, PERL, PL/SQL, etc. In general, a processor (e.g., a microprocessor) receives instructions, e.g., from a memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes, including one or more of the processes described herein. Such instructions and other data may be stored and transmitted using a variety of computer-readable media. - With regard to the processes, systems, methods, heuristics, etc. described herein, it should be understood that, although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes could be practiced with the described steps performed in an order other than the order described herein. It further should be understood that certain steps could be performed simultaneously, that other steps could be added, or that certain steps described herein could be omitted. In other words, the descriptions of processes herein are provided for the purpose of illustrating certain embodiments, and should in no way be construed so as to limit the claims.
- Accordingly, it is to be understood that the above description is intended to be illustrative and not restrictive. Many embodiments and applications other than the examples provided would be apparent upon reading the above description. The scope should be determined, not with reference to the above description, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. It is anticipated and intended that future developments will occur in the technologies discussed herein, and that the disclosed systems and methods will be incorporated into such future embodiments. In sum, it should be understood that the application is capable of modification and variation.
- All terms used in the claims are intended to be given their broadest reasonable constructions and their ordinary meanings as understood by those knowledgeable in the technologies described herein unless an explicit indication to the contrary in made herein. In particular, use of the singular articles such as “a,” “the,” “said,” etc. should be read to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary.
- The abstract of the disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.
- While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. Additionally, the features of various implementing embodiments may be combined to form further embodiments of the invention.
Claims (20)
1. A system for opportunistic packet retransmission, comprising:
a network node, including a processor and a network transceiver configured to perform network communication over a communication channel, the processor programmed to
transmit a message over the communication channel,
verify that a count of transmissions of the message is within a maximum retransmission limit for the message,
determine a channel busy level for the communication channel,
responsive to determining that a retransmission mode is set, calculate a retransmission probability using minimum and maximum channel busy level retransmission thresholds, such that if the channel busy level is less than the minimum channel busy level retransmission threshold then the retransmission probability is set to 100%, if the channel busy level is greater than the maximum channel busy level then the retransmission probability is set to 0%, and within the minimum and maximum channel busy level retransmission thresholds the retransmission probability is set to decrease from 100% to 0% as the channel busy level rises from the minimum channel busy level retransmission threshold to the maximum channel busy level retransmission threshold,
update the retransmission mode by randomly determining whether to retransmit according to the retransmission probability, and
if the retransmission mode indicates to continue with retransmission, perform retransmission of the message over the communication channel and update the count of transmissions of the message.
2. The system of claim 1 , wherein the processor is further programmed to:
determine a priority of the message; and
responsive to determining that the priority of the message is high priority, override the retransmission mode to provide for retransmission of the message.
3. The system of claim 2 , wherein the processor is further programmed to determine the message as being high priority responsive to occurrence of a sharp vehicle maneuver event by a vehicle including the network node.
4. The system of claim 1 , wherein the processor is further programmed to set the maximum retransmission limit for the message according to a priority of the message.
5. The system of claim 1 , wherein the processor is further programmed to, for a first retransmission of the message, set the minimum and maximum channel busy level retransmission thresholds such that an arithmetic average of the minimum and maximum channel busy level retransmission thresholds is a channel busy level providing for 50% probability of retransmission of the message, and the minimum channel busy level retransmission threshold is less than the maximum channel busy level retransmission threshold.
6. The system of claim 1 , wherein the processor is further programmed to, for a second or greater retransmission of the message, set the minimum and maximum channel busy level retransmission thresholds such that the maximum channel busy level retransmission threshold is less than the channel busy level providing for a 50% probability of retransmission of the message and the minimum channel busy level retransmission threshold is less than half of the maximum channel busy level retransmission threshold.
7. The system of claim 6 , wherein the processor is further programmed to determine the channel busy level providing for a 50% probability of retransmission of the message as an average of the minimum and maximum channel busy level retransmission thresholds in view of the channel busy level.
8. The system of claim 1 , wherein the processor is further programmed to compute the channel busy level as a percentage of time that the channel is busy, including time that the network transceiver of the network node has spent transmitting over the channel.
9. A method for opportunistic packet retransmissions by a network node, comprising:
verifying that a count of transmissions of a message over a communication channel is within a maximum retransmission limit for the message;
when verified, and responsive to determining that a retransmission mode is set, calculating a retransmission probability using minimum and maximum channel busy level retransmission thresholds, such that if the channel busy level is less than the minimum channel busy level retransmission threshold then the retransmission probability is set to 100%, if the channel busy level is greater than the maximum channel busy level then the retransmission probability is set to 0%, and within the minimum and maximum channel busy level retransmission thresholds the retransmission probability is set to decrease from 100% to 0% as a channel busy level of the communication channel rises from the minimum channel busy level retransmission threshold to the maximum channel busy level retransmission threshold; and
responsive to randomly determining whether to retransmit according to the retransmission probability indicating to retransmit, retransmitting the message over the communication channel and updating the count of transmissions of the message.
10. The method of claim 9 , further comprising overriding the determination whether to retransmit responsive to determining the message as being high priority.
11. The method of claim 9 , further comprising setting the maximum retransmission limit for the message according to a priority of the message.
12. The method of claim 9 , further comprising, for a first retransmission of the message, setting the minimum and maximum channel busy level retransmission thresholds such that an arithmetic average of the minimum and maximum channel busy level retransmission thresholds is a channel busy level providing for 50% probability of retransmission of the message, and the minimum channel busy level retransmission threshold is less than the maximum channel busy level retransmission threshold.
13. The method of claim 9 , further comprising, for a second or greater retransmission of the message, setting the minimum and maximum channel busy level retransmission thresholds such that the maximum channel busy level retransmission threshold is less than the channel busy level providing for a 50% probability of retransmission of the message and the minimum channel busy level retransmission threshold is less than half of the maximum channel busy level retransmission threshold.
14. The method of claim 13 , further comprising determining the channel busy level providing for a 50% probability of retransmission of the message as an average of the minimum and maximum channel busy level retransmission thresholds in view of the channel busy level.
15. The method of claim 9 , further comprising computing the channel busy level as a percentage of time that the channel is busy, including time that the network node has spent transmitting over the channel.
16. A non-transitory computer-readable medium comprises instructions for opportunistic packet retransmission, the instructions including retransmission rules that, when executed by a processor of a network node having a network interface to a communication channel, cause the processor to:
compute a channel busy level for the communication channel as a percentage of time that the communication channel is busy, including time that the network transceiver of the network node has spent transmitting over the channel;
verify that a count of transmissions of a message over the communication channel is within a maximum retransmission limit for the message;
when verified, and responsive to determining that a retransmission mode is set, calculate a retransmission probability using minimum and maximum channel busy level retransmission thresholds, such that if the channel busy level is less than the minimum channel busy level retransmission threshold then the retransmission probability is set to 100%, if the channel busy level is greater than the maximum channel busy level then the retransmission probability is set to 0%, and within the minimum and maximum channel busy level retransmission thresholds the retransmission probability is set to decrease from 100% to 0% as a channel busy level of the communication channel rises from the minimum channel busy level retransmission threshold to the maximum channel busy level retransmission threshold; and
responsive to randomly determining whether to retransmit according to the retransmission probability indicating to retransmit, retransmit the message over the communication channel and updating the count of transmissions of the message.
17. The medium of claim 16 , further comprising instructions that, when executed by the processor, cause the processor to:
determine a priority of the message responsive to occurrence of a sharp vehicle maneuver event by a vehicle including the network node;
set the maximum retransmission limit for the message according to a priority of the message; and
responsive to determining that the priority of the message is high priority, override the retransmission mode to provide for retransmission of the message.
18. The medium of claim 16 , further comprising instructions that, when executed by the processor, cause the processor to, for a first retransmission of the message, set the minimum and maximum channel busy level retransmission thresholds such that an arithmetic average of the minimum and maximum channel busy level retransmission thresholds is a channel busy level providing for 50% probability of retransmission of the message, and the minimum channel busy level retransmission threshold is less than the maximum channel busy level retransmission threshold.
19. The medium of claim 16 , further comprising instructions that, when executed by the processor, cause the processor to, for a second or greater retransmission of the message, set the minimum and maximum channel busy level retransmission thresholds such that the maximum channel busy level retransmission threshold is less than the channel busy level providing for a 50% probability of retransmission of the message and the minimum channel busy level retransmission threshold is less than half of the maximum channel busy level retransmission threshold.
20. The medium of claim 16 , further comprising instructions that, when executed by the processor, cause the processor to determine the channel busy level providing for a 50% probability of retransmission of the message as an average of the minimum and maximum channel busy level retransmission thresholds in view of the channel busy level.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/594,961 US10992583B1 (en) | 2019-10-07 | 2019-10-07 | Opportunistic packet retransmissions |
DE102020126153.5A DE102020126153A1 (en) | 2019-10-07 | 2020-10-06 | OPPORTUNISTIC PACKAGE RETRANSMISSIONS |
CN202011074325.6A CN112636876A (en) | 2019-10-07 | 2020-10-09 | Opportunistic packet retransmission |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/594,961 US10992583B1 (en) | 2019-10-07 | 2019-10-07 | Opportunistic packet retransmissions |
Publications (2)
Publication Number | Publication Date |
---|---|
US20210105213A1 true US20210105213A1 (en) | 2021-04-08 |
US10992583B1 US10992583B1 (en) | 2021-04-27 |
Family
ID=74875550
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/594,961 Active 2039-10-28 US10992583B1 (en) | 2019-10-07 | 2019-10-07 | Opportunistic packet retransmissions |
Country Status (3)
Country | Link |
---|---|
US (1) | US10992583B1 (en) |
CN (1) | CN112636876A (en) |
DE (1) | DE102020126153A1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20220164898A1 (en) * | 2020-11-26 | 2022-05-26 | National Tsing Hua University | Method and system for calculating total transmission probability within social network based on timing |
US20220393806A1 (en) * | 2019-11-07 | 2022-12-08 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and device for determining transmission priority |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070070902A1 (en) * | 2005-06-21 | 2007-03-29 | Toshiba America Research, Inc. | An admission control for contention-based access to a wireless communication medium |
US20090225682A1 (en) * | 2006-04-04 | 2009-09-10 | Alex Peter Grote-Lopez | Optimization Procedure for Wireless Networks Operating in Infrastructure Mode with Standard Protocol IEEE 802.11 |
US20160057770A1 (en) * | 2014-08-22 | 2016-02-25 | Qualcomm Incorporated | Techniques for transmitting and receiving channel occupancy identifiers over an unlicensed radio frequency spectrum band |
US20170048880A1 (en) * | 2015-08-12 | 2017-02-16 | Blackberry Limited | Uplink resource scheduling control in response to channel busy condition |
US20170303159A1 (en) * | 2014-10-06 | 2017-10-19 | Vid Scale, Inc | Adapting communication parameters to link conditions, traffic types, and/or priorities |
US20180048572A1 (en) * | 2016-08-09 | 2018-02-15 | Qualcomm Incorporated | Congestion control for lte-v2v |
US9942918B2 (en) * | 2012-02-11 | 2018-04-10 | Vid Scale, Inc. | Method and apparatus for video aware hybrid automatic repeat request |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6882624B1 (en) | 1998-04-09 | 2005-04-19 | Nokia Networks Oy | Congestion and overload control in a packet switched network |
US7385923B2 (en) | 2003-08-14 | 2008-06-10 | International Business Machines Corporation | Method, system and article for improved TCP performance during packet reordering |
US8549170B2 (en) | 2003-12-19 | 2013-10-01 | Nvidia Corporation | Retransmission system and method for a transport offload engine |
US7773576B2 (en) | 2007-02-27 | 2010-08-10 | Viasat, Inc. | Slotted Aloha congestion control |
WO2011064810A1 (en) | 2009-11-24 | 2011-06-03 | Skillupjapan Corporation | Method and apparatus for dynamically adapting the number of retransmissions |
ES2529304T3 (en) | 2010-10-29 | 2015-02-18 | Telefonaktiebolaget L M Ericsson (Publ) | Congestion control in a communication network |
US8396072B2 (en) | 2011-02-21 | 2013-03-12 | Renesas Mobile Corporation | Method and apparatus for channel traffic congestion avoidance in a mobile communication system |
-
2019
- 2019-10-07 US US16/594,961 patent/US10992583B1/en active Active
-
2020
- 2020-10-06 DE DE102020126153.5A patent/DE102020126153A1/en active Pending
- 2020-10-09 CN CN202011074325.6A patent/CN112636876A/en active Pending
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070070902A1 (en) * | 2005-06-21 | 2007-03-29 | Toshiba America Research, Inc. | An admission control for contention-based access to a wireless communication medium |
US20090225682A1 (en) * | 2006-04-04 | 2009-09-10 | Alex Peter Grote-Lopez | Optimization Procedure for Wireless Networks Operating in Infrastructure Mode with Standard Protocol IEEE 802.11 |
US9942918B2 (en) * | 2012-02-11 | 2018-04-10 | Vid Scale, Inc. | Method and apparatus for video aware hybrid automatic repeat request |
US20160057770A1 (en) * | 2014-08-22 | 2016-02-25 | Qualcomm Incorporated | Techniques for transmitting and receiving channel occupancy identifiers over an unlicensed radio frequency spectrum band |
US20170303159A1 (en) * | 2014-10-06 | 2017-10-19 | Vid Scale, Inc | Adapting communication parameters to link conditions, traffic types, and/or priorities |
US20170048880A1 (en) * | 2015-08-12 | 2017-02-16 | Blackberry Limited | Uplink resource scheduling control in response to channel busy condition |
US20180048572A1 (en) * | 2016-08-09 | 2018-02-15 | Qualcomm Incorporated | Congestion control for lte-v2v |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20220393806A1 (en) * | 2019-11-07 | 2022-12-08 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and device for determining transmission priority |
US20220164898A1 (en) * | 2020-11-26 | 2022-05-26 | National Tsing Hua University | Method and system for calculating total transmission probability within social network based on timing |
US11557006B2 (en) * | 2020-11-26 | 2023-01-17 | National Tsing Hua University | Method and system for calculating total transmission probability within social network based on timing |
Also Published As
Publication number | Publication date |
---|---|
CN112636876A (en) | 2021-04-09 |
DE102020126153A1 (en) | 2021-04-08 |
US10992583B1 (en) | 2021-04-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20200304244A1 (en) | Method and Apparatus for Feeding Back Hybrid Automatic Repeat Request of Downlink Data | |
CN110535555B (en) | Method, apparatus and computer readable storage medium for determining transmission priority | |
EP3550752B1 (en) | Method device and system for feedback | |
EP2567482B1 (en) | Method and system of transfering data in a carrier aggregation environment | |
CN108631950B (en) | Method and device for sending feedback information | |
US10992583B1 (en) | Opportunistic packet retransmissions | |
CN112653541B (en) | Communication method and device | |
US20220369296A1 (en) | Method and apparatus for transmitting downlink control information | |
CN114866204A (en) | Transmission method, terminal equipment and base station | |
CN110351757B (en) | Scheduling request transmission method, terminal and network side equipment | |
WO2022000318A1 (en) | Harq feedback transmission method, base station and user equipment | |
CN109716699B (en) | Method, network device and terminal device for hybrid automatic repeat request process | |
US20170054541A1 (en) | Discarding and Retaining Physical Data Channels | |
EP3203670A1 (en) | Method and apparatus for implementing a retransmission scheme | |
WO2018086707A1 (en) | Feedback based flexible transmission scheme for contention-based urllc transmission | |
US10003470B2 (en) | Method and terminal for transmitting and receiving data | |
WO2022151442A1 (en) | Resource conflict processing method and apparatus | |
WO2020220962A1 (en) | Sidelink transmission method and terminal | |
CN112134658B (en) | Method for transmitting feedback information, user equipment and access equipment | |
CN115428374A (en) | Combined blind and feedback-based retransmission | |
WO2023231910A1 (en) | Feedback information sending method, feedback information receiving method, terminal, and storage medium | |
CN109450602B (en) | Data transmission method and device and electronic equipment | |
Santos et al. | A performance study for the multicast collision prevention mechanism for IEEE 802.11 | |
CN109937548B (en) | Apparatus, method and computer program for unlicensed wireless communication | |
WO2023053108A1 (en) | Wireless data transmission system and method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: FORD GLOBAL TECHNOLOGIES, LLC, MICHIGAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:AHMAD, SYED AMAAR;VUKOVIC, IVAN;RAO, JAYANTHI;SIGNING DATES FROM 20190916 TO 20191001;REEL/FRAME:050644/0602 |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |