专利名称：通过业务信道下发短信时的语音呼叫优先实现方法
技术领域：
本发明涉及码分多址技术领域，尤其涉及一种通过业务信道下发短信时的语音呼叫优先实现方法。
背景技术：
在码分多址(Code Division Multiple Access，简称CDMA)系统中，移动交换中心 (Mobile Switching Center，简称MSC)可以根据短信长度设置通过控制信道还是通过业务信道向用户下发短信。为了避免由于突发的短信业务造成控制信道的拥塞，同时提升短信成功率，电信运营商通常只将超短的短信设置为通过控制信道下发，其他短信通过业务信道下发，甚至将所有短信都设置为通过业务信道下发。
现有的MSC通过业务信道下发短信的信令流程参见图1，MSC接收到短信中心短信下发消息后，向基站子系统(Base Station Subsystem，简称BSS)下发短信寻呼指令，BSS 再向移动终端(Mobile Station，简称MS)转发该短信寻呼指令；MSC收到MS对短信寻呼的响应后进入业务信道建立过程；业务信道建立后通过业务信道下发短信；短信下发完成后拆除业务信道。
当用户终端关机时，由于用户短信无法送达，短信中心则将缓存该用户短信。该用户终端开机时，MSC将向短信中心通知用户的开机状态，短信中心会将缓存的短信通过MSC 下发至用户。当缓存的短信为多条并且通过业务信道进行下发时，MSC可以建立一次业务信道，在业务信道中连续下发多条短信，也可以为每一条短信建立一次业务信道逐条下发。 当缓存短信条数较多时，短信连发时一次短信下发持续时间比较长。逐条下发时虽然一次下发时间不长，但是由于会重复图1所示流程多次，总的下发时间也比较长。
在MS已经发送短信寻呼响应后检测到语音始呼请求，MS将丢弃始呼请求；在MS 尚未发送短信寻呼响应之前检测到语音始呼请求，MS将始呼请求发至BSS，BSS此时已经为相同用户分配了通信控制模块，BSS将拒绝始呼请求，因此，在短信下发的整个过程，用户都将无法发起语音呼叫。
在短信下发持续期间，如果该用户有语音终呼请求，用户归属位置寄存器(Home Location Register，简称HLR)将向用户服务MSC/拜访位置寄存器(Visitor Location Register，简称 VLR)发送移动应用部分(Mobile Application Part，简称MAP)消息LOCREQ 要求MSC分配临时本地电话号码(Temporary Local Directory Number，简称TLDN)接续该被叫用户，具体信令交互流程参见图4，MSC将判断该用户处于忙的状态而拒绝用户终呼请求，用户也就无法作为语音被叫；或者已经为用户分配了 TLDN，但是接收到入局呼叫时用户还处于短信接收状态，用户的终呼请求也无法处理。这就将造成用户在一定的时间内无法使用语音始呼或终呼业务，引起极大的不便，同时可能造成用户的误解，带来用户对网络状况的投诉。
发明内容
5 本发明的目的是提出一种通过业务信道下发短信时的语音呼叫优先实现方法，能够解决通过业务信道下发短信持续期间用户无法使用语音呼叫的问题。
为实现上述目的，本发明提供了一种通过业务信道下发短信时语音始呼优先实现方法，包括 移动台检测到语音始呼请求时，对所述移动台当前所处的状态进行判断； 当确定所述移动台处于空闲状态或寻呼响应子状态时，所述移动台将该语音始呼请求发送到基站子系统； 所述基站子系统向所述移动台发送语音始呼请求确认，并向移动交换中心发送语音始呼请求； 所述移动交换中心判断是否下发短信寻呼请求，是则挂起短信处理进程，并缓存待发的短信，然后进行标准语音始呼流程处理，并在建立的语音业务信道中下发缓存的短信；否则进行标准语音始呼流程处理。
为实现上述目的，本发明提供了一种通过业务信道下发短信时语音终呼优先实现方法，包括 移动交换中心接收用户归属位置寄存器发送的位置请求消息LOCREQ时，检查用户是否处于通过业务信道下发短信的状态； 如果所述用户处于通过业务信道下发短信的状态，则所述移动交换中心为所述用户分配临时本地号码，并将所述临时本地号码通过位置请求消息的回应消息Iocreq回送到所述用户归属位置寄存器； 当所述移动交换中心接收到被叫为该临时本地号码的入局呼叫请求时，判断是否处于短信下发过程，是则判断当前处于短信下发过程的阶段，并根据当前所处阶段执行相应的终呼优先过程，否则进行标准语音终呼流程处理。
基于上述技术方案，本发明基于对语音请求发生在短信下发的不同状态与阶段的判断，通过在不同设备上的处理方式实现语音优先的功能，保证了实时性要求更强的语音业务的优先接续，实现了短信、语音两种不同服务种类的分优先级别处理；克服了目前语音与短信业务冲突的问题，同时保证了用户短信业务的正常使用，解决了通过业务信道下发短信持续期间用户无法使用语音呼叫的问题，尤其是由于用户长时间无法接收短信而恢复正常短信接收状态后短信中心大量下发短信造成用户较长时间内无法使用语音呼叫的问题。
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中 图1为现有MSC通过业务信道下发短信的信令流程以及MS所处状态的示意图。
图2为本发明通过业务信道下发短信时语音始呼优先实现方法的一实施例的流程示意图。
图3为本发明通过业务信道下发短信时语音始呼优先实现方法的另一实施例的流程示意图。
图4为现有通过业务信道下发短信过程中MSC所处阶段示意图。
图5为本发明通过业务信道下发短信时语音终呼优先实现方法的一实施例的流程示意图。
图6为本发明通过业务信道下发短信时语音终呼优先实现方法的另一实施例的流程示意图。
具体实施例方式下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。
如图2所示，为本发明通过业务信道下发短信时语音始呼优先实现方法的一实施例的流程示意图。在本实施例中，语音始呼优先实现方法包括 步骤101、MS检测到语音始呼请求时，对所述MS当前所处的状态进行判断； 步骤102、当确定所述MS处于空闲状态或寻呼响应子状态时，所述MS将该语音始呼请求发送到BSS ； 步骤103、所述BSS向所述MS发送语音始呼请求确认，并向MSC发送语音始呼请求； 步骤104、所述MSC判断是否下发短信寻呼请求，是则执行步骤105，否则执行步骤 106 ； 步骤105、所述MSC挂起短信处理进程，并缓存待发的短信，然后进行标准语音始呼流程处理，并在建立的语音业务信道中下发缓存的短信； 步骤106、进行标准语音始呼流程处理。
在本实施例中，空闲状态和寻呼响应子状态的判断可由图1中所示的状态进行确认，具体来说，当MS检测在其发出释放响应命令(Release Order)之后，且根据接收到的从 BSS发出的寻呼消息(Page Message)返回寻呼响应消息(Page Response Message)之前， 则确认当前状态为空闲状态；当MS检测到其返回寻呼响应消息，且未接收到BSS发出的扩展信道指定消息(Extended Channel Assignment)，则确认当前状态为寻呼响应子状态。
MS在上述两种状态下接收到语音始呼请求时，并不丢弃语音始呼请求，而是继续向BSS发出语音始呼请求，并且不对BSS发出的寻呼消息(Page Message)返回寻呼响应消息(Page Response Message)，当该语音始呼请求被发送到MSC时，MSC则需要判断是否已下发了短信寻呼请求，如果已经下发，此时MSC可以将当前待发的短信先缓存在本地，并挂起短信处理进程，优先执行标准的语音始呼流程处理，在建立了语音业务信道后，利用该语音业务信道下发之前缓存在本地的短信。这样不仅使得语音始呼得到优先处理，而且也不会影响到短信业务的正常使用。
之所以利用MSC缓存待发短信，也是考虑到如果采用短信中心缓存短信，则需要 MSC向短信中心发送失败响应，造成短信成功率下降，同时短信中心在接收到失败响应后仍然会继续下发短信，造成频繁下发失败，而MSC缓存待发短信，不仅可以避免短信成功率下降的问题，而且还可以利用后续建立的语音业务信道下发短信，不会影响短信的下发流程。
在MS将该语音始呼请求发送到BSS之后，BSS也不再简单的拒绝该语音始呼请求， 而是对自身是否接收到MSC下发的短信寻呼请求进行判断，如果已经接收，则丢弃短信处理进程，向MS发送语音始呼请求确认；否则直接向MS发送语音始呼请求确认。在这之后， 继续向MSC发送语音始呼请求。
在下一个实施例中，除了给出MS在空闲状态或寻呼响应子状态下的处理，还提供了 MS处于业务信道控制子状态下的处理过程，业务信道控制子状态的确定仍可参考图1所示，如果MS接收到BSS发出的扩展信道指定消息(Extended Channel Assignment)后，且未根据BSS发出的释放命令(Release Order)返回相应的释放响应命令，则确认当前状态为业务信道控制子状态。
当确定MS处于业务信道控制子状态时，MS缓存该语音始呼请求，并执行短信业务信道拆除流程，在短信业务信道拆除流程完成后，MS再将缓存的语音始呼请求发送给BSS， BSS向MSC发送语音始呼请求，MSC进行标准语音始呼请求流程处理。
在所述移动台缓存所述语音始呼请求之前，还可以对MS是否收到网络侧的业务信道拆除指令进行判断，以便根据具体情况选择适合的业务信道拆除方式。其中当确定MS 已收到网络侧的业务信道拆除指令时，由于此时拆除过程即将完成，则MS缓存该语音始呼请求，并等待短信业务信道拆除流程完成后，将缓存的所述语音始呼请求发送给BSS，BSS 向MSC发送语音始呼请求，MSC再进行标准语音始呼请求流程处理。
当确定MS未收到网络侧的业务信道拆除指令时，则移动台缓存该语音始呼请求， 并主动向BSS发起业务信道拆除信令；BSS和MSC执行业务信道拆除流程，由于此时短信并未发送完毕，MSC将缓存待发的短信，MS则等待短信业务信道拆除流程完成后，将缓存的语音始呼请求发送给BSS ；BSS向MSC发送语音始呼请求，接下来MSC进行标准语音始呼请求流程处理，当建立了语音业务信道后，则利用建立的语音业务信道中下发其缓存的短信。
为了避免MSC在短信业务信道拆除过程中向用户下发短信终呼请求，可以在MS向 BSS发起业务信道拆除信令时，在业务信道拆除信令中携带表示拆除原因为语音优先的值 (举例H’41，表示语音优先)。在MSC执行业务信道拆除流程时，可以根据接收到的该表示拆除原因为语音优先的值设置定时器，并在定时器超时之前不向MS发出短信终呼请求。在定时器未超时之前，所有接收到的下发短信均由MSC在本地缓存而不下发，直到建立语音业务信道后再下发缓存的短信。
下面通过一个更为具体的实施例来对本发明进行说明，如图3所示，为本发明通过业务信道下发短信时语音始呼优先实现方法的另一实施例的流程示意图。整体流程包括 步骤200、MS检测到语音始呼请求； 步骤201、MS对自身当前所处的状态进行判断，如果确定自身处于空闲状态或寻呼响应子状态，则执行步骤202，如果确定自身处于业务信道控制子状态，则执行步骤210 ； 步骤202、MS将该语音始呼请求发送到BSS ； 步骤203、BSS判断是否接收到MSC下发的短信寻呼请求，是则执行步骤204，否则执行步骤205 ； 步骤204、BSS丢弃短信处理进程； 步骤205、BSS向MS发送语音始呼请求确认，并向MSC发送语音始呼请求； 步骤206、MSC判断是否下发短信寻呼请求，是则执行步骤207，否则执行步骤 209 ； 步骤207、挂起短信处理进程，并缓存待发的短信，然后进行标准语音始呼流程处理；
8 步骤208、语音业务信道建立后，在语音业务信道中下发缓存的短信； 步骤209、进行标准语音始呼流程处理； 步骤210、MS判断自身是否收到网络侧的业务信道拆除指令，是则执行步骤211， 否则执行步骤214; 步骤211、MS缓存语音始呼请求，并执行短信业务信道拆除流程，在短信业务信道拆除流程完成后，将缓存的语音始呼请求发送给BSS ； 步骤212、BSS向MSC发送语音始呼请求； 步骤213、MSC进行标准语音始呼请求流程处理； 步骤214、MS缓存语音始呼请求，并向BSS发起业务信道拆除信令，在该信令中携带有表示拆除原因为语音优先的值； 步骤215、BSS执行业务信道拆除流程； 步骤216、MSC执行业务信道拆除流程，同时缓存待发的短信，并根据表示拆除原因为语音优先的值设置定时器，在定时器超时之前不向MS发出短信终呼请求； 步骤217、MS等待短信业务信道拆除流程完成后，将缓存的语音始呼请求发送给 BSS ； 步骤218、BSS向MSC发送语音始呼请求； 步骤219、MSC进行标准语音始呼请求流程处理； 步骤220、在建立语音业务信道后，MSC在建立的语音业务信道中下发缓存的短 在短信下发持续期间，用户也可能会有语音终呼的请求，当用户归属位置寄存器向用户服务MSC发送MAP消息L0CREQ，要求MSC分配TLDN接续被叫用户，或MSC接收到为该用户分配的TLDN的入局呼叫时，MSC则会判断该用户处于忙的状态而拒绝用户终呼请求，这就导致了短信下发持续期间语音终呼无法实现。本发明则通过MSC识别当前所处状态来执行语音终呼优先的流程，而不是简单的拒绝用户终呼请求。
下面通过一个实施例及附图进行说明。如图5所示，为本发明通过业务信道下发短信时语音终呼优先实现方法的一实施例的流程示意图。在本实施例中，语音终呼优先实现方法包括 步骤301、MSC接收用户HLR发送的位置请求消息LOCREQ时，检查用户是否处于通过业务信道下发短信的状态； 步骤302、如果所述用户处于通过业务信道下发短信的状态，则MSC为所述用户分配TLDN，并将TLDN通过位置请求消息的回应消息Iocreq回送到所述用户HLR ； 步骤303、所述MSC接收到被叫为该TLDN的入局呼叫请求； 步骤304、MSC判断是否处于短信下发过程，是则执行步骤306，否则执行步骤 305 ； 步骤305、进行标准语音终呼流程处理； 步骤306、判断当前处于短信下发过程的阶段，并根据当前所处阶段执行相应的终呼优先过程。
在本实施例中，MSC检查到用户正处于下发短信状态时，则为用户分配TLDN，并且通知HLR，当接收到被叫号码为TLDN的入局呼叫请求时，则判断当前是处于短信下发过程，如果是，则判断所处短信下发过程的哪个阶段，针对于不同阶段提供不同的语音终呼优先处理方式。
MSC判断当前所处短信下发过程的阶段可以参考如图4所示的划分方式，S卩如果 MSC已发出寻呼请求(Paging Request)，且未接收到寻呼响应(Paging Response)，则确定当前所处阶段为第一阶段；如果MSC已接收到寻呼响应，且未发出指配请求(Assignment Request)，则确定当前所处阶段为第二阶段；如果MSC已发出指配请求，且未接收到指配完成消息(Assignment Complete)，则确定当前所处阶段为第三阶段；如果MSC已接收到指配完成消息，且未发出应用数据传递业务传递消息(ADDS Deliver)，则确定当前所处阶段为第四阶段；如果MSC已发出应用数据传递业务传递消息，且未接收到应用数据传递业务传递确认消息(ADDS Deliver Ack)，则确定当前所处阶段为第五阶段；如果MSC已接收到应用数据传递业务传递确认消息，且未发出业务信道拆除命令(Clear Command)，则确定当前所处阶段为第六阶段；如果MSC已发出业务信道拆除命令，且未接收到业务信道拆除完成消息(Clear Complete)，则确定当前所处阶段为第七阶段。
针对于不同阶段，各网络设备的执行方式也存在差异，具体通过下一实施例进行说明。如图6所示，为本发明通过业务信道下发短信时语音终呼优先实现方法的另一实施例的流程示意图。在本实施例中，语音终呼优先实现方法包括 步骤400、MSC接收用户HLR发送的位置请求消息LOCREQ ； 步骤401、MSC检查用户是否处于通过业务信道下发短信的状态； 步骤402、如果用户处于通过业务信道下发短信的状态，则MSC为用户分配TLDN， 并将TLDN通过位置请求消息的回应消息Iocreq回送到用户HLR ； 步骤403、MSC接收到被叫为该TLDN的入局呼叫请求； 步骤404、MSC判断是否处于短信下发过程，是则执行步骤406，否则执行步骤 405 ； 步骤405、进行标准语音终呼流程处理； 步骤406、判断当前处于短信下发过程的阶段，并根据当前所处阶段执行相应的终呼优先过程，如果是第一阶段或第二阶段，则执行步骤410，如果是第三阶段，则执行步骤420，如果是第四阶段，则执行步骤430，如果是第五阶段，则执行步骤440，如果是第六阶段，则执行步骤450，如果是第七阶段，则执行步骤460 ； 步骤410、MSC缓存待发短信，并向BSS下发语音寻呼请求； 步骤411、MSC进行标准语音终呼请求流程处理； 步骤412、在建立的语音业务信道中下发缓存的短信； 步骤420、MSC缓存待发短信，并等待BSS返回指配完成消息； 步骤421、当MSC接收到指配完成消息时，向BSS下发业务信道拆除命令； 步骤422、当MSC接收到业务信道拆除完成消息时，向BSS下发语音寻呼请求； 步骤423、MSC进行标准语音终呼请求流程处理； 步骤424、在建立的语音业务信道中下发缓存的短信； 步骤430、MSC缓存待发短信； 步骤431、向BSS下发业务信道拆除命令； 步骤432、当MSC接收到业务信道拆除完成消息时，向BSS下发语音寻呼请求； 步骤433、MSC进行标准语音终呼请求流程处理； 步骤434、在建立的语音业务信道中下发缓存的短信； 步骤440、MSC等待BSS返回应用数据传递业务传递确认消息； 步骤441、当接收到应用数据传递业务传递确认消息时，MSC向BSS下发业务信道拆除命令； 步骤442、当MSC接收到业务信道拆除完成消息时，向BSS下发语音寻呼请求； 步骤443、MSC进行标准语音终呼请求流程处理； 步骤450、MSC向BSS下发业务信道拆除命令； 步骤451、MSC接收到业务信道拆除完成消息时，向BSS下发语音寻呼请求； 步骤452、MSC进行标准语音终呼请求流程处理； 步骤460、MSC等待BSS返回的业务信道拆除完成消息； 步骤461、当接收到业务信道拆除完成消息时，MSC向BSS下发语音寻呼请求； 步骤462、MSC进行标准语音终呼请求流程处理。
最后需要说明的是，在本发明中涉及的标准语音始呼流程以及后续将提到的标准语音终呼流程均为CDMA系统中的标准流程，除了涉及MSC等设备之外，还涉及其他网元。例如，在描述上使用MSC进行标准语音始呼流程，或者CDMA系统进行标准语音始呼流程，或者直接称标准语音始呼流程均表达类似含义，具体流程可参考相关CDMA标准。
本领域普通技术人员可以理解实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括R0M、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应当说明的是以上实施例仅用以说明本发明的技术方案而非对其限制；尽管参照较佳实施例对本发明进行了详细的说明，所属领域的普通技术人员应当理解依然可以对本发明的具体实施方式
进行修改或者对部分技术特征进行等同替换；而不脱离本发明技术方案的精神，其均应涵盖在本发明请求保护的技术方案范围当中。
1权利要求
1.一种通过业务信道下发短信时语音始呼优先实现方法，包括移动台检测到语音始呼请求时，对所述移动台当前所处的状态进行判断； 当确定所述移动台处于空闲状态或寻呼响应子状态时，所述移动台将该语音始呼请求发送到基站子系统；所述基站子系统向所述移动台发送语音始呼请求确认，并向移动交换中心发送语音始呼请求；所述移动交换中心判断是否下发短信寻呼请求，是则挂起短信处理进程，并缓存待发的短信，然后进行标准语音始呼流程处理，并在建立的语音业务信道中下发缓存的短信；否则进行标准语音始呼流程处理。
2.根据权利要求1所述的方法，其中在所述移动台将该语音始呼请求发送到基站子系统之后，还包括所述基站子系统判断是否接收到移动交换中心下发的短信寻呼请求，是则丢弃短信处理进程，向所述移动台发送语音始呼请求确认；否则直接向所述移动台发送语音始呼请求确认。
3.根据权利要求1或2所述的方法，其中还包括当确定所述移动台处于业务信道控制子状态时，所述移动台缓存所述语音始呼请求， 并执行短信业务信道拆除流程；在所述短信业务信道拆除流程完成后，所述移动台将缓存的所述语音始呼请求发送给所述基站子系统；所述基站子系统向所述移动交换中心发送所述语音始呼请求； 所述移动交换中心进行标准语音始呼请求流程处理。
4.根据权利要求3所述的方法，其中在所述移动台缓存所述语音始呼请求之前，还包括判断所述移动台是否收到网络侧的业务信道拆除指令的步骤，当确定所述移动台已收到网络侧的业务信道拆除指令时，所述移动台缓存所述语音始呼请求，并等待所述短信业务信道拆除流程完成后，将缓存的所述语音始呼请求发送给所述基站子系统；所述基站子系统向所述移动交换中心发送所述语音始呼请求； 所述移动交换中心进行标准语音始呼请求流程处理；当确定所述移动台未收到网络侧的业务信道拆除指令时，所述移动台缓存所述语音始呼请求，并向所述基站子系统发起业务信道拆除信令；所述基站子系统和移动交换中心执行业务信道拆除流程，所述移动交换中心缓存待发的短信；所述移动台等待所述短信业务信道拆除流程完成后，将缓存的所述语音始呼请求发送给所述基站子系统；所述基站子系统向所述移动交换中心发送所述语音始呼请求； 所述移动交换中心进行标准语音始呼请求流程处理，并在建立的语音业务信道中下发缓存的短信。
5.根据权利要求4所述的方法，其中在所述移动台向所述基站子系统发起业务信道拆除信令时，在所述业务信道拆除信令中还携带有表示拆除原因为语音优先的值；在所述移动交换中心执行业务信道拆除流程时，还根据所述表示拆除原因为语音优先的值设置定时器，在所述定时器超时之前不向所述移动台发出短信终呼请求。
6.一种通过业务信道下发短信时语音终呼优先实现方法，包括移动交换中心接收用户归属位置寄存器发送的位置请求消息LOCREQ时，检查用户是否处于通过业务信道下发短信的状态；如果所述用户处于通过业务信道下发短信的状态，则所述移动交换中心为所述用户分配临时本地号码，并将所述临时本地号码通过位置请求消息的回应消息Iocreq回送到所述用户归属位置寄存器；当所述移动交换中心接收到被叫为该临时本地号码的入局呼叫请求时，判断是否处于短信下发过程，是则判断当前处于短信下发过程的阶段，并根据当前所处阶段执行相应的终呼优先过程，否则进行标准语音终呼流程处理。
7.根据权利要求6所述的方法，其中判断当前处于短信下发过程的阶段的操作具体为如果所述移动交换中心已发出寻呼请求，且未接收到寻呼响应，则确定当前所处阶段为第一阶段；如果所述移动交换中心已接收到寻呼响应，且未发出指配请求，则确定当前所处阶段为第二阶段；如果所述移动交换中心已发出指配请求，且未接收到指配完成消息，则确定当前所处阶段为第三阶段；如果所述移动交换中心已接收到指配完成消息，且未发出应用数据传递业务传递消息，则确定当前所处阶段为第四阶段；如果所述移动交换中心已发出应用数据传递业务传递消息，且未接收到应用数据传递业务传递确认消息，则确定当前所处阶段为第五阶段；如果所述移动交换中心已接收到应用数据传递业务传递确认消息，且未发出业务信道拆除命令，则确定当前所处阶段为第六阶段；如果所述移动交换中心已发出业务信道拆除命令，且未接收到业务信道拆除完成消息，则确定当前所处阶段为第七阶段。
8.根据权利要求7所述的方法，其中所述根据当前所处阶段执行相应的终呼优先过程的操作具体包括如果当前所处阶段为第一阶段或第二阶段，则所述移动交换中心缓存待发短信，并向基站子系统下发语音寻呼请求；移动交换中心进行标准语音终呼请求流程处理，并在建立的语音业务信道中下发缓存的短信；如果当前所处阶段为第三阶段，则所述移动交换中心缓存待发短信，并等待所述基站子系统返回指配完成消息；当所述移动交换中心接收到所述指配完成消息时，向所述基站子系统下发业务信道拆除命令；当所述移动交换中心接收到业务信道拆除完成消息时，向所述基站子系统下发语音寻呼请求；所述移动交换中心进行标准语音终呼请求流程处理，并在建立的语音业务信道中下发缓存的短信；如果当前所处阶段为第四阶段，则所述移动交换中心缓存待发短信，并向所述基站子系统下发业务信道拆除命令；当所述移动交换中心接收到业务信道拆除完成消息时，向所述基站子系统下发语音寻呼请求；所述移动交换中心进行标准语音终呼请求流程处理，并在建立的语音业务信道中下发缓存的短信；如果当前所处阶段为第五阶段，则所述移动交换中心等待所述基站子系统返回应用数据传递业务传递确认消息；当接收到所述应用数据传递业务传递确认消息时，所述移动交换中心向所述基站子系统下发业务信道拆除命令；当所述移动交换中心接收到业务信道拆除完成消息时，向所述基站子系统下发语音寻呼请求；所述移动交换中心进行标准语音终呼请求流程处理；如果当前所处阶段为第六阶段，则所述移动交换中心向所述基站子系统下发业务信道拆除命令；当所述移动交换中心接收到业务信道拆除完成消息时，向所述基站子系统下发语音寻呼请求；所述移动交换中心进行标准语音终呼请求流程处理；如果当前所处阶段为第七阶段，则所述移动交换中心等待所述基站子系统返回的业务信道拆除完成消息；当接收到所述业务信道拆除完成消息时，所述移动交换中心向所述基站子系统下发语音寻呼请求；所述移动交换中心进行标准语音终呼请求流程处理。
全文摘要
本发明涉及一种通过业务信道下发短信时语音始呼优先实现方法，包括移动台检测到语音始呼请求时，对当前所处的状态进行判断；当确定处于空闲状态或寻呼响应子状态时，将该语音始呼请求发送到BSS；BSS返回语音始呼请求确认，并向MSC发送语音始呼请求；MSC判断是否下发短信寻呼请求，是则挂起短信处理进程，并缓存待发的短信，然后进行标准语音始呼流程处理，并在建立的语音业务信道中下发缓存的短信；否则进行标准语音始呼流程处理。本发明基于对语音请求发生在短信下发的不同状态与阶段的判断，通过在不同设备上的处理方式实现语音优先的功能，保证了实时性要求更强的语音业务的优先接续，实现了短信、语音两种不同服务种类的分优先级别处理。
文档编号H04W4/16GK102186153SQ20111013977
公开日2011年9月14日 申请日期2011年5月27日 优先权日2011年5月27日
发明者曹磊, 杨维忠, 李力卡, 马金兰 申请人:中国电信股份有限公司