Cet article est lié au mode RLC AM. RLC ARQ est un mécanisme de retransmission. En fait, les trois couches de protocole différentes de NR, MAC (HARQ), RLC (ARQ) et PDCP ont toutes des fonctions de retransmission. Pourquoi les protocoles de couche 3 doivent-ils avoir une fonction de retransmission ? J'ai aussi réfléchi à ce problème au début.Voici un passage de 5G NR La technologie d'accès sans fil de nouvelle génération pour expliquer ce problème.
L'objectif du mécanisme HARQ au niveau de la couche MAC est d'obtenir une retransmission rapide. Par conséquent, une fois que l'UE reçoit le TB, il doit effectuer un retour HARQ ACK/NACK à la réception du DL. Pour la transmission UL, il n'y a pas de retour explicite mécanisme similaire à HARQ-ACK. , la raison principale est que dans le scénario UL, le côté réseau est à la fois le côté réception et l'extrémité de planification des données, et le côté réseau peut indiquer si l'UE doit retransmettre via le NDI dans le DCI . Bien que HARQ puisse atteindre une probabilité d'erreur très faible, HARQ se fait au prix d'un sacrifice des ressources de transmission. Dans certains cas, cette méthode n'est pas très éprouvée. Un exemple évident est le scénario de transmission de données ultra-fiable et à faible latence. Dans ce cas, il faut soit réduire le taux d'erreur de rétroaction, soit accepter le coût accru de la signalisation de retour, ou des retransmissions supplémentaires sont effectuées sans compter sur le signal de retour, mais cela réduit l'efficacité spectrale. Les faibles taux d'erreur ne sont pas seulement une préoccupation pour les services de type URLLC, mais sont également importants du point de vue du débit de données. Les débits de données élevés de TCP peuvent nécessiter que les paquets soient livrés à la couche TCP avec peu d'erreurs. Comme indiqué dans ACM/IEEE Trans TCP reno performance : un modèle simple et sa validation empirique133–145, pour des débits de données durables supérieurs à 100 Mbit/s, une probabilité de perte de paquets inférieure à 10^-5 est requise.
Par rapport à la confirmation HARQ, la fréquence de transmission du rapport d'état RLC est relativement faible et le coût d'obtention d'une fiabilité de 10^-5 ou moins est relativement faible. La combinaison des deux mécanismes de retransmission de HARQ et RLC ARQ peut obtenir l'effet d'un RTT suffisamment petit et d'une surcharge de rétroaction modérée, de sorte que les deux mécanismes se complètent. HARQ est responsable de la retransmission rapide et RLC ARQ est responsable de la transmission fiable de paquets de données réels .
Pourquoi PDCP a encore la fonction de retransmission ? La raison principale est que la retransmission PDCP est principalement utilisée dans les scénarios de transfert inter-gNB. Pendant le transfert, les paquets de données de liaison descendante non livrés seront transférés de l'ancien gNB au nouveau gNB via PDCP. Dans ce cas, une nouvelle entité RLC et une entité HARQ seront établies dans le nouveau gNB, de sorte que l'état RLC d'origine sera perdu. La fonction de retransmission PDCP peut garantir qu'aucun paquet de données n'est perdu pendant le processus de transfert. Dans UL, étant donné que le tampon HARQ sera actualisé pendant le transfert, l'entité PDCP de l'UE traitera tous les paquets de données UL qui n'ont pas été transmis au gNB auparavant.
Commençons par nous pencher sur le contenu spécifique de ce mode NR RLC AM.De plus, il y a plusieurs autres points de connaissance triviaux à la fin.
Expéditeur de transfert de données AM
L'expéditeur de l'entité AM RLC donnera la priorité à l'unité PDU de commande RLC. L'émetteur de l'entité AM RLC doit également donner la priorité à la transmission des PDU AMD contenant des SDU RLC ou des segments RLC SDU précédemment transmis (tels que des scénarios de retransmission), puis traiter les PDU AMD des nouveaux SDU RLC ou segments RLC SDU à transmettre.
L'extrémité émettrice de l'entité AM RLC doit maintenir la fenêtre d'envoi en fonction de TX_Next_Ack. La plage SN correspondant à la fenêtre d'envoi est [TX_Next_Ack, TX_Next_Ack+AM_Window_Size). Uniquement lorsque TX_Next_Ack est mis à jour, la fenêtre d'envoi sera mise à jour. Si TX_Next_Ack n'est pas mis à jour pendant une longue période (par exemple, le réseau ne peut pas recevoir d'accusé de réception positif sur le côté), après l'envoi du SN dans la fenêtre d'envoi, l'UE ne peut pas continuer à envoyer de nouvelles données, c'est-à-dire le blocage de la fenêtre.
Le mode AM TX_Next lui-même est une variable de l'état d'envoi, qui stocke la valeur SN de la prochaine PDU AMD nouvellement générée. Initialement défini sur 0, et mis à jour chaque fois que l'entité AM RLC construit une PDU AMD avec SN = TX_Next contenant une SDU RLC ou une SDU RLC du dernier segment. Après avoir reçu le RLC SDU du PDCP, l'entité AM RLC doit l'associer au SN du TX_Next actuel et définir le SN du PDU AMD nouvellement généré sur la valeur correspondant à TX_Next ; après cela, TX_Next +1 pointe vers le prochain SN à générer.
Cette méthode d'auto-incrémentation de TX_Next est principalement liée aux réglementations AM RLC SN. Pour AM RLC, sn est incrémenté en unités de RLC SDU, c'est-à-dire que chaque RLC SDU a un SN unique et qu'une RLC SDU doit être segmentée. Le SN de chaque segment suivant est le même que le SN RLC SDU d'origine.
Comme le montre la figure ci-dessus, le journal envoyé par SRB UL RLC est imprimé. L'UE a envoyé 6 PDU RLC, qui sont respectivement des SDU RLC avec SN = 3, 4, 5 et 6. Étant donné que l'octroi UL est insuffisant, le SDU RLC avec SN = 4 est divisé en trois segments , les informations de segment spécifiques peuvent être vues via SI, qui sont le premier segment, le segment du milieu et le dernier segment. Le champ SO derrière indique la position correspondante du premier octet de chaque Segment RLC SDU dans le RLC SDU d'origine Il y en a 3 Le SN du segment est tous les 4, tout comme la régulation d'auto-incrémentation TX_Next mentionnée ci-dessus.
Lors de la soumission d'une AMD PDU contenant un segment RLC SDU à la couche MAC, l'expéditeur de l'entité AM RLC doit définir le SN de l'AMD PDU sur le SN de la RLC SDU correspondante.
L'extrémité émettrice de l'entité AM RLC peut déterminer l'accusé de réception positif de la SDU RLC associée en recevant la PDU STATUS de l'entité AM RLC homologue (représentant que l'entité AM RLC homologue a reçu avec succès) :
Lors de la réception du RLC SDU ACK positif avec SN = x, l'expéditeur de l'entité AM RLC doit envoyer une indication de la livraison réussie du RLC SDU au PDCP ; incrémenter TX_Next_Ack dans l'ordre et le régler sur le plus petit RLC SDU actuel qui n'a pas reçu ack SN, ce SN doit être dans la plage de [TX_Next_Ack, TX_Next].
Par exemple, TX_Next_Ack = 1 TX_Next = 7, seuls SN 2 et 4 ont reçu un accusé de réception positif, puis ont reçu un accusé de réception positif de SN 1 et 5 via le STATUS PDU de l'homologue, UE a envoyé SN = 7 RLC AMD PDU, puis mettez à jour la fenêtre d'envoi, le limite inférieure de la nouvelle fenêtre d'envoi TX_Next_Ack=3, et TX_Next=8.
Récepteur de transfert de données AM
L'extrémité de réception de l'entité AM RLC maintiendra une fenêtre de réception selon RX_Next, et la plage de la fenêtre de réception correspond à [RX_Next, RX_Next+AM_Window_Size). Lors de la réception d'un PDU AMD du MAC, l'extrémité de réception de l'entité AM RLC rejettera le PDU AMD reçu ou le placera dans le tampon de réception en fonction de la scène ; pour le PDU AMD dans le tampon de réception, il mettra à jour la variable d'état et définira Le PDU AMD est réassemblé et transmis au PDCP, et démarre/arrête le t-réassemblage selon les besoins. Lorsque t-Reassembly arrive à expiration, le récepteur de l'entité AM RLC doit mettre à jour les variables d'état correspondantes et démarrer t-Reassembly si nécessaire.
Ce mécanisme de fenêtre piloté par la limite inférieure RX_Next est ce que l'on appelle la fenêtre push ; et le mécanisme de mise à jour de la fenêtre de réassemblage piloté par la limite supérieure RX_Next_Highest à l'extrémité de réception du mode UM est ce que l'on appelle la fenêtre pull. L'utilisation de différents mécanismes est principalement déterminée par leurs caractéristiques respectives. Par exemple, UM considère plus les performances en temps réel, et AM considère plus la fiabilité.
Lorsque l'extrémité de réception AM reçoit l'AMD PDU du MAC, elle doit prendre une décision afin d'éliminer les données inutiles, de mettre les données utiles dans la mémoire tampon, puis de réorganiser les données et de les transmettre au PDCP. Le processus principal impliqué est la comparaison entre le SN recevant le PDU AMD et la variable d'état de la fenêtre de réception.
Lorsque AMD PDU est reçu de MAC
Lorsque le PDU AMD est reçu du MAC, le PDU AMD contient le numéro de segment y ~ z du SDU RLC avec SN = x, et l'extrémité réceptrice de l'entité AM RLC doit le traiter comme suit :
(1) Si x tombe en dehors de la fenêtre de réception ou si le numéro de segment y ~ z de la SDU RLC avec SN=x a été reçu auparavant, rejetez la PDU AMD reçue.
(2) Dans d'autres cas, placez le PDU AMD reçu dans la mémoire tampon de réception ; si certains segments ont déjà été reçus, supprimez les segments en double.
Lorsqu'il y a AMD PDU dans le tampon de réception
Pour les PDU AMD placés dans le tampon de réception avec SN = x,
(1) Si x >= RX_Next_Highest, mettre à jour RX_Next_Highest à x+ 1.
(2) Si tous les octets de SN = x RLC SDU sont reçus, réassemblez l'AMD PDU avec SN = x dans RLC SDU, supprimez l'en-tête RLC et transmettez la RLC SDU réassemblée au PDCP ;
Si x = RX_Highest_Status à ce moment, mettre à jour RX_Highest_Status au premier SN qui est supérieur au RX_Highest_Status actuel et n'a pas reçu toutes les SDU RLC ; si x = RX_Next à ce moment, mettre à jour RX_Next au premier SN qui est supérieur au RX_Next actuel et n'a pas reçu tous les mots SN du RLC SDU de la strophe.
Par exemple, initialement RX_Next=1 RX_Next_Highest=7, le jaune représente le SN reçu, le vert représente le SN incomplet, le segment de SN=7 AMD PDU a été reçu, mais le PDU avec SN=1 n'a pas encore été reçu, le suivant l'étape est RX_Next_Highest= 8.
Si initialement RX_Next=1, RX_Next_Highest=7, RX_Highest_Status=1, SN 2 et 4 ont été reçus à ce moment ; le segment de AMD PDU avec SN=7 a été reçu, et l'AMD PDU avec SN=1 a également été reçu A ce moment, RX_Next = 3, RX_Next_Highest = 8, RX_Highest_Status = 3, puisque RX_Next = 3, la fenêtre de réception AM a avancé de 2 SN.
t-Remontage
Si t-Reassembly est en cours d'exécution, si RX_Next_Status_Trigger = RX_Next ou RX_Next_Status_Trigger = RX_Next + 1 (à ce moment, RX_Next correspond au SDU du SN et il n'y a pas de segment manquant avant la réception du dernier octet du segment) ou
Si RX_Next_Status_Trigger tombe en dehors de la fenêtre de réception et que RX_Next_Status_Trigger n'est pas égal à RX_Next + AM_Window_Size, arrêtez et réinitialisez t-Reassembly.
RX_Next_Status_Trigger correspond à la variable d'état t-Reassembly, qui stocke le prochain SN du RLC SDU SN qui déclenche le t-Reassembly.
La figure ci-dessus correspond aux trois scénarios où le t-Reassembly doit être arrêté et réinitialisé pendant l'exécution du t-Reassembly.
Si t-Reassembly n'est pas en cours d'exécution (y compris t-Reassembly arrêté en raison des opérations ci-dessus), si RX_Next_Highest > RX_Next + 1 ou RX_Next_Highest = RX_Next + 1 (à ce moment, toutes les SDU correspondant à RX_Next correspondant à SN reçoivent au moins un octet avant que le dernier octet du segment 1 octet ne soit manquant), il est nécessaire d'activer t-Reassembly et de définir RX_Next_Status_Trigger sur RX_Next_Highest.
Comme indiqué dans la scène ci-dessus, t-Reassembly n'est pas en cours d'exécution, RX_Next_Highest > RX_Next +1, à ce moment, mettez à jour RX_Next_Status_Trigger à la position de RX_Next_Highest=7.
t-Reassembly timeout
Si t-Reassembly expire, mettez à jour RX_Highest_Status au premier RLC SDU SN qui est supérieur ou égal à RX_Next_Status_Trigger et qui n'a pas été entièrement reçu ;
Si RX_Next_Highest>RX_Highest_Status +1 ou RX_Next_Highest=RX_Highest_Status+1 (à ce moment, au moins 1 segment d'octet est manquant avant le dernier octet de toutes les SDU correspondant à RX_Highest_Status recevant le segment), démarrez t-Reassembly et définissez RX_Next_Status_Trigger sur RX_Next_Highest.
Comme indiqué ci-dessus, si RX_Next_Highest >RX_Highest_Status +1, vous devez activer le t-Reassembly, puis mettre à jour RX_Next_Status_Trigger à la position RX_Next_Highest=7.
Si RX_Next_Highest = RX_Highest_Status + 1, où RX_Highest_Status correspond à SN 6, au moins 1 segment d'octet est manquant avant le dernier octet de tous les segments SDU reçus, t-Reassembly doit être activé, puis RX_Next_Status_Trigger doit être mis à jour sur RX_Next_Highest=7.
Procédures ARQ
Les procédures ARQ (demande de répétition automatique) sont uniques à l'entité AM RLC, et ni UM ni TM n'ont ARQ.
La retransmission des PDU perdues est également l'une des principales fonctions du mode RLC AM. La plupart des erreurs peuvent être gérées par HARQ, et ARQ est un mécanisme de retransmission de second niveau en complément de HARQ. L'extrémité réceptrice AM RLC peut vérifier le nombre de PDU reçues et, si des PDU sont perdues, elle peut demander à l'extrémité émettrice homologue de retransmettre les données correspondantes via le rapport STATUS.
Voyons comment ARQ retransmet.
L'extrémité émettrice de l'entité AM RLC peut recevoir la PDU STATUS de l'entité AM RLC à l'extrémité opposée, puis déterminer s'il existe une situation dans laquelle certaines SDU ou certains segments RLC ne parviennent pas à être reçus à l'extrémité réceptrice RLC à l'extrémité opposée. .
Lorsqu'un NACK est reçu, si le SN de la RLC SDU correspondant au NACK tombe dans la plage de TX_Next_Ack <= SN <= la valeur maximale AMD PDU SN envoyée à la couche MAC, la RLC SDU ou le segment correspondant au SN de le NACK sera signalé au pair Faire une retransmission. La description de ce paragraphe est le processus général d'ARQ.
Pour que la SDU ou le segment RLC soit retransmis, si la SDU ou le segment RLC est retransmis pour la première fois, initialisez le RETX_COUNT associé à la SDU RLC à 0 ; si la SDU ou le segment RLC correspondant est envoyé, mais dans la PDU STATUS Si NACK est reçu à nouveau, RLC retransmettra à nouveau et RETX_COUNT++ sera défini à ce moment.
Chaque SDU RLC maintiendra un compteur RETX_COUNT ; si RETX_COUNT = maxRetxThreshold, cela indiquera que la couche supérieure a atteint la retransmission maximale, ce qui entraînera rlc max numRetx et conduira à RLF.
Lors de la retransmission du RLC SDU ou du segment, selon la taille d'attribution UL fournie par la couche MAC, l'UE peut segmenter le segment RLC SDU ou RLC SDU (par exemple, lorsque l'attribution UL n'est pas suffisante pour envoyer) et générer un nouveau que le MAC est suffisant pour envoyer AMD PDU, remis à la couche MAC.
Lors de la formation d'un nouveau PDU AMD, l'expéditeur de l'entité AM RLC ne mappera que le segment RLC SDU ou RLC SDU d'origine sur le champ Données du nouveau PDU AMD et définira l'en-tête du nouveau PDU AMD en fonction de la situation spécifique.
Vote
L'extrémité émettrice de l'entité AM RLC peut demander à l'entité RLC homologue d'envoyer un rapport STATUS par interrogation, afin de connaître la situation d'accusé de réception du RLC SN homologue, de retransmettre ou de mettre à jour la fenêtre d'envoi et de définir spécifiquement le bit p dans la PDU AMD envoyée est 1, et les scénarios spécifiques sont les suivants.
Une fois que la couche MAC a notifié l'opportunité de transmission, pour chaque PDU AMD soumise pour transmission, si elle contient une SDU ou un segment RLC non transmis, alors l'expéditeur de l'entité AM RLC doit ajouter PDU_WITHOUT_POLL +1 ; ajouter BYTE_WITHOUT_POLL au champ de données AMD PDU Le nouveau octet transmis ;
Si PDU_WITHOUT_POLL >= pollPDU ou BYTE_WITHOUT_POLL >= pollByte, un bit d'interrogation doit être inclus dans l'AMD PDU.
Après notification de l'opportunité de transmission par la couche MAC, pour chaque AMD PDU soumis à transmission,
Si la nouvelle transmission et le tampon de retransmission sont vides (à l'exception du RLC SDU envoyé ou du segment en attente d'accusé de réception) ; ou après la transmission du PDU AMD, il n'y a pas de nouveau RLC SDU à transmettre (par exemple, la fenêtre de transmission est pleine, ne peut pas continuer à envoyer de nouvelles SDU RLC et doit mettre à jour TX_Next_Ack avant d'envoyer de nouvelles SDU RLC. À ce stade, le rapport STATUS de l'extrémité opposée est requis. À ce stade, un sondage doit être inclus dans la PDU AMD.
La façon d'inclure le sondage dans AMD PDU consiste à définir le champ P de AMD PDU sur « 1 », puis de définir PDU_WITHOUT_POLL et BYTE_WITHOUT_POLL sur 0 pour la génération de sondage ultérieure.
Après avoir soumis le PDU AMD contenant le sondage à la couche MAC, l'expéditeur de l'entité AM RLC doit définir POLL_SN sur la valeur SN la plus élevée dans le PDU AMD soumis à la couche MAC ; si t-PollRetransmit n'est pas en cours d'exécution, démarrez t-PollRetransmit, sinon il redémarrera t-PollRetransmit.
Après avoir reçu le rapport STATUS de l'entité homologue RLC AM, si le rapport STATUS contient ack ou nack du RLC SDU correspondant à POLL_SN, arrêtez et réinitialisez t-PollRetransmit (si t-PollRetransmit est en cours d'exécution).
Après l'expiration de t-PollRetransmit, si les nouveaux tampons de transmission et de retransmission sont vides (à l'exception du RLC SDU envoyé ou du segment en attente de confirmation ); ou après la transmission du PDU AMD, il n'y a pas de nouveau RLC SDU à transmettre (par exemple, la fenêtre d'envoi est pleine et bloquée), soumettez le SN le plus élevé au MAC pour retransmission, ou retransmettez toute RLC SDU qui n'a pas reçu d'accusé de réception. Dans ce cas, une interrogation doit également être incluse dans l'AMD PDU et un rapport STATUS doit être envoyé à l'homologue. Après tout, l'expéditeur de l'UE a déjà demandé le rapport STATUS de l'homologue via le sondage, mais l'UE continuera à demander le délai d'attente t-PollRetransmit correspondant ; on peut voir que pendant le fonctionnement de t-PollRetransmit, le sondage ne peut pas être déclenché plusieurs fois. Après t-PollRetransmit timeout , pour créer un nouveau processus d'interrogation.
Regardons d'abord un exemple de réception RLC AM DL. Le journal est un scénario VONR. Généralement, les scénarios vocaux accordent plus d'attention aux performances en temps réel et utilisent le mode RLC UM, mais il y a des exceptions. À l'ère LTE, il y avait des cas où la voix utilisait le mode RLC AM lorsque l'état du réseau était bon. Il n'y a pas de problème dans la situation et l'état du réseau est médiocre. L'exemple suivant correspond à la situation où la voix utilise le mode RLC AM dans le scénario 5G. Il suffit de prendre un regarder.
Au début, la session PDU 2 est établie, et sa configuration associée à qfi 4 est utilisée pour la transmission de signalisation IMS (5qi=5), correspondant au DRB5 LCID 5, mode AM.
La figure ci-dessus est l'impression des paramètres de configuration RLC pertinents dans RRCReconfiguration.
Ensuite, passez un appel VONR, configurez qfi 7 pour la transmission vocale, correspondant au mode DRB6 LCID 6, RLC AM.
La figure ci-dessus est l'impression des paramètres de configuration DRB RLC voix pertinents dans RRCReconfiguration.
Après cela, vous pouvez voir les changements des 4 paramètres de l'expéditeur du mode RLC AM. RX_Next est toujours égal à RX_Next_Highest, c'est-à-dire que tous les PDU RLC actuels sont reçus et transmis à PDCP, ce qui correspond à la meilleure condition de réception, similaire à celle illustrée dans la figure ci-dessous.
Ce qui précède est un exemple de réception DL en mode RLC AM normal. Comme pour les autres cas, il est nécessaire de modifier les quatre paramètres de l'émetteur en mode RLC AM. La situation spécifique est analysée en détail, je ne donnerai donc pas d'exemples ici.
Examinez un autre problème UL. Lorsque l'UE envoie RRCSetup Complete, l'UL RLC n'a pas reçu le sn ack, ce qui entraîne le nombre maximal de retransmissions, provoquant RLF. Examinons le processus lié à RLC dans le journal.
Configurez SRB1 dans la configuration RRC, et le RRCSetup Complete suivant sera envoyé via SRB1. Puisqu'il n'y a pas de paramètres de niveau RLC configurés dans la configuration RRC, la configuration par défaut de SRB1 dans 38.331 doit être appliquée à ce moment, comme indiqué dans les paramètres correspondants. dans la case orange ci-dessus.
Ensuite, vous pouvez voir la configuration des paramètres pertinents de SRB1 RLC à travers la figure ci-dessus, telle que longueur sn = 12 bits, seuil max retx = 8, etc. Après cela, l'entité RLC envoie AMD PDU avec SN = 0, TX_Next_Ack = 0, indiquant qu'il attend. Le côté réseau répond avec l'accusé de réception de sn=0 via le rapport STATUS, et TX_Next=1 représente le SN de la prochaine PDU AMD nouvellement générée. Grâce à l'en-tête RLC ci-dessus SN = 0 SI = 00, on peut voir que le PDU AMD correspondant au SN = 0 envoyé est un SDU RLC complet ; via P = 1, cela signifie qu'il existe un rapport d'état d'interrogation ; via NEW_TX /RE_TX/RE_TX/RE_TX, vous pouvez voir Tant que l'UE n'a pas retransmis le PDU avec SN = 0, RE_TX est imprimé 8 fois dans le journal, ce qui correspond au seuil max retx = 8, puis RLF est déclenché avec RLCUL MAX RETX .
Grâce à l'impression de RLC UL Stats, on peut également voir que 8 fois de PDU Retx ont été effectuées et qu'un pdu d'état n'a pas été reçu au cours de la période ultérieure, c'est-à-dire qu'aucun rapport STATUS n'a été reçu.
Enfin, faites attention à la raison pour laquelle lorsque le premier nouveau tx sn = 0, l'en-tête RLC a P (bit d'interrogation) = 1, c'est-à-dire que le rapport d'état est demandé. La condition de jugement la plus impressionnante pour déclencher l'interrogation est liée à pollPDU et pollBYTE. Plus précisément, si PDU_WITHOUT_POLL >= pollPDU ou BYTE_WITHOUT_POLL >= pollByte, un bit d'interrogation doit être inclus dans l'AMD PDU. Cependant, la configuration par défaut pollPDU=pollBYTE=infinity de SRB1 dans 38.331 est évidemment impossible à déclencher par la condition ci-dessus, alors que peut-on déclencher d'autre ? En parcourant 38.322, j'ai finalement trouvé la condition la plus facilement négligée pour déclencher l'interrogation :
"Si les tampons de transmission et de retransmission sont vides (à l'exclusion du RLC SDU envoyé ou du segment en attente d'accusé de réception ); ou lorsqu'aucun nouveau RLC SDU ne peut être transmis après la transmission du PDU AMD (comme le blocage de la fenêtre), il est temps de inclure un sondage dans le PDU AMD." Le P=1 dans le journal est évidemment déclenché par la condition que le tampon de transmission précédent et le tampon de retransmission sont vides, et après que l'UE envoie le PDU avec SN=0, il n'y a rien Après tout, dans ce scénario, l'UE n'a besoin d'envoyer que RRCSetup Complete, et le reste est l'accusé de réception indiqué par la PDU STATUS de l'expéditeur AM RLC et du récepteur AM RLC pair.
Voyons ensuite dans quelles circonstances le récepteur d'entité AM RLC doit effectuer un rapport STATUS et comment construire une PDU STATUS.
Rapport d'état
STATUS PDU se compose d'une charge utile STATUS PDU et d'un en-tête PDU de contrôle RLC. L'en-tête PDU de commande RLC se compose des champs D/C et CPT. La position de départ de la charge utile STATUS PDU commence à partir du premier bit après l'en-tête PDU de contrôle RLC. Il se compose d'un ACK_SN et d'un E1, et de zéro ou plusieurs NACK_SN et d'un E1, d'un E2 et d'un E3. Parfois, il peut également y avoir un paire de champs de plage SOstart et SOend ou NACK pour chaque NACK_SN. Selon le scénario de NACK_SN, les champs requis ci-dessus sont également différents et une analyse spécifique est requise pour des situations spécifiques.
L'entité AM RLC enverra un STATUS PDU à l'entité homologue AM RLC, de manière à fournir l'accusé de réception et le non-accusé de réception de son RLC SDU (ou segment) à l'expéditeur RLC homologue.
Les conditions qui déclenchent le rapport STATUS sont les suivantes :
(1) Lors de la réception de l'AMD PDU avec SN = x de l'extrémité homologue et champ P = 1 de la couche MAC, l'entité de réception AM RLC juge d'abord si l'AMD PDU doit être rejetée conformément aux réglementations ci-dessus lors de la réception du AMD PDU de la couche MAC, puis Pour déclencher un rapport STATUS pour empêcher l'homologue de continuer à envoyer des PDU AMD en double ;
Si x < RX_Highest_Status ou x >= RX_Next + AM_Window_Size, le rapport STATUS sera déclenché ;
Dans les autres cas, retardez le déclenchement du rapport STATUS jusqu'à ce que x < RX_Highest_Status ou x>= RX_Next + AM_Window_Size.
Il convient de noter que le rapport RLC STATUS ne peut être transmis qu'après la réorganisation HARQ, c'est-à-dire que la retransmission des données sous-jacentes du niveau HARQ est effectuée en premier et que le retour d'état du niveau RLC est lancé une fois l'opération HARQ terminée. deux mécanismes de rétroaction sont combinés, et le travail n'est pas fatigant.
(2) Lorsqu'il est détecté qu'il y a un échec de réception AMD PDU, si t-Reassembly expire également à ce moment, l'extrémité de réception de l'entité AM RLC devrait également déclencher un rapport STATUS. Le délai d'attente de t-Reassembly entraînera la mise à jour de RX_Highest_Status et le déclenchement du rapport STATUS. Les deux sont traités séquentiellement. Le rapport STATUS doit être déclenché après la mise à jour de RX_Highest_Status.
Lorsque le rapport STATUS est déclenché, si t-StatusProhibit n'est pas en cours d'exécution, lorsque la couche MAC indique qu'il existe une opportunité de transmission, le récepteur AM RLC construira une PDU STATUS et la soumettra à la couche inférieure pour transmission ; Une opportunité de transmission à construire une seule PDU STATUS basée sur la situation actuelle (même si plusieurs rapports STATUS sont déclenchés pendant l'opération t-StatusProhibit) et la soumettre à la couche inférieure.
Lorsqu'une unité PDU STATUS est soumise à la couche MAC, l'extrémité de réception AM RLC doit lancer immédiatement t-StatusProhibit.
Lors de la construction d'une PDU STATUS, l'entité AM RLC doit :
Pour les SDU RLC dont le SN est RX_Next <= SN < RX_Highest_Status, les segments dans le RLC SDU du même SN sont dans l'ordre croissant des octets ; les RLC SDU de différents SN sont dans l'ordre croissant du SN, et le STATUS PDU généré à partir du SN =RX_Next , jusqu'à ce que suffisamment d'octroi UL actuel soit envoyé :
(1) Pour la SDU RLC qui n'a reçu aucun segment d'octet, régler son SN sur NACK_SN et l'inclure dans la PDU STATUS ;
(2) Si un segment d'une certaine RLC SDU a des octets continus non reçus, régler son SN sur NACK_SN, et exprimer la partie non reçue via SOstart et SOend ;
(3) Pour les SDU RLC complets continus qui n'ont pas été reçus, définissez leur SN sur NACK_SN et utilisez la plage NACK pour indiquer les SDU RLC non reçues. Si nécessaire, une paire de SOstart et SOend peut être incluse dans le STATUS PDU.
Définissez ACK_SN sur le SN qui n'est pas indiqué comme perdu dans la PDU STATUS, et ce SN correspond au SN de la prochaine RLC SDU qui n'est pas reçue.
En prenant le PDU SN STATUS 12 bits comme exemple, voyons comment remplir les champs spécifiques. Si la fenêtre de réception de l'extrémité de réception RLC est comme ci-dessus, alors ACK_SN=8 ; parmi eux, aucun des SDU RLC avec SN= 1 a été reçu et le contenu du rapport STATUS correspond à la police bleue Partial ; SN=2 La partie médiane n'est pas reçue, le contenu du rapport STATUS correspond à la partie de police verte, SOstart=X et SOend=Y indiquent la partie médiane manquante de SN = 2 ; SN = 5,6,7,5 Reçu Dans la première moitié, 6 n'a pas été reçu du tout et 7 a été reçu dans la seconde moitié. Le contenu du rapport STATUS correspond à la partie en violet SOstart=W et SOend=Z représentent la plage de SN 5~7 consécutifs manquants. Grâce au contenu du rapport STATUS ci-dessus, l'extrémité émettrice homologue peut savoir que l'extrémité réceptrice actuelle de l'UE SN = 3 et 4 a été reçue, et quelles parties du SN non reçu 1, 2, 5, 6, 7 n'ont pas été reçues. , puis L'expéditeur pair peut organiser la retransmission correspondant au SN.
Procédures de rejet de SDU
Lorsque le PDCP indique qu'une SDU RLC spécifique doit être rejetée, si la SDU RLC pertinente ou son segment n'est pas soumis au MAC, l'expéditeur RLC AM doit rejeter la SDU RLC correspondante. Lors du rejet de la RLC SDU, l'expéditeur RLC ne doit pas introduire l'écart RLC SN, c'est-à-dire que si la SDU à envoyer avec SN=3 doit être rejetée, remplacer la SDU à envoyer ultérieurement par SN=3 et continuer à envoyer dans l'ordre croissant du numéro SN pour empêcher l'apparition de l'écart SN afin d'éviter le problème qui peut provoquer le blocage de la fenêtre de réception RLC de l'extrémité opposée.
Calcul du volume de données
Lorsque l'UE exécute MAC BSR, il estime le volume de données afin que le réseau puisse allouer suffisamment d'allocations UL après avoir reçu le BSR. Le volume de données RLC comprend les parties suivantes :
(1) RLC SDU et segment RLC SDU non encore inclus dans la PDU de données RLC ;
(2) PDU de données RLC en attente de transmission initiale;
(3) PDU de données RLC (RLC AM) en attente de retransmission.
De plus, si la PDU STATUS a été déclenchée et que t-StatusProhibit ne fonctionne pas ou a expiré, l'UE doit évaluer la taille de la PDU STATUS à transmettre lors de la prochaine opportunité de transmission et la considérer comme faisant partie du volume de données RLC. .
Si la PDU RLC reçue contient une valeur réservée ou invalide, l'UE doit rejeter cette PDU RLC. Par exemple, si le champ RLC STATUS PDU CPT reçu a une valeur de 001, l'UE doit rejeter la RLC STATUS PDU à ce moment.