GBT27930.2 电动汽车非车载传导式充电机与车辆之间的数字通信协议 第2部分 ChaoJi系统

ICS29.200

K81

中华人民共和国国家标准

GB/T27930.2—XXXX

电动汽车非车载传导式充电机与车辆之间

的数字通信协议第2部分ChaoJi系统

Communicationprotocolsbetweenoff-boardconductivechargerandelectricvehicle

Part2ChaoJiSystem

点击此处添加与国际标准一致性程度的标识

（征求意见稿）

XXXX—XX—XX发布XXXX—XX—实施

前言

本文件按照GB/T1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定

起草。

GB/T27930《电动汽车非车载传导式充电机与车辆之间的数字通信协议》分为2个部分：

——第1部分：GB/T2015系统；

——第2部分：ChaoJi系统。

本文件为GB/T27930的第2部分。

请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。

本文件由中国电力企业联合会提出并归口。

本文件主要起草单位：。

本文件主要起草人：。

II

GB/T27930.2—xxxx

电动汽车非车载传导式充电机与车辆之间的数字通信协议第2部

分ChaoJi充电系统

1范围

本文件规定了电动汽车非车载传导式充电机（以下简称充电机）充电通信控制器（SupplyEquipment

CommunicationController，以下简称SECC）与车辆充电通信控制器（ElectricVehicleCommunication

Controller，以下简称EVCC）之间基于控制器局域网（ControlAreaNetwork，以下简称CAN）的通信物

理层、数据链路层及应用层的定义。

本文件适用于采用GB/T18487.1—202X附录D规定的充电模式4的充电机与车辆之间的通信，也适

用于充电机与具有充电控制功能的车辆电子控制单元之间的通信。

2规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，

仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本

文件。

GB/T19596电动汽车术语

GB/T29317电动汽车充换电设施术语

GB/T18487.1—202X电动汽车传导充电系统第1部分通用要求（征求意见稿）

SAEJ1939-11:2006商用车控制系统局域网CAN通信协议第11部分：物理层，250K比特/秒，屏蔽双

绞线（RecommentedpracticeforserialcontrolandcommunicationvehiclenetworkPart11:Physicallayer–

250Kbits/s,twistedshieldedpair）

SAEJ1939-15:2018商用车控制系统局域网CAN通信协议第15部分：物理层，250K比特/秒，非屏蔽

双绞线（RecommentedpracticeforserialcontrolandcommunicationvehiclenetworkPart15:Physicallayer

–250Kbits/s,Un—ShieldedTwistedPair）

SAEJ1939-21:2006商用车控制系统局域网CAN通信协议第21部分：数据链路层（Recommended

practiceforserialcontrolandcommunicationvehiclenetworkPart21:Datalinklayer）

3术语和定义

GB/T19596、GB/T29317界定的以及下列术语和定义适用于本文件。

3.1

帧frame

组成一个完整信息的一系列数据位。

3.2

CAN数据帧CANdataframe

用于传输数据的CAN协议所必需的有序位域，以帧起始（StartofFrame，简称SOF）开始，帧结

束（EndofFrame，简称EOF）结尾。

3.3

1

GB/T27930.2—xxxx

报文CANmessage

发送或接收参数组及其参数数据的一个实例，一个报文的发送可能需要交互一个或多个“CAN数

据帧”。

3.4

标识符identifier

CAN仲裁域的标识部分。

3.5

扩展帧extendedframe

CAN2.0B规范中定义的使用29位标识符的CAN数据帧。

3.6

优先权priority

在标识符中一个3位的域，设置传输过程的仲裁优先级，最高优先权为0级，最低优先权为7级。

3.7

参数组parametergroup(PG)

在应用层传输的参数集合。

3.8

参数组标识parametergroupidentification(PGI)

用于唯一标识一个参数组的一个字节。

3.9

协议数据单元protocoldataunit(PDU)

一种特定的CAN数据帧格式。

3.10

电子控制单元electroniccontrolunit(ECU)

电子控制单元，即车载电脑，由微控制器和外围电路组成。

3.11

功能模块functionmodule

车辆与充电机的能量交互过程中的某个业务功能。

3.12

必须项功能模块mandatoryfunctionmodule

一个完整的能量交互过程必须具有的功能模块。

3.13

可选项功能模块optionalfunctionmodule

