51学通信

深度解析 3GPP TS 31.102：4.2.86 EFeCall-Code & 4.2.87 EF-eCall-Data (生命救援的“快捷指令”与“数据包”)

16分钟阅读

好的，我们继续接续上一篇文章，对 3GPP TS 31.102 规范进行深度拆解。由于规范中 4.2.84 EFIMS-Config-Data (IMS配置数据) 和 4.2.85 EFEXT6 (IMS扩展文件) 的内容与我们已深入剖析的EFIMS和EFEXT系列原理高度重合，它们是IMS配置的具体参数和扩展，在此合并说明，不再展开。我们将直接进入下一组具有独特功能的文件，即与eCall相关的核心文件。

深度解析 3GPP TS 31.102：4.2.86 EFeCall-Code & 4.2.87 EF-eCall-Data (生命救援的“快捷指令”与“数据包”)

本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.86 EFeCall-Code (eCall code)”和“4.2.87 EF-eCall-Data”的核心章节，旨在为读者深入剖析在eCall（紧急救援呼叫）这一至关重要的车载应急系统中，USIM卡是如何通过EFeCall-Code和EF-eCall-Data这两个文件，既提供了发起紧急呼叫的“快捷指令”，又预存了那份包含着生命关键信息的“数据急救包”。

在我们之前的探索中，曾多次提及eCall（紧急救援呼叫）。这套系统被誉为汽车领域的“救命稻草”，能够在车辆发生严重碰撞时，自动（或手动）向公共安全应答点（PSAP，即救援中心）发起紧急呼叫，并在接通的同时，通过带内调制解调器（in-band modem）技术，在语音通道上传输一份包含事故精确位置、车辆信息、时间戳等关键数据的“最小数据集 (Minimum Set of Data, MSD)”。

救援人员在电话接通的瞬间，就能从这份MSD中得知“你在哪里”、“你是谁”、“发生了什么”，这为争取“黄金救援时间”提供了无与伦 Bǐ 的优势。

那么，这个救命的MSD数据包，它的“默认模板”或“备份副本”存储在哪里？发起eCall呼叫的特殊指令又是如何配置的？答案就藏在USIM卡中这对为生命救援而生的专属文件里：

  • EFeCall-Code: “eCall代码”，它存储了用于手动发起不同类型eCall呼叫的快捷指令码。

  • EF-eCall-Data: “eCall数据”，它存储了一份MSD数据包的副本或模板。

今天，我们将一同打开这个USIM卡中的“车载急救箱”，深入理解这两个文件是如何为eCall系统的可靠运行，提供最基础的数据支撑。

1. “快捷指令”：4.2.86 EFeCall-Code

EFeCall-Code的核心价值在于，为用户或车载系统提供一个标准化的、存储在USIM卡中的手动触发eCall的指令代码。

If service n° 89 is “available”, this file shall be present.

This EF contains the eCall Inactivity/Activation codes.

这段原文揭示了EFeCall-Code的关键特性：

  1. 服务关联: 它的存在与EF_UST中的服务n°89（eCall数据）紧密绑定。

  2. 功能核心: 存储eCall的非激活/激活码。

手动eCall的触发机制

虽然eCall最广为人知的特性是“自动触发”，但在很多情况下，也需要手动触发。例如，目击他人事故、车辆故障但未发生碰撞、乘客突发疾病等。

在这些场景下，驾驶员可以按下车内的“SOS”按钮。这个按钮的动作，背后可能就关联着EFeCall-Code中定义的代码。

工作流程：

  1. USIM预置: 汽车制造商或运营商在车载USIM卡的EFeCall-Code文件中，预置了两个代码：一个用于激活eCall，一个用于测试模式下的去激活。

  2. 用户操作: 我们的主角“李想”，现在是一名测试工程师。他需要验证一辆新车的eCall手动功能。他按下了SOS按钮。

  3. 车载系统（IVS）响应: 车载系统（In-Vehicle System, IVS）捕获到按钮动作，它会读取EFeCall-Code文件。

  4. 发起呼叫: IVS提取出“eCall激活码”（这是一个特殊的补充业务码，如*140*...#），并通过通信模块将其作为拨号串发起呼叫。

  5. 网络识别: 网络核心网识别出这是一个eCall业务的激活码，随即触发eCall流程，将呼叫路由到PSAP，并准备接收MSD数据。

