KR20060086697A - Method for Delivery of Header Compression Information for MBMS Service - Google Patents

Abstract

The present invention relates to a multimedia / multicast broadcasting service, and more particularly, to a method of helping to determine whether to use a header compression method for an MBMS service delivered in an IP packet form in an RNC. For each service, SGSN provides information to help determine whether header compression is performed in UTRAN, and SGSN forwards this information to the RNC. The RNC uses the above information to determine whether header compression is performed between the UE and the RNC, and accordingly, creates a PDCP entity and transmits the determined information to the UE, thereby enabling smooth transmission of MBMS data between the RNC and the UE.

MBMS, Header Compression, PDCP, ROHC (Robust Header Compression)

Description

A Transmission Method Of Informaiton On Header Compression For MBMS}             

1 is a diagram illustrating a network configuration for a general multicast multimedia broadcasting service.

2 is a message flow diagram between BM-SC, SGSN, RNC and UE according to a preferred embodiment of the present invention.

3 illustrates the operation of an RNC in accordance with a preferred embodiment of the present invention.

4 is a diagram illustrating operation of a UE according to a preferred embodiment of the present invention.

The present invention relates to a multimedia multicast / broadcast service (hereinafter referred to as MBMS), and in particular, header compression (Header compression) for a MBMS service delivered in the form of an IP packet from a radio network controller (RNC). Compression) relates to a method of transmitting header compression information for determining whether to use.

Due to the development of communication technology, the services provided by the mobile communication system using the Wide Band Code Division Multiple Access (WCDMA) scheme are not only conventional voice services but also large data volumes. It is developing into a packet service communication that transmits and a multimedia broadcast / communication capable of transmitting a multimedia service. Accordingly, in order to support the multimedia broadcasting / communication, an MBMS service that provides a service from one or more multimedia data sources to a plurality of user equipments (hereinafter referred to as 'UE') has been discussed.

The MBMS service refers to a service for transmitting the same multimedia data to multiple receivers through a wireless network. In this case, it is possible to save radio transmission resources by allowing multiple receivers to share one radio channel. The MBMS service supports multimedia transmission forms such as real-time video, audio, still images, and text. The MBMS service is a service that can simultaneously provide audio data and video data according to the multimedia transmission format, and requires a large amount of transmission resources. In the case of the MBMS service, since the same data must be transmitted to a plurality of cells in which users are located, one-to-one (Point to Point: 'PtP') or one-to-many depending on the number of users located in each cell. : Hereinafter called 'PtM') Connection is made.

1 is a diagram schematically illustrating nodes participating in providing an MBMS service in a mobile communication network. Here, a configuration example of applying MBMS service to 3GPP (3rd Generation Project Partnership) system, which is a standard of 3G asynchronous mobile communication based on Global System for Mobile Communications (GSM) and General Packet Radio Services (GPRS), is shown.

Referring to FIG. 1, UEs 161, 162, 163, 171, and 172 refer to terminal devices or subscribers capable of receiving MBMS service, and cell 1 160 and cell 2 170 provide subscribers. A base station apparatus for wirelessly transmitting MBMS-related data, that is, a physical or logical service area controlled by the Node B.

The RNC 140 controls the plurality of cells 160 and 170, selectively transmits multimedia data to a specific cell, and controls a radio channel configured to provide MBMS services. The connection between the RNC 140 and the UEs 161 to 172 is connected to a Radio Resource Control (hereinafter referred to as 'RRC') interface. The RNC 140 is referred to as a Packet Switched or Packet Service (hereinafter referred to as 'PS') by the Serving GPRS Support Node (hereinafter referred to as 'SGSN') 130. It is connected to a network. Communication between the RNC 140 and the PS network is made by packet switched signaling (hereinafter, referred to as 'PS signaling'). In particular, the connection between the RNC 140 and the SGSN 130 is called an Iu-PS interface.

SGSN 130 controls the MBMS-related services of each subscriber. Representative examples of the role played by the SGSN 130 include managing the service-related data of each subscriber and selectively transmitting multimedia data to a specific RNC 140.

Transit NW 120 provides a communication path between Broadcast Multicast Service Center (hereinafter referred to as BM-SC) 110 and SGSN 130, which is not shown. However, it may be connected to the external network through a gateway packet wireless service support node (hereinafter referred to as 'GGSN'). The BM-SC 110 is responsible for scheduling MBMS data and providing MBMS data as a source of MBMS data.

