好的，我们继续接续上一篇文章，对 3GPP TS 31.102 规范进行深度拆解。
深度解析 3GPP TS 31.102：4.2.59 EFDCI & 4.2.60 EFDCA (数据连接的“出生证明”)
本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.59 EFDCI (Data Connection Identifier)”和“4.2.60 EFDCA (Data Connection Ack)”的核心章节，旨在为读者深入剖析在CSD（电路交换数据）这一传统数据业务中，USIM卡是如何通过
EFDCI和EFDCA这对“身份与回执”文件，为每一次数据连接的建立提供唯一的标识和状态确认，从而保障计费和管理的准确性。
在我们今天享受着4G/5G高速分组交换（PS）数据网络带来的便利时，很容易忘记在移动通信的早期，数据业务曾长期依赖于一种类似“拨号上网”的技术——电路交换数据 (Circuit Switched Data, CSD)。在这种模式下，每一次数据连接都会像语音通话一样，独占一条固定的无线信道。
虽然CSD技术已基本被淘汰，但在某些特定的、需要固定速率和稳定时延的传统行业应用中（如一些老旧的工业遥测、POS机交易），它仍有少量存在。更重要的是，理解CSD业务中的一些核心设计，有助于我们理解整个3GPP体系演进的脉络。
在CSD业务中，一个核心的需求是：如何唯一地标识和追踪每一次数据连接？ 这对于计费、审计和故障排查至关重要。为了解决这个问题，3GPP规范设计了EFDCI和EFDCA这对文件。
-
EFDCI(Data Connection Identifier): “数据连接标识符”，它解决了“这次连接是谁”的问题。网络在发起一次CSD连接前，会为这次连接分配一个唯一的“出生证明”——DCI。EFDCI就是用来存储这个“出生证明”的文件。 -
EFDCA(Data Connection Ack): “数据连接确认”，它解决了“‘出生证明’是否已收到”的问题。手机在成功接收并存储DCI后，需要向网络回送一个“确认回执”。EFDCA就是用于生成这个“回执”的文件。
今天，我们将一起穿越回CSD时代，探索这对“身份与回执”文件，是如何为每一次“拨号”数据连接的生命周期，提供严谨的标识和确认机制的。
1. 连接的“出生证明”：4.2.59 EFDCI (数据连接标识符)
EFDCI的核心价值在于，它在USIM这个可信载体上，为手机提供了一个存储由网络权威下发的、用于唯一标识一次CSD连接的ID的地方。
This EF contains a Data Connection Identifier (DCI). This is used in Circuit Switched (CS) data connections.
这段原文非常简洁地指明了EFDCI的功能：存储一个用于CS数据连接的DCI (Data Connection Identifier)。
CSD连接与DCI的工作机制
这个机制主要用于网络发起的CSD连接 (Network-initiated CSD Call)。
-
网络发起: 网络侧的应用（例如，一个工业监控中心）需要从一个远程的传感器（安装了我们主角“李想”负责的USIM卡）采集数据。该应用向核心网请求建立一条到该传感器的CSD连接。
-
DCI下发: 在正式建立CSD呼叫之前，核心网（MSC）会首先通过一个USAT（USIM Application Toolkit）的
SEND DATA命令，将一个为此次连接唯一生成的DCI，通过信令通道下发给目标终端。这个DCI就像是即将到来的数据连接的“预约号”或“会话ID”。 -
USIM存储: 终端（传感器）的通信模块接收到这个
SEND DATA命令后，会将其中包含的DCI数据，写入USIM卡的EFDCI文件中。 -
连接建立: 随后，网络正式发起CSD呼叫。在呼叫建立的过程中，手机会将
EFDCI中存储的DCI包含在信令中，回送给网络。 -
网络验证: 网络侧将收到的DCI与自己之前下发的DCI进行比对。如果一致，就证明了“来电者”正是自己刚刚“预约”的那个终端，连接建立成功。如果不一致，则拒绝连接。
通过这个流程，DCI确保了网络发起的每一次CSD连接，都能够被精确地识别和追踪，防止了连接被误接或伪造，为后续的计费和业务处理提供了可靠的依据。
EFDCI文件结构与编码剖析
EFDCI的设计专注于存储这个唯一的ID。
表 4.2.59-1: EFDCI 文件结构
| 属性 | 值 |
| :--- | :--- |
| Identifier | ‘6FDE’ |
| Structure | Transparent |
| File size | 16 bytes |
| Access Conditions| READ: PIN, UPDATE: PIN (USAT) |
字节内容
| 字节 | 描述 | M/O | 长度 |
| :--- | :--- | :--- | :--- |
| 1 to 16 | Data Connection Identifier | M | 16 bytes |
关键特性解读：
-
File size: 固定16字节，为一个128位的DCI预留了充足的空间。
-
Access Conditions:
UPDATE权限是一个特殊情况，它虽然是PIN，但通常是由USAT命令在后台触发的，而非用户直接操作。当手机收到网络下发的SEND DATA命令时，该命令本身已经经过了网络的安全验证，手机会据此在PIN解锁的状态下，执行对EFDCI的更新。 -
编码:
The coding of the DCI is operator specific.
DCI的16个字节具体如何编码，是运营商自定义的 (operator specific)。这给了运营商极大的灵活性，他们可以根据自己的计费和管理系统，来设计DCI的格式，例如可以包含时间戳、设备ID、业务类型等信息。
2. “收妥回执”：4.2.60 EFDCA (数据连接确认)
EFDCA的作用，是在上述流程的第3步和第4步之间，增加一个“确认”环节，使整个交互更加可靠。
This EF contains a Data Connection Identifier Acknowledgement (DCA). The DCA is used for acknowledging the reception of a DCI sent from the network.
EFDCA的核心使命是：在手机成功将DCI写入EFDCI之后，生成一个“收妥回执 (DCA)”，并将其发送回网络，告知网络“预约号已收到，可以开始呼叫了”。
DCA的工作机制
-
… (流程同上 1-3步，DCI被成功写入
EFDCI) … -
生成DCA: DCI写入成功后，手机会立即读取
EFDCI中的DCI值，并可能加上一些其他信息（如时间戳、终端状态等），按照运营商预定义的规则，生成一个DCA。这个DCA存储在EFDCA文件中。 -
回送DCA: 手机通过USAT的
TERMINAL RESPONSE命令，将EFDCA中的DCA值，作为对网络之前SEND DATA命令的响应，回送给网络。 -
网络确认: 网络收到DCA并验证通过后，确认终端已准备就绪，才会继续发起后续的CSD呼叫。
这个“DCA回执”机制，增加了一次握手，使得网络能够确切地知道DCI已经被终端成功接收，从而避免了因DCI在空中丢失而导致的后续呼叫失败，提升了整个业务流程的可靠性。
EFDCA文件结构与编码剖析
EFDCA的结构与EFDCI非常相似。
表 4.2.60-1: EFDCA 文件结构
| 属性 | 值 |
| :--- | :--- |
| Identifier | ‘6FDF’ |
| Structure | Transparent |
| File size | 17 bytes |
| Access Conditions| READ: PIN, UPDATE: PIN |
字节内容
| 字节 | 描述 | M/O | 长度 |
| :--- | :--- | :--- | :--- |
| 1 to 17 | Data Connection Acknowledgement | M | 17 bytes |
关键特性解读：
-
File size: 17字节，比
EFDCI多一个字节，可能是为了在DCA中额外增加一个状态或类型字节。 -
编码:
The coding of the DCA is operator specific.
与DCI一样，DCA的编码格式也是运营商自定义的。DCA的生成规则（如何基于DCI来计算DCA）也是运营商私有协议的一部分。
3. 设计思想的延续
EFDCI和EFDCA所体现的“会话标识 + 确认回执”的设计思想，在通信协议中非常经典和普遍。虽然它们所服务的CSD业务已趋于淘汰，但这种思想在后续的技术中得到了不断的继承和发扬。
例如，在IMS网络中，每一次会话都由一个唯一的Call-ID来标识；在TCP/IP协议中，每一个数据包都有一个序列号，并需要对方返回一个ACK（确认）包。
EFDCI/EFDCA可以被看作是这种通用设计思想，在早期USIM卡与网络通过USAT进行应用层交互时的一个具体实现。它们展示了如何利用USIM卡作为安全载体，来完成一次业务会话关键参数的安全传递和状态确认。
总结：为传统数据业务构建的严谨流程
EFDCI和EFDCA这对文件，为传统的、网络发起的电路交换数据业务，构建了一套严谨、可靠的会话标识和确认流程。
-
EFDCI(出生证明): 通过在USIM中存储一个唯一的连接标识符，确保了每一次网络发起的CSD连接都具有可追溯性，为计费和管理的准确性提供了基础。 -
EFDCA(收妥回执): 通过一个确认回传机制，增强了DCI下发流程的可靠性，实现了一次完整的“请求-确认”握手，避免了因信令丢失导致的业务失败。 -
运营商的灵活性: 规范将DCI和DCA的编码格式定义为“运营商特定”，给予了运营商根据自身业务系统进行定制的最大灵活性。
对于李想而言，即使他负责的那个老旧的工业传感器还在使用CSD进行数据回传，他也可以确信，每一次由中心发起的远程数据采集，都是一次被精确标识、严格确认的可靠连接。这份可靠性的背后，正是EFDCI和EFDCA这对“老将”，在USIM卡中默默地履行着它们在标准中被赋予的、历久弥新的职责。
FAQ环节
Q1：EFDCI和EFDCA在现代4G/5G网络中还有用吗？
A1：在纯4G/5G的分组交换（PS）数据业务中，这两个文件基本没有用武之地。PS域的数据连接（PDU会话）有自己一套更复杂的、基于NAS和GTP协议的会话管理和标识机制（如PDU Session ID），不再需要通过USAT和USIM文件来传递连接标识符。EFDCI/EFDCA是专为CSD业务设计的，它们的存在主要是为了保障对这些传统业务的兼容性。
Q2：为什么DCI需要通过USAT的SEND DATA命令下发，而不是直接通过普通的短信？
A2：使用USAT命令有几个关键优势：1) 可靠性: USAT命令在底层信令通道上传输，其可靠性和实时性远高于普通短信。2) 后台处理: USAT命令可以被手机的底层协议栈直接捕获并处理（如写入EFDCI），整个过程对用户完全透明，不会像普通短信一样弹出通知。3) 安全性: USAT通道本身具有一定的安全机制，比普通短信更适合传递敏感的业务参数。4. 交互性: USAT框架支持TERMINAL RESPONSE，可以方便地实现“请求-响应”的交互模式，这正是DCA回执机制所需要的。
Q3：EFDCI和EFDCA的编码既然是运营商自定义的，那手机怎么知道如何解析它们？
A3：手机通常不需要解析它们的内部含义。在这个机制中，手机扮演的是一个“透明管道”和“存储器”的角色。
-
对于
EFDCI，手机的任务就是从SEND DATA命令中“抠出”这16个字节的数据，然后原封不动地“存入”EFDCI文件。 -
对于
EFDCA，手机的任务可能是根据运营商提供的规则（可能硬编码在手机软件中，或由其他配置下发）基于DCI生成DCA，或者DCA本身就是由USIM卡内的某个小程序生成的，手机只负责将其读出并发回网络。
DCI/DCA的真正“读者”和“作者”是网络侧的业务平台，手机在其中主要负责传递和存储。
Q4：为什么这两个文件的UPDATE权限是PIN，而不是ADM？
A4：这里的PIN权限，实际上是由USAT命令在后台隐式满足的。当手机收到一个合法的、经过网络侧安全验证的USAT命令（如SEND DATA）时，这个命令本身就携带了足够的“权威性”。手机的协议栈在处理这个命令时，会在USIM已解锁（通过开机PIN）的前提下，自动执行对EFDCI的写操作。这个过程不需要用户再次输入PIN。将权限设为PIN，而不是ADM，正是为了允许这种由授权信令触发的、合法的后台写操作。
Q5：这个机制和eCall中的数据上报有什么相似之处吗？
A5：有很好的类比性。在eCall中，当车辆发生事故后，除了建立语音通话，车载单元（IVS）还需要通过“in-band modem”技术，在语音通道上传输一组数据（MSD, Minimum Set of Data），其中包含了事故位置、车辆信息等。这个MSD也可以看作是一种“连接标识和上下文数据”，它使得接警中心在接通电话的瞬间，就能获得关于事故的全部关键信息。虽然技术实现完全不同，但EFDCI和eCall MSD的核心思想都是一样的：在主业务（CSD数据连接/紧急语音通话）建立的同时或之前，安全、可靠地传递与本次会话相关的、唯一的上下文标识信息。