CN100544462C - 一种提供组播承载的方法与系统 - Google Patents

Abstract

本发明公开了一种提供组播承载的方法，在网络侧和UE侧之间建立用于传输组播数据的逻辑信道，并在网络侧和UE侧设置缺省的组播无线承载参数，当UE请求组播流媒体业务时，网络侧向请求组播流媒体业务的UE发送携带RAB标识的RRC状态转换命令；UE侧收到所述命令后，将自身状态转换为公共信道状态，且根据所设置的缺省的组播无线承载参数建立组播无线承载；网络侧将组播数据承载在所建立的逻辑信道，并映射在公共信道传输至UE侧；UE侧从公共信道中接收承载在所建立的逻辑信道的组播数据。本发明还公开一种提供组播承载的系统。根据本发明公开的方法和系统对现有单播流媒体业务的信道映射结构进行较少的修改，实现组播流媒体业务。

Description

一种提供组播承载的方法与系统

技术领域

本发明涉及组播技术，特别是指一种提供组播承载的方法与系统。

背景技术

无线链路控制(RLC)协议在空口上实现数据传输的模式分为透明模式(TM)、非确认模式(UM)和确认模式(AM)三种工作模式。在透明模式和非确认模式中，有一个发送实体和一个接收实体，确认模式只有一个发送和接收结合的实体。在透明模式下，RLC发送实体对上层数据不进行任何处理，直接通过逻辑信道传输至RLC接收实体。在非确认模式下，RLC发送实体接收上层数据，对该数据进行分段级联成若干个数据块，对每个数据块分别加上连续的序列号，通过逻辑信道传输至RLC接收实体；RLC接收实体接收来自逻辑信道的数据块，对所接收到的数据块进行解分段级联，恢复上层数据，提交给上层，接收实体还可以根据所接收到的数据块的序列号的连续与否，检测出在传输过程中数据是否丢失。在确认模式下，除了实现以上所述非确认模式的功能以外，RLC接收实体还通过反向信道向RLC发送实体指示对应哪些序列号的数据块没有正确接收，并要求RLC发送实体重新发送对应序列号的数据块，保证数据的可靠传输。

在无线资源控制(RRC)协议中，RRC实体控制用户设备(UE)在专用信道状态和公共信道状态之间转换。图1为RRC状态转换的示意图，如图1所示，网络侧的RRC实体给UE侧的RRC实体发送RRC状态转换命令消息，消息中指示UE需要转移的目标状态，UE侧的RRC实体接收到该消息后，转移到对应的目标状态，并给网络侧的RRC实体返回RRC状态完成响应。

公共信道上行为随机接入信道(RACH)，下行为前向接入信道(FACH)，当UE处于公共信道状态时，多个UE共享一条公共信道。网络侧为各UE分配不同的小区无线网络临时标识(C-RNTI)，使得各UE的数据块在一个FACH信道上传输时，网络侧在每个数据块的头部加上该UE的C-RNTI，该UE接收公共信道上的所有数据块后，通过数据块中的C-RNTI区分各个数据块是否发给本UE。

图2为单播流媒体业务发起阶段的信道映射关系示意图，图2中包括UE A和UE B发起单播业务时的信道映射关系，分别如图2中A和B所示。图3为单播流媒体业务接收阶段的信道映射关系示意图，图3中包括UE A和UE B接收单播业务时的信道映射关系，分别如图3中A和B所示。

图2和图3所示的信道映射结构包括：网络侧和UE侧，网络侧和UE侧分别包括业务层和传输层，其中，业务层包括流媒体控制面，传输层包括RRC实体、RLC实体以及逻辑信道，在网络侧和UE侧之间包括UE的专用通道。在图3中业务层还进一步包括流媒体用户面。

