omusubi techblog

This website is my technical memo (Mobile/Wireless)

3GPP会合寄書を一挙に要約してくれるGPTsを作った


はじめに

以前、下記記事でChatGPTを用いた3GPP仕様書の解説をお試ししました。

ChatGPTに3GPP仕様を解説してもらった - omusubi techblog

その後のVerUPにより、GPTsという自分好みにカスタマイズ可能な機能が追加され、回答のベースとなる資料のアップロード(但し、数や容量に制約あり)や、回答方法を予め設定可能となりました。今回の記事では、GPTsを使って、3GPP会合の膨大な量の寄書を一挙に要約させる試みについて紹介します。

 

ちなみに、今回作成した下記GPTsは公開しています(ChatGPTplusで利用可能です)

実現したいこと

何度か紹介したことがありますが、3GPP会合の寄書は一般公開されていて、誰でも読むことができます。例えば、RAN2#124会合の寄書は下記からDLできます。

https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_124/Docs

ご覧の通り、採番されたzipファイルが数百個格納されています。これらを一つ一つDLして、展開して、内容を確認していく作業は想像するだけでも嫌になりそうです。

ということで、これらの手間を省けるだけ省き、下記のような要約した表をGPTに作ってもらう、というのが今回実現したいことになります。

こんな感じの表を簡単に出力したい
準備(寄書ファイル取得)

当初、ChatGPT経由で寄書一覧のWebサイトからファイルをDL→展開→要約を試みていたのですが、そこまでは対応できませんでした。

従って、正攻法のftpで寄書は取得しました(数が少なければhttpサイト経由でも良いですが、DLに失敗することも多いので、ftpで一挙に取得する方がおすすめです)

 

ftpで寄書をDLする(Windowsの場合)

RAN2だとここから取得する

zipのままChatGPTにアップロードしても対応可能ですが、処理時間がやや増えるのと、中に複数ファイルが含まれている場合にやや煩雑になりがちなので、できれば全て展開して1フォルダに入れておくのがおすすめです。

ちなみに、DLした大量のZipファイルを一つのフォルダに全て展開するのも、今回はChatGPTにpythonのコードを書いてもらい、こちらを利用しました。

import os
import zipfile
def extract_zip_files(zip_folder, destination_folder):
    # ディレクトリが存在しない場合は作成する
    if not os.path.exists(destination_folder):
        os.makedirs(destination_folder)
    # ZIPファイルの一覧を取得する
    zip_files = [f for f in os.listdir(zip_folder) if f.endswith('.zip')]
    # 各ZIPファイルを展開して目的のフォルダにコピーする
    for zip_file in zip_files:
        with zipfile.ZipFile(os.path.join(zip_folder, zip_file), 'r') as zip_ref:
            zip_ref.extractall(destination_folder)
            print(f"{zip_file} を展開しました。")
if __name__ == "__main__":
    # 展開元のZIPファイルがあるフォルダ
    zip_folder ="DLしたfilepathを書く"
    # 中身を格納するフォルダ
    destination_folder ="展開先のfilepathを書く"
    extract_zip_files(zip_folder, destination_folder)

実際に使ってみる

現状のChatGPTは、一度にアップロード可能なファイル数に制限があり、かつ一挙に大量にアップロードすると、途中で生成がストップする可能性があるので、Tdoc一覧のエクセルから、興味のあるWIなどを抽出したうえで、1プロンプトにつき4~5ファイル位がおすすめです。

この辺のサマリを手間かけず知りたい

今回は上記4つの寄書で試してみます。雑に放り込んでEnterでOKです。

雑に放り込んでEnter

解析が無事終わり、「このまま表形式にして」、と指示しても上手く過去の自身の出力をバッファに格納できていないのか、上手くいきません。したがって、いったん今回の出力をコピーします。出力結果は左下のコピーボタンを押下すると、クリップボードにコピーされます。

ポチっとコピー

各ファイルの要約は'---'で区切って出力されていて、冒頭にファイル名、本文タイトル、作者名を付与するようにしています。あとはこの出力を煮るなり焼くなりお好きな形に成型していただければ要約表の完成です。

コツとしては、「表形式にして」等のザックリとした指示だと、勝手に省略したり、一部分しか実行しなかったりと、なかなか痒いところに手が届かないので、具体的に指示する必要があります。ChatGPTの性質上、実施するたびに若干異なる出力になるので、一概には言えませんが、下記のようにすると上手くいくかもしれません。

(これも勝手に省略される場合があるので、何度か再生成してみると良いです)

以下の文章をCSSとHTMLを用いて体裁を整えて、表形式にして下さい。 列の項目は、ファイル名、本文タイトル、作成者、内容の4つです。 行の区切りは'---'です。内容は省略せずコピーペーストしてください。すべての文章に適用し、ひとつの表にしてください。

(以下要約出力をコピペして実行)

いい感じの粒度の要約表ができた

要約自体の出力粒度はあまりぶれませんが、表形式にしたり、見栄えを整えようとすると、プロンプトや生成毎にブレがあるのでやや注意です。ぜひ色々とお試ししてみてください。

オマケ

ChatGPTではBingを用いたWebBrowingが標準機能としてありますが、ある特定のWebサイトを指定してナレッジとして用いることはできませんでした。

それを解決する手段として、gpt-crawlerが登場しました。

