CDMA网优网测规范 Ver10 -信令专题05(业务配置协商).docx

一． 业务/业务选择协商
1． 协商机制
在业务信道工作过程中，移动台和基站通过交换前反向业务信道帧进行通信。而业务信道帧有很多的构成格式，对应地有不同的解码方式，因此移动台和基站需要用一套公共的属性来定义一致业务信道帧“建立”和“解释”方式。这套属性，被称为“业务配置(Service Configuration)”。
业务配置（Service Configuration）包含以下内容：
1) 复用选择（Multiplex Option）：Rate1 / Rate2 ；
2) 传输速率（Transmission Rate）：full / half / quarter / eighth ；
3) 业务选择连接（Service Option Connection），它又包含以下三个内容：
ü 业务选择（Service Option）：voice / markov等，详见“相关参数”；
ü 业务类型（Traffic Type）：primary traffic / secondary traffic ；
ü 业务选择连接参考（Service Option Connection Reference）：用来标识“业务选择连接”；
其中有可能一个“业务配置”会没有“业务选择连接”，例如移动台和基站之间只传送信令业务或者无业务信道数据时就可以没有“业务选择连接”；也有可能一个“业务配置”有多个“业务选择连接”，因此需要“业务选择连接参考”来标识每个“业务选择连接”。
我们把双方通过“对话”，共同决定前方向业务信道的“业务配置（Service Configuration）”的过程称为“协商（Negotiation）”。通常有两种协商方式：“业务协商（Service Negotiation）”和“业务选择协商（Service Option Negotiation）”。两者的主要区别是“协商”的“范围”不同：“业务协商”的协商范围大；而“业务选择协商”的协商范围小。在“业务选择协商”中，基站与移动台仅共同规定要使用的“Service Option”，无法规定Multiplex Option”、“Transmission Rate”、“Traffic Type”等业务配置属性（不过它也有“Service Option Connection”的概念）。那些具体协商的属性都采用与“Service Option”相配的缺省的配置。特别是：（1）“Multiplex Option”和“Transmission Rate”假设为与“Service Option”相配的缺省的“Multiplex Option”和“Transmission Rate”。（2）“Traffic Type”假设为“primary traffic”。而在“业务协商”中可以由基站和移动台共同确定所有的业务配置属性。
“业务选择协商”的可选择性比“业务协商”的小，这就是两者的主要区别，“业务选择协商”通常用于较低级的话音服务。如果申请的“Service Option”是“Basic Variable Rate Voice Service”，将会采用“Service Option Negotiation”；如果申请的“Service Option”是“Extended Variable Rate Voice Service”，将会采用“Service Negotiation”。现在的普通话音服务一般都是“Enhanced Variable Rate Voice Service”，所以一般都是采用“Service Negotiation”。
在已经分配业务信道之后、完成协商之前，移动台和基站都只按与“Service Option”相配的缺省的业务配置来处理前反向业务信道，例如仅按缺省的primary traffic形式处理。

2． 与“业务协商/业务选择协商”相关的信令消息
（1） 同时支持“业务协商”和“业务选择协商”的消息
u Origination Message （Access Channel）
相关字段：
SPECIAL_SERIVCE：特殊业务选择指示。如果为1，移动台将把下面的SERVICE_OTPION字段置为《TSB-58对于TIA/EIA宽带扩频标准参数值的支配管理》中对应的请求业务选择中给出的值。特殊业务选择实际就是“Service Option”不为1的业务选择。
SERVICE_OPTION：业务选择。具体参见“相关参数”。如果SPECIAL_SERVICE 为0，SERVICE_OPTION字段将被忽略，Service Option被默认为“Service Option 1”。
功能描述：
移动台通过该消息的“Service Option字段”在始呼时发起 Service Option请求，并请求与Service Option相关联的缺省的业务配置。
u General Page Message （Paging Channel）
相关字段：
SPECIAL_SERIVCE：特殊业务选择指示。如果为1，移动台将把下面的SERVICE_OTPION字段置为《TSB-58对于TIA/EIA宽带扩频标准参数值的支配管理》中对应的请求业务选择中给出的值。
SERVICE_OPTION：业务选择。具体参见“相关参数”。如果SPECIAL_SERVICE 为0，SERVICE_OPTION字段将被忽略。
功能描述：
基站通过该消息的“Service Option字段”在寻呼移动台时发起 Service Option请求，并请求与Service Option相关联的缺省的业务配置。

