5G核心網路早已不再只面向人與人之間的通訊。車聯網、智慧工廠、智慧園區、遠距醫療、無人機等各類垂直產業應用，愈來愈希望依據服務狀態動態影響網路資源，或從電信業者取得經授權的網路狀態資訊。如果每出現一項新需求，都需要業者手動修改AMF、SMF、PCF、UDM等網路功能的設定，那麼5G在垂直產業中的大規模部署將非常困難。

這正是NEF（Network Exposure Function，網路開放功能）發揮作用的地方。它位於5GC與應用功能AF之間，將核心網路內部能力轉換為外部應用可使用的標準化介面，同時負責安全控管、資訊轉換與參數傳遞。對第三方應用而言，NEF並不是單純的API閘道，而是進入電信業者5G核心網路能力體系的受控入口。

為什麼5GC需要NEF

4G的商業模式主要面向B2C：網路提供連線，使用者透過行動網際網路存取各種應用。進入5G後，模式進一步擴展至B2B2X。網路不僅要服務個人使用者，也需要與製造、交通、園區、醫療等垂直產業平台進行更深入、更自動化的互動。

這就帶來一個重要問題：產業應用如何在兼顧安全與標準化的前提下使用電信業者的網路能力？

例如，一家工業企業希望特定區域內的生產終端獲得更可預測的QoS，或希望將應用流量導向更靠近工廠的本地資料網路。如果沒有統一的能力開放機制，應用平台可能必須直接連接多個核心網路功能，並針對不同供應商實作不同設定。這不僅會增加整合複雜度，也會暴露更多核心網路內部介面。

NEF在產業應用與5GC之間建立統一邊界。外部AF不需要理解AMF、SMF、PCF、UDM或UPF的每一項內部細節，只要透過NEF提交符合標準的服務請求。之後，NEF會與適當的5GC網路功能互動，並把結果回傳至應用端。

這種方式把原本依賴人工協調與靜態設定的部分需求轉換為標準化服務呼叫，使電信業者能以更自動化的方式向合作夥伴開放網路能力。

NEF在5GC中的位置

NEF部署於5GC網路功能與AF之間。AF是負責商業邏輯的應用層功能實體，可以是電信業者擁有或管理的可信任應用，也可以是位於業者信任網域之外的第三方應用平台。第三方應用不能取得對核心網路內部功能的無限制存取，因此受控互動需要透過NEF完成。

從介面角度看，NEF實際上連接兩個不同環境。北向面向視訊平台、車聯網平台與工業控制系統等AF；南向則連接5GC內部網路功能，並依照所請求的服務與SMF、PCF、UDM等實體通訊。

NEF由4G中的SCEF演進而來，但涵蓋範圍明顯更廣。SCEF主要與特定IoT使用情境相關，而5GC中的NEF支援更廣泛的以人為中心與以機器為中心的應用，已成為服務化能力開放架構中的重要組成。

從設計上看，NEF遠不只是轉送訊息。其核心職責包括開放網路能力與事件、將外部應用提供的資訊安全地佈建至3GPP網路、在外部格式與內部格式之間進行資訊轉換，以及在需要時接收其他網路功能的資料，用於儲存或後續再次開放。

NEF接收的部分資訊可儲存在UDR中，因此不必長期綁定單一NEF執行個體。NEF也可支援PFD功能，為更精準的應用偵測與策略處理提供基礎。

五項關鍵能力如何開放

NEF的價值最終體現在它能開放的服務上。在實際5GC部署中，其主要能力可歸納為五類：QoS開放、網路事件訂閱、流量導向、參數佈建與PFD管理。這些功能對應產業應用與電信業者網路之間最常見的互動需求。

QoS能力開放

QoS能力開放允許合作夥伴應用針對特定服務流請求指定的服務品質。例如，某個視訊應用可能已在既有PDU工作階段上運作。當使用者選擇更高品質的視訊服務時，AF可以透過NEF為該流量請求增強的QoS。

NEF收到請求後，會與PCF等核心網路功能協調。PCF接著執行策略邏輯，並與SMF及其他網路資源配合，為該服務流建立適當的QoS處理。

重點不是單純替裝置增加頻寬，而是讓應用透過標準化介面表達服務需求，同時仍由5GC掌握策略決策與網路資源執行。

移動性與網路事件訂閱

第三方AF也可以透過NEF訂閱與UE相關的網路事件，例如UE是否失去連線、是否重新可達、目前或最後已知位置、漫遊狀態、通訊失敗原因，以及下行資料傳遞狀態等。

這些事件由不同的核心網路功能偵測。AMF可偵測UE可達性、連線中斷和部分通訊故障；UDM可提供漫遊狀態或特定身分關聯變更等資訊；SMF則可回報與下行資料傳遞相關的狀態。