其中，业务层的网络业务接入点和传输层的无线接入承载之间存在对应的关系。流媒体控制面实体和流媒体用户面实体使用相同的网络业务接入点，且在同一个无线承载上传输单播数据。流媒体控制面实体进行双向的数据传输，流媒体用户面实体进行下行单向数据传输。RLC实体提供无线承载的功能，单播数据通过RLC实体在逻辑信道上传输，而专用通道上可以承载不同的逻辑信道。在UE的专用通道上传输的数据块头部包含逻辑信道标识，逻辑信道标识用于区分不同的逻辑信道，实现多个逻辑信道复用到一个专用通道上。逻辑信道标识的定义如表1所示，共有四个比特，取值分别为0到15，其中，0到14用于表示逻辑信道1到逻辑信道15，15保留还未使用。

 

逻辑信道标识	表示
		0000	逻辑信道1
0001	逻辑信道2
		...	...
1110	逻辑信道15
		1111	保留

表1

在图2和图3中，逻辑信道1用于传输RRC的消息，逻辑信道2用于传输流媒体业务数据。

图2和图3所示UE A和UE B分别有自己专用的通道，当UE处于专用信道状态时用专用信道区分不同通道，当UE处于公共信道状态时用公共信道上传输的业务数据中C-RNTI区分不同通道。

随着通信业务的不断发展，单播业务和组播业务并存，因此希望在不改动以上所述的实现单播传输时的信道映射关系的情况下，能够实现组播承载。

现有技术中，在不改动以上所述的实现单播传输时的信道映射关系的情况下，实现组播流媒体业务时，组播流媒体业务发起阶段的信道映射关系同图2所示映射关系，而组播流媒体业务接收阶段的信道映射关系如图4所示。

图4包括UE A和UE B，各UE有自己专用的通道，且UE处于公共信道状态，UE接收组播数据时，双向逻辑信道使用UM模式，且网络侧发送的组播数据通过下行逻辑信道传输至UE侧。图4所示的在单播承载的基础上，实现组播承载时，具有以下几个特点：

(1)下行逻辑信道用于承载下行组播数据，不再用于承载下行单播数据。下行单播数据和下行组播数据不能通过同一个下行逻辑信道传输的原因是：下行组播数据为一个小区内各组播UE共享，有独自的数据分段级联和添加序列号的特性，如果在其中再加上单个UE的下行单播数据，将打乱RLC接收实体的解分段级联功能，导致该UE的下行单播数据和组播数据都不能正常接收。因此，当实现组播传输时，下行单播数据不能通过下行逻辑信道传输到UE侧，即，下行单播通道被中断。

(2)下行组播数据采用RLC的非确认模式传输，即网络侧UM RLC发送实体将下行组播数据承载在逻辑信道中，发送给UE侧UM RLC接收实体。因为，如果下行组播数据采用RLC的确认模式，各UE侧的RLC实体接收到下行组播数据后，都向网络侧的RLC实体反馈组播数据的接收状态，导致网络侧的RLC实体的处理很复杂，且很容易出问题。但是，如果下行组播数据的传输采用RLC的非确认模式，则上行单播数据的传输也采用非确认模式，因此导致上行单播数据的传输不太可靠。

(3)当需要实现组播传输时，在空中接口上不需要对组播数据加密，且UE侧也不需要启动加密功能。因为，正常情况下，单播传输时，单播数据在空口上一般是加密的，每个UE有自己特定的加密密钥，并且现有协议中加密过程在一次连接过程一旦启动就无法停止。但是，下行组播数据需要发给多个UE，因此不能在空口加密，需要实现组播业务的UE在连接建立时就不能启动加密功能。

综上所述，现有技术方案中，在现有的承载单播的信道映射结构中实现组播承载，存在以下几个缺点，总结如下：在实现组播承载时由于下行逻辑信道只用于传输下行组播数据，因此在传输组播数据时下行单播数据的传输信道被中断；在实现组播承载时由于采用RLC的非确认模式，因此导致上行单播数据不能可靠传输；在实现组播承载时，由于在空口上对下行组播数据不进行加密，因此希望启动组播业务的UE在连接建立时就不能启动加密功能。

发明内容

有鉴于此，本发明的主要目的在于提供一种提供组播承载的方法，对现有单播流媒体业务的信道映射结构进行较少的修改，实现组播流媒体业务。

