管理网络设备的制作方法

本发明涉及网络设备，尤其涉及用于管理用户终端之间的呼叫的网络设备。

背景技术：

通信系统可以包括连接到网络设备的多个用户终端。网络设备可以管理各个用户终端之间的呼叫。下文中，术语“管理网络设备”和“网络设备”可互换使用。

存在不同的编解码器来实施用户终端之间的通信。不同的编解码器提供不同的编码质量，也需要不同的计算功率。编解码器之一可以是增强语音服务evs编解码器。evs可以用于在gsma“用于语音和sms的ims简档(imsprofileforvoiceandsms)”ir.92中描述的超宽带和全带volte服务。相比于自适应多速率宽带amr-wb，evs的优势在于提高了话音和音频质量，并且扩展了音频带宽，对数据包丢失具有明显更高的鲁棒性。evs包括主模式和amr-wb互操作模式。在下文中，amr-wbio将用作amr-wb互操作模式的同义词，在使用rfc4867作为有效载荷格式的备选实现中，evsio将用作使用evs实时传输协议rtp有效载荷格式的amr-wb互操作模式的同义词。

evs主模式提供evs的整个话音和音频质量，以及对数据包丢失的鲁棒性，因此，如果两个用户终端/ue(用户设备)都支持evs，就应该选择这种模式。

然而，不能保证网络中的所有终端或ue都支持evs模式。因此，可能需要满足异构网络条件，同时保持参与终端的最佳音频质量和鲁棒性。

技术实现要素：

基于这些考虑，本发明的目标在于提供一种新的管理概念，其能够改进用户终端之间的通信技术，具有更高的鲁棒性和改进的话音和音频质量。

此目标通过独立权利要求的主题得以解决。优选实施例在从属权利要求中限定。

根据一个实施例，用于管理用户终端之间的呼叫的网络设备检查第一用户终端是否支持针对呼叫使用第一音频编码模式，以及第二用户终端是否打算针对该呼叫使用第二音频编码模式，如果第一用户终端支持针对该呼叫使用第一音频编码模式并且第二用户终端打算针对该呼叫使用第二音频编码模式，将从第一用户终端向第二用户终端发送的并且被打包到与第二音频编码模式有关的第一数据包中的该呼叫的第一数据重新打包到与第一音频编码模式有关的第二数据包中，以及将从第二用户终端向第一用户终端发送的并且被打包到与第二音频编码模式有关的第三数据包中的该呼叫的第二数据重新打包到与第一音频编码模式有关的第四数据包中。这样做的好处是，在具有例如evs和amr-wb终端的混合模式环境中，evs的能力可以得到最大程度的利用。

在又一实施例中，网络设备可以在第一和第二用户终端之间的呼叫建立期间执行该检查。

在又一实施例中，网络设备可以检查从发起用户终端向终止用户终端发送的第一初始呼叫邀约是否指示针对该呼叫使用第二音频编码模式，如果第一初始呼叫邀约指示针对该呼叫使用第二音频编码模式，拦截第一初始呼叫邀约并向终止用户终端转发第二初始呼叫邀约而不是第一初始呼叫邀约，第二初始呼叫邀约指示针对该呼叫使用第一音频编码模式，检查从终止用户终端向发起用户终端发送的对第二初始呼叫邀约的第一应答是否指示针对该呼叫使用第一音频编码模式，如果第一应答指示针对该呼叫使用第一音频编码模式，拦截第一应答并向发起用户终端转发第二应答而不是第一应答，第二应答指示针对该呼叫使用第二音频编码模式，以及断定终止用户终端支持针对该呼叫使用第一音频编码模式并且发起用户终端打算针对该呼叫使用第二音频编码模式，从而终止用户终端是第一用户终端，发起用户终端是第二用户终端。

在又一实施例中，从发起用户终端向终止用户终端发送的第一初始呼叫邀约可以从属地指示针对该呼叫使用第一音频编码模式。

