KR20050046483A - Method and apparatus for providing multimedia broadcast/multicast service on point to point mode - Google Patents

Abstract

The present invention relates to a method and apparatus for providing an MBMS service to a plurality of cells in a mobile communication system. The wireless network controller may include: PTP processing chains corresponding to the number of terminals to receive the MBMS service located in cells to be serviced in PTP mode; one PTM processing chain corresponding to cells to be serviced in PTM mode; The upper layer data including the user data for the MBMS service is referred to by identifiers indicating service access locations (SAPs) with lower layer devices corresponding to terminals of the PTP processing chains and the PTM processing chain. A copy and distributor for copying the total number and distributing to the PTP and PTM processing chains. This invention makes it possible to provide a more efficient multimedia broadcasting / multicast service in a wireless network controller and prevents unnecessary system resource equipment.

Description

METHOD AND APPARATUS FOR PROVIDING MULTIMEDIA BROADCAST / MULTICAST SERVICE ON POINT TO POINT MODE}

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a multimedia broadcast / multicast service (hereinafter referred to as MBMS service) for a mobile communication system. In particular, the present invention relates to a MBMS service in a point to point (PtP) mode using a dedicated channel. A method and apparatus for providing a.

Universal Mobile Telecommunication Service (UMTS) is based on the Global System for Mobile communication (GSM) and General Packet Radio Services (GPRS) communication standards, but unlike wideband CDMA, which uses time division multiple access (TDMA) It uses technology and provides a consistent service that enables mobile phone or computer users to transmit packet-based text, digitized voice or video and multimedia data at high speeds of 2 Mbps and beyond, anywhere in the world. UMTS uses the concept of virtual access, which is a packet-switched connection that uses a packet protocol such as Internet Protocol (IP), and can always be connected to any other end in the network.

FIG. 1 is a block diagram illustrating a UMTS Terrestrial Radio Access Network (hereinafter referred to as UTRAN) of UMTS (Universal Mobile Telecommunications Services), which is one of third generation mobile communication.

Referring to FIG. 1, the UTRAN 102 includes a plurality of cells 110, 114, 122, 126, node Bs 108, 112, 120, 124, and a radio network controller (hereinafter referred to as RNC) 106, 118. Equipment (hereinafter referred to as UE) 128 is connected to the core network 100. Under the UTRAN 102 there may be a plurality of RNCs 106, 118, a plurality of Node Bs 108, 112, 120, 124 and a plurality of cells 110, 114, 122, 126, each RNC 106, 118 having a corresponding lower Node Bs 108, 112, 120, 124. ), And each Node B (108, 112, 120, 124) controls the corresponding lower cells (110, 114, 122, 126).

One RNC and Node Bs and cells controlled by the RNC are collectively referred to as a Radio Network Subsystem (hereinafter referred to as RNS). RNC and Node B are connected via Iub interface, and RNC and RNC are connected through Iur interface.

The RNC allocates or manages radio resources of Node Bs it controls. Node B serves to provide the actual radio resources. The radio resource is configured for each cell, and the radio resource provided by the node B means radio resources of cells managed by the node B. The terminal may configure a radio channel and perform communication by using a radio resource provided by a specific cell of a specific Node B. From the point of view of the terminal, the distinction between the Node B and the cell is meaningless, and since only the physical layer configured for each cell is recognized, the Node B and the cell will be referred to as the same meaning.

The interface between the terminal and the RNC is called a Uu interface, and its detailed hierarchical structure is shown in FIG. The Uu interface, like the aforementioned Iu interface or Iub interface, is regarded as a protocol stack configured to perform communication between nodes, where a control plane is used to exchange control signals between the terminal and the RNC. And the user plane (User Plane) used to transmit the actual data will be described.

Referring to FIG. 2, the control plane 200 includes a radio resource control (RRC) layer 202, a radio link control (RLC) layer 210, a media access control (MAC) layer 212 and a physical: A PHY layer 214 exists here, and the user plane 202 has a Packet Data Control Protocol (PDCP) layer 206, a Broadcast / Multicast Control (BMC) layer 208, an RLC layer 210, and a MAC. There is a layer 212, a physical layer 214. Among the layers shown here, the physical layer 214 is located in each cell, and the MAC layer 212 to the RRC layer 204 are located in the RNC.

The physical layer 214 is a layer that provides an information transmission service using a radio transfer technology, and corresponds to a first layer of an Open Systems Interconnection (OSI) model. The physical layer 214 and the MAC layer 212 are connected by transport channels, which are defined by the manner in which specific data is processed in the physical layer.

The MAC layer 212 and the RLC layer 210 are connected through a logical channel. The MAC layer 212 transmits the data delivered by the RLC layer 210 through the logical channel to the physical layer through the appropriate transport channel, and the data transmitted by the physical layer 214 through the transport channel through the appropriate logical channel. It serves to deliver to the RLC layer 210. In addition, by inserting additional information into the data received through the logical channel or the transport channel or by analyzing the inserted additional information to take appropriate action, and controls the random access operation.

The RLC layer 210 is responsible for establishing and releasing logical channels. The RLC layer 210 may operate in one of three operation modes such as an acknowledgment mode (AM), an unacknowledged mode (UM), and a transparent mode (TM), and provide different functions for each operation mode. In general, the RLC layer 210 is responsible for dividing or assembling a service data unit (hereinafter referred to as SDU) from an upper layer into an appropriate size, and for correcting an error through an automatic repeat request (ARQ). .

The PDCP layer 206 is located above the RLC layer 210 in the user plane 202. The PDCP layer 206 compresses and restores headers of data transmitted in the form of IP packets, and provides RNC services to specific terminals with mobility. It is responsible for the lossless transfer of data, etc. under the situation that is changed. The PDCP layer 206 is responsible for lossless SRNS relocation support and header compression in the case of a normal service, but in the case of MBMS service, a lossless SRNS (Serving RNS) replay is required due to the characteristics of broadcast / multicasting. There is no need to support allocation. Here, SRNS reassignment refers to a process in which a UE moved to a cell controlled by another RNC other than the SRNC resets the other RNC to the SRNC. The BMC layer 208 is located above the RLC layer 210 and supports a broadcast service for transmitting the same data to a plurality of unspecified terminals in a specific cell.

In the process of establishing a call for a specific service, the RNC configures Entities that perform protocol processing of each of PDCP / RLC / MAC / PHY layers for providing the service, which is configured to provide a specific service. The set of protocol entities is called a radio bearer (RB). Each of these entities may consist of separate software execution blocks and will be used interchangeably in the same sense throughout the specification. In addition, an access point between the protocol entities is SAP (Service Access Point), for example, the contact point between the PDCP and RLC is called RLC SAP. Through the RLC SAP, primitives such as RLC-DATA-REQ, which are user data transferred from PDCP to RLC, are delivered.

The RRC layer 204 is responsible for allocating and releasing radio resources between the UTRAN and the terminal. The RRC layer 204 manages radio resources allocated to terminals in an RRC connected mode, manages mobility of the terminals, and delivers core network signals to the terminals to be transmitted to the terminals. Etc.

In the UMTS communication system described above, the configuration of protocol entities configured between the terminal and the RNC is based on a one-to-one (Point to Point) connection between the RNC and the terminal. In the case of a multimedia broadcast / multicast service (hereinafter referred to as MBMS service) in which the same multimedia data is transmitted to multiple receivers through a wireless network, a plurality of receivers share one radio channel for wireless transmission. You can save resources. For the MBMS service, the PDCP layer 206 is only responsible for the functions related to header compression and decompression. Since the MBMS service is transmitted only in the forward direction, the header compression function is located in the RNC and the header decompression function is located in the terminal.

In the case of the MBMS service, since one RNC transmits the same data to multiple terminals and consequently transmits the same data to multiple cells in which the terminals are located, the RNC and the terminals are one-to-many (Point to Multiple:). Connection may be made). As such, the MBMS service is different from the existing unicast service in which one RNC transmits data to one terminal. Like the existing service, one PDCP object, one RLC object, and one MAC object per radio bearer. Using the PHY entity with the PHY object causes a problem that the service delay is greatly increased while simultaneously wasting system resources.

