>
首页 » 解决方案 » 在移动终端中实现PoC服务功能的设计考虑

在移动终端中实现PoC服务功能的设计考虑

作者:  时间:2008-11-17 22:00  来源:52RD手机研发

VoIP这种通过基于包交换服务传输语音的技术在个人计算机的群体中普及程度正在稳步提高。技术的进步使得在蜂窝设备中运行类似服务成为可能。与台式PC不同的是,其关键问题是如何调整好这些服务功能,以应对带宽下降以及处理功耗必须显著减少的挑战。 

图1: 典型的PoC会话建立过程。
 

“无线一键通”(PoC,Push-to-Talk Over Cellular)服务定义了一种适合移动设备的半双工VoIP系统。与传统双向无线系统如专有移动网络(PMR,Private Mobile Radio)不同的是,通过利用无线数据网络的包交换能力,这种服务将不受地理位置的限制。要使得PoC成功,手机和网络的性能必须进行优化,人机界面也需要更加简便易用。任何影响延迟的性能因素可能都将决定这个服务是走向成功,还是不幸失败。 

PoC具有一套VoIP通讯服务和即时短信风格的特性,如在线状态提示和消息等。用户可以得到以下的语音服务如: 

1. 一对一的对话:允许一个用户立即与从通讯录中选出的在线密友进行联系。 
2. 特别分组:可以临时为特定目的从在线通讯录中选择一个或者多个联系人召集起来进行会话。如要一对一对话,可在电话簿风格的列表中选择任何一个联系人。 
3. 分组对话:预先定义分组(如销售团队),可以仅仅通过一个按键与分组中的多方进行会话。 
4. 聊天组:用户可以加入或退出预先定义好的聊天室风格会议。 

开放移动联盟(OMA)正在进行PoC的标准化工作,迄今为止,还没有一个统一的“一键通”标准。现在市场上的解决方案一般都是以往或者厂商专有的标准。运营商和用户都不希望市场出现割裂的情况,用户经历过由于不同PoC技术之间不能访问特定的服务或者不能联系伙伴而带来的挫折感,而运营商也担心不兼容问题令PoC收入下降。以美国的SMS服务为例,在不同的运营商之间实现互通之后,这项业务的收入增长超过300%。 

PoC协议 

与许多VoIP解决方案一样,OMA的PoC解决方案是基于互联网工程工作小组(IETF)所定义的会话发起协议(SIP)和实时协议(RTP)的。 

SIP协议被用来作为“一键通”协议的控制层面,它提供了以下功能: 
1.用户在网络中的注册和认证; 
2.定义、建立和管理谈话进程; 
3.对其他用户在线状态显示的支持; 
4.在用户之间发送警报(消息)。 

语音包的传输是通过RTP协议实现的。大部分的RTP链路传输是通过语音包的,其余的是控制信息RTCP。实时控制协议(RTCP)提供了会议中谈话者的仲裁器,并且对RTP会话质量进行判决。 

典型的PoC会话建立过程有6个阶段,如图1所示: 
图2:针对具有PoC功能
的手机的特定插件和接口。
 

1.数据信道的建立:PoC独立于任何特定的数据载体(如GPRS、EDGE或者CDMA等),网络本身应该提供不同数据网络之间协同工作的机制; 
2.注册:手机如果还没有注册到PoC服务器,首先就需要做这项工作。注册过程将手机的联系方式细节(如IP地址)提供给PoC服务器,并且进行网络用户的认证工作。所以,注册是发送和接受PoC进程的先决条件。由于无线连接的固有特性,注册过程需要周期性的更新; 
3.预约:一般情况下,用户需要经常尝试去判断联系人的在线状态。这个需求将产生一个包含联系人现在状态的初始回复,并且在其状态发生变化时发送一个联系人状态的更新信息; 
4.邀请/接受谈话:一个谈话进程是从SIP邀请指令的发出开始的。这个邀请将被发送到PoC服务器,并重新定向到收件人,收件人做出相应的回应。在邀请/接受的过程中,通过SIP消息中的会话描述协议(SDP),会话参与者交换了传输介质的容量信息。SDP描述了传输介质中物理链路的详细信息以及编码类型和数据速率; 
5.媒介传输:一旦SIP会话建立成功,会话参加者的数据将通过PoC服务器进行交换。由于PoC是半双工,参与者在发送谈话信号之前必须请求许可,仲裁是通过PoC服务器完成的。一旦一次讲话数据序列完成,参与者需要放弃控制从而其他用户可以请求讲话。在媒介传输过程中,发送者和接收者信息报告在参与者之间交流。其中一点很重要的是,会话容量信息需要根据现有网络状态不断更新,这样才能保证对于所有的会话成员来说数据都可以接收; 
6.会话终止:当会话结束以后,会话将终止。 