GitHub - BuilderIO/gpt-crawler: Crawl a site to generate knowledge files to create your own custom GPT from a URL

これは、特定のサイトをクローリングして、jsonファイルとして出力してくれるもので、これをGPTsに読み込ませることで、回答のベースにすることができます。
冒頭の下記は、4G/5G解説で有名なSharetechnoteサイトの記事をナレッジとして読み込ませたGPTsになります。したがって、かなりニッチな質問にも回答してもらえます。

ChatGPT - Mobile Expert

 

 

3GPP TS38.300 8.NG Identities を読んでいく

 

メリークリスマス!

この記事は 3GPP TS38.300(V17.6.0)を読んでいく Advent Calendar 2023

の最終日の記事として執筆したものです。
その他の記事はQiitaのアドベントカレンダーページからどうぞ! 

3GPP TS38.300(V17.6.0)を読んでいくのカレンダー | Advent Calendar 2023 - Qiita

 

はじめに

5Gシステムの中では、様々な識別子が登場します。

有名なのは、加入者識別子であるIMSI (International Mobile Subscriber Identity) でしょうか。SIMカードに紐づくアレです。

ただし、厳密には5GではIMSIではなく、SUPI(SUbscription Permanent Identifier)と呼ばれたりもします。その他、SUPIが暗号化されたSUCIであったり、5G-GUTIと呼ばれる一時的な加入者識別子なんかもあったりします。

お分かりいただけたでしょうか、加入者識別子だけでもこんなに色々と存在しているのです…。

今回はこのような識別子だらけの中で、TS38.300で述べられている、RANにまつわる識別子の一部を紹介していきます。

 

RANにまつわる識別子ってどんなの?

今回はRANにまつわる識別子、ということでRACH手順(端末が基地局と通信を開始する)の中で登場する識別子を中心に見ていきます。

RANにおいては、○○-RNTI(Radio Network Temporary Identifier)というような識別子が大量に存在します。標準上は下記が挙げられます。

また、これらはいわゆるPHYやMACといった物理層に近いレイヤー(L1/L2)で使われる識別子であり、RRCやNGAPのような上位レイヤではまた別の識別子が登場します。

  • RA-RNTI: Random Access RNTI
  • TC-RNTI : Temporary Cell RNTI
  • C-RNTI : Cell RNTI
  • I-RNTI : System Information RNTI
  • P-RNTI  : Paging RNTI
  • MCS-C-RNTI : Modulcation Coding Scheme Cell RNTI
  • CS-RNTI : Configured Scheduling RNTI
  • TPC-PUCCH-RNTI :Transmit Power Control-PUCCH – RNTI
  • TPC-PUSCH-RNTI :Transmit Power Control-PUSCH – RNTI
  • TPC-SRS-RNTI : Transmit Power Control-Sounding Reference Symbols – RNTI
  • INT-RNTI : Interruption RNTI
  • SFI-RNTI : Slot Format Indication RNTI
  • SP-CSI-RNTI : Semi-Persistent CSI RNTI

今回は、特にRACH手順の中で重要な赤字の3つについて扱っていきます。

ちなみに、各RNTIの値の範囲や、論理チャネルとトランスポートチャネルにおいてどこで登場するか、は下記にまとめられています。

RNTIの範囲とチャネルマッピング 下記より引用

https://www.techplayon.com/5g-nr-radio-network-temporary-identifier-rnti/

端末から基地局への接続要求~接続完了を例に見ていく

では実際に、どこでどの識別子が登場するのかをRACH手順を例に見ていきます。

ちなみ、LTEに関しては下記記事でRACH手順及び各識別子がどこで登場するか、わかりやすく解説されているのでおすすめです。

IIJmio meeting 25 スマートフォンはなぜ「つながらない」のか | PPT

 

下記Callflow図をもとに、各RNTIを見ていきます。

Msg1~Msg3

https://www.eventhelix.com/5G/standalone-access-registration/5g-standalone-access-registration.pdf より引用

①Msg1:Preamble (プリアンブルの決定≒RA-RNTI)[UE→gNB]
RACH手順の最初に、UE側でPRACHのプリアンブルを決定しますが、その際に併せてRA-RNTIという識別子がプリアンブルの内容によって決まります。具体的には、下記式により、gNB側でRA-RNTIが導出されます。

https://www.techplayon.com/5g-nr-ra-rnti-calculation/ より引用

②DCI1_0 [gNB→UE]

Preambleの応答であるRAR (RandomAcccesResponse)をPDSCHで送信し、UE側でそれを受信するための情報であるDCIを、①で導出したRA-RNTIでスクランブル化(符号系列を乗算してランダム化する)して送信します。

 

③Msg2:RAR (RandomAcccesResponse)[gNB→UE]

RARにはMAC PDUが含まれ、その中で新たにTC-RNTIがgNBから払い出されます。

ちなみに、これは以前みたAmarisoftのシミュレータトライアル版でも見て取れます。

TC-RNTIは一時的な識別子ですが、すでにC-RNTIが割り当てられている場合(Connected→Idle→Connectedと通信再開する場合など)を除き、接続確立後にC-RNTIへ昇格します。

また、RARでは、TC-RNTIと併せてUL grant情報も含まれており、これをもとにUEは次に送るMsg3のタイミング(周波数領域や時間領域)を通知されます。