一个完整的能量交互过程可选择具有的功能模块。

3.14

可重载功能模块overridefunctionmodule

可被重新定义和替换的功能模块。

3.15

功能代码functioncode(FC)

为功能模块分配的编号。

3.16

功能描述码functiondescriptioncode(FDC)

为具备特定功能的功能模块实例分配的编号。

3.17

2

GB/T27930.2—xxxx

信息帧informationframe(IF)

数据链路层上用于传输有效信息或数据的CAN数据帧。

3.18

控制帧controlframe(CF)

数据链路层上用于进行流量控制、差错管理、接收确认的CAN数据帧。

3.19

多信息帧传输方式Multi—messageframetransportmode

使用自动重传请求方式传输具有帧编号的多帧数据的方式。

3.20

长消息longmessage

采用多信息帧传输方式传输的消息。

3.21

需要确认的消息reliablemessage

采用自动重传请求方式传输的消息，包括需要确认的短消息和长消息。

3.22

不需要确认的消息unreliablemessage

不需要采用自动重传请求方式传输不具有帧编号的单帧数据。

4缩略语

LM长消息longmessage

RM需要确认的消息reliablemessage

RM_SM需要确认的短消息reliableshortmessage

URM不需要确认的消息unreliablemessage

RM_SM_ACK需要确认的短消息应答确认reliableshortmessageacknowledge

LM_ACK长消息应答确认longmessageacknowledge

LM_NACK长消息放弃连接确认longmessagenegativeacknowledge

LM_EndofACK长消息接收结束确认longmessageendofacknowledge

5总则

5.1充电机与车辆之间的通信网络基于CAN。

5.2充电机与车辆之间的充电通信过程由完成不同业务功能的功能模块按序组成，具体信息交互报

文、交互过程由功能模块的FDC决定。

5.3充电信息交互报文包括各功能模块FDC规定的报文（见附录A）及公共报文（见附录B），基

本充电应用场景的信息交互过程详见附录C。

6物理层

本文件采用的CAN通信总线网络物理层应符合SAEJ1939-11:2006（屏蔽双绞线）或SAEJ1939-

15:2018（非屏蔽双绞线）中关于物理层的规定。本文件充电机与车辆的通信应使用独立的CAN总线，

3

GB/T27930.2—xxxx

并应支持SECC、EVCC、适配器通信控制器（VehicleAdaptorCommunicationController，以下简称VACC）

三个节点，通信速率采用250kbit/s。双绞线满足SAEJ1939—11中5.2.1表7的要求，终端电阻满足SAE

J1939—11:2006中5.2.3的要求。

7数据链路层

7.1帧格式

采用本文件的设备应使用CAN扩展帧的29位标识符，具体每个位分配的相应定义应符合SAE

J1939—21:2006中的相关规定。

7.2协议数据单元

每个CAN数据帧包含一个单一的协议数据单元（PDU），见表1。协议数据单元由七部分组成，分

别是优先权，扩展数据页，数据页，PDU格式，PDU特定格式，源地址和数据域。

表1协议数据单元

D…

EDP

PPPFPSSADATA

3118880—64

注1：P为优先权：从最高0设置到最低7。

注2：EDP为扩展数据页：备今后扩展使用，本文件中为0。

注3：DP为数据页：用来选择参数组描述的辅助页，本文件中为0。

注4：PF为PDU格式消息类型：用来确定PDU的格式，以及数据域对应的消息类型。

注5：PS为PDU特定格式：PS值取决于PDU格式。本文件中采用PDU1格式，PS值为目标地址。

注6：SA为源地址：数据帧的源地址。

注7：DATA为数据域：不同消息类型的数据域定义详见本文件8.2的规定。

7.3协议数据单元(PDU)格式

选用SAEJ1939—21:2006中定义的PDU1格式。

7.4地址的分配

网络地址用于保证信息标识符的唯一性以及表明信息的来源。SECC、EVCC和VACC定义为不可配

置地址，即该地址固定在ECU的程序代码中，包括服务工具在内的任何手段都不能改变其源地址。SECC、

EVCC和VACC的地址分配如表2所示。

表2地址分配

节点首选地址

SECC95(5F)

EVCC37(25H)

VACC96(60H)

4

GB/T27930.2—xxxx

7.5帧类型

本文件规定的帧类型包括信息帧、控制帧2类。

