3GPP_ISAC_感測結果的最後一哩_SA6應用致能層與網路API生態
感測結果的最後一哩
SA6 悄悄完成接力：TR 23.700-15 結案、TS 23.138 啟動，網路 API 生態已經跑在規範前面
一、本週焦點
上週本專欄以 3GPP 官方技術頁 2026 年 8 月 18 日發布的跨工作群組清單為主軸，盤點 ISAC 規範版圖。若回頭細看那份清單會發現一處空缺：清單列出 SA1 的服務需求、SA2 的架構研究與規範、SA3 的安全研究、CT3 與 CT4 的協定文件、RAN1 與 RAN3 的無線研究，以及 RAN3 的 Ns 規範族，唯獨沒有 SA6 [1]。但翻查 3GPP 規範資料庫可知，SA6 的感測工作不僅存在，且已完成一輪研究並開出規範性文件。研究報告 TR 23.700-15，標題為 Study on Use of sensing results for Vertical Applications，已於 2026 年 3 月 16 日轉入變更控制狀態，並於 SA#112 全會以 V20.1.0 帶入五件變更請求 [2]；規範性文件 TS 23.138 則於 2026 年 3 月 27 日建號，V0.1.0 於 SA6#73 會議 2026 年 5 月 27 日上傳，目前為草稿狀態 [3]。
這件事之所以值得一整篇的篇幅，在於它補上了感測服務鏈路上最後一段沒人談的環節。上週報導所整理的 TS 23.137 把核心網側的事情做完了：感測功能 SenF 選定感測實體、聚合資料、產生結果，經網路開放功能 NEF 以訂閱與通知模型送給應用功能 [5]。但送出去的是什麼？TS 23.137 的感測結果表目前只有報告識別碼與感測服務結果兩個欄位，欄位擴充標示為待研究，結果顆粒度等級如何映射到服務請求則待與 RAN3 協調 [5]。核心網把管線鋪到了門口，門後面的事情由誰定義，正是 SA6 這一層的職責。一個垂直應用除了要有回波量測外，也要有可以直接餵進業務邏輯的判斷，這中間的落差就是本篇所稱的最後一哩。
本專欄2026 年 6 月 6 日報導程序標準化與垂直應用，追問 SA6 研究項目 SP-250875 最終確立的感測結果應用程式介面框架，包括資料格式標準是否達成共識，以及如何透過共通應用程式介面框架 (Common API Framework, CAPIF) 對垂直應用開放。上週的規範報導確認核心網側的模型已定型為訂閱與通知，但 SA6 側如何與該路徑分工仍未公布。本週的答案是：SA6 的研究已經結案，規範性文件已經開號，只是尚未進入官方對外的進度盤點。
二、SA6 的接力：從 TR 23.700-15 到 TS 23.138
開始前，我們先把時間線與工作項目對應清楚。研究項目描述 SP-250875，標題為 Study on Utilization of Sensing Results for Vertical Applications，於 2025 年 6 月布拉格 TSG SA#108 全會與其他六項 SA6 研究一併核准 [4]。對應的研究報告 TR 23.700-15（即 TS 23.138 的前身）於 2025 年 7 月 14 日建號，工作項目代號 FS_Sensing_APP，識別碼 1080028，主責群組為 SA6，報告人先後由 Yang Li 與中興通訊的 Wei Luo 擔任 [2]。研究進程走得相當緊湊：V0.1.0 於 SA6#68 (2025 年 9 月)、V0.2.0 於 SA6#69、V0.3.0 於 SA6#70、V1.0.0 於 SA#110 (2025 年 12 月，文號 SP-251459)、V1.1.0 於 SA6#71、V2.0.0 於 SA#111 (文號 SP-260185)，最終於 2026 年 3 月 16 日轉入變更控制，出版版本 V20.0.0 於同月 30 日上傳 [2]。
規範性工作幾乎無縫接上。TS 23.138 於研究結案後十一天建號，工作項目代號 Sensing-APP，識別碼 1110051，主責群組同為 SA6，報告人為中興通訊的 Lijuan Chen [3]。這個銜接節奏與核心網側高度平行：SA2 的 TR 23.700-14 同樣於 2026 年 3 月 16 日轉入變更控制，同一場 SA#111 全會核准工作項目 SP-260297 開出 TS 23.137 [5]。換言之，2026 年 3 月的那場全會不只是核心網感測由研究轉入規範的分水嶺，應用致能層在同一時點做了同樣的動作，只是外界關注度低得多。
|
項目 |
TR 23.700-15 |
TS 23.138 |
|
文件標題 |
Study on Use of sensing results for Vertical Applications |
Use of sensing results for Vertical Applications |
|
文件類型 |
技術報告，研究階段 |
技術規範，規範性階段 |
|
工作項目 |
FS_Sensing_APP，識別碼 1080028，研究項目描述 SP-250875 |
Sensing-APP，識別碼 1110051 |
|
建號日期 |
2025 年 7 月 14 日 |
2026 年 3 月 27 日 |
|
版本進程 |
V0.1.0 (SA6#68) 起，至 V20.1.0 (SA#112，2026-07-05)，含五件變更請求 |
V0.0.0 (SA6#72)、V0.1.0 (SA6#73，2026-05-27)；截稿後另有 V0.2.0 (SA6#74，2026-09-02) 與 V1.0.0 (SA#113，2026-09-08) |
|
目前狀態 |
已於 2026-03-16 轉入變更控制，研究結案 |
草稿階段（V1.0.0 已提交 SA#113） |
三、NEF 之外：應用致能層要補的三件事
要理解 SA6 這一層存在的必要性，得先回到 3GPP 北向開放的既有分工。NEF 開放的是網路能力，其消費者在規範語言中是應用功能；而 SA6 所定義的服務致能架構層 (Service Enabler Architecture Layer, SEAL) 與 CAPIF，處理的是應用程式如何被納管、被授權、被計費，以及不同垂直產業之間如何共用同一套致能服務 [6][10]。CAPIF 自 Release 15 起就被定位為存取 3GPP 北向應用程式介面的統一框架 [6]；其核心功能 (CAPIF Core Function) 是所有應用程式介面的中央存放處，負責呼叫者的登錄與除役、介面的發布與探索、認證與授權，以及記錄與計費相關事項，使 NEF 與 SEAL 的各式介面對外呈現單一入口 [10]。感測結果若要成為可販售、可稽核、可跨產業重用的服務，這一層無法跳過。
3.1 授權模型的錯位：感測目標沒有資源擁有者
第一件要補的事牽涉授權，而且是本篇認為最值得工程讀者留意的結構性落差。3GPP 在 Release 18 的 CAPIF 增強工作中引入資源擁有者感知的北向應用程式介面存取 (Resource owner-aware Northbound API Access, RNAA)，其設計前提是：當應用程式介面在某位資源擁有者的脈絡下被呼叫時，該資源擁有者應有機會同意或拒絕。為此 CAPIF 架構新增資源擁有者用戶端與授權功能兩個功能實體，前者通常是資源擁有者終端上的用戶端應用，由真人以允許或拒絕的方式行使控制 [6]。官方文件所舉的範例是遊戲服務的服務品質調整：無論由終端上的遊戲用戶端發起，或由遊戲伺服器代為發起，受影響的終端使用者都能在被計費之前決定是否接受 [6]。
把這套模型套到感測上會立刻出現錯位。感測服務的請求對象是一塊區域或一段空域，其量測目標是非協作、無身分的被動物體，本專欄 2026 年 8 月 1 日的 SA1 使用情境全譜報導已從需求層說明這項特性的來源。被感測者通常不是網路的用戶，沒有終端，因而不存在可以彈出同意提示的資源擁有者用戶端。RNAA 所建立的同意鏈在感測情境中找不到落點。TS 23.137 的處理方式是把管制上移到運營商側：SenF 依預先設定或由維運系統設定的授權資訊逐案判斷，欄位包含應用功能識別碼、允許的感測服務類型、允許或不允許的區域、以及允許的時段 [5]。這是一種以區域與時段為單位的行政式管制，而非以個人同意為基礎的授權。兩種模型可以並存，但它們回答的不是同一個問題，感測服務的應用層規範是否需要另立一套針對非用戶的政策執行點，目前無官方文本可據。
3.2 跨網探索與多營運商情境
第二件事是跨網。CAPIF 的 RNAA 增強已經處理過一個結構相近的問題：應用程式介面呼叫者可能服務分屬不同公用陸地行動網路的終端，因此框架需支援呼叫者在多網環境中找到正確的開放功能 [6]。感測面對的是同一類需求的加強版。一個橫跨數個營運商涵蓋範圍的感測區域，其請求必須被拆解、分派、再把結果彙整回單一視圖，而這個彙整點在規範上目前無處安放。TS 23.137 V0.3.0 明文要求 SenF 與擔任感測實體的 gNB 必須部署於同一公用陸地行動網路之內，跨營運商感測不在 Release 20 範圍 [5]。應用層若要提供跨網感測，只能在 3GPP 邊界之外自行處理。
3.3 結果格式與資料模型
第三件事是資料格式本身：目標物件描述、座標系與不確定度的表達方式是否達成共識。TS 23.137 在請求方向已相當具體，外部目標感測區域以通用地理區域描述的形狀表示並可附加高度範圍，感測效能參數引用 TS 22.137 的定位估計精度、速度估計精度、漏偵測率與誤警率四項 [5]。但回報方向仍停留在兩個欄位，且未見與座標系或不確定度表達相關的條款 [5]。這正是 TS 23.138 的用武之地，也是本專欄後續應追蹤的內容。在 V0.1.0 之後的版本公布之前，任何關於其資料模型設計的推論都缺乏依據。
四、顆粒度階梯：結果要多細，決定介面切在哪裡
資料格式之所以難談，根源在於感測結果沒有唯一的正確顆粒度。這組分級不是外部評論者的發明，而是 RAN 側研究本身的用語：TR 38.765 第 5.1 節從實體層角度列出可由無線接取網路回報的量測，定為 Level A 至 Level D，由原始資料逐級收斂至物件／目標級量測 [11]。一份 2026 年 8 月 12 日發布的單一作者綜述在整理 3GPP 感測標準化進程時，也以同一組四級抽象說明介面切點的取捨 [9]。須留意 TR 38.765 屬研究階段文件，這組層級尚未寫入規範性文件，但當成理解介面切點的框架相當有用；下表後兩欄的跨節點融合空間與典型消費端，則是本文的分析而非該研究的結論。
|
抽象層級 |
內容 |
傳輸負擔 |
跨節點融合空間 |
典型消費端 |
|
樣本級 |
原始數位化無線觀測值 |
最高 |
最大 |
無線側或邊緣處理節點 |
|
參數剖面級 |
時延、都卜勒或角度的振幅與相位剖面 |
高 |
大，適合多節點融合 |
核心網感測處理功能 |
|
偵測點級 |
距離、速度、角度構成的偵測清單，無身分 |
中 |
中 |
感測結果聚合端 |
|
物件級 |
位置、三維速度、功率與信心度量的物件級量測 |
最低 |
最小 |
垂直應用 |
這張表把先前幾則報導的爭議串成一條線。往上看，抽象層級愈低則傳輸負擔愈重，這正是本專欄 2026 年 6 月 20 日 O-RAN 報導所整理的、學界批評既有控制面介面不足以承載次毫秒尺度資料的原因，也是 RAN3 必須為 Ns 另立第一層與訊令傳輸兩份專門規範的動機。往下看，抽象層級愈高則跨節點融合的空間愈小，因為航跡一旦形成，來自不同基地台的觀測就無法再回頭合併。介面該切在哪一級，因此不是純粹的效率問題，而是決定了誰有能力做多站融合、誰只能消費成品。
在此基礎上再看 3GPP 目前的分工，佈局便清楚了。TS 23.137 把 SenF 的職責寫為接收一個或多個感測實體的資料並予以聚合、處理，再產生感測結果 [5]，意即參數剖面級到偵測點級的融合工作留在核心網之內；而對外開放的感測服務結果，其顆粒度等級如何映射到請求，則明白標示為待與 RAN3 協調 [5]。應用層的 TS 23.138 若採物件級為主要對外形態，垂直應用得到的是最容易消費也最難二次加工的形式；若允許較低層級輸出，則整個授權與隱私問題會隨資料的原始程度而放大。這是一個尚未公開結論的設計取捨。
五、生態現況：商業側已經跑在規範前面
把視角從規範移到市場，會看到一個節奏相反的畫面。GSMA 於 2026 年世界行動通訊大會期間發布的統計顯示，Open Gateway 倡議已有 86 個營運商集團參與，涵蓋逾 300 張網路與全球八成的行動連線；商業化方面，20 種 CAMARA 應用程式介面已在 65 個市場完成逾 300 個商業實例部署，並有逾 60 家通路夥伴，包含超大規模雲端業者、聚合平台與通訊平台服務商參與商業化 [8]。GSMA 把這套規模歸因於兩件事：解決長年的碎片化問題、促成跨營運商一致的行為，以及以 CAMARA 標準化介面讓開發者能跨市場一致部署，也就是該文所稱的「一次撰寫、處處部署」；而聚合平台與通訊平台服務商，則與超大規模雲端業者並列在那逾 60 家通路夥伴之中 [8]。
這個趨勢與感測服務的規範現況正好對撞。Ericsson 在其技術評論的感測架構專文中，把感測服務的商業實現拆為服務開放框架、業務支援系統與管理能力三塊：開放框架負責受理請求、認證授權、施加隱私與客戶政策，並由應用程式介面閘道擔任存取控制與流量限制的執行點；業務支援系統負責夥伴管理與商業管理，以承接系統整合商為特定垂直產業加值的合作模式；而當感興趣的區域跨越多張公用陸地行動網路，甚至跨越國界時，該文明白主張引入聚合者，位於營運商的服務開放與感測用戶端之間，彙整多家營運商的應用程式介面，並指出這套聚合者模型可以建立在 CAMARA 等產業論壇進行中的應用程式介面規範工作之上 [7]。
相對而言，規範側尚未為這條路徑提供支撐。如前所述，Release 20 的架構把感測服務限制在單一公用陸地行動網路之內 [5]，因此業界所設想的跨網聚合在 3GPP 文本中沒有對應的介面或程序。這並不表示業界的主張不成立，只表示其實現目前必須落在標準之外的商業層。兩種讀法都有道理：從規範制定的角度看，先把單網單站的基本情境做扎實，再談跨網彙整，是控制風險的合理次序；從生態建構的角度看，網路應用程式介面市場已經證明跨營運商一致性才是開發者採用的前提，感測若在這一點上落後，可能重蹈早期網路能力開放各自為政的覆轍。本專欄不對兩者孰輕孰重做判斷，但值得指出的是，這兩種節奏差的收斂點很可能不在 Release 20，而在 Release 21 的 6G 架構研究。
另一個值得記下的觀察是 GSMA 對下一階段的描述。該文指出，以 Telefónica 與 Nokia 的合作試點為首，業界正以代理人對代理人協定 (Agent-to-Agent, A2A) 與模型脈絡協定 (Model Context Protocol, MCP) 進行試驗，讓自主軟體代理人自動完成應用程式介面的探索、網路能力的選用、多支介面的串接與權限查核 [8]。若這條路徑成形，感測服務的消費方式將不再是人工整合的固定呼叫，而是由代理人依任務目標動態組裝，那麼結果顆粒度、不確定度標示與授權範圍就必須被機器可讀地表達出來。這使得第四節所談的抽象分級與第三節所談的授權模型，從純規範議題變成生態議題。此為對產業趨勢的推論，非 3GPP 官方立場。
六、展望與追蹤
官方時程本週無異動，Release 20 第二階段採兩段式時程，2026 年 6 月達成八成完成度，百分之百凍結目標維持在 2026 年 9 月 [12]。對本篇主題而言，最近的具體節點有二：其一是 TS 23.137 於凍結版本中是否補齊感測結果欄位與顆粒度映射，這決定了應用層可以拿到什麼 [5]；其二是 TS 23.138 在 SA6#74 之後的版本推進，以及 TR 23.700-15 於 SA#112 帶入的五件變更請求所修正的內容 [2][3]，後者是研究結論在結案後仍持續調整的訊號，通常反映與其他工作群組的對齊尚未完成。
截稿後更新（2026 年 9 月 12 日查核）：上述第二個節點已有動作。TS 23.138 於 SA6#74 推出 V0.2.0（2026 年 9 月 2 日），並以 V1.0.0 於 9 月 8 日隨 SP-260874 提交 SA#113 審議 [3]；TS 23.137 亦於 9 月 7 日上傳 SA2#176 的 V0.4.0，並以 V1.0.0 隨 SP-260754（MCC 編輯性更新）提交 SA#113 [5]。本文所引 TS 23.137 條文出自 V0.3.0，感測結果欄位在 V0.4.0 之後是否已擴充，須俟該版本核對後另行說明。
後續可關注的方向：
1. TS 23.138 後續版本的資料模型設計，包含感測結果的目標物件描述、座標系、不確定度表達，以及是否定義獨立於 TS 23.137 的應用層感測結果格式。
2. TS 23.138 與 CAPIF 的整合方式，特別是感測服務應用程式介面是否登錄於 CAPIF 核心功能之下，以及是否沿用或另立資源擁有者授權模型以處理非用戶被感測者。
3. TR 23.700-15 於 SA#112 帶入的五件變更請求所修正的內容，及其反映的跨工作群組對齊議題。
4. 感測結果四級抽象是否被 3GPP 採為規範性用語，以及對外開放的顆粒度等級最終切在哪一級。
5. 跨營運商感測的彙整機制是否於 Release 21 的 6G 架構研究中取得規範地位，或持續由商業聚合平台在標準之外承擔。
6. SA6 的感測工作是否被納入 3GPP 官方對外的 ISAC 進度盤點，作為判斷應用層工作成熟度的間接指標。
資料來源
[1] 3GPP 官方技術頁，ISAC Architecture Progress in 3GPP，2026 年 8 月 18 日發布 (截至 2026 年 7 月的跨工作群組 5G-A 感測進度清單，未列 SA6) https://www.3gpp.org/technologies/isac-arch
[2] 3GPP 規範資料庫，TR 23.700-15 Study on Use of sensing results for Vertical Applications 規格頁 (SA6 主責，Release 20，工作項目 FS_Sensing_APP，2026-03-16 轉入變更控制，V20.1.0 於 SA#112) https://www.3gpp.org/dynareport/23700-15.htm
[3] 3GPP 規範資料庫，TS 23.138 Use of sensing results for Vertical Applications 規格頁 (SA6 主責，Release 20，工作項目 Sensing-APP，報告人 Lijuan Chen；本文引用之 V0.1.0 於 SA6#73；截稿後已推進至 V0.2.0 與 V1.0.0，狀態仍為草稿) https://www.3gpp.org/dynareport/23138.htm
[4] 3GPP SP-250875，TSG SA#108 全會文件，SA6 研究項目描述 Study on Utilization of Sensing Results for Vertical Applications (2025 年 6 月布拉格核准) https://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_108_Prague_2025-06/Docs/SP-250875.zip
[5] 3GPP，TS 23.137 Integrated Sensing and Communication; Stage 2，V0.3.0 (SA2#175，2026-06-05)；本文引用之 SenF 職責、授權資訊欄位、感測服務請求與結果欄位、同一公用陸地行動網路限制均出自該版本。截稿後另有 V0.4.0 (SA2#176) 與提交 SA#113 的 V1.0.0，本文未據以更新。規格頁： https://www.3gpp.org/dynareport/23137.htm
[6] 3GPP 官方技術頁，3GPP CAPIF Framework - RNAA (SA6 主席與報告人撰文，說明 TS 23.222 之 CAPIF 定位、資源擁有者用戶端與授權功能、多網探索) https://www.3gpp.org/technologies/rnaa
[7] R. Keller, L. Olsson, J. Arkko, G. Rune, T. Cagenius，Sensing in 6G: Use cases and architecture，Ericsson Technology Review，2025 年 10 月 23 日 (業界技術文章，提出 6G 端到端感測架構；感測服務開放框架、業務支援系統與跨營運商聚合者模型) https://www.ericsson.com/en/reports-and-papers/ericsson-technology-review/articles/sensing-in-6g-use-cases-and-architecture
[8] GSMA，From Ambition to Execution: How Open Gateway Is Scaling the Global API Economy (產業組織文章，Open Gateway 與 CAMARA 商業化統計、聚合平台趨勢與代理人式應用程式介面消費) https://www.gsma.com/newsroom/article/from-ambition-to-execution-how-open-gateway-is-scaling-the-global-api-economy/
[9] X. Lin，Integrated Sensing and Communication in 3GPP: Evolution from 5G-Advanced to 6G，arXiv:2608.11606 (2026 年 8 月 12 日，單一作者學術綜述；四級抽象之原始出處為 TR 38.765 第 5.1 節，見 [11]) https://arxiv.org/abs/2608.11606
[10] 3GPP 官方新聞頁，3GPP SA6 initiatives to enable new vertical applications (CAPIF 於 Release 15 交付；核心功能 CCF 作為所有應用程式介面的中央存放處，負責登錄、探索、認證與記錄計費；對應規範 TS 23.222) https://www.3gpp.org/news-events/3gpp-news/sa6-verticals2
[11] 3GPP，TR 38.765 V1.0.0 (2026-02) Study on Integrated Sensing And Communication (ISAC) for NR，第 5.1 節 Level A 至 Level D 量測層級定義 (RAN1 主責，研究階段文件)。規格頁： https://www.3gpp.org/dynareport/38765.htm
[12] 3GPP 官方 Release 20 說明頁，Rel-20 5G-Advanced 階段時程 (Stage 2 兩段式：2026 年 6 月八成完成度、2026 年 9 月最終凍結；頁面所載資料來源為 2026 年 3 月 Work Plan) https://www.3gpp.org/specifications-technologies/releases/release-20