TC-RNTI発見

④Msg3:RRC Setup request [UE→gNB]

Msg3ではようやく上位レイヤのRRCメッセージが登場します。

最初のRRC Setup requestでは、RRCメッセージの中で新たにUE-identityという識別子が用いられます。これは39bitの値で、下記のようにランダムな値か、5G-S-TMSIの1部分(48bitのうちの39bit)というどちらかの値が用いられます。

UE-identity

ここでいきなり5G-S-TMSIが現れましたが、これは48bitの識別子であり、5G-GUTIの短縮版として用いられています。主にAMFで生成される識別子なので、RAN内というよりはRAN~コア間でのやりとりに用いられると覚えておくと良さそうです。

よくわかる5G-GUTIと5G-S-TMSIの構造

5G Identities in detail Part 2 - ProDeveloperTutorial.com より引用

脱線しましたが、RRCではUE-identityという識別子が登場することを見ました。

 

DCI1_0とMsg4

DCI1_0 [gNB→UE]

続いて、Msg4をUEが受信するためのDCI1_0をPDCCHで送信します。

②ではRA-RNTIでスクランブル化していましたが、この時点ではC-RNTIでスクランブル化しています(③で登場したTC-RNTIがそのままC-RNTIに昇格した)

 

⑥Msg4:RRC Setup [gNB→UE]

UEからのRRC Setup requestに対するgNBの応答メッセージです。

以降の個々のUE向けDCIはC-RNTIでスクランブル化されます。

 

DCI0_0とMsg5

DCI0_0 [gNB→UE]

続いて、Msg5をUEが送信するためのDCI0_0をPDCCHで送信します。ここでのスクランブル化も⑤と同じC-RNTIを用います。

 

⑧Msg5:RRC Setup Complete  [UE→gNB]

UE~gNB間だけの接続の最後のメッセージです。これより先は、gNB~AMF間のコアとの通信が行われます。

 

ということで、UE~gNB間の接続開始~完了までの間に出てきたRNTIをまとめます。

RACH手順の間に出てきたRNTI

これらはセル固有の一時的な識別子であるため、接続する基地局が変われば必然的に変わります。

これに対し、AMFとのやり取り等に使われる識別子は、セルごとではなく、あるAMFの管轄するトラッキングエリア内であったり、Regsitration後の一定期間の間であったりと、有効エリアや期間が異なります。

 

まとめ

今回は、RANにおける一時的な識別子であるRNTIについて、特に端末のRACH手順にか関わるものを見ていきました。途中出てきた5G-GUTIなど、gNB~コア間の識別子やコア内の識別子についても、ぜひ今後まとめられればと思います。

 

3GPP TS38.300 16.13 Support of Reduced Capability (RedCap) NR devices を読んでいく

この記事は 3GPP TS38.300(V17.6.0)を読んでいく Advent Calendar 2023

の1日目の記事として執筆したものです。
その他の記事はQiitaのアドベントカレンダーページからどうぞ! 

3GPP TS38.300(V17.6.0)を読んでいくのカレンダー | Advent Calendar 2023 - Qiita

はじめに

一日目ということで本カレンダーの趣旨を簡単に紹介します。

5Gに関する仕様は3GPPで標準化され、公開されています。

中でも、下記の3つが概要を記載していることから、よく言及されます。

  • TS23.501 System architecture for the 5G System (5GS) →5Gのアーキテクチャ
  • TS23.502 Procedures for the 5G System (5GS) →5Gにおける各種手順
  • TS38.300 NR and NG-RAN Overall Description →基地局・無線関連の概要

いずれも500ページを超えるような大長編かつ、概ね3ヶ月毎に改版されているため、これらを解説するような記事は、ほとんどありません。

 

今回は昨年の、「5Gアーキテクチャの仕様であるTS23.501最新版を皆で読んでいこう!」に引き続き、基地局・無線関連の全体概要を記したTS38.300を読んでいきます。

RedCapってなんなの一問一答

Q.RedCap(ReducedCapbility)って何?

A.通常のUE(非RedCapUE)と比較して、対応機能を削ぎ落したUEのことです。Rel-17で仕様化されました。2024年から本格的に商用製品が世の中に登場する見込みです。
(ちなみに、RedCapという名称以前はNR-Lightという呼ばれ方もしていました)

ファーウェイが5GのRedCapを大規模商用化へ、23年末までに50超の製品発売 | 日経クロステック(xTECH)


軽量版5G「RedCap」は2024年後半に商用化へ、MediaTekがチップセット発表|BUSINESS NETWORK

 

Q.何故機能を削ぎ落すの? せっかく5Gで進化してるのに!

A.機能盛りだくさんだと、構造が複雑化してしまう(アンテナをいっぱい搭載するとか、CPUが熱々になるので冷却必須とか)のでコストも高くなりますが、全てのUEが機能盛りだくさんを必要としてはいない(特にIoTデバイスなど)ので、最低限の機能だけを実装して安く仕上げてバッテリーも長持ちさせようぜ!がコンセプトです。

 

Q.具体的にどんな機能が削がれちゃったの?

A.CA、MR-DC、DAPSハンドオーバーなどの機能が非対応です。
また、サポートする最大帯域幅やMIMO数については、下記の通りとなっており、スループット的にはあまり大きくありません(DL 150Mbps,UL 50Mbps程度想定)

  • FR1:20MHz
  • FR2:100MHz
  • MIMO: DL 2Layer , UL 1Layer
  • 半二重FDDもサポート