在又一实施例中，如果第一应答指示针对呼叫使用第二音频编码模式，则网络设备可以向发起用户终端转发第一应答，第一应答指示针对该呼叫使用第二音频编码模式，以及断定第一用户终端和第二用户终端都不支持针对该呼叫使用第一音频编码模式。

在又一实施例中，网络设备可以检查第一应答是否指示使用第二音频编码模式，第一应答是响应于从发起用户终端向终止用户终端发送的第一初始呼叫邀约而从终止用户终端向发起用户终端发送的并且指示针对该呼叫使用第一音频编码模式所属的一个或多个音频编码模式的组中的任意一个音频编码模式，以及如果第一应答指示针对该呼叫使用第二音频编码模式，可以拦截第一应答并向发起用户终端转发第二应答而不是第一应答，其中第二应答指示针对该呼叫使用第一音频编码模式，以及断定发起用户终端支持针对该呼叫使用第一音频编码模式并且终止用户终端打算针对该呼叫使用第二音频编码模式，从而发起用户终端是第一用户终端，终止用户终端是第二用户终端。

在又一实施例中，从发起用户终端向终止用户终端发送的第一初始呼叫邀约可以至少从属地指示使用第一音频编码模式。

在另一实施例中，网络设备可以检查第一初始呼叫邀约是否指示使用第一音频编码模式，如果是，则可以拦截第一初始呼叫邀约(310)并转发第二初始呼叫邀约(320)而不是第一初始呼叫邀约(310)，第二初始呼叫邀约(320)指示使用多个音频编码模式，包括第一音频编码模式和第二音频编码模式。

在又一实施例中，第二音频编码模式可以是amr-wb，第一音频编码模式可以是evs的amr-wb互操作模式。

在又一实施例中，第二音频编码模式可以是使用用于amrwb的rtp格式的amr-wb，第一音频编码模式可以使用用于evs的rtp格式的evs的amr-wb互操作模式。

在又一实施例中，第一和第二音频编码格式可以使用同等的编码语法或使用同等可解析的有效载荷来表示音频内容，或它们无需转码而相互可转移。例如，无需转码可以指相互可转移而无需重新量化。

在又一实施例中，第一数据包和第二数据包可以在其有效载荷段的内容上一致，第三数据包和第四数据包可以除了可选的非转码操作之外在其有效载荷段的内容上一致。

在又一实施例中，除了在重新打包中可选的非转码操作外，网络设备可以在重新打包中不修改第一数据包和第三数据包的有效载荷段。

附图说明

下面将参考在附图中示出的实施例来描述本发明，附图中：

图1示出了根据本发明的实施例连接到用户终端的概念性网络设备；

图2示出根据本发明的实施例的用户设备之间的信令序列；以及

图3示出根据本发明另一实施例的用户设备之间的另一信令序列。

具体实施方式

如前所述，使用evs模式是有利的，因为它提供改进的音频质量和鲁棒性。在所有参与呼叫的终端(所谓的“呼叫支路”)都能够使用evs的情况下，evs将按预期使用。

在仅一个呼叫支路(calllegs)支持evs的情况下，例如一个ue以及可能还有它所连接的网络支持evs，而另一ue或其连接的网络不能支持evs并且仅支持amr-wb，则通过在支持evs的呼叫支路中使用evs仍然可以利用evs的提高的错误鲁棒性。

根据本申请的概念，强制在具有异构设备功能的网络中或者在具有不同编解码器功能的网络互连的情况下强制使用evs。。该技术依赖于sip网络节点中的sdp修改，此节点例如可以是ims中的cscf或atcf网络节点。

利用此技术，可以假设即使由于最初缺少支持evs的设备而无法实现端到端evs呼叫，但是随着在支持evs的终端上已经可以运行evs实现，因而加快了向高质量evs呼叫的迁移。

通过在evs呼叫支路中使用evs主模式并在网络中执行转码到amr-wb，可以促进此概念的实现。evs呼叫支路继而受益于上行链路和下行链路二者中卓越的错误鲁棒性。特别是在信道感知模式下，提高的evs错误鲁棒性允许放宽呼叫支路中的bler目标，这对应于改进的信噪比snr和室内/室外小区覆盖率。

