51学通信

深度解析 3GPP TS 31.101：第6A章 初始通信(Part 2) - 速度与默契的协商：PPS与通信优化

23分钟阅读

好的，遵照您的指令，我们继续深度拆解 3GPP TS 31.101 规范。这是本系列的第六篇文章，将完成对第6A章的解读，聚焦于通信速度的协商与链路的优化。

深度解析 3GPP TS 31.101：第6A章 初始通信(Part 2) - 速度与默契的协商：PPS与通信优化

本文技术原理深度参考了3GPP TS 31.101 V19.0.0 (2025-10) Release 19规范中，关于“Chapter 6A Initial communication establishment procedures”的核心章节，特别是协议与参数选择(PPS)、时钟管理、错误处理等关键部分。本文旨在为读者揭示终端与UICC如何在ATR建立的初步认知上，通过一次精妙的“握手”协商，最终建立起一条高效、节能且稳健的通信链路。

引言：从“能力清单”到“执行合同”

在上篇文章中，我们的新人工程师小林已经成功破译了UICC的“数字出生证明”——ATR。他能够从一串十六进制代码中，解读出UICC支持的通信协议、潜在的最高速度等关键能力。

这周一，导师老王看到小林案头上的ATR解码报告，满意地点了点头，随即抛出了一个新的、更深入的问题：“小林，你现在手握UICC的‘能力清单’(ATR)，就像拿到了一份餐厅的菜单。菜单上写着‘本店可提供T=0协议（家常菜）和T=15协议（特色菜），并支持‘超级加速’烹饪模式’。那么，作为‘顾客’的终端，是如何根据自己的口味和需求，向‘餐厅’UICC下单，最终敲定今天这顿饭具体吃什么、怎么做的呢？这个‘下单’的过程，就是我们今天要学习的PPS协商。”

PPS (Protocol and Parameters Selection) 协商，是初始通信建立过程中的“点睛之笔”。它将ATR中声明的“可能性”转变为当前通信会话中实实在在的“契约”。正是通过PPS，终端与UICC才能摆脱龟速的默认设置，“飙”向更高的通信速率。

1. PPS规程 (6A.4 PPS procedure) - 从试探到握手的“三步舞”

PPS协商的本质，是一次终端与UICC之间关于“我们接下来用什么协议、以什么速度聊天”的正式谈判。

原文引用 (Chapter 6A.4 PPS procedure):

The provisions of ETSI TS 102 221 clause 6.4 apply.

规范再次将我们引向了ETSI的基础标准，其中定义了PPS的完整流程。这个流程，可以被看作是一场优雅的“三步舞”。

1.1 第一步：终端发起PPS请求 - “我想这样，你觉得如何？”

在成功接收并解析ATR后，如果终端发现ATR中表明UICC支持比默认值更优的参数（比如更高的速度，或者终端更偏好的T=1协议），它就会主动发起PPS请求。

场景演绎：

小林在他的协议分析仪上，看到了终端在收到ATR后，立刻发出了一串新的数据：FF 10 96 EF。他知道，这就是PPS请求。老王指导他逐字节进行解析。

一个PPS请求由4个部分组成：PPSS, PPS0, [PPS1, PPS2, …], PPSC。

  • PPSS (Start Byte): 固定为FF。它像是一个信封上的特殊邮戳，明确告知UICC：“这是一封PPS请求信，请注意查收！”

    • 捕获值: FF

  • PPS0 (Format Byte): 格式字节，定义了后续PPS字节的存在情况和选择的协议。

    • 捕获值: 10

    • 解读: 10的二进制是0001 0000。

      • 高4位 0001: 表明后续将包含PPS1字节（用于指定新的F/D参数），但不包含PPS2和PPS3。

      • 低4位 0000: T=0。这表明终端建议（或确认）使用T=0协议进行后续通信。在小林的场景中，ATR表明UICC支持T=0和T=15，终端可能因为自身实现或当前需求的考虑，选择了更简单、更普遍的T=0协议。

  • PPS1 (Parameter Byte 1): 可选参数。根据PPS0的指示，这个字节存在。

    • 捕获值: 96

    • 解读: 这个值通常直接来源于ATR中的TA1字节。96代表终端提议将传输因子切换为(F,D)=(512,32)。这是它向UICC发出的“我们加速吧！”的明确信号。

  • PPSC (Check Sum Byte): 校验和。

    • 捕获值: EF

    • 解读: PPSC是对前面所有PPS字节（从PPSS到最后一个参数字节）进行异或(XOR)运算的结果。FF XOR 10 XOR 96 = EF。UICC会用同样的方法计算校验和，如果结果一致，说明PPS请求在传输过程中没有损坏。

