语音优化实现装置的制作方法

本申请要求于2014年7月30日提交的美国临时申请号62/030674的权益，该临时申请以引用方式全文并入本文。

技术领域

这些教导内容整体涉及使用互联网协议流来传送语音内容。

背景技术：

使用基于互联网协议(IP)的流来传送语音信息(例如，以支持蜂窝电话)包括现有技术努力的已知领域。因为基于IP的流是基于数据包的，并且还由于信号链中的各种动态变化，故以此方式传送的语音消息的质量可有所不同。因此，现有技术还探索了试图响应此类情况的方式。许多此类方法通常被视为属于所谓的移动语音优化。

在典型的现有技术应用程序设置中，移动语音优化触发器基于操作支持系统(OSS)生成的小区关键性能指标(KPI)以及从移动网络元件(NE)导出或驱动测试给定移动网络的计数器。不幸的是，OSS小区性能KPI和基于驱动测试的方法不是足够细粒度的、网络范围的、实时的或准实时的，并且固有地不可提供足以及时真正成功地触发语音优化的信息，因为移动网络中的语音质量往往是高度时间动态的并且通常是先前未检测到的小区拥塞的结果。在这种情况下，网络探头可更成功，但往往会产生非常高的相应成本，并且通常需要非常复杂和冗长的校准和部署工作以及调度。

此外，在由3G语音应用中的数据过载溢出到语音信道以及4G语音应用网络范围中的准实时的覆盖范围事件和容量事件所引起的无线电链路中的过度数据包错误的情况下，现有技术的移动语音优化触发器通常不能可靠地适当触发。此外，现有技术的移动语音优化触发器通常不能在基于IP的流之间实时地正确关联以便传送语音信息和OSS小区性能KPI来触发语音优化。

附图说明

通过提供以下具体实施方式中描述的语音优化实现装置来至少部分地满足上述需求，特别是当结合附图进行研究时，其中：

图1包括根据这些教导的各种实施例配置的流程图；

图2包括根据这些教导的各种实施例配置的框图；

图3包括根据这些教导的各种实施例配置的工艺流程图；

图4包括根据这些教导的各种实施例配置的示意性框图；

图5包括根据这些教导的各种实施例配置的流程图；以及

图6包括根据这些教导的各种实施例配置的流程图。

附图中的元件是为了简单和清楚而示出的，并且未必按比例绘制。例如，附图中一些元件的尺寸和/或相对定位可相对于其他元件被夸大，以便帮助提高对本教导的各种实施例的理解。另外，通常未描绘在商业上可行的实施例中有用或必要的常见但众所周知的元件，以便较少妨碍对本教导的这些各种实施例的观察。某些动作和/或步骤可能以特定发生顺序来描述或描绘，而本领域技术人员将理解实际上不需要顺序方面的这种特异性。本文使用的术语和表达具有如上所述的本技术领域技术人员赋予此类术语和表达的普通技术意义，除非在本文另外阐述具有不同的具体含义。

具体实施方式

一般来说，依据这些各种实施例，控制电路可操作地耦接到多个网络接口，并且至少基本上准实时地从多个移动通信(至少包括语音通信)接收互联网协议(IP)流内容和/或OSS小区性能KPI。控制电路分析该IP流内容和/或OSS小区性能KPI，以识别语音质量方面表现不佳的至少一个移动通信架构小区，并且进一步识别该移动通信架构小区所导致的性能不佳的至少一个原因。然后，控制电路启用针对该移动通信架构小区的语音优化。

在实施过程中，这些教导是高度灵活的，并且将与包括2G、3G、4G、GSM、UMTS、Wifi和LTE系统的多种系统兼容地服务。在所有这些情况下，单一类型的监测单元可以可靠且有效地用于检测语音优化触发器。

通过一种方法，上述IP流内容可包括以下一者或多者：通用分组无线业务(GPRS)传输协议(GTP)v1数据包、GTPv2数据包、Wi-Fi数据包、实时传输协议数据包和/或实时控制协议数据包。当IP流内容包括GTPv1数据包时，上述分析可包括分析IP流内容，以便识别对于每个目的地IP地址和/或小区ID具有顶级<X>业务数据卷的移动通信架构小区的GTPv1数据包。作为另一个示例性实例，当IP流内容包括GTPv2数据包和/或Wi-Fi IP数据包时，上述分析可包括分析IP流内容，以便识别关于实时传输协议间隔和丢包中至少一者具有最差<X>性能度量的移动通信架构小区。

