WO2007112670A1 - Procédé, système et appareil de prise en charge de multidiffusion - Google Patents

Procédé, système et appareil de prise en charge de multidiffusion Download PDF

Info

Publication number
WO2007112670A1
WO2007112670A1 PCT/CN2007/001011 CN2007001011W WO2007112670A1 WO 2007112670 A1 WO2007112670 A1 WO 2007112670A1 CN 2007001011 W CN2007001011 W CN 2007001011W WO 2007112670 A1 WO2007112670 A1 WO 2007112670A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
side device
rnti
network side
mbms
Prior art date
Application number
PCT/CN2007/001011
Other languages
English (en)
French (fr)
Inventor
Jun Hu
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2007112670A1 publication Critical patent/WO2007112670A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways

Definitions

  • the present invention relates to multicast technology, and more particularly to a method, system and apparatus for providing multicast 7-load. Background of the invention
  • the radio link control (RLC) protocol implements data transmission on air interfaces in three modes: transparent mode (TM), unacknowledged mode (UM), and acknowledge mode (AM).
  • transparent mode TM
  • unacknowledged mode UM
  • acknowledge mode AM
  • transparent mode the RLC sending entity does not perform any processing on the upper layer data and directly transmits it to the RLC receiving entity through the logical channel.
  • the RLC transmitting entity receives the upper layer data, and segments the data into a plurality of data blocks, and adds a consecutive sequence number to each data block, and transmits the data to the LC receiving entity through the logical channel;
  • the receiving entity receives the data block from the logical channel, performs de-segmentation cascading on the received data block, restores the upper layer data, and submits the upper layer data to the upper layer, and the receiving entity may further determine whether the sequence number of the received data block is continuous or not. , detects if data is lost during transmission.
  • the RLC receiving entity In addition to implementing the functions of the non-acknowledgment mode described above, the RLC receiving entity also indicates to the RLC transmitting entity through the reverse channel that the data blocks corresponding to which sequence numbers are not correctly received, and requests the RLC transmitting entity to resend.
  • the data block corresponding to the serial number ensures reliable transmission of data.
  • the RRC entity controls User Equipment (UE) to switch between a dedicated channel state and a common channel state.
  • UE User Equipment
  • 1 is a schematic diagram of RRC state transition.
  • the RRC entity on the network side sends an RRC state transition command message to the RRC entity on the UE side, where the message indicates the target state that the UE needs to transfer, and the RRC on the UE side.
  • the entity moves to the corresponding target state and returns an RRC state completion response to the RRC entity on the network side.
  • the random access channel acts as a forward access channel (FACH).
  • FACH forward access channel
  • the network side allocates different cell radio network temporary identifiers (C-RNTIs) for each UE, so that when the data blocks of each UE are transmitted on one FACH channel, the network side adds the C- of the UE to the head of each data block.
  • C-RNTI cell radio network temporary identifiers
  • RNTI after receiving all data blocks on the common channel, the UE distinguishes whether each data block is sent to the UE by using C-RNTI in the data block.
  • FIG. 1 is a schematic diagram of a channel mapping relationship in a unicast streaming media service initiation phase.
  • FIG. 2 includes channel mapping relationships when UE A and UE B initiate unicast services, as shown in (A) and (B) of FIG. 2, respectively.
  • FIG. 3 is a schematic diagram of a channel mapping relationship in a receiving phase of a unicast streaming media service.
  • FIG. 3 includes channel mapping relationships when UE A and UE B receive unicast services, as shown in (A) and (B) of FIG. 3 respectively.
  • the channel mapping structure shown in FIG. 2 and FIG. 3 includes: a network side and a UE side, where the network side and the UE side respectively include a service layer and a transport layer, where the service layer includes a streaming media control plane, and the transport layer includes an RC entity and an RLC entity. And a logical channel, including a dedicated channel of the UE between the network side and the UE side.
  • the business layer further includes a streaming media user plane.
  • the streaming media control plane entity and the streaming media user plane entity use the same network service access point and transmit unicast data on the same radio bearer.
  • the streaming media control plane entity performs bidirectional data transmission, and the streaming media user plane entity performs downlink one-way data transmission.
  • the RLC entity provides the function of radio bearer.
  • the unicast data is transmitted on the logical channel through the RLC entity, and the dedicated channel can carry different logical channels.
  • the data block header transmitted on the dedicated channel of the UE includes a logical channel identifier, and the logical channel identifier is used to distinguish different logical channels, and multiple logical channels are multiplexed onto one dedicated channel.
  • the definition of the logical channel identifier is as shown in Table 1. It is shown that there are four bits, which are 0 to 15, respectively, where 0 to 14 are used to indicate logical channel 1 to logical channel 15, and 15 remains unused.
  • logical channel 1 is used to transmit RRC messages
  • logical channel 2 is used to transport streaming media service data.
  • the UEA and the UE B shown in FIG. 2 and FIG. 3 respectively have their own dedicated channels.
  • the dedicated channel is used to distinguish different channels.
  • the service data transmitted on the common channel is used.
  • RNTI distinguishes between different channels.
  • the unicast service and the multicast service coexist. Therefore, it is desirable to implement the multicast bearer without changing the channel mapping relationship of the unicast transmission described above.
  • the channel mapping relationship in the initial stage of the multicast streaming service is the same as that shown in FIG. 2 when the multicast streaming service is implemented without changing the channel mapping relationship in the unicast transmission. Relationship, and the channel mapping relationship of the receiving phase of the multicast streaming service is as shown in FIG. 4.
  • Each UE has its own dedicated channel, and the UE is in a common channel state.
  • the bidirectional logical channel uses the UM mode, and the multicast data sent by the network side passes through the downlink logical channel. Transfer to the UE side.
  • the unicast bearer shown in Figure 4 when implementing multicast bearer, it has the following characteristics:
  • the downlink logical channel is used to carry downlink multicast data, and is no longer used to carry downlink unicast data. Downlink unicast data and downlink multicast data cannot be transmitted through the same downlink logical channel. The reason is: The downlink multicast data is shared by each multicast UE in a cell, and has the characteristics of separate data segmentation cascading and adding a sequence number. If the downlink unicast data of a single UE is added, it will be disrupted. The RLC receives the de-segment cascading function of the entity, and the downlink unicast data and multicast data of the UE cannot be normally received. Therefore, when multicast transmission is implemented, downlink unicast data cannot be transmitted to the UE side through the downlink logical channel, that is, the downlink unicast channel is interrupted.
  • the downlink multicast data is transmitted in the non-acknowledgment mode of the RLC. That is, the UM RLC sending entity on the network side carries the downlink multicast data in the logical channel and sends it to the UM RLC receiving entity on the UE side. If the downlink multicast data is in the acknowledgment mode of the RLC, the RLC entity on the UE side feeds back the multicast data to the RLC entity on the network side after receiving the downlink multicast data, resulting in the processing of the RLC entity on the network side. Very complicated and very prone to problems.
  • the transmission of the downlink multicast data adopts the non-acknowledge mode of the RLC
  • the transmission of the uplink unicast data also adopts the non-acknowledge mode, thereby causing the transmission of the uplink unicast data to be less reliable.
  • the downlink multicast data needs to be sent to multiple UEs.
  • the multicast data cannot be encrypted on the air interface, and the UE side does not need to start the encryption function.
  • unicast data is generally encrypted on the air interface, each UE has its own specific encryption key, and the encryption process in the existing protocol cannot be stopped once the connection process is initiated. Therefore, the channel for transmitting multicast data cannot be encrypted, and the unicast data transmitted through the channel cannot be encrypted.
  • the embodiment of the invention provides a method, a system and a device for providing a multicast bearer, and implements a multicast streaming media service based on a channel mapping structure of an existing unicast streaming media service.
  • a method for providing a multicast bearer including:
  • the UE side requesting the multicast streaming service controls the RRC state transition command according to the radio resource sent by the network side, and converts the state to the common channel state, and according to the preset multicast.
  • the line bearer parameters establish a multicast radio bearer
  • the network side carries the multicast data in a logical channel between the pre-established network side and the UE side, and the mapping is transmitted to the UE side on the common channel;
  • the UE side receives 7
  • a system for providing a multicast bearer including a network side device and a UE side device, where the network side device includes a network side RC entity and a network side RLC entity, and the UE side device includes a UE side RRC entity and a UE side RLC entity.
  • the network side R C entity is configured to send an RRC state transition command to the UE side device that requests the multicast streaming media service, to indicate that the UE side device is converted to the common channel state;
  • the network side RLC entity is configured to carry the multicast data in a logical channel between the pre-established network side device and the UE side device, and map the signal to the UE side device on the common channel; Receiving an RRC state transition command sent by the network side RRC entity, converting the UE side device state to a common channel state, and establishing a multicast radio bearer according to the preset default multicast radio bearer parameter;
  • the UE side RLC entity is configured to receive, on the common channel, multicast data that is carried by the network side RLC on the logical channel.
  • a network side device that provides a multicast bearer, including an RC entity and an RLC entity, where the RRC entity is configured to send an RRC state transition command to the UE side device that requests the multicast streaming service, and instruct the UE side device to convert to the common channel.
  • the RLC entity is configured to carry the multicast data in a logical channel between the pre-established network side device and the UE side device, and map the common channel to the UE side device.
  • the method, the system and the device provided by the embodiments of the present invention add a logical channel for carrying multicast data based on the existing channel mapping structure of the unicast bearer, so that when the multicast data is propagated, The transmission of unicast data is interrupted, thereby implementing multicast streaming media services.
  • Figure 1 is a schematic diagram showing the R C state transition in the prior art
  • FIG. 2 is a schematic diagram showing a channel mapping relationship in a unicast streaming media service initiation phase in the prior art
  • FIG. 3 is a schematic diagram showing a channel mapping relationship in a receiving phase of a unicast streaming media service in the prior art
  • FIG. 4 is a schematic diagram of channel mapping in a receiving phase of a multicast streaming media service in the prior art
  • FIG. 5 is a schematic diagram showing a channel mapping relationship of a multicast streaming service receiving phase using a dedicated logical channel with a logical channel identifier of 15 in the first embodiment of the present invention
  • FIG. 6 is a schematic diagram showing the channel mapping relationship of the multicast streaming service receiving phase using the MTCH in the second embodiment of the present invention. Mode for carrying out the invention
  • the embodiment of the present invention adds a logical channel for transmitting multicast data, and sets a default parameter for the multicast radio bearer parameter.
  • the RRC state transition process is initiated to the UE side, and then the multicast data bearer is sent to the UE on the added logical channel according to the set multicast radio bearer default parameter; the UE side defaults according to the set multicast radio bearer.
  • the parameter receives the multicast data.
  • FIG. 5 is a multicast streaming service transport using a dedicated logical channel with a logical channel identifier of 15.
  • the channel mapping relationship in the receiving phase is as shown in FIG. 5.
  • the channel mapping relationship includes the channel mapping structure in the receiving phase of the unicast streaming media service shown in FIG. 3, and further includes: a logical channel for transmitting multicast data.
  • a multicast channel is added between the network side and the UE side, and the added multicast channel is used to carry the logical channel for transmitting the multicast data.
  • set the group radio network temporary identifier (G-RNTI) for the UE identity extension in the MAC protocol data unit (PDU) transmitted in the multicast channel and the G-RNTI is the network.
  • the parameters for different multicast services are used to distinguish different multicast services, that is, the G-RNTI corresponds to the multicast streaming service identifier.
  • the set G-RNTI structure includes a group label i (Group-Id) for distinguishing different multicast groups.
  • the logical channel identifier of the logical channel used to transmit the multicast data is configured as a reserved logical channel identifier 15.
  • the multicast radio bearer parameter adopts a preset default parameter, and the preset default parameter refers to: the multicast data transmission mode adopts the UM mode, that is, the RLC entity adopts the UM mode; the multicast data transmission does not start the air interface encryption function. That is, the network side does not encrypt the multicast data sent by the air interface, and the UE side does not decrypt the received multicast data.
  • the multicast radio bearer is set to correspond to the network service access point (NSAPI) of the transport stream control plane, that is, the radio access bearer (RAB).
  • NSAPI network service access point
  • RAB radio access bearer
  • Step 101 After the service initiation phase is completed, the streaming media control plane entity of the network side service layer determines that the UE needs to initiate multicast. The streaming media service notifies the RC entity of the transport layer on the network side, and the notification message includes the multicast streaming service identifier.
  • Step 102 The RRC entity of the network side transport layer corresponds to the multicast stream media service identifier.
  • the G-KNTI determines whether the C-RNTI of the UE belongs to the multicast group indicated by the G-RNTI. If the C-RNTI of the UE does not belong to the multicast group indicated by the G-RNTI, the UE is allocated a new one. After the C-RNTL RRC entity belonging to the multicast group allocates a new C-RNTI to the UE, the network side may send the CR TI to the UE side through the signaling interaction process between the network side and the UE side, and the UE will The C-KNTI is updated to the C-RNTI allocated on the network side, for example,
  • the allocated C-RNTI structure includes a group identifier (Group-Id) for distinguishing different multicast groups.
  • the method for determining whether the C-KNTI belongs to the multicast group represented by the G-RNTI is: Since the C-RNTI and the G-RNTI both include the Group-Id, the Group-Id is obtained from the C-RNTI and the G-RNTI, respectively. And determining whether the two Group-Ids are the same. If the same, the C-RNTI is considered to belong to the multicast group represented by the G-RNTI; otherwise, the C-RNTI is not considered to belong to the multicast group indicated by the G-RNTI.
  • Step 103 The RC acquires a radio access bearer identifier, where the radio access bearer identifier corresponds to the network service access point identifier of the transport stream media control plane, and therefore obtains the network service access point identifier of the streaming media control plane.
  • the radio access bearer identifier; or, the radio access bearer identifier is obtained by acquiring the context of the UE, because the radio access bearer is the radio access bearer when the UE requests the multicast service.
  • Step 104 The RRC entity of the network side transport layer sends an RC state transition command to the RRC entity of the UE side transport layer, where the RC state transition command indicates that the target state of the transfer is a common channel state, and the message includes the extended cell and the multicast.
  • the radio bearer identifier corresponding to the radio bearer which is the identifier of the radio access bearer that currently transmits the data of the control plane of the streaming media, that is, the RAB identifier acquired in step 103; the wireless corresponding to the multicast radio bearer Access Bearer Identity "The cell indicates that a multicast radio bearer is to be established.
  • Step 105 After receiving the RRC state transition command, the RRC entity of the UE side transport layer receives the RRC state transition command.
  • the state of the self is transferred to the common channel state, the multicast radio bearer is established according to the "radio access bearer corresponding to the multicast radio bearer", and the RRC state transition completion response is returned to the RRC entity on the network side.
  • the process of setting up a multicast radio bearer is the process of configuring the multicast radio bearer parameters.
  • the configuration does not start when transmitting multicast data. Encryption function.
  • the UE can receive the multicast data sent by the network side.
  • the streaming media user of the network side service layer sends multicast data to the streaming media user plane of the UE side service layer, and the multicast data is multicast radio bearer.
  • the parameter is carried by the network side UM RLC entity on the logical channel with the logical channel identifier of 15, and the mapping is transmitted to the UE side in the common channel, where the common channel is a common channel that the UE starts to listen after receiving the RRC state transition command.
  • the G-RNTI for indicating the multicast streaming service identifier is set in the UE identifier in the PDU of the MAC to distinguish the group carrying the different multicast streaming services.
  • the multicast channel is not encrypted in the air interface according to the preset setting of the multicast radio bearer parameter.
  • the network side is transmitting multicast data, so the UE can receive the multicast data immediately.
  • the process of receiving the multicast data by the streaming media user plane of the UE side service layer is: the streaming media user plane of the UE side service layer extracts the G-RNTI from the multicast streaming media service data carried in the common channel, and judges with itself Whether the CR TI has the same Group-Id, and if so, receives the corresponding multicast streaming service data, and forwards the multicast data to the upper application through the NSAPI corresponding to the RAB identifier carried in the RC state transition command. , otherwise discard the data.
  • the logical channel of the logical channel identifier 15 is used as the multicast radio bearer.
  • the UE identifies its own data packet through the C-RNTI or G-RNTI identifier, it also uses the logical channel identifier to distinguish the logical channel. If a UE currently has multiple logical channels, it may have its own dedicated data.
  • the logical channel identifiers 1 to 14 are used, but the multicast logical channel must be the logical channel of the channel identifier 15 so that the UE does not generate collisions when receiving multiple service data; if the multicast logical channel uses logic
  • the logical channel with the channel identifier is 14, assuming that the user has a unicast logical channel and a logical channel identified by the logical channel as 14, then the two data may be considered as the same logical channel data, and the UE side receives the data.
  • the present invention uses logical channels identified by logical channels as 15, since logical channel identities 15 are reserved in the prior art.
  • Embodiment 2 Multicast bearer scheme using MTCH
  • the channel mapping relationship includes a channel mapping structure in a receiving phase of the unicast streaming media service shown in FIG.
  • the method includes: an MTCH for transmitting multicast data, an RLC entity for providing a multicast radio bearer, and a common channel carrying a logical channel, where the common channel can be FACEL
  • the logical channel used to carry the multicast data is MTCH.
  • the TCTF field included in the data block header is 0110, indicating that the currently carried service is the MBMS service, and the MBMS of the data block header is included.
  • Id is 4 bits, and its value is 0 to 14, 15 is reserved.
  • the value of MBMS-Id can be arbitrarily configured to distinguish multiple MTCHs mapped to the same downlink common channel.
  • the channel structure of the MTCH is shown in Table 2.
  • the multicast radio bearer parameter adopts a preset default parameter, and the preset default parameter refers to: the multicast data transmission mode adopts the UM mode, that is, the RLC entity adopts the UM mode; the multicast data transmission does not start the air interface encryption function. That is, the network side does not encrypt the multicast data sent by the air interface, and the UE side does not decrypt the received multicast data.
  • the air interface encryption function can still be activated because the network transmits multicast data through a dedicated channel for transmitting multicast data, and does not conflict with the transmission of unicast data.
  • the multicast radio bearer is set to correspond to the network access point of the transport stream control plane, that is, the radio access bearer.
  • Step 201 After the service initiation phase is completed, the media control plane entity of the network-side service layer determines that the UE needs to initiate the multicast stream. The media service notifies the RRC entity of the transport layer on the network side, and the notification message includes the multicast streaming service identifier.
  • Step 202 The RNC acquires a radio access bearer identifier, where the radio access bearer identifier corresponds to the network service access point identifier of the transport stream media control plane, and therefore obtains the network service access point identifier of the streaming media control plane.
  • the radio access bearer identifier; or, because the radio access bearer is a radio access bearer when the UE requests the multicast service, the radio access bearer identifier may be obtained by acquiring the context of the UE.
  • Step 203 The RRC entity of the network side transport layer sends an RRC state transition command to the RRC entity of the UE side transport layer, where the RRC state transition command indicates that the target state of the transfer is a common channel state, and the message includes the extended cell and the multicast.
  • the RAB identifier obtained in step 202 the value of "MBMS-Id" is the MBMS-Id of the streaming multicast media service that the UE needs to read, and the extended cell indicates that the multicast radio bearer is to be established.
  • Step 204 After receiving the RRC state transition command, the RRC entity of the UE side transport layer transfers its state to the common channel state, and according to the radio access bearer identifier corresponding to the multicast radio bearer, and the MBMS -Id" establishes a multicast radio bearer and returns an RRC state transition completion response to the RRC entity on the network side.
  • the process of setting up a multicast radio bearer is the process of configuring the multicast radio bearer parameters.
  • the configuration does not start when transmitting multicast data. Encryption function.
  • the UE can receive the multicast data sent by the network side.
  • the streaming media user of the network side service layer sends multicast data to the streaming media user plane of the UE side service layer, and the multicast data is multicast radio bearer.
  • the parameters are carried in the MTCH through the network side UM RLC entity, and the mapping is transmitted to the UE side in the common channel.
  • the MBMS-Id of the MTCH is set to the MBMS-Id of the multicast streaming service that the UE needs to read, and the multicast data is not performed in the air interface according to the preset setting of the multicast radio bearer parameter. encryption.
  • the network side is transmitting multicast data, so the UE can receive the multicast data immediately.
  • the process of receiving the multicast data by the streaming media user plane of the UE side service layer is: the streaming media user plane of the UE side service layer extracts the MBMS-Id from the multicast streaming media service data in the MTCH carried in the common channel, And determining whether the MBMS-Id carried in the RRC state transition command is the same, and if yes, receiving the corresponding multicast streaming media service data, and passing the multicast data through the RAB identifier carried in the RRC state transition command.
  • the NSAPI forwards to the upper application, otherwise the data is discarded.
  • the unicast-based channel mapping structure can still implement the uplink/downlink unicast data transmission; the unicast service and the multicast service can be separately activated and disabled. Encryption function; existing existing channel mapping structure for unicast bearers The unicast data transmission in the acknowledgment mode can be used, so that the transmission reliability of the uplink unicast data can be ensured; the existing channel mapping structure of the unicast bearer can also use the unacknowledged mode, and the transparent mode unicast data transmission, The multicast bearer can be implemented on the basis of the channel mapping structure of the unicast bearer in the non-acknowledgement mode and the transparent mode, and the channel mapping structure of the existing unicast bearer is changed little.