而且，可以使用evsio模式并且可以在网络中执行重新打包。此重新打包过程已经在单无线语音呼叫连续性srvcc期间执行，其中在evsvolte到volte的呼叫期间，一个ue切换到cs网络并因此需要切换到amr-wb。在这种情况下，evs编解码器可以在切换网络之前和之后连续使用。编解码器可以从主模式切换到evsio模式以满足与两个网络的互操作性。这也使得在呼叫建立期间直接协商evsio模式的用例成为可能。在错误鲁棒性和音频质量方面，使用evsio而不是传统的amr-wb可能是有利的。

接下来，假设控制和用户平面中存在活跃网络节点，这些节点分析数据包并能够对其进行修改。缩写ims(ip多媒体子系统)将用作呼叫建立中所涉及的ims和演进包核心epc中所有网络节点的同义词。

如前所述，oue和tue可能不直接通信，而是经由可以管理该通信的ims。在协商了amr-wb(自适应多速率宽带)编解码器的情况下，则ue(例如oue和tue)可以将amr-wbio模式用作发送侧和/或接收侧的amr-wb的备选实现。这种行为对于传统amr-wb可能是有益的。由于使用或不使用amr-wbio实现amr-wb是由ue供应商自行决定的，因此运营商或ims网络不能强迫ue这样做。

下面提供一种技术，其中运营商或ims网络强迫支持evs的ue通过evsio模式来使用内置amr-wb互操作模式用于呼叫不支持evs的ue，例如代替传统的amr-wb。这可以通过在呼叫建立期间进行以下sdp修改来实现：

在第一类修改中，oue支持包括evs-io的evs，tue仅支持amr-wb。

在此第一类中，根据修改1a，当接收到tue对oue的初始邀约的应答时，ims知晓oue支持evs-io模式并且tue仅支持amr-wb。根据修改1b，imsi)在此应答及后续应答中以“按evsio模式开始evs”代替amr-wb，以及ii)在后续邀约中以amr-wb代替“按evsio模式开始evs”。

在第二类修改中，oue仅支持amr-wb，tue支持包括evs-io的evs。

在此第二类中，根据修改2a，当接收到来自oue的初始邀约(仅包含amr-wb)时，ims将“按evsio模式开始evs”添加到转发给tue的邀约中。

根据修改2b，如果tue利用“按evsio模式开始evs”进行应答，则ims知晓oue仅支持amr-wb，但是tue支持evsio模式。

根据修改2c，imsi)在此应答及后续应答中以amr-wb代替“按evsio模式开始evs”，以及ii)在后续邀约中以“按evsio模式开始evs”代替amr-wb。

例如，在具有两个终端ue1和ue2的系统中，可能出现这样的情况，ims知晓ue1仅支持amr-wb并且ue2支持evs，因此将amr-wb映射到evsio。

根据修改1a，如果应答包含amr-wb但不包含evs，且初始邀约包含evs，则ims网络将以“evs”代替“amr-wb”，特别是应答消息中的evsio能力。

根据修改1b，如果邀约包含amr-wb但不包含evs，且初始应答消息包含evs，则ims网络将以“evs”代替“amr-wb”，特别是邀约消息中的evsio能力。

根据修改2，可以探测tue对evsio的支持。在这种情况下，ims网络将evsio能力添加到呼叫邀约中，如果邀约包含amr-wb但不包含evs的话。ims“知晓”ue1支持evs，而ue2仅支持amr-wb，因此将evsio映射到amr-wb。

根据第三类修改，特别是针对修改3a，如果应答消息包含evsio而初始呼叫邀约不包含evs，则ims网络将在应答消息中使用amr-wb能力代替evsio。

进一步地，在第三类修改中，根据修改3b，如果呼叫邀约包含evsio而初始应答消息不包含evs，则ims网络将在呼叫邀约中使用amr-wb能力代替evsio。

