51学通信

深度解析 3GPP TS 29.586：Sidelink定位密钥管理 (SLPKMF) 总体架构与核心功能

18分钟阅读

好的，我们立刻开启全新的3GPP规范深度解读系列。这次的目标是 3GPP TS 29.586，一份定义5G系统中一个新兴且关键领域——Sidelink定位密钥管理服务 (SideLink Positioning Key Management Services) 的规范。

按照我们的既定规则，第一篇文章将是对这份规范进行一次全景式的鸟瞰，帮助大家理解它的核心价值、所处的生态位以及它要解决的关键问题。

深度解析 3GPP TS 29.586：Sidelink定位密钥管理 (SLPKMF) 总体架构与核心功能

本文技术原理深度参考了3GPP TS 29.586 V18.1.0 (2024-06) Release 18规范，旨在为读者提供一个关于5G系统中“Sidelink定位密钥管理功能（SLPKMF）”及其服务化接口的全景视图。我们将揭示该服务如何在创新的Sidelink定位场景中，扮演“安全管家”和“密钥总管”的关键角色，确保设备间直接通信的定位过程既精准又安全。

引言：当5G定位遇上“Sidelink”——安全挑战催生新角色

5G不仅仅是更快的网速，它还带来了许多革命性的新能力，其中“高精度定位”和“Sidelink通信”是备受瞩目的两大特性。

  • 高精度定位: 5G网络本身能够实现亚米级甚至厘米级的定位精度，远超传统的GPS。
  • Sidelink (或称PC5接口): 允许终端设备（UE）之间不经过基站，直接进行通信。这在车联网（V2X）、公共安全、工业物联网等场景中至关重要。

当这两大特性结合，便催生了“Sidelink定位”：一组UE可以利用它们之间的Sidelink直连信号，进行相互测距（ranging）和定位，即使在没有基站信号覆盖的区域（如隧道、地下停车场）也能实现高精度定位。

但这带来了一个严峻的安全挑战：在开放的无线环境中，任何设备都可以监听Sidelink信号。如何确保：

  1. 只有经过授权的设备才能发起或参与定位？
  2. 定位信令本身不被窃听或篡改？
  3. 一个设备的位置信息不被恶意的“邻居”设备非法获取？

为了解决这些安全问题，3GPP引入了一个全新的网络功能——SLPKMF (SideLink Positioning Key Management Function)，即Sidelink定位密钥管理功能。而我们今天要解读的 3GPP TS 29.586 规范，正是定义这个SLPKMF如何对外提供密钥管理和授权服务的Stage 3“施工图”。

接下来，我们将设定一个生动的场景：在一个大型自动化仓库中，一群名为“穿梭者”的自主移动机器人（AMR），需要通过Sidelink定位技术，在室内实现厘米级的协同作业。我们将跟随这些机器人，一步步揭开SLPKMF这位“安全总管”的神秘面纱。

1. SLPKMF的核心价值与诞生背景

在深入技术细节前，我们必须理解SLPKMF为何而生。

3GPP TS 29.586 - Chapter 1: Scope

The present document specifies the stage 3 protocol and data model for the Nslpkmf Service Based Interface to support ranging based service and sidelink positioning in 5G system. It provides stage 3 protocol definitions and message flows, and specifies the API for each service offered by the SLPKMF…

规范的第一章“范围”开宗明义：

  • 目标: 为Sidelink定位和测距服务提供支持。
  • 角色: SLPKMF，作为服务的提供者。
  • 内容: 定义Nslpkmf服务化接口的Stage 3协议、消息流和API。

SLPKMF的核心价值在于，它为去中心化的Sidelink通信，引入了一个中心化的、可信的安全锚点。网络（通过SLPKMF）掌握着为Sidelink定位过程生成、分发和管理所有安全密钥的最终权力。

场景设定：在自动化仓库中，有两类“穿梭者”机器人：

  • “穿梭者-搬运工” (Target UE/Located UE): 负责搬运货物，是需要被定位的目标。
  • “穿梭者-观察员” (Reference UE/Discoverer UE): 可能固定在货架上或在巡逻，它们的精确位置已知，作为定位的参考点。

这些机器人之间需要通过Sidelink信号进行高频的相互测距，以计算出每个“搬运工”的实时位置。

2. SLPKMF在5G网络中的位置与角色

SLPKMF是一个相对独立和专用的网络功能，它的“朋友圈”也非常聚焦。

3GPP TS 29.586 - Chapter 4: Overview

Figure 4-1 provides the reference model … with focus on the SLPKMF: SLPKMF ⇐- Npc9* / Nslpkmf -⇒ SLPKMF