Description

一种提供组播承载的方法、 系统及装置 技术领域
本发明涉及组播技术， 特别是指一种提供組播 7 载的方法、 系统及 装置。 发明背景
无线链路控制 （RLC )协议在空口上实现数据传输的模式分为透明 模式（TM )、 非确认模式（UM )和确认模式（AM )三种工作模式。 在 透明模式和非确认模式中， 有一个发送实体和一个接收实体， 确认模式 只有一个发送和接收结合的实体。 在透明模式下， RLC发送实体对上层 数据不进行任何处理，直接通过逻辑信道传输至 RLC接收实体。在非确 认模式下， RLC发送实体接收上层数据， 对该数据进行分段级联成若干 个数据块， 对每个数据块分别加上连续的序列号， 通过逻辑信道传输至 LC接收实体； LC接收实体接收来自逻辑信道的数据块，对所接收到 的数据块进行解分段级联， 恢复上层数据， 提交给上层， 接收实体还可 以根据所接收到的数据块的序列号的连续与否， 检测出在传输过程中数 据是否丢失。在确认模式下，除了实现以上所述非确认模式的功能以夕卜， 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。
图 1为单播流媒体业务发起阶段的信道映射关系示意图， 图 2中包 括 UE A和 UE B发起单播业务时的信道映射关系， 分别如图 2中 (A)和 (B)所示。 图 3为单播流媒体业务接收阶段的信道映射关系示意图， 图 3 中包括 UE A和 UE B接收单播业务时的信道映射关系，分别如图 3中 (A) 和 (B)所示。
图 2和图 3所示的信道映射结构包括： 网絡侧和 UE侧， 网络侧和 UE侧分别包括业务层和传输层， 其中， 业务层包括流媒体控制面， 传 输层包括 R C实体、 RLC实体以及逻辑信道， 在网络侧和 UE侧之间 包括 UE的专用通道。 在图 3中业务层还进一步包括流媒体用户面。
其中 , 业务层的网络业务接入点和传输层的无线接入承载之间存在 对应的关系。 流媒体控制面实体和流媒体用户面实体使用相同的网络业 务接入点， 且在同一个无线承载上传输单播数据。 流媒体控制面实体进 行双向的数据传输， 流媒体用户面实体进行下行单向数据传输。 RLC实 体提供无线承载的功能，单播数据通过 RLC实体在逻辑信道上传输，而 专用通道上可以承载不同的逻辑信道。 在 UE的专用通道上传输的数据 块头部包含逻辑信道标识， 逻辑信道标识用于区分不同的逻辑信道， 实 现多个逻辑信道复用到一个专用通道上。 逻辑信道标识的定义如表 1所 示， 共有四个比特， 取值分别为 0到 15, 其中， 0到 14用于表示逻辑 信道 1到逻辑信道 15, 15保留还未使用。
Figure imgf000005_0001
表 1
在图 2和图 3中， 逻辑信道 1用于传输 RRC的消息， 逻辑信道 2 用于传输流媒体业务数据。
图 2和图 3所示 UEA和 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侧根据网络侧发送的无线资源控制 RRC 状态转换命令， 将自身状态转换为公共信道状态， 并根据预设的组播无 线承载参数建立组播无线承载；
网络侧将组播数据承载在预先建立的网络侧和 UE侧间的逻辑信 道， 并映射在公共信道传输至 UE侧；
UE侧从所述公共信道中接收 7|载在所述逻辑信道的组播数据。 一种提供组播承载的系统， 包括网络侧设备和 UE侧设备， 所述网 络侧设备包括网络侧 R C实体和网络侧 RLC实体， 所述 UE侧设备包 括 UE侧 RRC实体和 UE侧 RLC实体，
所述网絡侧 R C实体，用于向请求组播流媒体业务的 UE侧设备发 送 RRC状态转换命令， 指示 UE侧设备转换为公共信道状态；
所述网络侧 RLC实体，用于将组播数据承载在预先建立的网络侧设 备和 UE侧设备间的逻辑信道， 并映射在公共信道传输至 UE侧设备； 所述 UE侧 RRC实体， 用于接收所述网络侧 RRC实体发送的 RRC 状态转换命令， 将 UE侧设备状态转换为公共信道状态， 并根据预设的 缺省组播无线承载参数建立組播无线承载；
所述 UE侧 RLC实体，用于在所述公共信道上接收所述网络侧 RLC 承载在所述逻辑信道的组播数据。
一种提供组播承载的网络侧设备， 包括 R C实体和 RLC实体， 所述 RRC实体，用于向请求组播流媒体业务的 UE侧设备发送 RRC 状态转换命令， 指示 UE侧设备转换为公共信道状态；
所述 RLC 实体， 用于将组播数据承载在预先建立的网络侧设备和 UE侧设备间的逻辑信道， 并映射在公共信道传输至 UE侧设备。
本发明实施例提供的方法、 系统及装置， 在现有存在的单播承载的 信道映射结构的基础上， 增加用于承载组播数据的逻辑信道， 从而在传 播组播数据时，也不会中断单播数据的传输，从而实现组播流媒体业务。 附图简要说明
下面参照实施例和附图对本发明做进一步详细说明。 应该理解， 下 面的描述只是本发明的示例， 并不用来限制本发明的范围。 附图中： 图 1所示为现有技术中 R C状态转换的示意图；
图 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结构中包含用于区分不同组播组 的组标 i只 ( Group-Id )o
用于传输组播数据的逻辑信道的逻辑信道标识配置为预留的逻辑信 道标识 15。
组播无线承载参数采用预先设置的缺省参数， 所述预先设置的缺省 参数是指： 组播数据传输模式采用 UM模式， 即 RLC实体采用 UM模 式； 组播数据传输时不启动空口加密功能， 即网络侧在空口对所发送的 组播数据不进行加密， UE侧对接收到的组播数据不进行解密。
设置组播无线承载与传输流媒体控制面的网络业务接入点（ NSAPI ) 即无线接入承载（RAB )相对应。
在图 5所示的组播承载系统中， 实现组播^ c载的方法如下所述： 步骤 101 : 在业务发起阶段完成后， 网络侧业务层的流媒体控制面 实体确定 UE需要发起组播流媒体业务,通知网络侧传输层的 R C实体， 通知消息中包含组播流媒体业务标识。
步骤 102: 网络侧传输层的 RRC实体根据组播流媒体业务标识对应 的 G-KNTI，判断 UE的 C-RNTI是否属于所述 G-RNTI所表示的组播组， 如果 UE的 C-RNTI不属于所述 G-RNTI所表示的组播组，则给 UE分配 新的属于该组播组的 C-RNTL RRC实体给 UE分配新的 C-RNTI后， 网絡侧可以通过网络侧与 UE侧之间的信令交互过程中将 C-R TI发送 给 UE侧， UE将自身的 C-KNTI更新为网络侧分配的 C-RNTI, 例如，
'
其中， 所分配的 C-RNTI 结构中包含用于区分不同组播组的组标识 ( Group-Id )。
判断 C-KNTI是否属于 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: R C获取无线接入承载标识, 所述无线接入承载标识与 传输流媒体控制面的网络业务接入点标识相对应， 因此， 通过获取流媒 体控制面的网络业务接入点标识获取无线接入承载标识； 或者， 由于所 述无线接入承载即为 UE请求组播业务时无线接入承载, 因此， 可以通 过获取 UE的上下文获取无线接入承载标识。
步骤 104: 网絡侧传输层的 RRC实体向 UE侧传输层的 RRC实体 发送 R C状态转换命令， 所述 R C状态转换命令指示转移的目标状态 为公共信道状态，该消息包含扩展信元"与组播无线承载对应的无线接入 承载标识"， 其取值为当前传输流媒体控制面数据的无线接入承载的标 识， 即步骤 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-R TI是否具有相同的 Group-Id, 如果是， 则接收对应的组播流媒体业务数据， 并将组播数据通过所述 R C状态 转换命令中携带的 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实体，承载逻辑信道的公共信道，所述公共信 道可以为 FACEL
用于承载组播数据的逻辑信道采用 MTCH, MTCH承载在下行公共 信道时， 数据块头部包含的 TCTF域取值为 0110, 表示当前承载的业务 为 MBMS业务， 数据块头部包含的 MBMS-Id是 4个比特， 其取值为 0 到 14, 15保留， MBMS-Id的取值可以任意配置， 用于区分映射到同一 个下行公共信道的多条 MTCH。
MTCH的信道结构如表 2所示。
header Payload
Λ 1—— ^
TCTF MBMS-Id Payload 表 2 组播无线承载参数采用预先设置的缺省参数， 所述预先设置的缺省 参数是指： 组播数据传输模式采用 UM模式， 即 RLC实体采用 UM模 式； 组播数据传输时不启动空口加密功能， 即网络侧在空口对所发送的 组播数据不进行加密， UE侧对接收到的组播数据不进行解密。 但是， 在传输单播数据时， 仍然可以启动空口加密功能， 因为网络是通过专用 的传输组播数据的信道传输组播数据 , 并不会与单播数据的传输产生冲 突。
设置组播无线承载与传输流媒体控制面的网络业务接入点即无线接 入承载相对应。
在图 6所示的组播承载系统中， 实现组播 7 载的方法如下所述： 步骤 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转发给上层应用， 否则丢弃该数据。
以上所述的实施例一和实施例二中， 通过现有存在的单播 载的信 道映射结构仍能够实现上 /下行单播数据的传输；对于单播业务和组播业 务能够分别启动和禁用加密功能； 现有存在的单播承载的信道映射结构 可以使用确认模式的单播数据传输， 因此能够保证上行单播数据的传输 可靠性； 现有存在的单播承载的信道映射结构还可以使用非确认模式， 以及透明模式的单播数据传输， 同时可以在非确认模式以及透明模式的 单播承载的信道映射结构的基础上实现組播承载， 对现有实现单播承载 的信道映射结构改动很小。
以上所述仅为本发明的较佳实施例而已， 并不用以限制本发明， 凡 在本发明的精神和原则之内， 所作的任何修改、 等同替换、 改进等， 均 应包含在本发明的保护范围之内。

