DIY编程器网

标题: 终端上VoLTE和RCS的共存 [打印本页]

作者: admin 时间: 2014-10-13 10:06
标题: 终端上VoLTE和RCS的共存
文章描述了爱立信关于RCS和VoLTE在同一IMS网络相同终端上的共存和融合的观点，并且共存的RCS和VoLTE使用相同的签约信息、相同的手机号码。RCS和VoLTE共同提供给用户统一的电话业务和丰富的个人通信多媒体业务。

我们预测有不同的终端实现机制去支持RCS和VoLTE在相同终端和网络上的共存；并概括了不同的网络连接方式支持融合的业务体验。虽然终端里单个IMS协议栈方案是业界认可的演进方向，但是早期终端仍会使用双IMS协议栈的实现机制。

我们认为要部署RCS和VoLTE业务，不需要等到终端厂家对RCS和VoLTE共存机制达成一致。然而，爱立信IMS网络支持并减轻由于双IMS协议栈导致的在资源和业务性能方面的影响。

融合多媒体通信之路-RCS和VoLTE

LTE是全分组交换（PS）技术。不象别的移动接入技术，如GSM，WCDMA和CDMA，包含了对传统电路交换（CS）电话业务的支持，LTE不支持。在LTE上的电话业务是在PS域上的移动宽带业务，它依赖于LTE无线和演进的分组核心网（EPC），能满足电话业务的需要。

业界选择VoLTE来在新的LTE接入网上提供运营商电话业务。GSMA运营商在2010年初决定主导为LTE上的语音和短信制定电信领域的、标准的方案。这方案总则（Profile）是3GPP所定义的最小必须支持的功能子集，用来帮助运营商和厂家建立互联互通的LTE语音和短信业务。GSMA IR.92“IMS Profile for Voice and SMS”是通用的VoLTE（Voice over LTE）参考文档；VoLTE同时也参考GSMA IR.94“IMS Profile for Conversational Video Service”，它制定了独特的功能，增加视频媒体能力到VoLTE中。

我们认为VoLTE作为LTE上的语音和视频业务，不需要局限于IR.92/94定义的最小能力集。VoLTE除提供高清语音和视频能力外，同样VoLTE被定义作为第一线电话服务，能满足所需要的业务能力和性能。

GSMA定义的RCS（Rich Communication Suite），提供了通过移动PS接入和（或）Wi-Fi接入的融合通信业务，能保证运营商间的业务互通。通信业务包括了从呼叫中视频和文件的共享、一对一和群组的聊天，一对一和群组中文件传送，到基于IP的语音和视频呼叫。

RCS丰富化通信业务是电话业务的补充，在这电话业务可以是传统的CS电话，也能是VoLTE.

当第一线的电话业务（CS和VoLTE）不可使用，或者用户不想使用时，RCS也提供了通过任何IP连接（通常是Wi-Fi）的电话业务，即语音和视频呼叫。另外有可能，CS被用来提供语音业务，用户希望通过PS提供视频呼叫。

RCS IP语音/视频呼叫（没有特定的QoS保证）允许运营商与OTT通信业务提供商提供的类似业务进行竞争。当VoLTE包含视频时，VoLTE业务提供QoS和满足法律法规要求。然而，在具备VoLTE能力的终端中RCS能够使用VoLTE提供的语音/视频能力，而不见得必须使用CS提供的能力；另外，当VoLTE终端附着到LTE后提供VoLTE业务时，RCS IP语音/视频呼叫就不能使用了。

RCS的通信体验类似于OTT应用，被认为是运营商留住客户的关键。RCS已经在欧洲、北美和亚洲寻找到了市场，市场推广品牌是GSMA拥有的joyn？。我们看到，RCS是灵活演进的个人通信业务和VoLTE互通的基础平台。爱立信通信演进方案支持所有核心通信业务和各种宽带接入方式，保证互联互通和业务的差异性。

当RCS和VoLTE业务共存时，运营商需要提供给终端用户一个统一、集成的通信体验。这表明需要同一IMS网络框架、同一发起通信业务的地址本、同一用户标识（E.164，MSISDN）的业务签约信息。依赖于当前可利用的接入网络和业务要求，这样的共存业务能提供最好的用户使用体验。

作为小结，目前有市场推动者正领导和推动RCS IP语音/视频呼叫和VoLTE在同一网络相同终端上共存。业务推广和业务演进的时间表使得需要支持不同的共存机制，然而，移动运营商可以灵活决定是否需要支持RCS IP语音/视频呼叫：

哪些业务要提供（端对端VoIP，VoIP到传统网络CS，都要或都不要）。

哪种承载可以提供VoIP（一些或所有Wi-FI，HSPA PS，3G PS和LTE）。

哪些用户允许使用这个VoIP业务（依赖于用户档案）。

智能移动终端的演进

智能手机架构是蜂窝设备的架构演进的起点。智能手机架构中的“调制解调器芯片”，或称为芯片，处理蜂窝无线、承载管理和CS电话业务。智能手机架构中的应用处理器（AP）装载操作系统（OS），运行所有在互联网APN上的业务，这些业务使用芯片作为连接到移动PS网络的接口。