邀约-应答期间的sdp修改以及sip命令的相关部分将在稍后根据图2和图3进行讨论。需要注意的是，消息序列被简化为编解码器协商相关消息。此外，为了提高可读性，还缩短了sdp消息。给出的两个示例是基于在“gsmafcm.01-volte服务描述和实现指南(2.0版本)”3.2节中讨论的单个pmn呼叫建立示例。进一步的信息可以在“3gpp26445的附件a3.3.3”中找到，其包含了sdp参数用法的详细描述，以及在“gsmair.92第2.4.3.3章”中找到，其描述了针对volte的evs特定的sdp限制。

所有修改都假定是在ims网络实例中实现的，这些实例已经对sdp消息进行了重整，例如，它们可以在p-cscf或其他ims网络实例中实现，诸如已经为srvcc提供的atcf(访问传输控制功能)。重新打包可以例如在媒体资源功能处理器(mrfp)(tbc.)或访问传输网关(atgw)中实现。

图1图示包括根据本发明的网络设备110的系统100。网络设备110检查第一用户终端120是否能够支持针对呼叫使用第一音频编码模式以及检查第二用户终端130是否打算针对该呼叫使用第二音频编码模式。在此实施例中，第一音频编码模式和第二音频编码模式可以不同，并且第一音频编码模式可以指evs，而第二音频编码模式可以指amr-wb。本领域技术人员很清楚，所提到的音频模式仅仅是示例，也可以包括不同的编码技术。

在第一用户终端120支持使用第一音频编码模式并且第二用户终端打算针对该呼叫使用第二音频编码模式的情况下，网络设备110将从第一用户终端120向第二用户终端130发送的被打包到与第二音频编码模式有关的第一数据包中的数据重新打包到与第一音频编码模式有关的第二数据包中。反之亦然，将从第二用户终端130向第一用户终端110发送的被打包到与第二音频编码模式有关的第三数据包中的该呼叫的第二数据重新打包到与第一音频编码模式有关的第四数据包中。

在包括网络设备110、第一用户终端120、第二用户终端130以及可能还有另一用户终端140的系统中，假设控制和用户平面中存在活跃网络节点，其中ims用作呼叫建立中所涉及的ims和epc中的所有网络节点的同义词。发起用户端点或用户设备对应于前面提到的oue，终止ue对应于前面提到的tue。

通常，oue发送和接收来自ims的数据，ims是该用户设备或用户终端所连接的ip多媒体子系统。同样，tue也连接到ims，因此oue和tue之间的通信是借助于ims。

当建立用于通信的编解码器时，并且在将使用amr-wb的情况下，ue可以将amr-wbio模式用作发送侧和/或接收侧的amr-wb的备选实现。如前所述，这种行为对于传统amr-wb可能是有益的，不过使用amr-wbio实现amr-wb是由ue供应商自行决定的，ims网络不能强迫ue这样做。

下面提供一种技术，其中运营商/ims网络强迫支持evs的ue通过evsio模式来使用内置amr-wb互操作模式用于呼叫不支持evs的ue，而不是amr-wb。这可以通过在呼叫建立期间前面讨论的sdp修改来实现。

当接收到tue对oue的初始邀约的应答时，ims知晓oue支持evs-io模式并且tue仅支持amr-wb。ims在此应答及后续应答中以“按evsio模式开始evs”代替amr-wb，以及在后续邀约中以amr-wb代替“按evsio模式开始evs”。

图1绘出了与两个用户终端120和130通信的网络设备110。如前所述，网络设备110检查终端是否打算针对呼叫使用特定音频编码模式。例如，网络设备110可以检查第一终端120是否打算使用与evs标准有关的音频编码模式以及第二用户终端130是否打算使用不同的音频编码模式，例如amr。

只要第一和第二用户终端打算使用共同的音频编码模式，通信就可以进行而无需进一步的努力。在第一用户终端120支持evs相关的音频编码模式(下文称为第一音频编码模式)并且第二用户终端打算使用amr相关的音频编码模式(下文称为第二音频编码模式)的情况下，网络设备110必须做出进一步的努力。更具体地，网络设备110将从第一用户终端120发送的数据从第一音频编码模式重新打包成第二音频编码模式，以及将从第二用户终端发送的数据从第二音频编码模式重新打包成第一音频编码模式。