On the other hand, MBMS data is expected to be transmitted until the cell boundary (boundary), since it must be provided so that all UEs in the cell can receive. In order to transmit data having a transmission rate of about 64 kbps until the cell change, approximately 30% of the transmission output of the cell should be used. Since excessive transmission output is required to provide the MBMS service, many techniques have been proposed to solve this problem, and one of them is outer coding.

In a typical wireless communication system, channel encoding is performed at the physical layer. A method of obtaining a stronger encoding gain by performing encoding at a separate layer is called additional encoding. If additional coding is used, the required transmission power is expected to be reduced by 20% based on the 64 kbps transmission rate. Although not shown in FIG. 2, a transmission / reception system providing an MBMS service uses a separate layer called a Forward Error Correction (FEC) layer on top of an RLC layer to perform additional encoding.

The FEC layer on the transmitting side encodes data from an upper layer (ie PDCP layer) and delivers the data to the other side through the lower layer (ie, RLC / MAC layer and physical layer). The FEC layer on the receiving side decodes the received data from the lower layer and delivers it to the upper layer.

Typically, a processing chain (processing chain) consisting of a user plane FEC / RLC / MAC layer and PHY layers is configured per cell in which a UE is located. At this time, the FEC / RLC / MAC layer is located at the RNC and the PHY layer is located at the Node B. In the case of an MBMS service, UEs intended to receive the service are located across several cells and the processing chain is configured for all the cells separately to deliver MBMS data to all of the cells.

As described above, in the conventional structure, FEC layers are provided for a plurality of cells providing MBMS services to the RNC, and thus the RNC performs the FEC operation several times. However, in the case of MBMS service, since one RNC transmits the same data to multiple terminals and consequently the same data to multiple cells in which the terminals are located, the actual operation of the FEC layers is the same.

As such, although the MBMS service is different from the existing unicast service in which one RNC transmits data to one terminal, multiple FEC layers for one MBMS service in one RNC, like the existing service, are provided. Has a problem that increases service delay while simultaneously wasting system resources.

In addition, as described above, the radio network controller (RNC) provides the MBMS service in the PTP mode using the dedicated channels and the PTM mode using the common channel according to the number of terminals to receive the MBMS service located in each cell. Can provide services. Therefore, there is a need for a method for providing a MBMS service in a PTP mode in a radio network controller (RNC).

Therefore, in order to solve the problems of the prior art operating as described above, the present invention, in configuring a radio bearer for the MBMS service of the PTP mode in a mobile communication system providing a multimedia broadcasting / multicast (MBMS) service A method and apparatus for reducing the processing load of an RNC are provided.

The present invention provides a method and operation of one shared PDCP entity connected to a plurality of RLC entities / MAC entities / PHY entities to provide MBMS services.

The present invention provides a method and apparatus for reducing the processing load according to the FEC operation of the RNC by configuring only one FEC layer per service in configuring the FEC layer of the RNC for processing MBMS data.

The present invention provides a method and apparatus for providing an MBMS service in a PTP mode in an RNC that processes MBMS data.

An embodiment according to the first aspect of the present invention, which is invented to achieve the above object, includes a wireless network controller and a plurality of base stations connected to the wireless network controller and communicating with terminals located in a plurality of cells. In the mobile communication system comprising: providing a multimedia broadcasting / multicast (MBMS) service to the plurality of cells by the radio network controller,

Determining cells to be served in a PTP mode and cells to be served in a PTM mode according to the number of terminals to receive the MBMS service for each cell;

Receive upper layer data including user data for the MBMS service and copy the upper layer data by the number of terminals to receive the MBMS service located in cells to be serviced in the PTP mode, and correspond to the terminals. And distribution to the PTP processing chains.

In accordance with a second aspect of the present invention, a wireless network controller includes a wireless network controller and a plurality of base stations connected to the wireless network controller and communicating with terminals located in a plurality of cells. Is,

PTP processing chains corresponding to the number of terminals that want to receive the MBMS service located in cells to be serviced in a PTP mode;

One PTM processing chain corresponding to the cells to be served in PTM mode,

The PTP processing chains and the PTM processing are performed on upper layer data including user data for the MBMS service with reference to identifiers indicating service access locations (SAPs) with lower layer devices corresponding to the plurality of terminals. And a copy and distributor for copying and distributing the total number of chains to the PTP and PTM processing chains.

Hereinafter, with reference to the accompanying drawings will be described in detail the operating principle of the preferred embodiment of the present invention. In the following description of the present invention, detailed descriptions of well-known functions or configurations will be omitted if it is determined that the detailed description of the present invention may unnecessarily obscure the subject matter of the present invention. Terms to be described later are terms defined in consideration of functions in the present invention, and may be changed according to intentions or customs of users or operators. Therefore, the definition should be made based on the contents throughout the specification.

The present invention to be described later in the configuration of the MBMS Radio Bearer (RB) for processing MBMS data on the Uu interface between the RNC and the terminal, even if the MBMS radio bearer is formed over a plurality of cells by using only one PDCP entity The structure of the MBMS radio bearer can reduce the processing load of the RNC. Here, the MBMS radio bearer is defined as a set of FEC / RLC / MAC / PHY layers that process MBMS data transmitted through the Iu interface to be transmitted on the Uu interface.

In addition, another embodiment of the present invention, in configuring an MBMS Radio Bearer (RB) for processing MBMS data on the Uu interface between the RNC and the terminal, even if the MBMS radio bearer is formed over multiple cells, one FEC By using only the object, the structure of the MBMS radio bearer can reduce the processing load of the RNC.

First, the MBMS service applied to the present invention will be described.

3 shows a simplified configuration diagram of a mobile communication system for an MBMS service. Here, an example of applying a MBMS service to a 3GPP (3rd Generation Project Partnership) system, which is a standard of third generation asynchronous mobile communication, is illustrated.

Referring to FIG. 3, the terminals 361, 362, 363, 371, and 372 denote terminal devices or subscribers capable of receiving MBMS service, and cell 1 360 and cell 2 370 are subscribers. Means a base station apparatus for transmitting MBMS-related data. As shown, only one radio channel for MBMS service is configured between cell 1 360 and terminals 361, 362, 363. The RNC 340 refers to a wireless network controller that controls a plurality of cells, selectively transmits multimedia data to a specific cell, and controls a radio channel configured to provide MBMS service. do.

The Serving GPRS Supporting Node (SGSN) 330 controls MBMS related services of respective subscribers. Typically, the SGSN 330 manages service charging related data of each subscriber and selectively transmits multimedia data to a specific RNC. The Transit Network 320 is responsible for providing a communication path between the Broadcast / Multicast Service Center (BM-SC) 310 and the SGSN 330, and the Gateway GPRS Support Node (GGSN) and the external network. And the like. The BM-SC 310 is a source of MBMS data and is responsible for scheduling data for each service.

The MBMS data stream is delivered to terminals 361, 362, 363, 371, 372 via the transport network 320, SGSN 330, RNC 340, cells 360, 370. Although not shown in the figure, there may be multiple SGSNs for one MBMS service and multiple RNCs for each SGSN. SGSN is an RNC, and the RNC needs to perform selective data transmission to cells, and for this purpose, a list of targets (a list of RNCs in SGSN and a list of cells in RNC), etc., to be transferred to the data stream, is stored later. Selective MBMS data transmission is performed to the targets.

FIG. 4 is a message flow diagram illustrating an MBMS service procedure, in which only a signal flow between a terminal receiving an MBMS service and an RNC and SGSN is used to describe a procedure in which an MBMS service is provided in a specific cell.

Referring to FIG. 4, in step 400, the SGSN transmits basic information about a specific MBMS service to a UE through the RNC 211, for example, the specific MBMS service identifier and available information of the MBMS service. Announcement. If there is a service to be received from among the MBMS services recognized through the announcement process 400, in step 410, the terminal informs SGSN that the UE joins the MBMS service through the RNC.

In the joining process 410, the terminal notifies the SGSN of an identifier of the MBMS service to be received by the terminal and notifies the terminal whether the MBMS service can be received after the SGSN performs authentication or the like, thereby requesting activation of the MBMS context. (ACTIVATE MBMS CONTEXT REQUEST) message and the MBMS Context Activation Accept (ACTIVATE MBMS CONTEXT ACCEPT) message exchange. The SGSN stores a list and locations of terminals to receive a specific MBMS service through the join process 410.