本发明的另一个主要目的在于提供一种提供组播承载的系统，对现有单播流媒体业务的信道映射结构进行较少的修改，实现组播流媒体业务。

为了达到上述目的，本发明提供一种提供组播承载的方法，在网络侧和用户设备UE侧之间建立逻辑信道标识为15的逻辑信道，用于传输组播数据，并在网络侧和UE侧设置缺省的组播无线承载参数，网络侧进一步针对每一个组播流媒体业务分配组无线网络临时标识G-RNTI，该方法包括：

当UE请求组播流媒体业务时，网络侧根据所述UE所请求的组播流媒体业务的对应的G-RNTI，判断所述UE的小区无线网络临时标识C-RNTI是否属于所述G-RNTI所表示的组播组，如果不是，则重新给UE分配属于所述组播组的C-RNTI；网络侧向请求组播流媒体业务的UE发送无线资源控制RRC状态转换命令，该命令携带无线接入承载RAB标识；UE侧收到所述RRC状态转换命令后，将自身状态转换为公共信道状态，且根据所设置的缺省的组播无线承载参数建立组播无线承载；

网络侧将组播数据承载在所建立的逻辑信道，并映射在公共信道传输至UE侧，且在传输时，媒体接入控制MAC协议数据单元PDU中携带UE所请求的组播流媒体业务对应的G-RNTI；UE侧从公共信道中接收承载在所建立的逻辑信道的组播数据，在MAC PDU中获取G-RNTI，并判断与自身C-RNTI是否属于相同组播组，如果是，则接收对应的组播数据，并将组播数据通过所述RRC状态转换命令中携带的RAB标识所对应的网络业务接入点NSAPI转发给上层应用，否则丢弃该数据。

所述RAB标识对应的RAB为UE请求组播流媒体业务时所使用的RAB。

所述判断UE的C-RNTI是否属于G-RNTI所表示的组播组为：从C-RNTI与G-RNTI中分别获取组标识Group-Id，并比较所获取的C-RNTI与G-RNTI中Group-Id是否相同。

所述设置缺省的组播无线承载参数为：设置组播数据传输模式为UM模式；

网络侧设置UM RLC实体，所述UM RLC实体将组播数据承载在所建立的逻辑信道，并映射在公共信道传输至UE侧；

UE侧设置UM RLC实体，所述UM RLC实体从公共信道中接收承载在所建立的逻辑信道的组播数据。

所述设置缺省的组播无线承载参数为：设置不启用加密功能；

网络侧发送组播数据时，在空口上对组播数据不进行加密；

UE侧接收所述组播数据时，对组播数据不进行解密。

所述UE侧收到RRC状态转换命令后，进一步包括：向网络侧返回RRC状态转换完成响应。

该方法进一步包括：保持UE请求组播流媒体业务时所使用的专用逻辑信道。

为了实现上述目的，本发明提供另一种提供组播承载的方法，在网络侧和用户设备UE侧之间建立多媒体广播多播业务信道MTCH，用于传输组播数据；该方法包括：

当UE请求组播流媒体业务时，网络侧向请求组播流媒体业务的UE发送无线资源控制RRC状态转换命令，该命令携带无线接入承载RAB标识和多媒体广播多播业务标识MBMS-Id，所述MBMS-Id的值为UE所请求的组播流媒体业务的MBMS-Id；UE侧收到所述RRC状态转换命令后，将自身状态转换为公共信道状态，且根据所设置的缺省的组播无线承载参数建立组播无线承载；

网络侧将承载组播数据的MTCH的MBMS-Id设置为UE所请求的组播流媒体业务的MBMS-Id；并将组播数据承载在MTCH上，并映射在公共信道传输至UE侧；UE侧从承载组播数据的MTCH中获取MBMS-Id，并判断与所述RRC状态转换命令中携带的MBMS-Id是否相同，如果是，则接收对应的组播流媒体业务数据，并将组播数据通过所述RRC状态转换命令中携带的RAB标识所对应的网络业务接入点NSAPI转发给上层应用，否则丢弃该数据。