通常，网络设备在呼叫建立期间执行有关各个用户终端打算使用哪个音频编码模式的检查。尽管如此，也不是必须在呼叫建立期间执行此检查，即使在呼叫已经建立之后也有可能执行此检查。这可能是这样的情况，其中有必要改变呼叫中使用的音频编码模式，例如以适应有限的带宽条件或关于用户终端的计算功率方面的考虑。

在呼叫建立期间已经执行检查的示例中，网络设备110检查从发起用户终端发送的第一初始呼叫邀约是否指示针对该呼叫打算使用第二音频编码模式，或者是否优选第一音频编码模式。在指示要使用第二音频编码模式的情况下，拦截第一初始呼叫邀约，代替地，向终止用户终端发送第二初始呼叫邀约，其中第二初始呼叫邀约指示针对该呼叫将使用第一音频编码模式。

类似地，网络设备110检查对第二初始呼叫邀约的应答是否指示针对该呼叫将使用第一音频编码模式，如果是，则拦截第一应答并向发起用户终端转发第二应答以代替第一应答，从而第二应答指示使用第二音频编码模式。此拦截和替换呼叫邀约及其应答确保了对于发起用户终端，看起来使用第二音频编码模式，对于终止用户终端，看起来针对呼叫使用第一音频编码模式。换言之，这断定了终止用户终端支持使用第一音频编码模式并且发起用户终端打算使用第二音频编码模式。

从发起用户终端向终止用户终端发送的第一初始呼叫邀约从属地指示针对该呼叫使用第一音频编码模式。

上文已经描述了当第一初始呼叫邀约指示使用第二音频编码模式时的情况，此后，讨论对该呼叫邀约的应答。如果第一应答指示针对将执行的呼叫使用第二音频编码模式，则向发起用户终端转发对该发起用户终端的第一应答，其中第一应答指示针对该呼叫使用第二音频编码模式。可以断定，第一用户终端和第二用户终端都不支持针对该呼叫使用第一音频编码模式。

在接收到响应于从发起用户终端到终止用户终端的第一初始呼叫邀约的来自终止用户终端的第一应答之后，可以检查第一应答是否指示使用第二音频编码模式，以及是否还指示针对该呼叫将使用第一音频编码模式所属的音频编码模式组中的任意一种音频编码模式。如果第一应答指示针对该呼叫使用第二音频编码模式，则拦截第一应答，代替地，向发起用户终端转发第二应答，其中第二应答指示针对该呼叫使用第一音频编码模式。进一步地，可以断定发起用户终端支持使用第一音频编码模式并且终止用户终端打算针对该呼叫使用第二音频编码模式。

在一个实施例中，第一初始呼叫邀约可以从属地指示使用第一音频编码模式。

在另一实施例中，网络设备可以检查从发起用户终端向终止用户终端发送的第一初始呼叫邀约是否指示使用第一音频编码模式，如果是，则可以拦截第一初始呼叫邀约，代替地，转发第二初始呼叫邀约，其中第二初始呼叫邀约指示使用多个音频编码模式，包括第一音频编码模式和第二音频编码模式。

显然，可以使用不同的音频编码模式，并且在一些实施例中，第二音频编码模式可以是amr-wb，第一音频编码模式可以是evs的amr-wb互操作模式。

在进一步的实施例中，第二音频编码模式可以是使用用于amrwb的rtp格式的amr-wb，第一音频编码模式可以是使用用于evs的rtp格式的evs的amr-wb互操作模式。尽管如此，本领域技术人员很清楚，当前讨论的发明不限于前面提到的音频编码模式，也可以用于其他音频编码模式。

关于音频编码模式，这些模式可以使用同等的编码语法或使用同等可解析有效载荷来表示音频内容，或它们相互可转移而无需转码。例如，无需转码可以指无需重新量化。