Claims

权利要求书
1、 一种提供组播承载的方法， 其特征在于， 该方法包括： 请求组播流媒体业务的 UE侧根据网络侧发送的无线资源控制 RRC 状态转换命令， 将自身状态转换为公共信道状态， 并才 据预设的组播无 线承载参数建立组播无线承载；
网络侧将组播数据 载在预先建立的网络侧和 UE侧之间的逻辑信 道， 并映射在公共信道传输至 UE侧；
UE侧从所述公共信道中接收承载在所述逻辑信道的组播数据。
2、 根据权利要求 1所述的方法， 其特征在于，
所述预先建立的网络侧和 UE侧间的逻辑信道为： 逻辑信道标识为 15的逻辑信道。
3、 根据权利要求 2所述的方法， 其特征在于， 所述 RRC状态转换 命令携带无线接入承载 RAB标识， 所述 RAB标识表示要建立组播无线 承载；
网络侧进一步针对每一个组播流媒体业务分配組无线网络临时标识 G-RNTI;
所述网络侧在公共信道上映射承载组播数据的逻辑信道时， 在媒体 接入控制 MAC协议数据单元 PDU中携带 UE侧所请求的组播流媒体业 务对应的 G-RNTI;
所述 UE侧从公共信道中接收承载在逻辑信道的组播数据时， 在 MAC PDU 中获取 G-RNTI, 并判断与自身的小区无线网络临时标识 C-RNTI是否属于所迷 G-RNTI所表示的组播组， 如果是， 则接收对应 的组播数据。
4、 据权利要求 3所述的方法， 其特征在于， 如果所述 UE侧判断自身的 C-RNTI不属于所述 G-RNTI所表示的 组播组， 则丟弃所述组播数据。
5、 根据权利要求 3所述的方法， 其特征在于， 还包括：
网络侧根据所述 UE侧所请求的组播流媒体业务对应的 G-RNTI，判 断所述 UE侧的 C-RNTI是否属于所述 G-RNTI所表示的组播組， 如果 不是， 则重新给 UE侧分配属于所述组播组的 C-RNTI。
6、 根据权利要求 3或 5所述的方法， 其特征在于， 所述判断 UE侧 的 C-RNTI是否属于 G-RNTI所表示的组播组为：从 C-RNTI与 G-RNTI 中分别获取组标识 Group-Id, 并比较所获取的 C-RNTI 与 G-RNTI 中 Group-Id是否相同。
7、 根据权利要求 1所述的方法， 其特征在于，
所述在网络侧和 UE侧间所预先建立的逻辑信道为多媒体广播多播 业务信道 MTCEL
8、 根据权利要求 7所述的方法， 其特征在于， 所述 RRC状态转换 命令中携带 RAB标识， 所述 RAB标识表示要建立组播无线承载；
所述网絡侧向 UE侧发送的 RRC状态转换命令中进一步携带多媒体 广播多播业务标识 MBMS-Id, 所述 MBMS-Id的值为 UE侧所请求的组 播流媒体业务的 MBMS-Id;
网络侧将承载组播数据的 MTCH的 MBMS-Id设置为 UE侧所请求 的组播流媒体业务的 MBMS-Id;
UE侧从承载组播数据的 MTCH中获取 MBMS-Id, 并判断与所述 RRC状态转换命令中携带的 MBMS-Id是否相同， 如果是， 则接 应 的组播流媒体业务数据。
9、 根据权利要求 8所述的方法， 其特征在于，
如果 UE侧判断从承载组播数据的 MTCH中获取的 MBMS-Id与所 述 RRC状态转换命令中携带的 MBMS-Id不相同，则丟弃所述组播数据。
10、 根据权利要求 1所述的方法， 其特征在于， 所述设置缺省的组 播无线承载参数为： 设置组播数据传输模式为 UM模式， 设置不启用加 密功能。
11、 一种提供组播承载的系统， 其特征在于， 包括网絡侧设备和 UE 侧设备， 所述网络侧设备包括网络侧 RRC实体和网络侧 RLC实体， 所 述 UE侧设备包括 UE侧 RRC实体和 UE侧 RLC实体，
所述网络侧 RRC实体，用于向请求组播流媒体业务的 UE侧设备发 送 R C状态转换命令， 指示 UE侧设备转换为公共信道状态；
所述网络侧 RLC实体，用于将组播数据承载在预先建立的网络侧设 备和 UE侧设备间的逻辑信道， 并映射在公共信道传输至 UE侧设备； 所述 UE侧 RRC实体， 用于接收所述网络侧 RRC实体发送的 R C 状态转换命令， 将 UE侧设备状态转换为公共信道状态， 并根据预设的 缺省组播无线承载参数建立组播无线承载；
所述 UE侧 RLC实体，用于在所述公共信道上接收所述网络侧 RLC 承载在所述逻辑信道的组播数据。
12、 根据权利要求 11所述的系统， 其特征在于，
所述预先建立的网络侧设备和 UE侧设备间的逻辑信道为： 逻辑信 道标识为 15的逻辑信道；
所述 RRC状态转换命令携带无线接入承载 RAB标识， 所述 RAB 标识表示要建立组播无线承载；
所述网络侧设备进一步包括标识单元， 用于针对每一个组播流媒体 业务分配组无线网络临时标识 G-R TI， 且在公共信道上映射承载组播 数据的逻辑信道时， 在 MAC PDU中携带 UE侧设备所请求的组播流媒 体业务对应的 G-RNTI; 所述 UE侧设备进一步包括识别单元， 用于从所述公共信道中接收 承载在逻辑信道的组播数据时， 在 MAC PDU中获取 G-RNTI, 并判断 与自身的 C-RNTI是否属于所述 G-RNTI所表示的組播组， 如果是， 则 指示所述 UE侧 RLC实体接收对应的组播数据。
13、 根据权利要求 11所述的系统， 其特征在于，
所述在网络侧设备和 UE 侧设备间所预先建立的逻辑信道为 MTCH;
所述 RRC状态转换命令中携带 RAB标识， 所述 RAB标识表示要 建立组播无线承载；
所述 RRC状态转换命令中进一步携带 MBMS-Id, 所述 MBMS-Id 的值为 UE侧设备所请求的组播流媒体业务的 MBMS-Id;
所述网络侧设备进一步包括设置单元， 用于将承载组播数据的 MTCH 的 MBMS-Id设置为 UE侧设备所请求的组播流媒体业务的 MBMS-Id;
所述 UE 侧设备进一步包括判断单元， 用于从承载组播数据的 MTCH 中获取 MBMS-Id, 并判断与所述 RRC状态转换命令中携带的 MBMS-Id是否相同 , 如果是， 则指示所述 UE侧 RLC实体接收对应的 组播流媒体业务数据。
14、 一种提供组播承载的网络侧设备， 其特征在于， 包括 RRC实体 和 RLC实体，
所述 RRC实体，用于向请求组播流媒体业务的 UE侧设备发送 RRC 状态转换命令， 指示 UE侧设备转换为公共信道状态；
所述 RLC 实体， 用于将组播数据承载在预先建立的网络侧设备和 UE侧设备间的逻辑信道， 并映射在公共信道传输至 UE侧设备。
15、 根据权利要求 14所述的网络侧设备， 其特征在于， 所述预先建立的网络侧设备和 UE侧设备间的逻辑信道为： 逻辑信 道标识为 15的逻辑信道；
所述 RRC状态转换命令携带无线接入承载 RAB标识， 所述 RAB 标识表示要建立组播无线承载；
所述网絡侧设备进一步包括标识单元， 用于针对每一个组播流媒体 业务分配组无线网络临时标识 G-RNTI, 且在公共信道上映射承载組播 数据的逻辑信道时， 在 MAC PDU中携带 UE侧设备所请求的组播流媒 体业务对应的 G-RNTI。
16、 根据权利要求 15所述的网络侧设备， 其特征在于，
该设备进一步包括重分配单元， 用于根据所述 UE侧设备所请求的 组播流媒体业务对应的 G-R TI,判断所述 UE侧设备的 C-RNTI是否属 于所述 G-RNTI所表示的组播组， 如果不是， 则重新给该 UE侧设备分 配属于所述组播组的 C-RNTI。
17、 根据权利要求 14所述的网络侧装置， 其特征在于，
所述在网络侧设备和 UE 侧设备间所预先建立的逻辑信道为 MTCH;
所述 RRC状态转换命令中携带 RAB标识， 所述 RAB标识表示要 建立组播无线承载；
所述 RRC状态转换命令中进一步携带 MBMS-Id, 所述 MBMS-Id 的值为 UE侧所请求的组播流媒体业务的 MBMS-Id;
所述网络侧设备进一步包括设置单元， 用于将承载组播数据的 MTCH 的 MBMS-Id设置为 UE侧设备所请求的组播流媒体业务的 MBMS-Id。
PCT/CN2007/001011 2006-03-30 2007-03-28 Procédé, système et appareil de prise en charge de multidiffusion WO2007112670A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200610070976.1 2006-03-30
CNB2006100709761A CN100544462C (zh) 2006-03-30 2006-03-30 一种提供组播承载的方法与系统