所述RAB标识对应的RAB为UE请求组播流媒体业务时所使用的RAB。

所述设置缺省的组播无线承载参数为：设置组播数据传输模式为UM模式；

网络侧设置UM RLC实体，所述UM RLC实体将组播数据承载在所建立的逻辑信道，并映射在公共信道传输至UE侧；

UE侧设置UM RLC实体，所述UM RLC实体从公共信道中接收承载在所建立的逻辑信道的组播数据。

所述设置缺省的组播无线承载参数为：设置不启用加密功能；

网络侧发送组播数据时，在空口上对组播数据不进行加密；

UE侧接收所述组播数据时，对组播数据不进行解密。

所述UE侧收到RRC状态转换命令后，进一步包括：向网络侧返回RRC状态转换完成响应。

该方法进一步包括：保持UE请求组播流媒体业务时所使用的专用逻辑信道。

为了达到上述第二个目的，本发明提供一种提供组播承载的系统，包括网络侧和UE侧、以及网络侧和UE侧之间的用于承载单播数据的逻辑信道，其特征在于，该系统进一步包括：网络侧和UE侧之间的用于承载组播数据的逻辑信道。

所述网络侧和UE侧分别包括RRC实体和RLC实体；

所述网络侧进一步包括：用于发送组播数据的UM RLC发送实体；

所述UE侧进一步包括：用于接收组播数据的UM RLC接收实体。

网络侧RRC实体，用于根据组播流媒体业务标识对应的由网络侧分配的G-RNTI，为UE分配属于该G-RNTI组播组的C-RNTI，用于向UE侧发送携带无线接入承载标识的RRC状态转换命令；

UE侧RRC实体，用于根据网络侧的RRC状态转换命令，将自身状态转换为公共信道状态，且根据无线接入承载标识建立组播承载，接收组播流媒体数据。

本发明提供的方法和系统，在现有存在的单播承载的信道映射结构的基础上，增加用于承载组播数据的逻辑信道，且通过预先设置组播无线承载参数实现组播承载，存在以下几个有益效果：

1)通过现有存在的单播承载的信道映射结构仍能够实现上/下行单播数据的传输；

2)对于单播业务和组播业务能够分别启动和禁用加密功能；

3)现有存在的单播承载的信道映射结构可以使用确认模式的单播数据传输，因此能够保证上行单播数据的传输可靠性；

4)现有存在的单播承载的信道映射结构还可以使用非确认模式，以及透明模式的单播数据传输，同时可以在非确认模式以及透明模式的单播承载的信道映射结构的基础上实现组播承载，对现有实现单播承载的信道映射结构改动很小甚至没有。

附图说明

图1所示为现有技术中RRC状态转换的示意图；

图2所示为现有技术中单播流媒体业务发起阶段的信道映射关系示意图；

图3所示为现有技术中单播流媒体业务接收阶段的信道映射关系示意图；

图4所示为现有技术中组播流媒体业务接收阶段的信道映射示意图；

图5所示为本发明第一实施例中使用逻辑信道标识为15的专用逻辑信道的组播流媒体业务接收阶段的信道映射关系示意图；

图6所示为本发明第二实施例中使用MTCH的组播流媒体业务接收阶段的信道映射关系示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面举具体实施例，对本发明作进一步详细的说明。

本发明中提供组播承载的总体思路是：在现有的单播承载的基础上，增加用于传输组播数据的逻辑信道，并给组播无线承载参数设置缺省参数；当网络侧确定UE侧请求组播业务后，向UE侧发起RRC状态转移过程，然后按照所设置的组播无线承载缺省参数，将组播数据承载在所增加的逻辑信道发送给UE侧；UE侧按照所设置的组播无线承载缺省参数，接收所述组播数据。

实施例一：使用逻辑信道标识为15的专用逻辑信道的组播承载方案

图5为使用逻辑信道标识为15的专用逻辑信道的组播流媒体业务接收阶段的信道映射关系示意图，如图5所示，所述信道映射关系包括图3所示单播流媒体业务接收阶段时信道映射结构之外，进一步包括：用于传输组播数据的逻辑信道标识为15的逻辑信道，提供组播无线承载的RLC实体，承载逻辑信道的组播通道。

