|
以下例子描述了通过移动广播来开展流媒体服务的性能。图2描述了当多个移动电视用户通过单播的方式来同时观看三个不同信道的情景。在这情况下，每个用户都需要与服务器建立一条独立的流媒体链接，服务器和网络的负载则与用户数量成正比。在这个例子中，由于有10个移动电视用户，流媒体服务器必须处理10个流媒体链接。随着用户数量的不断增加，服务器负载将不断增加，同时核心网络和无线网络的均会产生大量的数据流量。
图3描述了通过MBMS来提供移动电视服务的相同情形。服务器对每个信道只需要传送一条流媒体连接到MBMSBM-SC。在有需要的时候，在核心和无线网络的数据流只有在需要的时候才被复制。在这个例子中,流媒体服务器只需要处理三个并发流媒体链接，因此，在最末端的无线节点使用三个并发传输会话就取代了原来的六个独立单播连接。注:：虽然例子是用于3GPPMBMS，它也适用於3GPP2BCMCS。
此外，MBMS和BCMCS除了支持流媒体发送之外，MBMS也支持下载。MBMS下载可以应用于有效地将文件从一个地点发送给多个接收者。MMS服务如果使用这个功能上获得很大的收益(例如提供精彩体育视频短片的传送服务)，而目前的MMS服务是使用点对点的技术进行发送的。将来，MMS子系统可以很方便地与BM-SC进行对接，从而使用MSMS下载来进行短片的发送。相对于MBMS而言，BMSCS并没有定义相关的协议来明确地支持文件下载服务。
通过MBMS的广播/组播器来进行文件的传送需要特别的注意。由于MBMS的广播和组播属于单向传输技术，因此不能使用需要双向单播连接的TCP协议。然而，IETF为文件传送提出了一个叫FLUTE（FileDeliveroverUndirectional Transport）的框架，FLUTE使用了在传输层以下的UDP协议。然而，由于UDP是不可靠的，FLUTE同时使用了前向纠错（FEC）框架来防止突发性的数据包丢失。但是，即使使用了FLUTE也不能保证经常出现的无错误递送，于是MBMS也提出了一个点对点的文件修复程序，该程序会在文件进行了广播或组播后执行。在此其间，接收者可以连接到文件修复服务器并请求数据。因此，MBMS总是能够保证可靠的文件传送。
典型的MBMS工作流程
图4展现了一个典型MBMS工作流程的多层参考模型。BCMCS的解决方案也是十分相似的,但是为了简单只是用MBMS命名。
一开始，特定的MBMS服务信息被发送到提供服务的服务器，这些信息一般作为服务通告。服务通告提供服务信息和终端的访问方法。发送MBMS服务通告给终端用户的方式有很多种，最简单的方法就是是将它们储存在一个WEB服务器，通过HTTP或WAP的方式进行下载。同时也可以通过现有的机制将服务通告发送到终端，如SMS或MMS，或者通过特定的MBMS服务通告信道来进行发送。
用户订购服务通告的服务后所发生的事情取决于该服务是广播或组播服务。广播服务不需更多的操作，终端根据服务通告的参数可以很简单地切换到相关信道。如果是组播服务，必须根据服务通告的参数向网络发起一个加入会话请求，用户终端就变成了MBMS服务组的一个成员，来接收服务发送的数据。
在传输开始之前，BM-SC一定要向在核心网络的GGSN发送一个会话开始请求。GGSN在内部分配请求和把该请求转发给相关的SGSNs。SGSNs依次序地请求能够保证服务质量(QOS)的无线资源的位置，最后，与该MBMS服务组相关的终端会被通知开始传送内容。
服务器开始传送多媒体数据给BMSC，该BMSC转发数据给MBMS运送者。数据被传送给参与MBMS会话的所有终端。
最后，服务器发送一个会话结束的通告表示数据传输完毕。
想离开MBMS组播服务的终端用户发送一个“服务离开”的请求给网络,网络就会将使用者从相应的MBMS服务组中脱离开来。
上一篇:曙光服务器搭建上海松江大学城解决方案
下一篇:向50毫秒恢复时间的共享型格形全光网演进
|
精品推荐