NR RLC(三) TM および UM モード

実際のネットワーク上の VOLTE 通話では、無音または断続的な通話が発生することがよくあります。通常は、MO/MT の UL 送信と DL 受信をチェックして、問題の原因をさらにトラブルシューティングします。モデムは RLC 送受信ステータスのチェックを避けることができず、音声設定 一般的には RLC UM モードですが、まれに AM モードとして設定されている場合も見られ、VONR も同様の状況です。LTE RLC 36.322 UM RLC の受信側および送信側の規制の説明と組み合わせて、LTE RLC を確認することで、UE の tx/rx の問題をより直観的に理解できます。これは、NR RLC (1) および (2) で多かれ少なかれ言及されています。 ) LTE と NR RLC にはいくつかの違いがありますが、VONR に無音または断続的な問題が発生した場合、NR RLC を通じて問題を直感的に確認できますか? NR RLC UM モードの送信状況は実際のログとどのように対応しますか? NR RLC UM モードのプロセスに焦点を当てましょう。この記事の主な内容は、RLC UM モードの具体的なプロセスに加えて、RLC TM モード、RLC エンティティの確立、再構築および解放プロセス、そして最後に NR RLC UM モード ログの簡単な分析プロセスの説明です。まず、RLC エンティティの確立、再構築、および解放のプロセスを見てください。

1f0e092cc8e342f099345f1b57561ba0.png

 上位層がRLCエンティティの確立を要求する場合、UEはRLCエンティティを確立し、RLCエンティティに対応する状態変数を初期値に設定し、設定に従って対応するデータ送信を実行する必要がある。

サイドリンク シナリオでは、TM は SBCCH に使用され、AM と UM の両方がユニキャスト送信に使用できます。UM はブロードキャストおよびグループキャスト送信に使用できますが、一方向送信のみです。

NR サイドリンク グループキャストおよびブロードキャストの場合、最初の UMD PDU が LCID のソース レイヤ 2 ID と宛先レイヤ 2 ID のペアから受信されたが、RLC エンティティを受信する対応する RB がない場合、UE は受信 RLC エンティティを確立する必要があります。 RLC エンティティの状態変数を初期値に設定し、対応するデータ送信を実行します。SL-SRB0 および SL-SRB1 の受信 RLC エンティティは、NR サイドリンク グループキャストおよびブロードキャストに使用できます。 

 

RLC エンティティの再設立

7734720de2304192b0e65e646350d426.png

 上位層が RLC エンティティの再確立を要求すると、UE はすべての RLC SDU、RLC SDU セグメント、および RLC PDU (存在する場合) を破棄し、すべてのタイマーを停止してリセットし、すべての状態変数を初期値にリセットします。

どのような状況で RLC エンティティが再確立されるのでしょうか? T300 タイムアウト、RRC 再確立プロセスなど、38.331 のコンテンツをフィルタリングすることで知ることができる多くのシナリオがありますが、これまであまり注目されていなかったシナリオ、つまり reestablishRLC の設定があります。が続きます。

ディー8d74f111e4a14b78506cd7d0959db.png

 reestablishRLC が設定されている場合、UE が RLC を再確立する必要があることを示します。少なくともネットワークは、RLC エンティティに関連付けられた無線ベアラーに使用されるセキュリティ キーが変更されるたびに、これを true に設定します。SRB2 および DRB の場合、完全な設定が使用されない限り、RRC 接続の再開中または再確立後の最初の再設定中にも true に設定されます。SRB1 の場合、RRC 接続が復元されたとき、または RRC 接続が再確立された後の最初の再構成時に、ネットワークはこのフィールドを true に設定しません。

149e723cb6624c6ca5d2e1c0f1fb6277.png

 そして、fullConfig は RRCReconfiguration または RRCResume に表示され、fullConfig はシステム内 Intra-RAT HO に適用されるフル コンフィギュレーションに対応します。E-UTRA から NR への inter-RAT HO の場合、fullConfig はソース RAT からの SDAP/PDCP デルタ シグナリングが適用可能かどうかを示します。DAPS ベアラが設定されている場合、または RRCReconfiguration メッセージが SRB3 で送信され、別の LTE RRCReconfiguration メッセージ内の SRB1 上の SCG の RRCReconfiguration メッセージに含まれている場合、このフィールドは存在しません。