8版本协商

8.1总体描述

版本协商是通信协议的引导部分，协商原则、报文定义和信息交互过程固定不变。版本协商过程中，

充电机和车辆通过协商决定通信协议版本号。版本协商的具体描述如表3所示。

表3版本协商总体描述

序号项目描述信息

1名称版本协商

2目标充电机和车辆协商决定通信协议版本号

通信链路建立后，由充电机发起通信协议版本协商过程，车辆检测是否

支持充电机发送的版本，并返回协商结果：

a)充电机侧

充电机首先发送其支持的最高协议版本号进行协商，如果充电机接收到

“协商成功”信息，进入应用层信息交互过程；如果充电机接收到“协商失

败”信息，通信结束，退出充电过程；如果充电机接收到“继续协商”以及

“车辆期望的版本号”信息，按照以下原则处理：

——如果充电机支持车辆期望的版本，则发送该版本号，等待车辆发

送“协商成功”信息；

——如果充电机不支持车辆期望的版本，且充电机不支持低于车辆当

前期望值的版本，则充电机发送版本号为0的版本信息报文，等

待车辆发送“协商失败”信息；

3描述

——如果充电机不支持车辆期望的版本，但充电机支持低于车辆当前

期望值的版本，则充电机发送“比车辆期望值低的最高版本号”

的版本信息，继续协商。

b)车辆侧

车辆接收充电机协商版本信息，按照以下原则处理：

——如果车辆支持充电机的协商版本，则返回“协商成功”信息；

——如果车辆不支持充电机的协商版本，且不支持低于充电机当前协

商值的版本，则车辆返回“协商失败”信息，通信结束，退出充电

过程；

——如果车辆不支持充电机的协商版本，但支持比充电机当前协商值

低的版本，则车辆返回“继续协商”信息，同时发送“比充电机当

前协商值低的最高版本号”进行协商。

4前置条件物理连接完成，通信链路建立

5其他说明充电机和车辆可支持多个版本的通信协议，只有双方都支持相同的版

5

GB/T27930.2—xxxx

序号项目描述信息

本，版本协商才能成功。

通信协议版本号由CAN类型、主版本号、次版本号、临时版本号组成。

——当前版本的CAN类型为CAN2.0，同时预留CANFD，CANXL的

应用；

——当通信协议有结构性的变化时（如功能模块的组成发生变化），更

新主版本号；

——当通信协议有较大的功能变化，但不影响通信协议的结构，更新

次版本号；

——临时版本仅用于示范项目和测试用途，正式发布的版本中临时版

本号为0。

a)协商成功：车辆和充电机支持相同的版本，车辆发送“协商成功”信息，

双方按照协商一致的版本进行信息交互。

6结束条件b)协商失败，包括：

——版本协商失败，车辆发送“协商失败”信息，退出充电过程。

——版本协商超时，车辆发送“协商失败”信息，退出充电过程。

8.2报文定义

版本协商的交互报文的数据链路层应满足本文件第6章的规定。版本协商过程包括“充电机协议版

本报文”、“车辆协商结果报文”，其帧格式定义如表4，表5所示，参数类型定义详见附录A。

表4充电机协议版本帧格式

协议数

PEDPDPPFPSSA数据域

据单元

占位

31188888888888

（bit）

0x250x5F

定义0x03000x38遵循表6的定义。

(目的地址)(源地址)

表5车辆协商结果帧格式

协议数

PEDPDPPFPSSA数据域

据单元

占位

31188888888888

（bit）

0x5F0x25

定义0x03000x38遵循表7的定义。

(目的地址)(源地址)

表6充电机协议版本数据域内容

序号参数内容长度数据类型参数类型描述与要求

1CAN类型1字节BYTECANType充电机CAN类型，当前版本的CAN类型为

6

GB/T27930.2—xxxx

序号参数内容长度数据类型参数类型描述与要求

CAN2.0。

充电机协商的协议版本号，本文件规定当前版

2协商版本3字节BYTE[3]ProtocolVersionType

本号为V2.0.0。

3预留1字节BYTEReservedType车辆不判断该值

4预留1字节BYTEReservedType车辆不判断该值

5预留1字节BYTEReservedType车辆不判断该值

校验码，采用校验和法计算报文第1个字节到

