英语原文共 16 页，剩余内容已隐藏，支付完成后下载完整资料

附录A 译文

一种基于android的新型可扩展架构，以满足端到端音频视频终端的ims服务

摘要 IP多媒体子系统（IMS）以其突出的服务提供而闻名，它也为手持设备上的视频语音（VVOIP）等应用铺路。 Android是来自Google的软件平台，它在手持设备的中间件和应用领域开创中处于领先地位，但是它还未通过设计给IMS服务提供支撑。

受到这些观察的启发，我们提出了一种新的可扩展架构以便在Android上支持基于IMS的服务。首先，我们讨论几个相关工作来调查和分析IMS和IMS在其业务中的作用。其次，为了满足IMS服务我们讨论了与中间件子系统相关的android体系结构和细节限制的特征。因此，我们描述了提供基于IMS的服务时遇到的QoS，可扩展性和安全性等固有挑战的架构。架构框架设计通过使用包含三层的分层方法，即QoE引擎，高级IMS服务核心（A-IMS）和应用服务引擎（ASE）来减少部署时间。A-IMS主要负责为VOIP提供IMS端到端高效的服务。我们列举使用ASE、通用媒体管理和控制界面（GMMCI）的好处，以确保在不同配置的Android平台上快速移植。最后，我们详细介绍了未来IMS服务的一些使用案例，例如正在视频电话呼叫时进行视频分享或视频录制。

关键词 安卓；IP多媒体子系统；中间件；应用框架；无线网络

1.介绍

由POTS线组成的传统电话无法在终端支持服务并且完全依赖于网络组件。 相反随着终端（如IP电话）的计算能力和功耗的迅速发展，情报逐渐向网络边缘转移。SIP是一种应用层会话控制协议，其设计保持上述要求，在端点嵌入了大量的智能呼叫处理技术。一方面,SIP是电信行业背后的推动技术，是从基于TDM的电路交换基础设施转移到更加灵活并且以web为中心的数据包的IP电话网络。它的灵活性和开放性使其成为创建增强型服务（如语音和视频消息，会议和预付费电话）的关键组成部分。随着分组通信的日益普及，运营商正在向以语音为中心、语音通话的连接和以服务为中心的模式转变，专注于快速有效地向消费者提供创新服务^[1-2]，如图1所示尽管在下一代网络中如何实现服务提供还有许多挑战，但IMS和SIP作为一个组成部分，目前正在获得相当大的动力^[3-4]。另一方面，Android是Google开发的一款软件平台，用于迎接手持设备的中间件和应用程序，这正是由于其能够在资源有限的手持设备上为增值服务（VAS）提供吸引人的娱乐体验^[5]。 Android采用分组视频多媒体框架（PVMF）来满足媒体相关服务。PVMF有两个引擎：PV Player Engine和PV Author Engine。这些引擎旨在满足媒体播放和录制的基本功能，继承了适应性的一个主要挑战，以迎合VVOIP等高级VAS。 Android中间件子系统的这个缺点促使我们在Android上设计一个可扩展的稳健架构来提供各种基于IMS的服务。

图1 实时场景

在本文中，我们提出了新的可扩展软件架构，以适应Android上的基于IMS的服务。该架构通过使用“模块互连架构”设计来提供未来主义，以提供添加新功能所需的灵活性。分层方法在定义的引擎之间采用逻辑接口，以确保基于功能的解耦，便于携带。本文还提供了不同的建筑视图，如“元建筑”，“概念视图”和“逻辑视图”以便在此方向进一步研究。为了展示这种架构的评估，我们演示了一些常见的用户场景以及实施细则MSC（消息状态图）。 我们得出结论，通过提供各种用例与实际序列图来帮助用户采用这种架构。

2.设计方法

在本文中，我们设想提供Android系统架构的“大图”来应对IMS业务。我们在IMS中讨论有关信令和媒体流互动的几个概念。我们还详细介绍了Android的体系结构及其在这种系统中的使用。大部分研究工作探索了基于SIP的控制模型和交付模型的问题^[6]。根据这些研究观察结果所提出的体系结构体现了用于控制和管理信令的高级IMS核心（A-IMS核心）层。它还负责在成功的信号激活后平滑切换到媒体流分量。通过IMS中的一系列功能元素实现媒体服务，SIP的现实实施经验突显出了提供高效媒体传输（如语音质量，声学回声消除（AEC）等）的局限性。为了解决这个问题，我们提出的架构有一个专用的QoE引擎，与A-IMS服务核心和GMMCI进行交互，丰富了VVOIP等实时应用的用户体验。 android架构的设计有两个显着的优点：一是分层组件之间的通信在本质上是异步的，二是基于功能的层次分类为应用程序提供服务。这种架构设计目标是由我们架构的中间件组件（A-IMS，QoE Engine）来实现的。此外，Android架构基于不透明的IPC模型。应用程序以及服务项目将其功能公开给系统，并且在运行时，其他应用程序可以请求这些功能。基本上该平台提供了一个受管理和安全的晚期代码绑定。该模型在应用服务引擎和Android应用程序框架之间的交互中特别有用并且便于携带。第三部分说明了所提出的软件架构以及相关软件模块的简要描述和功能。