为了实现组播流媒体业务，在现有的单播承载系统的基础上，在网络侧和UE侧之间增加组播通道，所增加的组播通道用于承载传输组播数据的逻辑信道，而且为了区分承载不同组播数据的组播通道，针对在组播通道中传输的MAC协议数据单元(PDU)中UE标识扩展设置组无线网络临时标识

(G-RNTI)，G-RNTI是网络侧针对每一个不同业务分配的用于区分不同多播业务的参数，即G-RNTI与组播流媒体业务标识一一对应。其中，所设置的G-RNTI结构中包含用于区分不同组播组的组标识(Group-Id)。

用于传输组播数据的逻辑信道的逻辑信道标识配置为预留的逻辑信道标识15。

组播无线承载参数采用预先设置的缺省参数，所述预先设置的缺省参数是指：组播数据传输模式采用UM模式，即RLC实体采用UM模式；组播数据传输时不启动空口加密功能，即网络侧在空口对所发送的组播数据不进行加密，UE侧对接收到的组播数据不进行解密。

设置组播无线承载与传输流媒体控制面的网络业务接入点(NSAPI)即无线接入承载(RAB)相对应。

在图5所示的组播承载系统中，实现组播承载的方法如下所述：

步骤101：在业务发起阶段完成后，网络侧业务层的流媒体控制面实体确定UE需要发起组播流媒体业务，通知网络侧传输层的RRC实体，通知消息中包含组播流媒体业务标识。

步骤102：网络侧传输层的RRC实体根据组播流媒体业务标识对应的G-RNTI，判断UE的C-RNTI是否属于所述G-RNTI所表示的组播组，如果UE的C-RNTI不属于所述G-RNTI所表示的组播组，则给UE分配新的属于该组播组的C-RNTI。RRC实体给UE分配新的C-RNTI后，网络侧可以通过网络侧与UE侧之间的信令交互过程中将C-RNTI发送给UE侧，UE将自身的C-RNTI更新为网络侧分配的C-RNTI，例如，网络侧向UE侧发送RRC状态转换命令时可以将C-RNTI携带给UE。其中，所分配的C-RNTI结构中包含用于区分不同组播组的组标识(Group-Id)。

判断C-RNTI是否属于G-RNTI所表示的组播组的方法是：由于C-RNTI和G-RNTI都包含Group-Id，因此，从C-RNTI和G-RNTI中分别获取Group-Id，并判断两个Group-Id是否相同，如果相同则认为C-RNTI属于所述G-RNTI表示的组播组；否则认为C-RNTI不属于所述G-RNTI表示的组播组。

步骤103：RNC获取无线接入承载标识，所述无线接入承载标识与传输流媒体控制面的网络业务接入点标识相对应，因此，通过获取流媒体控制面的网络业务接入点标识获取无线接入承载标识；或者，由于所述无线接入承载即为UE请求组播业务时无线接入承载，因此，可以通过获取UE的上下文获取无线接入承载标识。

步骤104：网络侧传输层的RRC实体向UE侧传输层的RRC实体发送RRC状态转换命令，所述RRC状态转换命令指示转移的目标状态为公共信道状态，该消息包含扩展信元“与组播无线承载对应的无线接入承载标识”，其取值为当前传输流媒体控制面数据的无线接入承载的标识，即步骤103所获取的RAB标识；所述‘组播无线承载的无线接入承载标识’信元表示要建立组播无线承载。

步骤105：UE侧传输层的RRC实体收到所述RRC状态转换命令后，将自身的状态转移到公共信道状态，根据“组播无线承载的无线接入承载标识”建立组播无线承载，并向网络侧的RRC实体返回RRC状态转换完成响应。

建立组播无线承载的过程就是配置组播无线承载参数的过程，配置组播无线承载参数时，需要根据预先设置的缺省参数，配置UM模式的RLC实体，配置在传输组播数据时不启动加密功能。