当传送以不同音频编码模式编码的数据时，此数据以数据包的形式传送。本领域技术人员知晓，一个数据包包含有效载荷段，涉及第一和第二音频数据的第一数据包和第二数据包在其有效载荷段的内容上一致。进一步地，对应于从第二用户终端用户向第一用户终端用户发送的数据的第三数据包和第四数据包可以在其有效载荷段的内容上一致，除了可选的非转码操作之外。

除了在重新打包期间可选的非转码操作外，网络设备可以配置成在重新打包期间不修改第一数据包和第三数据包的有效载荷段。

图2示出在支持evs和amr-wb的发起用户终端oue和支持使用amr-wb的终止用户终端tue之间的通信的信令序列示例。这些用户终端可以连接到如前所述的管理网络设备，管理网络设备能够使用evs和amr-wb二者通信并且能够在evs和amr-wb之间翻译/转换消息。此管理网络设备可以是ip多媒体子系统ims，如下面示例中所描述的。

在步骤210，从oue向ims发送sdp邀约。此消息指示evs和amr-wb二者都可以使用。在步骤220，该消息从ims转发到tue。在此消息中，仅提到amr-wb模式。步骤210和步骤220表示“sip邀请”消息。步骤210和220涉及检查400a，其中使用该呼叫邀约来检查终端是否支持使用第一和/或第二音频编码模式以及指示哪个音频编码模式用于该呼叫。

作为对sip邀请的响应，在步骤230从tue向ims发送消息，在此情况下是sdp应答，该消息为amr-wb格式。在步骤240，从ims向oue转发该消息，该消息已被转换成evs模式。步骤230和240表示“sip183‘进展’”消息。步骤230和240涉及检查400b，其中使用该sdp应答来检查指示哪个音频编码模式用于该呼叫。

在步骤250，使用evs模式从oue向ims发送sip邀约。步骤250涉及“sip更新”消息。在步骤260，使用amr-wb模式从ims向tue发送此sdp邀约消息。

在步骤270，使用amr-wb从tue向ims发送sdp应答消息。步骤270涉及“sip200‘ok’”消息。在步骤280，使用evs模式向oue转发此sdp应答消息。

在此实施例中，在oue上使用evsio，在tue上使用amr-wb。网络(在此由ims表示)可以执行重新打包以协助oue和tue之间的连接。此处，转码不是必需的。

进一步地，在此实施例中，应用前面提到的修改1a(ims网络通过用evs-io交换amr-wb来修改sdp应答)以及修改3b(ims网络用amr-wb交换evsio(在第二sdp邀约中))。

图3示出发起用户终端oue和终止用户终端tue之间的与结合图2示出和描述的类似的信令序列/信号流，不过在此示例中，oue支持amr-wb，tue支持evs和amr-wb。同样地，oue和tue可以连接到如前所述的管理网络设备，管理网络设备能够使用evs和amr-wb二者通信并且能够在evs和amr-wb之间翻译/转换消息。此管理网络设备可以是ip多媒体子系统ims。

在步骤310，以amr-wb模式从oue向ims发送“sdp邀约”。在步骤320，此sdp邀约从ims发送/转发到tue(在此示例中以evs模式)。步骤310和320可以涉及“sip邀请”。步骤310和320涉及检查400c，其中使用该呼叫邀约来检查终端是否支持使用第一和/或第二音频编码模式以及指示哪个音频编码模式用于该呼叫。

在步骤330，使用evs模式从tue向ims发送“sdp应答”。在步骤340，使用amr-wb模式从ims向oue转发该sdp应答。步骤330和340二者可以涉及“sip183‘进展’”消息。步骤330和340涉及检查400d，其中使用该sdp应答来检查指示哪个音频编码模式用于该呼叫。

在步骤350，使用amr-wb模式从oue向ims发送“sdp邀约”。步骤350可以涉及“sip更新”消息。在步骤360，使用evs模式从ims向终端ue转发此sdp邀约。

在步骤370，使用evs模式从tue向ims发送“sdp应答”消息。步骤370可以涉及“sip200‘ok’”消息。在步骤380，使用amr-wb模式从ims向oue转发步骤370的sdp应答。