将这些协议集成到PoC客户端的工作,将会对手持设备的设计产生深远的影响,在设计过程中,有很多因素需要认真考虑。 

蜂窝设备中的PoC 

图2所示的系统架构展示了针对具有PoC功能的手机的特定插件和接口。这个系统的中心组件就是PoC客户端软件。客户端软件通过PoC协议与系统不同部分的连接以实现PoC的功能,同时它为希望应用PoC协议的应用软件(调制解调器设备、图形接口)提供了简单的接口,这些接口包括: 

1.配置管理:为客户端程序提供配置管理功能,包括用户细节以及网络设定的存储管理; 
2.通讯录:管理并存储此客户端的通讯录,并且可以与网络上的通讯录服务器进行同步; 
3.在线状态:提供在线联系人的注册和其他操作; 
4.会话:能够创建和管理会话,进行谈话仲裁等; 
5.消息服务:提供PoC消息提醒功能。 

以上这些接口很多都是双向的。一个应用程序可以通过会话接口主动请求一个新的会话,也可以接收邀请提示加入一个从外部进来的会话。 

为了能向应用程序提供这些接口,PoC客户端程序需要与系统其他许多部分进行通信: 

1. TCP/IP。利用这个接口,客户端可以进行相应信道的配置如前后文的建立和QoS设定等。 
2. SIP。PoC客户端创建一个SIP用户代理进程,可以提供建立会话、用户层面调整、在线状态和通讯录管理等服务。用户代理进程通过发送和接收PoC的SIP消息实现这些功能。 


图3:数据接收过程。
 

3. RTP/RTCP。PoC客户端程序也提供了处理接收到的RTP和RTCP数据的程序。RTP处理机提供了通往音频系统的接口,可以高效率将RTP数据传输到多媒体编解码器,而RTCP处理机将控制信息传送到PoC客户端程序,这些RTCP数据是用来控制整个系统的。当收到RTCP数据以后,如果是讲话者指示或者是由于QoS信息变化引起的SIP或者信道管理,主要会影响到音频接口。 
4. 音频。音频接口和PoC客户端软件具有双向接口。当接收到网络数据以后,客户端配置音频系统开始播放从紧随RTCP包的RTP链路进来的数据流,音频系统将会根据数据流状态将信息返回到客户端。在传输方向,PoC客户端发出提示,指明抽样编码后的音频何时应该开始或者停止的提示,音频系统也将根据提示对音频数据进行传输或者缓冲。 

PoC很重要的一方面就是系统反应速度。对系统中的SIP和RTP性能不断优化是相当重要的,在转换时SIP远不及对RTP承载数据的处理重要。在VoIP系统中,最重要的路径就是数据信道和音频系统的联接。与RTP接口的关键问题是保证输入的数据能够被相关软件实体很好的及时处理完成。如果我们去研究接收过程,主要有以下动作被执行: 
数据包到达手机—— 
* 数据通过数据通道路由到相关前后文环境进行处理。 
* 前后文的拥有者——TCP/IP收到数据到达的提示。数据经过验证通过堆栈传输到上层,到达监听特定端口的实体部分。对于PoC来说,SIP和RTP协议栈会分别监听属于他们用户代理和会话的数据。 
* 如果数据属于SIP用户代理,A. 数据包进入SIP协议栈处理;B.处理好的SIP消息依次通过目标SIP用户代理。在一个典型的手机里面,对于每个SIP应用有独立的不同用户代理(如一个是为PoC应用,另一个是针对即时短信服务等)。 
* 如果数据是一个RTP会话的RTCP数据,A.数据包被送到RTP协议栈被处理。处理后的数据包被送入与针对会话的RTCP处理相关的处理机中。对于每个PoC会话,都会定义一个合适的RTCP处理程序。 
B.由于RTCP包含主要的控制信息,它被直接路由到PoC客户端软件中进行处理: 
a.包含底层信息的RTCP APP包用来控制和配置系统,并把指示信息发送到应用程序,通知它们底层状态发生变化。PoC客户端软件收到底层产生的指示,就会配置音频系统做好播放音频流的准备工作。 
b. 包含讲话者识别信息的RTCP SDES 包由诸如输入RTP数据突发等来监控,可与用户名联系起来,因而应用程序可以显示出富有意义的用户指示。 
c. 服务质量通过使用收到的发送者和接收者报告监控。相应的,PoC客户端产生自己的报告并发送出去。 
* 如果数据包用于是RTP会话: 
A.TCP/UDP包将被传送到RTP协议栈处理; 
B.一旦处理完成,RTP数据包被成功收到,它将被传送到它所属的会话的RTP数据处理机中。对于每个PoC会话,只有单一的RTP会话,因而具有自己相关的数据处理机。 
C.面向PoC会话的RTP数据收到后,被处理机传送到音频编解码器: 
a.RTP数据将根据会话的优先级进行筛选。如一个会话的数据收到时,另外一个会话正在讲话,这个包将被丢弃。 
b.有效的RTP包数据将根据有效载荷类型(如AMR)被路由到合适的编解码器。 
c.数据帧经过缓冲以通过编解码器解码。数据包里面包含的信令内容可以帮助编解码器与数据序列互相同步。数据序列开始、结束、讲话者指示和编解码器速率变化等信息需要传递到PoC客户端软件以用于控制。 
d.一旦有足够的数据进入缓冲,可以应对传输中的抖动,那么音频流就将进入播放阶段。 