Redcap対応UEの違い(Ericsson資料から引用)

https://www.ericsson.com/en/blog/2021/2/reduced-cap-nr

 

Q.IoTデバイスって具体的に何?

現状、WiFiやBlutoothしか搭載されていないことが多い、ウェアラブル機器やセンサ類がeSIM+RedCap対応でセルラー対応していく、といったイメージでしょうか。

その他、LPWA、NB-IoT、LTE Cat.1などのセルラーIoT規格の次世代規格としても期待されています。

2026年以降は、民生用途では、健康モニタリングなどができる5G接続のウェアラブル機器、産業用途では、産業データ収集や資産追跡用の低コストの無線センサー、スマートシティーやスマート工場向けの監視デバイスの使用が増えるとみられていることから、商用RedCapデバイスが急成長する見込みです。

5G時代の新たなセルラーIoT技術「RedCap」とは何か:2026年以降に市場が成長する見込み(3/3 ページ) - EE Times Japan

Q.どのくらいコスト削減になるの?

A.TR38.875 Study on support of reduced capability NR devices内で下記のように試算されています。例えば、最大帯域幅100MHzを代わりに20MHzとすれば、31.9%の削減につながるとしています。

削減効果試算

https://www.nrexplained.com/tr/38875

以上がRedCapのサマリとなります。
毎度おなじみドコモテクニカルジャーナルでも触れられています。

https://www.docomo.ne.jp/binary/pdf/corporate/technology/rd/technical_journal/bn/vol30_3/vol30_3_007jp.pdf

 

以下ではさらに詳しく見ていきます。

RedCapUEをどう識別・制御するのか?

RedCap対応UEを用いて、RedCap対応のネットワークに接続したいとなったとき、

どのような手順でつながるのか見ていきます。いくつか手順(RACH手順の中で識別、UECapabilityから識別)が考えられていますが、RACH手順内における2つのパターンについて見ていきます(下図参照)

What is 5G NR Light - Reduce Capability? - Techplayonより引用

 

①RACH Msg1 based identification

前回解説したSIB1の中身の中に、いろんなIEが含まれていたと思いますが、

中でもinitialUplinkBWPについて、RedCap向けのものがRel-17で新たに定義されています。

SIB1の中身を見てみた(5GSA) - omusubi techblog

これがSIB1にある場合は、こっちを使う

RedCapUEは、SIB1に上記が含まれている場合、このBWPを用いてRACH手順を実施することで、gNB側も識別することができます。

②RACH Msg3 (LCID) based identification

もう一つの方法は、Msg3(PUSCH)において、MACサブヘッダー内のLCIDで識別します。

MACフレーム構造

LCIDの値一覧は下記表です。ここで、通常のUEであれば"52"、RedCap対応UEであれば"35"を選択します。これにより、gNBはRedCapUEであることを識別することができます。

LCID一覧表
その他SIB1拡張

SIB1に関してもRedCap向けのIEが増えています。

RedCap向けSIB1

halfDuplexRedcapAllowedは該当セルの半二重FDDのサポート有無を表しています。

そのほか、1RX、2RX対応UEごとのアクセス規制が可能にするという使いどころが謎のIEも規定されています。

まとめ

次期IoT向け規格のメインストリームになるかもしれない?RedCapの仕様を見ていきました。単に機能を削いだUEというわけではなく、gNB側でRedCap対応UEであることを識別したうえで、半二重FDD適用や細かなアクセス規制などのRedCap対応UE向けの制御が行えるようになっていることが見て取れます。

今後のウェアラブルバイスやIoTデバイスで商用導入されるのを楽しみにしましょう!

SIB1の中身を見てみた(5GSA)

はじめに

本記事は下記記事でSIB1を得るまでを追った続きのお話となります。

5Gの物理層まとめ②' ~MIBからSIB1を得るまで~ - omusubi techblog

具体的には、Amarisoftの5Gシミュレータのデモ版ログをもとに、SIB1の中身を見てみました。端末の電源をONにしてからの、全体の流れでみた位置づけは下記です。

 

 

RACH手順を開始する前のSIB1をデコードするところ

https://www.telecomhall.net/t/5g-call-flow-diagram/7466/2

SIB1はどこだ

SIB1発見

デモ版のログを見ていくと、途中から160ms毎にSIB1が現れます。

RRCかつBCCHかつPDSCHで伝送されるシグナリングだということがわかります。

画面右に内容が表示されているので、全部コピペして見ていきたいと思います。
ちなみに、TS38.331では下記のように中身が規定されています。

TS38.331 v15.5.1


OPTIONALが多く、実際に今回のログでも含まれていないものが結構ありました。

以下、ログに含まれていたSIB1の中身を見ていきます(上記の赤線のもの)

CellSelectInfo/CellAccessRelatedInfo

セル選択関連

主に、このセルの識別子はこれだよ~的な情報が含まれています。

ConnEstFailureControl/ServingCellConfigCommon

接続失敗時の制御とセルのより細かな情報

主に接続失敗時の制御や、セルの周波数やサブキャリア間隔といった周波数情報が含まれています。また、ServingCellConfigCommonの中に以下の更に詳しい情報が含まれています。