规范的Figure 4-1: Reference model – SLPKMF 展示了一个非常独特的架构：

  • 核心交互关系: SLPKMF ⇐> SLPKMF。

这看起来有些奇怪，自己和自己交互？这里的深层含义是，SLPKMF的主要服务消费者，是另一个SLPKMF。这通常发生在漫游场景下。

场景链接：

  • 非漫游场景: 仓库中的所有“穿梭者”机器人，都归属于同一个运营商网络。它们的定位请求，会由应用服务器（AF）通过NEF等网元，最终触发对SLPKMF的调用。在这种情况下，消费SLPKMF服务的可能是PCF、AMF等其他NF（尽管本规范未明确画出，但在Stage 2流程中有描述）。
  • 漫游场景（本规范的焦点）: 假设一个临时的“穿梭者-访客”机器人（来自另一个运营商网络）进入仓库协同作业。这个“访客”机器人在当前网络（V-PLMN）中需要获取定位授权和密钥。此时，拜访地网络的SLPKMF（V-SLPKMF），就需要作为服务消费者，去调用归属地网络的SLPKMF（H-SLPKMF），为其用户获取授权。

因此，TS 29.586主要定义的是SLPKMF之间的接口，用于处理跨网络的Sidelink定位安全问题。

3. SLPKMF提供的核心服务与操作

规范的第五章“Services offered by the SLPKMF”是核心功能描述。Table 5.1-1: List of SLPKMF Services 为我们列出了其服务“菜单”。

SLPKMF对外提供两大核心服务：

3.1 Nslpkmf_Discovery (发现服务)

这个服务主要用于Sidelink定位的准备阶段，负责处理与设备发现和监控相关的授权。它包含了三个服务操作：

  • AnnouncementAuthorization (广播授权)

    • 功能: 一个UE（如“搬运工”机器人）想要在Sidelink信道上广播自己的存在（“我在这里，谁能帮我定位？”），它需要获得网络的许可。这个操作就是为其颁发“广播许可证”。
    • 场景链接: “穿梭者-搬运工-01”开机后，它需要向网络申请在仓库的Sidelink信道上广播自己的ID。V-SLPKMF会向H-SLPKMF发起AnnouncementAuthorization请求，获取授权。

  • MonitorAuthorization (监控授权)

    • 功能: 一个UE（如“观察员”机器人）想要监听Sidelink信道，以发现和帮助其他设备定位，它也需要获得网络的许可和用于解密广播信号的密钥。这个操作就是为其颁发“监听许可证”和“解码本”。
    • 场景链接: “穿梭者-观察员-01”需要获取用于发现和解码“搬运工”广播信号的安全密钥。V-SLPKMF向H-SLPKMF发起MonitorAuthorization请求，获取这些密钥。

  • DiscoveryAuthorization (发现授权)

    • 功能: 这是针对特定发现模型（Model B restricted discovery）的授权，同样是为“发现者”UE获取进行发现操作所需的密钥和许可。

3.2 Nslpkmf_SLPKMFKeyRequest (密钥请求服务)

这个服务用于Sidelink定位的执行阶段，负责为设备间的安全直接通信提供密钥。它只包含一个核心操作：

  • UnicastKey (单播密钥)
    • 功能: 当两个UE已经相互发现，并准备建立一个安全的一对一（Unicast） Sidelink链路来进行精确测距时，它们需要一个共享的会话密钥。这个操作就是由网络（SLPKMF）为它们生成和分发这个一次性的会话密钥。
    • 场景链接: “搬运工-01”和“观察员-01”已经相互发现。现在，“观察员-01”需要与“搬运工-01”建立一条加密链路，进行一系列的测距信号交换。它们的通信模块会通过网络，最终触发V-SLPKMF向H-SLPKMF发起UnicastKey请求，为这次测距会话获取一个安全的共享密钥。

4. 规范的整体结构：两大服务，两大API

通览TS 29.586的目录，我们可以看到其结构非常清晰，完全围绕上述两大服务展开：

  • 第5章 (Services offered by the SLPKMF): 定义了两大服务（Discovery和KeyRequest）和四个服务操作的功能逻辑。
  • 第6章 (API Definitions): 为这两大服务分别定义了两个独立的API：
    • 6.1 Nslpkmf_Discovery Service API: 定义了实现AnnouncementAuthorization, MonitorAuthorization, DiscoveryAuthorization的API接口。有趣的是，它的API设计不是标准的CRUD，而是基于PUT操作的资源创建/更新模式。
    • 6.2 Nslpkmf_SLPKMFKeyRequest Service API: 定义了实现UnicastKey操作的API接口，采用了一种“自定义操作（Custom Operation）”的POST请求模式。
  • 附录A (OpenAPI specification): 提供了这两个API的OpenAPI/YAML定义文件，这是工程师进行开发的直接输入。

