CN100442939C - 基于蜂窝网络的一键通业务呼叫建立时延的优化方法 - Google Patents
基于蜂窝网络的一键通业务呼叫建立时延的优化方法 Download PDFInfo
- Publication number
- CN100442939C CN100442939C CNB2006100868202A CN200610086820A CN100442939C CN 100442939 C CN100442939 C CN 100442939C CN B2006100868202 A CNB2006100868202 A CN B2006100868202A CN 200610086820 A CN200610086820 A CN 200610086820A CN 100442939 C CN100442939 C CN 100442939C
- Authority
- CN
- China
- Prior art keywords
- poc
- subscriber equipment
- transmission channel
- service call
- rab
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种基于蜂窝网络的一键通业务呼叫建立时延的优化方法:用户设备向无线网络控制器发送无线资源控制连接建立请求消息,该消息中包括PoC会话建立信息;无线网络控制器通过无线资源控制连接建立消息指定用户设备预先建立PoC无线接入承载的传输信道,传输信道的配置参数根据所述PoC业务的最高数据速率设定;进行无线接入承载建立和分组数据协议上下文激活,并根据传输信道的配置参数设置分组数据协议上下文中的服务质量参数;根据服务质量参数,用户设备与PoC服务器进行SIP信令交互,建立PoC会话。本发明无论采用何种PoC信令和语音承载方式,UMTS都能为PoC会话预先预留足够的资源,以此提高用户的使用效果。
Description
技术领域
本发明涉及宽带码分多址接入***中基于蜂窝网络的一键通技术,尤其涉及一种基于蜂窝网络的一键通业务呼叫建立时延的优化方法。
背景技术
集群通信,即PTT(Push To Talk,一键通),作为移动通信的一个重要分支,主要供公安、消防等专业用户进行指挥调度通信,并且一般单独进行组网。集群通信采用半双工、一对一或者一对多的通信方式,主叫方只需一个按键就能接续,被叫方无须摘机即可接听,从而具有接续速度快,可靠性、安全性较高等特点。
随着移动通信业务的发展,运营商希望在公众移动通信网内对普通用户实现PTT业务。因此,OMA组织从2003年起开始制定PoC(Push-to-talk overCellular,基于蜂窝网络的一键通)标准,使得在公众蜂窝网络上实现PTT业务成为可能。OMA PoC具有开放的架构,独立于具体的承载技术,因而能够很容易地引入到现有网络中。另外,OMA又向3GPP(3rd Generation PartnershipProject,第三代移动通信伙伴计划)提交了在WCDMA(Wideband CodeDivision Multiple Access,宽带码分多址接入)下实现PoC业务的使能协议23.979,使得PoC成为第一个基于IMS(IP Multimedia Subsystem IP,多媒体子***)的业务。
OMA PoC的控制面基于SIP(Session Initiation Protocol,会话初始化协议),在建立PoC会话时,UE(User Equipment,用户设备)通过SIP信令注册到PoC服务器,使得PoC服务器得到UE的路由、协商语音编码方式等信息。用户面基于RTP(Real-time Transmission Protocol,实时传输协议)/RTCP(Real-time Transmission Control Protocol,实时传输控制协议),其中,RTCP用于传送话权控制信令,每一时刻只有得到话权的用户才能说话,其他用户接听;RTP承载AMR(Adapt Multitude Rate,自适应多速率)语音帧,讲话者将语音发送到PoC服务器,PoC服务器进行必要的编码转换后再分发给会话组内的其他成员。对于RAN(Radio Access Network,无线接入网络)和CN(Core Network,核心网络)来说,SIP和RTP/RTCP都属于用户面,且都承载在IP协议之上,RAN和CN通过建立相应的RAB(Radio Access Bearer,无线接入承载)和PDP(Packet Data Protocol,分组数据协议)上下文来提供传送通道。
基于IMS的OMA PoC体系结构如图1所示,PoC服务器负责管理PoC会话的发起、中转、结束以及对PoC会话参与用户管理等处理工作,PoC服务器除需要与用户终端通信外,还要与Presence Server(呈现服务器)、XDMS(组管理服务器)、Device management(设备管理服务器)等交换数据与信令,***体设备服务。在IMS的注册中,首先用户建立PDP上下文,通过GPRS(General Packet Radio Service,通用分组无线业务)请求或者DNS(DomainName Server,域名服务器)解析过程发现IMS中的P-CSCF(Proxy Call SessionControl Function,代理呼叫会话控制功能),P-CSCF把注册请求转发给I-CSCF(Interrogating Call Session Control Function,协商呼叫会话控制功能),通过I-CSCF问询HSS(Home Subscriber Server,本地用户服务器)而找到S-CSCF(Server Call Session Control Function,服务呼叫会话控制功能),在S-CSCF中实现注册过程。
如前所述,PoC业务的信令面(SIP信令)和用户面(RTP/RTCP媒体流)在UMTS中都基于IP协议,一般将SIP信令设置为Interactive(交互)类业务,将RTP/RTCP媒体流设置为Interactive或Streaming(流动)类业务,SIP信令和RTP/RTCP流可用同一个PDP上下文承载,也可以分别用一个单独的PDP上下文承载。对于UMTS(Universal Mobile Telecommunications System,通用移动通信***)来说,PoC就是一个普通的PS(分组交换)域Interactive或Streaming类业务,不涉及PoC高层信令和数据,所以PoC呼叫建立过程在UMTS内的部分与普通的PS呼叫建立过程相同。典型的UE从小区空闲状态CELL_idle或小区寻呼信道CELL_PCH/注册区寻呼信道URA_PCH状态开始的PoC呼叫建立过程如图2和图3所示,其中图2是用户终端为主叫终端的情况,包括以下步骤:
S201,若UE为主叫,则用户按下PTT键,发起PoC会话建立请求。
S202a,当用户设备处于Cell_idle态时,用户设备在RRC Connection SetupRequest(RRC连接建立请求)中将Establishment Cause(建立原因)值设为Originating Interactive Call(源交互式呼叫)。当用户设备处于Cell_PCH/URA_PCH态时,将Cell Update(小区更新)中Establishment Cause(建立原因)值设为Originating Interactive Call(源交互式呼叫)。
S202b,无线网络控制器在RRC Connection Setup(RRC连接建立)或CellUpdate Confirm(小区更新确认)中指定用户设备建立SRB(信令无线承载)。
S203a,用户设备发送承载SIP的PDP上下文激活请求。
S203b-s203d,用于承载SIP的RAB指配和RB建立过程,其中由于RB建立过程需增加传输信道,所以将采用同步建立过程,等待激活时间产生额外的时延。
S203e,核心网络回复用户设备确认PDP上下文激活成功。
S204,用户设备和PoC服务器通过SIP信令交互,协商IP地址、AMR编码速率等参数,建立PoC会话。
S205,若RTP/RTCP媒体流采用单独的PDP上下文承载方式,用户设备须另外建立一个PDP上下文和RAB,和步骤s203类似,其中的RB建立过程采用同步方式。
S206,PoC服务器向主叫用户设备发送Talk Burst Confirm消息,指示用户设备可以开始发送语音。
S207,若RTP/RTCP媒体流与SIP共用一个PDP上下文承载,由于步骤s203中建立的RAB和PDP上下文的最大数据比特率只是为SIP设置的,所以此时RTP/RTCP媒体流可能会造成拥塞,大量语音IP包会缓存在用户设备或网络侧,甚至被丢弃。
S208,若RTP/RTCP媒体流与SIP共用一个PDP上下文承载,核心网络会发起PDP上下文修改过程,使得最大数据比特率满足SIP和RTP/RTCP数据的要求,无线网络控制器也会据此发起RAB修改过程,其中的RB重配置过程采用同步方式。
S209,最终空口和地面的承载都符合SIP和RTP/RTCP媒体流的速率需求,语音数据能够及时地被传送。
图3是用户终端为被叫终端的情况,包括以下步骤:
S301a-s301b,用户设备接收到网络发送的寻呼消息,其中的Paging Cause(寻呼原因)值为Terminating Interactive Call(终端交互式呼叫)。
S302a,用户设备处于Cell_idle状态时,在RRC连接建立请求中将Establishment Cause值设为Terminating Interactive Call。用户设备处于Cell_PCH/URA_PCH状态时,将Cell Update中Establishment Cause值设为Terminating Interactive Call。
S302b,无线网络在RRC Connection Setup(RRC连接建立)或Cell UpdateConfirm(小区更新确认)中指定用户设备建立SRB。
S303a,用户设备发送承载SIP的PDP上下文激活请求。
S303b-s303d,用于承载SIP的RAB指配和RB建立过程,其中由于RB建立过程需增加传输信道,所以将采用同步建立过程,等待激活时间造成额外的时延。
S303e,核心网络回复用户设备确认PDP上下文激活成功。
S304,用户设备和PoC服务器通过SIP信令交互,协商IP地址、AMR编码速率等参数,建立PoC会话。
S305,若RTP/RTCP媒体流采用单独的PDP上下文承载方式,用户设备须另外建立一个PDP上下文和RAB,和步骤S303类似,其中的RB建立过程采用同步方式。
S306,PoC服务器向被叫用户设备发送接收会话突发Receiving TalkBurst,提示用户设备开始接收语音。
S307,若RTP/RTCP媒体流与SIP共用一个PDP上下文承载,由于S303中建立的RAB和PDP上下文的最大数据比特率只是为SIP设置的,所以此时RTP/RTCP媒体流可能会造成拥塞,大量语音IP包会缓存在UE或网络侧,甚至被丢弃。
S308,若RTP/RTCP媒体流与SIP共用一个PDP上下文承载,CN会发起PDP上下文修改过程,使得最大数据比特率满足SIP和RTP/RTCP数据的要求,RNC也会据此发起RAB修改过程,其中的RB重配置过程采用同步方式。
S309,最终空口和地面的承载都符合SIP和RTP/RTCP媒体流的速率需求,语音数据能够及时地被传送。
在PoC***中,呼叫建立时延是重要性能指标,分为主叫建立时延和被叫建立时延。主叫建立时延是指主叫用户从按下PTT键到听到话权提示音之间的时间间隔;被叫建立时延是指从主叫用户按下PTT键到被叫用户听到语音的时间间隔。
现有方案中,如果采用两个PDP上下文分别承载PoC信令和语音,在收到会话突发确认Talk Burst Confirm或接收会话突发Receiving Talk Burst消息之前要经历两次RAB和PDP上下文建立过程,其中包含同步RB建立过程将造成主叫建立时延(或被叫建立时延)较长。如果采用一个PDP上下文承载PoC信令和语音,虽然在UE收到Talk Burst Confirm(或Receiving Talk Burst)之前只有一次RAB和PDP上下文建立过程,但由于之前建立的RAB和PDP上下文的最大数据比特率不符合RTP/RTCP媒体流的要求,需要对RAB和PDP上下文进行修改,可能造成被叫建立时延较长或通话质量较差,影响用户使用效果。
发明内容
本发明要解决的问题是提供一种基于蜂窝网络的一键通业务呼叫建立时延的优化方法,以克服现有技术中采用同步RB建立过程,PoC会话建立时延长的缺陷。
为了实现以上目的,本发明提供了一种基于蜂窝网络的一键通业务呼叫建立时延的优化方法,包括以下步骤:
A、用户设备向无线网络控制器发送无线资源控制连接建立请求消息,该消息中包括PoC会话建立信息;
B、所述无线网络控制器通过无线资源控制连接建立消息指定用户设备预先建立所述PoC无线接入承载的传输信道,所述传输信道的配置参数根据所述PoC业务的最高数据速率设定;
C、进行无线接入承载建立和分组数据协议上下文激活,并根据所述传输信道的配置参数设置所述分组数据协议上下文中的服务质量参数;
D、根据所述服务质量参数,用户设备与PoC服务器进行SIP信令交互,建立PoC会话。
步骤D后还包括:
E、根据用户设备与PoC服务器协商的语音编码速率对应的最大数据速率修改无线接入承载设置和分组数据协议上下文。
所述PoC会话建立信息包括主叫PoC会话建立和被叫PoC会话建立信息。
步骤A中,用户设备作为主叫终端或作为被叫终端接收到网络侧寻呼时,通知无线网络控制器建立PoC会话。
用户设备作为被叫终端时,具体过程包括:
核心网络向无线网络控制器发送寻呼消息,所述寻呼消息中包括被叫PoC会话建立信息;
所述无线网络控制器通过寻呼类型1消息将所述被叫PoC会话建立信息发给用户设备。
步骤B中预先建立的传输信道包括:SIP传输信道和RTP/RTCP传输信道,当使用一个PDP上下文承载时,SIP和RTP/RTCP使用一条传输信道;当使用两个PDP上下文承载时,SIP和RTP/RTCP各使用一条传输信道。
步骤A还包括:
用户设备向无线网络控制器发送小区更新请求,该请求中包括主叫/被叫PoC会话建立信息;
步骤B还包括:
所述无线网络控制器通过小区更新请求确认指定用户设备根据PoC的最高传输速率预先建立PoC无线接入承载传输信道。
步骤C具体为:进行SIP信令和RTP/RTCP信令的无线接入承载建立和分组数据协议上下文激活,并根据所述传输信道的配置参数设置服务质量参数。
步骤C具体为:进行SIP信令的无线接入承载建立和分组数据协议上下文激活,并根据所述传输信道的配置参数设置服务质量参数。
步骤C进一步包括:
C1、用户设备向核心网络发送激活分组数据协议上下文请求;
C2、核心网络向无线网络控制器发送无线接入承载指配请求;
C3、所述无线网络控制器异步建立无线承载;
C4、所述无线网络控制器向所述核心网络发送无线接入承载指配响应;
C5、所述核心网络向用户设备发送激活分组数据协议上下文响应。
步骤C3进一步包括:建立无线承载映射和无线链路控制协议信息。
步骤C之后或步骤D之后还包括进行RTP/RTCP信令的无线接入承载建立和分组数据协议上下文激活。
步骤C之后分组数据协议上下文激活请求中的服务质量参数中设置用户设备支持的最大传输数据速率;步骤D之后分组数据协议上下文激活请求中的服务质量参数中设置为用户设备与PoC服务器协商的语音编码速率对应的最高数据速率。
步骤E通过SIP信令交互获得IP地址、自适应多速率编码速率。
与现有技术相比,本发明具有以下优点:
本发明无论采用何种PoC信令和语音承载方式(一个PDP上下文还是两个PDP上下文),UMTS都能为PoC会话预先预留足够的资源,以此提高用户的使用效果。
对于使用一个PDP上下文承载SIP和RTP/RTCP的情况,由于RNC在RRC建立或小区更新过程中预先建立了PoC业务相关的传输信道,使得在后面的RAB指配过程中可以采用异步RB建立过程,能够避免采用同步RB建立过程中等待激活时间而造成的时延;同时,在UE和PoC协商语音编码速率之前建立的RAB和PDP上下文,都是按照PoC业务最大可能数据比特率来配置的,避免出现现有方案中RAB和PDP上下文建立时只考虑SIP信令而导致RTP/RTCP媒体流出现拥塞的情况。
对于使用两个PDP上下文分别承载SIP和RTP/RTCP的情况,一方面通过预建立SIP和RTP/RTCP相关的传输信道使得SIP和RTP/RTCP的RAB指配过程时延缩短;另一方面,UE可以选择不等待与PoC服务器协商语音编码速率,而提前按PoC业务最大可能RTP/RTCP数据比特率发起RTP/RTCP的PDP上下文激活过程,使得其能与SIP的PDP上下文激活过程和/或UE与PoC服务器的SIP信令交互过程并行,达到进一步缩小PoC会话建立时延的目的。
附图说明
图1是基于IMS的PoC网络结构图;
图2是现有技术主叫用户设备从空闲状态发起PoC呼叫建立流程图;
图3是现有技术被叫用户设备从空闲状态发起PoC呼叫建立流程图;
图4是本发明基本原理流程图;
图5是本发明主叫用户设备采取一个PDP上下文时,PoC会话建立流程图;
图6是本发明被叫用户设备采取一个PDP上下文时,PoC会话建立流程图;
图7是本发明主叫用户设备采取两个PDP上下文时,PoC会话建立流程图;
图8是本发明被叫用户设备采取两个PDP上下文时,PoC会话建立流程图。
具体实施方式
本发明一种基于蜂窝网络的一键通业务呼叫建立时延的优化方法,如图4所示,包括以下步骤:
步骤s401,用户设备向无线网络控制器发送无线资源控制连接建立请求消息,该消息中包括一键通PoC会话建立信息。其中,PoC会话建立信息包括主叫PoC会话建立和被叫PoC会话建立信息。另外,用户设备作为主叫终端或作为被叫终端接收到网络侧寻呼时,通知无线网络控制器建立PoC会话,用户设备作为被叫终端时,具体过程包括:核心网络向无线网络控制器发送寻呼消息,所述消息中包括被叫PoC会话建立信息,无线网络控制器通过寻呼类型1消息将所述被叫PoC会话建立信息发给用户设备。
步骤s402,所述无线网络控制器通过无线资源控制连接建立消息指定用户设备预先建立所述PoC无线接入承载的传输信道,所述传输信道的配置参数根据所述PoC业务的最高数据速率设定。其中,预先建立的传输信道包括:SIP传输信道和RTP/RTCP传输信道,当使用一个PDP上下承载时,SIP和RTP/RTCP使用一条传输信道;当使用两个PDP上下承载时,SIP和RTP/RTCP各使用一条传输信道。具体过程包括:用户设备向无线网络控制器发送无线资源控制连接建立请求或小区更新请求,该请求中包括源/终端PoC会话建立信息;无线网络控制器通过无线资源控制连接建立或小区更新确认指定用户设备根据PoC的最大传输速率预先建立PoC无线接入承载传输信道。
步骤s403,进行无线接入承载建立和分组数据协议上下文激活,并根据所述传输信道的配置参数设置所述分组数据协议上下文中的服务质量参数。进行SIP信令和RTP/RTCP信令的无线接入承载建立和分组数据协议上下文激活,并根据所述传输信道的配置参数设置服务质量参数;或进行SIP信令的无线接入承载建立和分组数据协议上下文激活,并根据所述传输信道的配置参数设置服务质量参数。
步骤s404,根据所述服务质量参数,用户设备与PoC服务器进行SIP信令交互,获得IP地址、AMR编码速率等信息,建立PoC会话。在步骤s404之后,可以根据用户设备与PoC服务器协商的语音编码速率对应的最大数据速率修改无线承载设置和分组数据协议上下文。
下面结合具体实施例对本发明进行详细说明。
当用户设备为主叫终端,且使用一个PDP上下文时,PoC会话建立流程如图5所示:
步骤s501,用户终端按下PTT键,发起PoC会话建立请求。
步骤s502a,用户终端处于Cell_idle(小区空闲)状态时,在RRC ConnectionSetup Request(RRC连接建立请求)中将Establishment Cause值设为OriginatingPoC Session Setup。用户终端处于Cell_PCH/URA_PCH态时,在Cell Update(Cell_PCH/URA_PCH态)中将Establishment Cause值设为Originating PoCSession Setup。
步骤s502b,无线网络控制器在RRC Connection Setup或Cell UpdateConfirm中指定用户设备预先建立PoC RAB相关的传输信道,配置参数的设定应参考PoC业务可能的最高数据比特率。
步骤s503a,UE发送PDP上下文激活请求,其中QoS Requested参数中的最大数据比特率应设为MBRSIP+MBRUE_supported,其中MBRSIP为SIP信令的最大数据比特率,MBRUE_supported为UE支持最高PoC语音编码速率所对应的最大数据比特率(语音帧加上RTP、UDP、IP头开销)。
步骤s503b-s503d,RAB指配和RB建立过程,由于步骤s402中PoC RAB相关的传输信道已经建立,所以RB建立过程采用异步方式,避免等待激活时间造成的时延。为了保证能够采用异步RB建立方式,即使步骤s402中建立的传输信道支持的最大数据比特率超过了RAB的需求,无线网络控制器也不会对传输信道进行重配置。
步骤s503e,核心网络回复用户设备确认PDP上下文激活成功。
步骤s504,用户设备与PoC Server进行SIP信令交互,建立PoC会话。
步骤s505,PoC服务器向主叫用户设备发送Talk Burst Confirm消息,指示用户可以开始发送语音。
步骤s506,由于之前建立的RAB和PDP上下文支持的最大数据比特率是等于或大于UE与PoC服务器协商的语音编码速率对应的最大数据比特率(记为MBRUE_PoC_negotiated)的,所以RTP/RTCP媒体流能顺利地发送出去,不会出现带宽不足而造成的拥塞。
步骤s507,若RAB和PDP上下文支持的最大数据比特率大于MBRUE_PoC_negotiated,出于节省网络资源的考虑,网络可发起RAB和PDP上下文修改过程,使得RAB和PDP上下文支持的最大数据比特率等于MBRUE_PoC_negotiated。
当用户设备为被叫终端,且使用一个PDP上下文时,PoC会话建立流程如图6所示:
步骤s601a-s601b,用户设备接收网络发送的寻呼消息,其中的PagingCause(寻呼原因)值为Terminating PoC Session Setup(终端PoC会话建立)。
步骤s602a,用户终端处于Cell_idle(小区空闲)状态时,在RRC ConnectionSetup Request(RRC连接建立请求)中将Establishment Cause值设为Terminating PoC Session Setup。用户终端处于Cell_PCH/URA_PCH态时,在Cell Update(Cell_PCH/URA_PCH态)中将Establishment Cause值设为Terminating PoC Session Setup。
步骤s602b,RNC在RRC Connection Setup或Cell Update Confirm中指定用户设备预先建立PoC RAB相关的传输信道,配置参数的设定应参考PoC业务可能的最高数据比特率。
步骤s603a,用户设备发送PDP上下文激活请求,其中QoS Requested参数中的最大数据比特率应设为MBRSIP+MBRUE_supported,其中MBRSIP为SIP信令的最大数据比特率,MBRUE_supported为用户设备支持最高PoC语音编码速率所对应的最大数据比特率(语音帧加上RTP、UDP、IP头开销)。
步骤s603b-s603d,RAB指配和RB建立过程,由于在步骤s502b中PoCRAB相关的传输信道已经建立,所以RB建立过程采用异步方式,避免等待激活时间造成的时延。为了保证能够采用异步RB建立方式,即使步骤s502b中建立的传输信道支持的最大数据比特率超过了RAB的需求,无线网络控制器也不会对传输信道进行重配置。
步骤s603e,核心网络回复用户设备确认PDP上下文激活成功。
步骤s604,用户设备与PoC服务器进行SIP信令交互,建立PoC会话。
步骤s605,PoC服务器向被叫用户设备发送Receiving Talk Burst,提示用户设备开始接收语音。
步骤s606,由于之前建立的RAB和PDP上下文支持的最大数据比特率是等于或大于用户设备与PoC服务器协商的语音编码速率对应的最大数据比特率(记为MBRUE_PoC_negotiated)的,所以RTP/RTCP媒体流能顺利地发送出去,不会出现带宽不足而造成的拥塞。
步骤s607,若RAB和PDP上下文支持的最大数据比特率大于MBRUE_PoC_negotiated,出于节省网络资源的考虑,网络可发起RAB和PDP上下文修改过程,使得RAB和PDP上下文支持的最大数据比特率等于MBRUE_PoC_negotiated。
当用户设备为主叫终端,且使用两个PDP上下文时,PoC会话建立流程如图7所示:
步骤s701-s702a,与图5相同,在此不在赘述。
步骤s702b,无线网络控制器在RRC Connection Setup或Cell UpdateConfirm中指定用户设备预先分别建立SIP和RTP/RTCP相关的传输信道,RTP/RTCP相关的传输信道配置参数的设定应参考PoC业务可能的最高数据比特率。
步骤s703a,用户设备发送SIP相关的PDP上下文激活请求。
步骤s703b-s703d,RAB指配和RB建立过程,由于SIP相关的传输信道已经建立,所以RB建立过程采用异步方式,避免等待激活时间造成的时延。
步骤s703e,核心网络回复用户设备确认PDP上下文激活成功。
步骤s704,用户设备与PoC服务器进行SIP信令交互,建立PoC会话。
步骤s705,用户设备发起RTP/RTCP相关的PDP上下文激活过程,由于RTP/RTCP相关的传输信道已经建立,所以RB建立过程采用异步方式,避免等待激活时间造成的时延。该步骤可以在s702之后、s706之前任何时候执行,若在用户设备与PoC服务器协商语音编码速率参数之前执行该步骤,则PDP上下文激活请求中QoS Requested的最大数据比特率应设为MBRUE_supported;若在用户设备与PoC服务器协商语音编码速率参数之后执行该步骤,则PDP上下文激活请求中QoS Requested的最大数据比特率应设为MBRUE_PoC_negotiated。为了保证能够采用异步RB建立方式,即使s703中建立的传输信道支持的最大数据比特率超过了RAB的需求,RNC也不会对传输信道进行重配置。
步骤s706,用户设备收到Talk Burst Confirm消息,提示用户可以开始发送语音。
步骤s707,由于之前建立的RTP/RTCP相关的RAB和PDP上下文支持的最大数据比特率是等于或大于MBRUE_PoC_negotiated的,所以RTP/RTCP媒体流能顺利地发送出去,不会出现带宽不足而造成的拥塞。
步骤s708,若RTP/RTCP相关的RAB和PDP上下文支持的最大数据比特率大于MBRUE_PoC_negotiated,出于节省网络资源的考虑,网络可发起RTP/RTCP相关的RAB和PDP上下文修改过程,使得RTP/RTCP相关的RAB和PDP上下文支持的最大数据比特率等于MBRUE_PoC_negotiated。
当用户设备为被叫终端,且使用两个PDP上下文时,PoC会话建立流程如图8所示:
步骤s801a-s802a,与图6相同,在此不在赘述。
步骤s802b,无线网络控制器在RRC Connection Setup或Cell UpdateConfirm中指定用户设备预先分别建立SIP和RTP/RTCP相关的传输信道,RTP/RTCP相关的传输信道配置参数的设定应参考PoC业务可能的最高数据比特率。
步骤s803a,用户设备发送SIP相关的PDP上下文激活请求。
步骤s803b-s803d,RAB指配和RB建立过程,由于在s802中SIP相关的传输信道已经建立,所以RB建立过程采用异步方式,避免等待激活时间造成的时延。
步骤s803e,核心网络回复用户设备确认PDP上下文激活成功。
步骤s804,用户设备与PoC服务器进行SIP信令交互,建立PoC会话。
步骤s805,用户设备发起RTP/RTCP相关的PDP上下文激活过程,由于在s702中RTP/RTCP相关的传输信道已经建立,所以RB建立过程采用异步方式,避免等待激活时间造成的时延。该步骤可以在s802之后、s806之前任何时候执行,若在用户设备与PoC服务器协商语音编码速率参数之前执行该步骤,则PDP上下文激活请求中QoS Requested的最大数据比特率应设为MBRUE_supported;若在用户设备与PoC服务器协商语音编码速率参数之后执行该步骤,则PDP上下文激活请求中QoS Requested的最大数据比特率应设为MBRUE_PoC_negotiated。为了保证能够采用异步RB建立方式,即使s802中建立的传输信道支持的最大数据比特率超过了RAB的需求,无线网络控制器也不会对传输信道进行重配置。
步骤s806,用户设备收到Talk Burst Confirm消息,提示用户可以开始发送语音。
步骤s807,由于之前建立的RTP/RTCP相关的RAB和PDP上下文支持的最大数据比特率是等于或大于MBRUE_PoC_negotiated的,所以RTP/RTCP媒体流能顺利地发送出去,不会出现带宽不足而造成的拥塞。
步骤s808,若RTP/RTCP相关的RAB和PDP上下文支持的最大数据比特率大于MBRUE_PoC_negotiated,出于节省网络资源的考虑,网络可发起RTP/RTCP相关的RAB和PDP上下文修改过程,使得RTP/RTCP相关的RAB和PDP上下文支持的最大数据比特率等于MBRUE_PoC_negotiated。
以上公开的仅为本发明的几个具体实施例,但是,本发明并非局限于此,任何本领域的技术人员能思之的变化都应落入本发明的保护范围。
Claims (14)
1、一种基于蜂窝网络的一键通业务呼叫建立时延的优化方法,其特征在于,包括以下步骤:
A、用户设备向无线网络控制器发送无线资源控制连接建立请求消息,该消息中包括PoC会话建立信息;
B、所述无线网络控制器通过无线资源控制连接建立消息指定用户设备预先建立所述PoC无线接入承载的传输信道,所述传输信道的配置参数根据所述PoC业务的最高数据速率设定;
C、进行无线接入承载建立和分组数据协议上下文激活,并根据所述传输信道的配置参数设置所述分组数据协议上下文中的服务质量参数;
D、根据所述服务质量参数,用户设备与PoC服务器进行SIP信令交互,建立PoC会话。
2、如权利要求1所述基于蜂窝网络的一键通业务呼叫建立时延的优化方法,其特征在于,步骤D后还包括:
E、根据用户设备与PoC服务器协商的语音编码速率对应的最大数据速率修改无线接入承载设置和分组数据协议上下文。
3、如权利要求1所述基于蜂窝网络的一键通业务呼叫建立时延的优化方法,其特征在于,所述PoC会话建立信息包括主叫PoC会话建立和被叫PoC会话建立信息。
4、如权利要求3所述基于蜂窝网络的一键通业务呼叫建立时延的优化方法,其特征在于,步骤A中,用户设备作为主叫终端或作为被叫终端接收到网络侧寻呼时,通知无线网络控制器建立PoC会话。
5、如权利要求4所述基于蜂窝网络的一键通业务呼叫建立时延的优化方法,其特征在于,用户设备作为被叫终端时,具体过程包括:
核心网络向无线网络控制器发送寻呼消息,所述寻呼消息中包括被叫PoC会话建立信息;
所述无线网络控制器通过寻呼类型1消息将所述被叫PoC会话建立信息发给用户设备。
6、如权利要求1所述基于蜂窝网络的一键通业务呼叫建立时延的优化方法,其特征在于,步骤B中预先建立的传输信道包括:SIP传输信道和RTP/RTCP传输信道,当使用一个PDP上下文承载时,SIP和RTP/RTCP使用一条传输信道;当使用两个PDP上下文承载时,SIP和RTP/RTCP各使用一条传输信道。
7、如权利要求1所述基于蜂窝网络的一键通业务呼叫建立时延的优化方法,其特征在于,步骤A还包括:
用户设备向无线网络控制器发送小区更新请求,该请求中包括主叫/被叫PoC会话建立信息;
步骤B还包括:
所述无线网络控制器通过小区更新请求确认指定用户设备根据PoC的最高传输速率预先建立PoC无线接入承载传输信道。
8、如权利要求1所述基于蜂窝网络的一键通业务呼叫建立时延的优化方法,其特征在于,步骤C具体为:进行SIP信令和RTP/RTCP信令的无线接入承载建立和分组数据协议上下文激活,并根据所述传输信道的配置参数设置服务质量参数。
9、如权利要求1所述基于蜂窝网络的一键通业务呼叫建立时延的优化方法,其特征在于,步骤C具体为:进行SIP信令的无线接入承载建立和分组数据协议上下文激活,并根据所述传输信道的配置参数设置服务质量参数。
10、如权利要求8或9所述基于蜂窝网络的一键通业务呼叫建立时延的优化方法,其特征在于,步骤C进一步包括:
C1、用户设备向核心网络发送激活分组数据协议上下文请求;
C2、核心网络向无线网络控制器发送无线接入承载指配请求;
C3、所述无线网络控制器异步建立无线承载;
C4、所述无线网络控制器向所述核心网络发送无线接入承载指配响应;
C5、所述核心网络向用户设备发送激活分组数据协议上下文响应。
11、如权利要求10所述基于蜂窝网络的一键通业务呼叫建立时延的优化方法,其特征在于,步骤C3进一步包括:建立无线承载映射和无线链路控制协议信息。
12、如权利要求9所述基于蜂窝网络的一键通业务呼叫建立时延的优化 方法,其特征在于,步骤C之后或步骤D之后还包括进行RTP/RTCP信令的无线接入承载建立和分组数据协议上下文激活。
13、如权利要求12所述基于蜂窝网络的一键通业务呼叫建立时延的优化方法,其特征在于,步骤C之后分组数据协议上下文激活请求中的服务质量参数中设置用户设备支持的最大传输数据速率;步骤D之后分组数据协议上下文激活请求中的服务质量参数中设置为用户设备与PoC服务器协商的语音编码速率对应的最高数据速率。
14、如权利要求2所述基于蜂窝网络的一键通业务呼叫建立时延的优化方法,其特征在于,步骤E通过SIP信令交互获得IP地址、自适应多速率编码速率。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100868202A CN100442939C (zh) | 2006-06-20 | 2006-06-20 | 基于蜂窝网络的一键通业务呼叫建立时延的优化方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100868202A CN100442939C (zh) | 2006-06-20 | 2006-06-20 | 基于蜂窝网络的一键通业务呼叫建立时延的优化方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101005704A CN101005704A (zh) | 2007-07-25 |
CN100442939C true CN100442939C (zh) | 2008-12-10 |
Family
ID=38704502
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2006100868202A Expired - Fee Related CN100442939C (zh) | 2006-06-20 | 2006-06-20 | 基于蜂窝网络的一键通业务呼叫建立时延的优化方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100442939C (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101969435A (zh) * | 2010-09-30 | 2011-02-09 | 北京新媒传信科技有限公司 | 基于sip-c协议的交互方法及*** |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101938707B (zh) * | 2009-06-29 | 2013-08-07 | 华为技术有限公司 | 一种优化一键通时延的方法和装置 |
CN103391623B (zh) * | 2012-05-11 | 2016-03-30 | ***通信集团广东有限公司 | 一种分组数据协议上下文的激活方法及装置 |
CN103716299B (zh) * | 2013-09-22 | 2019-10-25 | 南京中兴新软件有限责任公司 | 一种基于sip进行会话的方法、终端及呼叫业务服务器 |
CN106211362B (zh) * | 2016-08-23 | 2020-02-28 | 海能达通信股份有限公司 | 集群会话方法、装置、终端设备和网络侧设备 |
CN107070854A (zh) * | 2016-12-09 | 2017-08-18 | 西安华为技术有限公司 | 一种传输语音数据的方法、设备和装置 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2005051016A1 (en) * | 2003-11-24 | 2005-06-02 | Telefonaktiebolaget Lm Ericsson (Publ) | A method of reducing or compensating for delays associated with ptt and other real time interactive communication exchanges |
CN1662093A (zh) * | 2003-12-05 | 2005-08-31 | 摩托罗拉公司 | 减少ptt呼叫建立延迟的方法和装置 |
WO2005086501A1 (en) * | 2004-02-27 | 2005-09-15 | Nortel Networks Limited | A fast call setup method |
US20050250523A1 (en) * | 2004-05-10 | 2005-11-10 | Lemke Mark R | Push-to-talk reverse channel establishment |
CN1770916A (zh) * | 2004-11-07 | 2006-05-10 | 华为技术有限公司 | 一种被呼方建立呼叫连接的方法 |
-
2006
- 2006-06-20 CN CNB2006100868202A patent/CN100442939C/zh not_active Expired - Fee Related
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2005051016A1 (en) * | 2003-11-24 | 2005-06-02 | Telefonaktiebolaget Lm Ericsson (Publ) | A method of reducing or compensating for delays associated with ptt and other real time interactive communication exchanges |
CN1662093A (zh) * | 2003-12-05 | 2005-08-31 | 摩托罗拉公司 | 减少ptt呼叫建立延迟的方法和装置 |
WO2005086501A1 (en) * | 2004-02-27 | 2005-09-15 | Nortel Networks Limited | A fast call setup method |
US20050250523A1 (en) * | 2004-05-10 | 2005-11-10 | Lemke Mark R | Push-to-talk reverse channel establishment |
CN1770916A (zh) * | 2004-11-07 | 2006-05-10 | 华为技术有限公司 | 一种被呼方建立呼叫连接的方法 |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101969435A (zh) * | 2010-09-30 | 2011-02-09 | 北京新媒传信科技有限公司 | 基于sip-c协议的交互方法及*** |
CN101969435B (zh) * | 2010-09-30 | 2013-02-20 | 北京新媒传信科技有限公司 | 基于sip-c协议的交互方法及*** |
Also Published As
Publication number | Publication date |
---|---|
CN101005704A (zh) | 2007-07-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1829302B1 (en) | Push-to-x over cellular coordinated floor and packet scheduling | |
US7058042B2 (en) | One-to-one communication | |
CN1972254B (zh) | 终端之间语音和多媒体的互动服务的装置和方法 | |
US8280422B2 (en) | Inter-system communications in mobile communications system | |
EP1811745A1 (en) | Method and apparatus for handling IMS terminal's call request including request for real-time service received over IMS domain by CSI terminal | |
CN1853395A (zh) | 建立通信会话 | |
WO2005120035A1 (fr) | Procede et systeme pour l'interconnexion d'un systeme de groupe numerique et d'un systeme telephonique publique | |
KR20070024586A (ko) | 시간-중요 서비스들에 대한 세션 설정 | |
US20100284267A1 (en) | Call set-up in a communication network | |
CN100442939C (zh) | 基于蜂窝网络的一键通业务呼叫建立时延的优化方法 | |
EP1380182B1 (en) | One-to-one communication in a system having different control plane and user plane logical entities | |
CN1914854A (zh) | 用于一键通服务的方法和*** | |
CN101217702A (zh) | Ip多媒体子***集中业务呼叫保持业务的实现方法 | |
CN101137105B (zh) | 控制按键即讲业务的方法和*** | |
CN100438656C (zh) | 一种实现集群业务的***和方法 | |
CN100459745C (zh) | 在第三代移动通信网络中实现一键通业务的方法 | |
KR100761805B1 (ko) | Ptt 서비스 방법 및 장치 | |
CN103139718A (zh) | 一种PoC时延优化处理的方法及装置 | |
CN103428781B (zh) | 一种ip语音通话切换的方法及***、用户设备 | |
EP1702487A1 (en) | Method and system for controlling access bearer in a real-time data service | |
CN102833715B (zh) | 询问转接实现方法、应用服务器、业务终端和*** | |
CN101931907B (zh) | 一种分组核心网呼叫传统电路域网络用户的方法及*** | |
CN101325792B (zh) | 一种ip多媒体子***集中业务会话控制路径的切换方法 | |
CN109348079A (zh) | 一种适合于窄带无线网络的一对多群组分组话音实现方法 | |
TW201023612A (en) | Mobile communication method and application thereof |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20081210 Termination date: 20210620 |