In the future, when the BM-SC notifies the start of the MBMS service, in step 415, the SGSN transmits a session start message to the RNC in which the terminal that performed the join process 410 is located. In step 420, the RNC transmits a PAGING message using a common channel such as a secondary common control channel (S-CCPCH) to call the terminal to receive the MBMS service. Since a plurality of terminals joining the MBMS service are called through the transmission of the MBMS paging message, the process 420 is referred to as group paging in a sense that is different from the existing paging procedure.

In step 430, the terminal transmits a response message (MBMS PAGING RESPONSE) for the call. Through the transmission process 430 of the response message, the RNC determines the number of terminals to receive the MBMS service for each cell and determines the type (ie, service type) of a radio channel of the corresponding cell. That is, if the number of terminals to receive the MBMS service is not smaller than a predetermined predetermined threshold value, the MBMS service is provided through a common channel by a point-to-multipoint (hereinafter referred to as PtM) method. A dedicated channel is configured for each terminal by a Point (hereinafter referred to as PtP) scheme, and the MBMS service is provided in step 430. The process 430 is performed by exchanging control messages between the RNC and the terminal, It can be done with control message exchange.

If the service type is determined to be PtP, the MBMS service proceeds in the same procedure as the existing unicast service. However, when the service type is determined to be PtM, a connection configuration for transmitting data from a specific RNC to a plurality of terminals should be made. Hereinafter, a service procedure when the PtM transmission is determined will be described.

In step 433, the RNC configures an MBMS radio bearer (RB) to be transmitted to a plurality of terminals including the terminal. The MBMS radio bearer information indicates information related to a data path to which an MBMS service is to be provided. Specifically, the MBMS radio bearer information means information on a processing chain including PDCP / FEC / RLC / MAC / PHY layers.

In step 435, the RNC transmits configuration information of the MBMS radio bearer to a plurality of terminals including the terminal through an MBMS Control Channel (MCCH). The MBMS radio bearer information is radio channel information to be provided with MBMS service, for example, Orthogonal Variable Spreading Factor (OVSF) code information, transport format information, and radio link control (hereinafter referred to as RLC). Information, packet data convergence control (hereinafter referred to as PDCP) information, and the like.

Typically, only one MCCH is configured per cell and is mapped to a common channel such as S-CCPCH. The terminals acquire the information received through the MCCH as system information. In step 440, the terminal receives MBMS data provided according to the MBMS radio bearer information.

<< first embodiment >>

UTRAN delivers data for one service through a hierarchical structure called PDCP / RLC / MAC / PHY. At this time, the RDCP / RLC / MAC layer is located in the RNC and the PHY layer is located in the Node B. In the case of the MBMS service, terminals wishing to receive the same MBMS service may be located in multiple cells, so in this case, MBMS data should be delivered to all of the cells.

However, it may be very inefficient to configure PDCP / RLC / MAC / PHY entities for each cell for MBMS service. In fact, the MBMS data provided to the RNC from the upper network element (SGSN, etc.) is processed the same up to the PDCP layer and then differently depending on the corresponding cells from the lower layer. Therefore, in the present invention, only one PDCP entity is configured in one RNC for one MBMS service and each operation is performed for each cell in lower entities.

One of the main data processing tasks in PDCP entities is the compression and decompression of headers. In MBMS service over IP network, MBMS data becomes IP / UDP (User Datagram Protocol) / Real-time Transfer Protocol (RTP) packet. The most important application of MBMS service is multimedia streaming service and multimedia streaming service in IP network. This is because the most influential way of providing IP is IP / UDP / RTP. Since the IP / UDP / RTP packet includes the IP header, the UDP header, and the RTP header, the total size of the header reaches 40 to 60 bytes, and the burden is too great to be transmitted over the air.

The PDCP entity removes the static fields from the header of the data packet to be transmitted, compresses them to a few bytes, passes them to lower layer RLC entities, and transmits the compressed header of the received data packet to a pre-stored header context. Restore it with reference to). For the MBMS service, a header compression scheme called ROHC (Robust Header Compression) is used. Accordingly, the PDCP entity processing the MBMS data includes a ROHC header compressor and a decompressor. The same header compression scheme is used for the same MBMS service. This is because a plurality of terminals receive the corresponding MBMS data.

5A and 5B illustrate a configuration of performing header compression in a PDCP entity.

First, FIG. 5A illustrates a configuration in which each PDCP entity is used for each cell. Each PDCP entity has header compressors 510, 515, 520 to process MBMS data to send to the corresponding cell. If the header compressors 510, 515, and 520 provided for each cell are configured to process the same MBMS data, the MBMS data through the Iu interface is equally input to all the compressors 510, 515, and 520. Header compressors 510, 515, 520 compress the MBMS data according to the same header compression protocol. Then, the header compressed data output from the header compressors 510, 515, and 520 are the same.

5B illustrates a configuration in which a header of the MBMS data 500 is compressed using one header compressor 540 and then delivered to each cell. In this case, one PDCP entity is used for multiple cells, but the data 525, 530, and 535 to which the RLC entities of each cell are transmitted are the same.

That is, the result of using one header compressor (FIG. 5B) and using multiple header compressors per cell (FIG. 5A) are the same. Therefore, in the present invention, only one header compression device and a PDCP entity are configured for a specific MBMS service.

6 shows an MBMS radio bearer (RB) structure of an RNC according to a first embodiment of the present invention. Here, a structure for broadcasting data of a specific MBMS service through n cells is shown.

Referring to FIG. 6, the MBMS RB 605 includes PHY entities 645-1, 645-2,... 645-n configured for n cells to which the MBMS data 650 is to be transmitted. MAC entities 640-1, 640-2, ... 640-n, RLC entities 635-1, 635-2, ... 635-n, and a shared PDCP entity 615. It is composed of Since the other entities except the PDCP entity 615 operate in the same manner as the existing ones, a detailed description thereof will be omitted.

PDCP entity 615 includes three sub-entities: header compressor 620, PDCP header attacher 625, and copy and distribution unit (CDU) 630. It consists of. The header compressor 620 compresses the header of the data packet received through the lu interface, referring to the pre-stored RRC / MBMS context 655, and delivers the header to the PDCP header inserter 625. The PDCP header inserter 625 inserts a PDCP header into the data provided from the header compressor 620 and transmits the PDCP header to the copy / distributor 630. The copy / distributor 630 copies the data transmitted from the PDCP header inserter 625 as necessary, and then the RLC entities 635-1, 635-2, ... 635-n configured for each cell. The MAC entities 640-1, 640-2,... 640-n are transmitted to the PHY entities 645-1, 645-2,.

7 illustrates in more detail the structure of a PDCP entity for transmitting MBMS data to a plurality of cells according to the first embodiment of the present invention.

Referring to FIG. 7, the PDCP entity receives a PDCP-DATA-REQ primitive 705 including data of an arbitrary MBMS service through an Iu interface, and then transfers the RLC-DATA- to RLC Service Access Points (SAPs). Constructs a REQ primitive. Here, SAP means a connection location between the PDCP layer and the RLC layer. In other words, passing data through a specific SAP is the same as passing data to the corresponding RLC entity.

In more detail, the PDCP-DATA-REQ primitive 705 transmitted through the Iu interface is composed of a protocol header and user data of an upper layer. The upper layer protocol may be RTP / UDP / IP or UDP / IP, but for the convenience of description, it is referred to as RTP / UDP / IP. User data means data to be transmitted to the actual terminals through the Uu interface. For example, video data may correspond to this.

The PDCP-DATA-REQ 705 is input to a header compressor 710. The header compressor 710 compresses the RTP / UDP / IP header included in the PDCP-DATA-REQ according to a previously promised header compression protocol, and then delivers the compressed header and user data to the PDCP header inserter 720. do. The header compressor 710 performs header compression using, for example, ROHC or RFC2507. The header compressor 710 determines a header compression protocol to be used according to the instruction of the RRC layer in the process of setting up the MBMS RB. One PDCP entity configures a header compressor for each service, and information about each header compressor is known to a receiver through a PDCP header field described later.

