51学通信

深度解析 3GPP TS 23.287：6.3 Procedures for V2X communication over PC5 (Part 2 - 单播链路的生命周期管理)

17分钟阅读

好的，我们迎来了PC5“路考”的终极挑战——单播模式。这不仅是技术上最复杂的科目，也是实现高级V2X应用（如远程驾驶、安全会话）的基石。让我们跟随“智行一号”，一步步攻克这个难关。

深度解析 3GPP TS 23.287：6.3 Procedures for V2X communication over PC5 (Part 2 - 单播链路的生命周期管理)

本文技术原理深度参考了3GPP TS 23.287 V18.4.0 (2024-09) Release 18规范中，关于“6.3.3 Unicast mode V2X communication over PC5 reference point”的核心章节，旨在为读者完整地拆解PC5单播通信的全生命周期管理流程，包括链路的建立、标识符更新、修改、释放和维护。

引言：从“广而告之”到“专属热线”

在Part 1中，我们的主角“智行一号”已经熟练掌握了广播和组播这两种“一对多”的沟通技巧。但V2X的世界，还需要更私密、更可靠、更具确定性的“一对一”交流。想象一下：

  • 两辆车在高速上需要协商一次精确到毫秒的协同超车动作。

  • “智行一号”需要与路侧单元建立一条绝对可靠的链路，以接收远程驾驶员发来的控制指令。

  • 两辆车在共享敏感数据前，需要先建立一个加密的会话通道。

这些场景，都无法通过广播或组播来满足。它们需要的是一条PC5单播链路——一条为通信双方量身定制的、端到端的“专属热线”。

本篇文章将是6.3节解读的完结篇，我们将聚焦于PC5单播通信的全生命周期。这不再是一次性的“发完就走”，而是一个包含了“结识、交换名片、保持联系、更新信息、变更业务、道别”的完整社交过程。我们将详细拆解这条“专属热线”是如何被建立、维护并最终被拆除的。

1. “结识与握手”：Layer-2链路的建立 (6.3.3.1)

这是单播通信的第一步，也是最关键的一步。规范中的“Figure 6.3.3.1-1: Layer-2 link establishment procedure”描绘了这幅复杂的“初识”画卷。整个过程可以类比为一次精心安排的“商务会谈”。

1.1 准备阶段：明确会谈目标 (Step 1 & 2)

Step 1. The UE(s) determine the destination Layer-2 ID for signalling reception…

Step 2. The V2X application layer in UE-1 provides application information for PC5 unicast communication…

  • 接收方 (UE-2/3/4) - 守株待兔:

    • 所有可能成为被叫方的车辆，都会提前根据PCF策略，在一个或多个默认的“单播发现”L2 ID上进行监听。这就像所有公司的前台，都在监听着总机电话。

  • 发起方 (UE-1, “智行一号”) - 明确意图:

    • “智行一号”的应用层决定发起一次单播通信。它需要向V2X层提供“会谈三要素”：

      1. 我是谁 (Source User Info): 我自己的应用层ID。

      2. 我想和谁谈 (Target User Info, 可选): 如果它知道对方的应用层ID，就可以“指名道姓”。

      3. 我们谈什么 (V2X Service Info): 本次会谈的主题，即请求建立链路的服务类型和QoS需求。

1.2 发起会谈：发出“直接通信请求” (Step 3 & 4)

Step 3. UE-1 sends a Direct Communication Request message…

Step 4. Security with UE-1 is established…

  • “智行一号”发出请求:

    • 它将“会谈三要素”以及用于建立安全连接的Security Information，打包成一个Direct Communication Request消息。

    • 它通过PC5接口，将这条消息发送出去。目标L2 ID可以是广播地址（广而告之“我要找人谈话”），也可以是之前配置的默认发现地址。

  • 建立安全通道:

    • 所有收到请求的UE，会首先与“智行一号”进行一次安全握手（具体流程由TS 33.536定义），建立一个加密和完整性保护的通道。这是后续所有私密对话的前提。

1.3 响应与确认：交换“名片”与协商“条款” (Step 5)