Publications (1)

Publication Number Publication Date
WO2007112670A1 true WO2007112670A1 (fr) 2007-10-11

Family

ID=38563104

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/001011 WO2007112670A1 (fr) 2006-03-30 2007-03-28 Procédé, système et appareil de prise en charge de multidiffusion

Country Status (2)

Country Link
CN (1) CN100544462C (zh)
WO (1) WO2007112670A1 (zh)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101867871B (zh) * 2009-04-17 2013-02-13 电信科学技术研究院 一种选择逻辑信道进行数据处理的方法、系统和设备
CN102123486B (zh) * 2010-01-11 2014-07-09 电信科学技术研究院 数据发送及终端操作方法、系统和设备
CA2832067C (en) * 2011-04-01 2019-10-01 Interdigital Patent Holdings, Inc. Method and apparatus for controlling connectivity to a network
EP2739076B1 (en) * 2011-08-31 2016-08-03 Huawei Technologies Co., Ltd. Method, system and device for implementing multicast in shared network
CN103999525B (zh) * 2011-12-06 2017-12-22 华为技术有限公司 状态迁移处理方法和设备
US9781652B2 (en) * 2015-02-05 2017-10-03 Mediatek Inc. Method and apparatus of LWA PDU routing
CN104602201B (zh) * 2015-02-09 2017-11-07 重庆邮电大学 Lte集群专网中单终端同时接收多组呼业务的方法
WO2016161655A1 (zh) * 2015-04-10 2016-10-13 华为技术有限公司 一种多播业务传输装置及方法
CN108347784B (zh) * 2017-01-23 2023-10-13 华为技术有限公司 一种资源调度方法以及无线接入网设备和终端设备
EP3588848B1 (en) 2017-03-17 2021-09-01 Huawei Technologies Co., Ltd. Network data processing method and apparatus
WO2021142702A1 (en) * 2020-01-16 2021-07-22 Mediatek Singapore Pte. Ltd. Methods and apparatus of uplink feedback and retransmission for nr multicast services
CN113950042A (zh) * 2020-07-17 2022-01-18 维沃移动通信有限公司 识别方法、发送方法及相关设备
CN114070482B (zh) * 2020-07-31 2023-04-07 大唐移动通信设备有限公司 业务传输的处理方法、装置、网络侧设备及终端
CN114071567B (zh) * 2020-08-06 2024-04-23 中国移动通信有限公司研究院 数据传输方法、终端及网络节点

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1476260A (zh) * 2002-08-16 2004-02-18 ��������ͨ�ż����о����޹�˾ 多媒体广播与组播业务点对点信道和点对多点信道的转换方法
US20040116125A1 (en) * 2002-08-07 2004-06-17 Interdigital Technology Corporation Channel switching for support of multimedia broadcast and multicast services
EP1507364A2 (en) * 2003-07-30 2005-02-16 Samsung Electronics Co., Ltd. Apparatus and method for establishing header compression context according to channel type change in packet data service
WO2005022812A1 (en) * 2003-08-21 2005-03-10 Qualcomm Incorporated Methods for forward error correction coding above a radio link control layer and related apparatus
CN1694546A (zh) * 2004-05-07 2005-11-09 三星电子株式会社 提供多媒体广播/组播业务通告的装置和方法
CN1736124A (zh) * 2003-01-08 2006-02-15 艾利森电话股份有限公司 为在蜂窝移动通信系统中的小区之间移动的用户设备供应多媒体广播/多播业务(mbms)

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040116125A1 (en) * 2002-08-07 2004-06-17 Interdigital Technology Corporation Channel switching for support of multimedia broadcast and multicast services
CN1476260A (zh) * 2002-08-16 2004-02-18 ��������ͨ�ż����о����޹�˾ 多媒体广播与组播业务点对点信道和点对多点信道的转换方法
CN1736124A (zh) * 2003-01-08 2006-02-15 艾利森电话股份有限公司 为在蜂窝移动通信系统中的小区之间移动的用户设备供应多媒体广播/多播业务(mbms)
EP1507364A2 (en) * 2003-07-30 2005-02-16 Samsung Electronics Co., Ltd. Apparatus and method for establishing header compression context according to channel type change in packet data service
WO2005022812A1 (en) * 2003-08-21 2005-03-10 Qualcomm Incorporated Methods for forward error correction coding above a radio link control layer and related apparatus
CN1694546A (zh) * 2004-05-07 2005-11-09 三星电子株式会社 提供多媒体广播/组播业务通告的装置和方法

