51学通信

深度解析 3GPP TS 29.586：5. Services offered by the SLPKMF (SLPKMF提供的服务)

15分钟阅读

好的，我们立刻进入对3GPP TS 29.586规范第五章的深度剖析。在上一篇中，我们已经明确了SLPKMF的核心职责和以漫游为焦点的架构。现在，我们将详细检视SLPKMF对外提供的两套核心服务，看看它们是如何保障Sidelink定位在不同阶段的安全性的。

深度解析 3GPP TS 29.586：5. Services offered by the SLPKMF (SLPKMF提供的服务)

本文技术原理深度参考了3GPP TS 29.586 V18.1.0 (2024-06) Release 18规范中，第五章“Services offered by the SLPKMF”的全部核心内容。本文旨在为读者深度剖析SLPKMF提供的两大核心服务——Nslpkmf_Discovery和Nslpkmf_SLPKMFKeyRequest，我们将拆解每个服务背后的业务逻辑、服务操作及其在Sidelink定位安全流程中的精确作用。

引言：安全总管的“两把刷子”——发现授权与密钥请求

SLPKMF作为Sidelink定位的“安全总管”，其工作可以清晰地分为两个阶段，对应着它所提供的两大核心服务，也就是它的“两把刷子”：

  1. 第一阶段：准备与发现 (Preparation & Discovery)
    • 任务: 确定谁有资格“加入游戏”。哪些设备可以广播自己的存在？哪些设备可以监听别人？这个阶段的安全由Nslpkmf_Discovery服务来保障。
  2. 第二阶段：执行与通信 (Execution & Communication)
    • 任务: 当两个已获授权的设备准备进行“亲密接触”（一对一精确测距）时，为它们的私密对话提供一把“安全锁”。这个阶段的安全由Nslpkmf_SLPKMFKeyRequest服务来保障。

本篇文章，我们将以V-SLPKMF向H-SLPKMF请求服务为视角，详细剖析这两大服务以及它们包含的四个服务操作，看看一个漫游中的“穿梭者-访客”机器人，是如何在SLPKMF的保驾护航下，一步步安全地融入本地定位网络的。

1. 解读第5.1章 Introduction (引言) - 服务菜单总览

本节通过两张总览表，为我们快速呈现了SLPKMF的服务全貌。

Table 5.1-1: List of SLPKMF Services

ServiceService OperationsOperation SemanticsExample Consumer(s)
Nslpkmf_DiscoveryAnnouncementAuthorizationRequest/ResponseSLPKMF
MonitorAuthorizationRequest/ResponseSLPKMF
DiscoveryAuthorizationRequest/ResponseSLPKMF
Nslpkmf_SLPKMFKeyRequestUnicastKeyRequest/ResponseSLPKMF

核心洞察:

  • 两大服务: 清晰地列出了Nslpkmf_Discovery和Nslpkmf_SLPKMFKeyRequest。
  • 请求/响应模式: 所有服务操作的Operation Semantics都是Request/Response。这表明SLPKMF的服务本质是同步的授权和密钥请求，不存在订阅/通知的异步模式。这非常符合安全业务的特点：我请求，你立即告诉我行不行，并给我凭证。
  • 消费者: Example Consumer(s)明确为SLPKMF，再次印证了本规范聚焦于网间交互。

Table 5.1-2: API Descriptions

这张表将两大服务与其在第六章和附录A中定义的具体API资源和OpenAPI文件进行了映射，是我们后续深入API层面的导航图。

2. 解读第5.2章 Nslpkmf_Discovery Service - “准入安检”

这个服务是Sidelink定位的第一道安全门槛，负责所有与UE发现相关的授权。

3GPP TS 29.586 - 5.2.1 Service Description

This service enables an NF (i.e. another SLPKMF in another PLMN) to request authorization information. The following are the key functionalities…

  • Provide the authorization… for announcing…
  • Provide the discovery key… for monitoring…
  • Provide the discovery key… for a discoverer UE…

2.1 5.2.2.2 AnnouncementAuthorization (广播授权)

The AnnouncementAuthorization service operation is invoked by a NF Service Consumer, i.e. another SLPKMF in another PLMN, towards the SLPKMF to retrieve the authorization from the SLPKMF for announcing in the PLMN.

