3GPP TS23.501 5.6 Session Management整理

3GPP TS23.501 5.6章セッションマネジメントを読んだメモとなります。
一部詳細内容を省略する場合もありますのでご了承ください。

下記のAdvent Calendarに参加しております。

https://qiita.com/advent-calendar/2022/3gpp_ts23501



# サマリー
この記事は以下の内容を含めております。
- DNNの選択ロジック
- 各IFのセッション関連処理の役割
- Roaming時LBO/HR構成におけるHPLMN/VPLMN側SMFの役割
- DNへ複数アクセス経路を提供・制御するマルチPSA機能
    - IPv4/IPv6 single prefix/IPv4v6/Ethernetセッション向け：　ULCL
    - IPv6 with multiple prefixesセッション向け： IPv6 multi-homing
- 特定サービスエリア内のみDNへアクセスできるLADNへのサポート
- DN-AAAによるセッションのsecondary認証
- トラヒックの経路制御においてAFのできること
- 既存PDUセッションU-planeのactivation/deactivation. (CM-IDLE/CONNECTED状態遷移)
- SSC mode１〜３と選択ロジック　
- 各PDU Typeにおける特性
- その他機能(Area of interest, Always-on PDU session, Framed routingへのサポートなど）
# 5.6.1 Overview
- 5.6章はUEとData Network間のPDU接続サービスについての説明です。5.6.1は概要的な話なので重点だけピックアップします。
- DNNの選択ロジック
    1. UEからのPDU Session Establishment Request中に含まれるDNN(その場合、SMFはUE requestとUDMに記載されたallowed情報と一致するかをチェックする)
    2. 1.がなければ、該当加入者データに記載されるdefault DNN
    3. 2.もなければ、AMFに設定されたlocally configured DNNが使用される
- UEからrequestされたDNNが網側にサポートされず、AMFによるSMFの選択が不可になった場合は
    - もしPCFにて代替DNNの設定が存在しないと、session establishmentがrejectされる
    - もしPCFにて代替DNNの設定が存在すれば、UE requested S-NSSAIに適する代替DNNが使われる
- 加入者情報にwildcard DNN (＊)記載の際は、UE request全てのDNNを許容する
- Multi-Access(MA) PDUは、同時に3GPPとnon-3GPP接続(それぞれ独立のトンネル)を持つセッション。Establishment request時に含むRequest Typeは"MA PDU Request"。詳細は5.32 Support for ATSSSに参照してください。
- Table 5.6.1-1にてestablishment request際必要な項目とsession確立後変更可否の一覧が記載されてる。

# 5.6.2 Interaction between AMF and SMF
- セッション関連処理の役割についての話
    - N1: UE-(AMF)-SMF
        - AMF：SM関連NAS信号をSMFに転送、後続信号のアクセス・処理SMFの一致性を保証する
        - SMF: NAS SM信号の処理を行う
        - UE: PDU Session Establishmentを要求する(RM-Registered状態下のみ)
    - N11: 
        - AMF->SMF: UE reachabilityの報告
        - SMF->AMF: Sessionリリース時AMFへの通知
    - N2: 一部AMF,SMF両方処理必要な内容はAMFよりSMFに転送される（handover関連など）
    - N3: 既存PDUセッションUser Planeのactivation/deactivation。詳細は5.6.8参照
    - N4: DLデータが発生したがUPFがN3トンネル情報を持っていない場合、UPFはSMFに通知し、SMFからAMFに通知してNetwork Triggered Service Requestをトリガーする。
  
# 5.6.3 Roaming
- Local breakoutの場合：PDUセッション制御ためのSMFと全てのUPFはVPLMNの下。
- Home routedの場合：hSMF-vSMF, UPF(HPLMN)-UPF(VPLMN)接続の構成
    - HPLMN側：SMFと少なくとも１UPF
    - VPLMN側：SMFと少なくとも１UPF
- 同じUEにおいて異なるモード(LBOかHR)のPDUセッションを利用してもよい。HPLMN側はS-NSSAIとDNNごとLBO/HR手法を設定できる。
- HRの際vSMFとhSMFの役割：
    - vSMF: UEからNAS SMを受信し、HPLMN SM関連の部分をHPLMNに転送
    - hSMF: 該当UEのSUPIをVPLMNから受け、request内容と加入者データの一致性を確認する
    - QoS関連：hSMFからvSMFにQoS情報を送ることも可能。vSMFはローミング規定に沿ってQoS requestを確認する。
- AMFがLBO方式でVPLMN SMFを選択後rejectされた場合、N11 reject causeによってHR方式に切り替わって新たにvSMFとhSMFを選択することも可能。

# 5.6.4 Single PDU Session with multiple PDU Session Anchors
- 1つのPDUセッションは複数のN6に対応できる。SMFがその制御により
  - DNへのルーティング選択が可能
  - SSCモード３(詳細は5.6.9参照)をサポートする
- 終端IF(N6)を有するUPFはPDU session Anchor(PSA)機能を持ち、DNへのアクセスを提供する
- PSAのアサインはSSCモードと同じセッションに追加アサインされたPSAに関連する。
- SMFは提供されたPCCルールにより、どの実現手法（次に説明する「ULCL」か「IPv6 multi-homing」）を使ってルーティングするかを決定する。
### ULCL
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2957124/79dcf99d-7a70-5e2a-9aed-51480952ff39.png)
- Uplink classifier (ULCL)とは：SMFからのFilter情報などに基づいて、特定トラヒックをローカル分散するためのUPFの機能。
  - DLトラヒック処理する際は、異なるPSAからのトラヒックをmergeしてUEに送る。