ServingCellConfigCommonの内容ばっかりだった

 

initialDownlinkBWP/PDCCH-configCommon 

DLのBWP情報やPDCCH(DCI)情報
SearchSpaceTypeCommon/PDSCH-ConfigCommon/BCCH-config/PCCH-config 

ここもDL関係

ここまでが、downlinkconfigcommonに含まれる、DL関係の情報(DownlinkconfigCommon配下に含まれる情報)となります。


UplinkConfigCommon/initialUplinkBWP

ここからUplink関係
RACH-configCommon

RACH関連

RACH手順関連の情報はこちらに集約されています。

PUSCH-configCommon/PUCCH-configCommon

PUSCH関連とPUCCH関連
SSB関連(ServingCellConfigCommon)/ue-TimersAndConstants (SIB1)

SSB関連とTimer関連


最後のTimer関連はServingCellConfigCommonに含まれるものではなく、SIB1のIEとなります。見てわかるように、ほとんどがServingCellConfigCommon配下に含まれるIEでした。

まとめ

SIB1はReleaseを重ねるごとに情報が増加しており、配下まで辿っていくと凄まじい情報量であることがわかります。例えば、RACH手順のために必要なRACH-ConfigCommonは、下記まで辿る必要があります。

SIB1→ServingCellConfigCommon→UplinkConfigCommon→initialUplinkBWP→BWPUplinkCommon→RACH-ConfigCommon

次回は、実際にRACH手順の開始を見ていきたいと思います。

 

ChatGPTに3GPP仕様を解説してもらった

はじめに

この記事は、ChatGPT(GPT-4)に3GPPのTS/TR、寄書、会合の議事録などを要約・解説してもらえないか、お試しした結果を記しています。

結論、2023/10時点では下記印象です。

  • TS/TRは分量が多すぎて一括ですべて要約するのは厳しい。
    セクション毎ならひと手間かければ、抽象的な要約程度には使えるかも
  • 寄書や議事録のサマリも、プロンプトを工夫すれば有用かも
    (文章量が多すぎるとざっくり省かれてしまうので、細かに分けるなど)
  • Advanced data analysis つよい

以下では、NTN (Non-Terrestrial Network)を例に、お試しした結果を述べていきます。
[2023/11/06 寄書要約お試しを追記しました]
[2023/11/07追記]

データ量が多いとまだまだかなと言っていたら、さっそくアップデートがきました

今日発表された「ChatGPTのアップデート内容」まとめ | ギズモード・ジャパン

まだ開発者向けプレビューのみのようですが、非常に期待です。

 

 

WebBrowsing

Bing等にも搭載されている、Webページをクロールしてそれっぽい回答をしてくれる機能です。

あなたは3GPP仕様の専門家です。 3GPP TS38.300における、NTN(非地上系ネットワーク)のRel-17での追加・変更事項をすべて列挙してください。

WebBrowsingできいてみた

TS38.300の指定はあっても無くても結果としては変わらず、TSを細かく見た感じは見受けられませんでした。引用元としては、NTNで検索して上位に出てくる下記のサイトが

用いられていました。引用元があることで、そこまでおかしな記述は無いのですが、
知りたかったNTNの詳細仕様はここからは読み取れなさそうです。あるキーワードのサマリを調べるのには向いているかもしれません。

3GPP公式サイト : NTN & Satellite in Rel-17 & 18

3GPP NTN(非地上ネットワーク) 仕様解説

WebPilot

こちらは指定したWebサイトを読み込んで分析してくれるプラグインです。

例えば、TS38.300だと下記Webサイトにテキストで置かれているので、これを読みこんで、同じような指示を実行してみました。

inside TS 38.300: Non-Terrestrial Networks

 

WebPilotで聞いてみた

WebBrowsingよりかは遥かに粒度が細かくなっていることが分かります
(というより指定サイトを翻訳して、要約してる感じなので当たり前な気もしますが)

この状態から、下記のように指示するとさらに詳しく解説してくれます。

タイミングと同期について詳しく教えてください

詳しく要素を解説

課題もご丁寧にまとめてくれるが、当たり障りない

ここまでは、"重要です"や"異なる場合がある"など、ざっくりまとめられているので、

より具体的に聞いてみます。特に、最後の"特定のフレーム構造が定義されている"はどこか違和感があります。そんなの定義されてたっけ。

特定のフレーム構造について詳しく教えてください

逆に一般的になってしまった

なんということでしょう。
情報が少ないからという理由で一般的な要点ではぐらかされてしまいました。しかも、フレーム長やサブフレーム長が調整されるという、本文に記載のない回答も増えています。この後、本文に記載されていないことは回答禁止 とプロンプトを足しましたが、回答に変化はありませんでした…

AskYourPDF

こちらはWebPilotと異なり、PDFのURLを指定することで分析可能なプラグインです。
3GPP関連はほとんどがWord(.docx)なので、PDFは少ないですが、
ETSI版のTS38.300(v17.0.0)を読み込ませ、同じ指示を実行してみました。

https://www.etsi.org/deliver/etsi_ts/138300_138399/138300/17.00.00_60/ts_138300v170000p.pdf

ちょっと文面違うけどざっくり感は同じ

変わらずざっくりしているので、詳しく聞いてみます。

ユーザプレーンの側面について詳しく教えてください

なんかイマイチ・・・