总结

3GPP TS 29.586，以其对Sidelink定位场景的专注，为我们揭示了5G网络安全管理的一个全新维度。通过本篇全景式的概述，我们理解了：

  1. 核心价值: SLPKMF是5G Sidelink定位业务的安全基石。它通过中心化的密钥管理和授权机制，确保了设备间的直接定位过程是可信、保密和完整的。

  2. 漫游场景为焦点: 本规范主要定义了SLPKMF之间的接口（Nslpkmf），其核心应用场景是处理漫游用户在拜访地网络中的Sidelink定位安全问题。

  3. 两大核心服务:

    • Nslpkmf_Discovery: 负责定位准备阶段的安全，管理谁可以“说话”（广播）和谁可以“倾听”（监控）。
    • Nslpkmf_SLPKMFKeyRequest: 负责定位执行阶段的安全，为设备间的一对一安全测距提供会话密钥。

  4. 独特的API设计: 与我们之前看到的订阅/通知模式不同，Nslpkmf服务的API更多地采用了基于PUT的资源授权和基于POST的自定义操作模式，这反映了其“请求-响应”式的安全授权业务本质。

这份规范虽然篇幅不长，但技术密度很高，它深入到了Sidelink物理层安全的最上层管理逻辑。在接下来的系列文章中，我们将严格按照TS 29.586的章节顺序，从第一章开始，逐一解剖其范围、定义，并深入到第五章和第六章，为您完整呈现Nslpkmf_Discovery和Nslpkmf_SLPKMFKeyRequest这两大服务的每一个技术细节。

FAQ

Q1：为什么Sidelink定位需要一个专门的密钥管理功能（SLPKMF），而不能复用核心网已有的安全机制（如AUSF/UDM）？ A1：因为Sidelink定位的安全需求非常独特。它涉及到设备间的直接通信（PC5接口），其密钥的生命周期、分发方式和使用场景，都与传统的UE-网络间通信（Uu接口）完全不同。例如，它需要为临时的、动态的UE群组生成和分发共享密钥，需要处理跨网络的密钥请求。这些特定的需求，使得设计一个专门的SLPKMF来处理这些复杂逻辑，比改造现有的、为Uu接口设计的安全网元更加高效和清晰。

Q2：SLPKMF和LMF（定位管理功能）是什么关系？ A2：LMF是5G定位业务的“计算中心”，它负责处理原始的定位测量数据，并计算出最终的位置结果。而SLPKMF是“安全中心”，它不关心定位算法，只负责在定位过程的各个阶段，提供必要的授权和安全密钥。在实际流程中，LMF（或通过LMF的AF）在发起一个Sidelink定位请求时，可能会先触发对SLPKMF的调用，以确保所有参与定位的UE都已获得安全授权和必要的密钥。

Q3：在本规范中，SLPKMF之间的接口叫Nslpkmf。这个接口是否也遵循SBA的通用规则？ A3：是的。尽管交互模式不同，但Nslpkmf接口仍然是一个标准的SBA接口。它同样使用HTTP/2作为传输协议，JSON作为数据格式，通过NRF进行服务发现，并可以采用OAuth 2.0进行安全保护。这保证了SLPKMF作为一个标准的5G NF，能够无缝地融入核心网的微服务生态。

Q4：为什么Nslpkmf_Discovery服务的API要使用PUT方法，而不是更常见的POST来创建授权？ A4：这是一种RESTful API设计选择，体现了操作的幂等性（Idempotency）。PUT方法的语义是“创建或替换”。当一个SLPKMF向另一个SLPKMF为某个UE申请广播授权时，无论这是第一次申请（创建），还是因为之前的请求超时而重试（替换），最终的结果都应该是在服务器上存在一份该UE的授权。使用PUT，客户端可以多次发送完全相同的请求，而不用担心会创建出重复的授权资源，这使得接口更加健壮。

Q5：这个服务听起来非常专业和底层，它对上层的应用开发者可见吗？ A5：对上层应用开发者完全不可见。SLPKMF及其Nslpkmf接口是核心网内部的实现细节。应用开发者（例如“智行未来”公司的工程师）只会接触到由NEF暴露的、高度抽象的北向定位API。当开发者调用一个“启动对车辆A的Sidelink定位”的北向API时，NEF和核心网内部的一系列NF（可能包括AMF, PCF, LMF, SLPKMF等）会自动协同完成所有复杂的信令交互和安全流程。

关系图谱