小结: 终端发送的FF 10 96 EF，翻译成“人类语言”就是：“你好UICC，我是终端。我提议我们接下来继续使用T=0协议进行通信，但是请把我们的通信速度参数切换到(F,D)=(512,32)这个高速模式。以上是我的请求，请确认。”

1.2 第二步：UICC处理请求 - “我看看我能不能办到”

收到PPS请求后，UICC内部的微控制器会进行快速决策：

  1. 校验PPSC: 首先计算校验和，如果不匹配，则不作任何响应，终端会在超时后得知请求失败。

  2. 检查参数: 检查终端请求的协议（T=0）和参数（(F,D)=(512,32)）是否在自己ATR中声明的能力范围之内。在这个案例中，ATR的TA1和TD1已经表明UICC完全支持这些参数。

1.3 第三步：UICC返回PPS响应 - “同意！就这么办！”

如果UICC同意终端的请求，它会返回一个PPS响应。这个响应的格式与请求完全一样。

场景演绎：

小林的协议分析仪上，紧接着请求之后，就收到了来自UICC的响应：FF 10 96 EF。

  • 解读: UICC原封不动地返回了终端发送的请求。这是一种“契约式”的确认。它的意思是：“你的请求FF 10 96 EF我已完整无误地收到，并且完全同意。从现在开始，我们的通信就按照这个新规则来办！”

如果UICC不同意呢？

  • 部分同意: 比如终端请求(T=1, 高速率)，但UICC只支持(T=0, 高速率)。UICC可能会在响应中只确认它能支持的部分。但3GPP规范通常要求终端和UICC在此类基础参数上达成一致。

  • 完全不同意: 如果UICC无法满足请求，它将不会返回任何响应。终端在等待一个规定的时间（由etu定义）后，会判定PPS协商失败。

PPS协商成功之后

一旦成功的PPS响应被终端接收，双方之间的“新合同”立即生效。从下一个字节开始，所有的通信都将按照新的协议和速率进行。终端会调整其UART（通用异步收发器）的波特率，以匹配新的F/D参数。通信链路正式从“默认慢车道”切换到了“高速快车道”。

2. 节能的智慧：时钟停止模式 (6A.6 Clock stop mode)

小林注意到一个现象：当手机静置锁屏时，协议分析仪上显示UICC的CLK信号线在大部分时间里都处于静止状态，没有了持续跳变的方波。他向老王请教这是为什么。

原文引用 (Chapter 6A.6 Clock stop mode):

The provisions of ETSI TS 102 221 clause 6.6 apply.

“这就是UICC的‘睡眠模式’，专业术语叫时钟停止(Clock Stop)。”老王解释道，“UICC内部的微控制器就像一个工厂，只要时钟（心跳）在跳动，工厂就在运转，就在消耗能量。但手机和UICC之间并不是时刻都在通信的。在空闲时，让这个工厂‘停工休息’，是手机省电的关键技术之一。”

时钟停止的工作机制：

  1. 能力声明: UICC是否支持时钟停止，以及支持哪种停止方式（时钟停在高电平、低电平，或根本不支持），是在ATR的历史字节中声明的。

  2. 终端控制: 终端是时钟停止的发起者和控制者。当终端预测到接下来一段时间内不需要与UICC通信时，它就可以停止向CLK引脚输出时钟信号。

  3. UICC的响应: UICC检测到时钟信号消失后，会立即进入一个预设的低功耗状态。在这个状态下，它的大部分内部电路都被“冻结”了，功耗可以降低几个数量级。

  4. 唤醒: 当终端需要再次与UICC通信时，它只需重新在CLK引脚上提供时钟信号。UICC检测到时钟恢复后，会从“冻结”的状态中“苏醒”，准备接收新的命令。