通过一种方法，控制电路通过根据识别表现出最差性能度量的移动通信架构小区来形成对应的元数据消息，分析IP流内容以便识别表现不佳的移动通信架构小区。例如，当考虑采用GTPv1数据包的移动通信架构小区时，控制电路可形成基于GTPv1的元数据消息，然后将该元数据消息转换成卷、利用率和吞吐量平线度量中的至少一者。作为另一个实例，当考虑采用GTPv2数据包和/或Wi-Fi IP数据包的移动通信架构小区时，控制电路可形成基于GTPv2/Wi-Fi的元数据消息，然后将该元数据消息转换成实时传输协议间隔延迟、抖动、等待时间和实时传输协议数据包丢失度量中的至少一者。

通过一种方法，控制电路通过至少部分地使用至少一个OSS小区性能度量关键性能指标(KPI)来识别这种移动通信架构小区所导致的性能不佳的原因。示例性KPI包括但不限于误码率、干扰、可接入性和掉话率。

在实施过程中，这些教导是高度灵活的，并且将适应各种各样的应用程序设置和所关注的参数/指标。这种方法可易于适应处理大量数据，并且高度适合用于以至少准实时方式在移动系统中触发语音优化。因此，语音通信可得益于改善的质量，并且系统用户可具有显著改善的用户体验。

在彻底查看和研究以下具体实施方式之后，这些和其他益处可变得更清楚。现在参见附图，并且特别参见图1，现将呈现与这些教导中的许多教导兼容的示例性过程100。

出于示例性实例的目的，本文将假定所选择的控制电路执行此过程100。暂时参见图2，这种控制电路201可以可操作地耦接到多个网络接口202。因此，作为“电路”，控制电路201包括结构，该结构包括以有序方式传送电力的至少一个(并且通常许多)导电路径(诸如由导电金属(诸如铜或银)构成的路径)，其中该路径还将包括对应的电子部件(无源(诸如电阻器和电容器)及有源(诸如多种基于半导体的设备中的任一种))以便允许电路实现这些教导的控制方面。

这种控制电路201可包括固定目的的硬连线的硬件平台(包括但不限于专用集成电路(ASIC)(其为通过设计被定制用于特定使用而不是旨在用于通用使用的集成电路)、现场可编程门阵列(FPGA)等)，或者可包括部分或整体可编程的硬件平台(包括但不限于微控制器、微处理器等)。此类结构的这些体系结构选择是本领域中众所周知和理解的，并且不需要本文对其进行进一步描述。该控制电路201被配置(例如，通过使用本领域技术人员将很好理解的对应编程)为执行本文所述的步骤、动作和/或功能中的一者或多者。

通过一种方法，该控制电路201包括积分数字存储器。例如，该存储器可用于非瞬时性存储计算机指令，该计算机指令在由控制电路201执行时使得控制电路201如本文所述的运转。(如本文所用，对“非瞬时性”的这种引用将被理解为指存储内容的非临时状态(并且因此排除存储内容仅构成信号或波的情况)而不是存储介质本身的易失性，并且因此包括非易失性存储器(诸如只读存储器(ROM))以及易失性存储器(诸如可擦除可编程只读存储器(EPROM))两者。)

网络接口202可操作地耦接在移动通信网络内，以便接收如对应于多个语音传送移动通信的IP流和OSS小区性能KPI内容。这些网络接口202可包括：通用移动电信服务(UMTS)/高速数据包接入(HSPA)网络中的Gn、长期演进(LTE)网络中的S1和S11、在Wi-Fi情况下的Wi-Fi网关(GW)接口，以及用于网络元件(NE)生成的KPI的OSS接口。这些语音传送移动通信可以是来源于移动设备(诸如蜂窝电话或自动语音系统)的通信和/或被定向到目标移动设备的通信。这些教导将适应多种语音传送数据包，其包括但不限于通用分组无线业务(GPRS)传输协议(GTP)v1数据包、GTPv2数据包、Wi-Fi数据包、实时传输协议数据包和实时控制协议数据包。(通过基于数据包的协议传送数字化语音内容包括现有技术努力的很好理解的区域。由于本教导在这些方面中对任何特定方法的选择不是过于敏感的，所以为了简洁起见，本文不提供这些方面的进一步详细阐述)。

