如何通过PLC网络传输电话语音？

传输速率不是传输电话语音时的主要问题，因为速率低到5.6kbit/s都可以，PLC网络支持这一速率还是绰绰有余的。

另一方面，因为电话应用是互动的，在信息由一个使用者发送，接收者接收的时候延迟一定不能超过300ms。如果它是一个对称网络，来回的最大时间一定不能超过300ms，因为这是人们可接受的最大时延数值。

当传输电话语音的时候，同步是第二个制约。信息必须在精确的时间内准确、有效地送达接收者。特别是源于数字化采样的字节必须在完全确定的同步时间内传送。例如，如果压缩生成了一个8kbit/s的流，这涉及每微秒同步。因此，1B的数据必须在1μs传送到接收者。如果语音没有压缩，一个64kbit/s的信道每125μs同步一次。

PLC电话的第三个主要特征是VoIP（基于IP的语音通信）技术的使用。语音字节在IP数据包中传递，并与传送其他应用程序的数据包同时使用网络资源。因此，基于PLC的电话通过IP融入了传统的IP语音（Speech over IP）的框架。

图6.1说明了远程电话方面的同步制约。尽管发送者有规律地发送数据包，但是它们是在不等的间隔内接收的。因此，想在精确时间传递语音字节，对于接收者是十分困难的。因为通过了PLC网络传输所以数据接收就没有规律，语音数据包将随机抵达。

图6.1 电话通信制约

接入方法是用来获得权限，从而将数据传送到接入点，CSMA/CA（载波侦听多路访问/冲突避免）机制随机使用PLC网络。除此之外，为了到达接收端，数据包必须通过更广泛的网络，并且随机通过中间传输节点。

语音打包和解包

假设语音被压缩成8kbit/s，这是基于IP环境的最通常的语音标准。

电话字节必须被打包成为IP包，为了在电力网络中传输，这个IP包封装至一个以太网帧，准确地讲，是将其封装如一个PLC帧，以便在电力网络上传输。

对于8kbit/s的速度，每1ms同步一次。如果N代表能在PLC中使用的字节数，那么整个打包时长^[1]为N个1ms。因为PLC帧的最小长度是64B，因此打包需要64ms。

解包工作是在打包工作进行的同时开展的，所以实际上并不需要额外的时间。这样一来，打包—解包需要的时间至少为64ms。事实上，现在的趋势是考虑打包—解包等待时间这一因素，增加对打包和解包耗时的预估。

64ms时间在150ms出口路径情况下是可接受的。然而，如果封包必须通过网络而不是PLC网络，或者如果打包—解包太慢，64ms这一数值就显得太高了。这就是为什么语音包仅为16B，且剩余的部分字节通过填充字节达到最小帧尺寸。对这16B的打包—解包时间大约仍保持在16ms。

实际速率

事实上，网络中的实际速率远远高于8kbit/s，因为数据封包有包头和填充字节之类的附加信息。我们认为使用IPv4标准并被封装成以太网帧，一个基于PLC网络或者其他封包传递网络的实际数据速度大约是60～70kbit/s。

如果使用IPv6标准，管理领域甚至更大，这时一个语音信道将会超过100kbit/s。

编码—解码器（简称编解码器）对模拟信号数字化的时间以及数字信号模拟化的时间大约为5ms。因此，编码、解码和打包—解包共需要26ms。总的可用传输时长将变成124ms（正如本节开始介绍的，最大传送时间是150ms，减去26ms各种各样的时间）。这个传输时长包含了MAC接入到PLC网络的部分。

转接时间

在PLC中，接入电力线介质所需要的等待时间可能会比较长。例如，如果5个客户通过使用1500B帧连接到相同的电力网络，并且整合有关的CSMA/CA接入时间，等待时间大约为10ms甚至更多。如果假定电话的接听者是连接到PLC网络的同一公司的另一位雇员，那么接入网络的时间还需要再增加大约10ms。