工程意义: 对于依靠电池供电的移动设备而言，每一个微安的电流都至关重要。时钟停止模式，是UICC接口层面最直接、最有效的节能手段。它确保了UICC只在需要工作时才消耗显著的能量，极大地延长了手机的待机时间。

3. 精确的时间掌控：比特/字符时长与采样时间 (6A.7 Bit/character duration and sampling time)

PPS协商成功后，通信速率变了。小林好奇地问：“速度变了，那么每个数据比特在信号线上持续的时间也变了。终端和UICC是如何精确同步，确保在正确的时间点去采样信号的呢？”

老王的回答指向了一个核心概念——etu (elementary time unit)。

原文引用 (Chapter 6A.7 Bit/character duration and sampling time):

The provisions of ETSI TS 102 221 clause 6.7 apply.

ETSI规范定义，在UICC接口上，所有的时间度量，都不使用绝对的微秒或纳秒，而是使用一个相对单位 etu。

  • etu 的定义: 1 etu = (F/D) * (1/f)

    • F: 时钟频率转换因子（来自TA1或默认值372）。

    • D: 比特率调整因子（来自TA1或默认值1）。

    • f: 外部时钟频率（由终端提供，如3.57MHz）。

  • 比特时长: 在异步半双工传输中，一个比特在I/O线上持续的时间，就定义为 1 etu。

场景演绎与计算：

  1. PPS协商前 (默认状态):

    • F=372, D=1, f=3.57MHz

    • 1 etu = (372/1) * (1 / 3,570,000 Hz) ≈ 104.2 微秒/比特

    • 波特率 = 1 / (104.2 µs) ≈ 9600 bps (这是一个经典的串行通信速率)

  2. PPS协商后 (高速模式):

    • F=512, D=32, f=3.57MHz

    • 1 etu = (512/32) * (1 / 3,570,000 Hz) ≈ 4.48 微秒/比特

    • 波特率 = 1 / (4.48 µs) ≈ 223,214 bps ≈ 223 kbps

通过计算，小林直观地感受到了PPS带来的巨大速度提升（超过23倍）。

  • 采样时间: 规范还定义，接收方应该在一个比特周期的中间点（大约0.5 etu处）进行电平采样，以获得最可靠的读数，避开信号跳变沿可能存在的不稳定状态。

工程意义: 使用相对单位etu，使得整个通信协议的时序定义与具体的时钟频率f解耦。无论终端提供的时钟是3MHz还是4.8MHz，只要F和D确定了，一个字符需要多少etu来传输就是固定的。这大大增强了协议的通用性和移植性。

4. 稳健通信的保障：错误处理与兼容性 (6A.8 Error handling & 6A.9 Compatibility)

“王工，在高速通信中，如果因为干扰导致某个比特翻转了，怎么办？”小林提出了最后一个问题。

原文引用 (Chapter 6A.8 Error handling):

The provisions of ETSI TS 102 221 clause 6.8 apply.

老王解释道，T=0协议虽然简单，但也包含了一套基础的错误检测和重传机制。

  • 奇偶校验 (Parity Check): 传输的每个字符（字节）都附加一个奇偶校验位。发送方计算数据位中’1’的个数，然后设置校验位，使得整个码字中’1’的个数总是偶数（偶校验）或奇数（奇校验）。接收方进行同样的计算，如果不匹配，则检测到了一个奇偶校验错误。

  • 错误信令: 当接收方（比如终端）检测到一个奇偶校验错误时，它会在一个特定的时间窗口内，将I/O线拉低，向发送方（UICC）发送一个错误信号。

  • 自动重传: 发送方检测到这个错误信号后，会自动重新发送刚才那个出错的字符。

这个简单的机制，可以有效地处理单比特翻转的错误，保证了数据传输的基本可靠性。

