本文目標：

• 認識 PFCP 協定
• 使用三方套件構造 PFCP 訊息

進入正題

PFCP 主要用於 UPF 與 SMF 之間的 N4 Interface，任何與 PFCP 有關的資料都可以在 3GPP TS 29.244 找到。

補充：

• PFCP 採用 TLV（Tag + Length + Value = TLV）進行編碼，TLV 對訊息的壓縮很有幫助，只要將 Protocol 定義好就不需要用額外的 metadate 來描述資料。
• 處理 PFCP 時需要特別注意網路端與本地端的排序方式是否一致（大端或是小端）

Protocol Stack

下圖為 PFCP 的 Protocol Stack：

上圖為 PFCP 的 Protocol Stack，CP Function（SMF）與 UP Function（UPF）使用 N4 interface 傳遞 PDU Session 需要使用的 flow rule。
SMF 在某些情況下需要修改 PDU Session 的資訊（接收到 NAS-SM 訊息或是收到 PCF 的 policy decision 時，這個部分已經在先前的文章中探討過），當 SMF 持有的 PDU Session 資訊被更動，SMF 會向 UPF 發出 Session Modification Request 來更新 UPF 端的 flow rule。

PFCP Message

參考上圖，每個 PFCP 訊息都需要遵守這個格式。

• Bit 0: SEID flag

• if S = 0, SEID field is not present, k = 0, m = 0 and n = 5
• if S = 1, SEID field is present, k = 1, m = 5 and n = 13.

• Bit 1: MP (message priority)
• Bit 2 - 4: Spare part
• Bit 5 - 7: Version

PFCP message 由一個 message header + 零至多個 Information Element 組合而成。

至於一個 PFCP message 到底會帶有多少個 IE 則取決於該訊息的用途，像是:

• PFCP Heartbeat Request/Response
• PFCP Association Setup Request/Response
• PFCP Session Establishment Request/Response
• ...
  PFCP message 有 50 多種，不同 message 需要的 IE 都已經詳細定義在 TS 29.244。

PFCP message type

PFCP message 主要可分為兩大類:

1. Node related PFCP message

• PFD 相關的訊息主要涉及 Traffic influence，不在本系列文探討的範圍內。

• 根據 TS 29.244 定義，SMF 與 UPF 只會處理有與之建立 N4 Association 的 Node，所以在 UPF 或是 SMF 啟動時，通常會由其中一方向對方發起 N4 Association Setup Request。

流程圖與相關定義在 TS 23.502 Clause 4.4.3。

2. Session related PFCP message

• 用於讓 SMF 向 UPF 建立/刪除/更新 PDU Session 對應到的 flow rule 所使用的訊息。
• 如果 MP = 1，第 16 段的 Bit 4 - 7 就會用來表示 Priority。

SMF 行為

參考 TS 29.244 Clause 5.8.2。

當 Association 建立後，CP 的行為如下:

• 必須提供 UP function（UPF）任何 node related parameters, e.g. PFDs
• 必須提供 UP 一個 CP（SMF）支援的功能列表 (e.g. support of load and/or overload control)
• 發起 Heartbeat procedure（用於檢測 UPF 是否保持運作狀態）。
• 在 UP function 建立 PFCP sessions。
• 如果 UPF 表示它要關機了，CP 應避免建立任何新的 PFCP Session（graceful shutdown）。

UPF 行為

當 Association 建立後，UP 的行為如下:

• 必須向 CP function 更新其所支援的功能
• 如果 UP 與 CP 支援 load and/or overload control，必須向 CP function 更新其 load and/or overload control information。
• 必須接受來自 CP function 的 PFCP Session related messages。
• 回應 Heartbeat procedure
• 如果 UP 即將 out of service，必須告知 CP。
• 如果 CP function 支援 e UE IP Address Usage Reporting feature 且 UE 的 IP 由 UP 所分配，UP 應該向 CP 回報 t UE IP address usage information。

相關專案介紹

go-pfcp 是一套開源的 pfcp 套件，只要使用這個 Go package 就能快速的構造 PFCP 請求。
目前 go-pfcp 已經實作了 TS 29.244 R16 提到的多數 Procedure 與 Information Element，如果想要進一步了解如何 PFCP 訊息的話，參考該專案的原始程式碼會是一個不錯的選擇！

使用案例

如果要構造一個 Association Req，可以這樣做：

import (
	"time"

	"github.com/wmnsk/go-pfcp/ie"
	"github.com/wmnsk/go-pfcp/message"
)

req := message.NewAssociationSetupRequest(seq,
  ie.NewNodeID("", "", "go-pfcp.epc.3gppnetwork.org"),
  ie.NewRecoveryTimeStamp(time.Now()),
  ie.NewUserPlaneIPResourceInformation(0x71, 15, "127.0.0.1", "", "some.instance.example", ie.SrcInterfaceAccess),
)

以 Association Req 中的 IE User Plane IP Resource Information 來看，從 NewUserPlaneIPResourceInformation() 函式來觀察每一個參數分別代表什麼：

func NewUserPlaneIPResourceInformation(flags uint8, tRange uint8, v4, v6, ni string, si uint8) *IE {
	fields := NewUserPlaneIPResourceInformationFields(flags, tRange, v4, v6, ni, si)
	b, err := fields.Marshal()
	if err != nil {
		return nil
	}

	return New(UserPlaneIPResourceInformation, b)
}

上面的函式需要傳入 flags、tRange、v4、v6、ni 以及 si 這些 payload，我們可以對照 3GPP TS 29.244 中的說明理解每一個 payload 的意義：

• flags 代表上圖中 Octets 5 的資料，將 0x71 轉為二進制為 01110001 後，我們可以逐一對照每個 Bit 所代表的意義：
  • Bit 8 為 Spare Part，所以為 0。
  • Bit 7 表示 ASSOSI，如果我們會在這個 IE 中表示 Associated Source Interface，那麼則設定為 1。
  • Bit 6 表示 ASSONI，如果我們會在這個 IE 中表示 Network Instance，那麼則設定為 1。
  • Bit 3 到 5 表示 TEID Range，上面的程式範例中該值為 100，即為 4。
  • Bit 2 表示是否包含 IPv6，上面的程式範例中不會傳入 IPv6 位址，所以該值為 0。
  • Bit 1 表示是否包含 IPv4，上面的程式範例中包含 IPv4 位址，所以該值為 1。

總結

今天一口氣發了兩篇文章將 NGAP 與 PFCP 的部分結束掉了，等到 Data link layer 也介紹給大家後，會把重點放在核心網路運作時會碰到的大型流程（探討主要流程 + 仔細的閱讀規格書如何定義一個流程），將核心網路的基本觀念帶給大家後，系列文就可以進入到雲原生相關的議題討論啦！