继续参见图1和图2，在框101处，控制电路201通过多个网络接口202从上述多个移动通信(至少基本上准实时地)接收IP流内容和/或OSS小区性能KPI。(如本文所用，表达“准实时”将被理解为对于IP流内容是指小于60秒的时间帧，并且对于OSS小区性能KPI是指15分钟或小于一小时的某个其他持续时间。)

在框102处，控制电路201分析上述IP流内容，以识别语音质量方面表现不佳的至少一个移动通信架构小区。为了帮助确保准确的结果，通过一种方法，此活动可包括识别并舍弃重复的IP流内容。

这种分析的具体方式可按需变化，以便适合给定应用程序设置的具体方式。例如，当IP流内容包括GTPv1数据包时，这种分析可至少部分地包括：识别对于每个目的地IP地址和/或小区ID具有顶级<X>业务数据卷的移动通信架构小区的GTPv1数据包。相反，当IP流内容包括GTPv2数据包和/或Wi-Fi IP数据包时，这种分析可至少部分地包括：识别关于实时传输协议(RTP)间隔和RTP丢包中至少一者具有最差<X>性能度量的移动通信架构小区的GTPv2数据包和/或Wi-Fi IP数据包中的任一者。

在任何情况下，上述分析可包括：识别关于延迟、掉话、数据包丢失、等待时间和抖动中至少一者具有最差<X>性能度量的移动通信架构小区。然后，这些教导还可包括：根据具有这样识别的带最差性能度量的移动通信架构小区而形成元数据消息。例如，在GTPv1数据包的情况下，控制电路201可根据识别具有最差性能度量的移动通信架构小区而形成基于GTPv1的元数据消息，并且随后将那些基于GTPv1的消息转换成卷、利用率或吞吐量平线度量中的至少一者。在GTPv2或Wi-Fi IP数据包的情况下，控制电路201可根据识别具有最差性能度量的移动通信架构小区而形成基于GTPv2/Wi-Fi的元数据消息，并且然后将那些基于GTPv2/Wi-Fi的消息转换成实时传输协议间隔延迟、抖动、等待时间或实时传输协议数据包丢失度量中的至少一者。

通过一种任选的方法，在框103处，该过程100将适应验证在这些方面表现不佳的移动通信架构小区。这种验证可包括例如利用参考数据以关联小区标识符和小区站点标识符，并且/或者记录Wi-Fi位置的最近的已知小区标识符。参考数据还可包括适于确定小区到小区距离的纬度和经度信息。这些教导将按需在这些方面中适应其他方法。

在框104处，控制电路201识别由识别的移动通信架构小区所导致的已检测的性能不佳的至少一个原因。通过一种方法，控制电路201至少部分地通过使用至少一个性能度量关键性能指标(KPI)来实现此结果。一般来说，这种性能度量KPI可包括误码率、干扰、可接入性和掉话率中的一者或多者。更具体地讲，但是不旨在这些方面中的任何具体限制，性能度量KPI可包括以下一者或多者：VoLTE呼叫掉话率、HARQ DURATION、切换(HO)执行故障率、上行链路接收信号强度指标(RSSI)以及切换执行故障保护时间。

在具体实施中，这些教导是高度灵活的、并且将适应识别多种不佳性能起因中的任一种。这些方面的实例包括但不限于：诸如低可接入性、上行链路(UL)接收信号强度指标(RSSI)降级、由于定时器到期的RRC连接故障、物理层故障、HO执行故障、高HO执行故障、HO执行保护故障、小区边缘覆盖和VoLTE小区边缘服务降级(略举数例)。

在框105处，控制电路201随后根据所识别的性能不佳原因来启用针对移动通信架构小区的语音优化。具体地讲，可启用适于解决性能不佳原因的特定种类的语音优化。对应于不佳性能起因的语音优化OSS参数通常是本领域中众所周知的，包括但不限于小区配置参数，诸如减少cellindividualoffsetEutran、增加“b2Threshold1Utra”、增加“P0NomPusch”和“P0NomPucch”、增加“t304IntraLte”(略举数例)。然而，这样配置的这种控制电路201允许以可靠且有效的方式、至少准实时地解决关于基于数据包的语音质量的性能不佳的特定动态和可能瞬时原因。