这时，UE可以接收网络侧发送的组播数据。

如果所述UE是第一个接收该组播数据的UE，则网络侧业务层的流媒体用户面向UE侧业务层的流媒体用户面发送组播数据，所述组播数据以组播无线承载参数通过网络侧UM RLC实体承载在逻辑信道标识为15的逻辑信道，并映射在公共信道中传输至UE侧，所述公共信道为UE接收到RRC状态转换命令后开始监听的公共信道。网络侧将组播数据承载在公共信道中传输时，在MAC的PDU内的UE标识中设置用于表示组播流媒体业务标识的G-RNTI，用以区分承载不同组播流媒体业务的组播通道，且根据组播无线承载参数的预先设置，在空口中对组播数据不进行加密。

如果所述UE不是第一个接收该组播数据的UE，则网络侧正在发送组播数据，因此，UE就能够立即接收组播数据。

UE侧业务层的流媒体用户面接收组播数据的过程是：UE侧业务层的流媒体用户面从承载在公共信道中的组播流媒体业务数据中提取出G-RNTI，并判断与自身的C-RNTI是否具有相同的Group-Id，如果是，则接收对应的组播流媒体业务数据，并将组播数据通过所述RRC状态转换命令中携带的RAB标识所对应的NSAPI转发给上层应用，否则丢弃该数据。

实施例一所述，使用逻辑信道标识15的逻辑信道作为组播无线承载的逻辑信道时，由于UE通过C-RNTI或G-RNTI等标识识别出自己的数据包之后，还会利用逻辑信道标识区分逻辑信道，如果一个UE当前有多个逻辑信道，可能自己专用的数据用的是逻辑信道标识1到14的逻辑信道，但是组播逻辑信道一定是逻辑信道标识15的逻辑信道，因此UE接收多个业务数据时，不会产生冲突；如果组播逻辑信道使用逻辑信道标识为14的逻辑信道，假设用户有一个单播的逻辑信道也是用逻辑信道标识为14的逻辑信道，那么这两个数据可能会被认为是同一个逻辑信道的数据，UE侧接收数据时就会出问题。为了保证不会使用单播可能用到的逻辑信道标识，本发明就用逻辑信道标识为15的逻辑信道，因为逻辑信道标识15在现有技术中是保留不用的。

实施例二：使用MTCH的组播承载方案

图6为使用MTCH的组播流媒体业务接收阶段的信道映射关系示意图，如图6所示，所述信道映射关系包括图3所示单播流媒体业务接收阶段时信道映射结构之外，进一步包括：用于传输组播数据的MTCH，提供组播无线承载的RLC实体，承载逻辑信道的公共信道，所述公共信道可以为FACH。

用于承载组播数据的逻辑信道采用MTCH，MTCH承载在下行公共信道时，数据块头部包含的TCTF域取值为0110，表示当前承载的业务为MBMS业务，数据块头部包含的MBMS-Id是4个比特，其取值为0到14，15保留，MBMS-Id的取值可以任意配置，用于区分映射到同一个下行公共信道的多条MTCH。

MTCH的信道结构如表2所示。

表2

组播无线承载参数采用预先设置的缺省参数，所述预先设置的缺省参数是指：组播数据传输模式采用UM模式，即RLC实体采用UM模式；组播数据传输时不启动空口加密功能，即网络侧在空口对所发送的组播数据不进行加密，UE侧对接收到的组播数据不进行解密。

设置组播无线承载与传输流媒体控制面的网络业务接入点即无线接入承载相对应。

在图6所示的组播承载系统中，实现组播承载的方法如下所述：

步骤201：在业务发起阶段完成后，网络侧业务层的流媒体控制面实体确定UE需要发起组播流媒体业务，通知网络侧传输层的RRC实体，通知消息中包含组播流媒体业务标识。

步骤202：RNC获取无线接入承载标识，所述无线接入承载标识与传输流媒体控制面的网络业务接入点标识相对应，因此，通过获取流媒体控制面的网络业务接入点标识获取无线接入承载标识；或者，由于所述无线接入承载即为UE请求组播业务时无线接入承载，因此，可以通过获取UE的上下文获取无线接入承载标识。