On the other hand, the RNC 140 is connected to a circuit switched (Circuit Switched: 'CS') network by a Mobile Switching Center (hereinafter referred to as 'MSC') 150. The CS network refers to a voice-based legacy communication network that is connection-based. Communication between the RNC 140 and the MSC 150 is performed by circuit switched signaling (CS signaling). In particular, the connection between the RNC 140 and the MSC 150 is called an Iu-CS interface.

The MBMS data stream generated from the BM-SC 110 is transmitted to the UEs 161, 162, 163 via the transport network 120, SGSN 130, RNC 140, Node B and cells 160, 170. , 171 and 172.

Although not shown in FIG. 1, there may be multiple SGSNs for one MBMS service and multiple RNCs for each SGSN. Each SGSN is a plurality of RNCs, each RNC performs a selective data transmission to each of a plurality of cells, and for this purpose a list of sub-nodes (i.e., SGSN list of RNCs, RNC In this case, a list of cells) may be stored to selectively perform MBMS data transmission only to the stored nodes.

MBMS is a packet switching service. All data transferred from BM-SC to RNC is based on IP (Internet Protocol) packet. In order to smoothly deliver the IP packet to the UE, the RNC creates one PDCP entity for each MBMS session. At this time, whether or not the header compression is entirely determined by the RNC. If the header compression is previously set for the PDCP entity because the RNC does not know the property of the data to be transmitted until MBMS data is transmitted, Header compression is used for each PDCP entity, and vice versa.

However, the header compression method according to the related art has a problem in that compression is fixed in advance, thereby inefficient use of radio resources or processor load for header compression occurs.

An object of the present invention, which was created to solve the above problems, is a method in which the RNC provides information for determining whether to compress a header.

Another object of the present invention is to provide a method for delivering information related to header compression from a BM-SC to an RNC.

It is also an object of the present invention to provide a method for the RNC to receive information related to header compression from the BM-SC and determine whether to compress the header using the same.                         

Another object of the present invention is to provide a method for BM-SC to transmit information related to variable header compression to RNC, and the RNC determines whether to compress the header using the same.

It is still another object of the present invention to provide a method in which a header has a relatively high compression rate relative to data for a packet having a short data size, and uses header compression, and a header compression for a packet having a long data size.

In order to achieve the above object, the transmission operation according to the first embodiment of the present invention is a multimedia / multicast broadcast service (MBMS) in the method of controlling header compression for the MBMS service,

Including a transport protocol for the MBMS service in a session start message informing the MBMS that an MBMS session for a service is to be started;

And transmitting a session start message including the transport protocol to a wireless network controller through a serving support node.

In the transmission operation according to the second embodiment of the present invention, in the multimedia / multicast broadcast service (MBMS), in the method for controlling header compression for the MBMS service,

Including a service type for the MBMS service in a session start message that informs the MBMS that an MBMS session for a service is to be started;

And transmitting a session start message including the service type to a wireless network controller through a serving support node.

In the transmission operation according to the third embodiment of the present invention, in a multimedia / multicast broadcast service (MBMS), in a method of controlling header compression for an MBMS service,

Including 'header compression information' indicating whether to use header compression for the MBMS service in a session start message that informs the MBMS that an MBMS session for a service is to be started;

And transmitting a session start message including the header compression information to a wireless network controller through a serving support node.

In the reception operation according to the first embodiment of the present invention, in the multimedia / multicast broadcast service (MBMS), in the method for controlling header compression for the MBMS service,

Receiving a session start message including a transport protocol for the MBMS service;

Determining whether to compress the header using the transport protocol;

Creating a packet data convergence protocol (PDCP) entity according to the header compression determination;

And including the configuration information of the generated PDCP entity in the radio bearer information and transmitting the same to the terminal.

In a reception operation according to a second embodiment of the present invention, in a multimedia / multicast broadcast service (MBMS), in a method of controlling header compression for an MBMS service,

Receiving a session start message including a service type of the MBMS service;

Determining whether to compress the header by using the service type;                         

Creating a packet data convergence protocol (PDCP) entity according to the header compression determination;

And including the configuration information of the generated PDCP entity in the radio bearer information and transmitting the same to the terminal.

In the reception operation according to the third embodiment of the present invention, in the multimedia / multicast broadcast service (MBMS), in the method for controlling header compression for the MBMS service,

Receiving a session start message including header compression information indicating whether header compression is used for the MBMS service;

Determining whether to compress the header by using the header compression information;

Creating a packet data convergence protocol (PDCP) entity according to the header compression determination;

And including the configuration information of the generated PDCP entity in the radio bearer information and transmitting the same to the terminal.

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.