由于性能不佳的原因实际上可能只是瞬时的，所以框106处所示的，这些教导将任选地适应结束此类语音优化。该框106可包括例如控制电路201分析在启用语音优化之后的IP流和KPI，以便确定损害语音质量的事件何时减少。在检测到减少时，控制电路201可结束先前触发的语音优化。通过一种方法，例如，控制电路201在优化之前存储优化前的小区配置参数，并且在检测到上述减少时恢复到那些存储的优化前小区配置参数。

也存在语音优化的尝试可使已经受损的语音质量变差的可能性。在该情况下，此活动还可包括检测相关语音质量IP流和/或OSS KPI何时在优化之后降级，在该情况下控制电路201可恢复到所存储的优化前小区配置参数。

为了进一步说明前述教导，现将提供更具体的实施实例。应当理解，本实例的具体方式不旨在进行特定限制。

图3总体示出了按照该示例性实例的活动流程。IP流记录分析器部件301评估IP流和性能，并且在GTPv1数据包和/或RTP间隔的情况下将表示顶级业务的对应元数据发送到优化触发部件302，或者在GTPv2数据包和/或Wi-Fi数据包的情况下将丢包流发送到该优化触发部件。优化触发部件302接收那些元数据消息并且将消息转换成较差语音质量小区指标，确定对应的度量，将这些度量与一组预设置的优化目标进行比较，并且当超过目标阈值时触发对应小区站点以用于优化。在该实例中，工作流引擎303使用无线电接入网络(RAN)KPI来识别/验证较差语音质量的根本原因，并且做出关于如何优化目标小区的相应决定。

图4进而示出了具有被配置为在上述方面进行服务的网络架构的系统400的实例。图4所示的部件包括分接或镜像处理聚合点处的IP流接口，该IP流接口在UMTS/HSPA网络的情况下位于面向NodeB的无线电网络控制器(RNC)前面，在LTE网络的情况下位于面向eNodeB的服务网关(S/PDN)前面，并且/或者在Wi-Fi的情况下分接Wi-Fi网关与互联网之间的接口。IP流接口连接到IP流/性能KPI收集器，该IP流/性能KPI收集器与规则引擎一起确定最差<X>小区以便触发优化。优化引擎利用OSS接口来检索来自小区性能部件的OSS小区性能KPI、来自库存管理部件的参考数据，该库存管理部件提供例如小区ID信息、NodeB ID信息、eNodeB ID信息和对应的纬度/经度信息，并且利用允许检索参数信息和在小区级基础上能够改变或设置参数的OSS设置部件(其可包括例如配置管理接口)。

图5呈现了由上述系统400执行的过程500。

在框501和502处，收集并分析所关注的IP流和/或OSS小区性能KPI记录。从移动回程中和/或图4所示的骨干网络中的边缘路由器和/或核心路由器提供IP流记录。从图4所示的OSS部件检索OSS小区性能KPI记录。通过一种方法，初步分析确定这些收集的资料是否包括任何重复的IP流或OSS小区性能KPI记录。在此实例中舍弃重复记录。

在决策框503处，舍弃504与GTPv1、GPTv2或Wi-Fi无关的记录。在决策框505处，识别对于GTPv2的每个目的地IP地址(主机)和/或小区ID具有顶级<X>业务数据卷的小区的GTPv1IP流记录和/或具有顶级<X>RTP间隔和/或有损数据包的小区的Wi-Fi IP流记录，其中在方框504处舍弃任何剩余内容。

在决策框506处，该过程500提供使用关于最高延迟、掉话、数据包丢失和/或抖动具有最差<X>性能度量的IP流和/或OSS小区性能KPI记录来识别小区。在框504处舍弃剩余内容。

在框507处，基于小区和变换度量来过滤满足上述分析的IP流和/或OSS小区性能KPI内容。然后传送那些度量，其作为(例如使用Syslog)发送到上述优化触发器302的消息中的元数据。

