智能外设的INAP和WIN协议.doc

智能外设的
INAP和WIN协议

12/13/2024 机密 目录 第 I 页

第1章 概述
INAP（Intelligent Network Application Protocol）是固网智能网使用的协议，由ITU-T标准化组织制定。而WIN（Wireless Intelligent Network）则应用于CDMA无线智能网系统，由ANSI标准化组织制定。因此，两套协议在网络承载上就使用的不同的协议标准，ITU-T和ANSI。
在INAP协议和WIN协议中都会使用智能外设（IP：Intelligent Peripheral）实现特殊资源功能，在使用IP时也会分别通过SSP和MSC来连接IP。但两套协议在使用IP时连接IP的方式和流程是不同的。
第2章 流程
2.1 INAP流程

图1
INAP协议中SCP连接IP的流程如图1所示，流程说明如下：
1. SSP发送由TC_Begin承载的IDP（InitialDP）操作触发SCP上的业务。
2. SCP业务出发后执行到需要连接IP时，向SSP发送ETC（EstablishTemporaryConnection）操作。ETC操作中带有3个非常重要的参数：AssistSSPIPRoutingAddress、scf_id和correlation_id。AssistSSPIPRoutingAddress是由SSP配置的路由到IP局向的字冠和附加字段组成的号码，作用是让SSP通过该号码将呼叫转接到IP上。scf_id为SCP的号码编码，IP通过scf_id和DPC（Destination Point code）的映射关系找到发送ARI（AssistRequestInstruction）操作时所需的SCP点码。correlation_id为SCP的自动机号，SCP在收到ARI操作后通过correlation_id关联到发送ETC操作的自动机上。
3. SSP在收到ETC操作后，将assist_SSP_IP_routing_address作为被叫号码向IP发送IAM消息，IAM消息中还带有scf_id和correlation_id参数。SSP同时将前段呼叫接续到IP上。
4. IP收到IAM消息后向SSP发送ACM消息。
5. IP向SSP发送ANM消息以保持并打通双向话路。
6. IP向SCP发送TC_Begin的ARI（AssistRequestInstruction）操作，ARI操作中包含IAM消息中的correlation_id参数，DPC由IAM消息中的scf_id映射获得。
7. SCP收到ARI操作后根据correlation_id参数关联到发送ETC操作的自动机，由原自动机控制发送PA（PlayAnnouncement）操作给IP。
8. IP执行完PA操作后发送SRR（SpecializedResourceReport）操作给SCP报告放音完成。
9. SCP收到SRR操作后得知放音完成，向SSP发送DFC（DisconnectForwardConnection）操作通知SSP切断与IP的连接。
10. SSP收到DFC操作后向IP发送REL消息，释放接续到IP的话路。
11. IP收到SSP的REL消息后释放话路，并向SSP返回RLC消息。
12. IP的呼叫释放后向SCP发送TC_End以结束对话。
22 WIN流程