The PDCP header inserter 720 inserts one byte of the PDCP header into the data 715 transmitted from the header compressor 710 to output the RLC-DATA-REQ primitive 725. The RLC-DATA-REQ primitive 725 includes PDCP data consisting of a PDCP header, a compressed header, and user data. The PDCP header consists of a Protocol Datagram Unit (PDU) type field and a Packet Identifier (PID) field. The PDU type field is a field for distinguishing whether the RLC-DATA-REQ primitive 725 is data compressed according to a header compression protocol or data containing additional information for supporting lossless SRNS reallocation. When the RLC-DATA-REQ primitive 725 is compressed data according to a header compression protocol, the PID field is a field including additional information related to header compression. For example, the protocol of the header compression protocol used and the CID (Context Identifier) value representing the identifier of the header context (HC) are inserted into the PID field.

The copy / distributor 730 copies the RLC-DATA-REQ 725 as necessary and transfers the copied data to RLC entities configured for each cell. Since the RLC-DATA-REQ primitive 725 is copied and distributed in the same form, the RLC-DATA-REQ primitives output from the copy / divider 730 are the same as the RLC-DATA-REQ primitive 725.

The copy / distributor 730 determines the RLC entities to which the RLC-DATA-REQ will be delivered using the RLC SAP list provided from the RRC layer during the MBMS RB setup. The RRC layer connects the PDCP layer and the RLC layer by informing the RLC SAP information of the RLC layer to be connected to the PDCP layer during the RB setup. In the case of MBMS RB, one PDCP entity and a plurality of RLC entities should be connected, so the RRC layer delivers the RLC SAP list to the PDCP layer in the process of configuring the MBMS RB. The RLC SAP list includes SAP identifiers of RLC entities organized by cell. The SAP identifier is used inside the RNC or the terminal and is determined to clearly distinguish the RLC entities in the device.

After the RNC receives call response messages from terminals wishing to receive a particular MBMS, the RNC decides to provide the MBMS service to cells in which the terminals are located and sends information determined for the MBMS service to the MBMS context (655 of FIG. 6). Save as). The MBMS context stores information related to a specific MBMS service, for example, a list of terminals wanting to receive a specific MBMS service, a list of cells to provide a specific MBMS service, and PHY entity information for each cell (code information and frequency). Information, etc.), RLC entity and MAC entity information for each cell (for example, information of a transport format combination), PDCP entity information, and the like are included in the MBMS context.

The RNC configures the MBMS RB by referring to the list of cells which should provide the MBMS service of the MBMS context. Configuring the MBMS RB means configuring PHY entities, MAC entities, and RLC entities for each cell to which the MBMS service is to be provided, and configuring one PDCP entity. Here, PHY entities are configured in Node Bs corresponding to respective cells. At this time, the RNC configures RLC entities to provide MBMS services to each cell, and then generates an RLC SAP list with the SAP identifiers of the configured RLC entities. RLC SAP identifiers are defined to clearly distinguish between RLC entities configured in one RNC. When the RNC completes the generation of the RLC SAP list, the RNC starts constructing the PDCP entity.

8 is a flowchart illustrating an operation of configuring a shared PDCP entity for one MBMS service according to the first embodiment of the present invention. This is an operation performed by the RNC after generating the RLC SAP list by referring to the MBMS context.

Referring to FIG. 8, in step 805, the PDCP layer receives a CPDCP-CONFIG-REQ primitive from an RRC layer. The primitive includes parameters such as PDCP header information, header compression information, and RLC SAP list. The header compression information indicates information necessary for the configuration of the header compressor, the PDCP header indicates information necessary for the configuration of the PDCP header inserter, and the RLC SAP list indicates information necessary for the configuration of the copy / distributor.

In step 810, the PDCP layer configures a header compressor using the header compression parameter. The parameter includes the type of header compression protocol and information necessary for configuring a header compressor using the protocol. For example, if a ROHC header compressor is to be configured, the header compression parameter includes configuration information related to ROHC, that is, profiles to be supported by the header compressor, and a maximum value of a CID to be used for header compression. The profile refers to protocols that ROHC can compress, that is, IP / UDP / RTP or IP / UDP. The ROHC header compressor can be configured to support one or more of the three types of profiles.

In step 815, the PDCP layer configures a PDCP header inserter using the PDCP header parameter. The PDCP header parameter indicates whether a PDCP header is configured or has a value of present or not present. If the PDCP header parameter is set to the configuration, the PDCP header inserter is configured. If the PDCP header parameter is not configured, the PDCP header inserter is not configured.

In step 820, the PDCP layer completes the configuration of the PDCP entity by configuring a copy / distributor using the RLC SAP list. The RLC SAP list includes identifiers of RLC SAPs to which the copy / distributor should establish a connection, and the PDCP layer establishes a connection with the RLC SAPs included in the RLC SAP list.

9 is a flowchart illustrating an operation of processing MBMS data in a PDCP entity configured according to the first embodiment of the present invention.

Referring to FIG. 9, when the MBMS data arrives at the RNC through the lu interface in step 905, the MBMS data is delivered to the PDCP entity in the form of a PDCP-DATA-REQ primitive. The PDCP-DATA-REQ primitive includes an RTP / UDP / IP header and user data and is passed to a header compressor that is a sub-object of the PDCP entity.

In step 910, the header compressor compresses the RTP / UDP / IP header included in the primitive, using a pre-defined header compression protocol such as ROHC, and passes the compressed header and the user data to a PDCP header inserter. do.

In step 915, the PDCP header inserter inserts a PDCP header including a PDU type field and a PID field into the received data. The data processed in the PDCP header inserter is called an RLC-DATA-REQ primitive. If no PDCP header inserter is configured at the time of PDCP entity configuration, the process 915 is skipped and the data processed by the header compressor is an RLC-DATA-REQ primitive.

In step 920, the copy / distributor copies the received RLC-DATA-REQ primitive N times. In this case, N means the number of RLC entities that will deliver the RLC-DATA-REQ. In step 925 the copy / distributor forwards the copied N RLC-DATA-REQ primitives through the connected RLC SAPs. The N RLC-DATA-REQ primitives are transmitted through corresponding RBs each consisting of an RLC layer, a MAC layer, and a PHY layer.

A feature of the MBMS radio bearer structure according to the first embodiment of the present invention is that the RLC and its lower layer entities are configured one per cell, while only one PDCP entity is configured to be shared by the lower entities, thereby making the header a PDCP entity. The compression operation is executed only once, which reduces the processing load of the RNC.

For example, when a plurality of terminals are receiving any MBMS service in cells A, B, and C, the RNC provides one PDCP entity, three RLC entities, three MAC entities, and three to provide the MBMS service. After configuring a radio bearer composed of PHY entities, MBMS data is transmitted to each cell through the radio bearer. In this case, when a new terminal requests to receive the MBMS service in a new cell D, the RNC newly configures an RLC entity, a MAC entity, and a PHY entity to process data to be transmitted to the cell D. The SAP identifier of the configured RLC entity is included and delivered to the PDCP layer of the MBMS service. The PDCP layer establishes a connection between the RLC layer and the copy / distributor and transmits an RLC-DATA-REQ to a new cell through the newly configured subordinate entities.

All header compression protocols operate correctly under the condition that the header compressor and decompressor share the basic information necessary for header compression and decompression. In RFC 2507, a full header packet and an ROHC, an Initializing & Refresh (IR) packet or an IR-DYN (Initializing & Refresh Dynamic) packet, inform the basic information. The basic information must be transmitted from the header compressor to the header decompressor before the actual header compression and decompression operation is performed. In the case of ROHC, the header compressor initially transmits the IR packet several times to convey basic information to the header decompressors of the terminals. The IR packet including the basic information only needs to be transmitted to the new terminal that has requested the MBMS service in the cell D. In the PDCP layer according to the present invention, these special packets are distinguished and selectively transmitted to the specific cell by the RLC-DATA-REQ primitive.

