1. はじめに
本Blogでは5Gで新たに追加されたNFであるUDSF(Unstructured Data Storage Function) についてご紹介したいと思います。また、3GPP v17ではUDSFに2種類のAPIと8種類のResourceが定義されていますが、その中の一つのAPI ResourceについてそのResourceへのHTTPアクセス方法を紹介します。
2. 5G Core Networkのデータベース
3GPP 5Gでは2つのデータベースが定義されています。加入者情報を格納するためのUDR(User Data Repository)と3GPPによって定義されていないデータを格納するUDSF (Unstructured Data Storage Function)があります。本BlogではUDSFについて解説していきます。
以下のテーブルにUDRとUDSFの特徴をまとめました。
3. UDSFとは
UDSFはモバイルネットワークにおけるユーザ定義のUnstructured Dataを格納するためのNF（Network Function)です。UDSFを利用するApplicationはSession DataをUDSFに格納することでApplicationで障害が発生しても他のApplicationが同一Session Dataを取得し、処理を継続することができます。UDSFに格納されたデータは参照・更新・削除ができます。
ちなみに3GPP TS 23.501の4.2.5 Data Storage architecturesではUnstructured Dataを「構造が定義されていないデータ」と定義しています。
４．UDSFの特長
3GPPではAMF、SMFといったNetwork Function(NF)が管理しているUE Context情報を3GPP準拠のUDSFに格納できると記載されています。UDSFに格納されたデータはデータベースの冗長機能で保護され、障害時でも継続してデータを提供できます。Consumer Service NF（クライアントアプリケーション）で障害が発生してもUE Context情報は失われないのでConsumer Service NF障害で発生しうる輻輳トラフィック（※）を抑制できるメリットがあります。
（※）障害時にUE Context情報を失うことで、大量のUEが同時にUE Context再作成処理を始めてしまい、一度に大量のトラフィックが発生する現象
3GPP TS 29.598 V17.6.0に以下の2つのAPIが定義されています。
1. Nudsf_DataRepository
2. Nudsf_Timer
Consumer Service NFはそのAPIでUDSFにデータを格納、削除、参照ができます。APIにアクセスに必要なURI、HTTP Methodなどは3GPP TS 29.598に定義されており、以下のテーブルでUDSFが提供するURIとURIへのアクセス方法（Resource URIとHTTP Method)が説明されています。
5. HTTP RequestとResponseの生成例
実際に前述のテーブルの情報を基にHTTP Requestを作ってみたいと思います。
TS V17では8種類のResourceが定義されていますが、ここでは2番目のRecord(Document)のHTTP Requestを作ってみます。
最初にTS29.598の5.2.2.3 “Create a Record”を確認すると、Consumer Service NFはUDSFにPUT MethodでResource （…/records/{recordId}/(Record)を送信することがわかります。
- …/records/recordId : Resource URIの一部が省略されていますが、これは/{realmId}/{storageId}/records/{recordId}を指しています。“{ }”は”変更可能”を意味します。例えば、{realmId}に会社名を入れて{storageId}にシステム名を入れることができます。{realmId}と{storageId} はUDSFの設定項目となります。
- (Record) : ”( )”はData Typeを指します。ここではRecordというData Typeを指します。6. API Definitionのチャプターには6.1.6 Data Modelがあり、その中にそのData Typeの詳細があります。
次に6.1.3.3 Resource: Record (Document)の6.1.3.3.3.2 PUTを確認すると、HTTP Requestに必要なData Typeが記載されており、RecordのP (Presence Condition)がM (必須)となっていることがわかります。その他、DescriptionからMetaと１個またはその以上のBlockデータを含めたRecordであることもわかります。
さらに6.1.6 Data ModelからはRecord data typeを構成しているAttribute名がわかります。Metaは必須ですがBlocksはOptionalで、数は1~N個まで入れられることがわかります。
以下は3GPP TSに記載されている内容をまとめた例です。 Multipartで複数のBlockを入れています。具体的にはMetaとRecordDataの２つのBlockを“myboundary” で区切っています。
C.2 Example HTTP multipart RecordにMultipart Recordの例がありますので、その例も一緒にご参考ください。
HTTP REQUEST:
PUT http://<UDSFのIPアドレス>:<Port番号>/nudsf-dr/v1/{realm0}/{space0}/records/imsi-9981598070011111?get-previous=true
HTTP Request Body:
--myboundary
Content-Type: application/json
Content-id: meta
{"tags": { "user" : ["admin"], "supi" : ["imsi-999559807001001"] } }
--myboundary
Content-Type: application/json
Content-Transfer-Encoding: binary
content-id: block1
______‑ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abc
--myboundary--
このようにUDSFのAPIはRecord IDをKeyにしてMetaおよびBlockデータをPUTしています。PUTされたデータは特定のRecord IDを指定してGETします。特定のKeyに対して値を返す動きからこのOperationはKVS(Key Value Store)の動きに似ています。
次にUDSFからのResponseを調べます。以下のFigureではUDSFが201 Created (RecordBody)を返しています。成功した場合 HTTP Response Codeとして201 Created 設定し、Bodyには(RecordBody)のData Typeを格納するという意味になります。
Responseの詳細を確認するために6.1.3.3 Resource: Record (Document)の6.1.3.3.3.2 PUTを参照します。Table 6.1.3.3.3.2-3にはPUT Response BodyのData Structureが記載されていますが、一行目のRecordBodyではPresence Condition(P)が必須(M)の場合Response Codeは200 OKを入れる必要があります。2行目にも同じRecordBodyが書かれていますが、こちらはOptionalとなっておりResponse Codeには201 CreatedをResponseに入れるとあります。他のData typeはPUT要求に対しOperationが失敗した場合のHTTP Responseに入れるData TypeとResponse Codeになります。
次にRecordBody Data Typeに入れるAttributeを調べます。RecordBodyはData TypeがRecordと同じで、Presence Conditionは必須になっています。
ここまでがRecord(Document)のHTTP PUT RequestとResponseの説明でしたが、この情報を基にJmeterやPostmanなどのツールを使い、HTTP Requestを送信することができます。以下はPostmanの入力例です。
3GPP TSはVersionが上がると仕様が変更されたり、新たなAPIが追加される可能性がありますが、同じ読み方でその更新内容を確認することができます。今回紹介されていない他のResourceを3GPP TSを読みながらチャレンジしてみてください。
6. 最後に
UDSFはMobile NetworkにおけるDynamicデータを格納するデータベースと言えますので、UDSFとして世の中で一般的に使われている汎用データベースが使えるのではないかと考える人もいるかと思います。実際、汎用データベースにUDSFのAPIを被せることでUDSFとして使用可能で、その場合Mobile OperatorとしてはUDSFの内部データベースの種別(RDBMS, NoSQLなど)を意識する必要がないためUDSFの選択肢が増えるというメリットもあります。
ただし、UDSFとして使用可能なDBは以下の二つの要件が必要になると考えています。
更新頻度が高いダイナミックデータを格納する必要があるため、短い応答時間（＝高速処理）が必要になります
用途によっては大容量のデータを格納する必要があるため、柔軟なスケールアウトを前提としたアーキテクチャが必要になります。
7. 別表
HPEではShared Data Environment (SDE)というソリューションがありますが、SDEの中には5G UDR, UDSF, 4G UDRの3つのデータベースで構成されるArchitectureです。外部から要求をハンドリングするFront Endは各データベースごとに用意されていますので、必要なデータベースだけをデプロイして使うことができます。https://www.hpe.com/psnow/doc/a50001320enw にHPE SDEのデータシートがありますので、ご参考ください。
yyun
ソリューションアーキテクト