最后，关于兼容性(6A.9 Compatibility)，规范再次简单地引用ETSI标准，并指出3GPP应用不需要支持其中的某些为兼容极特殊古老卡片而设计的特性。这再次体现了3GPP规范在通用平台上的“化繁为简”，使得针对3GPP的终端和UICC实现可以更聚焦、更高效。

结论：从试探到高效协同的完美闭环

小林合上了协议分析仪的日志，心中对UICC的初始通信过程形成了一个完整的闭环。他向老王汇报了他的最终理解：

“王工，我现在完全明白了。第6A章描述了一个从‘一无所知’到‘高效协同’的完整建链过程。

  1. 激活与复位 是物理的唤醒，让UICC具备了‘说话’的能力。

  2. ATR 是UICC的‘自我介绍’，它展示了自己的能力菜单。

  3. PPS协商 则是终端与UICC之间基于这份菜单的‘商业谈判’，双方通过请求和响应，达成了一份关于通信协议和速度的‘执行合同’。

  4. 而时钟停止、etu计时、错误处理等机制，则是这份合同的‘补充条款’，确保了双方后续的合作既高效节能，又稳健可靠。

整个过程，就像是两个训练有素的外交官，遵循着一套严谨的礼仪，从初次见面、交换名片，到最终就合作细节达成共识，每一个步骤都精准而高效。”

老王欣慰地笑了：“说得非常透彻。你已经掌握了UICC-终端通信的‘建交’全过程。有了这条稳定可靠的通信链路，我们下一次就可以开始探索UICC的‘内心世界’了——它的文件系统是如何组织的。”

FAQ 环节

Q1：ATR和PPS有什么本质区别？为什么不直接在ATR里规定好最终的通信速率？

A1：本质区别在于**“声明”与“协商”。ATR是UICC单方面的能力声明**，它告诉终端“我最多能跑多快，我支持哪些协议”。而PPS是一个双向的协商过程，终端根据自身能力和ATR信息，提出一个具体的合作方案，UICC确认后双方才共同执行。之所以不直接在ATR里规定，是为了灵活性和兼容性。一个UICC可能被插入支持高速模式的新手机，也可能被插入只支持默认速率的老手机。通过PPS协商，可以确保双方总能找到一个共同支持的最佳工作模式。

Q2：如果PPS协商失败（比如UICC不响应），通信会中断吗？

A2：不会立即中断。如果PPS协商失败，终端和UICC会继续使用ATR建立的默认参数（通常是T=0协议，(F,D)=(372,1)的慢速模式）进行通信。通信链路依然是通的，只是速度会比较慢。终端协议栈可能会记录一个事件或日志，但上层应用（如网络注册）可以继续进行。

Q3：时钟停止(Clock Stop)是由终端还是UICC决定的？

A3：时钟停止的能力由UICC在ATR中声明，但执行完全由终端决定。终端是时钟源，它掌握着启动和停止时钟的主动权。UICC只能被动地响应时钟的变化，进入或退出低功耗状态。

Q4：为什么规范要使用etu (elementary time unit) 这个相对时间单位？

A4：使用etu的核心目的是实现协议时序与物理时钟频率的解耦。通过将所有超时、间隔等时间都定义为N个etu，协议规范本身就不再依赖于终端提供的具体时钟频率（例如是3.57MHz还是4.8MHz）。只要终端和UICC都知道当前的F和D值，它们就可以根据各自的时钟源，计算出etu的绝对时间，从而精确地同步。这使得同一套协议规范可以无缝地应用在不同时钟配置的硬件平台上，大大增强了通用性。

Q5：T=0协议的奇偶校验错误处理机制能应对所有传输错误吗？

A5：不能。奇偶校验是一种非常基础的错误检测机制，它只能检测到奇数个比特的翻转错误。如果在一个字节的传输中，同时有两个比特（偶数个）发生了翻转，奇偶校验是无法检测出来的。此外，它也无法进行错误纠正，只能通过请求重传来解决。对于需要更高可靠性的场景，块导向的T=1协议提供了更强大的错误校验码（如LRC或CRC），可以检测出更多类型的错误，因此在某些高速数据传输场景中更为常用。

关系图谱