The basic information necessary for the header compressor and the header decompressor of the PDCP layer to normally proceed with the header compression operation and the header decompression operation includes a static part and a dynamic part. The static part and the dynamic part represent respective field values of headers to be compressed and decompressed, wherein the static part means values of fields that do not change, and the dynamic part means values of fields that change. The IR packet is transmitted for header compression and decompression using ROHC, and includes the static part and the dynamic part. An IR-DYN packet is a packet used when it is necessary to retransmit the values of the dynamic part.

For convenience of description, a case of transmitting an IR packet and an IR-DYN packet of the ROHC protocol will be described. However, the configuration and operation of the present invention described below should be transmitted to a specific cell and a specific terminal for MBMS service. Of course, it can be applied to the transmission of the control packet.

10 illustrates in detail the structure of a PDCP entity for selectively transmitting MBMS control packets according to the first embodiment of the present invention. Here, when the PDCP layer receives a CPDCP-CONFIG-REQ primitive 1010 including an IR / IR-DYN indicator 1015 and an RLC SAP identifier 1025 from an RRC layer, the IR / IR-DYN indicator 1015 It passes to the compressor 710 and the RLC SAP identifier 1025 passes to the copy / distributor 730. The IR / IR-DYN indicator 1015 is information indicating whether a control packet to be selectively transmitted to a specific cell is IR or IR-DYN, and the RLC SAP identifier 1025 is information of a cell to transmit the IR or IR-DYN packet. Information that identifies the SAP of the RLC entity.

Referring to FIG. 10, when the compressor 710 receives the IR / IR-DYN indicator 1015, the compressor 710 generates an IR or IR-DYN packet according to the value of the indicator 1015 to generate the IR / IR-DYN indicator. And to the PDCP header inserter 720 with 1015. The PDCP header inserter 720 inserts a PDCP header into the data 1020 transferred from the compressor 710 to generate an RLC-DATA-REQ primitive 1030 and the generated RLC-DATA-REQ primitive 1030. To the copy / distributor 730. The RLC-DATA-REQ primitive 1030 includes the PDCP header and an IR or IR-DYN packet and the IR / IR-DYN indicator 1015.

The copy / distributor 730 confirms that the IR / IR-DYN indicator 1015 is included in the received RLC-DATA-REQ primitive 1030 and through the RLC SAP indicated by the RLC SAP identifier 1025. Delivering the RLC-DATA-REQ primitive 1030. If the IR / IR-DYN indicator 1015 was not received together, the copy / distributor 730, as already mentioned, has the RLC-DATA-REQ primitive 1030 through all the RLC SAPs indicated by the RLC SAP list. ).

As described above, the RRC layer informs the CPDCP-CONFIG-REQ primitive of the type of packet to be transmitted to a specific cell and the RLC SAP identifier of the cell to transmit the packet, so that the PDCP entity transmits the specific RLC-DATA-REQ only through the corresponding RLC SAP. do.

<< 2nd Example >>

Prior to describing the second embodiment of the present invention, additional coding and additional decoding operations performed by the FEC layer will be briefly described. As described above, the additional encoding means that a stronger encoding gain is obtained by performing the encoding once more in a separate layer other than the physical layer. On the receiving side, additional decoding is used to perform the decoding more efficiently.

11 is a diagram illustrating (n, k) additional encoding and additional decoding operation to which the second embodiment of the present invention is applied.

Referring to FIG. 11, the FEC layer responsible for additional encoding at the transmitting side includes k data blocks (or MBMS payloads, PDUs (Packet Data Units) (PDUs) 1100 through 1) having the same size as the data transmitted from the upper layer. 1120, and (n, k) encoding is performed on each column of the k data blocks separately. That is, (n, k) encoding is performed on the bits of the same position of each data block. As a result, (n-k) parity blocks 1125 to 1130 composed of only parity bits are generated. The physical layer on the transmitting side performs channel coding on the n data blocks (k original blocks and nk parity blocks) separately, adds predetermined Cyclic Redundancy Codes (CRCs), and transmits them to the receiving side. .

The physical layer on the receiving side performs channel decoding on the data blocks and discards the data blocks in which an error occurs through a CRC operation. For example, if an error occurs in the second data block 510, the data block is discarded in the physical layer. The physical layer transfers the blocks that pass the CRC test to the FEC layer responsible for further decoding, and discards the blocks that do not pass the CRC test.

The FEC layer on the receiving side reconstructs the received blocks into the original n blocks 1150 to 1175. Blocks discarded because they do not pass the CRC test are considered erasure bits (1155 in the example shown). For example, if the 2nd and 6th blocks do not pass the CRC test, the FEC layer has 2 The code words at the sixth and sixth positions are considered to be the remove bit.

The remove bit is a bit that an error occurs during transmission and the receiver cannot determine its value. The receiving FEC layer can perform additional decoding more efficiently by knowing the exact location of the removal bits. For example, when the RS (Reed Soloman) code of (16, 12) is used as the additional coding, when the receiving side FEC layer correctly locates the removal bits, the error of 4 bits can be corrected. On the other hand, if the location of the removal bits is not known correctly, only one or two bits of error are corrected.

As described above, decoding that knows and performs the position of the removal bits correctly is referred to as removal decoding, and removal decoding is used as additional decoding corresponding to the additional encoding proposed to support MBMS. To this end, the transmitting FEC layer assigns a sequence number to each data block.

When the FEC layer of the receiving side is capable of performing additional decoding, that is, when k original blocks and n-k parity blocks are all received, the FEC layer performs error correction through additional decoding on each column of the blocks. Error corrected data blocks are passed to the upper layer.

Hereinafter, an additional encoding and an additional decoding operation for an MBMS service will be described with an example. Here, (16,12) RS codes are used, and the size of each block is assumed to be 100 bits.

1. The transmitting FEC layer waits until 1200 bits of data arrive from the upper layer.

2. The transmitting FEC layer reconstructs 1200 bits of data into 12 100 bit blocks.

3. The transmitting side FEC layer performs (16, 12) RS encoding on the bits of the same position of each block on the basis of the column, thereby generating four 100-bit parity blocks.

4. The transmitting side FEC layer inserts sequence number information into the original block and parity blocks, and delivers the sequence number information to the physical layer.

5. The transmitting physical layer performs channel encoding and CRC operation on each block transmitted from the transmitting FEC layer and transmits the data through the wireless channel.

6. The receiving physical layer performs channel decoding and CRC operation on the received blocks, and transfers the blocks that succeeded in the CRC test to the upper layer and discards the failed blocks.

7. The receiving side FEC layer interprets the serial number of blocks delivered by the physical layer and rearranges each block in order. In this case, blocks determined to be lost during transmission are replaced with removal bits of a predetermined value.

8. The receiving side FEC layer executes (16, 12) RS decoding operations on each column of the blocks, and delivers 1200 bits of corrected data to the upper layer.

For reference, if the number of removal bit blocks is greater than or equal to a predetermined number, the receiving side FEC layer determines that decoding is impossible and immediately transfers data to an upper layer without performing decoding.

12 illustrates a structure of an FEC layer to which a second embodiment of the present invention is applied.

Referring to FIG. 12, a service data unit (SDU), which is upper layer data, is transmitted from a higher layer SAP (Service Access Point) 1295 to a transmitting side FEC layer 1205. Here, SAP means a point of contact used for data exchange between layers. The data transferred from the upper layer SAP is stored in the SDU buffer 1215 until it is sufficient to perform additional encoding.

When a sufficient amount of data is received through the upper layer SAP, the data is divided into a predetermined size in a segmentation & concatenation block 1220. This segmentation operation is because the SDUs transmitted from the upper layer do not have a constant size, but additional encoding is performed on blocks of a constant size. Information, such as a length indicator, is inserted into the divided blocks so that the receiver can restore the original SDU.

The additional encoder block 1225 performs an additional encoding operation as described above. If (16,12) RS coding is used, 16 blocks are output from the additional encoder block 1225. In sequence add block 1230, a sequence number is assigned to sixteen blocks from the add encoder block 1225. The transmit buffer 1235 is stored until the serialized blocks are delivered to the lower layer through the RLC SAP 1240.

Data delivered to the receiving side FEC layer through the RLC SAP 1240 is stored in the receiving buffer 1245 for reordering and duplicate detection. The receive buffer 1245 rearranges the received data blocks using the sequence numbers assigned to the data blocks and detects the redundant blocks.