假定话务量高但是没有发生碰撞，那么总的转接时间仍然大约为100ms。这个转接时间使得在PLC网络上传输电话语音成为可能。

随着HomePlug AV标准及其竞争者的发展（由于当前这一代PLC不能管理优先级），其他用户的数据封包也有着同样的优先级，即便它们传送的数据不是最急需的。例如，一个客户工作在一个点对点（P2P）的应用上，并且正在续传一个几个GB的视频文件的数据封包可以在一个电话用户数据封包之前传播。这是为什么对当前的PLC技术需要采取强力措施制约用户数量或者空着总的话务量。下一代HomePlug AV的PLC将有能力管理电话和视频包的优先级，以确保基于该数据网络上的业务质量。

如果用户数量超过10，或者有用传输速率超过5Mbit/s，此时则不能保证利用HomePlug 1.0 PLC网络传输电话语音的可靠性，也就是达不到必要的服务质量（QoS）。在这种情况下，必须使用另一个技术对电话语音包指定优先权。

区分IP包

就目前来说，可以采用两种解决方案来区分PLC上通过的封包。

1）IP协议层的IP包控制技术。在这种情况下，PLC网络管理者（管理单元）在接收工作站，暂缓那些不具备优先级的封包的确认信息的传入，这样一来这些数据流将维持在一个低星级的状态，发送者只能发送少数几个封包，且必须等待进一步的传输确认。

2）使用HomePlug AV标准，该标准在2007年发布。这个标准在MAC层决定优先级。在这种情况下，给电话业务指派最高优先级是足够的。

第二种解决方案显然是最好的，因为它能应用在结构的最底层并且明显地有利于电话语音流。另一种解决方案更加智能一些，因为它包含优先级控制，不用去顾及具备优先级的语音客户的实际带宽要求。

图6.2示意性地给出了除了从一个终端到另一个终端的语音通信之外的PLC网络应用（及其相应组件），这些应用都在同样一个PLC网络中。

图6.2 通过PLC数字语音流连接的设备(www.xing528.com)

在通过输出PLC网络后，语音数据流在一个固定IP网络中传输，这个网络可能是一个运营商网络。然后，在进入传统的电话设施之前，通过一个专用网关（PABX IP）。这个网关把IP地址转换成电话地址，并且执行必要编码转换工作，转换成一个64kbit/s压缩数据的语音数据流。

Asterisk软件常用于创建一个IPBX（PABX），由它在服务层管理本地IP呼叫和流向STN（电话交换网）的呼叫。

高保真电话

PLC用来传送比传统电话语音更高质量的语音。事实上，因为PLC在传输速率上没有制约，所以提供较大的带宽从而传输高保真（Hi-Fi）语音或者近似高保真的语音。

假定你将512kbit/s的语音压缩成64kbit/s。传输64B的语音数据，只需要8ms。一般地，IP封包流的传输速率和以前相同，但是这个封包没有填充（pad-ding）字节，也就是说它仅仅包含有用字节。因此，以同样的实际传输速率就可以传输更高质量的语音。

不过，这一技术的应用并不广泛，其原因是电话机并不都兼容高保真语音信息。这一兼容性能通过使用一个有声卡的微机解决。不幸的是，这个解决方案被证明是不完善的，因为市场上的声卡速度非常慢并且要求大约50ms的处理时间。当不得不使用两个装置（发送者和接收者）时，传输时间是不可接受的。

无论如何，这一实例表明基于PLC的IP语音业务是具有更高质量的。

视频

视频是PLC网络的另一个应用，并且它在未来会大放异彩。这一应用特别需要在一个高传输速率的PLC环境下实现接入。

目前，（视频传输）时间上的制约或多或少都是存在的，这一问题是视频应用需要考虑的。下面主要研究两个场景，视频流和视频会议。

视频流