图2
WIN协议中SCP连接IP的流程如图2所示，流程说明如下：
1. MSC发送由TC_Begin承载的ORREQ操作触发SCP上的业务。
2. SCP的业务执行到需要连接IP时，向IP发送由TC_Begin承载的SeizeResource操作。在SeizeResource操作中的PreferredLanguageIndicator参数将指定语言的类型。
3. IP收到SeizeResource操作后，根据分配的TLDN号段和处理本次呼叫自动机号生成TLDN号码，然后将TLDN号码通过SeizeResource的result返回给SCP。
4. SCP收到SeizeResource的result后，取出TLDN号码通过CONNRES操作发送给MSC，通知MSC连接IP。
5. MSC收到CONNRES操作后，根据里面的TLDN号码指示的局向找到IP，并将该TLDN号码作为被叫号码向IP发送IAM消息，同时将前段呼叫接续到IP。
6. IP收到IAM后向MSC发送ACM消息
7. IP向MSC发送ANM消息以保持并打通双向话路。
8. IP根据被叫号码判断出属于WIN协议的呼叫，根据TLDN号码后缀码找到对应的呼叫自动机。IP完成IAM消息与自动机的关联后向SCP发送InstructionRequest操作通知SCP呼叫接续完成等待SCP的进一步指示。
9. SCP收到InstructionRequest操作后得知MSC和IP直接的接续已经完成，此时向IP发送SRFDirective操作控制IP进行放音、收号等动作。
10. IP在完成放音、收号等动作后向SCP发送SRFDirective操作的result，返回操作执行结果。
11. SCP在使用完IP后向IP发送InstructionRequest操作的result，通知IP特殊资源使用完毕。
12. IP向SCP发送TC_End，结束IP和SCP之间的对话。
13. 同时IP想MSC发送REL消息释放IP和MSC之间的话路。
14. MSC完成释放后向IP返回RLC消息。
2.3 总结
从上面两段流程可以看出INAP协议和WIN协议在连接特殊资源的处理上是不同的。主要体现在以下几点：
1. INAP协议中SCP通过向SSP下发ETC操作连接IP，IP向SCP发送ARI来触发SCP上的特殊资源处理对话。而在WIN协议中SCP先向IP发送SeizeResource操作触发IP的特殊资源处理对话，再使用IP返回的TLDN向MSC发送CONNRES来连接IP。即从特殊资源的触发方向上来看两者相反。
2. INAP协议中SCP收到ARI操作后根据内部的correlation_id来关联原自动机，而在WIN协议中IP根据IAM消息的被叫用户号码参数的后缀部分来关联原自动机。即从由ISUP向INAP或WIN的转化过程中对原自动机的关联方式是不同的（INAP协议中由SCP完成关联，WIN协议由IP完成关联）。
3. 在INAP协议中，ETC中AssistSSPIPRoutingAddress参数帮助SSP找到并连接IP，scf_id参数帮助IP找到SCP并发起对话，correlation_id帮助SCP自身关联原自动机。而在WIN协议SCP连接IP的过程中有一个非常重要的参数，即IP在返回SeizeResource操作的result中的TLDN（在协议中定义的名称为DestinationDigits），这个TLDN号码贯串整个连接过程的始终，TLDN号码的前面号段部分帮助MSC找到并连接IP，而后面部分则帮助IP关联自身的原自动机。从功能上来看WIN协议中连接IP使用的TLDN号码相当于INAP协议中AssistSSPIPRoutingAddress参数和correlation_id参数的总和。
4. 在INAP协议中SCP控制IP实现特殊资源功能时有多种操作，PA（PlayAnnouncement）、PC（PromptAndCollectUserInformation）、PR（PromptAndRecordMessage）、UIScript等一系列操作各自实现不同的功能。而在WIN协议中特殊资源功能统一由SRFDirective操作来实现，具体实现什么样的功能则有该操作内部的参数来描述。
第3章 CIN-IP
CIN-IP目前对两种协议都做了支持，由于INAP和WIN是两种协议，在呼叫流程和参数的定义上都有所不同，因此CIN-IP也对这些差异进行适应。
3.1 呼叫处理
在CIN-IP的CN进程上使用两个业务逻辑分别处理INAP协议的呼叫和WIN协议的呼叫，INAP协议的处理逻辑为ipcontrol.slp.bin（servicekey=101），WIN协议的处理逻辑为wincontrol.slp.bin（servicekey=121）。INAP协议的处理逻辑ipcontrol.slp.bin被ISUPGateway上报的IAM消息触发，而WIN协议的处理逻辑则被SeizeResource（OperationID=2377）操作触发，因此还需要在sc里进行相应的配置。
INAP协议的呼叫在IP上的处理如图3所示：
图3
WIN协议的呼叫与INAP不同的是，CN在被SeizeResource触发后会向ISUPGateway发送seizeTLDN消息申请TLDN号码后缀的编码，ISUPGateway会将该后缀编码与CN的自动机好进行映射，当ISUPGateway收到IAM消息后再分析判断被叫号码后的后缀号码，并查找映射表找到CN对应处理该呼叫的自动机。因此ISUPGateway上新增seize.slp.bin（servicekey=10）的业务逻辑用来处理TLDN后缀号码的分配。同时ISUPGateway需要在config.isup中的#[CALL]配置项中增加对TLDN号段的配置，以便让ISUPGateway知道该呼叫是否属于WIN协议的呼叫，如下：
#[CALL]
#index key len scf correlation T7 T9 bci
0 13334820(DD) 4 0 0 0 0 FFFF
1334820为TLDN的号段，(DD)表示该号码为WIN协议处理用。CN上在构成TLDN号码时也需要通过读取xmlwoods的配置完成，CN使用的名为WIN的xmlwoods配置如下：

13334820
100

WIN协议的IP处理流程如下图4所示：

图4
3.2 语音处理
由于IP实现的是特殊资源功能（SRF：SpecializedResourceFunction），因此INAP协议和WIN协议在控制操作中会不可避免的涉及到语音编号的问题。
在INAP协议中语音编号被定义在InformationToSend结构中的MessageID参数中，INAP协议中的MessageID参数为4字节的整形，国内的《YD-T 1256-2003 智能网能力集1 (CS-1) 智能网应用规程 (INAP)补充规定》对MessageID做了如下定义：
字节4
字节3
字节2
字节1
业务标识
语言种类
录音通知编号
即MessageID的最高位字节定义了该语音号所属的业务键，第二高位字节定义了语音所属的语言种类（0：混合录音通知；1：中文；2：英文；3：本地话），最低两个字节位定义了业务中的录音通知编号。如：语音编号为16842753（0x01010001）的语音在INAP中的描述为servicekey为1的业务中编号为0001的中文语音。
WIN协议与INAP协议类似，每条语音也包含了三个要素：业务标识、语言种类和录音通知编号，与INAP不同的是WIN协议没有定义4字节的整形来包含这三部分。如我们前面流程说明中所提到的，WIN协议在SeizeResource操作中指定了语言种类（由PreferredLanguageIndicator参数指定，1：英语；2：法语；3：西班牙语；4：德语；5：葡萄牙语；6：中文GB13000），在SRFDirective操作中的AnnouncementList和AnnouncementList中的ServiceID则分别指定了录音通知编号和业务标识。
有上面的描述我们可以看出INAP协议和WIN协议在语音上存在两个差异：
l 语音ID的构造不一致
l 语言种类的定义不一致
CIN-IP分别对这两方面做了处理，首先在WIN协议处理中按照INAP协议的方式构造语音ID，即将WIN协议中的PreferredLanguageIndicator、ServiceID和AnnouncementList参数按照INAP中MessageID的结构构成语音ID。其次将WIN协议中的语言种类按照INAP协议的定义进行转换，即当发现PreferredLanguageIndicator参数值为6时按照INAP改为1，值为1时按照INAP改为2。
需要注意的是当CIN-IP采用EXCEL交换机作为平台时，EXCEL在播放可变音时采用chain方式，而使用chain方式播放的语音号必须小于0x100000。按照WIN协议转换过来的语音号一般都大于0x100000，因此首先需要在VN的初始化业务中使用initial mixvoice将大于0x100000的语音号转换成小于0x100000的语音号（实际语音文件的编号）（如：function(‘initial mixvoice 16842753 1000’)）。然后在EXCEL使用的NFS Server上共享目录中的voiceindex.dat文件中加入转换后的小语音号。东信等其它硬件平台无需做此类配置。

12/13/2024 正文 第 8 页