Step 5. A Direct Communication Accept message is sent to UE-1… The Direct Communication Accept message includes:

  • Source User Info: Application Layer ID of the UE sending the … Accept message.
  • QoS Info: the information about PC5 QoS Flow(s) requested by UE-1…
  • If IP communication is used: IP Address Configuration…

  • 接收方响应:

    • UE oriented (A): 如果请求中“指名道姓”了，那么只有被点名的UE-2会响应。

    • V2X Service oriented (B): 如果请求是开放式的，那么所有对这个“会谈主题”（V2X服务）感兴趣的UE（如图中的UE-2和UE-4）都会响应。

  • “交换名片”:

    • 响应方在Direct Communication Accept消息中，会包含自己的应用层ID和当前的源L2 ID。通过这次交换，双方都获得了对方的底层“联系方式”。

  • 协商“条款” (QoS & IP):

    • 响应方会确认（或反建议）发起方提出的QoS需求。

    • 如果需要IP通信，双方还会协商谁来扮演IPv6路由器的角色。

1.4 “专属热线”接通 (Step 6)

Step 6. V2X service data is transmitted over the established unicast link…

  • 链路建立成功后，V2X层会为这条链路分配一个唯一的PC5 Link Identifier，并连同协商好的L2 ID、QoS参数等，一同配置给底层的接入层。

  • 从此，“智行一号”就可以在这条双向的、有QoS保障的、安全的“专属热线”上，开始传输真正的业务数据了。

2. “保持联系”：标识符更新 (6.3.3.2) & 链路维护 (6.3.3.5)

2.1 更换“名片”：链路标识符更新

由于隐私保护的要求，通信双方的L2 ID会周期性地更换。为了不让“专属热线”因此中断，必须有一个“更换名片”的流程。

Figure 6.3.3.2-1: Link identifier update procedure

流程解读：

  1. UE-1决定更换ID: “智行一号”的隐私定时器到期，它生成了一个新的L2 ID。

  2. 发送更新请求: 它使用旧的L2 ID，向UE-2发送一条Link Identifier Update Request消息，其中加密包含了它的新L2 ID。

  3. 对方响应并更新: UE-2收到后，也为自己生成一个新的L2 ID，并在Link Identifier Update Response消息中，将自己的新ID加密后发回。

  4. 最终确认: UE-1收到响应后，发送一条Link Identifier Update Ack消息，确认双方都已更新。

  5. 切换到新ID: 从此刻起，双方开始使用新的L2 ID对进行通信。整个过程对上层应用透明，业务不中断。

2.2 “嘘寒问暖”：链路维护

如果“专属热线”长时间没有数据传输，如何确认对方还在不在？这就是Keep-alive（心跳）机制的作用。

Figure 6.3.3.5-1: Layer-2 link maintenance procedure

流程解读：

  • 任何一方（如UE-1）在一段时间内没有收到对方的数据后，可以发送一个Keep-alive消息。

  • 如果对方（UE-2）在线，会回复一个Keep-alive Ack消息。

  • 如果UE-1在超时前没有收到Ack，它就可以判断这条链路已经失效，并进行本地释放。

3. “变更与道别”：链路修改 (6.3.3.4) & 释放 (6.3.3.3)

3.1 增加“会谈议题”：链路修改

在“专属热线”通话过程中，可能需要增加新的业务，或者调整现有业务的QoS。

Figure 6.3.3.4-1: Layer-2 link modification procedure

流程解读：

  • 发起方（UE-1）发送Link Modification Request消息，其中可以包含：

    • 新增的PC5 QoS Flow信息。

    • 修改现有PC5 QoS Flow的参数。

    • 要移除的PC5 QoS Flow的PFI。

  • 接收方（UE-2）响应Link Modification Accept消息，确认变更。

  • 双方的V2X层随即将变更通知接入层，动态调整底层的无线资源配置。

3.2 挂断“电话”：链路释放

当所有业务都结束后，需要礼貌地挂断“电话”。

Figure 6.3.3.3-1: Layer-2 link release procedure

