3GPP TS23.501 5.6 Session Management整理

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

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

サマリー

この記事は以下の内容を含めております。

• 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

• 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

• 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可能な分析情報について説明されている。