- ULCLの適用PDU Type: IPv4, IPv6, IPv4v6, Ethernet
- SMFはN4を通してULCLを制御する。PDUセッション確立の際/後にULCLのinsert,removeができる。
- １つのセッションに対して複数ULCLが対応することも可能。
- UEはULCLを意識しない。IPv4アドレス/IPv6 prefixは１セッションごと一つ。
- 特定PSAの削除によりPDUセッションをリリースさせることはSMFにて設定可能。
- ULCLはdst IPやprefixなどのfilterによりパケットのルーティングを制御するほか、chargingルールの適用やSession AMBRの制御も可能。
    - N9が存在する場合、Session AMBRはsource ULCL用UPFに適用される
    - ULCL用UPFもPSAとして使うことが可能(ULCLから)
- セッションデータパス追加のため、追加のULCL(とPSA)を挿入しても良いが、N3を通してRAN側と繋ぐULCLは１つのみ(relocation時セッション持続ための場合除き)。
- UE移動によりULCLとしてのUPFが変更される場合、セッション継続性を維持するためにsourceとtarget ULCL間仮のN9トンネルを作っても良い。AFによりN9トンネルを作るかどうかが影響される場合もある。

### IPv6 multi-homing
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2957124/2da81d88-9d82-1851-b299-9eaf18151638.png)
- multi-homed PDU session: 複数IPv6 prefixに関連するPDU Session。DNへのアクセスは異なるPSAに経由することで複数パスを持つ。
- 共通のUPF=Branching Point（BP)によって異なるパスへ分岐する。BPはULトラヒックをターゲットPSAへフォワードし、DLトラヒックを集約してUEへ送る。
- BP機能を持つUPFはSMFの制御によりchargingためのトラヒック計測や流量制御も出来うる。
- SSC mode3のサービス持続性維持のため、multi-homed PDUは"make before break"=PSA変更発生時はまず新PSAへのN9トンネルを張ってから、元の接続を切断する。
- Internetとlocal DN両方へアクセスするなどのユースケースが想定される。

# 5.6.5 Support for Local Area Data Network
- LADN: UEが特定tracking areaに位置する場合のみ該当DNに接続可能。該当DN或いはwildcard DNNのsubscriptionが必要。
- LADNの情報は、UEにlocal configurationに定義されるか、Registration中に通知される。
  - LADN service areaはRegistration areaに影響しない。RAに基づいてLADN中一部のみを通知することも可能。