6校验码1字节BYTECheckcodeType第7个字节的校验码（如果校验和的数值超过

0xFF，则将其补码作为校验和）

表7车辆协商结果数据域内容

序号参数内容长度数据类型参数类型描述与要求

车辆CAN类型，当前版本的CAN类型为

1CAN类型1字节BYTECANType

CAN2.0。

车辆版本协商结果，包括“继续协商”，“协商

2协商结果1字节BYTEVersionResultType

成功”，“协商失败”。

车辆期望或协商一致的版本号：

——如果车辆协商结果为“协商成功”时，

值为双方协商一致的版本号；

——如果车辆协商结果为“继续协商”，值

3期望版本3字节BYTE[3]ProtocolVersionType

为车辆期望的版本号；

——如果车辆协商结果为“协商失败”，值

为0xFFFFFF，此时充电机不判断该

值。

4预留1字节BYTEReservedType充电机不判断该值。

5预留1字节BYTEReservedType充电机不判断该值

校验码，采用校验和法计算报文第1个字节到

6校验码1字节BYTECheckcodeType第7个字节的校验码（如果校验和的数值超过

0xFF，则将其补码作为校验和）

8.3报文交互过程

车辆和充电机物理连接完成，充电机闭合S1开关后应在1s内发送“充电机协议版本报文”。充电

机首先发送其支持的最高协议版本号，车辆接收后检查自身支持的版本号并返回协商结果。如果“继续

协商”，双方继续以较低的版本号进行协商；如果“协商成功”，双方按照协商一致的版本进行信息交

互；如果“协商失败”，双方退出充电过程。

完整的状态转换过程如表8，表9所示。

表8充电机状态转换表

7

GB/T27930.2—xxxx

触发条件

充电机接收接收接收

T1定时器到T2定时器到

“协商成功”“协商失败”“继续协商”

发送CvList（Ns）

S0

队列报文，进入————

初始状态

S1

根据车辆“期望版本号”信息调

S1发送CvList（Ns）

状进入S2进入S3整Ns指向并发送CvList（Ns）进入S3

协商中队列报文，保持S1

态队列报文（详见表3），保持S1

S2

关闭T1，T2定时器，进入功能协商模块

协商成功

S3

关闭T1，T2定时器，退出充电过程

协商失败

注1：T1为充电机发送版本信息报文的周期定时器，充电机发送CvList（Ns）队列报文后重置T1定时器，周期为50ms

注2：T2为版本协商超时定时器，当S1闭合后启动T2定时器，默认为5s

注3：CvList是充电机支持的协议版本队列，版本号从小到大排列，Ns为计数器，初始值指向最高版本号

注4：表中未列举的报文，如版本协商报文以外的或不满足交互顺序的版本内容等均为非法报文，充电机不作任何处理

注5：.—表示充电机不作任何处理

表9车辆状态转换表

触发条件

接收到“版本信息报文”

车辆不支持充电机的协商版不支持充电机的协商版

T2定时器到

支持充电机的本，但支持比充电机当前本，且不支持低于充电机

协商版本协商值低的版本当前协商值的版本

发送“继续协商”信息，

发送“协商失

S1发送“协商成功”信息，发送“比充电机当前协商发送“协商失败”信息，

败”信息，进

协商中进入S2值低的最高版本号”，保持进入S3

入S3

状S1

态S2

关闭T2定时器，进入功能协商阶段

协商成功

S3

关闭T2定时器，退出充电过程

协商失败

注1：T2为版本协商超时定时器，当车辆检测到S1闭合后启动T2定时器，默认为5s

注2：表中未列举的报文，如版本协商报文以外的或不满足交互顺序的版本内容等均为非法报文，车辆不作任何处理

注3：—表示车辆不作任何处理

9传输层

9.1消息类型

8

GB/T27930.2—xxxx

本文件规定的消息类型包括需要确认的消息、不需要确认的消息。需要确认的消息为上层应用提供

可靠性传输服务，按照消息长度分为需要确认的短消息（消息长度小于等于8字节）和长消息（消息长

度大于8字节），长消息按照多信息帧传输方式传输。不需要确认的消息则是面向简单不可靠信息的传

输服务，消息长度小于等于8字节。

9.2不需要确认的消息

不需要确认的消息无需接收方应答确认，上层应用中需周期发送的报文通常定义为该消息类型。不