流程解读：

  • 发起方（UE-1）发送Disconnect Request消息。

  • 接收方（UE-2）可以选择性地回复Disconnect Response消息。

  • 双方收到或发送了释放消息后，立即删除与该链路相关的所有上下文信息（L2 ID、QoS配置等），彻底拆除这条“专属热线”。

总结：单播，构建V2X高级应用的精密艺术

通过对6.3.3节的全生命周期流程的深度剖析，我们看到了PC5单播通信的复杂性与强大能力。它不再是广播/组播那样简单的“一次性”行为，而是一个面向连接的、有状态的、可管理的精密过程。

  • 严谨的建立流程，通过请求/接受模型，实现了安全上下文的建立、L2 ID的交换、QoS参数的协商，为可靠通信奠定了基础。

  • 灵活的维护机制，通过标识符更新流程，完美地解决了隐私保护与链路连续性之间的矛盾；通过Keep-alive机制，保证了链路状态的活性检测。

  • 动态的变更能力，通过链路修改流程，赋予了单播通信根据业务实时需求，动态调整QoS保障的能力。

  • 清晰的释放过程，确保了通信结束后，资源的被彻底回收。

“智行一号”的“路考”至此已全部完成。它已经从一个理论家，成长为了一名能够熟练驾驭PC5广播、组播、单播三种模式的“全能驾驶员”。

至此，我们已经完成了对第6章最核心部分——PC5通信流程的完整解读。在下一篇文章中，我们将把目光再次投向Uu接口，看看V2X业务在与云端交互时，又会涉及到哪些具体的信令流程。

FAQ

Q1：PC5单播链路的建立过程看起来很复杂，时延会不会很大？

A1：初始建立的时延确实会比广播的“零时延”要高，可能在几十到上百毫秒量级。但关键在于，单播链路通常是为持续性的业务（如远程驾驶、视频共享）而设计的。它是一种“一次建立，长期使用”的模式。一旦链路建立成功，后续的数据传输时延可以做到极低（毫秒级）。对于那些需要极低时延又无法预先建立链路的突发性单播场景，规范也在不断演进，引入更快速的建链机制。

Q2：在链路标识符更新流程中，为什么要用旧ID来发送包含新ID的消息？

A2：这是为了保证更新过程的连续性。在双方完成“换名片”并达成共识之前，旧的“名片”（旧L2 ID）是双方唯一共同认可的联系方式。如果UE-1直接开始使用新ID来发送更新请求，UE-2将不认识这个新的ID，会直接将其作为未知来源的数据包丢弃，更新流程便无法完成。

Q3：链路修改流程和重新建立一条新链路，哪个开销更小？

A3：链路修改流程的开销要小得多。它复用了已有的安全上下文和底层无线链路，只是通过简单的信令交互，对上层的QoS Flow配置进行增量更新。而重新建立一条链路，则需要再次经历完整的发现、安全认证、L2 ID交换和QoS协商过程，信令开销和时延都会大很多。因此，对于在已有连接上增减业务的场景，链路修改是首选。

Q4：如果UE-1发送了Disconnect Request后，UE-2没有回复Response就直接关机了，会发生什么？

A4：这不会影响链路的最终释放。规范规定，UE-1在发送了Disconnect Request后，就可以立即删除本地的链路上下文。它无需等待UE-2的回复。UE-2不回复Response是完全合规的（“may respond”）。这个设计保证了链路释放的鲁棒性，即使一方突然掉线或崩溃，另一方也能单方面、干净地拆除链路，释放资源。

Q5：整个单播链路的生命周期管理，是由V2X层还是接入层（AS Layer）负责的？

A5：这是V2X层的核心职责。V2X层是单播链路的“大脑”和“状态机”，它负责发起和处理所有的控制面信令（Request/Accept/Update/Disconnect等），并维护链路的完整状态（如协商好的L2 ID、QoS参数等）。当状态发生变化时（如链路建立成功、QoS被修改），V2X层会生成相应的配置指令，下发给接入层。接入层是“执行者”，它根据V2X层的指令，去执行具体的无线资源分配、数据收发等物理操作。

关系图谱