The rearrangement operation includes replacing a block that has not been received with removal bits. For example, if a block having a serial number of x is not received, the reception buffer 1245 replaces the block with removal bits and stores the block at a position corresponding to the serial number of x. Redundancy detection refers to an operation of detecting blocks having the same serial number. That is, when the same block is received several times on the wireless channel due to a transmission error or the like, this operation detects this and discards the overlapping blocks.

Remove sequence number 1250 removes a serial number inserted into the rearranged blocks. The additional decoder block 1255 performs an additional decoding operation as described above to correct an error of the received data. The SDU buffer / assembly block 1260 reconstructs the blocks in which the error is corrected into the original SDU using a length indicator and the like, and then transfers the blocks to the upper layer.

13 shows the structure of a processing chain configured for processing MBMS data in the RNC. As described above, the processing chain refers to a set of protocol entities through which data of a specific service passes.

Referring to FIG. 13, an FEC entity 1315, an RLC entity 1320, a MAC entity 1325, and a PHY entity 1330 configured to process data to be transmitted to cell 1 are processed in an MBMS service chain for cell 1. Configure Similarly, the FEC entity 1335, RLC entity 1340, and MAC entity 1345 compose a processing chain of MBMS services for cell x.

Herein, an operation of the RNC processing MBMS data will be described with reference to FIG. 13. When the MBMS service is provided with x cells from cell 1 to cell x, the operation for cell 1 will be described below.

When the MBMS data is provided in the form of an IP packet, when IP packets 1305 for a specific MBMS service arrive at the RNC, the upper layer 1310 of the RNC performs protocol processing of the corresponding layer for the IP packets. After performing the operation, the number of cells to provide MBMS data is copied and delivered to the FEC / RLC / MAC layers configured for each cell. In this case, the upper layer 1310 may be a PDCP layer or another upper layer that is responsible for IP header compression. However, since the upper layer 1310 is not directly related to the present invention, a detailed description thereof will be omitted.

The FEC layer 1315, which processes the data to be provided to the cell 1, reconfigures the IP packets to a predetermined size, performs an operation such as additional encoding, assigns a sequence number, and transmits the sequence number to the RLC layer 1320. The RLC layer 1320 stores the data in a buffer until a separate request is made at the MAC layer 1325.

The MAC layer 1325 performs scheduling of data stored in the RLC layer 1320 in consideration of channel conditions of the corresponding cell. That is, when data from the RLC layer 1320 can be transmitted, a request is made to deliver data to the RLC layer 1320, a protocol processing of a layer corresponding to the received data is performed, and then a physical body configured in the corresponding cell is provided. Transfer to layer 1330. The physical layer 1330 performs channel encoding and modulation on data received from the MAC layer 1325 and transmits the data on the wireless channel through a common channel.

Among the UEs located in the cell 1, UEs that want to receive the MBMS service receive data through the common channel. Data received through the common channel is passed to the upper layer after passing through the physical layer / MAC / RLC / FEC layer of the UE.

As described above, the UTRAN delivers data for one service through a hierarchical structure called PDCP / FEC / RLC / MAC / PHY. At this time, the PDCP / FEC / RLC / MAC layers are located in the RNC and the PHY layer is located in the Node B. In the case of the MBMS service, terminals wishing to receive the same MBMS service may be located in multiple cells, so in this case, MBMS data should be delivered to all of the cells.

However, configuring the FEC entities for each cell for the MBMS service can be very inefficient. In fact, the MBMS data provided to the RNC from the upper network element (SGSN, etc.) are all processed identically in the FEC layers configured for the plurality of cells.

Referring to FIG. 13, when the plurality of FEC layers corresponding to the plurality of cells are configured, the operation of the FEC layer FEC_1 for the cell 1 is as follows.

1. Reconstruct MBMS data into blocks of constant size x_1 bits.

2. When 12 blocks are collected, additional encoding is performed.

3. Assign sequence numbers to 16 blocks generated by additional encoding.

4. Deliver the blocks to the RLC layer RLC_1 configured for cell 1.

In addition, the operation of the FEC layer (FEC_2) for the cell 2 is as follows.

1. Reconstruct MBMS data into blocks of constant size x_2 bits.

2. When 12 blocks are collected, additional encoding is performed.

3. Assign sequence numbers to 16 blocks generated by additional encoding.

4. Forward the blocks to the RLC layer RLC_2 configured for cell 2.

Here, considering that the MBMS data input to the FEC layers of Cell 1 and Cell 2 are the same data and use the same additional coding scheme in each FEC layer, the operation of the FEC layer for Cell 1 and the FEC layer for Cell 2 The operation of is the same except below.

The FEC layer of cell 1 constitutes blocks of x_1 bit size, and the FEC layer of cell 2 constitutes blocks of x_2 bit size. In addition, the FEC layer of cell 1 delivers blocks to RLC_1, and the FEC layer of cell 2 delivers blocks to RLC_2.

However, the sizes x_1 and x_2 of blocks reconstructed in the FEC layers are parameters determined by the RNC and there is no reason to have different values for each cell. Therefore, if the size of the reconstructed block is the same for all cells for any service, the first, second, third operation of the FEC layer is the same for all cells. Therefore, rather than performing the same operations of the FEC layer for each cell separately, performing a common service for one service increases the processing capability of the RNC.

As described above, the operation of the FEC layer is the same for all cells for the same service, but the RLC layer, the MAC layer, and the PHY layer perform different operations for each cell. Herein, operations of the RLC layer, the MAC layer, and the PHY layers will be briefly described.

Since the PHY layer should encode MBMS data into a scrambling code defined for each cell and a channelization code defined for each physical channel, the PHY layer takes different operations for each cell. Therefore, each cell must be composed of separate objects.

The MAC layer adds a MAC header to MBMS data, and cell-specific information is inserted into the MAC header. For example, service identifier information unique to each cell may be inserted in the header. Therefore, the MAC layer takes different operations for each cell and must be configured as a separate entity for each cell.

The RLC layer is involved in cell-specific scheduling through mutual control information exchange with the MAC layer. Since the scheduling is performed based on the channel condition of each cell, the RLC layer should be configured separately for each cell. In more detail, the RLC layer reports the amount of data stored at any point in time to the MAC layer, and the MAC layer determines scheduling based on data conditions of various RLC layers and channel conditions at that time, and RLC Notify the amount of data to send to the layer, the RLC layer delivers that amount of data to the MAC layer. Since the scheduling operation is performed for each cell separately, the RLC layer should be configured separately for each cell.

In other words, the RLC / MAC / PHY layer must be configured for each cell. However, as described above, only one FEC layer may be configured for a service. Accordingly, the present invention proposes a processing chain structure consisting of one FEC entity and a plurality of RLC / MAC / PHY entities as a radio bearer structure for one MBMS service.

14 shows the structure of a processing chain configured in the RNC for processing MBMS data according to the second embodiment of the present invention. As shown, the processing chain according to the present invention configures one FEC layer 1415 in order to transmit MBMS data to a plurality of cells, and configures the FEC layer 1415 per cell in an RLC / MAC / PHY layer. 1420, 1425, and 1430, the RNC performs the FEC operation only once for one MBMS service.

Referring to FIG. 14, the FEC layer 1415 reconstructs the IP packet stream 1405 delivered by the upper layer 1410 to a predetermined size through division or concatenation, performs additional encoding, and inserts x numbers by inserting sequence numbers. Transfer to RLC / MAC / PHY layers 1420, 1425, 1430 configured for each of the cells.

FIG. 15 shows a detailed structure of the FEC layer shown in FIG. Here, the functions of the SDU buffer 1215, the division / concatenation block 1220, the additional encoder 1225, the sequence number addition block 1230, and the transmission buffer 1235 are the same as in the prior art, and thus detailed descriptions thereof are omitted.

The copy / distribution block 1540 receives the data blocks from the transmission buffer 1235, copies the number of cells to which MBMS data is to be transmitted, and delivers them to RLC entities configured for each cell. Here, the RLC entities to which the data is to be delivered are determined using the RLC SAP list received from the RRC layer during the MBMS radio bearer setup.

