在進行5G核心網服務化介面（SBI）疑難排解時，許多工程師都會遇到相同的難點。從AMF傳送到SMF的請求主體中，可能已經包含SUPI、DNN、S-NSSAI、TAI、PDU Session ID和5QI等熟悉欄位，但要判斷這則訊息是否真正有效，仍然不容易。欄位應該編碼成字串還是整數？它是否有明確的數值範圍？任何值都能使用，還是必須從預先定義的列舉中選擇？一個物件裡是否還能包含其他巢狀參數？
這些問題由SBI共通資料型別來定義。服務化介面涵蓋AMF、SMF、UDM、PCF和NRF等網路功能，但許多底層參數並不專屬於單一NF。如果每項服務都各自定義這些值，規範中就會出現不必要的重複，同一個用戶識別碼或QoS參數也可能在不同API中採用不同表示方式。因此，分析SBI流量不能只檢查HTTP方法與資源URI。HTTP/2規定請求如何傳輸，JSON規定資料如何表示，而共通資料型別回答的是更根本的問題：每個JSON參數必須遵循什麼格式與驗證規則。
共通資料型別解決了哪些問題？
可以把它們理解成整個5GC服務化API環境共用的一套「資料詞彙」。某個資料型別可能出現在AMF請求中，也可能被SMF、UDM或PCF引用。它不屬於單一介面，而是提供一套可在多項服務之間重複使用的標準化定義。
以IPv4位址為例，每個NF都不應自行定義如何用字串表示位址。PLMN資訊也是如此，其中MCC與MNC有明確的長度和格式要求；SUPI、GPSI、PEI等用戶與設備識別碼也各自遵循特定編碼規則。統一的定義能讓不同NF之間的RESTful API可靠地交換資訊。
共通資料型別也應與NF專用型別區分。共通型別用來描述會在多個介面反覆出現的物件，而某個特定網路功能獨有的業務物件，則定義在對應的29系列規範中。實務上，一項SBI API經常會同時引用這兩種資料型別。
它們的範圍遠不只網路位址。共通定義還涵蓋一般參數、訂閱與身分資訊、5G網路資料、QoS、計費、追蹤資訊以及其他可重複使用的物件。這些內容共同構成SBI訊息參數的基礎資料模型。
三種基本資料結構有什麼不同？
從結構來看，SBI參數通常可分成三類：簡單資料型別、列舉型別和結構化資料型別。理解這三類結構比背誦個別參數名稱更實用，因為在Wireshark封包擷取、API文件與OpenAPI定義中看到的大多數欄位，都可以歸入這個模型。
簡單資料型別是最底層的基本構成單元，包括字串、整數、數值、日期、日期時間和布林值。在5GC中，這些基本型別通常還會搭配數值範圍、編碼格式或正規表示式等額外限制。
例如，IPv4位址在技術上以字串表示，但並非任意字串都有效，它必須符合規定的IPv4格式。IPv6位址、IPv6前綴和MAC位址也各自有格式要求。Uint16、Uint32與Uint64規定無符號整數的數值範圍。URI必須符合URI格式規則，DateTime值則必須使用指定的日期時間格式。
規範也經常定義帶有Rm後綴的型別，例如Ipv4AddrRm、DateTimeRm和Uint32Rm。這些型別與對應的基礎型別使用相同的底層格式，但包含OpenAPI的nullable屬性，因此欄位可以帶有null值。
列舉型別類似選項欄位：值必須從預先定義的集合中選擇。例如AccessType用來區分3GPP_ACCESS與NON_3GPP_ACCESS；PduSessionType可以取IPV4、IPV6、IPV4V6、UNSTRUCTURED或ETHERNET；CoreNetworkType可以表示5GC或EPC。
列舉的目的在於消除歧義。呼叫端不能自行建立一個含義相近但未被定義的字串，而必須使用規範明確列出的值。這也是疑難排解中常見的情況：欄位名稱完全正確，但列舉值無效，因此API仍會拒絕請求或錯誤解讀請求。
結構化資料型別會將多個屬性組合成一個完整物件。這些屬性本身還可以引用簡單型別、列舉型別或其他結構化物件，進而形成階層式模型。
ProblemDetails就是典型例子，它可以包含type、title、status、detail、instance、cause和invalidParams等欄位。TAI也是結構化物件，由PLMN ID與TAC組成；GUAMI更進一步，由PLMN ID與AMF ID組成。到了這一層，SBI分析不能只看個別欄位，還需要關注物件內各屬性之間的關係。
身分與網路參數是如何逐層建立的？
在實際封包擷取中，訂閱、身分與5G網路相關資料是最常見的SBI參數之一。SUPI用來識別用戶，GPSI表示外部用戶身分，PEI表示永久設備識別碼，DNN識別資料網路，NF Instance ID則唯一識別一個NF執行個體。
這些欄位大多看起來只是簡單字串，但真正重要的是字串內部的編碼規則。SUPI可以包含IMSI或NAI表示形式，而GPSI可以包含MSISDN或External Identifier。換句話說，被定義為字串，不代表任何字串都有效。
5G網路相關型別會在這些基礎識別碼之上建立工作階段與位置資訊。PduSessionId識別一個PDU Session；MCC與MNC構成PLMN身分的一部分；TAC識別Tracking Area Code；NrCellId與EutraCellId則分別識別NR和E-UTRA小區。
結構化物件再把這些基礎參數組合成更高層的資料模型。S-NSSAI使用SST和可選的SD來表示網路切片；TAI由PLMN ID和TAC組成；NCGI將PLMN ID與NR Cell ID組合起來識別NR小區，而ECGI則對E-UTRA發揮相近作用。
UserLocation是更高層次的抽象。依接取類型不同，它可以帶有NR Location、E-UTRA Location或Non-3GPP Access Location。一個NR Location本身還能包含TAI、NCGI、位置時間戳記與地理資訊。
這反映了SBI資料模型的模組化設計。先將MCC、MNC、TAC和Cell ID等基本元素標準化，再組合成PLMN ID、TAI、NCGI和UserLocation等高層物件。API可以直接重複使用這些物件，而不需要每項服務都重新定義整套位置參數。
為什麼QoS、計費和追蹤資料也必須標準化？
SBI流量傳遞的內容遠不只有用戶身分與網路位置。QoS政策、使用資訊與網路追蹤資料同樣會在多個NF之間流動，因此這些值也需要一致的資料定義。
在QoS參數中，QFI用來識別QoS Flow，5QI代表5G QoS Identifier，BitRate以數值和單位表示速率，Packet Delay Budget表示延遲預算，而Packet Error Rate與Packet Loss Rate用來描述傳輸品質。
QoS政策也會使用多種列舉型別。PreemptionCapability表示某項服務是否可以搶占已分配給其他服務的資源；PreemptionVulnerability表示現有資源是否可能被更高優先級服務取代；QosResourceType則區分NON_GBR、NON_CRITICAL_GBR和CRITICAL_GBR等數值。
這些基礎欄位接著會組合成ARP、AMBR、Dynamic 5QI和Non-Dynamic 5QI等結構化物件，讓SMF、PCF以及其他相關網路功能在交換優先級、位元率、延遲和搶占行為等概念時，使用相同的表示方式。
計費資料採用相同的設計原則。ChargingId、RatingGroup和ServiceId屬於較直接的簡單資料型別，而QoSFlowUsageReport可以包含QFI、收集開始與結束時間戳記，以及上行和下行流量；VolumeTimedReport則可以表示某個指定時間區間內的PDU Session使用量。
追蹤相關型別用來標準化網路追蹤資訊。TraceDepth透過列舉值描述不同追蹤層級，而TraceData則組合Trace Reference、Trace Depth和NE Type等參數，避免每個NF各自定義一套彼此不相容的追蹤欄位。
這些例子說明，共通資料型別並不只是標準化「幾個JSON欄位」，而是在標準化不同核心網服務如何理解相同的業務與網路概念。如果QoS、位置、計費資訊或用戶識別碼需要在多個NF之間傳遞，就必須先有一致的資料模型。
如何在實務疑難排解中使用資料型別？
工程上很常見的錯誤，是檢查JSON訊息時只看某個欄位是否存在，卻不確認其資料型別與相關限制。更有效的疑難排解方式，是把HTTP層與資料模型一起分析。
先確認正在呼叫哪項服務以及資源URI，接著在請求主體或回應主體中找到目標欄位。找到之後不要只看數值本身，還要檢查它引用哪種資料型別、是必填還是選填、Cardinality為何、是否屬於列舉，以及是否有Format或Pattern限制。
IPv4欄位在人眼看來可能像IP位址，但如果不符合規範定義的格式，它仍然是無效輸入。同樣地，PduSessionType的某個值即使以一般語言來看可以理解，只要不屬於規範指定的列舉值，就不符合API定義。
對結構化資料應遞迴展開分析。看到UserLocation時，要確認物件中包含的是NR、E-UTRA還是Non-3GPP位置資訊；看到TAI時，要檢查PLMN ID與TAC；看到S-NSSAI時，要檢查SST與可選SD。只有逐層追蹤型別引用，才能判斷JSON物件是否真正符合API模型。
當伺服器拒絕請求時，也值得仔細查看ProblemDetails。除了HTTP狀態碼之外，它還可以提供detail、cause與invalidParams資訊。如果這些欄位存在，疑難排解就能直接從違反API要求的具體參數開始，而不必只停留在一般性的HTTP 4xx回應。
為什麼資料模型思維比背誦參數表更有用？
5GC SBI共通資料型別數量很多，如果想記住每個欄位、正規表示式和數值範圍，很快就會變得沒有效率。更好的方法是建立資料模型思維：簡單型別定義最小資料單元，列舉限制合法狀態，結構化型別則把這些單元組合成能由5GC服務直接使用的物件。
在這個架構下，SUPI、MCC、TAC和QFI不再是孤立參數，而是建立用戶、位置、工作階段、QoS、計費與追蹤模型的基本元件。不同NF能透過SBI一致地呼叫服務，其中一個重要原因就是這些共通型別提供穩定且可重複使用的資料語意。
因此，在閱讀陌生的5GC API時，最有用的第一個問題不應是「這則訊息裡有多少個欄位？」，而應確認這些欄位引用了哪些型別、物件如何巢狀組合，以及哪些限制決定最終JSON是否有效。熟悉這種方法後，即使遇到從未看過的SBI服務，也能沿著OpenAPI與資料型別定義逐層分析，而不需要重新背誦整張參數表。
常見問題
哪一份3GPP規範定義SBI共通資料型別？
它們主要定義在TS 29.571《5G System; Common Data Types for Service Based Interfaces》中。此規範定義可在多項SBI服務之間共用的可重複使用資料結構。NF專用服務與資料型別則定義在對應的29.5xx系列規範中，例如SMF服務使用TS 29.502，UDM服務使用TS 29.503。
OpenAPI的nullable屬性在實際JSON訊息中如何呈現？
被定義為nullable的欄位，通常透過帶有Rm後綴的型別實作，可以在JSON主體中明確帶有null值，表示目前沒有有效值被指定。這與欄位完全不存在不同。欄位缺少可能表示該參數不適用或未提供，而明確的null可以具有特定語意，例如清除先前已設定的值。
不同廠商的SBI共通資料型別會不一樣嗎？
在規範層級，這些定義已標準化，但實際產品仍可能出現實作差異。有些廠商可能只實作部分選填欄位，某些API可能包含廠商專用擴充，而對列舉值的驗證嚴格程度也可能不同。這些差異是互通性測試中常見的檢查重點。
如何快速判斷欄位使用的是共通型別還是NF專用型別？
最直接的方法是查看OpenAPI定義中的$ref路徑。如果引用指向TS 29.571所定義的共通schema，通常就是共享的SBI資料型別；如果指向目前服務規範內部定義的schema，一般就是NF專用型別。熟悉SUPI、TAI、S-NSSAI和ProblemDetails等常被重複使用的型別，也能在封包分析時更快辨識。
封包擷取中Rm型別與一般型別有什麼差別？
當數值不是null時，兩者的JSON表示實際上相同，因為它們使用相同的底層格式。差別存在於OpenAPI模型層：Rm型別允許欄位包含null。如果擷取到的欄位明確帶有null值，它必須使用nullable定義；如果欄位帶有一般的有效值，僅憑該值本身無法判斷schema引用的是一般型別還是對應的Rm型別。