60ff37ac8c0244e196569e02164f18cf.png

 上位層が RLC エンティティの解放を必要とする場合、UE はすべての RLC SDU、RLC SDU セグメント、および RLC PDU (存在する場合) を破棄し、RLC エンティティを解放する必要があります。

以下は TM と UM モードの内容です。主に UM であり、TM モードについては言うことはありません。

 

TMデータ転送

c371a3c4b1b14038863dfaeaa2a18181.png

 新しい TM PDU を MAC 層に渡すとき、TM RLC エンティティの送信側は MAC に変更を加えずに RLC SDU を渡す必要があり、MAC 層から新しい TMD PDU を受信するとき、TM RLC エンティティの受信側は RLC SDU を渡す必要があります。 TMD PDU は変更せずに PDCP に渡されます。TM モードでは、RLC タスクは小さく、何もする必要はなく、データを破棄するだけです。

TM モードと比較すると、UM モードにはより多くのコンテンツ、特に受信側の操作が含まれますが、AM モードよりもはるかに複雑ではありません。

 

データ転送

差出人

1eae94ef074a41b1b3fe97fc9a62dc7f.png

 UM RLCエンティティの送信者がUMD PDUをMACに渡すとき、UMD PDUがRLC SDUのセグメントに対応する場合、TX_Next=UMD PDUのSNである。

UMD PDU に含まれるセグメントが RLC SDU の最後のバイトである場合、つまり、現在の RLC SDU が送信されている場合、TX_Next++。

前回の記事 TX_Next で説明したように、RLC SDU のセグメントのみが SN を持ち、TX_Next は RLC SDU セグメントの SN を指し、Tx_Next は順番に増加し、RLC SDU セグメントが順番に増加することを表します。その理由は、NR RLC が再順序付けを実行する必要がなくなり、再順序付けが NR PDCP に配置されることです。また、RLC SDU のセグメントに SN が含まれている必要がある理由も、主に、RLC が RLC SDU を配信する前に再組み立てする必要があるためです。 PDCP のため、後続の再編成操作のためにセグメントに SN を追加する必要があります。

また、前の記事の法ベースで説明したように、SN が反転していることに注意してください。たとえば、12 ビット SN、SN 値の範囲は [0, 4095] で、SN が 4095 に達すると、次の値は 0 になります。 、それがSNフリップです。

 

受信側

fe8bdbbd89de47689de1057357d0b919.png

 UM RLCエンティティの受信端は、RX_Next_Highestに従って再組立ウィンドウを維持する必要があり、再組立ウィンドウのサイズは、[RX_Next_Highest−UM_Window_Size、RX_Next_Highest)に対応する。

UM RLC エンティティの受信側が MAC 層から UMD PDU を受信すると、RLC ヘッダーを削除した後、対応する UMD PDU を PDCP に渡すか、UMD PDU が受信バッファーに配置されている場合は破棄するか、受信バッファーに配置することができます。受信した UMD PDU がある場合、関連する状態変数を更新し、再アセンブルして PDCP にアップロードし、必要に応じて t-Reassembly を有効または停止する必要があります。

t-Reassembly がタイムアウトすると、UM RLC エンティティの受信側は関連する状態変数を更新し、RLC SDU セグメントを破棄し、必要に応じて t-Reassembly を有効にする必要があります。

 

UM受信機の具体的な処理を見てみましょう。

MAC から UM PDU を受信したとき

bdf67514473840ff8232d21cd740df84.png

 UE が MAC 層から UMD PDU を受信すると、UM RLC エンティティの受信側は何らかの処理を行う必要があります。

(1) UMD PDU ヘッダーに SN が含まれていない場合、RLC ヘッダーを直接削除し、RLC SDU を PDCP に送信します。

(2) UMD PDU ヘッダーに含まれる SN が [RX_Next_Highest-UM_Window_Size, RX_Next_Reassembly) 区間にある場合、RX_Next_Reassembly よりも前の SN が再構成プロセスを完了しているため、再度受信しても無駄であるため、受信した UMD PDU は破棄; それ以外の場合 受信バッファに入れて、対応する RLC SDU のすべてのセグメントが後で受信されるのを待ってから、再組み立てします。

ここでの SN の処理方法は、主に UM RLC SN の規定に関連しています。前述したように、UMD PDU は SN を持たない可能性があり、具体的な理由も前述しました。UM RLC の場合、セグメント RLC SDU のみが SN を持ち、SN は完全な RLC SDU には SN がありません。したがって、UM RLCエンティティ受信端がデータを処理するとき、UM PDUがSNを持たない状況を考慮する必要がある。

 