需要确认的消息的信息帧格式如表10所示。

表10不需要确认的短消息的信息帧定义

协议数

PDPDPPFPSSA数据域

据单元

占位

311888

（bit）

目的源

定义0x06000x36遵循应用层定义，不足8字节的填充0xFF。

地址地址

9.3需要确认的消息

9.3.1需要确认的短消息

发送方发送需要确认的短消息的信息帧后，如果没有接收到应答确认帧，应进行重发，重发次数默

认为4（具体参考第10章具体要求）。如果发送方完成最大重发次数后仍然没有接收到确认信息，发送

方应该放弃进一步尝试，重发的时间间隔为250ms。需要确认的短消息信息帧格式如表11所示，应答确

认帧的格式定义如表12所示。

表11需要确认的短消息的信息帧格式

协议数

PEDPDPPFPSSA数据域

据单元

占位

31188888888888

（bit）

目的源

定义0x04000x35遵循应用层定义，不足8字节的填充0xFF。

地址地址

表12需要确认的短消息的应答确认帧格式

协议数

PEDPDPPFPSSA数据域

据单元

占位

31188888888888

（bit）

0x0目的源

定义000x37010xFF0xFF0xFF0xFF0xFF0xFF

3地址地址

9.3.2长消息

9

GB/T27930.2—xxxx

长消息的传输应遵循9.4规定的多信息帧传输方式，其信息帧格式定义如表13所示。

表13长消息的信息帧格式

协议数

PEDPDPPFPSSA数据域

据单元

占位

31188888888888

（bit）

总字

目的源帧序号：0总帧数0xFF0xFF0xFF0xFF

定义0x06000x34节数

地址地址

帧序号：>0遵循应用层定义，最后一帧不足8字节的，填充0xFF。

注1：为了描述方便，通常用LM（0）表示帧序号为0的长消息信息帧；LM（n）表示帧序号为n（n>0）的长消息信息帧

注2：总帧数为组成应用层报文的所有帧数

注3：总字节数为组成应用层报文的总长度

长消息的控制帧用于差错控制、流量控制及应答确认，包括3类：

——长消息应答确认LM_ACK

——长消息放弃连接确认LM_NACK

——长消息接收结束确认LM_EndofACK

其中LM_ACK，LM_EndofACK是接收方对发送方的控制帧，LM_NACK是接收方或发送方发送给

对方的控制帧。长消息的控制帧格式定义如表14所示。

表14长消息的控制帧格式

协议数

PEDPDPPFPSSA数据域

据单元

占位

31188888888888

（bit）

待接收待接

LM_

起始帧收总0xFF0xFF0xFF0xFF0xFF

ACK：1

序号帧数

目的源

定义0x03000x37LM_

地址地址0xFF0xFF0xFF0xFF0xFF0xFF0xFF

NACK：2

LM_Endo接收的接收的

0xFF0xFF0xFF0xFF

fACK：3总帧数总字节数

注1：为了描述方便，通常用LM_ACK（n,k）表示待接收起始帧序号为n，待接收总帧数为k的长消息应答确认帧

9.4多信息帧传输方式

9.4.1原则

长消息的传输控制分为两个主要功能：分包重组以及连接管理。

9.4.2分包重组

10

GB/T27930.2—xxxx

发送方首先将长消息其拆分为多个信息帧，在建立连接后按序进行传输。接收方接收到所有的数据

帧后再重组成原始信息。

9.4.2.1信息帧

为了保证信息帧能被识别和重组，信息帧数据域的首字节定义为信息帧的帧序号，序号范围为1~255

（序号为0的信息帧，仅仅用于建立连接），信息帧应从编号1开始按序进行发送，最长的数据长度是1785

个字节。当发送方请求建立长消息传输的虚拟连接时，首先发送帧序号为0的信息帧，在收到接收方的

应答确认后，按要求发送信息帧。

每个信息帧（除了最后一个信息帧）都装载着应用层数据中的7个字节，最后一个信息帧的数据域

的8个字节包含：信息帧的序号和至少一个字节的应用层数据，未使用的字节全部设置为0xFF。

9.4.2.2数据传输

信息帧之间的发送间隔时间LMS_T1应不大于10ms。由于无法区分帧序号相同的不同长消息的信息