- AMFは自身に設定されるLADN情報、UE位置情報と加入者情報をもとに、利用可能のLADNリストをUEに通知する。
- LADN listは下記のように決められる：
    - Registrationする際UEがLADN DNNを含める場合は、UE requestのLADNにする（加入者データに許容したDNNの場合)
    - LADN情報をrequestする指示を含める場合は、AMFあるいは加入者データのLADN listにする
    - 両方とも含めない場合は加入者データのLADN listにする
- UEがLADN areaの外に出た際、UEは自らUP connection establish/modifyの要求はしない。だたし、網からrelease requestが送られる前に自らセッションをリリースする必要もない。
- SMFがLADN関連のrequestをAMFから受けて、UEのLADNサービスエリア内にいるかどうかの情報を確認できない場合は、エリア外として判断しrejectする。
- LADNへのsession確立時、SMFはAMFからUE mobility event notificationを要求し、サービスエリアにおけるUEの位置をリポートさせる。
- AMFからLADN areaにおけるUEの位置を通知を受けのSMFの挙動
    - UEがエリア外であることが通知された場合、SMFは
      - 即PDUセッションをリリースか;
      - セッションを一時維持しするが該当セッションのU-plane切断し、Data Notificationがdisabledであることを確認する。
    - UEがエリア内であることが通知された場合
      - Data Notificationがenabled状態を確認する
      - 網からDLデータがある際にNetwork triggered Service Requestを送る。
    - UNKNOWNと通知されたとき、エリア内にいる場合と同様に扱っても良い
# 5.6.6 Secondary authentication/authorization by a DN-AAA server during the establishment of a PDU Session
- DN側AAAサーバを使ったPDU session establishment時のsecondary認証/認可(TS33.501 sec11.1)はこの章で解説される。詳細proucedureは4.3.2.3 of TS 23.502に参照。
- セッション確立時、DNがUEからの認証情報が必要とする場合、SMFの挙動は以下の通り
    - UEが認証情報を提供した場合：認証情報をSMF->UPF->AAAに転送する (DN-AAAは5GC内にアクセスできる場合、UPF経由しなくても良い)
    - UEから認証情報が提供されてない場合：SMFがUEに認証情報を含めるように要求する
    - UEから認証情報で認証失敗の場合：PDUセッションの確立をrejectする
- DN-AAAからSessionの認可が行われる場合、SMFに以下確立済みPDUのDN Authorization Dataを送られる
    - SMF/PCFにて定義済みのDN Authorization Profile Index
    - DNより払い出されたSession AMBR(UDM加入者情報のSession AMBRより優先度高い)
    - 5.6.14に定義されるFramed route information
    - L2TP情報
    - (Ethernet typeのみ)allowed VLAN/MACアドレスリスト
    - DN Authorization Dataから受信し且つdynamic PCCが適用される場合は、SMFはPCFにDNより払い出されたsession AMBRかDN Authorization Profile Indexを送信する。
- secondary認証/認可が行われないが、SMF policyによりDN認可のみが必要な場合、SMFは可能な限りUE GPSIをDN-AAAに提供する。
- SMFとDN-AAA間の認証セッションはSMFからinitiateし、認証後もセッションが保持される。
- UEからの認証情報はNAS SMに含まれる。
- UEに定義されたDNNがsecondary認証/認可の対象である場合、DNと該当認証情報をセットでUEに保存される。
- UEのremote provisioningもサポート可能。その場合は5.39章で定義されるprovisioningサーバへ接続可能なS-NSSAI/DNNを使ってセッションを確立する。
- SMFにPSAを追加した際、secondary認証認可(再認証?)が不要だが、SMFポリシーによってSMFからDNに変更内容を通知する。
- 任意のタイミングで、DN-AAAからの認証取り消し、DN Authorization Dataの変更が可能。 SMFはそれに従ってセッションのリリースやアップデートを実施する。
- 任意のタイミングで、DN-AAAやSMFからの再認証・認可ができる。