受信バッファにUMD PDUがある場合

0d25b6b03a644e87b7901efe6fbd38d2.png

 受信バッファに配置された UMD PDU の SN=x について、UM RLC エンティティの受信側は状況に応じて処理する必要があります。

(1) SN=x のすべてのバイト セグメントが受信された場合、RLC SDU を再組み立てし、RLC ヘッダーの削除操作を実行して、それを PDCP に渡します。この時点で x がたまたま = RX_Next_Reassembly である場合は、RX_Next_Reassembly を次のセグメントに設定します。まだ再構築を完了した SN の値。

(2) その他の場合、再構成ウィンドウのサイズは [RX_Next_Highest-UM_Window_Size, RX_Next_Highest) に対応します、つまり、上記の境界 RX_Next_Highest が駆動要因であり、RX_Next_Highest の更新により再構成ウィンドウが変更されます。 x が再アセンブリ ウィンドウを超えている場合、RX_Next_Highest の値を x +1 に設定し、再アセンブリ ウィンドウ内の SN に対応しない UMD PDU を破棄します。RX_Next_Reassembly が再アセンブリ ウィンドウ内にない場合は、RX_Next_Reassembly を大きい方の最初の SN に設定します。 (RX_Next_Highest-UM_Window_Size) 以上であり、再アセンブリはまだ完了していません。

上記の説明から、UM 受信ウィンドウは、受信した UMD PDU SN に応じて RX_Next_Highest を更新することがわかり、受信ウィンドウが変更された後、一部の SN が受信されない場合がありますが、それでも破棄する必要があります。

bc92091e484449e199dca4430070ae52.png

 たとえば、UM_Window_Size=6、現在の RX_Next_Highest=7 の場合、UM 受信機によって現在受信されている SN は 1 ~ 6 で、そのうち SN=3 と 4 はまだ受信されていないため、RX_Next_Reassembly=3; 次に受信される UMD PDU SN の場合、 = 9、その後、再組み立てウィンドウを更新、新しい RX_Next_Highest=10、新しい再組み立てウィンドウの SN は 4 ~ 9、そのうち 4/7/8 は受信されていない、RX_Next_Reassembly=4; UE が SN=3 を受信した場合たとえ UE が以前にこのセグメントを受信して​​いなかったとしても、UE はそれを破棄します。          

この処理方法は不合理に思えますが、使用シナリオと組み合わせると最も合理的です。たとえば、音声 DRB は、よりリアルタイムのパフォーマンスを考慮して、一般に UM モードを使用し、UM RLC には複数の UM RLC があるため、UE はそれを没収しません。 SN が到着すると停止し、実際に受信した SN に従って再構成ウィンドウがリアルタイムで更新されます。信号状態が悪い場合、UE は特定の SN を受信できない可能性がありますが、再構成ウィンドウが更新されているため、DL が可能です。受信した音声データ パケットはリアルタイムで送信され、一部のデータ パケットが失われた場合でも、UE が解放できる音声を確保できることが保証されます。

t-再構成

46c6780aac554aa884f2324852b727d3.png

 RX_Timer_Trigger は、t-Reassembly SN をトリガーする次の SN の値を格納する UM t-Reassembly 状態変数を表します。

t-Reassembly が実行中であり、RX_Timer_Trigger<=RX_Next_Reassembly または RX_Timer_Trigger がリアセンブル ウィンドウ内になく、RX_Next_Highest または RX_Next_Highest=RX_Next_Reassembly+1 に等しくなく、RX_Next_Reassembly に対応する RLC SDU の最後のバイトより前のすべてのセグメントが受信されているので、停止する時間です次の例に示すように、UM_Window_Size=5 と仮定して、t-Reassembly をリセットします。

2d0624ba62d84a9c915cf41735d2e99a.png

 t-Reassembly が実行されておらず、RX_Next_Highest>RX_Next_Reassembly+1 または RX_Next_Highest=RX_Next_Reassembly+1 で、RX_Next_Reassembly に対応する RLC SDU の最後のバイトの前にセグメントがない場合、UE は t-Reassembly を開始し、RX_Timer_Trigger を RX_Next_Highest に割り当てる必要があります。 SN 値は、たとえば次のようになります。

c7c01a492ed140139d60c5e16925c11a.png 