以上过程图3有所阐明。 

以上情况中一个更加复杂的问题是这些处理在设备中所处的物理位置。大部分的手机设计依靠多个处理器来满足这些需要。典型的分工是,协议软件在一个RISC微处理器中运行,而物理层和多媒体编解码将在一个传统的DSP中运作。参考上述的数据流程,我们看到数据编解码将在物理层的DSP中完成,然后基于TCP/IP协议栈形式被上传到微处理器中,送入RTP处理机,处理机再将有效载荷返回到DSP进行音频编解码。很明显,处理过程分段反而使事情变得更加复杂,所以需要小心考虑以优化系统性能。 


图4:应用程序需要考虑的一
些界面和一些有可能开发的应用程序。
 

除了PoC系统组件的集成工作外,在手机里面使用SIP和RTP协议栈也是个问题。随着IMS的成长,SIP和RTP可能成为这一代和下一代手机服务的支撑技术。所以以下问题变得极其重要: 

1. 存储器占位面积:在设计手机的时候,一个关键问题就是材料清单BOM表。当引入大量代码以后,设计者也许没有别的办法只能增加内存容量从而造成占位面积迅速增加。PoC需要SIP和RTP协议,比较自己开发或者从外部购买,从互联网上面下载一些免费协议代码将更具吸引力。大部分免费下载的解决方案都是基于具有丰富资源(如足够的磁盘或者内存空间)的PC而开发,对于嵌入式设备紧张的资源考虑甚少。 

2. 维护问题:一个典型的SIP解决方案可能包含几千句没有经过验证的代码。在手机能够正式投产前,到底需要多长时间来跟踪和解决系统错误或者漏洞呢?这些解决方案能处理所有的需求吗?如果答案是否定的,那么代码容易被人理解并修改增强吗?也许协议栈已经足够满足今天的需求,但是可能对于新的应用需要升级。 

3. 性能问题:如同前面提到的占位面积会因为方案是专为计算机设计而需要折衷,方案的处理速度也是一个问题。SIP作为一个HTML语言,继承了许多分析程序来进行所需的编码与解析工作。代码的效率十分重要,极耗资源的解析子程序可能会阻塞任务调度,并影响高优先级的任务。 

应用程序 

应用程序的目标是给手机一个友好、容易理解的用户界面。应用程序开发人员有可能将一些功能进行组合以使用户界面更加简明易用,譬如将PoC和即时短信的通讯录和SIM卡的电话簿组合或者将PoC和传统的电路交换语音服务一同分在语音服务里面。这样,用户就可以在打电话之前通过组合的通讯录看看对方是否在线,根据在线状态,他们可以选择发送一个PoC序列还是发起传统语音通话。图4展示了应用程序需要考虑的一些界面和一些有可能开发的应用程序。 

本文小结 

由于2.5G和3G网络的手机用户可利用带宽不断增加,市场上具有潜力而基于包的应用如PoC有望很快布署。为了使这些新的业务如PoC能够迅速成功,认真考虑性能和集成问题以及使吞吐量最大化,是一个基本的工作,这样才能给用户提供一种令人赞叹的切身体验。 

 

相关推荐

u-blox与Iskraemeco和EMH合作 将蓝牙显示接口整合至智能量表

行业应用 2018-11-15

业界最小的u-blox SARA 3G模组荣获年度最佳产品奖

3G  u-blox  导航  2014-09-15

u-blox推出具备3G/2G向下相容性的4G LTE模组 TOBY-L2

u‑blox  TOBY-L2  LTE  3G  2014-01-15

4G宣传战铺天盖地 业内呼吁消费者理性对待

4G  3G  2013-12-24

u-blox发布业界尺寸最小的新款SARA 3G模组产品

u‑blox  SARA  3G  2013-12-16

LTE终端欲爆发 芯片需先行

3G  4G  2013-11-27
在线研讨会
焦点