u Page Response Message （Access Channel）
相关字段：
SERVICE_OPTION：业务选择。具体参见“相关参数”。
功能描述：
移动台通过该消息的“Service Option字段”在响应寻呼时发起 Service Option请求，并请求与Service Option相关联的缺省的业务配置。

u Channel Assignment Message （Paging Channel）
相关字段：
ASSIGN_MODE：信道分配模式：指出所分配信道的类型。详见“相关参数”。
如果ASSIGN_MODE 为4，还有下列相关字段：
DEFAULT_CONFIG：缺省配置。如果为0，规定前反向业务信道都采用Multiplex Option 1和 Rate Set 1；如果为1，规定前反向业务信道都采用Multiplex Opton2和Rate Set 2；如果为2，规定前向业务信道采用Multiplex Option 1和Rate Set 1，反向业务信道采用Multiplex Option 2 和Rate Set 2；如果为3，规定前向业务信道采用Multiplex Option 2 和Rate Set 2，反向业务信道采用Multiplex Option 1和Rate Set 1。
GRANTED_MODE授予模式。规定了在业务协商完成前对业务信道的缺省的处理方式。如果GRANTED_MODE 为“00”，表示在业务协商完成前对业务信道采用DEFAULT_CONFIG规定处理方式，并且业务协商在基站发送第一个“Service Connect Message”前开始；如果GRANTED_MODE为“01”，表示在业务协商完成前对业务信道采用与“Origination Message”或“Page Response Message”提出的“Service Option”相配的缺省的业务配置规定的处理方式，并且业务协商在基站发送第一个“Service Connect Message”前开始；如果GRANTED_MODE为“10”，表示在业务协商完成前对业务信道采用与“Origination Message”或“Page Response Message”提出的“Service Option”相配的缺省的业务配置规定的处理方式，但是业务协商不能在基站发送第一个“Service Connect Message”前开始；
功能描述：
“ASSIGN_MODE”决定分配的信道类型，实际间接地决定了采用“Service Negotiation”还是“Service Option Negotiation”。例如：如果服务基站分配“业务信道”，并对应采用“Service Option Negotiation”；如果服务基站其分配“扩展业务信道”，并对应采用“Service Negotiation”。
u Extended Channel Assignment Message （Paging Channel）
相关内容同“Channel Assignment Message”。
u Extended Handoff Direction Message （Forward Traffic Channel）
相关字段：
SERV_NEG：协商指示。如果为1，采用“业务协商”；如果为0，采用“业务选择协商”。
功能描述：
在“硬切换”的情况下该字段才有意义。如果硬切换发生，同时需要重新进行业务配置协商，SERV_NEG用于规定新的协商的方式。
u General Handoff Direction Message （Forward Traffic Channel）
相关内容同“Extended Handoff Direction Message”。