AF不需要直接連接每一個網路功能，而是透過NEF建立事件訂閱。NEF再與相關網路功能建立所需的內部訂閱。當目標事件發生時，核心網路通知NEF，NEF再依照訂閱把事件通知轉送給外部AF。

這項機制特別適合需要依據裝置狀態觸發自動化商業邏輯的產業應用。外部平台無須持續輪詢網路查詢UE狀態，而可在相關事件真正發生時收到通知。

流量導向

NEF也可接收AF發出的Traffic Influence請求，將特定UE或服務的流量導向Local DN（Local Data Network，本地資料網路）。Local DN以DNAI識別，通常與邊緣運算或區域化部署的服務相關。

例如在自動化工廠中，工業控制伺服器可能部署在靠近生產現場的本地網路內。應用平台可以透過NEF請求5GC調整使用者平面路徑，使相關裝置流量被路由至適當的Local DN。

NEF不會直接控制UPF，而是把需求送入策略控制流程。之後由PCF和SMF處理策略與使用者平面設定。視實際情況，SMF可重新選擇UPF，或在現有路徑中新增、替換或移除UPF，以完成流量導向。

安全參數佈建

外部AF也可透過NEF向5GC提供某些與使用者相關的參數，但這並不表示應用可以自由修改核心網路參數。可佈建資訊的範圍受到嚴格控管。

典型範例包括Expected UE Behaviour（預期UE行為）與選定的Network Configuration Parameters（網路設定參數）。預期UE行為可描述裝置預期的移動特性；網路設定參數則可能包含最大回應時間、可接受的下行資料傳輸延遲，或UE不可達時建議緩衝的下行封包數量等資訊。

NEF把經授權的參數請求轉送給UDM，UDM與UDR配合讀取及更新相關資料。已訂閱這些資料變更的AMF或其他網路功能，之後即可接收更新後的參數，用於後續網路處理。

PFD管理

PFD（Packet Flow Description，封包流描述）可理解為一組用於應用偵測的規則。第三方AF可以透過NEF建立應用識別資訊，產生的規則可儲存在UDR中，由SMF透過NEF取得，再下發給UPF進行應用偵測。

相較於只依靠基本連接埠或位址識別流量，PFD可以描述更具體的應用特徵。例如，某個視訊服務可透過特定URL模式或其他流量特徵識別，使網路能更精準地將流量對應至適當的策略處理規則。

NEF真正的技術價值

從架構角度來看，NEF最重要的角色並不是增加另一個轉送節點，而是建立可管理的能力開放層。外部AF看到的是服務導向介面，而5GC內部的實際工作仍由PCF策略控制、SMF工作階段管理、UDM資料管理與UPF使用者平面處理等功能完成。

因此，NEF不應被視為一般API閘道。它必須理解外部商業請求與3GPP核心網路能力之間的關係，同時處理兩側之間的安全控管、資訊轉換與流程協調。

NEF也不會取代其他網路功能。QoS執行仍依賴策略控制與工作階段資源設定；網路事件仍由適當的NF偵測；使用者平面路徑仍由SMF等功能調整；使用者相關資料仍由UDM與UDR維護。NEF的角色是以受控且標準化的方式開放這些內部能力。

這項能力對5G B2B2X服務尤其重要。產業應用無須理解5GC完整的內部拓撲，也無須為每個網路功能建立專有介面，只需透過標準化開放機制提交網路需求。同時，電信業者仍掌握核心網路邊界控制權，並把選定的網路能力轉化為可信任合作夥伴可使用的服務。

實際上，NEF協助5G核心網路從主要提供連線的網路，演進為能直接向產業應用開放網路能力的平台。

常見問題

所有AF都必須部署在電信業者網路之外嗎？

不是。AF可以是電信業者擁有或管理的可信任應用，也可以是位於業者信任網域之外的第三方應用。不同類型AF的存取方式與安全處理方式可能不同。

商業資料是否都會儲存在NEF本機？

不是。NEF接收的部分資訊可以儲存在UDR中，之後再由其他網路功能或後續程序使用。因此，資料儲存不需要始終綁定單一NEF執行個體。

Local DN和UPF是相同的概念嗎？

不是。Local DN是承載特定應用或資料服務的本地資料網路，而UPF是5GC中的使用者平面網路功能。流量可以透過適當的UPF路徑到達指定Local DN，但兩者扮演不同角色。

UPF會自行建立PFD規則嗎？

不會。PFD規則可以由AF提供並透過NEF管理。SMF取得相關規則後，再將其下發給UPF，以便在使用者平面中進行更精準的應用偵測。