信令流程 (Figure 5.2.2.2.1-1):

  • 步骤1: V-SLPKMF 发起 PUT 请求
    • 请求: PUT .../{ueId}/announcement-authorization/{userInfoId}
    • 场景链接: “穿梭者-访客-007”需要广播自己。V-SLPKMF向H-SLPKMF发起PUT请求。URI中的ueId是“访客-007”的SUPI/GPSI，userInfoId是一个应用层ID，用于区分同一UE在不同应用下的授权。
    • 请求体 (AnnounceAuthReqData): 包含rangingSlAppId（应用ID）和ueRole（UE角色，如TARGET_UE）。
  • 步骤2: H-SLPKMF 响应
    • 201 Created: 如果这是首次为该userInfoId创建授权，H-SLPKMF会返回201，响应体AnnounceAuthData中包含了授权令牌。
    • 204 No Content: 如果该授权已存在，H-SLPKMF会用新请求的数据更新它，并返回204，表示更新成功但无内容返回。
    • 4xx/5xx: 失败响应，例如403 Forbidden（如果H-SLPKMF判断该用户未签约Sidelink定位服务）。

核心逻辑: 使用PUT的“创建或替换”语义，为“UE+应用”的组合，在H-SLPKMF上创建一个持久化的广播授权资源。

2.2 5.2.2.3 MonitorAuthorization (监控授权)

The MonitorAuthorization service operation is invoked by… another SLPKMF… to retrieve the discovery key from the SLPKMF for monitoring in the PLMN.

信令流程 (Figure 5.2.2.3.1-1):

  • 步骤1: V-SLPKMF 发起 PUT 请求
    • 请求: PUT .../{ueId}/monitor-authorization/{userInfoId}
    • 场景链接: 仓库中的“穿梭者-观察员-01”需要监听“访客-007”的广播。V-SLPKMF会为“观察员-01”向其H-SLPKMF请求监控授权和密钥。这里我们假设“观察员”也可能是漫游的。
    • 请求体 (MonitorAuthReqData): 包含rangingSlAppId, ueRole（如REFERENCE_UE），以及一个关键字段ueSecurityCapability（UE的安全能力），告知H-SLPKMF该UE支持哪些加密算法。
  • 步骤2: H-SLPKMF 响应
    • 201 Created / 204 No Content: 成功时，响应体MonitorAuthRespData中将包含**discSecMaterials（发现安全材料）**，这其中就有所需的密钥。H-SLPKMF会根据“观察员”的安全能力，选择一个双方都支持的算法来生成和加密这些密钥。

核心逻辑: 与广播授权类似，但目的是获取用于“监听”的安全材料。

2.3 5.2.2.4 DiscoveryAuthorization (发现授权)

流程与MonitorAuthorization几乎完全相同，只是URI路径和请求/响应体的数据类型名称不同，专门用于另一种特定的发现模型（Model B restricted discovery）。它同样是为一个“发现者”UE获取进行发现操作所需的密钥。

3. 解读第5.3章 Nslpkmf_SLPKMFKeyRequest Service - “会话密钥”分发

这个服务负责为已相互发现的UE之间建立安全的单播链路提供会话密钥。

3GPP TS 29.586 - 5.3.1 Service Description

This service enables an NF (i.e. another SLPKMF in another PLMN) to request ranging related keying material. The following are the key functionalities…

  • Provide ranging related keying material for unicast communication.

3.1 5.3.2.2 UnicastKey (单播密钥)

The UnicastKey service operation is invoked by a NF Service Consumer, i.e. another SLPKMF in another PLMN, towards the SLPKMF to retrieve the keying material related to ranging.

信令流程 (Figure 5.3.2.2.1-1):

  • 步骤1: V-SLPKMF 发起 POST 请求
    • 请求: POST .../ranging-keys/request
    • 注意: 这是一个自定义操作（Custom Operation）。请求的URI不是指向一个具体的资源，而是指向一个名为request的“动作”。
    • 场景链接: “观察员-01”和“访客-007”准备进行一对一测距。V-SLPKMF需要为这对UE（或其中之一，取决于谁是漫游方）向其H-SLPKMF请求一个会话密钥。
    • 请求体 (UnicastKeyReqData):
      • rangingSlAppId: 应用ID。
      • slpkId: Sidelink定位密钥ID。这是一个关键标识符，用于关联这次密钥请求与之前的授权。
      • kslpFreshnessParameter1: 一个用于防止重放攻击的“新鲜度参数”（Nonce）。
  • 步骤2: H-SLPKMF 响应
    • 200 OK: 成功。
    • 响应体 (UnicastKeyRspData):
      • kslp: Key for Sidelink Positioning，即生成的会话密钥。
      • kslpFreshnessParameter2: H-SLPKMF返回的另一个新鲜度参数，用于双向验证。
    • 4xx/5xx: 失败响应，例如403 Forbidden (UE_NOT_AUTHORIZED)。