对于没有回传信道的视频流（譬如视频点播即VoD和电视），视频流从节目源发送到该视频显示在屏幕上需要耗费相当长的时间，这个时间长度大约为秒级，甚至达到15s。在观看者看到图像之前，他（她）没有必要关心视频源是否正常工作。

这些应用最主要的制约就是在视频开始前的等待时间。就算是在接收端重新进行同步，等待应用程序自我初始化的耗时也令人十分反感。数据流之所以在展示给用户之前停顿一下，是为了让接收机的内存中缓存足够的数据封包，以防用户在使用数据包时产生中断。图6.3说明了这种制约。

视频可为数字化的模拟信号（被压缩）或者来自经压缩的数字信号。这些信号被大大压缩，且需要更高的传输速率。传输速率的具体数值取决于网络的能力以及发送端和接收端的计算能力。

传输速率越高并且压缩率越小，图像质量就越好。在传送视频图像中，对传输速率的要求是一个重要因素。只要网络不饱和，这个因素不是PLC网络的主要问题。让我们首先分析传输一个视频信道的必要传输速率。

图6.3 PLC网络上的视频应用

传送视频的必要的传输速率

视频设备主要使用最新的MPEG标准，DVB（数字视频广播）也已经被广泛应用。

MPEG使用了帧内和帧间压缩算法。其传输速率可以降至1.5Mbit/s，并且与原始图像相比，压缩质量损失很小。采用大约4Mbit/s传输速率的MPEG-2技术改善了图像质量。条件允许的话，可以考虑采用MPEG-4标准，应用更高的压缩比，并且增加用于在另一端重现图像的必要的某些元素。

广播电视传播的难点在于其传输速率并不固定，并且必须进行自行调整以适应传输网络。根据时间和介质中可用的资源，算法或多或少要压缩信息。如果网络几乎完全可用，图像质量能够提高不少。反之，若网络被来自于不同数据源的其他混合信息所充斥，就必须考虑降低视频传输的等级，当然这必须满足用户端的QoS需求。为了充分优化该应用传输，必须有一个控制机制。

为了满足使用者的节目质量的需求，高清数字电视（HDDTV）大约需要5～10Mbit/s的传输速率。5Mbit/s传输速率太大了，对HomePlug 1.0和Turbo网络而言，支持这样的速率存在困难。如果使用HomePlug AV（40Mbit/s），同时只能有两个用户能使用这项服务。

虽然HDDTV可以在PLC网络上传输，但是最大用户数量不能超过10个。

传输负荷（能力）问题

PLC网络必须有能力提供连接，使视频应用使用最优传输速率，这个传输速率能确保一个可接受的服务质量。

我们首先看一下负荷量问题带来的困难。对电话语音没有问题，是语音因为一旦被压缩，其数据流的传输速率是8kbit/s，甚至是5.6kbit/s。与此相对，对一个MPEG-2电视质量图像而言，负荷量要求在2～8Mbit/s之间。对MPEG-4，这一要求下降到1Mbit/s。也就是说，不管怎么样，当前对能力的要求都在2Mbit/s左右。如果通过降低视频的质量，那么这个值有望下降至几百kbit/s。

对视频的播放质量，如果HomePlug 1.0网络的传输速率不足，那么HomePlug Turbo网络或者HomePlug AV网络的传输速率应该满足。因为对后两种网络而言，其提供的有用传输速率大约是10Mbit/s和40Mbit/s，这一数值已经粗略地估计了自己的数据流和其他应网络应用的数据流。

与语音传输类似，可以采用优先级分类技术，给数据流的传输定义较高的优先级。在这种情况下，通过使用HomePlug Turbo和AV网络就不会在有传输速率的问题。

如果网络负荷容量充足，且用户的数目远远小于所需的负荷量，或者实施优先级分类，那么要解决第二个问题就是关注对字节再同步导致的延迟的处理。这就是为什么延时大约是几秒，甚至是几十秒也是必要的。这种情况下，一旦视频流的开始使用时，最初的图像只有在这个延迟之后才出现。