当RCS早于VoLTE部署时，非VoLTE终端的RCS可以有两种方式提供给用户。RCS被终端厂家内置在设备中，RCS的功能和能力紧紧地集成在手机地址簿里，通过多种手机原有的方式访问；RCS也能通过从应用商店下载应用的方式安装在终端中，RCS的功能通过一个独立的应用提供给用户，此下载的应用通常在终端的文件夹或桌面上。

在早期版本，没有引入VoLTE时，RCS通常是自带IMS协议栈，使用互联网APN连接到运营商网络中。

当手机支持具备SRVCC的VoLTE时，需要紧密地和驻留在芯片的PS承载控制、CS信令和CS媒体集成在一起，也考虑到所需要的性能要求和电池优化措施，VoLTE客户端需要内置在芯片中。

作为基于IMS的业务，如RCS，推动和提升运营商在手机终端的业务渗透率，因此定义不同IMS业务架构在同一终端上的共存非常必要。在这讨论的方式包含如下：

多IMS协议栈方式

IMS终端API方式

SIP B2BUA/Proxy方式

一些早期RCS和VoLTE结合的终端会有RCS客户端和VoLTE客户端各自独立实现方式。RCS客户端驻留在终端的AP部分，而VoLTE客户端驻留在芯片处。RCS要使用互联网APN或者通过Wi-Fi连接到移动无线接入网；VoLTE则要使用专用的、标准名称的IMS APN连接到运营商的无线接入网。

图一：RCS和VoLTE各自独立的实现

业界中关心的问题是，双客户端和双IMS协议栈的实现方式，会带来资源使用的增加和由于双IMS注册和重叠业务导致的服务限制。然而，弊病是多个IMS注册必须在终端里维持，这样会对流量造成明显的影响，更重要的是，对手机电池寿命的影响。因此，此架构对于移动终端来说并不推荐，因为最佳的手机电池使用时间是智能手机的主要功能之一。

我们都知道结合RCS和VoLTE的终端提供单一的登记的方便。一种方式是，在终端芯片中提供一个共用的IMS协议栈，同时引入一个新的API接口，位于芯片和高层操作系统（OS）/应用处理器（AP）之间，服务于RCS应用和IMS协议之间的调用，如图2.另一种方式是，允许多个客户端（应用）自带自己的IMS协议栈，但是在芯片里引入一个简化的IMS B2BUA/Proxy模块，它能聚合相关的IMS信令，并且在网络看来，它提供唯一一个整合后的IMS接口，如图3.

图2：API方案图3：B2BUA/Proxy方案

对于API方案，此架构的好处是，终端仅仅有一个IMS协议栈，然而，为了保证此方式成功，要求一个有足够灵活的IMS API的标准化工作是需要的，要允许所有终端能够共享相同的API原理、由于OS和终端API的多样性，要求其语法尽可能的多。

对于B2BUA/Proxy方案，尽管终端里有多个IMS协议栈（每个客户端一个），但是仅仅一个IMS协议栈实际上注册到IMS核心网。此想法只要是一个SIP B2BUA/Proxy功能模块被引入到终端中，主要的任务是处理IMS注册，包括鉴权和信令安全，从电池管理角度看，这样是最好的资源消耗方式。这个新的功能模块对运行在终端上的不同的IMS客户端/协议栈扮演了一个透明的方式。它拦截注册、连接管理（如保活）等的SIP消息，以便IMS核心网维护和管理单个注册和IMS连接。此架构的好处是，不必放弃每个IMS业务有自己IMS协议栈的想法，能够使影响最小化，特别是对智能终端来说最关键的电池电量管理。为了使架构更加有效，新的B2BUA/Proxy功能必须深度集成到设备里，理想地，绑定到终端硬件里。

目前来看，终端通常会部署了两个独立的IMS协议栈，一个是使用IMS APN的VoLTE客户端，另一个是使用互联网APN或者专用的RCS APN的RCS客户端，以后，或不久的未来，我们能看见使用一个IMS协议栈的终端平台，VoLTE和RCS能够共享相同IMS APN和IMS注册。

GSMA目前已针对IMS协议栈的问题拿出了结论，VoLTE和RCS需要在终端中共享相同的IMS协议栈。就像在RCS规范中解释的一样，推荐的架构是允许每个终端仅仅有一个IMS注册。即使GSMA推荐一个IMS协议栈的方式，然而，现实情况是，目前在市场上和终端厂家，依然存在，或正在推出双IMS协议栈的终端。

因此，IMS网络需要准备好支持不同形式的终端结构，如VoLTE和RCS在双IMS协议栈上。

RCS和VoLTE共存时的网络连接

网络和终端架构需要支持VoLTE和RCS结合在一起的业务体验。

用户期望有一个高品质的业务，不管在家里，漫游外地，或在不同地方（家里，户外，办公室，酒店）。当描述业务的使用场景和体验时，用户对成本和质量的期望也需要被考虑。然而这些使用场景和体验依赖于当前的接入环境，漫游地或者在家里，场景可以不同。例如，当在酒店，或者漫游到外地时，用户可能更喜欢通过Wi-Fi的视频呼叫；当在归属地运营商时，用户偏爱使用LTE接入。