3.软件架构的建议

最近的研究表明，消费者对IMS服务使用的兴趣正在从面向用户转向面向群体的沟通。OEM正在趋向于为以媒体为中心的应用提供组合服务，例如手持设备上的视频会议^[7]。这些需要非常高的End-2-End高效媒体传输的应用仍然是资源受限设备的主要挑战。 根据下一代IMS服务目标所提出的架构（如图2所示）主要涵盖以媒体为中心的服务和扩展Android软件平台的应用程序，包括以下组件：

a.IMS应用：IP语音（VOIP）、IP视频语音（VVOIP）、视频分享等。

图2 软件体系结构的建议

b.高级IMS服务核心：IMS架构选择的SIP协议由于其有效的会话管理，在无线领域带来了新的挑战。因此，需要开发IMS架构来管理SIP和非SIP应用之间的交互。A-IMS服务核心提供功能来满足端到端VOIP等服务。

c.QoE引擎：对于不同类型的应用程序，主要负责发现关键参数（如带宽）的最优值。它负责提供诸如音频/视频同步、QoS管理、媒体管理、回声消除、噪声抑制和数据包处理器等核心QoS功能。

d.应用服务引擎（ASE）：应用服务引擎负责响应中间件发布的事件并与Android应用程序框架组件交互。 ASF对输入和外部事件做出反应，包括用户输入、IMS应用的连接和应用状态。

4.建筑设计方面

所提出的架构（如图3所示）集中关注QoE、松散耦合和可扩展性，这是影响整个系统提供关键IMS服务的三个参数^[8-9]。A-IMS服务核心和QoE主要负责处理IMS网络架构的复杂性，以提供更好的语音质量并减少语音延迟。另一个重点是端到端的安全性，我们的架构的移动安全引擎（MSE）符合这一要求。

图3 概念架构视图

4.1 QoE引擎

这是架构的核心强调需要为诸如VVOIP的实时应用程序提供更好的QoS，它由各种模块组成，提供诸如QoS、抖动缓冲区管理、数据包丢失和口令同步等关键功能。开发的每个应用程序都可以根据该应用程序的性质和用途连接到该层中的一个或多个模块。例如：VOIP应用程序连接到噪声抑制模块，以提供更好的语音质量。另一个应用程序如VVOIP可能会连接到所有三个模块（QoS、AV同步处理程序和网络丢包处理程序）。

QoS管理器：QoS管理器模块负责使用诸如实时控制协议（RTCP）之类的媒体协议来测量和监视QoS参数。RTCP-XR扩展了基本RTCP指标，包括的内容如下图所示：

1.延迟：最大容许延迟（ms）

2.抖动：最大容许抖动（ms）（延迟的变化）

3.Bandwidth：为数据包或流量保留的带宽

4.可接受率：最小可接受率（位/秒）

5.BER / FER：误码率（BER）或帧错误率（FER）

6.信号噪声等级

7.丢包率（在RX抖动缓冲区）

8.抖动缓冲区大小和配置

9.短暂、连续或持续的包装损失

该模块主要涉及通过在正在进行的多媒体会话中跟踪关键QoS参数来监视会话质量。QoS管理器的工作是将预定义的QoS属性存储在信息表中，监视和比较协商的QoS参数与实际情况，如果出现协商值的变化，则启动用户触发以了解当前值 QoS。

QoS管理器的设计方法：满足QoS要求的设计方法需要满足以下四个目标：

（1）目标1：最大化用户设备偏好

（2）目标2：最大化应用带宽

（3）目标3：最大程度减少抖动，延迟和损失

（4）目标4：最大限度地减少带宽波动

图4 QoS管理软件模块

（1）源或用户使用其最小/最大容差值来指定不同QoS参数的值。

（2）QoS参数及其各自的值在运行时间内提供给QoS管理器。