# 5.6.7 Application Function influence on traffic routing
- AFはPCF(5GC内接続が許容された場合)あるいはNEFにrequestを送り、特定PDUセッション/UEの特定トラヒックルーティングを変更することが可能。
- この節の内容はnon-roamingとLBOに限る。Home routedの場合PCFはAF requestを適用されない。
- AF requestの影響によりUPF・(I-)SMFの再選択やLocal breakoutが発生する可能性がある。PCFはAF requestの内容をPCCルールに反映し、PDUセッションに適用する。
- AF requestに含める内容は「Table 5.6.7-1: Information element contained in AF request」に記載。一部重要の内容は以下で詳細ピックアップ：
    - トラヒックの指定方法：
        - DNN,S-NSSAI,AF-Service-Identifierどれかひとつ
        - UPFのトラヒック検出用にApplication idあるいはフィルター情報(5 tunpleかFQDNレンジ)
    - ルーティングの指定方法：DNAI(option：UE groupとDNAIの紐付け)
    - ターゲットUE情報
        - 単独UEの情報 GPSI,IP/prefix,MACアドレス
        - TS 23.682 より定義されたUEグループID
        - 指定DNN/S-NSSAI/DNAIにアクセスする全てのUE
- AFはUP path management eventsの通知を要求することも可能。DNAI/N6トラヒックルーティングが変更された際、AFはSMF(とNEF)から通知を受ける。
### 5.6.7.2 Enhancement of UP path management based on the coordination with AFs
- PSA relocationやULCL/BPによるサービス中断を最小限にするため、AFがSMFにUP path management events発生する前に通知を要求することが可能。
- 通知を受けた場合、AFはpositive/negative responseを送ることで、SMFに該当セッションの変更を発生/発生しないよう指示できる。
- SMFの通知実装がlate notificationである場合、AFが通知配信要求に"AF acknowledgment to be expected"を含むことで上記を実現する。
- SMFはpositive responseを受信するまでにDNAIやルーティングを維持する。
  
# 5.6.8 Selective activation and deactivation of UP connection of existing PDU Session
- この節は同一UEに複数PDUセッションが確立された場合に適用する。既存PDUセッションU-Plane接続のactivationはUE-CNのU-Plane接続(data bearerとN3トンネル)をactivateする。
- UEがCM-IDLE状態時：
    - 3GPPアクセス:UE/NW-triggered Service Requestは個別PDUセッションUPのactivationをサポート可能。
    - non-3GPPアクセス：UE-triggered Service RequestはPDUセッションのreactivationと個別PDUセッションUPのactivationをサポート可能。
- UEがCM-CONNECTED時UPのactivation：UE triggered service requestで個別PDUセッションUPをactivateする。
- 既存PDUセッションのNW triggered reactivationは以下のように扱われる
    - AMFでのUE CM状態が(3GPPアクセス、non-3GPPアクセス両方とも)CM-CONNECTEDである時、NW initated service requestでUPをreactivateする。
    - 3GPPとnon-3GPPアクセス片方がCM-CONNECTED、もう片方がCM-IDLEの際、CM-CONNECTEDである方のセッションを通してCM-IDLEの方に通知する。
- 上記以外、always-on PDUセッションについては5.6.13に解説される。always-on PDUセッションがinactiveになっても、SMFはそれをdeactivateしない。
- UEがCM-CONNECTED状態である際、PDUセッションUPのdeactivationは独立で行われる。I-SMFにより制御されるN9トンネルを使ったPDUセッションをdeactivateする際に、N9トンネルは保持される。

# 5.6.9 Session and Service Continuity
- 5GSがサポートする３つのSSCモードが解説される。
- ３つのモードにて、UEの移動などアクセス方式によりUPの変更が発生する際、セッションの持続性とIPアドレスの保持有無状況が異なる。
  - SSC mode1: セッションとIPアドレス両方を保持する。
  - SSC mode2: セッションとIPアドレスをリリースする→瞬断あり
  - SSC mode3: IPアドレスは変更されるが、瞬断を防ぐために元の接続を切断する前に新しい接続を確立する。
### SSC mode１〜３詳細
- SSC mode1:
    - PDUセッション確立時PSAとしてのUPFは固定され、PSAとして使われ続ける。
    - PDUタイプがIPv4,IPv6,IPv4v6である際、UEの移動関係なくIPアドレスは保持される。
    - IPv6 multihomingやULCLをSSC mode1であるPDUセッションに適用する場合、たとえ網側から追加のPSAをこのPDUセッションに割り当ても、追加PSAは再割り当てかリリースされる可能性がある。
    - SSC mode１はPDU接続可能なUEの必須サポートモード。