网络需要支持不同的接入技术下不同的RCS和VoLTE实现机制，不同的接入方式可能取决于用户的选择。依赖于市场和运营商的策略，接入技术的选择可以是LTE、WCDMA、GSMA、CDMA和Wi-Fi，如图4.

图4：RCS和VoLTE的网络连接

VoLTE总是使用专用的IMS APN，为了保证正确的QoS参数和漫游。当使用IMS APN时，仅仅IMS流量（信令和媒体）能够在此PDN连接上发送。承载要使用预先定义的QoS参数：信令为QCI 5，媒体为QCI 1，参见图5.

图5：当VoLTE客户端使用IMS APN时承载使用的QoS参数

依赖于终端的实现机制，当正在使用移动网络接入时，RCS业务可以在IMS APN上提供，也能在互联网APN上。RCS规范允许Wi-Fi作为一个接入补充，例如在没有LTE覆盖时，被使用。

当使用IMS APN/PDN连接时，RCS也能给定专有的QoS设置，而且使用和VoLTE相同的漫游规则，如不用回归属地，本地Break-out，如图6.

图6：当RCS和VoLTE客户端都使用IMS APN共享同一PDN连接时的承载示例

当RCS业务使用互联网（Internet）APN时，所有RCS流量要从缺省的Internet PDN连接中传送，除非网络触发的专用承载（NIDB）被使用，看图7.

如果缺省承载被使用，RCS流量使用和别的数据业务相同优先级的承载，即Best Effort，并且和别的数据业务流竞争资源和带宽。如果使用NIDB，RCS业务流能被分离出来到专用承载上，使用和传送在缺省承载上的别的数据业务不同的优先级。在这个“Internet”模式中，使用现有的漫游规则，当漫游时业务流总是回归归属地（Home Routing）。

图7：VoLTE使用IMS APN，RCS使用互联网（Internet）APN

RCS也能通过Wi-Fi接入。对于同时支持RCS和VoLTE的终端，RCS规范要求仅仅允许当VoLTE没有覆盖时Wi-Fi才能被使用。

然而，爱立信看到RCS规范框架之外的使用场景，实际上，终端被允许注册VoLTE同时，注册通过Wi-Fi接入的RCS.

图8：通过WiFi和LTE同时注册的场景

RCS和VoLTE共存时共用IMS Core

无论何种接入技术被使用，所有运营商控制的业务，如VoLTE和RCS总是由同一个IMS核心网（IMS Core）提供控制和服务。

IMS网络需要联合终端设备，支持通过移动网和Wi-Fi方式进行的鉴权和注册。依赖于设备的实现方式，相同用户/终端的这些IMS注册可以是仅仅VoLTE注册、仅仅RCS注册，或者为VoLTE和RCS的双注册。

使用不同PDN连接的RCS，或者RCS和VoLTE使用不同的IMS协议栈（IMS Stack），要求IMS网络处理同一个用户的双IMS注册和多个鉴权机制。

爱立信IMS网络从功能角度看没有限制去处理同一用户下的多个注册，前提是IMS协议栈使用不同的注册标识（即私有用户ID，IMPI），并且调优了注册刷新间隔，以便所需要的附加资源被保持在最小范围。

VoLTE基于存储在USIM/ISIM卡的信息使用IMS AKA鉴权机制，而RCS要使用不同的鉴权方法（如SIP Digest），其基于存储在终端设备上的鉴权数据，如用户名、密码和域名等。

当不同IMS协议栈被使用时，规范对VoLTE和RCS推荐不同的鉴权机制，有多个原因。

VoLTE使用基于USIM或ISIM的鉴权，即IMS AKA，但是不能保证下载的一个应用能够访问这些信息。最关键的限制是客户端标识，附带认证信息的私有用户标识仅仅允许只能在一个IMS注册中。如果VoLTE和RCS都访问USIM/ISIM信息，IMS网络认为来自两个IMS协议栈的注册请求其实是同一个IMS客户端，因而在给定的时间内，仅仅允许这些注册请求中的一个被激活。

爱立信对IMS核心网和应用层逻辑的实现方法保证了VoLTE和RCS被同等地提供服务，不管终端的实现机制是什么，和不管一个用户使用了多少个不同的终端。

爱立信IMS有能力去控制来自不同IMS协议栈或客户端的多个IMS注册，和多种鉴权机制。

爱立信IMS网络也能正确地根据IMS注册分发IMS业务流（如Forking/Hunting功能），减轻终端上的SIP信令的竞争条件（Race Condition）和被拒绝。IMS核心网通知PS核心网有特定业务在使用，依赖于业务类型和运营商的策略，以便正确的QoS规则能被使用在PS和无线（RAN）中。

因此，对于运营商不必等到终端厂家都达成一致，就可以提供和部署RCS和VoLTE业务。

欢迎光临 DIY编程器网 (http://diybcq.com/)