（3）如果QoS Manager第一次接收流数据包的QoS参数，则会根据其相对重要性对参数进行排序。之后QoS管理器调用特定功能来处理相对最重要的参数。而后需要适当的步骤来处理下一个比较重要的参数（如果可能的话），依此类推。

（4）然后根据其QoS规范和来源将信息传递给用户界面。如果源不满足所传递的分组的QoS，则向QoS管理器通知其希望在QoS中具有的改变。QoS管理器尝试相应地调整QoS参数。

图4所示的QoS管理功能实体包括：

（1）QMF（QoS测量功能）：QMF实体负责使用RTCP收集有关正在进行的媒体会话的QoS参数的所有信息，并将其传递给QCF（质量控制功能）。

（2）QCF（质量控制功能）：QCF实体从QMF接收信息，重新协商QoS参数，接收现有链路的QoS标准，将协商的QoS参数与同一链路进行比较，并检查现有的QoS标准服务是否满足。在这种案例中，用户指定了QoS参数的值，它们的最小值或最大值以及相对重要性和每个参数的公差限制。综上所述，QoS管理器根据其相对重要性对参数进行排序。QoS管理器与适当的模块（Stack Manager，ICF）连接来用于提供QoS。

抖动缓冲区：该模块主要负责在播放之前通过缓冲每个到达数据包的时间来消除流中抖动的影响。这也足以替代可能在接收端看到的额外的延迟或数据包丢失。固定的抖动缓冲器保持恒定的大小，而自适应抖动缓冲器具有动态调整其大小的能力，以优化延迟或丢弃权衡。固定和自适应抖动缓冲器都能够自动调整延迟的变化。自适应抖动缓冲器对丢弃事件或测量的抖动电平增加做出反应。当检测到丢弃事件时，抖动缓冲区大小增加，并且当没有丢弃事件时，缓冲区大小减小。

图5 抖动缓冲模块-接口图

网络包丢失处理程序：成功建立呼叫后，媒体数据通信以实时协议（RTP）格式发生。实现的实时控制协议（RTCP）协议提供周期性报告（RTCP-SR，RTCP-RR），其中详细介绍了正在进行的会话中丢包或损坏的数据包信息。如果任何媒体数据包丢失（可能被组件丢弃或从未达到），则该模块将采取如下适当的措施：

（1）如果是VOIP应用程序，任何由协议组件检测到或声明为丢失的音频数据包，它将为丢失的音频数据包插入静音帧。

（2）如果是VVOIP /视频共享，任何被检测到或声明丢失或迟到的视频帧将被丢弃，并且显示或渲染将呈现下一个相应的视频帧。

音频视频同步：该模块主要负责确保在同时呈现音频和视频流时同步。它与抖动缓冲区进行交互以获取数据。以下是实现同步的操作顺序，该模块不时地将视频时钟与当前音频时间同步，这确保渲染的视频总是与当前渲染的音频数据同步。通常音频用作参考时钟，然而该模块还具有赶上视频数据以及使音频时钟等待的能力。根据应用类型和QoS统计，在模块中使用适当的方法。

（1）音频渲染应为用于同步视频的主时钟，该时钟应来自在任何时间点播放的音频样本的数量。

（2）引擎根据在NAL接收到的音频数量来计算当前音频渲染时间。

（3）接收器/渲染器根据视频帧的渲染方式来维持自己的时钟。

接收侧视频渲染

本节描述了使用从每帧的RTP头信息中提取的呈现时间戳来渲染视频帧的逻辑，一旦解码第一帧就被渲染。此时的系统时间（Tr）作为参考时间。

（1）将Td作为后续解码帧可用的系统时间。

（2）令Tp为实例Td解码帧的呈现时间，这一次是相对于媒体时间单位的第一帧的时间戳。

（3）如果（Td - Tr）== Tp，立即呈现框架。

（4）如果（Td-Tr）lt;Tp，则为（Tr-Td-Te）设置定时器，其中Te是定时器触发的大致开销，在超时功能中，渲染帧不进行任何检查。

（5）如果（Td - Tr）gt; Tp，帧延迟显示，如果满足所有性能参数，则不应发生此情况。

发送侧视频帧时间戳生成

本节介绍用于嵌入到RTP头中的时间戳创建的逻辑。 基于帧捕获速率配置，每当帧可用于相机时计算帧时间戳。 对于第一帧时间戳应为0，对于后续帧令“F”以帧或秒为单位的捕获率。设Tr为帧时间戳并计算为（1 / F）times; 1000毫秒，则当前帧时间Tf

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[614002]，资料为PDF文档或Word文档，PDF文档可免费转换为Word