As described above, the point of contact between the FEC and the RLC is called an RLC SAP, and the RRC connects the FEC entity and the RLC entity by informing the RLC SAP of the RLC entity to be connected to the FEC entity in the process of establishing a radio bearer. However, in the case of MBMS, one FEC entity and a plurality of RLC entities must be connected, so the RLC entities deliver the RLC SAP list to the FEC entity in the process of establishing the MBMS radio bearer.

The RLC SAP list includes SAP identifiers of RLC entities organized by cell. The SAP identifier is an identifier used inside the RNC or the UE, and is defined to clearly distinguish the RLC entities in the device.

The copy / distribution block 1540 performs only distribution after copying the received data without modifying it. Thus, the data delivered to copy and distribution block 1540 at 1537 and the data delivered via RLC SAPs at 1545 are the same data.

As shown in FIG. 4 described above, the RNC configures an MBMS radio bearer in step 433. Configuring the MBMS radio bearer means that the RNC configures the RLC entity, the MAC entity, and the PHY entity for each cell to which the MBMS service is to be provided, and configures one FEC entity. Whether a specific MBMS service is provided to which cells is determined in step 430, and such information is stored in an MBMS context managed by the RNC.

The MBMS context stores information related to a specific MBMS service. For example, a list of UEs that want to receive a specific MBMS service or a list of cells to provide a specific MBMS service is stored in the MBMS context.

The RNC configures RLC entities to provide services to each cell by referring to the 'list of cells to provide MBMS services' in the MBMS context, and then generates an RLC SAP list by collecting the SAP identifiers of the configured RLC entities. The RNC starts configuring the FEC entity when the configuration of the RLC entities is completed.

16 is a flowchart illustrating an operation of configuring a shared FEC entity for one MBMS service according to an embodiment of the present invention.

Referring to FIG. 16, in step 1605, the RRC entity delivers configuration information of the FEC layer to the FEC entity. The configuration information includes a PDU size and an RLC SAP list.

In step 1610, the FEC entity configures a split / contiguous block and an SDU buffer using PDU size information. The PDU size information means the size of a block to be reconstructed by the split / contiguous block. When the RS encoding of (16, 12) is used, the FEC entity delivers the PDU size multiplied by 12 to the SDU buffer, and the SDU buffer is stored among the stored SDUs when the data more than the received value is stored. Transfer the remaining SDUs except for the last SDU to the split / contiguous block.

Then, the SDU buffer stores the SDUs delivered by the upper layer. When the amount of data stored exceeds a certain level, the SDU buffer transfers the SDUs to the split / contiguous block. Upon receiving the PDU size information, the split / contiguous block reconstructs the SDUs received from the SDU buffer according to the PDU size.

For example, if the PDU size is 300 bits, the FEC entity carries 3600 bits of data into the SDU buffer. Thereafter, the SDU buffer receives and stores SDUs from an upper layer. When the total number of stored SDUs is 3600 bits or more, the SDU buffer transfers the remaining SDUs except the last SDU to the split / contiguous block. For example, if 10 SDUs are stored in the SDU buffer and the total is 3550 bits, a 100-bit SDU arrives. The SDU buffer divides / concatenates 10 SDUs except the last SDU of 100-bit size. To pass. The division / concatenation block divides the remaining 50 bits short of 3600 bits after zero-padding.

In step 1615, the FEC entity configures an additional encoder block, a sequence number adder block, and a transmission buffer. That is, the sequence number adder block initializes the sequence number to zero. The sequence number is incremented by one each time one block is received.

In step 1620, the FEC entity constructs a copy / distribution block using the RLC SAP list. Since the RLC SAP list contains the identifiers of the RLC SAPs to which the copy / distribution block should establish the connection, the FEC entity establishes the connection between the RLC SAPs contained in the RLC SAP list and the copy / distribution block. Thereafter, the copy / distribution block copies the data received from the transmission buffer by the number of RLC SAPs included in the RLC SAP list and delivers the data to the RLC entities through the respective RLC SAPs.

<< third embodiment >>

While the first and second embodiments of the present invention described above were a method for efficiently configuring a PTM processing chain for cells that provide MBMS service to a PTM, the third embodiment of the present invention is a method in which an RNC uses a PTM. In addition to the processing chain, the present invention relates to a scheme for configuring processing chains of a PTP.

The 3GPP communication system provides a MBMS service using a dedicated channel when the number of terminals in a cell is small. This is to improve the efficiency of radio resources. For example, if only one terminal in a cell wants to receive a specific MBMS service, if the common channel is used, the transmission output control is not performed, so the MBMS data is transmitted as an output that will reach the end of the cell, and thus Waste of resources is inevitable. On the other hand, in such a situation, if MBMS data is separately transmitted to each terminal using a dedicated channel through which transmission output is controlled, it may be more efficient than using a common channel.

As described above, a method of providing MBMS data using a dedicated channel is called PTP, and a method of providing MBMS data using a common channel is called PTM.

17 illustrates two transmission modes of an MBMS communication system applied to a third embodiment of the present invention. Here, when three or more terminals in a cell want to receive a specific MBMS service, the MBMS service is provided to the PTM.

Referring to FIG. 17, when the SGSN 1705 transmits MBMS data to the RNC 1710, the RNC 1710 transmits the MBMS data to cells 1720 and 1725 that provide MBMS services according to a PTM. At the same time, the MBMS data is transmitted to a cell 1715 receiving MBMS service through PTP. In cell A 1715, there are only two terminals UE1 and UE2 that receive the MBMS service, so that the terminals UE1 and UE2 receive the MBMS service through PTP by establishing a dedicated channel. On the other hand, since there are three or more terminals that receive the MBMS service in cell B and cell C, the terminals receive the MBMS service through PTM.

The RNC 1710 transmits the MBMS data received from the SGSN 1705 to the PTP data in order to transmit the MBMS data to the UEs receiving the MBMS service through the PTP, such as the UEs UE1 and UE2 located in the cell A 1715. Distribute to processing chains to process.

18 illustrates a structure of a processing chain configured in an RNC for processing MBMS data according to a third embodiment of the present invention.

Referring to FIG. 18 above, the RNC 1805 has a PTP / PTM copy and distributor 1810. The PTP / PTM copy and distributor 1810 copies MBMS data (MBMS data_Iu) arriving through the Iu interface by the number of terminals receiving the MBMS service, and then configures PTP processing chains 1815 and 1820. Equally).

The PTP / PTM copy and distributor 1810 also copies the MBMS data and forwards it to the PTM processing chain 1825. The PTM processing chain 1825 may be RLC / MAC / PHY entities configured for each PDCP and cell as in the first embodiment described above. Alternatively, as in the above-described second embodiment, there may be one PDCP entity and RLC / MAC / PHY entities configured for each cell and FEC entity.

The PTP processing chains 1815 and 1820 convert MBMS data arriving through the Iu interface into data to be transmitted through dedicated channels for PTP transmission, and like the PTM processing chain, PDCP / RLC / MAC / PHY or PDCP / FEC / RLC / MAC and the like. However, the PTP processing chains 1815 and 1820 always include only one entity except the PHY.

An operation according to a third embodiment of the present invention will now be described with reference to FIGS. 4 and 18 mentioned above.

Prior to providing a specific MBMS service, the RNC determines the cells to serve the MBMS with the PTM and the cells to serve the MBMS through the PTP through the MBMS PAGING 420 and PAGING RESPONSE 430 processes. For the cells that will serve MBMS with the PTM, PTM processing chains are constructed according to the first or second embodiment of the present invention. The PTM processing chain receives the MBMS data (MBMS data_Iu) delivered by the PTP / PTM copy and distributor, and delivers the MBMS data through common channels configured for each cell.

The RNC configures a PTP processing chain for each of the terminals located in the cells for the cells to provide MBMS to the PTP. The PTP processing chain takes MBMS data delivered by the PTP / PTM copy and distributor, and outputs MBMS data to be transmitted through a dedicated channel allocated to the terminal. The PTP processing chain consists of PDCP / RLC / MAC / PHY or PDCP / FEC / RLC / MAC / PHY.

