ＹＤ中华人民共和国通信标准参考性技术文件
YDC XXXX-2002
cdma2000空中接口技术规范
层3信令
（报批稿）
20xx-xx-xx 发布 20xx-xx-xx 实施中华人民共和国信息产业部科学技术司发布
目录
前言 (1)
1. 范围 (2)
2. 引用标准 (2)
3. 符号及缩略语 (2)
4.概述 (3)
4.1信令结构 (3)
4.2信令和功能 (3)
4.2.1控制平面和数据平面 (3)
4.3.2 到层2的接口 (4)
4.3.2.1 消息控制和状态块（MCSB） (4)
4.3.2.2 接口原语 (4)
4.3.3 资源控制-层3信令控制接口原语 (5)
4.3.4 功能描述 (8)
4.3.5 PDU发送和接收 (8)
5. 移动台CDMA操作的要求 (8)
5.1 保留 (9)
5.2 保留 (9)
5.3 保密与识别 (9)
5.3.1 移动台识别码 (9)
5.3.1.1 IMSI_M_S和IMSI_T_S的编码 (10)
5.3.1.2 IMSI_M_11_12和IMSI_T_11_12的编码 (11)
5.3.1.3 MCC_M和MCC_T的编码 (11)
5.3.1.4 移动台电话号码 (11)
5.3.2 电子串号 (11)
5.3.3 移动台登记标志 (12)
5.3.4 登记存储器 (12)
5.3.5 接入过荷等级 (12)
5.3.6 保留 (13)
5.3.7 保留 (13)
5.3.8 归属系统和网络识别 (13)
5.3.9 本地控制选项 (13)
5.3.10 优选操作选择 (14)
5.3.10.1 优选系统 (14)
5.2.10.2 优选CDMA或模拟 (14)
5.3.11 不连续接收 (14)
5.3.12 鉴权、信令信息/用户数据的加密和话音保密 (14)
5.3.12.1 鉴权 (14)
5.3.12.1.1 公用加密数据（SSD） (15)
5.3.12.1.2 随机查询存储器（RAND） (15)
5.3.12.1.3 呼叫历史参数（COUNT S-P） (15)
5.3.12.1.4 唯一查询-响应过程 (15)
5.3.12.1.5 更新共同加密数据 (15)
5.3.12.2 信令消息加密 (18)
前言
本标准的制定是为了保证我国cdma2000蜂窝移动通信系统系统能够正常运行。本标准可供运营、管理、规划、设计蜂窝移动通信系统和码分多址个人通信业务系统，以及引进或生产相关设备时使用。
本标准规定了cdma2000蜂窝移动通信系统空中接口层3信令的具体要求。
本标准主要依据《3GPP2 C.S0005-A-1》而编写。
附录A和B为标准的附录。
本标准由通信标准技术审查部提出并归口
本标准起草单位是信息产业部电信传输研究所、中兴通讯股份有限公司
本标准主要起草人：郭进军,李星
1. 范围
本标准技术规范文件定义了cdma2000 的高层（层3）信令的结构和原语详细要求。
本标准可供运营、管理、规划、设计蜂窝移动通信系统和码分多址个人通信业务系统，以及引进或生产相关设备时使用。
2. 引用标准
下列标准包含的条文，通过在本标准中引用而构成本标准的条文。在标准出版时，所示版本均为有效。所有标准都会被修订，使用本标准的各方应探讨使用下列标准最新版本的可能性。
1. ANSI/EIA/TIA-691, ANSI Enhanced Analog IS-691, date pending.
2. ANSI T1.607-1990, Integrated Services Digital Network (ISDN)–Layer 3 Signaling Specification for Circuit Switched Bearer Service for Digital Subscriber Signaling System Number 1 (DSS1), July 1990.
3. ANSI TI.610-1994, Generic Procedures for the Control of ISDN Supplementary Services, August, 199
4.
4. ANSI J-STD-018, Recommended Minimum Performance Requirements for 1.8 to 2.0 GHz Code Division Multiple Access (CDMA) Personal Stations.
5. ANSI J-STD-019, Recommended Minimum Performance Requirements for Base Stations Supporting 1.8 to 2.0 GHz Code Division Multiple Access (CDMA) Personal Stations.
6. ANSI X3.4-1986, Coded Character Set - 7-bit American National Standard Code for Information Interchange, 1992.
7. TIA/EIA-97-C, Recommended Minimum Performance Standards for Base Stations Supporting Dual-Mode Spread Spectrum Mobile Stations, date pending.
8. TIA/EIA-98-C, Recommended Minimum Performance Standards for Dual-Mode Spread Spectrum Mobile Stations, date pending.
9. TIA/EIA-553-A, Core Analog Standard 800 MHz Mobile Station - Land Station Compatibility Specification with Authentication, date pending.
10. TIA/EIA-41-D, Cellular Radiotelecommunications Intersystem Operations, December 1997. TIA/EIA-637-A, Short Message Services for Spread Spectrum Cellular Systems.
3. 符号及缩略语
AC: 鉴权中心
AUTHR: 鉴权响应
AURHEBS: 基站鉴权响应
BLOB: 比特块
CDMA: 码分多址
CRC: 循环冗余码
DTMF: 双音多频
ERP: 有效辐射功率
ESN: 电子串号
f-csch: 前向公用信令逻辑信道
f-dsch: 前向专用信令逻辑信道
GPS: 全球定位系统
HLR: 归属位置登记
IMSI: 国际移动台身份码
LSB: 最低有效位
MCC: 移动台国家码
MCSB: 消息控制与状态块
MIN: 移动台识别码
MNC: 移动网码
MSIN: 移动台识别码
MSB: 最高有效位
MSC: 移动交换中心
NMSI: 国内移动台身份码
NDSS: 网络直接系统选择
NID: 网络识别
PACA: 优先接入和信道分配
PCI: 协议控制信息
PCS: 个人通信业务
PDU: 协议数据单元
PN: 伪随机
PUF: 开机功能
RC: 无线配置
RANDBS: 基站随机变量
SAP: 业务接入点
SDU: 业务数据单元
SSD: 公用加密数据
SMS: 短消息业务
SID: 系统标识
SCM: 电台级别标志
TMSI: 临时移动台身份码
4.概述
4.1信令结构
CDMA2000的层3信令结构模型如下：
? 平面. 共有两个平面：数据平面（用于信令协议）和控制平面（根据功能要求用于协议的监控）。
? 协议层. 层3产生层3 PDU，并将这些PDU传送给低层，并在低层进行低层PDU的封装。在接收端，低层PDU被分解，分解出的SDU被从低层送往高层处理。
? 业务接入点. SAP及相应的通信原语被定义在层3与低层之间的数据平面上。控制平面通信未定义SAP。
4.2信令和功能
4.2.1控制平面和数据平面
通常结构表现为两个平面：控制平面，产生处理决定；数据平面，产生PDU，对其进
行处理并发送。数据平面包含有协议，并被划分成几个层次。
4.3.2 到层2的接口
层3和层2间的接口是业务接入点(SAP)。在SAP上，层3与层2使用一组原语以消息控制和状态块（MCSB）的形式交换业务数据单元（SDU）和业务控制信息。
4.3.2.1消息控制和状态块（MCSB）
MCSB为定义原语的一个参数块，包含关于个体层3消息的相关信息，及消息如何被控制或消息如何（在发送时或在接收时）被层2处理。MCSB为是一个概念上的结构并不是本文献的具体规范；然而，可以想象MCSB将包含以下信息：
? MSG_TAG.若该消息产生以响应之前接收到的消息，之前接收到的消息的MSG_TYPE也被存储。
? PDU的长度。
? 与该事件相关的唯一事件标识，使发送/非发送或恢复过程通知的消息标识成为可能。? 消息是否在层2被确认（即，在允许模式或非允许模式下发送）
? 消息发送通知是否需要。
? 消息的地址身份。
? 被发送到层3的PDU是否是一个副本（层2不丢弃副本的情况下）。
? 鉴权过程所需的数据（即，起呼消息CHARi域）
? 相关PDU分类(即，登记，起呼)，其中层2的处理对被发送的PDU是很敏感的。
? 逻辑信道的加密状态。
? 对应于接收消息第一位和最后一位的帧的CDMA系统时间。
? 层2的传输指令，如以一定优先级发送消息的指令（在前，在后，或中断其他消息的发送），关于监控的指令，等等。
? 来自层2的异常指示。
4.3.2.2 接口原语
如下原语适用于层3与层2之间的通信。
原语名称: L2-Data.Request
类型: 请求
方向: 层3到层2
参数: PDU, MCSB
动作: PDU被传递给层2为了能够通过空中接口发送.。
原语名称: L2-Data.Confirm
类型: 确认
方向: 层2到层3
参数: MCSB
动作: 指定（在MCSB中）被发送的PDU的接收在层2通过地址证实。
原语名称: L2-Data.Indication
类型: 指示
方向: 层2到层3
参数: PDU, MCSB
动作: 接收的PDU被传送给层3.。
原语名称: L2-Condition.Notification
类型: 指示
方向: 层2到层3
参数: MCSB 3
动作: 层3被通知发现层2中有关事件（如，异常情况）。细节通过MCSB指出。
原语名称: L2-Supervision.Request
类型: 请求
方向: 层3到层2
参数: MCSB
动作: 层2执行一个层3指示的控制命令。这可能是，比如，一个为了消息序列号，证实序列号和副本侦测的本地重置放弃一个消息或指令的重传的指令。
4.3.3 资源控制-层3信令控制接口原语
资源控制和层3信令控制之间交换的接口原语列于表4.3.3-1，表4.3.3-2，及表4.3.3-3。原语定义如下：
?SIG-Allocate (见表4.3.3-1和4.3.3-2)
?SIG-Release (见表4.3.3-1和4.3.3-2)
?SIG-Send (见表4.3.3-3)
?SIG-Receive (见表4.3.3-3)
?RC-Reset (见表4.3.3-3)
?SIG-UpdateServiceInfo (见表4.3.3-3)
SIG-Allocate.Request原语携带4个参数：
资源列表-这是一组标记用于表示资源控制需要连接什么样的资源。可能的标记如下：“SO_INSTANCE”：有该标记表示SO参数对应于一个新的业务选项连接请求。“FCH”：表示基本信道。
“DCCH”：表示专用控制信道。
“CONT_REV_PILOT”：表示连续的反向导频。若有的话，它表示开始连续的反向导频操作。SO(业务选项)-该16位的字段带有业务选项号，so。若为NULL，表示该参数为无效值。CON_REF(连接参考)-该8-bit字段带有连接参考号，con_ref。对于SIG-Allocate.Request原语，该参数总是置为NULL，表示该参数为无效值。
BLOB-该7位字段带有一个比特块，blob,被从移动台（或基站）的资源控制发送到对等的基站（或移动台）的资源控制。层3不解释该字段，且层3信令在空中接口上透明的传送该字段。
当一个SIG-Allocate.Request原语被层3信令控制接收到，层3信令将根据原语中每个参数的值执行如下操作：
?SIG-Allocate.Request({“SO_INSTANCE”, {“FCH”, “DCCH”, or both}}, so, NULL, blob):
层3建立基本信道，专用控制信道，或都有。
层3连接业务选项号so给定的业务选项。
层3初始化连续反向导频操作。
请求实体的层3通过空中接口传送blob参数到对等实体，并被发送到资源控制。
?SIG-Allocate.Request({“FCH”, “DCCH”, or both}, so, NULL, blob):
层3建立基本信道，专用控制信道，或都有。
层3恢复所存储的业务连接。
层3初始化连续反向导频操作。
请求实体的层3通过空中接口传送blob参数到对等实体，并被发送到资源控制。
?SIG-Allocate.Request({“SO_INSTANCE”}, so, NULL, blob):
层3连接业务选项号，so，给定的业务选项。
接收实体的层3通过空中接口传送blob参数到对等实体，并被传送到资源控制。
?SIG-Allocate.Request({{“FCH” or “DCCH”} and/or “CONT_REV_PILOT”}, NULL, NULL, blob):
层3建立基本信道或专用控制信道
层3初始连续反向导频操作，若有”CONT_REV_PILOT”标记。
请求实体的层3通过空中接口传送blob参数到对等实体，并被发送到资源控制。
应该注意，当业务选项号被在SIG-Allocate.Request原语中传送时，这里有层3将建立业务选项连接的意思。层3要求的可选的业务选项和业务协商策略假定是层3已知的，尽管他们不是很明显的在SIG-Allocate.Request原语中传送。
SIG-Release.Request原语带有4个参数：
资源列表-这是一组标记用于表示资源控制需要连接什么样的资源。可能的标记如下：“SO_INSTANCE”：有该标记表示SO参数对应于一个新的业务选项连接请求。“FCH”：表示基本信道。
“DCCH”：表示专用控制信道。
“CONT_REV_PILOT”：表示连续的反向导频。若有的话，它表示停止连续的反向导频操作（即，操作的门控模式）。
SO(业务选项)-该16位的字段带有业务选项号，so。若为NULL，表示该参数为无效值。CON_REF(连接参考)-该8-bit字段带有连接参考号，con_ref。对于SIG-Allocate.Request原语，该参数总是置为NULL，表示该参数为无效值。
BLOB-该7位字段带有一个比特块，blob,被从移动台（或基站）的资源控制发送到对等的基站（或移动台）的资源控制。层3不解释该字段，且层3信令在空中接口上透明的传送该字段。
当SIG-Release.Request原语被层3信令控制接收到，层3信令将根据原语中每个参数的值执行如下操作：
?SIG-Release.Request({“SO_INSTANCE”, {“FCH”, “DCCH”, or both}}, NULL, con_ref, blob): 层3释放基本信道，专用控制信道，或都有。
层3断开业务选项与连接参考号，con_ref，给定的连接参考间的连接。
请求实体的层3通过空中接口传送blob参数到对等的实体，并被传送到资源控制。
?SIG-Release.Request({“FCH”, “DCCH”, or both}, NULL, NULL, blob):
层3释放基本信道，专用控制信道，或都有。
请求实体的层3通过空中接口传送blob参数道对等的实体，并被传送到资源控制。
?SIG-Release.Request({“SO_INSTANCE”}, NULL, con_ref, blob):
层3断开业务选项和连接参考号，con_ref，给定的连接参考的连接。
请求实体的层3通过空中接口传送blob参数到对等的实体，并被传送到资源控制。
?SIG-Release.Request({{“FCH” or “DCCH”} and/or “CONT_REV_PILOT”}, NULL, NULL, blob):
层3释放基本信道或专用控制信道。
层3初始化门控反向导频操作，若有”CONT_REV_PILOT”标记。
请求实体的层3通过空中接口传送blob参数到对等实体，并被传送到资源控制。
当完成SIG-Allocate.Request或SIG-Release.Request原语请求的操作后，层3信令控制通知基站的和移动台的资源控制。若最初的请求来自移动台（或基站）的资源控制，然后SIG-Allocate.Confirm或SIG-Release.Confirm原语将被发送到移动台的资源控制（或基站）且SIG-Allocate.Indication或SIG-Release.Indication被发送到基站（或移动台）的资源控制。SIG-Allocate.Confirm和SIG-Allocate.Indication原语带有如下参数：
资源列表-这是一组标记用于表示资源控制需要连接什么样的资源。可能的标记如下：“SO_INSTANCE”：有该标记表示SO参数对应于一个新的业务选项连接请求。“FCH”：表示基本信道。
“DCCH”：表示专用控制信道。
“CONT_REV_PILOT”：表示连续的反向导频。若有的话，它表示开始连续的反向导频操作。SSR_ID-信令业务参考标识。若业务选项被连接，该字段被置为分配给那个业务选项连接的前向业务类型的值。若为NULL，表示该参数为无效值。
SO(业务选项)-该16位的字段带有业务选项号，so。若为NULL，表示该参数为无效值。CON_REF(连接参考)-该8-bit字段带有连接参考号，con_ref。对于SIG-Allocate.Request原语，该参数总是置为NULL，表示该参数为无效值。
BLOB-该7位字段带有一个比特块，blob，由资源控制提供。
SIG-Release.Confirm和SIG-Release.Indication原语带有4个参数：
资源列表-这是一组标记用于表示资源控制需要连接什么样的资源。可能的标记如下：“SO_INSTANCE”：有该标记表示SO参数对应于一个新的业务选项连接请求。“FCH”：表示基本信道。
“DCCH”：表示专用控制信道。
“CONT_REV_PILOT”：表示连续的反向导频。若有的话，它表示停止连续的反向导频操作（即，操作的门控模式）。
SO(业务选项)-该16位的字段带有业务选项号，so。若为NULL，表示该参数为无效值。
CON_REF(连接参考)-该8-bit字段带有连接参考号，con_ref。对于SIG-Allocate.Request 原语，该参数总是置为NULL，表示该参数为无效值。
BLOB-该7位字段带有一个比特块，blob，若为NULL，表示该参数位无效值。
SIG-Send.Request和SIG-Receive.Indication原语带有一个参数，PP_BLOB。该13位的字段带有一个比特块，pp_blob。该参数被移动台资源控制发送到层3信令并通过空中接口，封装在一个对等资源控制（微型）消息中，发送到基站，且它是被层3信令发送到对等资源控制的。层3不解释该字段且层3通过空中接口透明的传送该字段。
RC-Reset.Request原语不带有任何参数且其被层3信令发送到资源控制。因为基站的资源控制PLICF和移动台的资源控制是不同步的，它请求资源控制重置与每个业务选项连接有关的PLICF。
SIG-UpdateServiceInfo.Indication原语被用于通知资源控制业务选项连接已被新的业务选项连接取代或业务选项连接的业务类型已经发生变化。该原语带有4个参数：
SSR_ID-信令业务参考标识。对于业务选项连接的替代情况，该字段被置为业务选项连接的前向业务类型；对于业务选项连接的业务类型改变的情况，该字段被置为前向业务类型的以前的值
NEW_SSR_ID-新信令业务参考标识。对于业务选项连接的替代情况，该字段被置为业务选项连接的前向业务类型的当前值；对于业务选项连接业务类型改变的情况，该字段被置为前向业务类型的新值。
SO-业务选项。对于业务选项连接的替代强矿，该字段被置为新的业务选项；对于业务选项连接的业务类型改变情况，该字段被置为当前业务选项。
CON_REF-连接参考。对于业务选项连接替代的情况，该字段被置为新连接参考；对于业务选项连接的业务类型改变情况，该字段被置为当前的业务参考。
表4.3.3-1 (略)
4.3.4 功能描述
在数据平面，层3根据基站和移动台间通信协议的语义和定时发起并终止信令数据单元。从语义角度看，信令数据单云可理解为”消息”(或”指令”)。从协议角度看，信令数据单元即PDU。一般来说，本技术规范的语言不严格区分语义和协议，也不明确区分”PDU”和”消息”。
但本规范的内容将会提供足够的信息以使读者能够产生适当的区分。
4.3.5 PDU发送和接收
层3使用该项在与层2接口上提供的业务传送PDU进出层3实体。
当请求一个PDU的发送时，层3将指定传输是在允许模式下执行还是在非允许模式下执行（例如，在L2-Data.Request原语的MCSB中设置适当的参数）。对于允许模式下的传送，层3会指定PDU的发送确认是否需要。
层2保证从发送的层3实体接收到的一个允许模式的PDU能够被发送到接收的层3实体。每个允许模式的PDU只被发送到接收层3实体一次且不出错。若发送的层3实体请求一个允许模式PDU的发送确认，当层2接收到那个PDU的确认，层2将发送一个指示到发送的层3实体（例如，使用L2-Data.Confirm原语）。若层2不能发送一个允许模式的PDU，它将发送一个失败指示到可以进行纠正操作的层3。
层2不保证从发送的层3实体接收到的允许模式的PDU能够被发送到接收的层3实体。因此，对于非允许模式的PDU层2确认不会被要求。为了增加非允许模式PDU发送的可靠性，层3会请求层2以一个很快的频率重复发送那些PDU多次并利用接收机的副本侦测能力获得发送时PDU。
层3也可以请求层2执行一个层2 ARQ过程的重置（例如，使用L2-Supervision.Request 原语）。
5. 移动台CDMA操作的要求
本章对CDMA移动台设备和操作的要求进行详细说明。一个CDMA移动台会支持一个或多个波段类。
5.1 保留
5.2 保留
5.3 保密与识别
5.3.1移动台识别码
工作在CDMA模式的移动台通过国际移动台身份码（IMSI）识别的。移动台将有两个不同的标识，IMSI_和IMSI_M。IMSI由不超过15个数字组成（0-9）。IMSI前3个数字为移动台国家码（MCC），剩下的数字是国内移动台识别码(NMSI)。NMSI又由移动台网络码（MNC）和移动台识别码（MSIN）组成。IMSI结构如图5.3.1-1所示。
MCC(3个数字)(10bits) MNC(2个数字)(7bits) MSIN(不大于10个数字)
MCC 移动台国家码
MNC 移动台网号
MSIN 移动台识别码
NMSI 国内移动台识别码(MNC+MSIN)
IMSI 国际移动台识别码(MCC+MNC+MSIN)
图5.3.1-1 IMSI结构
长度为15的IMSI，是0类IMSI(NMSI长为12)，IMSI长度少于15的是1类IMSI(NMSI 少于12个数)。
IMSI_M是一个在NMSI的低十位上包含一个MIN的IMSI。一个IMSI_M可以为0类或1类IMSI。若IMSI_M未被程控，移动台将置IMSI_M的低四位数字为ESN P的值，直接由二进制转换为十进制，并模10000，且置其它数为0。
IMSI_T是一个与分配给移动台的MIN无关的IMSI。IMSI_T可以是0类的或1类的IMSI。若IMSI_T非程控的，移动台将置IMSI_T的低四位数字为ESN P的值。
当工作在CDMA模式，移动台将设置其操作IMSI值，IMSI_O，为IMSI_M或者IMSI_T，这将取决于基站的性能（见5.6.2.2.5）。
IMSI_S为来自IMSI的10个数字（34比特）。当IMSI有10个或更多数时，IMSI_S等于IMSI最后10个数，如果IMSI长度小于10，IMSI_S的低有效位数字等于IMSI，零被填在最高有效位比特以达到总数10个数。10位数字的IMSI_S由3个和7个数部分组成，称为IMSI_S2和IMSI_S1，由图5.3.1-2说明，IMSI_S被编为34比特(见5.3.1.1)。IMSI_M的IMSI_S被指定为IMSI_M_S。IMSI_T的IMSI_S被指定为IMSI_T_S。IMSI_O的IMSI_S被指定为IMSI_O_S。
移动台将记忆存储34位IMSI_M_S P和34位IMSI_T_S P。IMSI_M_S P通过10位IMSI_M_S2P和24位IMSI_M_S1P。IMSI_T_S P通过10位IMSI_T_S2P和24位IMSI_T_S1P。
当一个IMSI有12或更多数时，IMSI_11_12等于IMSI数中的第11位和12位数字。当IMSI小于12个数时，数值前填0补足12位数,且IMSI_11_12等于等于数中的第11位和12位数字。
IMSI_11_12按5.3.1.2中所述编码。移动台将记忆存储7位IMSI_M_11_12P和7位IMSI_T_11_12P。
3位MCC按5.3.1.3中所述编码。移动台将记忆存储10位MCC_M P和10位MCC_T P。
若移动台有1类IMSI_T，或IMSI_M，它将记忆存储IMSI_T_ADDR_NUM P和IMSI_M_ADDR_NUM P。
IMSI_T_ADDR_NUM P等于NMSI减4的数。IMSI_M_ADDR_NUM P等于IMSI_M的NMSI
减4的数。
5.3.1.1 IMSI_M_S和IMSI_T_S的编码
IMSI_M_S和IMSI_T_S二进制编号定义如下：
IMSI_M_S及IMSI_T_S的开始3个数通过以下编码算法编成10比特(对应于IMSI_S2p)
用D1、D2、D3代表3个数，0值为10
a.
计算100×D1+10×D2+D3-111
b.
c.
按以下标准十进制与二进制转换如下表5.3.1.1-1
表 5.3.1.1-1十进制到二进制的转换表
十进制数二进制数
0 0000000000
1 0000000001
2 0000000010
3 0000000011
4 0000000100
……
998 1111100110
999 1111100111
接下来3个数字分别编码成IMSI_M_S1P和IMSI_T_S1P的最高10位有效位比特，编码方式如1所述
IMSI_S的最后四位按下述方式分别映射成IMSI_M_S1P和IMSI_T_S1P的最低14位有效比特：
IMSI_S的千位数字根据BCD转换规则映射成4个比特，如表5.3.1.1-2所述。
最后3位数字编码成IMSI_S1P的最低10位有效位比特，编码方式如1所述。
以下例子说明IMSI_T_S2P和IMSI_T_S1P的计算过程。
设IMSI_T为9位数123456789。已知IMSI_T小于10位，IMSI_T_S的低9位数等于IMSI_T数且
IMSI_T_S的最高位数被置为0。所以10位IMSI_T_S为0123456789。IMSI_T_S2P和IMSI_T_S1P
计算如下：
? IMSI_T_S2P。10位ISMI_T_S2P来自IMSI_T_S的前3位（即012）：
D1=10;D2=1;D3=2
100×D1+10×D2+D3-111=100×10+10×1+2-111=901
901用二进制表示为’1110000101’
因此，IMSI_T_S2P为’1110000101’。
? IMSI_T_S1P。IMSI_T_S1P的前10位来自IMSI_T_S的其次3位（即345）
D1=3;D2=4;D3=5
100×D1+10×D2+D3-111=100×3+10×4+5-111=234
234用二进制表示为’0011101010’
IMSI_T_S1P的其次4个数字来自BCD转换的IMSI_T_S的千位数字（即6）：（6）BCD
=’0110’。
IMSI_T_S1P的最低10位来自IMSI_T_S的最低三位（即789）：
D1=7;D2=8;D3=9
100×D1+10×D2+D3-111=100×7+10×8+9-111=678
678用二进制表示为’1010100110’
因此，IMSI_T_S1P等于’001110101001101010100110’
5.3.1.2 IMSI_M_11_12和IMSI_T_11_12的编码
IMSI_M_11_12和IMSI_T_11_12的二进编码如下：
用D11代表第11位数，D12代表第12位数，如果值为零用10代替
计算10×D12+D11-11
通过表6.3.1.1-1的所述的十进制-二进制转换将第2步的结果转换为二进制数并限定结果在低7位。
5.3.1.3 MCC_M和MCC_T的编码
MCC_M和MCC_T的编码定义如下：
用D1、D2、D3代表3位数国家码，0数值用10代替
计算100×D1+10×D2+D3-111
将第2步计算出的结果通过标准十进到二进转换，转换如表5.3.1.1-1所述。
5.3.1.4 移动台电话号码
移动台电话号码（MDN）是一个通过业务预约与移动台对应的可拨打的号码。移动台电话号码不如移动台标识在空中接口上那样重要，如，MIN,IMSI_M,或IMSI_T。一个MDN 由15个数字组成。移动台应该记忆存储至少一个移动台电话号码（见表F.3-1）。
5.3.2 电子串号
ESN是一个32位二进制数用于唯一识别移动台与其它任一无线系统。ESN值可以从移动台中获得的为变量值ESN P。RN_HASH_KEY S变量值与变量ESN P值相同，不需要分别存储。
5.3.3 移动台登记标志
移动台的等级信息称为移动台等级标志（SCM P），必须贮存在移动台内。此0类和1类的等级标志的数字表示表5.3.3-1所示。
5.3.3--1移动台等级标志
表5.3.3
功能比特设置
保留7总为 0×××××××
双模6仅 CDMA ×0××××××
双模×1××××××
×时隙划分等级5无时隙××0××××
×××××
划分时隙××1×××××IS--54 功率等级4总为 0 ×××0××××IS
25 MHZ 带宽3总为1××××1×××
发送2连续×××××0××
非连续×××××1××
0 0
功率等级1～0第一级××××××0 0
第二级××××××0 1
第三级×××××× 0
1 0
保留××××××11
当采用0类的模拟方式时，移动台将置功率等级功能位为将其0类的模拟功率级别各位前后调换之后的值，而不管其工作在和波段类；否则，移动台将置这些位为’00’。
5.3.4 登记存储器
移动台在基于区域登记表ZONE_LIST S-P(见5.6.5.1.5和5.6.5.5)中有一个存贮单元。该存贮单元将包括REG_ZONE和对应的(SID、NID)对。在关机状态下数据的保留时间至少为48小时。48小时后，若不能保证数据的完整性，则输入的ZONE_LIST S-P在开机后将被删除。移动台内有存贮器来存贮系统/网路登记表SID_NID_LIST S-P(见5.6.5.1.5和5.6.5.5)的内容。在关机状态下的数据保留时间至少为48小时。48小时后，若不能保证数据的完整性，那么在开机后将删除SID_NID_LIST S-P中的各项数据。
移动台有存贮器用于存贮基于距离登记的变量BASE_LAT_REG S-P，BASE_LONG_REG S-P和 REG_DIST_REG S-P(见 5.6.5.1.4和5.6.5.5)。在关电状态下的数据保留时间至少为48小时。在48小时后，若不能保证数据的完整性，则在开机后REG_DIST_REG S-P将被置为0。
5.3.5 接入过荷等级
4比特过荷等级指示(ACCOLC P)用于识别通过移动台尝试的过荷等级控制接入，并用于识别在总体业务重指示中的重指示过荷等级。
移动台将存储4比特接入过荷等级（ACCOLC P）。非测试的移动台和非紧急使用的移动台分级为ACCOLC 0至ACCOLC 9，移动台的4比特接入级指示(ACCOLCp)将自动从IMSI最后一位数
的十进制转换为二进制数，如表5.3.5-1所示。当相应的数字移动台IMSI更新时，移动台将
重新计算ACCOLC P如上所述。测试用的移动台应该分配ACCOLC 10;紧急使用的移动台应该分
配ACCOLC 11。ACCOLC 12到ACCOLC 15被保留。如表5.3.5-2定义的对过荷等级ACCOLC10至
ACCOLC15编成4比特ACCOLCp的程序，仅为设备厂家和系统运营者所使用。
ACCOLC P的内容将不会通过移动台显示器显示出来。
.5--1 ACCOLC0到ACCOLC9的二进制表示
5.3.5
表5.3
.5
IMSI的最后一位数字ACCOLC P
0 0000
1 0001
2 0010
3 0011
4 0100
5 0101
6 0110
7 0111
8 1000
9 1001
5.3.6 保留
5.3.7 保留
5.3.8 归属系统和网络识别
除移动台为800MHz模拟操作存储的HOME_SID P参数外，移动台将提供给存贮器至少
一个归属(SIDp，NIDp)对。移动台也将提供给存贮器1比特的参数 MOB_TERM_HOMEp，
MOB_TERM_FOR_SIDp以及MOB_TERM_FOR_NIDp(见 5.6.5.3)。
5.3.9 本地控制选项
若移动台支持本地控制选项，在移动台打开或关闭本地控制选项间将提供一个方案。
5.3.10 优选操作选择
5.3.10.1优选系统
若移动台支持0类的操作（见3GPP2 C.S0002）,一个方案将在移动台识别优选系统中被提供。另外，移动台会提供一个允许只工作在系统A或只工作在系统B的方案。
5.2.10.2 优选CDMA或模拟
若移动台支持0类操作（见3GPP2 C.S0002），将提供在移动台识别优选操作类型是CDMA模式还是模拟模式的方案。另外，移动台会提供一个允许只工作优选方式下的方案。
5.3.5--2 ACCOLC10到ACCOLC15的二进制表示
表5.3.5
过载等级ACCOLC P
10 1010
111011
12 1100
13 1101
14 1110
15 1111
5.3.11不连续接收
移动台将提供存储器存储优先的时隙周期指数，SLOT_CYCLE_INDEX P（见5.6.2.1.1.3.2）。
数据的加密和话音保密
用户数据的加密和话音保密
5.3.12 鉴权、信令信息/用户
5.3.12.1鉴权
鉴权是一种移动台与基站之间的信息交换过程，用于证实移动台的识别。仅当证明移动台和基站具有相同的共用加密数据组时，鉴权过程才是成功的。
鉴权算法在”通用加密算法”有所表述。算法的接口(输入和输出参数)表述在”通用加密算法的接口规范”中。表 5.3.12.1-1总结了该标准中每一次使用鉴权签字程序(Auth Signature Procedure)的输入参数组。
表5.3.12.1-1鉴权特征程序输入参数
程序
RAND_
RAND_
CHALLENGE
CHALLENGE
ESN
ESN
A UTH_
UTH_
DATA
DATA
SSD_AUTH
SSD_AUTH
SAVE_
SAVE_
REGISTERS
REGISTERS
独特查询(5.3.12.1.4) RANDU和IMSI_S2的
最低8位有效比特
ESNp IMSI_S1SSD_A “伪”
基站查询
(5.3.12.1.5)
RANDBS ESNp IMSI_S1SSD_A_NEW “伪”
5.3.12.1.1 公用加密数据（SSD）
SSD是移动台半永久性存贮器中存贮的128比特，且基站很容易的就可以获得移动台SSD。如图5.3.12.1.1-1所示，SSD被分为两个单独的子集。每个子集被用于支持不同的操作。SSD_A用于支持鉴权过程，SSD_B用于支持话音保密（见5.3.12.3）和消息加密(间5.3.12.2)。SSD根据5.3.12.1.5定义的过程产生，而且用户是无法访问SSD的。
5.3.12.1.2 随机查询存储器（RAND）
RAND是一个保存在移动台中的32位值。当工作在CDMA模式，它等于最近一次接收到的CDMA f-csch的接入参数消息RAND值。
RAND S被用于SSD_A和其他参数的连接，以鉴别移动台发始呼叫，接收呼叫和登记。
5.3.12.1.3 呼叫历史参数（COUNT S-P）
COUNT S-P是移动台中的一个模-64计数。当参数更新指令在f-dsch上被接收到时，COUNT S-P被移动台更新。
5.3.12.1.4 唯一查询-响应过程
唯一查询-响应过程是由基站初始化且既可在f-csch和r-csch上执行又可在f-dsch和r-dsch上执行。过程如下：
基站产生一个24位数量RANDU并放在鉴权查询消息中在f-csch或f-dsch上发送到移动台。一旦接收到鉴权查询消息，移动台将置Auth_Signature过程的输入参数（见通用加密算法的接口规范”的节2.3）如图5.3.12.1.4-1所示。RAND_CHALLENGE输入参数的最高24个有效位将用RANDU填入，且RAND_CHALLENGE最低8个有效位将用IMSI_S2的最低8个有效位填入。
移动台将置SAVE_REGISTERS输入参数为FALSE。
然后移动台将执行Auth_signature过程。18位输出AUTH_SIGNATURE将用于填充鉴权查询响应消息的AUTHU字段，该消息将发往基站。
基站用与移动台同样的方法计算AUTHU值，但使用其内部存贮的SSD_A值。基站将计算出的AUTHU值与从移动台收到的AUTHU值进行比较。若比较失败，基站则否认移动台的进一步接入尝试，在进展过程中断呼叫或启动更新SSD的过程(见 5.3.12.1.5)。
5.3.12.1.5 更新共同加密数据
SSD用SSD生成过程进行更新，由移动台特定信息、随机数据和移动台A钥进行初始化。 A 钥为64比特长。它分给移动台并存贮在移动台的永久性安全和识别存贮器中。仅有移动台及与其相关的（HLR/AC）（见TIA/EIA-41-D）知道A钥。无手动方法，诸如TIA/EIA/IS-683-A
所述，被优选为A钥进入移动台的入口。TSB50描述了当自动方法不可用时的可被使用的手动方法。
SSD更新过程完成如下(见图5.3.12.1.5-1):
基站在f-csch或f-dsch上发送SSD更新消息。SSD更新消息的RANDSSD字段包含与HLR/AC 计算出的SSD同样的值。
在收到SSD更新消息后移动台将设置SSD生成过程的输入参数，如图5.3.12.1.5-2所示。然后移动台将运行SSD生成过程。移动台将设置SSD_A_NEW与SSD_B_NEW为SSD生成过程的输出值。
然后移动台选择32比特的随机数，RANDBS，并通过在r-csch或r-dsch上的基站查询指令消息发往基站。
移动台和基站将设置Auth_Signature过程，如图5.3.12.1.5-3所示，并运行Auth_Signature过程。
移动台和基站将设置SAVE_REGISTER输入参数为False。
移动台和基站将运行Auth_Signature过程。AUTHBS设置为18比特的输出结果AUTH_ SIGNATURE。基站在f-csch或f-dsch上的基站查询证实指令消息中将AUTHBS值发往移动台。在收到基站查询证实指令消息后，移动台将收到的AUTHBS值与其内部计算的值进行比较。(若当SSD更新未进行时移动台收到基站查询证实指令消息，移动台将响应以SSD更新拒绝指令消息)。
若比较结果成功，移动台将运行SSD更新程序，分别将SSD_A和SSD_B设置为SSD_A_NEW 和SSD_B_NEW。然后移动台将发送SSD更新证实指令消息给基站，表示成功地完成了SSD更新。若比较不成功，移动台将舍弃SSD_A_NEW和SSD_B_NEW。然后移动台向基站发送SSD更新拒绝指令(SSD Update Rejection Order)，表示SSD更新没有成功。
在收到SSD更新证实指令后，基站将SSD_A和SSD_B设置为从HLR/AC中收到的值（见EIA/TIA/IS-41）。
若当基站查询指令的确任被接收到，移动台却未能在T64m秒内接收到基站查询证实指令，移动台将放弃SSD_A_NEW和SSD_B_NEW。移动台然后将结束SSD更新过程。
SSD更新消息
图5.3.12.1.5-1 SSD更新消息流程
图5.3.12.1.5-2 共享保密数据(SSD)的计算
RAND－CHALLENGE ESN AUTH_DATA SSD_AUTH
RANDBS
32
ESN
32
IMSI_S1
24
SSD_A_NEW
64
↓
鉴权特征程序
↓AUTH SGNAURE
AUTHR
18
图5.3.12.1.5-3 AUTHBS的计算
5.3.12.2 信令消息加密
为了加强鉴权过程以及保护某些敏感的用户信息(如 PINs)，系统提供了一种可对所选f-dsch或r-dsch上业务信道信令消息的某些字段进行加密的方法。
如下是关于f-dsch(见5.3.12.2.1)和（见5.3.12.2.2）上消息的叙述，这些消息被使用蜂窝消息加密算法（见”公共加密算法”,C版，节2.5.1）或增强蜂窝消息加密算法（”公共加密算法”，C版，2.5.2）译成密码.加密算法信息的获得控制在美国专家管理规则。TIA扮演着提供这些信息的重要角色和服务商。
对于每个消息，被加密子段是确定的。消息按信道分配分成几个组。
若未完成鉴权(在接入参数消息中的AUTH字段等于“00”)，则不进行消息加密。请参见《公共加密算法技术规范书》中加密程序初始化和使用的细节。
信令消息加密分别受控于每个呼叫。移动台在表5.7.1.3.2.4-5中所示的始呼消息和寻呼响应消息中的ENCRYPTION_SUPPORTED字段确定其加密能力。呼叫的初始加密模式由信道指
附件4：数据交换接口规范 一、概述 计量器具检定数据交换接口采用Web service作为数据传输机制，是自包含、自描述（WSDL）、模块化的应用，由省局发布、定位、各技术机构通过web方式调用。接口基于标准的互联网协议，支持超文本传输协议(HTTP)和XML。与省局交换的数据都封装成XML格式的文件，传输前以GZIP格式将文件压缩，然后设置BASE64编码，最后在接收端将其解压，解析读取数据。 二、软件准备 JDK1.6，tomcat6.0，Web service相关包以及数据库。三、数据交换示意图 四、服务端接收数据过程 1、用户合法性校验：服务端在接收数据时同样需要进行用户合法性 校验，并返回信息。
2、数据封装：为方便数据传输和解析，客户端通过Web service交 换的数据需要封装成可扩展标记语言XML的规范，并严格按照此规范。 3、数据压缩：为提高数据的传输效率和减小传输的数据量，客户端 在传输之前需将数据以GZIP格式进行压缩，并设置BASE64位编码，以便基于HTTP传输。 4、对上传文件进行规范性校验：服务端在接收数据之前，校验客户 端数据是否按照XML规范要求，并按GZIP格式进行压缩，设置BASE64编码，否则返回不合法文件格式。 5、返回结果：服务端进行完校验，解析成功并反馈给业务系统后， 会反馈成功信息给客户端，如不成功则返回不成功。 五、客户端接收数据过程（与服务端接收过程类似。） 六、术语说明
THANKS !!! 致力为企业和个人提供合同协议，策划案计划书，学习课件等等 打造全网一站式需求 欢迎您的下载，资料仅供参考
国家标准《信息技术会计核算软件数据接口》（征求意见稿） 编制讲明 一、任务来源 国家标准化治理委员会2002年下达的国家标准项目打算中，列入了《信息技术会计核算软件数据》（编号为20020389—T—424 ）；2004年国家标准化治理委员会又下达《关于调整信息技术会计核算软件数据国家标准打算项目的复函》（标委办函[2004]6号），明确由中华人民共和国审计署、中华人民共和国财政部作为主管部门，组织《信息技术会计核算软件数据》的起草单位和相关单位，承担《信息技术会计核算软件数据接口》国家标准的制定。 二、要紧工作过程 2002年3月上海市技术监督局制定了《信息技术会计核算软件数据接口规范》，并作为地点标准。2002年依照国家标准项目打算中编号为20020398—T—424的国家标准打算项目《信息技术会计核算软件数据》，上海市技术监督局组织相关单位和专家进行该标准的起草工作，于2003年底提出了《信息技术会计核
算软件数据接口规范》国家标准草案文本。 审计署依照工作需要，自1999年以来开展了“会计核算软件数据接口”方面的研究和实践。经国家电子政务治理委员会、国务院信息化工作办公室批准，审计署于2002年2月开始组织研究编写《会计核算软件数据接口》国家标准，于2003年底提出标准草案文本。 2004年2月，依照国家标准化治理委员会“标委办函[2004]6号”—“关于调整《信息技术会计核算软件数据》国家标准打算项目的复函”的精神，审计署计算中心召集上海《信息技术会计核算软件数据》标准起草组成员，审计署南京特派员办事处、南京审计学院等相关专家与人员，在北京对上述两个标准草案文本进行了深入细致的分析研究，综合整理提出了《信息技术会计核算软件数据接口规范（企业、事业单位）（草案稿）》。 2004年3月，依照国家标准化治理委员会关于“要符合国家标准撰写格式及语言规范；要使用数据元素表示；会计核算软件数据输出文件要有文本和XML格式”的要求，组织审计署计算技术中心、财政部会计司、审计署南京特派员办事处、信息产业部电子标准化所、用友公司、金算盘公司、浪潮公司等相关人员共同研究，编制出《信息技术会计核算软件数据接口（征求意见
系统接口规范以及常见的接口技术概述 一、基本要求： 为了保证系统的完整性和健壮性，系统接口应满足下列基本要求： 1.接口应实现对外部系统的接入提供企业级的支持，在系统的高并发和大容量 的基础上提供安全可靠的接入； 2.提供完善的信息安全机制，以实现对信息的全面保护，保证系统的正常运行， 应防止大量访问，以及大量占用资源的情况发生，保证系统的健壮性； 3.提供有效的系统的可监控机制，使得接口的运行情况可监控，便于及时发现 错误及排除故障； 4.保证在充分利用系统资源的前提下，实现系统平滑的移植和扩展，同时在系 统并发增加时提供系统资源的动态扩展，以保证系统的稳定性； 5.在进行扩容、新业务扩展时，应能提供快速、方便和准确的实现方式。 二、接口通讯方式： 接口基本采用了同步请求/应答方式、异步请求/应答方式、会话方式、广播通知方式、事件订阅方式、可靠消息传输方式、文件传输等通讯方式： 1.同步请求/应答方式：客户端向服务器端发送服务请求，客户端阻塞等待服 务器端返回处理结果； 2.异步请求/应答方式：客户端向服务器端发送服务请求，与同步方式不同的 是，在此方式下，服务器端处理请求时，客户端继续运行；当服务器端处理结束时返回处理结果； 3.会话方式：客户端与服务器端建立连接后，可以多次发送或接收数据，同时 存储信息的上下文关系； 4.广播通知方式：由服务器端主动向客户端以单个或批量方式发出未经客户端 请求的广播或通知消息，客户端可在适当的时候检查是否收到消息并定义收到消息后所采取的动作；
5.事件订阅方式：客户端可事先向服务器端订阅自定义的事件，当这些事件发 生时，服务器端通知客户端事件发生，客户端可采取相应处理。事件订阅方式使客户端拥有了个性化的事件触发功能，极大方便了客户端及时响应所订阅的事件； 6.文件传输：客户端和服务器端通过文件的方式来传输消息，并采取相应处理； 7.可靠消息传输：在接口通讯中，基于消息的传输处理方式，除了可采用以上 几种通讯方式外，还可采用可靠消息传输方式，即通过存储队列方式，客户端和服务器端来传输消息，采取相应处理。 三、接口安全要求： 为了保证系统的安全运行，各种接口方式都应该保证其接入的安全性。 接口的安全是系统安全的一个重要组成部分。保证接口的自身安全，通过接口实现技术上的安全控制，做到对安全事件的“可知、可控、可预测”，是实现系统安全的一个重要基础。 根据接口连接特点与业务特色，制定专门的安全技术实施策略，保证接口的数据传输和数据处理的安全性。 系统应在接入点的网络边界实施接口安全控制。 接口的安全控制在逻辑上包括：安全评估、访问控制、入侵检测、口令认证、安全审计、防恶意代码、加密等内容。 四、传输控制要求： 传输控制利用高速数据通道技术实现把前端的大数据量并发请求分发到后端，从而保证应用系统在大量客户端同时请求服务时，能够保持快速、稳定的工作状态。 系统应采用传输控制手段降低接口网络负担，提高接口吞吐能力，保证系统的整体处理能力。具体手段包括负载均衡、伸缩性与动态配置管理、网络调度等功能：
呼叫信令详解（前后台） 呼叫流程信令图 起呼过程分四个阶段：RRC连接建立，直传信令连接建立，RAB建立，震铃接通建立RRC连接 直传信令连接建立（含鉴权和加密）
RAB建立过程
振铃，接通 RRC建立过程 （1）UE 在取得下行同步后，向NodeB发送SYNC_UL，接收到NodeB 回应的FPACH 信息后，在RACH 信道上向RNC 发送RRC Connection Request 消息，发起RRC 连接建立过程。 （2）RNC 准备建立RRC 连接，分配建立RRC 连接所需要的资源，并发送一条Radio Link Setup Request 消息给NodeB。 （3）NodeB 配置物理信道，在新的物理信道上准备接收UE 消息，并给RNC 发送一条
Radio Link Setup Response 响应消息。 （4）RNC 通过ALCAP 协议，建立Iub 数据传输承载。Iub 数据传输承载通过AAL2 的绑定标识与DCH 绑定在一起。建立Iub 数据传输承载需要NodeB 确认。 （5）（6）通过Downlink Synchronisation 和Uplink Synchronisation. 控制帧，NodeB 与RNC 为Iub 数据传输承载建立同步，此后NodeB 开始DL 发送。（7）RNC 在FACH 信道上发送RRC Connection Setup 消息给UE。 （8）UE 在DCCH 上发送RRC Connection Setup Complete 消息给RNC，RRC 连接建立完成 建立初始直传/上下行直传 （9）UE 在DCCH 上给RNC 发送一条Initial Direct Transfer（CM Service Request）消息，该消息包括了UE 请求的业务类型等信息，例如12.2K语音业务。 （10）RNC 发起初始到CN 的信令连接，并发送一条Initial UE Message 消息给CN，通知CN 关于UE 请求的业务等内容。 通过初始直接传输过程后，可使用该信令连接传输UE 和CN 之间的NAS 消息。 （11）CN 发送RANAP 消息Direct Transfer （Authentication Request）到RNC，要求对UE 进行鉴权。 （12）RNC 发送RRC Downlink Direct Transfer（Authentication Request）消息给UE。NAS 消息由UTRAN 透明的传输到UE （13）UE 发送RRC Uplink Direct Transfer Message（Authentication Response）消息给RNC，告知网络侧UE 已经按照鉴权要求完成了鉴权。 （14）RNC 发送RANAP 消息Direct Transfer 给CN，将UE 的NAS消息转发给CN。NAS 消息被透明的传输到UTRAN。 安全模式控制 （15）CN 发送RANAP 消息Security Mode Command 给RNC，要求终端进行安全模式控制。 （16）RNC 在下行DCCH 上发送RRC Security Mode Command 给UE，开始/重启加密过程。 （17）UE 成功应用新的加密方式后，在上行DCCH 上发送RRC SecurityMode Complete 给RNC （18）RNC 发送RANAP 消息Security Mode Complete 给CN，双方完成安全模式控制。建立RAB （19）（20）（21）（22）上行和下行的直接传输过程，NAS 要求传输数据， UE 向网络侧说明Bearer Capability 以及Called Number 等内容。 （22）CN 向RNC 发送RANAP 消息Common ID，告知RNC 该UE 的IMSI。 （23）CN 向RNC 发送RANAP 消息Radio Access Bearer Assignment Request ，发起RAB
监管报表数据报送接口规范修订历史纪录
一、销售机构、基金资金划付明细文件格式建议（J01） （一）报表格式 使用标准txt文件，文件内容格式如下(左侧数字表示行号)： 1.总记录数（不包括本行） 2.交易确认日期(YYYYMMDD)|交易申请日期(YYYYMMDD)|基金代 码|业务类型编码|销售机构向基金划付金额|基金向销售机构划付金额|登记结算机构代码| 3.交易确认日期(YYYYMMDD)|交易申请日期(YYYYMMDD)|基金代 码|业务类型编码|销售机构向基金划付金额|基金向销售机构划付金额|登记结算机构代码| （二）报表说明 用于表示基金销售机构与基金之间的实际资金划付。其中资金划付日期是指实际资金汇划的日期；交易确认日期是与指该笔资金划付相对应的基金交易的确认日期；交易申请日期是与指该笔资金划付相对应的基金交易的申报日期；业务类型是指基金交易业务代码，包括：认购（一次交易确认为120、二次交易确认为130）、申购122、定额申购139、赎回124、定额赎回163、强制赎回142、分红143。 对于三种特殊业务类型“交易申请日期”字段的说明。分红143业务：“交易申请日期”填写权益登记日；强制赎回142业务：“交易申请日期”填写交易确认日期的上一工作日（由于上工作日的赎回可能会和当日的强赎合并划款）；认购退款130业务：“交易申请日期”填写交易确认日期。 报送的实际资金划付数据是按照基金代码、业务类型进行
汇总的，即对于某个具体的资金划付日期，针对一只基金的某种业务类型，只申报一条汇总数据记录。 对于一种业务类型而言，只存在销售机构向基金划付金额或者只存在基金向销售机构划付金额。 基金代码---目前为6位编码，最长可扩展至30位。 业务类型---目前为3位编码，最长可扩展至30位。 登记结算机构代码--目前为8位编码，最长可扩展至30位。 （三）核对逻辑 中国结算每日将基金确认成功的交易数据按照基金代码、销售机构代码、业务类型进行汇总统计，得出销售机构各业务对基金应划入金额和应划出金额，用于与J01报表中的实际划付金额数据进行核对。中国结算汇总统计基金划入和基金划出金额的方法是：对认购业务，第一次确认（业务类型120）时统计的基金应收金额为：汇总每笔交易的确认金额全额；第二次确认（业务类型130）时统计的基金应付金额为：汇总每笔交易的（一次确认金额-二次确认金额+退回给投资人的利息）。 对申购（业务类型122）和定额申购（业务类型139）业务，统计的基金应收金额为：汇总每笔交易的（确认金额全额-代理费）。 对赎回（业务类型124）、定额赎回（业务类型163）、强制赎回（业务类型142）业务，统计的基金应付金额为：汇总每笔交易的（投资人实得金额+代理费）。 对分红（业务类型143）业务，统计的基金应付金额为：汇总每笔交易的（投资人实得现金红利金额）。
层三信令掉话分析 1.前言 作为一名网优工程师, 需要牢牢掌握一个完整呼叫的信令流程. 我们做GSM优化, 主要是对Um口要把握的更深些. 尤其是Layer3信令－也就是我们平常做路测的工程师说的层3信令。关于层3信令，可以参考GSM规范04.08. 对层3信令的准确理解,可以帮助我们快速分析和定位网络问题. 2. 理论部分 2.1一次完整的主叫流程（含切换） IDLE： DL: SYSTEM INFORMA TION TYPE 1：包括小区信道描述和RACH控制参数 DL: SYSTEM INFORMA TION TYPE 2（2bis，2ter）：邻小区BCCH频点描述，RACH 控制信道，允许的PLMN（扩展邻小区BCCH频点描述+RACH控制信道；扩展邻小区BCCH 频点描述2） DL: SYSTEM INFORMA TION TYPE 3：CI，LAI，控制信道描述，小区选择，小区选择参数，RACH控制参数 DL: SYSTEM INFORMA TION TYPE 4：LAI，小区选择参数，RACH控制参数，CBCH 信道描述，CBCH移动配置 DL: SYSTEM INFORMA TION TYPE 7：小区重选参数 DL: SYSTEM INFORMA TION TYPE 8：小区重选参数 UL: Channel request DL: Immediate assignment（SDCCH） 试呼： UL:CM service request（如果后面直接收到System Information Type1，则视为起呼失败DL: CM service Request DL: CM service accept DL: AUTHENTICA TION REQUEST UL: AUTHENTICA TION RESPONSE DL: CIPHER MODE COMMAND UL: CIPHER MODE COMPLETE DL: TMSI REALLOCA TION COMMAND UL: TMSI REALLOCA TION COMPLETE UL: SETUP DL: CALL PROCEEDING DL: ASSIGNMENT COMMAND UL: ASSIGNMENT COMPLETE （TCH） DL: ALERTING 成功起呼： DL: CONNECT（呼叫成功的标志,） UL: CONNECT ACKNOWLEDGE DL: SYSTEM INFORMA TION TYPE 5（5bis，5ter）：邻近小区BCCH频点描述（扩展邻近小区BCCH频点描述） DL: SYSTEM INFORMA TION TYPE 6：CI，LAI，小区参数设置
中国财务软件数据接口标准(DOC7) 编者按:标准应该是衡量事务的准则。标准的制定一样都由国际/国家有关标准机构或行业主管部门完成。但一些行业的生产厂商为了爱护用户的投资,促进行业有序进展,也按照本行业的特点,联合起来制定了一些大伙儿认可并共同遵守的规范,这种做法在国外已被广泛采纳。随着中国改革开放的深入,国内一些行业的厂家也开始进行这方面的探究,本期我们刊登的《中国财务软件数据接口标准》确实是由该财务软件行业的民间组织——中国软件行业协会财务及企业治理软件分会制定的,起草者为闻名财务软件厂商深圳金蝶公司。 一、背景 目前,国内财务软件众多,它们采纳的数据库平台和数据库结构各不相同,不同财务软件之间的数据交换,因为数据库平台和结构不同而产生许多困难,几乎任意两个不同软件之间要实现数据传递都会存在专门的数据转换咨询题。烦琐的数据转换工作白费了大量人力和物力,同时也阻碍了财务软件产业的健康进展。国内财务软件的商业化差不多比较成熟,各财务软件公司都有一批用户。由于各种缘故,一些用户期望从一个软件交叉升级为另一软件。由于用户在旧软件上已做了大量的工作,必定期望升级后原有数据能移植到新的软件中,然而有些软件的数据文件通过加密或数据库结构未公布,要从中直截了当读取数据几乎不可能。为了爱护用户已付出的劳动,各财务软件需要提供一个标准的数据输入输出接口。如此,建立一个公用的数据交换标准是专门必要的。 用户在使用财务软件时,有一些需求通过财务软件本身是难以实现的,如:用户期望把会计报表通过电子表格软件处理输出为各种专门形式;另一些高级用户,则期望在其它治理软件中能取到财务数据。这些数据交换工作都需要有一个标准的数据接口来规范。财务会计通过长期的进展已形成一定的理论,财务会计工作也有规范可循,国内财务软件是在这些理论和规范的基础上开发出来的,各软件储存财务数据的模式也大同小异。财务数据要紧按会计科目、凭证、余额及发生额、报表几个部分分块储备,它们之间既
税控发票开票软件发票信息 数据接口规范V4.0 1概述 为进一步优化纳税服务，满足纳税人内部管理信息系统与增值税发票税控开票软件的衔接需要，国家税务总局下发了税控发票开票软件发票信息数据接口规范V1.0、V2.0、V3.0版。随着增值税发票管理新系统的全国推广和营改增的全面实施，公布的接口已经不能满足需要，现对该接口进行更新升级，形成V4.0版。 本接口规范适用于是增值税发票税控开票软件（金税盘版）与增值税发票税控开票软件（税控盘版）的商品编码版本（以下统一简称为税控发票开票软件），配合手工导入开具、自动导入开具和发票明细导出功能使用。 2接口说明 2.1待开发票信息导入接口 通过税控发票开票软件中的手工导入开具和自动导入开具功能，将待开发票的信息批量导入到税控发票开票软件，完成发票开具。 选择手工导入开具时，首先选择要导入的XML文件，再对导入发票信息逐张开具并打印发票。
选择自动导入开具时，首先设置文件存储路径和轮询时间。自动导入开具功能开启后，系统自动轮询指定路径下的XML文件，自动完成发票开具，并将开具结果写入指定文件目录。 2.2已开发票信息导出接口 通过税控发票开票软件中的发票明细导出功能，实现已开发票信息的批量导出，生成EXCEL文件或XML文件。 3接口定义 本接口规范内容包括待开发票信息导入接口和已开发票信息导出接口，发票类型为增值税专用发票、增值税普通发票、货物运输业增值税专用发票、机动车销售统一发票和二手车销售统一发票。3.1增值税专用发票和增值税普通发票 3.1.1修改说明 单据新增了Version节点，增加商品编码功能后的版本为2.0； 单据新增了Spbmbbh节点，增加商品编码功能后为税局下载的商品编码表版本号； 单据新增了Hsbz节点，用于区分营改增新增的5%不含税税率和中外合作油气田（原海洋石油）5%税率、1.5%税率、差额税； 单据商品明细中新增了Spbm（商品编码）、Qyspbm（企业商品编码）、Syyhzcbz（享受优惠政策）、Lslbz（零税率标识）、Yhzcsm
中国结算开放式基金新版系统管理人数据接口规范(TXT) 版本1.1 二○○九年九月
1. 总则 (4) 2. 术语定义 (4) 3. 基本要求 (8) 4. 数据接口 (10) 4.1. 信息格式 (10) 4.2. 接口文件名定义 (11) 4.3. TA支持业务 (13) 4.4. 业务数据项 (15) 4.4.1. 开户确认业务101 (16) 4.4.2. 销户确认业务102 (20) 4.4.3. 客户资料修改确认业务103 (21) 4.4.4. 撤销交易账号确认109 (25) 4.4.5. 变更交易帐户确认158 (27) 4.4.6. 认购业务数据项020 (27) 4.4.7. 认购结果业务数据项057 (29) 4.4.8. 申购业务数据项022 (31) 4.4.9. 定期定额申购业务数据项039 (34) 4.4.10. ETF一次申购业务数据项091 (37) 4.4.11. ETF二次申购业务数据项092 (39) 4.4.12. 赎回业务数据项024/定期定额赎回业务数据项063 (42) 4.4.13. ETF一次赎回业务数据项093 (46) 4.4.14. ETF二次赎回业务数据项094 (48) 4.4.15. 预约赎回业务数据项025 (51) 4.4.16. 撤预约单业务数据项053 (53) 4.4.17. 转托管业务数据项026/028 (55) 4.4.18. 转托管入业务数据项027 (56) 4.4.19. 设置分红方式业务数据项029 (58) 4.4.20. 基金转换业务数据项036 (59) 4.4.21. 份额冻结业务数据项031 (62) 4.4.22. 份额解冻业务数据项032 (64) 4.4.23. 非交易过户业务数据项033 (65) 4.4.24. 强增业务数据项044 (67) 4.4.25. 强减业务数据项045 (68) 4.4.26. 开通定期定额协议业务数据项059 (70) 4.4.27. 撤销定期定额协议业务数据项060 (71) 4.4.28. 变更定期定额协议业务数据项061 (72) 4.4.29. 认购业务数据项120 (74) 4.4.30. 认购结果业务数据项130 (75) 4.4.31. 申购业务数据项122 (78) 4.4.32. 定期定额申购业务数据项139 (81) 4.4.33. ETF一次申购业务数据项191 (83) 4.4.34. ETF二次申购业务数据项192 (85) 4.4.35. 赎回业务数据项124/定时定额赎回163 (88) 4.4.36. 强制赎回业务数据项142 (91)
1 具体需求 功能需求 功能需求1 对于每一类功能或者有时对于每一个功能，需要具体描述其输入、加工和输出的需求。由四个部分组成： a．引言 描述的是功能要达到的目标、所彩的方法和技术，还应清楚说明功能意图的由来 和背景。 b．输入 1)详细描述该功能的所有输入数据，如：输入源、数量、度量单位、时间设定、 有效输入范围（包括精度和公差）； 2)操作员控制细节的需求。其中有名字、操作员活动的描述、控制台或操作员的 位置。例如：当打印检查时，要求操作员进行格式调整； 3)指明引用接口说明或接口控制文件的参考资料。 c．加工 定义输入数据、中间参数，以获得预期输出结果的全部操作。它包括如下的说明： 1)输入数据的有效性检查； 2)操作的顺序，包括事件的时间设定； 3)响应，例如，溢出、通信故障、错误处理等； 4)受操作影响的参数； 5)降级运行的要求； 6)用于把系统输入变换成相应输出的任何方法（方程式、数学算法、逻辑操作等）； 7)输出数据的有效性检查。 d．输出 1)详细描述该功能所有输出数据，例如：输出目的地、数量、度量单位、时间关
系、有效输出的范围（包括精度和公差）、非法值的处理、出错信息； 2)有关接口说明或接口控制文件的参考资料。 此外，对着重于输入输出行为的系统来说，需求说明应指定所有有意义的输入、 输出对及其序列。当一个系统要求记忆它的状态时，需要这个序列，使得它可以 根据本次输入和以前的状态作出响应。也就是说，这种情况犹如有限状态机。 功能需求2 ．．．．．． 功能需求n 外部接口需求 用户接口 提供用户使用软件产品时的接口需求。例如，如果系统的用户通过显示终端进行操作，就必须指定如下要求： a．对屏幕格式的要求； b．报表或菜单的页面打印格式和内容； c．输入输出的相对时间； d．程序功能键的可用性。 硬件接口 要指出软件产品和系统硬部件之间每一个接口的逻辑特点。还可能包括如下事宜：支撑什么样的设备，如何支撑这些设备，有何约定。
接口标准规范 目录 接口标准规范 (1) 第1章概述 (3) 第2章基本要求 (4) 2.1信息通讯安全 (4) 2.1.1 安全评估 (4) 2.1.2 访问控制 (4) 2.1.3 防恶意代码 (4) 2.1.4 加密 (5) 2.2支持高并发 (6) 2.3可监控 (6) 2.3.1 日志全覆盖 (6) 2.4系统资源的动态扩展 (6) 2.5异常处理机制 (7) 2.6业务扩展 (7) 第3章接口通讯方式 (7) 3.1同步请求/应答方式 (7) 3.2异步请求/应答方式 (7) 3.3会话方式 (7) 3.4广播通知方式 (7) 3.5事件订阅方式 (7)
3.7可靠消息传输 (8) 第4章传输控制要求 (8) 4.1负载均衡 (8) 4.2伸缩性与动态配置管理 (8) 4.3网络调度 (9) 4.4充分理由 (9) 4.5单一职责 (9) 4.6高内聚低耦合 (9) 4.7状态及消息 (10) 4.8控制数据量 (10) 4.9禁止随意拓展参数 (10) 第5章接口技术 (10) 第6章接口规范 (11) 6.1域名规范 (11) 6.1.1 http接口 (11) 6.1.2 webservice接口 (11) 6.2 API路径规范 (11) 6.2.1 http接口 (11) 6.2.2 webservice接口 (11) 6.3版本控制规范 (12) 6.3.1 http接口 (12) 6.3.2 webservice接口 (12) 6.4 API命名规范 (12) 6.4.1 新增方法 (13) 6.4.2 删除方法 (13) 6.4.3 修改方法 (13) 6.4.4 获取方法 (13) 6.4.5 获取列表方法 (13)
层三信令“Disconnect”原因值解析
原因值表1 下面是具体解释： ISUP消息中rel原因值 G3.1正常类别 原因NO.1：未分配的（未确定的）号码 "unassigned (unallocaled) number" 该原因表示不能到达主叫用户所请求的终点，因为虽然号码格式有效，但该号码目前尚未分配（未确定）。 原因NO.2：无路由到达规定的转换网络（国内使用） "no route to specified transit network(nationaluse)" unallocaled(unassigned) number 该原因表示发送该原因的设备已经收到一个通过特定未被识别的转接网络迂回呼叫的请求。发送该原因的设备不能识别该转接网络是因为该转接网络不存在或当它存在时并没有未该设备提供服务。 是否支持该原因由网络决定。 原因NO.3无路由到达终点 "no route to destination" 该原因表示不能到达被叫用户，因为呼叫所经过的网络不为所希望的终点提供服务。 是否支持该原因由网络决定。 原因NO.4发送特殊的信息音 "send special information tone" 该原因表示不能达到被叫用户的原因在于应向主叫用户返回特殊信息音。 原因NO.5转接前缀拨号错误（国内使用）
"misdialled trunk prefix(national use)" 该原因表示被叫方号码的转接前缀错误内含。 原因NO.6：不可接受的通路 "chnnel unacceptable" 该原因表示发送实体在呼叫中不接受使用最新标识的通路。 原因NO.7：呼叫已给出并正在已建立的通路上递交 "call awarded and being delivered in an established channel" 该原因表示已给予用户来呼叫，并表示这一来呼叫在已建立的通路上与类似的呼叫一起正在被连接到该用户。 原因NO.8：先占 "preemption" 该原因表示呼叫正在被预先占有。 原因NO.9：先占电路留作重新使用 "preemption-circuit reserved for reuse" 该原因表示呼叫正在被预先占有，电路留作先点交换的重新使用。 原因NO.16：正常的呼叫清除 "normal call clearing" 该原因表示呼叫正在被清除，这是因为呼叫所涉及的用户之一已经请求清除呼叫。 在正常情况下，网络不发送这一原因。 原因NO.17：用户忙 "user busy" 当被叫用户指示不能接受另一个呼叫时使用这一原因。 原因NO.18：无用户响应 "no user responding" 当被叫用户在规定的时间周期内不用提醒或连接指示响应呼叫建立消息时使用这一原因。原因NO.19：无用户应答（用户已提醒） "no answer from user(user alerted)" 当用户在规定的时间周期内提供提醒指示但未提供连接指示时使用这一原因。 注－该原因不一定由Q.931程序产生，而可能由内部网络定时器产生。 原因NO.20：用户缺席 "subscriber absent" 该原因用作移动应用，本规范暂不使用。 原因NO.21：呼叫拒绝 "call rejected" 该原因表示发送这一原因的设备不希望接收呼叫，虽然它可以接受呼叫，因为发送该原因的设备既不忙，也兼容。 该原因可以由网络产生，表示由于补充业务的限制而清除了呼叫。诊断字段可能包含有关补充业务的附加信息和拒绝原因。 原因NO.22：号码变更 "number changed" 当主叫用户所指示的被叫用户号码不再被分配时，该原因被返回到主叫用户。新的被叫用户号码可以作为任选项目包含在诊断字段中。如果网络不支持这种能力，将使用原因NO.1未分配的（未确定）的号码。 原因NO.26：清除未选择的用户
1 前言 《企业信用信息基础数据库数据接口规》（简称“数据接口规”）规定了企业信用信息基础数据库与外部系统进行信息交换时应遵循的有关信息格式和数据管理规定，本文档分为六部分。 前言简介本规各部分的容。 报文规规定了本规中报文的基本概念、设计原则、数据处理原则、文件命名原则、报文文件的结构和种类。 数据采集要求规定了公积金管理中心提交数据的围、频率以及文件传送方式。 公积金信息采集报文和公积金信息删除报文中规定了公积金中心向企业信用信息基础数据库报送采集报文和删除报文的具体数据项以及对数据项的描述和约束。 公积金信息反馈报文规定了企业信用信息基础数据库向公积金中心反馈容的具体数据项以及对数据项的描述和约束。 附录包含公积金信息采集接口规的代码表、数据校验规则。 本接口规适用于与企业信用信息基础数据库进行报文交换的公积金机构及公积金部门的数据处理。文档的主要读者有：拟建系统用户、系统设计人员、系统编码人员、项目经理、系统测试人员、项目监理人员。 2 报文规 2.1术语和定义 下列术语和定义适用于本规。 2.1.1报文 由报文头、报文体构成的，按照一定规则组合起来的数据集合体。 2.1.2报文文件 包含报文的数据文件。 本规中报文文件与报文是一对一的关系。 2.1.3段 一个已标识、命名和结构化的、在功能上相互关联的复合数据元和/或独立数据元的集合。段有各自固定的长度。 本规中段为基础段。 2.1.4信息记录 数据采集的基本信息单位，包含报送机构一笔业务的有关数据。 本规中的信息记录由基础段组成。 2.1.5报文头 每个报文必须包含且只包含一个报文头，报文头表示一次数据采集的开始，该部分给出本次采集数据的信息提要。 2.1.6报文体 报文体是数据采集报文的主体容，报文体部分可包含一种或多种不同类型的信息记录，最后一条信息记录结束即为报文结束。 信息记录之间用一个回车换行符（“﹨r﹨n”或“﹨n”）分隔。 2.1.7信息记录 此信息记录由基础段组成。 每个信息记录包含且仅包含一个基础段。 信息记录的容中不允许存在回车换行符（“﹨r﹨n”或“﹨n”）。 2.1.8基础段 基础段是由固定数据项按照一定次序排列组成的信息集合体。 2.2设计原则
Ps64上传 SM Deactivate PDP Context Request SM cause Cause value: (36) Regular deactivation 2：原因NO.27：终点故障"destination out of order" 该原因表示不能到达用户所指示的收端，因为收端的接口工作不正常。术语"工作不正常"表示信令消息不能递交到远端用户；例如，远端用户的物理层或数据层故障，用户设备脱机等。
22 Number changed(号码改变) 26 Non selected user clearing(清除未选择的用户) 27 Destination out of order(终点故障) 28 Incomplete number(无效号码格式（不完全的号码）) 29 Facility rejected(设施被拒绝) 30 Response to status enquiry(对状态询问的响应) 31 Normal,unspecified(正常，未规定) 34 No circuit/channel available(无电路/信道可用) 38 Network out of order(网络故障) 41 Temporary failure(临时故障) 42 Switching equipment congestion(交换设备拥塞) 43 Access information discarded(接入信息被丢弃) 44 Requested circuit/channel not available(请求的电路/信道不可用) 47 Resources unavailable,unspecified(资源不可用，未规定) 49 Quality of service unavailable(服务质量不可用) 50 Requested facility not subscribed(未预订所请求的设施) 55 Incoming calls barred within the CUG 57 Bearer capability not authorized(承载能力未认可) 58 Bearer capability not presently available(承载能力目前不可用) 63 Service or option not available,unspecified(无适用的业务或任选项目，未规定) 65 Bearer service not implemented(承载业务不能实现) 68 ACM equal to or greater than ACMmax 69 Requested facility not implemented(所请求的设施不能实现) 70 Only restricted digital information bearer(仅能获得受限数字信息承载能力) 79 Service or option not implemented(业务不能实现，未规定) 81 Invalid transaction identrfier value(无效处理识别码) 87 User not member of CUG 88 Incompatible destination(非兼容目的地址) 91 Invalid mandatory information(无效过渡网选择)
附件2 武汉市节能智慧管理系统 数据接口规范 武汉市发展和改革委员会 2013年12月
前言 为指导我市各级节能智慧管理系统建设，市发改委组织有关专家，以我国现行相关标准为依据，结合我市节能智慧管理系统建设、验收和运行管理要求，研究制定了本数据接口规范。 本规范包括主要用能单位上传数据接口标准规范和市区各级系统上传数据接口标准规范两部分，其中两部分包括了接口的标准应用范围、接口的实现、接口的要求、术语和定义和基本原则。 本规范由市发改委负责管理和解释。
目录 1. 主要用能单位上传数据接口规范 (5) 1.1标准应用范围 (5) 1.2术语和定义 (5) 1.3基本原则 (5) 1.4接口实现 (6) 1.4.1数据提供方 (6) 1.4.2数据接收方 (6) 1.4.3接口的实现方式 (7) 1.4.4传输方式 (7) 1.4.5传输协议 (7) 1.4.6传输过程 (7) 1.4.7编码原则 (8) 1.4.8接口的验证方式 (8) 1.4.9使用策略 (9) 1.5接口数据的要求及保障 (9) 2. 区分系统上传数据接口规范 (10) 2.1标准应用范围 (10) 2.2术语和定义 (10) 2.3基本原则 (10) 2.4接口实现 (11)
2.4.1数据提供方 (11) 2.4.2数据接收方 (12) 2.4.3接口的实现方式 (12) 2.4.4传输方式 (12) 2.4.5传输协议 (12) 2.4.6传输过程 (12) 2.4.7编码原则 (13) 2.4.8接口的验证方式 (13) 2.4.9使用策略 (14) 2.5接口数据的要求及保障 (14) 附录1 数据采集器身份认证过程和数据加密 (15) 附录2 数据采集器或子系统和市数据中心通信过程 (16) 附录3 数据传输的XML数据格式 (17)
1 Unassigned （unallocated）number（未指定【未分配】号码） 3 No route to destination （无目的地路由）6 Channel unacceptable （不接受的信道） 8 Operator determined barring（运营商确定阻塞） 16 Normal call clearing （正常呼叫清除） 17 User busy （用户忙） 18 No user responding（无用户响应） 19 User alerting, no answer（用户振铃，无应答） 21 Call rejected（呼叫被拒绝） 22 Number changed（号码改变） 25 Pre-emption（预占） 26 Non selected user clearing（非选定用户清除） 27 Destination out of order（目的地混乱） 28 Invalid number format （incomplete number）（无效号码格式【数字不完全】） 29 Facility rejected （设备被拒绝） 30 Response to STATUS ENQUIRY（对STATUS ENQUIRY作出响应） 31 Normal, unspecified （not logged）（正常，未指定【未记录】） 34 No circuit/channel available （无可用电路/ 信道） 38 Network out of order （网络故障） 41 Temporary failure （临时故障） 42 Switching equipment congestion（交换设备拥塞） 43 Access information discarded （访问信息丢弃） 44 Requested circuit/channel available（请求电路/ 信道不可用） 47 Resources unavailable, unspecified （资源不可用，未指定） 49 Quality of service unavailable（服务质量不可用） 50 Requested facility not subscribed（请求设备未预订） 55 Incoming calls barred within the CUG（CUG内的来电阻断） 57 Bearer capability not authorized（承载容量未批准） 58 Bearer capability not presently available（承载容量当前不可用） 63 Service or option not available, unspecified（服务或选择不可用，未指定）65 Bearer service not implemented（承载服务未实施） 68 ACM equal to or greater than ACMmax （ACM等同或大于ACMmax） 69 Requested facility not implemented（请求设备未实施） 70 Only restricted digital information bearer capability isavailable （只有有限的数字信息承载容量） 79 Service or option not available, unspecified（服务或选择不可用，未指定）81 Invalid transaction identifier value（无效交易标识符值） 87 User not member of CUG（用户非CUG成员） 88 Incompatible destination （不兼容的目的地） 91 Invalid transit network selection（无效转接网选择） 95 Semantically incorrect message（语义错误消息） 96 Invalid mandatory information（无效强制信息） 97 Message type non-existent or not implemented（消息类型不存在或未实施） 98 Message type not compatible with the protocol state（消息类型与协议状态