帧，因此只允许在同一时间建立一个虚拟连接，即只有当发送方或接收方发送长消息放弃连接确认或接

收方发送长消息接收结束确认，才能建立新的虚拟连接。

9.4.2.2信息帧重组

信息帧接收完成后，接收方接收完成所有信息帧后，应按照帧序号从小到大将其重组回原始信息。

9.4.3连接管理

虚拟连接是指在通信过程中，为了传送长消息，在两个节点间建立的临时连接，连接管理规定了虚

拟连接的建立、使用和关闭。

9.4.3.1总则

本文件只支持点到点的长消息传输，其连接管理应遵循以下原则：

——虚拟连接建立前，收发双方应确认记录帧序号的计数器为0，其中发送计数器用于记录下次要

发送的帧序号，接收方计数器用于记录下次要接收的起始帧序号；

——发送方发送帧序号为0的信息帧作为连接建立的请求，接收方应答确认后，连接建立；

——连接建立后，发送方按照接收方的应答确认发送信息帧，发送结束后等待接收方的下一个应答

确认；

——发送方、接收方不支持同时建立两个及以上的虚拟连接；

——当连续出现3次同类型的连接超时后，应返回“发送失败”信息至应用层；

9.4.3.2连接的建立

发送方请求发送长消息时，信息帧帧序号为0，且包含了长消息的总帧数和总字节数。

接收方接收到帧序号为0的长消息后，可选择接收或者拒绝建立连接：如果选择接收，应发送长消

息应答确认帧LM_ACK，且LM_ACK中应包含接收方待接收的起始帧序号、待接收总帧数，发送方接收

到应答确认帧LM_ACK，连接建立完成，之后接接收方应从序号为1的信息帧开始接收；如果接收方缺

少资源或存储空间，可拒绝建立连接，此时应发送放弃连接确认LM_NACK，连接建立失败。

9.4.3.3数据传输

发送方接收到LM_ACK后开始数据传输，由接收方负责调整节点之间的数据流控制，如果接收方需

要暂停数据流，可使用LM_ACK将待接收总帧数置为1，待接收起始帧序号置为前一次接收到的最后一

帧帧序号，发送方按要求发送信息帧（接收方每发送一次LM_ACK，接收方响应一次），接收方收到该

报文后不做处理。

11

GB/T27930.2—xxxx

9.4.3.4连接的关闭

接收方接收到所有信息帧后，应发送消息结束确认LM_EndofACK，通知发送者连接关闭。

在传输过程中，接收方和发送方均可发送LM_NACK终止传输，收到LM_NACK后双方退出长消息

的传输，连接关闭，接收方不对收到的报文作处理。

任一方发生传输故障（例如连续出现3次同类型的连接超时）都会导致连接关闭。

长消息的连接关闭，包括以下情形：

a）发送方：

——完成整个长消息的数据传输且接收到LM_EndofACK

——发送LM_NACK

——接收LM_NACK

b）接收方：

——完成整个长消息的数据传输后发送了LM_EndofACK；

——发送LM_NACK（如发送方希望提早停止通讯，超时等等）；

——接收LM_NACK；

9.4.3.5连接的超时

——接收方接收到一个信息帧后，若LMS_T2时间内未接收到下一个信息帧即为超时，超时后发送

LM_ACK通知发送方重发，连续出现3次超时后发送LM_NACK放弃连接。

——接收方发送LM_ACK后，若LMS_T2时间内未接收到正确帧序号的信息帧即为超时，超时后发

送LM_ACK通知发送方重发，连续出现3次超时后发送LM_NACK放弃连接。

——发送方发送帧序号为0的信息帧后，若LMS_T2时间内未接收到接收方的确认消息即为超时，超

时后重发帧序号为0的信息帧，连续出现3次超时后发送LM_NACK放弃连接；

——发送方发送完成本次需要传输的全部信息帧后，若LMS_T2内未接收到接收方的确认消息

（LM_ACK或LM_EndofACK）即为超时，超时后发送方重发本次传输的最后一帧，连续出现

3次超时后发送LM_NACK放弃连接；

——发送方从发送帧序号为0的信息帧后，传输整个长消息的时间大于LMS_T3即为超时，超时后发

送方发送LM_NACK放弃连接。

LMS_T2=100ms

LMS_T3=10000ms

多信息帧传输方式的完整状态转换过程如表15，表16所示。

12