步骤203：网络侧传输层的RRC实体向UE侧传输层的RRC实体发送RRC状态转换命令，所述RRC状态转换命令指示转移的目标状态为公共信道状态，该消息包含扩展信元“与组播无线承载对应的无线接入承载标识”和“MBMS-Id”，其中“与组播无线承载对应的无线接入承载标识”的取值为当前传输流媒体控制面数据的无线接入承载的标识，即步骤202所获取的RAB标识，“MBMS-Id”取值为UE需要读取的流组播媒体业务的MBMS-Id，所述扩展信元表示要建立组播无线承载。

步骤204：UE侧传输层的RRC实体收到所述RRC状态转换命令后，将自身的状态转移到公共信道状态，且根据“组播无线承载的无线接入承载标识”和“MBMS-Id”建立组播无线承载，并向网络侧的RRC实体返回RRC状态转换完成响应。

建立组播无线承载的过程就是配置组播无线承载参数的过程，配置组播无线承载参数时，需要根据预先设置的缺省参数，配置UM模式的RLC实体，配置在传输组播数据时不启动加密功能。

这时，UE可以接收网络侧发送的组播数据。

如果所述UE是第一个接收该组播数据的UE，则网络侧业务层的流媒体用户面向UE侧业务层的流媒体用户面发送组播数据，所述组播数据以组播无线承载参数通过网络侧UM RLC实体承载在MTCH，并映射在公共信道中传输至UE侧。网络侧发送组播数据时，在MTCH的MBMS-Id设置UE需要读取的组播流媒体业务的MBMS-Id，且根据组播无线承载参数的预先设置，在空口中对组播数据不进行加密。

如果所述UE不是第一个接收该组播数据的UE，则网络侧正在发送组播数据，因此，UE就能够立即接收组播数据。

UE侧业务层的流媒体用户面开始接收组播数据的过程是：UE侧业务层的流媒体用户面从承载在公共信道中的MTCH中的组播流媒体业务数据中提取出MBMS-Id，并判断与RRC状态转换命令中携带的MBMS-Id是否相同，如果是，则接收对应的组播流媒体业务数据，并将组播数据通过所述RRC状态转换命令中携带的RAB标识所对应的NSAPI转发给上层应用，否则丢弃该数据。

以上所述的实施例一和实施例二中，对图3所示现有的单播流媒体业务接收阶段时信道映射结构并没有作任何改动，仍能够实现单播承载，其中，传输单播数据时可以分别采用TM、UM、AM模式传输，而且对单播数据的传输仍能够启动加密功能。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (13)

1、一种提供组播承载的方法，其特征在于，在网络侧和用户设备UE侧之间建立逻辑信道标识为15的逻辑信道，用于传输组播数据，并在网络侧和UE侧设置缺省的组播无线承载参数，网络侧进一步针对每一个组播流媒体业务分配组无线网络临时标识G-RNTI，该方法包括：

当UE请求组播流媒体业务时，网络侧根据所述UE所请求的组播流媒体业务的对应的G-RNTI，判断所述UE的小区无线网络临时标识C-RNTI是否属于所述G-RNTI所表示的组播组，如果不是，则重新给UE分配属于所述组播组的C-RNTI；网络侧向请求组播流媒体业务的UE发送无线资源控制RRC状态转换命令，该命令携带无线接入承载RAB标识；UE侧收到所述RRC状态转换命令后，将自身状态转换为公共信道状态，且根据所设置的缺省的组播无线承载参数建立组播无线承载；

网络侧将组播数据承载在所建立的逻辑信道，并映射在公共信道传输至UE侧，且在传输时，媒体接入控制MAC协议数据单元PDU中携带UE所请求的组播流媒体业务对应的G-RNTI；UE侧从公共信道中接收承载在所建立的逻辑信道的组播数据，在MAC PDU中获取G-RNTI，并判断与自身C-RNTI是否属于相同组播组，如果是，则接收对应的组播数据，并将组播数据通过所述RRC状态转换命令中携带的RAB标识所对应的网络业务接入点NSAPI转发给上层应用，否则丢弃该数据。