核心逻辑: 这是一个典型的RPC（远程过程调用）式的API。V-SLPKMF调用H-SLPKMF的一个“生成单播密钥”函数，并提供必要的参数，H-SLPKMF执行后返回结果。

总结

通过对第五章的深度解读，我们已经清晰地掌握了SLPKMF提供的两大核心服务和四个服务操作的业务逻辑和交互流程。

  1. 分阶段的安全保障:

    • Nslpkmf_Discovery服务通过三个授权操作（广播、监控、发现），为Sidelink定位的准备阶段提供了全面的准入控制。
    • Nslpkmf_SLPKMFKeyRequest服务通过UnicastKey操作，为执行阶段的一对一精确测距提供了链路级的安全保障。

  2. 以授权为核心的资源模型: Discovery服务的API设计，通过PUT方法在H-SLPKMF上创建或更新持久化的授权资源，体现了其“授权即资源”的设计思想。

  3. RPC式的密钥请求: KeyRequest服务的API设计，采用自定义操作（POST .../request）的方式，提供了一种高效、直接的密钥生成服务，更贴近其“函数调用”的业务本质。

我们已经完全理解了SLPKMF的“两把刷子”是如何使用的。在下一篇，也是本系列解读的最终章中，我们将进入第六章“API Definitions”，深入这些API请求和响应的“骨髓”——数据模型，详细解剖构成这些安全交互的每一个JSON对象的具体字段。

FAQ

Q1：AnnouncementAuthorization和MonitorAuthorization为什么都使用PUT方法？ A1：使用PUT方法是为了实现幂等性。一个UE（由ueId和userInfoId唯一标识）在特定应用下的广播或监控授权，在H-SLPKMF上应该只存在一份。无论V-SLPKMF是第一次为它申请（创建），还是因为网络问题重试申请（更新），最终的结果都应该是一样的。PUT的“创建或替换”语义完美地契合了这一需求，可以防止因重试而创建出重复的授权资源。

Q2：DiscoveryAuthorization和MonitorAuthorization有什么区别？ A2：它们都服务于“发现者”角色的UE，为其获取进行发现操作所需的安全材料。其主要区别在于它们所支持的发现模型不同。3GPP定义了多种Sidelink发现模型（如Model A, Model B）。DiscoveryAuthorization专门用于一个名为“Model B restricted discovery”的特定发现流程，而MonitorAuthorization则可能用于更通用的监控场景。具体的差异体现在底层的Sidelink协议（如TS 24.554）中。

Q3：UnicastKey服务操作为什么使用POST自定义操作，而不是PUT或POST到一个资源集合？ A3：因为UnicastKey的业务本质不是管理一个持久化的资源。它更像是一次性的“动作”或“函数调用”：“请立即为我生成一个会话密钥”。这个生成的密钥是临时的，用于一次通信会话，H-SLPKMF可能不会（或不需要）像存储授权那样持久化地存储每一个会话密钥。在这种场景下，使用RPC风格的自定义操作（POST /.../action-name）比严格的RESTful资源模型更能清晰地表达其业务意图。

Q4：在UnicastKey请求中，slpkId这个ID是从哪里来的？ A4：slpkId（Sidelink定位密钥ID）是一个关键的关联标识符。它通常是在之前的发现和授权阶段，由H-SLPKMF生成，并下发给参与定位的UE的。当两个UE需要建立单播链接时，它们会交换这个slpkId。发起密钥请求的一方（通过V-SLPKMF）会将这个ID提交给H-SLPKMF。H-SLPKMF利用这个ID，可以快速地查找到与此相关的授权上下文（例如，确认这两个UE是否都被授权在同一个应用下进行定位），从而做出是否生成会话密钥的决定。

Q5：整个流程中，实际的密钥（如kslp）在空中接口和核心网接口传输时，是明文的吗？ A5：绝对不是。所有Sidelink定位相关的密钥，在任何接口（无论是UE-网络间的Uu接口，还是SLPKMF之间的Nslpkmf接口）上传输时，都必须被加密保护。

  • 在Nslpkmf接口上，整个HTTP/2通信都由TLS保护。此外，密钥材料本身在JSON对象中，也可能会被更上层的安全机制（如JWE - JSON Web Encryption）再次加密。
  • 当网络将密钥下发给UE时，会使用UE与核心网之间已建立的安全上下文（NAS安全密钥）进行加密。
  • 最终，这些密钥被用于保护PC5接口上的Sidelink定位信令。

关系图谱