さらにイマイチになってしまいました。WebPilotはtech-inviteのNTNのセクションだけを対象にしていたのに対して、こちらはTS38.300全体から分析しているせいもあるかもしれません。このあと、いろんなプロンプトを試してみましたが、下記のように分量オーバー的な回答が返ってきて、思ったような回答は得られませんでした。

一度にすべてを読み込むことはできませんでした。以下は、読み込んだ部分から得られた~

ちなみに、「16.14.2 User Plane aspects  について詳しく教えてください」というようにセクションを指定しても、若干回答は変化しますが、あまり多きな改善は得られませんでした。

したがって、TS/TRのように文章量が膨大だと、現状だと文章を細かく分割するなどの1手間を加えないと、そもそもChatGPTで読み込むことが難しそうです。

Advanced data analysis

最後に、最近登場した新機能 Advanced data analysisを試してみました。

こちらは、プロンプトをもとに、ChatGPT上でPythonコードが生成され、実行される機能で、様々なファイル形式の読込・生成に対応しています。

今度はTS38.300の3GPP公式ワードファイルを読み込んで、同じ指示を実施ししてみましたが、やはり読み込みがうまくいかず、まともな回答が得られませんでした。

ということで、TS/TRは諦めて、寄書やChair notesを試すことにしました。


Chair notesでお試し

下記のRAN2#123bisの議事録を読み込ませることにしました。

https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_123bis/Inbox/Chair_Notes/RAN2-123bis%20-%20NR-NTN-IoT-NTN%20(Sergio)_2023-10-12-1800.docx

毎度ながら、議事録はなかなか見づらくて合意事項や議論状況がパッと見ではわからないので、これをまとめてくれるとかなり嬉しいはずです。

 

また、指示するプロンプトも今までの反省を活かし、下記のようにしてみました。

あなたは3GPP仕様のエキスパートです。 下記手順で議事録の要約を作成してください

1.文章全体を読み込み、目次を作成する(英語)。省略しないこと。

2.目次の中からこのあと指定した章(サブセクションも含む)について、内容を要約する

3.内容の要約には合意事項を含め、詳しく述べること

4.1度にすべて読み込めないときは、何回かに分けて読み込むこと

最初の配役設定みたいなフレーズは、あっても無くても変わらなかったので、雰囲気です。

手順1の結果がこちらです。

目次読込は成功!

試しに、7.7.2 Coverage Enhancements を要約してもらいます。

結構それっぽいぞ!

今まで試してきた中では、一番具体的かつ、いい感じの出力が得られました。

合意事項については恐らく本文の下記文面を用いたと思われ、大きな乖離はなさそうです。

本文のAgreements

主な討論点は、???なチョイスな気もしますが、まったく関係のないキーワードではなく、頻繁に出てくるキーワードから選択されている感じがします。


寄書要約でお試し

NTN関連のRel-18のWI寄書である下記でお試ししてみました。
RP-220953 NR NTN (Non-Terrestrial Networks) enhancements

単に要約してくれ、といった指示だけだとこれまた上手くいかなかったので、

もう少し具体的に指示しました。

あなたは3GPP仕様の専門家です。

読み込んだ寄書の提案について、

・背景(Justificationのセクション)

・目的(Objectiveのセクション)

・リードWG(Work item leadershipのセクション)

・関連WG(Aspects that involve other WGsのセクション)

を日本語で解説してください。

いずれも内容は省略せず、記載されていない内容は含めていはいけません

Objectiveが省かれちゃった

目的以外は大体良い感じに見えます。Objectiveの文章が多すぎて、例のごとくザックリ省かれてしまったようです。対して、同様に"Objectiveについて詳しく教えてください"と指示しましたが、やはり上手く本文をトレースできていないようでした。

なので、セクションの見出しを再度読み込ませつつ、解説をさせるようにしました。

目的(Objectiveのセクション)のセクション見出しを列挙し、解説してください。

Objectiveの解説

一部怪しいですが、パッと流し見する程度の要約にはなっている感じがします。

まとめ

ということで、ChatGPTに3GPP仕様を解説してもらう試みですが、現状ではTS/TRを読み込ませて分析は分量的に厳しいものの、Advanced data analysis を用いてChair notesのdocxを放り込んで要約させる程度には有用な気がします。
また、寄書についても、文章量が多くなると一工夫というか分けて指示を行う必要がありますが、ある程度有用と思われます。

 

 

 

 

5Gの物理層まとめ②' ~MIBからSIB1を得るまで~

この記事は、下記記事で省略したMIBからSIB1受信までの複雑な手順をまとめたものです。

5Gの物理層まとめ② ~端末の電源ONからセルサーチ~ - omusubi techblog

④PBCHからMIBを取得し、SIB1を受信するための情報を得る ←ここの話

 

参考リンク:

5G | ShareTechnote

5G NR CORESET - Control Resource Set - Techplayon

5G NR pdcch-ConfigSIB1 - ControlResourceSetZero & SearchSpaceZero

MIBの中身を改めてみる

MIBの中身

SIB1を得るための全体的な流れとしては、下記となります。

<SIB1(PDSCH)を得たい >

  • PDSCHで伝送されるので、伝送スケジュールが記されたDCI(PDCCH)を得る必要がある
  • SIB1向けのDCI(PDCCH)はCORESET0と呼ばれる領域なので、これを得る必要がある
  • CORESET0の場所はMIB(pdcch-configSIB1)から導出できる