（2） 仅支持“业务协商”的消息
u Service Request Message（Forward/ Reverse Traffic Channel）
相关字段：
SERV_REQ_SEQ：业务请求序列号
REQ_PURPOSE：请求目的。如果为1，表示同意对方的业务配置建议请求）；如果为2，表示拒绝对方的建议，同时自己没有新的建议；如果为3，表示自己提出业务配置建议（请求）。
RECORD_TYPE：记录类型。此处应为“Service Configuration”。
RECORD_LEN：记录长度。
Type-specific fields：类型特定字段。记录类型为“Service Configuration”是，为如下字段：
FOR_MUX_OPTION：前向业务信道多路复用选择。如果为1，表示选择Rate1；如果为2，表示选择Rate2。
REV_MUX_OPTION：反向业务信道多路复用选择。如果为1，表示选择Rate1；如果为2，表示选择Rate2。
FOR_RATES：前向业务信道传输速率。可以是复用选择对应的速率集或者其子集。详见“相关参数”。
REV_RATES：反向向业务信道传输速率。可以是复用选择对应的速率集或者其子集。详见“相关参数”。
NUM_CON_REC：业务选择连接个数。如果为0，下面的字段将被忽略。
（下面的字段将出现NUM_CON_REC次）
RECORD_LEN：业务选择连接记录长度。
CON_REF：业务选择连接参考。
SERVICE_OPTION：业务选择。
FOR_TRAFFIC：前向业务信道业务类型。详见“相关参数”。
REV_TRAFFIC：反向业务信道业务类型。详见“相关参数
功能描述：
前反向业务信道均有此消息；双方都有权提出“业务配置”请求。
u Service Response Message（Forward/Reverse Traffic Channel）
相关字段：
同“Service Request Message”的相关字段。
功能描述：
前反向业务信道均有此消息：双方都能够响应对方的业务配置请求，表示“同意”、“拒绝”或者“另有建议”。它的功能与“Service Request Message”的功能是有很大重重叠的，因为“Service Request Message”不单是提出请求，它也可以用于表示同意或拒绝对方提出的请求；而“Service Response Message”也不单是同意或拒绝对方提出的请求，它也可以提出自己的请求。
u Service Connect Message（Forward Traffic Channel）
相关字段：
USE_TIME：使用动作时间指示。如果为1，使用ACTION_TIME规定的动作时间；如果为0，使用缺省的动作时间。
ACTION_TIME：动作时间。即规定移动台设置“业务配置”的动作时间。
SERV_CON_SEQ：业务连接序列号。
RECORD_TYPE：记录类型。此处应为“Service Configuration”。
RECORDLEN：记录长度。
Type-specific fields：类型特定字段。相关字段同“Service Request Message”的相关字段。
功能描述：
该消息在“业务协商”中是必不可少的。如果基站最终同意了由移动台提出的业务配置（不管该业务配置是最初由移动台用“Service Request Message”提出的，还有用“Service Response Message”提出的），业务协商的主要过程完成，基站将发送此消息，设置移动台进行业务配置设置的时间。
u Service Connect Completion Message（Reverse Traffic Channel）
相关字段：
SERV_CON_REQ：业务配置序列号。
功能描述：
该消息在“业务协商”过程中也是必不可少的。如果移动台收到“Service Connect Message”，并同意其中的业务配置，移动台将在基站规定的动作时间内进入“设置业务配置”状态。完成设置后，发送“Service Connect Completion Message”通知基站；如果不同意，它将发“Mobile Station Reject Order ”作为响应。可见“业务协商”的最终决定方在“移动台”。因为基站所支持的“业务配置”通常要比移动台多，移动台与基站共同协商的业务配置受限于“移动台”。
u Service Option Control Message（Forward / Reverse Traffic Channel）
相关字段：
CON_REF：业务选择连接参考。
SERVICE_OPTION：业务选择。
CTL_REC_LEN：控制记录长度。
Type-specific fields：类型特定字段。
功能描述：
因为一个“Service Configuration”可能有多个“Service Option Connect”，所以可用该消息来调用其中的某一个“Service Option Connect”。

（3） 仅支持“业务选择协商”的消息
u Service Option Request Order （Forward/ Reverse Traffic Channel）
相关字段：
ORDQ：指令鉴定码。
SERVICE_OPTION：业务选择。
功能描述：
基站或者移动台提出业务选择请求
u Service Option Response Order（Forward/Reverse Traffic Channel）
相关字段：
ORDQ：指令鉴定码。
SERVICE_OPTION：业务选择。
功能描述：
基站或者移动台响应对方的业务选择请求。如果该消息中的SERVICE_OPTION与对方建议的业务选择相同，表示它同意对方的建议；如果与对方建议的不同并且不为空，表示它拒绝对方的建议，但是自己有新的建议；如果为空，表示它拒绝对方的建议，自已也没有新的建议。
u Service Option Control Order（Foward/Reverse Traffic Channel）
功能描述：
因为一个“Service Configuration”可能有多个“Serivce Option Connect”，所以可用该指令来调用其中的某一个“Serivce Option Connect”）