EFeCall-Code在这里，就像是拨打112之外，另一条专门用于启动eCall会话的“暗语”或“快捷指令”。

文件结构与编码剖析

EFeCall-Code是一个线性固定文件，通常包含两条记录：激活码和去激活码。

表 4.2.86-1: EFeCall-Code 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier| ‘6F1C’ (注意：此ID在规范中可能因版本而异，以EFDIR为准) |

| Structure | Linear Fixed |

| Record length| X+14 bytes |

| Access Conditions| READ: ALW, UPDATE: ADM |

关键特性解读：

  • Access Conditions: 读取权限为ALW（总是允许），确保在任何紧急情况下，IVS都能无障碍地获取激活码。而更新权限为ADM，这些由国家或区域标准定义的官方代码，必须由运营商进行权威配置。

  • 记录结构: 其记录结构与EFADN（电话本）等文件完全相同。eCall代码本身被存储在“Dialling Number”字段中，而“Alpha Identifier”字段则可以存储其描述，如“eCall Activate”。

2. “数据急救包”：4.2.87 EF-eCall-Data

EF-eCall-Data是整个eCall机制在USIM卡上的数据核心。它存储了那份至关重要的**MSD（最小数据集）**的副本。

If service n° 89 is “available”, this file shall be present.

This EF contains a copy of the last transmitted Minimum Set of Data (MSD)… The ME may use the data stored in this EF, e.g. for a re-transmission or if no up-to-date data from other sources is available.

MSD的核心价值与EF-eCall-Data的作用

MSD是一个140字节的数据块，其格式由CEN EN 15722标准定义，包含了：

  • Message Identifier: 消息序号。

  • Control flags: 标志位，如是自动触发还是手动触发，是否为测试呼叫。

  • Vehicle Identification Number (VIN): 车辆的唯一识别码。

  • Vehicle Propulsion Storage Type: 车辆动力类型（汽油、柴油、电动等）。

  • Timestamp: 事故发生的时间戳。

  • Vehicle Location: 事故发生时的经纬度坐标。

  • Vehicle Direction: 车辆行驶方向。

  • …以及可选的更多数据。

EF-eCall-Data的作用:

  1. 数据备份: 它的首要作用是备份最后一次成功发送的MSD。

    This EF contains a copy of the last transmitted Minimum Set of Data (MSD).

  2. 提供默认值/回退方案: 在某些极端情况下，IVS的GPS模块可能失灵，无法获取实时、准确的位置信息。此时，IVS可以 (may use) 使用存储在EF-eCall-Data中的这份“老数据”作为回退。虽然这份数据可能不是最新的，但在完全没有位置信息的情况下，提供一个“最后已知位置”也远胜于无。

    …if no up-to-date data from other sources is available.

  3. 支持重传: 如果第一次MSD数据传输因网络问题失败，IVS需要重传。此时，它可以直接从EF-eCall-Data中读取上次构建好的MSD数据包，而无需重新从各个传感器（GPS、碰撞传感器等）采集和组织数据，提高了重传的效率和可靠性。

文件结构与编码剖析

EF-eCall-Data的设计完全围绕着存储140字节的MSD。

表 4.2.87-1: EF-eCall-Data 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F1D’ |

| Structure | Transparent |

| File size | 140 bytes |

| Update activity| High |

| Access Conditions| READ: PIN, UPDATE: PIN |

关键特性解读：

  • File size: 固定140字节，与MSD的标准长度完全匹配。

  • Structure: 透明文件，整个MSD数据块被原封不动地存入。

  • Update activity: High。每次成功的eCall呼叫后，IVS都应该将发送出去的MSD更新到这个文件中，以确保备份的时效性。

  • Access Conditions: 读写都受PIN保护。MSD中包含了车辆的VIN和精确的位置轨迹，属于高度敏感的隐私信息，必须加以保护。