- SSC mode2: 
    - PDUセッションはPSAを一つしか持たない。
    - オペレータポリシーにより、UEの位置情報などに基づきPSAの変更が必要だと判断した場合、網側がPDUセッションをリリース後即UEから再確立するように指示する。
    - multi-homed PDUやULCLの適用により、SSC mode2であるセッションが複数PSAを持つような場合、追加のPSAがリリースや再割り当てされる可能性がある。
    - UEのSSC mode2サポートはoptional。
- SSC mode3: 
    - SSC mode3では、UEと元のPSA間接続をリリースする前に、新しいPSA経由でDNへの接続を確立することを許容する。
    - このrelease17では、IPタイプのPDUにのみ適用する。
    - IPアドレスの再割り当てが発生する。元のIPアドレス/prefixは、UE NAS signalingやRouter Advertisementに定義された期間中保持される後、リリースされる。
    - UEのSSC mode3サポートはoptional。
### SSC modeの選択
- SMFは、加入者情報のallowed/default SSC mode・PDUタイプとUEからrequestしたSSCモードにより、SSC modeの選択を行う。
    - UDMにてDNN,S-NSSAIごとにallowed/default SSC modeが定義される。
    - UEはオペレーターにアサインされたURSP中のSSC mode selection policy (SSCMSP)に基づいてSSC modeをrequestする。SSCMSPをもた場合は、UEのローカル設定によりrequestするか、SSC modeの指定しない。
    - SMFは加入者情報中のallowed SSC modeとPDU Tpyeに基づき、UEからrequestされたSSC modeをaccept/rejectするかを判断する。
    - rejectされた場合は、UEは再度requestするか、別のURSPルールを使う。
- static IPをPDUセッションに適用される場合は、SSC mode1がアサインされる。

# 5.6.10 Specific aspects of different PDU Session types
- IP session type
    - PDUセッションlifetimeの間、UEはSMFから以下の情報が必要とする
        - P-CSCFのアドレス (IMS使う際)
        - DNSサーバのアドレス
        - UEがDNS over (D)TLSをサポートし、且つNW側もDNS over (D)TLSを使う場合、その関連情報
        - UEのGPSI
    - PDUセッションlifetimeの間、SMFはUEから以下の情報を必要とする
        - P-CSCF re-selectionサポートの情報
        - UEのPS data off status