3． 关于“协商”的流程
在“业务协商”中，“Service Request Message”、“Service Response Message”和“Service Connect Message”这些消息的功能比不像它们的名称表示的那样单一，每个消息都能够提出建议、同意对方建议或者拒绝对方建议，因此在实际的协商过程中，并不是简单地用“Service Response Message”响应“Service Request Message”，用“Service Connect Completion Message ”响应“Service Connect Message”，可能会出现“Service Request Message”响应“Service Connect”等情况。因此一个很复杂业务配置的协商流程可能会很杂乱，但是我们从网测的角度，因为业务配置的协商仅仅是呼叫建立一个小的子程序，所以并不太需要关心协商的具体过程细节，我们通常只需要关心协商的结果。因此我们在此不对每一个具体可能出现的情况进行讨论。而且尽管IS-95B标准中设置的相关信令非常的完备，考虑的情况非常的细致复杂，但是对于普通的话音业务和一些基本的数据业务（这些业务普通的移动台和基站都可以很好的支持），通常由移动台在Origination或Page Response的时候和基站Paging的时候请求一个Service Option，并同时请求一个与Service Option相关联的Service Configuration。然后，在业务信道操作阶段，如有必要再协商一个新的业务配置，而这种情况通常不出现，因此通常的流程如下：
Ø 移动台通过发“Origination Message”发起始呼并提出Service Option要求（或者基站通过发“General Page Message”发起呼叫并提出Service Option要求，然后移动台通过发“Page Response Message”响应寻呼并且同意基站提出的Service Option要求）
Ø 基站根据双方谈妥的Service Option，决定使用“业务协商”还是“业务选择协商”，并通过“Channel Assignment Message”或“Extended Channel Assignment Message”为移动台分配响应的业务信道。
Ø 如果采用“业务协商”，接下来的流程如下：
ü 基站发“Service Connect Message”
ü 移动台发“Service Connect Completion Message”
ü 开始通话
Ø 如果采用“业务选择协商”，接下来的流程如下：
ü 基站发“Service Option Response Order”
ü 移动台发确认消息（有可能是专门的“Mobile Station Acknowledgement Order”或者其他后续的可以附带“确认标记”的消息）
ü 开始通话

4． 相关参数
1) Service Option

Service Option Number
Type of Service
1
Basic Variable Rate Voice Service (8Kbps)
2
Mobile Station Loopback (8 Kbps)
3
Enhanced Variable Rate Voice Service (8Kbps)
4
Asynchronous Data Service
5
Group 3 Facismile
6
Short Message Services
7
Packet Data Service :Internet or ISO Protocol Stack
8
Packet Data Service : CDPD Protocol Stack
9
Mobile Station Loopback (13Kbps)
10
STU_III Service Option
11 ~ 32767
Reserved for standard service options
32768 ~ 65535
Reserved for proprietary service options
2) ASSIGN_MODE:

ASSIGN_MODE
描述
1
业务信道分配
2
寻呼信道分配
3
捕获模拟系统
4
模拟话音信道分配
5
扩展业务信道分配
6
扩展寻呼信道分配
其他
保留

3) Rate1的前向业务信道传输速率

子字段
长度
子字段描述
RS1_9600_FOR
1
前向业务信道速率集合1，9600kbps
RS1_4800_FOR
1
前向业务信道速率集合1，4800kbps
RS1_2400_FOR
1
前向业务信道速率集合1，2400kbps
RS1_1200_FOR
1
前向业务信道速率集合1，1200kbps
RESERVED
4

4) Rate2的前向业务信道传输速率

子字段
长度
子字段描述
RS2_14400_FOR
1
前向业务信道速率集合2，14400kbps
RS2_7200_FOR
1
前向业务信道速率集合2，7200kbps
RS2_3600_FOR
1
前向业务信道速率集合2，3600kbps
RS2_1800_FOR
1
前向业务信道速率集合2，1800kbps
RESERVED
4

5) Rate1的反向向业务信道传输速率

子字段
长度
子字段描述
RS1_9600_VER
1

反向业务信道速率集合1，9600kbps
RS1_4800_VER
1
反向业务信道速率集合1，4800kbps
RS1_2400_VER
1
反向业务信道速率集合1，2400kbps
RS1_1200_VER
1
反向业务信道速率集合1，1200kbps
RESERVED
4

6) Rate2的反向业务信道传输速率

子字段
长度
子字段描述
RS2_14400_VER
1
反向业务信道速率集合2，14400kbps
RS2_7200_VER
1
反向业务信道速率集合2，7200kbps
RS2_3600_VER
1
反向业务信道速率集合2，3600kbps
RS2_1800_VER
1
反向业务信道速率集合2，1800kbps
RESERVED
4

7) FOR_TRAFFIC编码

FOR_TRAFFIC
描述
0000
业务选择连接不使用前向业务信道的业务量
0001
业务选择连接使用前向业务信道的primary traffic
0010
业务选择连接使用前向业务信道的secondary traffic
其他
reserve

8) REV_TRAFFIC编码

REV_TRAFFIC
描述
0000
业务选择连接不使用反向业务信道的业务量
0001
业务选择连接使用反向业务信道的primary traffic
0010
业务选择连接使用反向业务信道的secondary traffic
其他
reserve