总结：为生命救援注入的“确定性”

EFeCall-Code和EF-eCall-Data这对文件，虽然服务于一个极低频（但极其重要）的应用场景，但它们完美地展示了USIM卡如何能够被集成到垂直行业（汽车）的关键安全系统中，为其提供基础的数据支撑和可靠性保障。

  • EFeCall-Code (快捷指令): 为手动eCall提供了一个标准化的、由运营商权威配置的触发机制，确保了在紧急时刻，正确的救援流程能够被迅速启动。

  • EF-eCall-Data (数据急救包): 通过在USIM这个高可靠性的硬件上备份关键的MSD数据，为eCall系统在极端情况下的数据可用性和重传可靠性，提供了一道重要的“安全冗余”。

对于李想而言，当他驾驶着配备了eCall系统的汽车时，他可能永远都不希望用到这些功能。但正是因为有了EFeCall-Code和EF-eCall-Data的存在，USIM卡为这套车载“守护神”系统，注入了一份源自通信核心标准的“确定性”。这份确定性，在最危急的瞬间，可能就是连接生命与希望的桥梁。

FAQ环节

Q1：EFeCall-Code和EFECC（紧急呼叫码）有什么区别？

A1：它们都用于发起紧急呼叫，但类型和流程完全不同。

  • EFECC: 存储的是通用的、面向所有用户的公共紧急号码（如112, 911）。拨打这些号码会触发一个标准的语音紧急呼叫。

  • EFeCall-Code: 存储的是专属于eCall业务的特殊业务代码。拨打这个代码，不仅会建立语音通话，还会告知网络“我即将发送MSD数据包”，从而触发网络侧一系列特殊的eCall处理流程。

前者是“普通急救”，后者是“带全套生命体征监护仪的急救”。

Q2：EF-eCall-Data里的MSD数据是谁生成的？

A2：MSD数据是由车载系统（IVS）生成的。IVS是一个复杂的嵌入式系统，它集成了碰撞传感器、安全气囊控制器、GPS/GNSS模块、通信模块（modem）等。当事故发生时，IVS会实时地从这些传感器和模块中采集数据（位置、时间、车辆VIN等），然后按照EN 15722标准，将这些数据组装成140字节的MSD数据包。USIM的EF-eCall-Data只负责存储这个由IVS生成好的数据包。

Q3：如果EF-eCall-Data里的位置信息是旧的，会不会误导救援人员？

A3：有可能，但这是一种“两害相权取其轻”的设计。MSD数据结构中有一个标志位，可以表明这份数据是“实时”的还是“最后已知位置”。当IVS使用EF-eCall-Data中的备份数据时，它会设置这个标志。救援中心（PSAP）在收到MSD后，看到这个标志，就会知道这个位置信息可能不是100%准确的，但它仍然提供了一个非常有价值的、缩小搜救范围的起点，远比没有任何位置信息要好。

Q4：为什么EF-eCall-Data的更新权限是PIN，而不是ADM？

A4：因为MSD的更新是由车载系统（IVS/ME）在每一次eCall事件后自主完成的，这是一个高频的、事件驱动的正常操作。如果设为ADM，就意味着只有运营商才能更新这份备份，这在逻辑上是不通的，也无法实现“备份最后一次发送”的功能。将其设为PIN，允许IVS在USIM解锁（通常车载USIM会通过某种机制保持解锁状态）的情况下，自行维护这份数据备份。

Q5：这些eCall文件是所有SIM卡都有吗？

A5：不是。只有专门用于车载（M2M/IoT）通信的、并且开通了eCall业务的专用USIM卡，才会被配置这些文件（即EF_UST中服务n°89被激活）。我们个人手机中使用的普通SIM卡，通常不会包含EFeCall-Code和EF-eCall-Data。

关系图谱