- Ethernet Type
    - Ethernet Type sessionに対して、SMFとPSA UPFはEthernet frameの処理をサポートする。
    - オペレータのDNN構成により、N6のトラヒック処理方法が異なる
        - PDUセッションとN6が1対１関係の場合、N6へdedicated tunnelが張られ、PSA UPFはUEのMACアドレスを意識する必要はない。
        - 複数のPDUセッションが１つのN6に対応する場合、DLトラヒックをmapするため、PSA UPFはUE(とその下に繋がってるデバイス）のMACアドレスを意識する必要がある。
    - SMFはUPFにlocal cache情報によってARP/IPv6 NDをresponseするように要求することが可能。
    - EthernetのpreambleとFCSは5GSにより転送されない。UL:UE/DL:PSA UPFはpreambleとFCSを除く。
    - 5GCよりPDUセッションにIPやMACアドレスを割り当てしない。DN側からIPを割り当てる場合はあるが、Ethernet PDUセッションの範囲として考えない。
    - PSAはUE MACを保存し、PDUセッションと紐づける。
    - 5.6.6節に書かれたようにDN-AAAの指定によるallowed VLANの設定、またはSMFのlocal configによるallowed VLAN設定が可能。さらに、指示によるVLAN TAGの挿入・削除処理などのVLAN処理も可能。
        - SMFはVLAN処理の内容を決定し、それをUPFに指示する。
        - UPFはallowed VLANによりトラヒックのaccept/discard、PDR(Outer header removal)とFAR(Forwarding policyにouter headerの追加を適用）によりVLANの挿入・削除を行う。
            - TS23.316に定義されたW-5GANサポートの状況以外、UPFはVLAN tagを削除してはならない。
    - DN-AAAから指示されたallowed MACアドレスは、１セッションごと最大16MACアドレスまで。
    - このrelease17では、認証はUEのみを対象とし、UEに繋ぐ端末は含まない。
    - このrelease17ではloop-freeとtopology変更時の迅速な対応に対応しない。
    - UPFはSMFから指示されたEthernet packet filter set and forwarding ruleに従ってパケットの検出とQoS適用を行う。
    - SSC modeへのサポートは、release17の時点mode1と２のみ。
    - ポリシーによってPCFはSMFにUE MACアドレスをレポートを要求する。
- unstructured PDUセッションタイプについて省略します。詳細は5.6.10.3を参照してくだい。
- Maximum Transfer Unit size considerations
    - UEとPSA間パケットフラグメントを防ぐために、UEは網側提供されたMTUを設定するべき
    - IPv4 Typeの場合、MTUサイズはPCOに含まれてUEに送信される(TS24.501参照)
    - IPv6 Typeの場合、MTUサイズはRAに含まれてUEに送信される(RFC4861参照)
    - Ethernet Typeの場合、Ethernet Frame payloadのMTUがUEに送信される。


# 5.6.11 UE presence in Area of Interest reporting usage by SMF
- 3GPP accessの「Area of Interest」は以下のどれかにより定義できる
    - Tracking areaリスト
    - Presence Reporting Area(PRA) IDのリスト
        - Presence Reporting AreaはUE-dedicatedとCN predefinedの二種類がある
            - UE-dedicated: 加入者データ或いはAFがPCFに提供したarea of interest情報(TA/NG-RAN/cellリスト)により定義される
            - CN predefined: AMFにて設定したTA/NG-RAN/cellリストにより定義される。オーバロードを防ぐため、PRAごとの優先度も設定可能。
    - LADN DNN
- AMFの"UE mobility event notification"サービスを使うことで、SMFはUEが「Area of Interest」内に位置するかしないかを把握し、セッションにUPF再割り当てを行うことなどを指示する。
- Policy制御やchargingに関するユースケースにおいて、PCFがAMFやSMFよりreportingエリアにUEに位置状況を受信する。
- subscriptionはPDUセッションlifetimeの間に保持される。セッションリリース後、subscriptionも取り消される。

# 5.6.12 Use of Network Instance
- N4 Session EstablishmentやModification中、SMFはUPF FAR/PDRにNetwork instanceの情報を提供する。
- Network instanceを使う意図はIP domainを分けること。例えばUPFが複数DNと接続する場合、異なるDNから割り当てられたUE IPアドレスの重複を防ぐ。[DNN-DNAI情報を含めて設定する場合は多い感触]

# 5.6.13 Always-on PDU session
- 上位レイヤの指示により、UEはAlways-on PDUセッションをrequestする。Always-on PDU session確立後、たとえuplinkデータやNW側のトリガーがなくとも、UEはこのセッションのactive状態を維持するようにrequestすべき。
- 網側からalways-on PDUの確立をrejectされた場合、UEはuplinkデータが無い際このセッションをactive保持するためのrequestを送ってはいけない。

# 5.6.14 Support of Framed Routing
- 企業用途などのケースで、UEの後ろにさらにNWが存在し、このIPレンジ内のデバイスがまとめて一つのPDUセッションを使って網に接続する場合が想定される。Framed route=UEの後ろのIP route。
- Framed route情報は網側からUEに送信するではなく、UEの後ろのデバイスはRFC 2865とRFC 3162に記載されたメカニズムより取得する。(3GPPスコープ外)
- Framed route情報はSMFからUPFのPDRに提供される。
- SMFはFramed route情報をDN-AAAサーバ或いは加入者情報から取得する。両方から取得した際、DN-AAAからの情報が優先度高い。
# 5.6.15 Triggers for network analytics
- SMFがNWDAFにrequest/subscribe可能な分析情報について説明されている。