Also Published As

Publication number Publication date
CN100544462C (zh) 2009-09-23
CN101047881A (zh) 2007-10-03

Similar Documents

Publication Publication Date Title
WO2007112670A1 (fr) Procédé, système et appareil de prise en charge de multidiffusion
US20210219105A1 (en) Communications method and apparatus
WO2021063133A1 (zh) Harq进程管理方法、装置、终端及存储介质
WO2020020209A1 (zh) 一种通信方法及装置
JP2014511168A (ja) 移動体通信ネットワークおよび方法
WO2013010420A1 (zh) 一种无线宽带通信方法，装置和系统
WO2007090321A1 (fr) Procédé, dispositif et réseau local sans fil pour établissement d'une liaison virtuelle et procédé de transfert de données
JP3984994B2 (ja) コンテキストリンクのスキーム
WO2011150774A1 (zh) 一种多个无线接入网聚合系统及其实现方法
BRPI0615128A2 (pt) método para transmissão e recepção de um serviço de mbms em sistema de comunicação móvel
TW202215873A (zh) 層2使用者設備透過網路中繼進行信令傳輸的方法
WO2012167743A1 (zh) 无线局域网与无线广域网互操作方法、用户设备和基站
WO2011095037A1 (zh) 一种传输保活信息的方法和设备
WO2007009370A1 (fr) Méthode pour établir des canaux de trafic inverse et terminal d’accès
WO2015013869A1 (zh) 传输机制的转换方法、用户设备以及基站
WO2010031347A1 (zh) 多播组播单频网资源配置方法、装置和系统
WO2018059269A1 (zh) 消息的识别方法和装置
WO2009076864A1 (zh) 点到多点gtp隧道的建立方法、网络设备
WO2015062287A1 (zh) 终端的本地交换方法及系统
WO2009039772A1 (fr) Procédé pour créer un canal de transmission de plan utilisateur du service de diffusion/multidiffusion multimédia
WO2009067912A1 (fr) Procédé et dispositif de commutation pour mettre en œuvre une commutation
WO2014067371A1 (zh) 集群业务实现方法、系统及网元
US9265071B2 (en) Signalling method for direct communication between terminals
JP2023062188A (ja) 通信制御方法、ユーザ装置、プロセッサ及び基地局
WO2013102450A1 (zh) Tcp数据包的处理方法和设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07720585

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07720585

Country of ref document: EP

Kind code of ref document: A1