优化触发器302接收前述消息，并且在框508处将那些度量转换成关键性能指标。例如，将基于GTPv1的消息转换成卷、利用率和/或吞吐量平线KPI，并且将基于GTPv2和Wi-Fi的消息转换成RTP间隔延迟、抖动和RTP数据包丢失KPI。例如，可通过将吞吐量除以小区容量来确定上述利用率。例如，可通过将丢失RTP数据包的秒数计数为可靠性KPI来确定上述RTP间隔延迟。RTP数据包间隔的公式的实例为：

并且例如，可通过对连续丢失的RTP数据包的数目进行计数并且将该数目用作语音质量KPI来确定上述RTP数据包丢失。例如，三个或四个连续丢失的RTP数据包可被视为消极语音质量KPI。RTP数据包间隔的公式的实例为：

在决策框509处，验证特定小区处的较差语音质量。这种验证可包括利用参考数据以关联小区ID与小区站点ID，或者利用Wi-Fi位置的最近的已知记录的小区ID。通过一种方法，验证IP流数据(诸如RTP数据包)的小区位置包括分析RTP流数据包和GTPv1消息两者，以便捕获用于确定位置的小区ID。一般来讲，这包括准实时地使基于IP流(诸如RTP流)的度量与OSS小区性能KPI相关，以便确定较差语音可靠性和质量，从而使小区有资格进行语音优化。

在框510处，该过程500提供确定小区语音质量是否在可接受的质量阈值以下。该活动还可包括识别构成所检测的不良性能的基础的根本原因。可至少部分地通过参见以上详细描述的OSS小区性能度量KPI来识别该根本原因。换句话讲，该步骤提供使用OSS小区性能度量KPI来确定小区语音质量是否在预定阈值以下，并且进一步识别引发该较差语音质量的一个或多个起因因素。

在框511处，该过程提供在进行语音优化之前存储现有的NodeB和/或eNodeB小区配置参数。然后，在框512处，通过基于先前确定的根本原因改变NodeB和/或eNodeB小区无线电资源管理(RRM)配置参数来启用语音优化。

在决策框513处，该过程提供确定语音质量IP流或对应的OSS小区性能度量KPI是否降级。换句话讲，优化语音的努力是否导致相反的结果。当为真时，在框514处，该过程500提供退回到小区的最后配置设置。

否则，在框515处，该过程将适应增加对配置的进一步改变，以便尝试进一步改善语音质量。

参见图6，推论过程600在框601处提供分析IP流(以及OSS小区性能KPI，如果需要)以便确定损害语音质量的起因事件是否已经减少。该分析可包括在框602处确定关于该输入数据与一个或多个所选择度量的相关性。可舍弃不相关的内容603。然而，在框604处，相关性可触发语音优化的减少。

在这样配置下，这些教导提供了一种优化触发器，该优化触发器可利用单一类型的监测系统以便为包括3G、Wi-Fi、4G以及甚至5G的多种电话技术检测较差语音质量小区站点。所公开的教导提供了一种语音优化触发器，在3G语音应用中的数据过载溢出到语音信道以及4G语音应用网络范围中的准实时的覆盖范围事件和容量事件所引起的无线电链路中的过度数据包错误的情况下，该语音优化触发器适当地触发。此外，所公开的教导提供了移动语音优化触发器，该移动语音优化触发器在基于IP的流之间实时地正确关联，以便传送适当触发移动语音优化的语音信息和OSS小区性能KPI。

此外，所公开的优化触发器可以可靠地检测较差语音质量小区站点，其仅利用与操作、管理和维护系统以及操作支持系统的有限交互，从而避免相当大的复杂性以及相应费用。本领域技术人员将理解，在不需要网络接口探头及其相应分析器而是依赖于相对简单的IP流记录分析器的情况下实现这些益处。还应理解，尽管这些教导利用了一些基本OSS小区性能KPI信息，但是所公开的方法减少了从不同类型的接口收集详细的OSS小区性能KPI信息的任何需要，从而避免支持这些接口的复杂性和成本，并且避免在相应供应商对接口和/或任何对应文件格式进行改变时采用KPI接口变化的任何需要。

本领域技术人员将认识到，在不脱离本发明范围的情况下，可对上述实施例进行各种修改、变更和组合，并且此类修改、变更和组合被视为在本发明构思的范畴内。