前回はfree5gcを構築してテストコールを行いました。
今回はテストコールの結果を詳しく見ていきましょう。
1. 5GCで使われるコールフロー
例の如く巨人の肩にのるため他の方の説明を引用します。
2. 実際にみてみる
という訳で読んでも分からないなら動かしてみるのが一番です。
前回と同じtest.shを使いますが、今回はfree5gc内を流れるパケットを実際に追ってみます。
まずはパケットキャプチャの準備としてテキストベースのtsharkをインストールします。
q14537@free5gc:~$ sudo apt install tshark
そしてキャプチャ取得。ターミナルを２つ開いて１つのターミナルで以下の様にtsharkを起動しておいて、もう1つのターミナルでtest.shを実行します。取得したキャプチャは5G_registration.pcapというファイル名で保存されます。
q14537@free5gc:~$ tshark -i any -w 5G_registration.pcap
以下の様にtmuxを使って画面分割してもよいでしょう。
3. wiresharkで開いてみる
tsharkだけでも解析はできますがやはりGUIが便利なのでtsharkでキャプチャしたファイルをホストWindowsマシンにsftpしてWindows上に別途InstallしたWiresharkで読み込ませてみます。
色々なパケットがキャプチャされているのですが、フィルターで注目すべきプロトコルだけに絞ってみます。
先に一部のメッセージが暗号化されていてうまくデコードしてくれないので、Wiresharkメニューの編集->設定->ProtocolsでNAS-5GSを探し、以下のNAS-5GSのメニューで"Try to detect..."のチェックボックスをチェックします。
その後フィルター部分に"sctp||ngap||pfcp||gtp"と入れてみます。
以下は例です。何やら見慣れないプロトコルが出てきました。
一部localのLoopbackアドレス同士で通信しているのでわかりにくいのですが、以下が対応表です。
| IP Adress:Port | Entity |
|---|---|
| 127.0.0.1:9487 | gNodeB(5G基地局) |
| 127.0.0.1:38412 | AMF |
| 10.200.200.1 | SMF |
| 10.200.200.101 | UPF |
| 60.60.0.1 | UE |
| 60.60.0.101 | DN上の何かサーバ等 |
このあたりの設定は各NFのconfigurationのyamlファイルに記載されています。
以下AMFの例の抜粋
q14537@free5gc:~/free5gc/config$ cat amfcfg.yaml
info:
version: 1.0.0
description: AMF initial local configuration
configuration:
amfName: AMF # the name of this AMF
ngapIpList: # the IP list of N2 interfaces on this AMF
- 127.0.0.1
sbi: # Service-based interface information
scheme: http # the protocol for sbi (http or https)
registerIPv4: 127.0.0.18 # IP used to register to NRF
bindingIPv4: 127.0.0.18 # IP used to bind the service
port: 8000 # port used to bind the service
serviceNameList: # the SBI services provided by this AMF, refer to TS 29.518
- namf-comm # Namf_Communication service
- namf-evts # Namf_EventExposure service
- namf-mt # Namf_MT service
- namf-loc # Namf_Location service
- namf-oam # OAM service
servedGuamiList: # Guami (Globally Unique AMF ID) list supported by this AMF
# <GUAMI> = <MCC><MNC><AMF ID>
- plmnId: # Public Land Mobile Network ID, <PLMN ID> = <MCC><MNC>
mcc: 208 # Mobile Country Code (3 digits string, digit: 0~9)
mnc: 93 # Mobile Network Code (2 or 3 digits string, digit: 0~9)
amfId: cafe00 # AMF identifier (3 bytes hex string, range: 000000~FFFFFF)
4. 5GCで使用されるプロトコル
前回の5GCアーキテクチャでも参照した図に各NF間で使用されるプロトコルをマッピングした図が以下です。
今回は紫で記載している部分が見えてる事になります。
| プロトコル名略称 | フルネーム |
|---|---|
| GTP | GPRS Tunneling Protocol |
| NGAP | NG Application Protocol |
| NAS | Non-Access Stratum |
| PFCP | Packet Forwarding Control Protocol |
| SCTP | Stream Control Transmission Protocol |
| HTTP2 | Hypertext Transfer Protocol Version2 |
5 コールフロー詳細
5.1 Registration手順
3GPP(TS23.502)の以下の図が参考になります。
上記コールフローはOld AMFとNew AMFの間のやりとりが記載されていますが、今回はOld AMFは無視してOKです。RANとNew AMFの間のやり取りに注目しましょう。微妙に3GPPのコールフローとは合わないのですが、コールフローの1,6,7,9,11,21,22の部分がキャプチャの以下の部分に対応しています。
ひとつひとつのメッセージにどんなパラメータが含まれいてるかは3GPPと睨めっこしながら勉強していくしかないのですが、例えば#1125のRegistration Requestを開くと以下の様にSUCI(Subscription Concealed Identifier)というパラメータが含まれており、端末の固有識別番号をネットワークに送信し認証をこの番号に対して行う依頼をしている事がわかります。この例では0-208-93-0-0-0-00007487がSUCIになります。SUCIはIMSIをもとに作成されています。IMSI=2089300007487です。
その他色々解説しているとキリがないのですがこの辺りは以下の記事も参考になります。
事業者国番号と事業者コードのPLMN ID=MCC+MNCだけ覚えておきましょう。今回の例はMCC=208:MNC=93でWiresharkはFranceのThales Communicationとデコードしてくれています。なぜにタレスなのかは謎。この部分が事業者毎に割り振られている番号ですので例えば日本のソフトバンクならMCC=440:MNC=20を使用したりします。
5.1.1 認証メカニズム
5GCの認証方式は5G AKAとEAP-AKA’認証があるのですが、このtest.shでは5G AKAを使う様になっています。両社の微妙な違いはとりあえずおいておいて#1356と#1357のパケットのやり取りを見てみましょう。AMF側から以下のパラメータ（秘密の暗号のヒントの様な物を端末に送信し、端末側が返してくる答えが合っているかどうかをAMF経由でAUSFに送信して認証をしています。様は”山”
と言ったら”川”が返ってくるかを試してます。
AMF->UEチャレンジ送信
UE->AMFチャレンジ応答
5.2 PDU Session Establishment手順
Registrationが成功=5GCに端末が認証され無事登録された=携帯サービスが使えるという事ですので、次にPDU Sessionと呼ばれるパケット通信が出来る通り道を確立する手順にいきます。
3GPP(TS23.502)の以下の図が参考になります。
キャプチャの以下の部分です。
PDU Session Establishment Requestの中にどんなサービスを受けたいかの詳細が含まれています。この例ではIPv4で繋げたいのでIPアドレスを割り振ってくれないか等々の要求が入っています。また5GではDNN(Data Network Name)と呼ばれる4GでのAPN相当のパラメータを使ってどこのData Networkを使って外部(5GCのその先)と通信するかを指定します。DNNの指定を変える事で出先のネットワークを変える事ができます。
5GC側ではこのUEからの要求をもとにUEに割り振るIPアドレスを払い出します。実際に行うのはSMFです。その他パケットの通り道のQoSパラメータ等も返信します。以下が#2555のメッセージに含まれいてるPDU Session Establishment Responseの中のUEにIPアドレス=60.60.0.1を割り振っているところです。
その後無事にUEに60.60.0.1が割り振られましたのでこのアドレスをソースとしてPINGを60.60.0.101に送っているところが見えます。コールフロー図のFirst Uplink DataとFirst Downlink Dataに該当する部分です。UEが送るユーザーからのペイロードの事をU-planeデータといいます。
U-planeのデータはGTPというトンネリングプロトコルを使用して運ばれます。UEとUPFの間でトンネルを作るのです。UPFがDNとのGatewayとなってGTPヘッダをつけたり、外したりします。以下の様に実際のペイロード(ICMP)がGTPの上に乗っかっているのがわかります。GTPの通信のIPアドレス(10.200.200.1<->10.200.200.102)とペイロードで使用するIPアドレス(60.60.0.1<->60.60.0.101)が全然別なのが分かります。
6.最後に
よく見たらRegistrationしてますが、最後にDeregistrationしてなかったですね。。UEがIP通信始めたらいきなりシグナルロストになったイメージですね。。
SMF<->UPF間のPFCPについては解説しませんでしたが、後日追記するかもです。。
実際のPINGメッセージはUPFを通ってDN(Data Network)に出ていきます。簡単に言うと、その為の通り道の設定をSMFがUPFにPFCPを使って指示出しをしているのです。
今回はUE/gNB<->AMF(5GC)間を中心にやりとりを見ましたが、次回は5GC内部を詳細にみてみましょう。