t-再アセンブリの有効期限が切れる

e795a30b00d84d0d8d11d14eeaba09a3.png

 t-Reassembly がタイムアウトすると、UM RLC エンティティの受信側は、RX_Next_Reassembly を、RX_Timer_Trigger 以上でまだ再組み立てが完了していない最初の SN の位置に更新し、その値より小さい SN のすべてのセグメントを破棄します。 RX_Next_Reassembly 値を更新しました。

この時点で RX_Next_Highest>RX_Next_Reassembly+1 または RX_Next_Highest=RX_Next_Reassembly+1 であり、RX_Next_Reassembly に対応する RLC SDU のセグメントが完全に受信されていない場合、UE は t-Reassembly を開始し、RX_Timer_Trigger を RX_Next_Highest の SN 値に割り当てる必要があります。

 

最後に、RLC UM モード送信の例を見てみましょう。

715e53cc6e44465388891cd55ec0843d.png

 

これは、実際のネットワークでの VONR のログです。音声 DRB 確立の開始時に、5qi=1 の qos フロー 2 とその qos ルールが、PDU セッション変更コマンドによって pdu session id =2 の下に設定され、5qi=1 がそれ​​に対応します。声。

e444da268fc3421f8296cfb886a96490.png

 この前に、上の図に示すように、DRB 3 LCID 5 および UM RLC パラメータに対応する、対応する DRB 情報がネットワーク側で設定されます。 

716ad8ba074b4593a947b68563fd20d8.png

 

上図の印刷からも、音声に対応する DRB 設定情報が印刷されており、エア インターフェイスの設定情報と一致していることがわかります。

fcacc8bf0f4848438380eca12c7714e7.png

 

通話が確立された後、上の図から、UM RLC が音声データを送信していることがわかります。UM RLC は、新しく生成された UMD PDU (RLC SDU セグメントに対応する) の SN を指す TX_Next という 1 つのパラメーターのみを送信します。初期値は0です。

ba5aebe8e7264484b2ffd4a8756ace39.png

 

別の観点から、UL データ PDU の観点から、関連する DRB 固有のデータ送信情報、たとえば SFN 492 スロット 4 で、SI = 00、SI = 00 で新たに送信された RLC データは、完全な RLC SDU が送信されることを意味します。 、UM モードでは、完全な RLC SDU には SN がないため、SN 情報は出力されません。上記の Tx Next は常に 0 であり、これは UE がセグメント化せずに完全な RLC SDU を送信していることも示しています。

5175b9928d63413faa5be20e13ca3f09.png

 

上の図から、DL は常に新しいデータ PDU を受信して​​いることがわかります。ネットワーク状態が良好なため、ピア UL グラントは十分であるため、UE DL が受信した RLC PDU も SI=00 であり、SN はありませんこの場合、RLC はヘッダーを直接削除し、PDCP に渡します。

上記の例を通じて、UL グラントが十分である場合、UM RLC は完全な RLC SDU を送信していることがわかります。そのため、ログは UE がデータを送受信していることのみを知ることができ、UE DL を判断することはできません。 LTE と同様に SN を介してデータが正常に受信されているかどうか、実際の受信状況は、この場合 RLC を確認するのは冗長と思われますが、このとき PDCP DL 受信 (COUNT) を確認する必要があります。上記の問題をさらに確認すると、下図に示すように、PDCP DL 受信は非常にスムーズです。

13de05eb2fe54010ba359ff758909a61.png

 逆に、ネットワーク状態が良くない場合、ULグラントが不足し、UEは多数のセグメントを生成することになるが、このとき、UMD PDUにはSNと、再構成ウィンドウに相当するパラメータが含まれることになる。 RX_Next_Reassembly と RX_Next_Highest には値が割り当てられ、RLC の観点から UE の送受信に関するいくつかの問題が発生する可能性があります。

実際、UM モード送信者の TX_Next 更新メカニズムと組み合わせると、UM モードのシナリオでは、UM モードの Tx_Next が音声データの送信を継続的に記録できず、DL 受信者も同様の状況にあることがわかります。したがって、UM モードのデータ送信が NR RLC を通じて完全に確認できないことを確認したい場合は、問題をさらに確認するために PDCP の送受信を確認する必要があります。 

NR RLC AM モードの具体的な状況については、次の記事で説明します。

 

おすすめ

転載: blog.csdn.net/asd199086/article/details/130855552