かなり回りくどいですが、まずはCORESET#0という領域が時間軸・周波数軸でどこにあるのか見つければよさそうです。

※DCI=Downlink Control Information:PDCCHで伝送される制御情報。上り下り両方の通信のスケジューリングをする超重要信号

※CORESET=COntrol REsource SET:PDCCHが存在する領域。LTEではある時間のすべての周波数領域でPDCCHが伝送されていたが、5Gでは一部周波数領域でのみ伝送される。SIB1はSIB1専用のDCIが用いられ、このDCIが存在するCORESETをCORESET#0と呼ぶ。

CORESETのわかりやすい図

https://www.techplayon.com/5g-nr-coreset-control-resource-set/

ちなみに、PDCCHとかPDSCHって何ぞやは下記の図を参照ください。

mappingの図



CORESET#0を導出する(周波数領域)


話を戻して、まずはCORESET#0の領域をpdcch-configSIB1から導き出します。

pdcch-configSIB1は0~255の整数とされていますが、さらに2つのパラメータが存在します。

pdcch-configSIB1

ここで、controlResourceSetZeroは上位4ビット、searchSpaceZeroは下位4ビットであらわされます。仮に、pdcch-ConfigSIB1="10110010"とすれば、

  • controlResourceSetZero=1011(bin)=11
  • searchSpaceZero=0010(bin)=2

となります。この2つの値とSSB及びPDCCHのサブキャリア間隔をもとに、TS38.213で定義された数多くの表からマッチする値を読み取る必要があります。

こんなテーブルが10個ぐらいある

どの表を見れば良いかすらわからなくなってしまいますが、Sharetechnote先生が

分類わけしてくれています。

ありがたい分類表

https://www.sharetechnote.com/html/5G/5G_CommonSearchSpace_Type0_PDCCH.html

仮に、n78のSSB,PDCCHともにサブキャリア間隔30kHzの場合、上記表に従ってTable13-4を参照すればよいことが分かります。ここで、controlResourceSetZeroの値がindexの値となります。この表からは、CORESET#0の周波数領域の位置が分かります。

index=controlResourceSetZero=1011(bin)=11の行を見る

各列の項目については下記イメージです。

  • multiplexing pattern:SSBとの相対位置(SSBと周波数や時間で同じタイミングか)
  • Number of RBs:リソースグリッドの周波数軸占有分
  • Number of Symbols:リソースグリッドの時間軸占有分
  • Offset(RBs):周波数軸のオフセット分

CORESET#0の周波数領域

https://www.techplayon.com/5g-nr-pdcch-configsib1-controlresourcesetzero-search-space-zero/

※KssB=SSBとリソースブロック間のオフセット


ここまでで、CORESET#0の周波数軸(縦軸)上の位置がつかめました。
次に、まだ使ってないsearchSpaceZeroの値をもとに、時間軸(横軸)上の位置(≒UEがサーチする対象の期間)を求めていきます。

 

CORESET#0を導出する(時間領域)

searchSpaceZeroの値を参照する表は、周波数やmultiplexing patternに応じて定義されていて、今回、n78(FR1)かつ先ほど見たmultiplexing pattern:1の場合は下記表を参照します。

index=searchspaceZero=0010(bin)=2の行を見る

各列の項目については下記イメージです。

  • O:フレームの先頭を基準としたスロットのオフセット
  • M:Number of Search speace sets per slotによって変わる係数的なもの
  • Number of Search speace sets per slot:スロット当たりのサーチスペースセット(PDCCHを探しに行く期間)数
  • First Symbol Index:スロット内のサーチ スペースセットの開始シンボル位置

表から読み取った各項目を下記のTS38.213内の式にあてはめます。

TS38.213 を頑張ってみるしかない

multiplexing pattern:1の場合、上の式で求めたn0から連続する2スロット、つまりn0とn0+1番目のスロットの最初(0番目)が、CORESET#0の位置候補となります。

今回の場合、n0=4と計算できるので、スロット4とスロット5の最初のシンボルでCORESET#0(SIB1のDCI)をサーチすることになります。

CORESET#0をサーチする場所

これで、SIB1をスケジューリングするDCIを含むCORESET#0の周波数領域と時間領域の位置が分かり、こちらに含まれるDCIからSIB1のPDSCH位置を読み取ります。

まとめ

前回、MIBからSIB1を受信するための情報を得る、とさらっと書きましたが、

計算式や定義された表を多く参照する必要があり、非常に複雑であることが分かりました。次回はDCIからPDSCHを読み取るまでを見ていきます。

 

5Gの物理層まとめ② ~端末の電源ONからセルサーチ~

この記事は、5Gにおける端末の電源ON~セルサーチの流れをまとめたものです。

筆者の勘違い等が含まれている可能性もありますので、あいまいな点はぜひご指摘願います。

 

おすすめ参考資料:
①TelecomhallのMohamed ELAdawi先生の記事

https://www.telecomhall.net/u/mohamedeladawi/activity/topics

②ドコモ先生の解説記事

5GにおけるNR物理レイヤ仕様 | 企業情報 | NTTドコモ

はじめに

大まかな流れは下記となります。

基地局が報知情報(SSB)を定期的に発信する