Referring to FIG. 17, one PTM processing chain is configured for cell B 1720 and cell C 1725, and a PTP processing chain is configured for terminal 1 and terminal 2, respectively. In the PTP processing chain and the PTM processing chain, the PHY entity is located in the corresponding cells, and the other PDCP / FEC / RLC / MAC, etc. are located in the RNC.

When the PTP / PTM copy and distributor and PTM and PTP processing chains are configured for a specific MBMS service as described above, user data of the MBMS service is then input to the PTP / PTM copy and distributor through the Iu interface. A PTP / PTM copy and distributor copies and transfers the input data to the PTM processing chain, while copying and transferring the input data to the PTP processing chains. The transferred data is converted by each processing chain, and then transmitted through a dedicated channel configured for each terminal in the case of PTP and a common channel configured for each cell in the case of PTM.

As described above, one PTP / PTM copy and splitter is configured for each service, and serves to copy the required number of MBMS data delivered through the Iu interface, and then deliver it to the appropriate processing chains. The following describes the process of configuring a PTP / PTM copy and distributor.

First, the RNC configures the PTP processing chains and the PTM processing chain for providing a specific MBMS service. The RNC determines terminals located in a cell determined to receive MBMS service through PTP through MBMS PAGING and PAGING RESPONSE processes, and then configures one PTP processing chain per terminal for the terminals. One PTM processing chain is configured in the RNC according to the second or third embodiment of the present invention described above.

The PTP / PTM copy and distributor receives SAPs of PTP processing chains and SAPs of PTM processing chain. As described above, the SAP refers to an identifier that can uniquely identify a specific protocol entity within a device. The input of the PTP / PTM copy and distributor is connected to the lu bearer on which the MBMS data is transmitted. The Iu bearer refers to a path through which data is transmitted between the SGSN and the RNC, and is identified as a GPRS Tunnel Protocol (GTP) tunnel end point.

The PTP / PTM copy and distributor sets the number of times to copy MBMS data according to the total number of the PTP processing chains and the PTM processing chain. The PTP / PTM copy and distributor then copies the MBMS data received via the Iu bearer for the set number of times and then transfers the MBMS data to the PTP processing chains and the PTM processing chain.

Meanwhile, in the detailed description of the present invention, specific embodiments have been described, but various modifications are possible without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined not only by the scope of the following claims, but also by those equivalent to the scope of the claims.

In the present invention operating as described in detail above, the effects obtained by the representative ones of the disclosed inventions will be briefly described as follows.

The present invention is to provide a plurality of processing chains corresponding to a plurality of terminals receiving MBMS data in PTP mode to process MBMS data in PTP mode in providing an MBMS service in a radio network controller (RNC). And copying and distributing MBMS data in the distributor to the plurality of processing chains to effectively support the multimedia broadcast / multicast service.

1 is a block diagram of a wireless access network for a conventional multimedia broadcasting / multicast service

2 is a hierarchical diagram illustrating an interface between a terminal and a radio network controller (RNC).

3 is a diagram illustrating a configuration of a mobile communication system for an MBMS service.

4 is a message flow diagram illustrating an MBMS service procedure.

5A and 5B illustrate the configuration of a PDCP entity that performs header compression.

6 illustrates an MBMS radio bearer (RB) structure of an RNC according to a first embodiment of the present invention.

7 is a diagram showing in more detail the structure of a PDCP entity for transmitting MBMS data to a plurality of cells according to a first embodiment of the present invention.

8 is a flowchart illustrating an operation of configuring a shared PDCP entity for one MBMS service according to the first embodiment of the present invention.

9 is a flowchart illustrating an operation of processing MBMS data in a PDCP entity configured according to the first embodiment of the present invention.

10 is a diagram showing in detail the structure of a PDCP entity for selectively transmitting MBMS control packets according to the first embodiment of the present invention.

11 is a diagram illustrating (n, k) additional encoding and additional decoding operation to which a second embodiment of the present invention is applied.

12 is a structural diagram of an FEC layer to which a second embodiment of the present invention is applied;

FIG. 13 shows the structure of a processing chain configured for processing MBMS data in an RNC. FIG.

14 is a structural diagram of a processing chain configured in an RNC for processing MBMS data according to a second embodiment of the present invention.

FIG. 15 is a diagram showing a detailed structure of an FEC layer shown in FIG. 14;

16 is a flowchart illustrating an operation of configuring a shared FEC entity for one MBMS service according to the second embodiment of the present invention.

FIG. 17 is a view showing two transmission modes of an MBMS communication system applied to a third embodiment of the present invention. FIG.

18 is a structural diagram of a processing chain configured in an RNC for processing MBMS data according to a third embodiment of the present invention.

Claims (13)

In a mobile communication system including a wireless network controller and a plurality of base stations connected to the wireless network controller and communicating with terminals located in a plurality of cells, the multimedia broadcasting / multicast to the plurality of cells by the wireless network controller In the method of providing a (MBMS) service, Determining cells to be served in a PTP mode and cells to be served in a PTM mode according to the number of terminals to receive the MBMS service for each cell; Receive upper layer data including user data for the MBMS service and copy the upper layer data by the number of terminals to receive the MBMS service located in cells to be serviced in the PTP mode, and correspond to the terminals. And distributing to the PTP processing chains. The method of claim 1, wherein the dispensing process, The identifiers indicating service access locations (SAPs) with lower layer devices corresponding to the plurality of terminals. The method of claim 1, wherein each of the PTP processing chains are: The method comprising a PDCP entity, an RLC entity, a MAC entity, and a physical layer entity. The method of claim 1, wherein each of the PTP processing chains are: The method comprising a PDCP entity, an FEC entity, an RLC entity, a MAC entity, and a physical layer entity. 2. The method of claim 1, further comprising transferring the higher layer data to one PTM processing chain corresponding to cells to be serviced in the PTM mode. The method of claim 5, wherein the PTM processing chain, And a plurality of RLC / MAC / PHY entities corresponding to one PDCP entity and cells to be served in the PTM mode. The method of claim 5, wherein the PTM processing chain, And a plurality of RLC / MAC / PHY entities corresponding to one PDCP entity, one FEC entity and cells to be served in the PTM mode. In a mobile communication system including a wireless network controller and a plurality of base stations connected to the wireless network controller to serve terminals located in a plurality of cells, the wireless network controller transmits a multimedia broadcast / multicast to the plurality of cells. In a method of configuring processing chains for providing MBMS) services, Determining cells to be served in a PTP mode and cells to be served in a PTM mode according to the number of terminals to receive the MBMS service for each cell; Configuring PTP processing chains corresponding to the number of terminals to receive the MBMS service located in cells to be served in the PTP mode; Configuring one PTM processing chain corresponding to cells to be served in the PTM mode; The PTP processing chains and the PTM processing are performed on upper layer data including user data for the MBMS service with reference to identifiers indicating service access locations (SAPs) with lower layer devices corresponding to the plurality of terminals. And copying and distributing the number of chains and distributing them to the PTP and PTM processing chains. In a mobile communication system including a wireless network controller and a plurality of base stations connected to the wireless network controller and communicating with terminals located in a plurality of cells, the wireless network controller includes: PTP processing chains corresponding to the number of terminals that want to receive the MBMS service located in cells to be serviced in a PTP mode; One PTM processing chain corresponding to the cells to be served in PTM mode, The PTP processing chains and the PTM processing are performed on upper layer data including user data for the MBMS service with reference to identifiers indicating service access locations (SAPs) with lower layer devices corresponding to the plurality of terminals. And a copy and divider for copying and distributing the total number of chains to the PTP and PTM processing chains. 10. The method of claim 9, wherein each of the PTP processing chains is: And a PDCP entity, an RLC entity, a MAC entity, and a physical layer entity. 10. The method of claim 9, wherein each of the PTP processing chains is: The wireless network controller comprising a PDCP entity, an FEC entity, an RLC entity, a MAC entity, and a physical layer entity. The method of claim 9, wherein the PTM processing chain, And a plurality of RLC / MAC / PHY entities corresponding to one PDCP entity and cells to be served in the PTM mode. The method of claim 5, wherein the PTM processing chain, And a plurality of RLC / MAC / PHY entities corresponding to one PDCP entity, one FEC entity, and cells to be served in the PTM mode.