2、根据权利要求1所述的方法，其特征在于，所述RAB标识对应的RAB为UE请求组播流媒体业务时所使用的RAB。

3、根据权利要求2所述的方法，其特征在于，所述判断UE的C-RNTI是否属于G-RNTI所表示的组播组为：从C-RNTI与G-RNTI中分别获取组标识Group-Id，并比较所获取的C-RNTI与G-RNTI中Group-Id是否相同。

4、根据权利要求1至3任一项所述的方法，其特征在于，所述设置缺省的组播无线承载参数为：设置组播数据传输模式为UM模式；

网络侧设置UM RLC实体，所述UM RLC实体将组播数据承载在所建立的逻辑信道，并映射在公共信道传输至UE侧；

UE侧设置UM RLC实体，所述UM RLC实体从公共信道中接收承载在所建立的逻辑信道的组播数据。

5、根据权利要求1至3任一项所述的方法，其特征在于，所述设置缺省的组播无线承载参数为：设置不启用加密功能；

网络侧发送组播数据时，在空口上对组播数据不进行加密；

UE侧接收所述组播数据时，对组播数据不进行解密。

6、根据权利要求1至3任一项所述的方法，其特征在于，所述UE侧收到RRC状态转换命令后，进一步包括：向网络侧返回RRC状态转换完成响应。

7、根据权利要求1至3任一项所述的方法，其特征在于，

该方法进一步包括：保持UE请求组播流媒体业务时所使用的专用逻辑信道。

8、一种提供组播承载的方法，其特征在于，在网络侧和用户设备UE侧之间建立多媒体广播多播业务信道MTCH，用于传输组播数据；该方法包括：

当UE请求组播流媒体业务时，网络侧向请求组播流媒体业务的UE发送无线资源控制RRC状态转换命令，该命令携带无线接入承载RAB标识和多媒体广播多播业务标识MBMS-Id，所述MBMS-Id的值为UE所请求的组播流媒体业务的MBMS-Id；UE侧收到所述RRC状态转换命令后，将自身状态转换为公共信道状态，且根据所设置的缺省的组播无线承载参数建立组播无线承载；

网络侧将承载组播数据的MTCH的MBMS-Id设置为UE所请求的组播流媒体业务的MBMS-Id；并将组播数据承载在MTCH上，并映射在公共信道传输至UE侧；

UE侧从承载组播数据的MTCH中获取MBMS-Id，并判断与所述RRC状态转换命令中携带的MBMS-Id是否相同，如果是，则接收对应的组播流媒体业务数据，并将组播数据通过所述RRC状态转换命令中携带的RAB标识所对应的网络业务接入点NSAPI转发给上层应用，否则丢弃该数据。

9、根据权利要求8所述的方法，其特征在于，所述RAB标识对应的RAB为UE请求组播流媒体业务时所使用的RAB。

10、根据权利要求8或9所述的方法，其特征在于，所述设置缺省的组播无线承载参数为：设置组播数据传输模式为非确认UM模式；

网络侧设置UM RLC实体，所述UM RLC实体将组播数据承载在所建立的逻辑信道，并映射在公共信道传输至UE侧；

UE侧设置UM RLC实体，所述UM RLC实体从公共信道中接收承载在所建立的逻辑信道的组播数据。

11、根据权利要求8或9所述的方法，其特征在于，所述设置缺省的组播无线承载参数为：设置不启用加密功能；

网络侧发送组播数据时，在空口上对组播数据不进行加密；

UE侧接收所述组播数据时，对组播数据不进行解密。

12、根据权利要求8或9所述的方法，其特征在于，所述UE侧收到RRC状态转换命令后，进一步包括：向网络侧返回RRC状态转换完成响应。

13、根据权利要求8或9所述的方法，其特征在于，

该方法进一步包括：保持UE请求组播流媒体业务时所使用的专用逻辑信道。

Images