②端末の電源を入れると、SSBをスキャンし始める(セルサーチ)

③受信したPSSとSSSからPCI(セルID)を取得する

④PBCHからMIBを取得し、SIB1を受信するための情報を得る

⑤SIB1をもとに、RACH手順を開始する ←ここでようやく端末から電波を発する

端末の電源ON~セルサーチの流れ
https://www.telecomhall.net/t/5g-call-flow-diagram/7466/2




基地局の報知情報(SS/PBCH Block : 通称SSB)

基地局から常に出てます

5Gの物理層まとめ① ~フレーム構成とリソースブロックとSSB~ - omusubi techblog

前回の記事でも少し触れましたが、基地局は報知情報と呼ばれる、その基地局に関する情報を定期的に発信しています。この報知情報のかたまりをSS/PBCH Block、通称SSBと呼びます。

 

SSBの周期は、5/10/20/40/80/160msのいずれかの範囲で、基地局ごとに設定可能かつ、ビームごとに異なるSSBを設定できるため、複数のSSBを送信することもできます。この複数のSSBをまとめて、SSバーストと呼んだりもします。

 

また、前回の記事でSSBは帯域幅のどの位置にも柔軟に設定可能であると記載しましたが、厳密には、同期ラスタ:GSCN(Global Synchronization Raster Channel)という粒度の範囲内で設定することができます。

LTEまでは、ラスタというのはキャリアの中心周波数を設定可能な粒度として用いられていましたが、5Gでは2つのラスタが登場します。

1つは、LTEまでと同様に、使用する帯域の中心周波数を設定する粒度としてのチャネルラスタです。ただし、LTEは100kHz単位のみでしたが、5Gでは15/60kHz単位となりました

チャネルラスタの変化

https://www.soumu.go.jp/main_content/000680139.pdf

そして、もう一つ新たに登場したのが同期ラスタです。こちらは、SSBを設定する粒度で、Sub6帯では1.44MHz単位、mmW帯では17.28MHz単位となります。

新たにラスタが導入された一番の理由としては、5Gでは広い帯域幅を使用することから、従来のチャネルラスタの粒度で報知情報をサーチしていては、非常に時間がかかってしまうため、より大きな粒度でSSBを設定することで、セルサーチの時間短縮が図られています。イメージとしては下記です。

チャネルラスタと同期ラスタのイメージ

あるバンド(例えばn79の100MHz)で、中心周波数を設定可能な位置は15kHz単位のチャネルラスタ位置のため、100MHzもあると膨大な数になり(青の線)、それをすべて確認していくとかなりの時間を要します。これに対し、同期ラスタは1.44MHz単位で設定するため、かなり粒度は荒くなり(赤の線)、確認対象の周波数を大幅に削減可能となります。

ということで、5Gでは、免許に申請されている中心周波数と、報知情報であるSSBが発信されている周波数位置は、往々にして異なります。

 

②端末の電源ON!

いろんな基地局やビームのSSBが飛んでる

端末の電源をONにすると、①で見たSSBをスキャン(セルサーチ)し始めます。

この時の粒度が、同期ラスタとなります。

PSSとSSSからPCIを取得する

プライマリ同期信号:PSSセカンダリ同期信号:SSSはそれぞれ

  • PSS:0~2の3つの値
  • SSS:0~335の336個の値

を持ち、PCIは下記のように計算されます。

  • PCI:3×SSS+PSS →0~1007の値

したがって、PCIは1008通り存在します(LTEでは504でした)

PCIをもとに、PBCHの復調用信号であるDMRSのSSB内の位置を求めることができ、

つぎにPBCHを復調していきます。

PCIでPBCH DMRSの場所が決まる

http://howltestuffworks.blogspot.com/2019/10/5g-nr-synchronization-signalpbch-block.html

④PBCHからMIBを取得し、SIB1を受信するための情報を得る

MIBの中身

MIBの中の下記情報からSIB1を受信するための情報を取得します。

具体的にはpdcch-configSIB1が該当します。SIB1はPDSCH(データ転送の物理チャネル)で送られるのですが、そのSIB1の送信をスケジューリングするためのPDCCH(制御データ転送の物理チャネル)情報を格納しています。
MIBからSIB1導出までの流れは複雑すぎてまだ理解が追い付ていないので下記を参照するとよさそうです。。。理解できたら追記します。

https://www.linkedin.com/pulse/5g-nr-controlresourcesetzero-corseset0-search-space-zero-chelikani

 

その他MIBには、サブキャリア間隔や、リソースグリッドがどこから始まるかをUEに通知するオフセット値、PDSCHのDMRS位置などが含まれており、80ms周期で送信されています。

 

⑤SIB1をもとに、RACH手順を開始する(端末から電波を発する)

SIB1には下記のような情報が含まれています。

  • セル情報:PLMN(ドコモは440-10とか),TACなど
  • セル選択情報:接続するために最低限必要な受信レベル(RSRP)など
  • 他のSIBスケジューリング情報
  • RACHパラメータに関する情報
  • 端末に通知する各種タイマー値

これらをもとに、ようやく端末が電波を発出し、基地局に対して接続を試みるRACH手順を行えるようになります。RACH手順までは、5GCは関係しないので、基本的には端末と基地局間でのみ完結します。つまり、initial registrationなどの5GCとのやりとりはまだまだ先の話となります。