好的，我们继续解读规范。在对2G到5G的各种核心标识体系有了全面的了解之后，我们将进入一个专门为“近场通信”和“去中心化”场景设计的独特领域——ProSe（Proximity-based Services - 基于邻近的服务）。
深度解析 3GPP TS 23.003：24 ProSe的号码、地址与身份标识
本文技术原理深度参考了3GPP TS 23.003 V18.7.0 (2024-09) Release 18规范中，关于“Chapter 24 Numbering, addressing and identification for Proximity-based Services (ProSe)”的核心章节。本文旨在为读者深入剖析一种允许终端设备在近距离内直接通信（Device-to-Device, D2D）的创新技术——ProSe，以及支撑其服务发现、直接通信和隐私保护的独特标识体系。
在之前的所有章节中，我们探讨的通信模式都有一个共同点：所有的数据和信令都必须经过运营商的核心网进行中转和处理。然而，在某些特定场景下，这种“中心化”的模式并非最高效。想象一下：在一个大型音乐节现场，你想给几米之外的朋友分享一张高清照片；或者，在一场紧急救援中，两名消防员在信号盲区需要直接通话。在这些场景下，让数据绕道几百公里外的核心网再回来，显然是舍近求远。
ProSe（Proximity-based Services），通常与**D2D（Device-to-Device）**通信紧密相关，正是3GPP为应对这类“近在咫尺”的通信需求而设计的解决方案。它允许UE（用户设备）在满足特定条件下，绕过（或部分绕过）基站和核心网，直接在设备之间建立通信链路。
为了实现这种“去中心化”的通信，ProSe需要一套全新的、能够标识应用、发现近邻、并保护用户隐私的标识体系。今天，我们将引入两位热爱户外探险的朋友——小李和小张，他们正在一个偏远的山区进行徒步。他们的智能手表和手机都支持ProSe功能，这将成为我们探索这套独特标识体系的绝佳载体。
1. “我们是谁？”：ProSe Application ID - 服务的“名片” (章节 24.1 & 24.2)
小李和小张的智能手表上都安装了一款名为“HikerMate”的户外社交App。这款App的一个核心功能是，在近距离内自动发现其他使用同样App的徒步爱好者。这个“发现”过程，正是ProSe的第一步：ProSe应用发现。要让两台设备知道彼此运行的是同一个“可以互相发现”的应用，就需要一个标准化的应用“名片”——ProSe Application ID。
24.2.1 General The ProSe Application ID is composed of two parts as follows:
- The ProSe Application ID Name, which is described in its entirety by a data structure characterized by different levels e.g, broad-level business category (Level 0) / business sub-category (Level 1)…
- The PLMN ID, which corresponds to the PLMN that assigned the ProSe Application ID Name.
ProSe Application ID是一个结构化的字符串，它借鉴了FQDN（域名）的设计，但语义更为丰富，由两大部分组成，并用点.分隔：
ProSe Application ID = PLMN ID + ProSe Application ID Name
1.1 ProSe Application ID Name - 应用的“层级化描述”
24.2.2 Format of ProSe Application ID Name… The ProSe Application ID Name is composed of a string of labels. These labels represent hierarchical levels… The first label on the left shall be “ProSeApp”.
这部分是描述应用本身是什么。它是一个由点分隔的、具有层级结构的字符串，并且必须以ProSeApp开头。
场景串联：
“HikerMate”这个App的开发者，在3GPP（或相关注册机构）为其应用注册了一个ProSe Application ID Name，可能是这样的：
ProSeApp.Social.Outdoor.HikerMate
这个层级结构清晰地描述了应用的属性：它是一个ProSe应用，属于“社交”大类，“户外”子类，具体名称是“HikerMate”。
1.2 PLMN ID - 应用的“发行方”
24.2.3 Format of PLMN ID in ProSe Application ID The PLMN ID shall uniquely identify the PLMN of the ProSe Function that has assigned the ProSe Application ID. The PLMN ID is composed of two labels…: “mcc
.mnc ”
这部分用于标识这个ProSe应用ID是由哪个运营商的ProSe Function（ProSe功能实体）分配和管理的。其格式是我们熟悉的mcc<MCC>.mnc<MNC>。
场景串联：
假设“HikerMate”与中国移动合作，其ProSe服务由中国移动的ProSe Function管理（MCC=460, MNC=00）。那么，完整的ProSe Application ID就是：
mcc460.mnc000.ProSeApp.Social.Outdoor.HikerMate
当小李和小张的手机在近距离互相“嗅探”时，它们会广播自己感兴趣的应用ID。当小李的手机广播出上述ID，而小张的手机也配置了要监听这个ID时，两台设备就知道：“嘿，我们是同道中人！”从而触发了发现事件。
Any label in the ProSe Application ID Name except the first label… can be wild carded. A wild card label is represented as ”*“.
规范还允许使用通配符*。例如，小李可以设置他的App去发现所有mcc460.mnc000.ProSeApp.Social.Outdoor.*的应用，这样他就能发现附近所有使用中国移动旗下户外社交App的用户，而不仅仅是“HikerMate”。
2. “暗号”与“接头码”：ProSe Application Code & User ID (章节 24.3 & 24.4)
在空口上直接广播完整的、具有明确语义的应用ID，可能会暴露用户的兴趣和行为，存在隐私风险。为了解决这个问题，ProSe引入了一套临时的、匿名的“代码”体系。
2.1 ProSe Application Code - 应用的临时“暗号”
24.3.1 General The ProSe Application Code… is composed of the following two parts:
- The PLMN ID of the ProSe Function that assigned the ProSe Application Code…
- A temporary identity that corresponds to the ProSe Application ID Name…
当小李的“HikerMate”App向网络（ProSe Function）请求进行邻近发现时，网络不会直接让他广播完整的应用ID。相反，网络会为这个应用ID ProSeApp.Social.Outdoor.HikerMate 动态地生成一个临时的、看起来是随机的184比特的二进制码——这就是ProSe Application Code。
这个Code同样包含了PLMN ID部分和一个代表应用名称的临时身份部分。小李的手机在空口上实际广播的是这个Code。其他手机监听到这个Code后，如果自己也从网络获取了同样的Code，就知道对方是“自己人”。
这个Code是临时的，会定期更换，从而避免了通过长期监听一个固定的应用ID来追踪用户。
2.2 EPC ProSe User ID - 用户的临时“接头码”
24.4.1 General The EPC ProSe User ID… identifies the UE registered for EPC-level ProSe Discovery in the context of the ProSe Function.
当小李不仅想被发现，还想让对方知道他是“小李”时（或者至少是一个唯一的身份），网络会为他分配另一个临时ID——EPC ProSe User ID。这是一个32比特的二进制串。
在应用发现成功后，小李的手机可以向小张的手机通告自己的EPC ProSe User ID。小张的App界面上可能会显示“发现附近用户 Hiker-1234”（Hiker-1234就是由这个User ID映射而来的昵称）。这个ID同样是临时的，由ProSe Function分配和管理，保护了小李的真实身份。
3. “寻人启事”与“回应”：ProSe Discovery UE ID & Restricted/Query/Response Codes (章节 24.6 - 24.11)
ProSe的发现机制分为开放发现和受限发现。开放发现（如寻找附近的“HikerMate”用户）主要使用上述的Application Code。而受限发现，则更像是“我想找我的朋友小张”，这是一个更具体、更私密的需求。
场景串联： 小李在徒步队伍中与小张走散了。他可以在“HikerMate”App中触发“寻找小张”的功能。
- ProSe Restricted Code (受限码) (章节 24.6)：小李和小张作为好友，他们的App可能从网络那里获取了一个共享的、代表他们好友关系的“受限码”。
- ProSe Query Code (查询码) (章节 24.9)：当小李寻找小张时，他的手机会广播一个基于他们共享“受限码”生成的“查询码”。
- ProSe Response Code (响应码) (章节 24.10)：小张的手机监听到这个它认识的“查询码”后，会回复一个“响应码”，告诉小李“我在这里！”。
24.11 ProSe Discovery UE ID The ProSe Discovery UE ID… identifies the UE participating in restricted ProSe direct discovery… It is composed of two parts…: The PLMN ID … and A temporary identifier…
在这次成功的受限发现后，小李和小张的手机可能还会交换一个ProSe Discovery UE ID（一个64比特的临时ID）。这个ID的作用，是在后续的直接通信建立阶段，让双方能够唯一地确认对方的身份。
这套基于各种临时代码的“你问我答”机制，为私密的、一对一的邻近发现提供了安全保障。
4. 建立“秘密通道”：ProSe UE ID & Relay UE ID (章节 24.12 & 24.13)
小李和小张终于在山谷中汇合，但这里完全没有手机信号。他们需要商量下一步的路线。此时，ProSe的直接通信功能就派上了用场。他们的手机将在没有基站的情况下，直接建立一条通信链路。
24.12 ProSe UE ID The ProSe UE ID… identifies the link layer address used for ProSe direct communication by a ProSe-enabled Public Safety UE.
24.13 ProSe Relay UE ID The ProSe Relay UE ID… identifies the link layer address used for ProSe direct communication by a ProSe UE-to-network relay UE.
在建立直接通信链路时，设备需要一个类似于MAC地址的链路层地址。
- ProSe UE ID (24 bits)：就是用于公共安全场景下ProSe直接通信的链路层ID。
- ProSe Relay UE ID (24 bits)：则用于一种更特殊的场景——中继（Relay）。假设小李的手机有信号，而小张的手机没有。小李的手机可以化身为一个“移动基站”（Relay），让小张的手机通过与小李手机的D2D连接，来间接地接入远端的蜂窝网络。此时，小李的手机就使用ProSe Relay UE ID来标识自己的中继身份。
这些ID是ProSe从“服务发现”迈向“数据传输”的桥梁，是构建去中心化通信链路的地址基础。
5. 总结：一套为“去中心化”而生的标识体系
通过小李和小张的户外探险故事，我们深入了解了ProSe这套独特的、为D2D和邻近服务设计的标识体系。它的核心设计哲学与传统的蜂窝网络截然不同，处处体现着对隐私保护、去中心化和灵活性的追求。
- 分层、语义化的应用标识 (ProSe Application ID)：通过
PLMN ID + 层级化名称，为跨运营商的应用发现提供了标准化的“名片”。 - 广泛使用临时代码 (Application Code, User ID, Restricted Code等)：在空口上，用动态分配的、无明确语义的二进制代码替代永久的、可读的身份，最大限度地保护了用户的隐私和匿名性。这是整个ProSe设计的精髓。
- 区分场景的专用ID (UE ID, Relay ID等)：为直接通信、中继等不同的D2D物理场景，定义了专用的链路层标识，实现了功能的解耦。
- 网络协同下的“可控去中心化”：ProSe并非完全脱离网络。所有的临时代码、发现权限、通信密钥等，仍然需要由网络侧的ProSe Function进行统一的分配和管理。这是一种“可管可控”的去中心化，兼顾了灵活性与安全性。
ProSe/D2D技术，为车联网（V2X）、公共安全、物联网等场景提供了全新的解决思路。虽然它在普通消费市场的应用尚未普及，但其背后的标识设计理念——特别是对隐私的极致追求和对“中心化vs去中心化”的平衡——对我们理解未来6G网络中可能出现的内生D2D、分布式智能等新范式，具有极其重要的启发意义。
FAQ - 常见问题解答
Q1：ProSe和Wi-Fi Direct/蓝牙有什么区别？ A1：它们都是实现设备间近距离直接通信的技术，但归属和管理体系完全不同。
- Wi-Fi Direct/蓝牙：是工作在非授权频谱上的技术，遵循IEEE/蓝牙SIG标准。它们的发现和连接过程是完全“野生的”，不受运营商网络控制，通常需要用户手动配对，安全性也依赖于设备本身。
- ProSe：是工作在授权频谱（运营商的LTE/NR频段）或专用频段上的技术，遵循3GPP标准。它的整个生命周期（发现、通信、安全）都受到运营商核心网（ProSe Function）的严密管理和授权。这带来了运营商级的安全性、可管理性和计费能力，并能与蜂窝网络实现无缝的协同（如中继）。
Q2：ProSe通信需要SIM卡吗？ A2：是的，在绝大多数场景下都需要。ProSe的设计理念是“运营商可控的D2D”。用户的ProSe服务权限、好友关系（用于受限发现）、安全密钥等，都与用户的签约身份（IMSI/SUPI）绑定，存储在SIM/USIM卡和核心网中。没有SIM卡，设备就无法向ProSe Function证明自己的合法身份，也就无法获取进行发现和通信所需的各种临时代码和密钥。
Q3：ProSe通信是免费的吗？ A3：这取决于运营商的商业模式。从技术上讲，ProSe通信（特别是脱网的直接通信）不消耗核心网的用户面资源，但它占用了宝贵的无线频谱资源，并且其前期的服务授权和密钥分发也消耗了核心网的信令资源。因此，运营商完全可以将其作为一项增值服务进行收费，例如按月收取功能费，或者为公共安全等特定行业客户提供套餐。
Q4：ProSe Application ID 和我们在Android/iOS上看到的App ID（如com.company.appname）有什么关系？
A4：两者都是应用的唯一标识，但应用层面和目的完全不同。
- OS App ID：是操作系统层面的标识，用于App的安装、管理、应用商店上架等。它与通信协议无关。
- ProSe Application ID：是3GPP ProSe协议层面的标识，专门用于邻近发现。一个App如果想使用ProSe功能，它的开发者需要在运营商或相关机构注册一个ProSe Application ID，并将其集成到App中。手机操作系统并不知道也不关心这个ID，只有手机的通信模组和ProSe客户端会使用它。
Q5：ProSe中继（Relay）功能听起来很像手机的“个人热点”，它们是一回事吗？ A5：不是一回事，虽然看起来效果类似。
- 个人热点（Wi-Fi Hotspot）：是将手机的蜂窝数据连接通过Wi-Fi分享出去。其他设备是通过Wi-Fi连接到你的手机，然后通过你的手机上网。这是一个IP层的共享。
- ProSe中继（UE-to-Network Relay）：是一台UE（中继UE）为另一台超出网络覆盖范围的UE（远程UE）提供到蜂窝网络的L2/L3层接入。远程UE通过D2D链路连接到中继UE，对于核心网来说，它就像是通过一个“移动基站”（中继UE）接入了网络。这个过程比个人热点更为底层，可以支持完整的移动性、安全性和QoS管理，是为扩展网络覆盖而设计的专业功能。