在此实施例中，在tue上使用evsio，在oue上使用amr-wb。网络(在此由ims表示)可以执行重新打包以协助oue和tue之间的连接。此处同样，转码不是必需的。

进一步地，在此实施例中，应用前面提到的修改2(ims网络向sdp邀约添加evsio以针对evs探测tue(在初始sdp邀约中)、修改3a(ims网络用amr-wb交换evsio(在sdp应答中))以及修改1b(ims网络用evsio交换amr-wb(在第二sdp邀约中))。

尽管在装置的上下文中已经描述了一些方面，不过很清楚，这些方面也可以表示对对应方法的描述，其中框或设备对应于方法步骤或方法步骤的特征。类似地，在方法步骤的上下文中描述的各方面也表示对对应装置的对应框或项目或特征的描述。部分或全部方法步骤可以通过(或使用)硬件装置来执行，例如微处理器、可编程计算机或电子电路。在一些实施例中，一个或多个最重要的方法步骤可以通过这种装置来执行。

根据本发明编码的音频信号可以存储在数字存储介质中，或者可以在传输介质上传输，诸如无线传输介质或有线传输介质诸如互联网。

取决于一些实现要求，本发明的实施例可以在硬件或在软件中实现。可以使用数字存储介质来执行实现，例如软盘、dvd、蓝光盘、cd、rom、prom、eprom、eeprom或闪存，其上存储有电子可读控制信号，与可编程计算机系统协作(或能够协作)使得执行相应的方法。因此，数字存储介质可以是计算机可读的。

根据本发明的一些实施例包括具有电子可读控制信号的数据载体，其能够与可编程计算机系统协作使得执行本文描述的方法之一。

通常，本发明的实施例可以实施为带有程序代码的计算机程序产品，当计算机程序产品在计算机上运行时，程序代码可操作用于执行本文方法之一。程序代码例如可以存储在机器可读载体上。

其他实施例包括存储在机器可读载体上的、用于执行本文描述的方法之一的计算机程序。

换言之，本发明方法的实施例因此是计算机程序，其具有当计算机程序在计算机上运行时、用于执行本文描述的方法之一的程序代码。

本发明方法的又一实施例因此是一种数据载体(或数字存储介质或计算机可读介质)，包括其上记录的用于执行本文描述的方法之一的计算机程序。数据载体、数字存储介质或记录介质通常是有形的和/或非瞬态的。

本发明方法的又一实施例因此是一种数据流或信号序列，表示用于执行本文描述的方法之一的计算机程序。数据流或信号序列例如可以配置成经由数据通信连接进行传输，例如经由互联网。

又一实施例包括处理装置，例如计算机或可编程逻辑器件，其配置用于或适用于执行本文描述的方法之一。

又一实施包括计算机，其上安装有用于执行本文描述的方法之一的计算机程序。

根据本发明的又一实施例包括装置或系统，配置用于向接收方传送(例如，电的或光学的)用于执行本文描述的方法之一的计算机程序。接收方例如可以是计算机、移动设备、存储器设备等等。该装置或系统例如可以包括用于向接收方传送计算机程序的文件服务器。

在一些实施例中，可编程逻辑器件(例如现场可编程门阵列)可以用于执行本文描述的方法的部分或全部功能性。在一些实施例中，现场可编程门阵列可以与微处理器协作以便执行本文描述的方法之一。通常，方法优选通过任何硬件装置来执行。

本文所描述的装置可以使用硬件装置、或使用计算机、或使用硬件装置与计算机的组合来实施。

本文描述的装置、或本文描述的装置的任何组件，可以至少部分地在硬件和/或在软件中实施。

本文描述的方法可以使用硬件装置、或使用计算机、或使用硬件装置与计算机的组合来实施。

本文描述的方法、或本文描述的装置的任何组件，可以至少部分地通过硬件和/或通过软件来实施。

上述实施例仅仅是对本发明原理的示例说明。应当理解，对本文描述的布置和细节的修改和变化对于本领域技术人员而言将是显而易见的。因此，其意图仅受未决专利权利要求的范围的限制，而不受通过本文实施例的描述和解释所呈现的具体细节的限制。