2 is a flow chart according to a preferred embodiment of the present invention.

Referring to FIG. 2, in steps 210 to 220, the BM-SC 201 sets 'header compression information' in a 'Session Start' message indicating that an MBMS session is about to start, and then the RNC 203 through the SGSN 202. To pass. In this case, the header compression information is information for determining whether to compress the header of the IP packet.

Upon receiving the Session start message, the RNC 203 checks the header compression information in step 230 and sets parameters related to PDCP and header compression. In step 240, the RNC 203 delivers the determined parameters related to the PDCP and header compression to the UE 204. At this time, the determination regarding the header compression is carried on the MBMS Control CHannel (MCCH) if the MBMS service is determined to be PtM or the Data Control CHannel (DCCH) if it is set to PtP according to the channel type set for the MBMS service. Is passed to 204.

In step 250, PDCP entities for the RNC 203 and the UE 204 are generated based on the determined parameters related to the PDCP and header compression. Here, if header compression is not used, the RNC 203 may deliver the MBMS data transmitted from the SGSN 202 to the UE 203 without generating a PDCP entity.

 In step 260, the UE 204 may receive MBMS service through the generated PDCP entity.                     

According to an embodiment of the present invention, 'header compression information' included in the 'Session Start' message includes one of a transport protocol, a service type, and explicit signaling.

The first embodiment of the present invention is a method using a transport protocol as 'header compression information'.

The transmission protocol includes IP / UDP (User Datagram Protocol) / RTP (Real Time Protolco) or IP / UDP / FLUTE. RTP packets are generally about 300 bytes in size and FLUTE packets are relatively large, about 1500 bytes. Therefore, the RTP packet has a large gain from compressing the header, but the FLUTE packet does not have much gain from the header compression but rather has a large overhead due to the header compression. That is, by sending a transport protocol to the 'session start' message, the RNC 203 can determine whether the transmitted protocol is advantageous in header compression as in the RTP or not in header compression as in FLUTE. do.

For reference, in a general UMTS system, real-time streaming service is serviced using the protocol stack of IP / UDP / RTP, and services such as file transfer are serviced using the IP / UDP / FLUTE protocol stack. Accordingly, the RNC 203 determines to compress the header when the protocol stack of the IP / UDP / RTP is received through the session start message, and not to compress the header when the protocol of the IP / UDP / FLUTE is received.

A second embodiment of the present invention is a method of using 'service type' as 'header compression information'.                     

The service types include streaming, download, and voice over internet protocol (VoIP), etc. In general, streaming services have a short data size, and thus benefit from header compression. In this large, download service, the data size is large and the gain from the header compression is not significant: Similarly, upon receiving the service type via the session start message, the RNC performs header compression if the service type is streaming and header compression if it is a download. Decide not to do it.

A third embodiment of the present invention is a method using 'explicit signaling' as 'header compression information'.

The explicit signaling includes signaling in the session start message whether the BM-SC explicitly compresses the header, that is, 'HC not required' requiring header compression or 'HC not required' not requiring header compression. The RNC 203 may be informed. Thereafter, the RNC 203 determines whether to compress the header as described above.

Table 1 below is an example of header compression information (hereinafter referred to as 'HC Info') IE added to a session start message according to an embodiment of the present invention. To transmit header compression information, one of the three header compression information is selected and delivered to the RNC. For reference, in Table 1, the HC Info IE is an optional IE.                     

3 is a view showing the operation of the RNC according to a preferred embodiment of the present invention.

Referring to FIG. 3, in step 300, the RNC receives a session start message transmitted by the BM-SC through SGSN and checks whether header compression information (HC info) is included in the session start message in step 310. If the header compression information is included as a result of the check, in step 330 it is determined whether the header is compressed using the header compression information.

If the check result does not include the header compression information, in step 320, the RNC arbitrarily determines whether to compress the header.                     

If it is determined whether header compression is performed in steps 320 to 330, the flow proceeds to step 340. In step 340, the RNC checks whether header compression is determined. If it is determined that header compression is to be performed, in step 380, the RNC creates a PDCP entity to which header compression has been applied.

If it is determined that the header compression is not to be performed, in step 350, the RNC determines whether to generate a PDCP entity by itself. If it is determined that the PDCP is generated, in step 370, a PDCP entity without header compression is created. If it is determined that the PDCP is not generated, the RNC proceeds to step 395 without creating a PDCP entity in step 360. Even if the PDCP entity is not created in step 360, it is obvious that the process should proceed to step 395 to transmit radio bearer information to the UE.

Subsequently, in step 390, the RNC adds configuration information of PDCP entities created in steps 370 to 380 to radio bearer information (RB infomation). In step 395, the RNC carries the radio bearer information on the MCCH or DCCH and delivers the information to the UE.

4 is a diagram illustrating an example of UE operation according to a preferred embodiment of the present invention.

Referring to FIG. 4, in step 400, the UE receives radio bearer information, and in step 410, the UE determines whether configuration information of a PDCP entity including header compression information is included in the radio bearer information. If there is configuration information of the PDCP entity as a result of the check, it is determined in step 420 whether to compress the header by reading the PDCP information.

If header compression is necessary as a result of the determination, in step 440, the UE creates a PDCP entity to which header compression has been applied. If the header is not determined as a result of the determination, in step 430, the UE creates a PDCP entity to which header compression is not applied and completes a task.

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 BM-SC transmitting MBMS data transmits header compression information to the RNC via SGSN to assist in determining whether to compress the header in the UTRAN for each service, so that the RNC uses the header compression information to provide a header between the UE and the RNC. There is an effect of determining whether to compress and accordingly create a PDCP entity and transmit the determined information to the UE to enable smooth transmission of MBMS data between the RNC and the UE.

Claims (15)

In a multimedia / multicast broadcast service (MBMS), a method for controlling header compression for an MBMS service, Including a transport protocol for the MBMS service in a session start message indicating that an MBMS session for the MBMS service is to be started; And transmitting a session start message including the transport protocol to a wireless network controller through a serving support node. The method of claim 1, wherein the transmission protocol, Method for indicating the Internet Protocol (IP) / User Datagram Protocol (UDP) / Real Time Protolco (RTP) or IP / UDP / FLUTE for transmitting the MBMS service. In a multimedia / multicast broadcast service (MBMS), a method for controlling header compression for an MBMS service, Including a service type for the MBMS service in a session start message indicating that an MBMS session for the MBMS service is to be started; And transmitting a session start message including the MGMS service type to a wireless network controller through a serving support node. The method of claim 3, wherein the service type is A method of indicating a streaming service, a download service, or a voice packet service. In a multimedia / multicast broadcast service (MBMS), a method for controlling header compression for an MBMS service, Including, in a session start message indicating that an MBMS session for the MBMS service is to be started, 'header compression information' indicating whether header compression for the MBMS service is used; And transmitting a session start message including the header compression information to a wireless network controller through a serving support node. The method of claim 5, wherein the header compression information, And a header compression request or no header compression request for the MBMS service. In a multimedia / multicast broadcast service (MBMS), a method for controlling header compression for an MBMS service, Receiving a session start message including a transport protocol of the MBMS service; Determining whether to compress the header using the transport protocol; Creating a packet data convergence protocol (PDCP) entity according to the header compression determination; And including the generated configuration information of the PDCP entity in radio bearer information and transmitting the same to the terminal. The method of claim 6, wherein the transmission protocol, Method for indicating the Internet Protocol (IP) / User Datagram Protocol (UDP) / Real Time Protolco (RTP) or IP / UDP / FLUTE for transmitting the MBMS service. The method of claim 6, wherein the radio bearer information, The method is characterized in that the transmission to the terminal via a MBMS control channel or data control channel. In a multimedia / multicast broadcast service (MBMS), a method for controlling header compression for an MBMS service, Receiving a session start message including a service type of the MBMS service; Determining whether to compress a header by using a service type of the MBMS service; Creating a packet data convergence protocol (PDCP) entity according to the header compression determination; And including the generated configuration information of the PDCP entity in radio bearer information and transmitting the same to the terminal. The method of claim 10, wherein the type of service, And a streaming service, a download service, or a voice packet service. The method of claim 10, wherein the radio bearer information, The method is characterized in that the transmission to the terminal via a MBMS control channel or data control channel. In a multimedia / multicast broadcast service (MBMS), a method for controlling header compression for an MBMS service, Receiving a session start message including header compression information indicating whether to use header compression for the MBMS service; Determining whether to compress the header by using the header compression information; Creating a packet data convergence protocol (PDCP) entity according to the header compression determination; And including the generated configuration information of the PDCP entity in radio bearer information and transmitting the same to the terminal. The method of claim 13, wherein the header compression information, And a header compression request or no header compression request for the MBMS service. The method of claim 13, wherein the radio bearer information, The method is characterized in that the transmission to the terminal via a MBMS control channel or data control channel.

Images