KR20050020548A - Method acquired header compression context information in user element serving packet data service - Google Patents

Abstract

The present invention provides a mobile communication system comprising a wireless network controller supporting a packet data service and a user terminal receiving a packet data service transmitted from the wireless network controller, wherein the header for compressing a header of packet data in the wireless network controller A method for transmitting a compression context, the method comprising: requesting retransmission of all or part of a header compression context according to a cause of the error when the header restoration occurs; and retransmission from the user terminal. Searching whether the requested header compression context is stored, and determining whether to transmit all or part of the found header compression context information according to the header compression context for which the retransmission is requested, and according to the determination, The process of transferring all or part , It comprises a step of reconstructing the header of the received packet data by using the received header compression context.

Description

METHODO ACQUIRED HEADER COMPRESSION CONTEXT INFORMATION IN USER ELEMENT SERVING PACKET DATA SERVICE}

The present invention relates to a mobile communication system supporting packet data, and more particularly, to a method for requesting retransmission when an error occurs in packet data received by a user terminal.

1 is a diagram schematically illustrating a structure of a general mobile communication system.

The mobile communication system is a universal mobile terrestrial system (UMTS) mobile communication system, and includes a core network (CN) 100 and a plurality of radio network subsystems (RNS). , Hereinafter referred to as "RNS" 110, 120, and a user terminal (UE: User Element, hereinafter referred to as "UE") 130. The RNS 110 and the RNS 120 are composed of a radio network controller (RNC: hereinafter referred to as "RNC") and a plurality of base stations (Node Bs). For example, the RNS 110 includes the RNC 111, the base station 113, and the base station 115, and the RNS 120 includes the RNC 112, the base station 114, and the base station 116. do. The RNCs 111 to 112 may be referred to as Serving RNCs (hereinafter referred to as "SRNC") or Drift RNCs (hereinafter referred to as "DRNC") or Controlling RNCs (hereinafter referred to as "CRNC") according to their operation. Classified as The SRNC refers to an RNC that manages information of each UE and is responsible for data transmission with the CN 100. Become another RNC. The CRNC is an RNC that controls each of the base stations. In FIG. 1, when the RNC 111 manages information of the UE 130, the RNC 111 operates as an SRNC for the UE 130, and the UE 130 moves to the UE 130. ) Data is transmitted and received through the RNC 112, the RNC 112 becomes a DRNC for the UE 130, and the RNC 111 controlling the base station 113 communicating with the UE 130. ) Becomes the CRNC of the base station 113.

The RNC and the base station are connected through an Iub interface, and the connection between the RNC and the RNC consists of an Iur interface. Although not shown in FIG. 1, the UE and the UTRAN are connected by a Uu interface. The RNC allocates radio resources to a plurality of base stations managed by the RNC, and the base station provides radio resources allocated from the RNC to the user terminal. The radio resource is configured for each cell, and the radio resource provided by the base station means a radio resource for a specific cell managed by the base station. The user terminal sets a radio channel using radio resources for a specific cell managed by the base station, and transmits and receives data using the set radio channel. Therefore, since the user terminal recognizes only the physical channel configured for each cell, the distinction between the base station and the cell is meaningless. Hereinafter, the base station and the cell will be used interchangeably.

In order to support multicasting multimedia communication, there is a broadcast / multicast service that provides a service from one data source to a plurality of user equipments (hereinafter referred to as UEs). The broadcast / multicast service is a multimedia broadcast / multicast supporting a multimedia service such as a cell broadcast service (hereinafter, referred to as a "CBS service"), a message-oriented service, and real-time video, voice, still image, and text. It may be classified as a service (Multimedia Broadcast / Multicast Service, hereinafter referred to as "MBMS").

Next, a network structure for providing the MBMS service in the mobile communication system will be described with reference to FIG. 2. 2 is a diagram schematically illustrating a network structure for providing an MBMS service in a mobile communication system.

Referring to FIG. 2, first, a multicast / broadcasting service center (BM-SC) (hereinafter, referred to as a “BM-SC”) 210 may provide a source for providing an MBMS stream. source), the BM-SC 210 schedules a stream for the MBMS service and transmits the stream to the transport network 220. The transport network 220 refers to a network existing between the BM-SC 230 and a Serving GPRS Support Node (SGSN) 230. Then, the stream for the MBMS service received from the BM-SC 230 delivers to the SGSN (230). Here, the SGSN 230 may be configured as a gateway packet wireless service support node (GGSN) (hereinafter referred to as "GGSN"), an external network, and the like and receive a plurality of MBMS services at any time. UEs, for example, UE1 261, UE2 262, UE3 263, which belongs to Cell 1 (Node B 1) 260, and UE4 271 that belongs to Cell 2 (Node B 2) 270. It is assumed that UE5 272 exists. The SGSN 230 receiving the stream for the MBMS service in the transmission network 220 controls the MBMS-related services of subscribers, ie, UEs, that want to receive the MBMS service. And MBMS-related services such as selectively transmitting MBMS service data to a specific Radio Network Controller (RNC) 240. In addition, the SGSN 230 configures and manages an SGSN service context regarding the MBMS service X, and transfers the stream for the MBMS service to the RNC 340 again. The RNC 240 controls a plurality of Node Bs, transmits MBMS service data to a Node B in which a UE requesting MBMS service among Node Bs managed by the RNC 240 exists, and also provides the MBMS service. The RNC service context is configured and managed with respect to the MBMS service X by controlling a radio channel to be set and having a stream for the MBMS service received from the SGSN 230. As shown in FIG. 2, an MBMS service is provided between one Node B, for example, Node B 1 260 and UEs 261, 262, and 263 belonging to Node B 1 260. Only one radio channel is configured to provide. Although not shown in FIG. 2, a Home Location Register (HLR) is connected to the SGSN 230 to perform subscriber authentication for an MBMS service.

Hereinafter, the Uu interface established between the user terminal and the RNC will be described with reference to FIG. 3. The Iu interface, the Iub interface, or the Uu interface may be referred to as an interface configured to perform communication between nodes. The messages of the upper layer processed in UTRAN may be largely divided into control signals and user data. In 3, the control plane (hereinafter referred to as C-Plane) signal 301 and the user plane (hereinafter referred to as U-Plane) data 302 are represented. The C-Plane signal 301 and the U-Plane data 302 are messages of a Non Access Stratum (hereinafter referred to as NAS). The NAS messages refer to messages that are not used for a wireless connection between the UE and the UTRAN, indicating messages that the UTRAN does not need to know the content of. Unlike the NAS, a message used directly for wireless connection between the UTRAN and the UE is called an access stratum (hereinafter referred to as an AS) message. The AS message indicates data or a control signal used in the radio resource control (hereinafter referred to as RRC) 311 of FIG. 3. The C-Plain signal 301 has an RRC 311, a Radio Link Control (hereinafter referred to as L2 / RLC) 341, and a Medium Access Control (hereinafter referred to as L2 / MAC). 371, a Physical Layer (hereinafter referred to as L1) 391 is included, and the U-Plain signal 302 is referred to as a Packet Data Convergency Protocol (hereinafter referred to as L2 / PDCP). 321, a broadcast / multicast control (hereinafter referred to as L2 / BMC) 331, an L2 / RLC 341, an L2 / MAC 371, and a physical layer 391 are included. do. Hereinafter, the functions of the layers will be described.

The physical layer 391 performs a function of channel coding / decoding, modulation / demodulation, channelization / dechannelization, and the like to convert data to be transmitted into a radio signal, and converts the received radio signal into data. The transport channels 381 transmitted to the physical layer 391 are appropriately transmitted to the physical channel and then transmitted to the UE or the RNC. The physical channels are referred to as a primary common control channel (hereinafter referred to as P-CCPCH) for transmitting the BCH, and a secondary common control physical channel (hereinafter referred to as P-CCPCH) for transmitting the PCH and FACH. S-CCPCH.), Dedicated Physical Channel (hereinafter referred to as DPCH) for transmitting the DCH, and Physical Downlink Shared Channel (hereinafter referred to as PDSCH) for transmitting the DSCH. , A High Speed Physical Downlink Shared Channel (HS-PDSCH) for transmitting the HS-DSCH, and a Physical Random Access Channel (hereinafter referred to as PRACH) for transmitting the RACH. Pilot channel, which is a pure physical channel that does not transmit higher layer data or control signals other than the channels, and a first synchronization channel. Synchronization Channel, Secondary Synchronization Channel, Secondary Synchronization Channel, Paging Indicator Channel, Paging Indicator Channel, Acquisition Indicator Channel, Physical Common Packet Channel. The physical layer 391 and the L2 / MAC 371 are connected by a transport channel 381. The transport channel 381 defines the manner in which specific data is processed at the physical layer 391. The processing method includes a channel coding scheme and a transport block set size that can be transmitted during one unit time. Table 1 describes the types and roles of the transport channels.

designation role Broadcast channel (BCH) It is mapped with the BCCH to transmit the data of the BCCH. Paging Channel (PCH) It is mapped with the PCCH to transmit the data of the PCCH. Random Access channel (RACH) It is used for transmission from the UE to the network, and is used for transmission of network connection and control messages and short length data. Forward Access Channel (FACH) Used for transmission of control messages and data from a network to specific UEs or specific UEs. BCCH, CTCH, CCCH, DCTH, DCCH can be mapped. Dedicated Channel (DCH) This is a channel that can transmit data and control signal between network and UE. DTCH and DCCH are mapped. Downlink Shared Channel (DSCH) DTCH and DCCH are mapped to the downlink channel from the network to the UE used for transmission of high capacity data High Speed DSCH (HS-DSCH) DTCH and DCCH are mapped to the downlink channel from the network which improves the efficiency of the transmission capability of the DSCH to the UE.

The L2 / MAC 371 serves to deliver data delivered by the RLC through a logical channel to the physical layer 391 through an appropriate transport channel 381, and the physical layer 391 plays the role of the transport channel 381. It transmits the data transferred through the appropriate logical channel 361 to the L2 / RLC 341. Also, the L2 / MAC 371 inserts additional information into data received through the logical channel 361 or the transport channel 381, or interprets the inserted additional information to perform an appropriate operation. The logical channel 361 is largely divided into a dedicated type channel, which is a channel for a specific UE, and a common type channel, which is a channel for a plurality of UEs. It is also divided into control type channel and traffic type channel according to the nature of the message. Table 2 shows the types and roles of the logical channels.

designation role Broadcast Control Channel (BCCH) Used for downlink transmission from UTRAN to UE, and used for transmission of UTRAN system control information. Paging Control Channel (PCCH) It is used for downlink transmission from the UTRAN to the UE, and is used to transmit control information to the UE when the location of the cell to which the UE belongs is unknown. Common Control Channel (CCCH) It is used to transmit control information between the UE and the network, and is used when the UE does not have an RRC connection channel. Dedicated Control Channel (DCCH) It is used for 1: 1 control information transmission between the UE and the network, and is used when the UE has a connection with the RRC. Common Traffic Channel (CTCH) 1: Used for data transmission between the network and the UEs. Dedicated Traffic Channel (DTCH) It is used for 1: 1 data transmission between the network and the UE.

After receiving the control message transmitted from the RRC 311 to the UE, the L2 / RLC 341 has a proper form in the RLC # 1 351 and the RLC #m 352 in consideration of the characteristics of the control message. Processing. The processed control message is transmitted to the L2 / MAC 371 using a logical channel 361. Also, the L2 / RLC 341 receives data from the L2 / PDCP 321 and the L2 / BMC 331 and processes the data into an appropriate form in the RLC # 1 353 and the RLC #n 354. do. The processed data is transmitted to the L2 / MAC 371 using the logical channel 361. How many RLCs are generated in the L2 / RLC 341 is determined by the number of radio links between the UE and the RNC. The L2 / RLC 341 is any one of an acknowledgment mode (hereinafter referred to as AM), an unacknowledged mode (hereinafter referred to as UM), and a transparent mode (hereinafter referred to as TM). It operates in a mode, and there is a difference in the function provided for each of the modes. The RLC # 1 351, RLC #m 352, RLC # 1 353 and RLC #n 354 are RLC entities operating in any one of the provided modes.

The L2 / PDCP 321 is located in an upper layer of the L2 / RLC 341 and performs a lossless data function when the RNC is changed due to the header compression function of the data transmitted in the form of an IP packet and the mobility of the UE. . The L2 / BMC 331 is located in an upper layer of the L2 / RLC 341 and supports a broadcast service for transmitting the same data to a plurality of unspecified UEs in a specific cell. The RRC 311 performs a function of allocating or releasing radio resources between the RNC and the UE. In 3GPP, there are various methods for supporting the MBMS, but it can be classified into two types. The two distinctions are based on the relationship between the UE and the RNC and are divided into a connected mode and an idle mode according to the relationship between the UE and the RNC. The connected mode refers to a state in which the RRC 311 can exchange control signaling or data with a specific UE as described in FIG. 3, and the RRC 311 knows information about the UE. What is needed for the connection mode is called RRC connection. Using the RRC connection, the RNC delivers radio resources allocated to UEs, mobility of the UEs, and core network signals to be transmitted to the UEs. The idle mode is a case in which the RRC 311 does not know that a specific UE exists and there is no method in which the RRC 311 and the specific UE can exchange control signaling or data.

 Hereinafter, an operation performed between nodes supporting the MBMS service will be described. 4 is a diagram illustrating a process of performing an MBMS service between a UE that wants an RNC and an MBMS service. The RNC performs the MBMS service to corresponding UEs that want the MBMS service via the MBMS service through a base station. However, although the base station is not shown in FIG. 4, it is obvious that the MBMS service is performed via the base station. The MBMS control message transmitted for the MBMS service will also be described.

According to FIG. 4, the UE is a UE that wants to receive the corresponding MBMS service, and the RNC is an RNC that transmits the MBMS service. The four processes are sequentially performed by announcement, joining, paging, and radio bearer (RB) setup. Hereinafter, the above four processes will be described. In step 400, the notification process, the SGSN notifies the UE of when the MBMS service starts. That is, the information on the notification tells which MBMS services are started, and time information and duration time of starting the MBMS services.

The UE that wants the MBMS services by the MBMS service notification of the SGSN performs a subscription step with the SGSN in step 410. In the subscribing step, the UE transmits a Joining Request Message requesting subscription to the SGSN. The subscription request message includes an identification code of a specific MBMS service that the UE wants to receive from the MBMS service list transmitted by the SGSN, and an identifier (UE ID) of the UE that wants the MBMS service. In addition, in step 410, the SGSN performs an authentication process of the UE requesting the MBMS service and notifies the UE whether the MBMS service can be received through the authentication process. The SGSN stores the list of UEs to receive the specific MBMS service and the location of the UEs by performing step 410.

When the mobile communication system completes the subscription step for the MBMS service, it performs the calling steps (415 to 430). If the BM-SC notifies the start of the MBMS service, the SGSN transmits a Session Start message to the RNCs in which UEs which performed the subscription process are located in step 415.

 In step 420, the RNC transmits a call message using a common channel such as a secondary-common control channel (S-CCPCH) to call UEs to receive the MBMS service. The call is a process in which the SGSN informs corresponding UEs that want the MBMS service that the MBMS service will start. Since a plurality of UEs are called through the call message transmission, step 420 is referred to as a group paging process in a sense contrasted with the existing calling procedure. The notification message may be transmitted through MCCH.

In step 430, UEs called in step 420 transmit a response message to the call message. Through the transmission of the response message, the RNC can determine the number of UEs to receive the MBMS service for each cell and determine the radio channel type of the corresponding cell. When a plurality of UEs included in a specific cell want to receive MBMS service, MBMS service is provided through a common channel, and for a cell having a small number of UEs that want to receive MBMS service, a dedicated channel is configured for each UE by MBMS. Can provide services.

In step 435, the UE that wants the MBMS service that has performed the call-related procedure performs the radio bearer setup process using radio bearer information transmitted by the RNC through an MBMS Control Channel (MCCH). The radio bearer setup process is a process of actually allocating a radio resource to provide the MBMS service and notifying the related devices of the information. In the radio bearer setup process, MBMS radio bearer information is transmitted to receive the received MBMS service without error. That is, the UE can restore the transmitted MBMS service without error using the MBMS radio bearer information. The MBMS radio bearer information may include radio channel information, for example, OVSF code information, transmission format information, RLC (Radio Link Control) information, and PDCP (Packet Data Convergence Control) information. A detailed description of the above information is given in 3GPP TS 26.331. When the radio bearer setup process is completed, all UEs that want to receive a specific MBMS service become aware of radio link related information to be provided with the MBMS service and higher layer information to be processed by the MBMS service.

The MCCH is a channel through which control information related to MBMS is provided, and the exact nature of the channel is still being discussed and has not been determined. According to the discussion to date, MCCH is expected to have the following characteristics.

1. One MCCH is configured per cell.

2. The MCCH is transmitted on a common physical channel such as S-CCPCH.

3. UEs can acquire information on the MCCH configured for each cell as system information.

In step 440, the RNC provides an MBMS service through an MBMS RB, and UEs receive an MBMS service provided through the MBMS RB.

While the MBMS data is provided, there is a need to change the type of channel established between the RNC and the UE due to mobility of UEs supported by the MBMS service. For example, the RNC supports the MBMS service using a common channel (hereinafter, referred to as a PTM) because a sufficient number of UEs located in an arbitrary cell are supported in the step 440. do. It is not desirable for the RNC to send MBMS service to the PTM when the sufficient number of UEs move to another cell at any point in time. That is, when the number of corresponding UEs supporting the MBMS service located in a specific cell is sufficient, it is preferable to support the MBMS service by PTM, but the number of corresponding UEs supporting the MBMS service located in the specific cell is If it is not enough, it is preferable to support the MBMS service in a PTP channel (Point to Point: dedicated channel).

In step 450, the RNC determines to change a channel type that supports the MBMS service. According to the determination, the RNC exchanges a predetermined control signal with UEs located in a cell and configures a dedicated channel. In step 460, the RNC transmits the MBMS service using the configured transport channel.

Hereinafter, in step 440, it is assumed that the MBMS data is transmitted and received between the RNC and the UE through the PTM channel, and in step 460, the MBMS data is transmitted and received through the PTP channel. However, the MBMS data is transmitted and received between the RNC and the UE through the PTP channel in step 440, and the MBMS data is transmitted and received through the PTM channel in step 460.

The MBMS data is expected to be an IP / UDP / RTP packet, and the most important application of the MBMS service will be a multimedia streaming service. The most efficient way to provide the multimedia streaming service is IP / UDP / RTP. Since the size of the IP / UDP / RTP packet is 40 to 60 bytes, the transmission as it is over the air is not efficient. Accordingly, as described above with reference to FIG. 3, header compression and header de-compression are performed in the PDCP entity, and the header is compressed and transmitted in a few bytes on the Uu interface. The header compression scheme called ROHC (Robust Header Compression) will be used for the MBMS service. Accordingly, the ROCH header compressor and the header decompressor should be provided in the PDCP entities of the RNC and the UE that process the MBMS data.

When the MBMS data transmission starts in step 440, the RNC compresses the MBMS data transmitted by the SGSN using the ROCH compression scheme and then transmits the MBMS data to the UE. The UE restores the compressed MBMS data to the MBMS data using the ROCH recovery technique. Even if the PTM channel is changed from the PTM channel, the PDCP should be responsible for the header compression and restoration. Hereinafter, the header compression and restoration will be described.

5 illustrates the general operation of general header compression and header recovery. When the header compression device 510 receives an uncompressed packet from an upper layer, the header compression device 510 compresses the packet according to a predetermined protocol and transmits the packet to the decompression device 525. The compressed packet includes a protocol used for compression and a context identifier (CID) indicating data. The header restoring apparatus restores the header by using the CID of the received packet, and transfers the restored header to a higher layer. As described above, when header compression is used, transmission resources can be efficiently used by transmitting and receiving only compressed headers on an actual transmission path.

The header compression context (HC context) HC 515, 516, 530, 531 stores data related to header compression / restore, and has a unique identifier CID. Packets having the same traffic characteristics are called packet streams, and packets belonging to the one packet stream have the same source IP address, destination IP address, source port number, and destination port number. Since it has a port number (Destination Port Number), header compression / restore is performed using the same HC context. When the header compressor 510 receives the uncompressed packet 505 from the upper layer, the header compressor 510 determines the HC context corresponding to the packet stream using the IP address and port number of the received packet. Alternatively, the packet 505 is included in the packet stream and the HC context is used by tracking the path of the uncompressed packet 505 from the upper layer. The HC context stores header contents and other necessary parameters of a packet immediately compressed. The header of the packet is composed of various types of fields, and can be classified as follows according to characteristics.

〈Field unchanged while the call is in progress〉

Source IP Address, Destination IP Address, Source Port Number, Destination Port Number ...

<Fields change regularly during the call>

RTP Sequence Number ...

〈Field irregularly changed while the call is in progress〉

IP ID, Time to Live ...

The characteristics of each field are not always constant, and may vary from case to case, and thus detailed description thereof will be omitted. The header compressor 510 omits a field that does not change during the call, and compresses only the value of the field that changes during the call. The value of a field that changes regularly during the call only includes a value corresponding to the difference from the previous value (hereinafter referred to as Delta), and the value of the field that changes irregularly during the call proceeds to include the value as it is. Compress the header. The header compressor 510 inserts the CID into the compressed header to complete the header compression and transmits the completed compressed header packet to the header decompressor 525 located in the UE.

The header decompressor 525 determines the HC context to be used for header restoration by using the CID of the received packet 520 and restores the header according to the determined HC context. That is, a field in which the call does not change is inserted into the value of the HC context as it is, and a field that changes regularly during the call inserts a value obtained by adding the received Delta value to the value of the HC context. The randomly changing field during the call proceeds to insert the received value to restore the header, and deliver the restored header packet 535 to the upper layer.

As described above, in order to perform header compression / restore, the header compressor and the decompressor must have the same HC context. The header compressor and the header decompressor have the same HC context through the process of initializing the HC context before performing header compression / restore. In the HC context initialization process, a header compressor generally transmits a CID and all field values to a header decompressor a plurality of times, and the header decompressor stores the CID and field values transmitted a plurality of times. Hereinafter, a process of initializing a conventional HC context will be described with reference to FIG. 6.

6 illustrates a mobile communication system in which the RNC supports the MBMS service by using a header compression scheme using the U-mode of the ROHC for the UE. In the U-mode of the ROHC, an IR packet is transmitted to the header decompressor of the UE a plurality of times prior to transmitting the compressed data. The header decompressor performs an HC initialization process using the transmitted IR packet. Hereinafter, a process of supporting an MBMS service for a UE by the RNC will be described in detail with reference to FIG. 7.

In step 615, the SGSN transmits a Session Start (SS) message to the RNC in step 615. In step 620, the RNC transmits a call message using a common channel such as a secondary-common control channel (S-CCPCH) to call UEs to receive the MBMS service. The call is a process in which the SGSN informs corresponding UEs that want the MBMS service that the MBMS service will start. The call message may be transmitted through MCCH.

In step 630, UEs called in step 620 transmit a response message to the call message. Through the transmission of the response message, the RNC can determine the number of UEs to receive the MBMS service for each cell and determine the radio channel type of the corresponding cell. When a plurality of UEs included in a specific cell want to receive MBMS service, MBMS service is provided through a common channel, and for a cell having a small number of UEs that want to receive MBMS service, a dedicated channel is configured for each UE by MBMS. Can provide services.

In step 635, the UE that wants the MBMS service that has performed the call-related procedure performs the radio bearer setup process by using radio bearer information transmitted by the RNC through an MBMS Control Channel (MCCH). The radio bearer setup process is a process of actually allocating a radio resource to provide the MBMS service and notifying the related devices of the information. In the radio bearer setup process, MBMS radio bearer information is transmitted to receive the received MBMS service without error. The setup of the radio bearer means that a PDCP entity for processing MTCH data of the MBMS service is configured in the RNC and the UE. That is, the configuration of the ROHC header compressor of the RNC is configured to the ROHC header decompressor of the UE.

In step 637, the SGSN transfers MBMS data to the RNC. The MBMS data consists of an IP / UDP / RTP header and a payload. After receiving the IP / UDP / RTP header and payload, the RNC transmits an IR packet to the UE in step 640. As described above, the IR packet includes a field that does not change and a field that changes. The header decompressor of the UE cannot restore the header transmitted from the RNC before receiving the IR packet. Therefore, the RNC transmits the IR packet before transmitting the MBMS data transmitted from the SGSN to the UE. In addition, to improve the transmission efficiency of the IR packet is transmitted to the UE a plurality of times. In FIG. 6, the operation as described above is performed in steps 640 to 650. Before the MBMS data is transmitted, the RNC transmits the IR packet stored in the ROHC header compressor, and the UE stores the transferred IR packet in the ROHC header decompressor in the HC initialization process 665. The number of retransmission of the IR packet can be appropriately adjusted by the user according to the system. The number of retransmissions of the IR packet is proportional to the success rate of HC initialization and is inversely related to the compression rate. That is, increasing the number of retransmissions of the IR packet increases the number of UEs that successfully initialize the HC but decreases the header compression rate. However, if the number of retransmissions of the IR packet is reduced, the number of UEs that successfully initialize the HC decreases but the header compression rate increases. The header compression rate is a value obtained by expressing the difference between the header size when using the header compression protocol and the header size when the header is not compressed and the difference between 1. Since the IR packet is a packet whose header is not compressed, the header compression rate decreases when the number of transmissions of the IR packet increases. Accordingly, the number of times of retransmitting the IR packet in the HC initialization process may be determined in consideration of the number of UEs to receive the MBMS service in the corresponding cell.

During the HC initialization process 665, the SGSN continuously transmits MBMS data to the RNC, and the RNC stores the received data until the HC initialization process is completed. When the HC initialization process 665 is completed, the ROHC header compressor of the RNC compresses the header of the MBMS data transmitted by the SGSN to the UE in step 655. In step 655, the IR / UDP / RTP header of the MBMS data transmitted through the MTCH is in a compressed state, and the UE which successfully performs the HC initialization process may restore the compressed header (cmp hdr: compressed header). . The ROHC header compressor of the RNC compresses the header of the data transmitted by the SGSN to the UE in step 660, and the UE transmits the header of the received data using HC (Header Compression) information stored in the header decompressor. Repeat the restoring operation.

In the U-mode of the ROHC, the header restorer of the UE is not allowed to feed back the IR packet. Therefore, the header compressor of the RNC retransmits the IR packet at regular intervals, thereby refreshing the HC of the header restorer of the UE. refresh). The period of retransmitting the IR packet is called an IR packet refresh period 680. The size of the IR packet refresh period does not have a fixed value like the number of IR packets retransmitted during the HC initialization and should be appropriately determined according to a situation.

The ROHC header compressor of the RNC operates a timer of an IR packet refresh period when the HC initialization process is completed, and transmits an IR packet when the timer reaches 0 (775). The transmission frequency of the IR packet in step 775 may be performed a plurality of times in the same manner as the HC initialization process.

As described above, the RNC transmits the IR packet a plurality of times so that the UEs can properly receive the IR packet in the U-mode of the ROHC. However, only the repeated transmission of the IR packet may not guarantee the successful HC initialization of all UEs to be supported by the MBMS service. For example, if a particular UE is in deep fading state during HC initialization, the UE cannot receive the IR packet without error even if the RNC repeatedly transmits the IR packet. Alternatively, if a specific UE newly subscribes to a cell supporting MBMS service while the HC initialization is in progress, the UE may not participate in the HC initialization process and thus receive data in which the header is compressed without receiving the IR packet. In this case, the UEs may wait for an IR refresh period and then receive and restore the MBMS data after receiving the IR packet retransmitted by the RNC. When the MBMS service operates in the ROHC U-mode, UEs failing to acquire HC information in the HC initialization process cannot receive MBMS data for a long time. Therefore, a solution for solving the above-mentioned problems is discussed.

Accordingly, an object of the present invention for solving the above-mentioned problems of the prior art is to propose a method for re-requesting the HC context information by a user terminal that fails to restore a header of compressed packet data transmitted from a radio network controller.

Another object of the present invention is to propose a method of reducing the amount of data transmitted and received by re-requesting only the HC context information which failed to be restored among the HC context information.

Another object of the present invention is to propose a method in which the radio network controller transmits HC context information through different paths according to the number of user terminals re-requesting HC context information.

Another object of the present invention is to propose a method for receiving the service from a user terminal requesting to join an ongoing service.

In the mobile communication system comprising a wireless network controller for supporting a packet data service and a user terminal for supporting a packet data service transmitted from the wireless network controller to achieve the objects of the present invention, the packet data in the wireless network controller A method of transmitting a header compression context for compressing a header, the method comprising: searching for storing a header compression context requesting retransmission from the user terminal; and searching for the header according to the header compression context requesting the retransmission And determining whether to transmit all or part of the compression context information, and transmitting all or part of the header compression context according to the determination.

In the mobile communication system comprising a wireless network controller for supporting a packet data service and a user terminal for supporting a packet data service transmitted from the wireless network controller to achieve the object of the present invention, the user terminal in the header compression context A method for restoring a header of packet data received by stored information, the method comprising: requesting retransmission of all or part of a header compression context according to a cause of the error when restoring the header; And restoring the header of the received packet data by using the header compression context received by the request.

In the mobile communication system comprising a wireless network controller for supporting a packet data service and a user terminal for supporting a packet data service transmitted from the wireless network controller to achieve the objects of the present invention, the packet data in the wireless network controller A method for transmitting a header compression context for compressing a header, the method comprising: requesting retransmission of all or part of a header compression context according to a cause of the error, when the user terminal encounters an error in header restoration; Searching whether the header compression context requesting retransmission from the user terminal is stored, and determining whether to transmit all or part of the found header compression context information according to the header compression context requesting the retransmission; According to the above header compression context Or it characterized by yirueojim using the process of transferring a portion with the received header compression context with the process to restore the header of the received packet data.

Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. In describing the present invention, when it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted.

7 shows the structure of an HC Context used for ROHC. The structure of the HC context depends on the header compression method used and the type of header to be compressed. The HC Context of FIG. 7 is a context structure when the ROHC scheme is applied to IPv6, UDP, and RTP. As described above, the HC context stores data and related parameters to be used for header compression and decompression by the header compressor and the header decompressor. The structure of the HC Context shown in FIG. 7 describes a part common to the header compressor and the header decompressor. It is apparent that the header compressor and the header recoverer may include other parts in addition to the parts shown in FIG. 7. In addition, the HC Context structure of the header compressor and the header restorer may be slightly different, but is not related to the present invention and thus will not be described.

The plurality of HC contexts stored in the header compressor / header decompressor are distinguished by a unique value called CID 705. This is because each HC context has one unique CID. The HC context consists of a static part 710, a dynamic park 740, and other parameters 790. Each of the parts stores header values or configuration parameters by type. As shown in FIG. 7, each part is divided into a field name 720 indicating the type of field, characteristics of the field (C, 715), size of the field (S, 725), and the like. The size 725 of the field uses b for displaying in bits and B for displaying in bytes. In addition, the V value indicates that the size of the corresponding field is variable. The field name 720 is shown with the name of the protocol to which the field belongs and the field name. For example, a field called IPv6 version includes a protocol name IPv6 and a field name version. The characteristic 715 may be classified as follows.

Ini: This field is not transmitted since it is sent to the header decompressor from the header compressor during the context initialization process because it always has a constant value during the lifetime of the packet stream.

Cha: A field transmitted whenever the field value changes because the field value is not constant.

Con: A field in which the value of the field changes constantly (for example, monotonically increases) and is transmitted in every packet.

SOR: The UDP checksum field 750 is always transmitted in the packet stream in which the UDP checksum is used, but not in the packet stream in which the UDP checksum is not used. Fields that are always transmitted or not transmitted at all, depending on the type of packet stream, due to the above characteristics.

The static part 710 stores values for which a value of a header field does not change while a packet stream is in existence. Therefore, the characteristic of the field values stored in the static part 710 is mostly Ini. The characteristics of each field are described only as necessary, if necessary.

The dynamic part 740 stores values in which the value of the header field is changed while the packet stream is in existence. For example, the IPv6 Traffic Class has a meaning or priority in that a payload of a corresponding packet should be processed at each router, and has a constant value in any single packet stream. However, since the possibility of changing the value of the header field cannot be excluded, the IPv6 Traffic Class is included in the dynamic part. In addition, the IPv6 Hop Limit is a field indicating how many routers the packet has passed up to this point in time, and is changed every time the transmission path is changed.

The other parameters 790 store configuration information of the HC context. For example, information such as the mode in which the HC context operates or whether the mode is in transition is stored in this section.

Hereinafter, the HC Context initialization process and the operations performed in the header compressor and the header decompressor will be described and then the operations in the RNC and the UE according to the present invention will be described. The HC context initialization process consists of a header compressor transmitting a plurality of times an IR packet to a header decompressor. The process of transmitting the IR packet a plurality of times by the header compressor to the header decompressor is the same as that illustrated in steps 640 to 650 of FIG. 6. Steps 640 and 650 of FIG. 6 illustrate an initialization process according to a channel change supporting the MBMS service while supporting the MBMS service, but the present invention supports the MBMS service before the MBMS service is first supported. The only difference is the initialization process. The IR packet includes a CID, static part information, and dynamic part information, which is an identifier of an HC context to be initialized. The header decompressor receiving the IR packet configures the HC context as shown in FIG. 7 based on the information included in the IR packet. Using the configured HC context, the header compressor compresses a header of a packet delivered from an upper layer, inserts a CID in the compressed header, and transmits the same. As described above with reference to FIG. 7, the header compressor has a difference in the compression method according to the characteristics of each field. Hereinafter, the operation of the header compressor will be described once again.

1. If the characteristic of the packet transmitted from the upper layer is Ini, the value of the received uncompressed header field is removed.

2. If the characteristic of the packet transmitted from the upper layer is Cha and has a different value from the value stored in the HC context, the header field value is included in the compression process, and if it has the same value as that stored in the HC context Do not include the value of the header field in the compression process.

3. If the characteristic of packet received from upper layer is Con, only LSB (Last Significant Bits) part is compressed and transmitted as much as it can infer the value correctly. As described above, a technique of transmitting only LSBs as necessary without transmitting the entire value is called W-LSB (Window based Last Significant Bits). The real time transport protocol time stamp (RTP) 770 shown in FIG. 7 has a constant relationship with the real time transport protocol sequence number (RTP SN) and can be deduced from the RTP SN. However, since the relationship between the RTP TS and the RTP SN may be changed in some cases, the RTP TS value is transmitted only when the relationship changes.

4. The stored HC context is updated with the header field value received from the upper layer, and the value of the updated header field is stored.

5. Send the compressed header, CID, and payload to the header decompressor.

The compression header, CID and payload transmitted from the header compressor are recovered by the header decompressor. The operation of the header decompressor is as follows.

1. Select one of a plurality of HC contexts stored using the CID value of the received packet.

2. If the received packet is Ini, add a value stored in the HC context to the removed header field.

3. If the received packet is Cha and is included in the compressed header, the value is added to the header field, and values not included in the compressed header add values stored in the HC context to the header field. .

4. The RTP SN exchanges the RTP SN value stored in the HC Context and the value determined by the received LSB with a value included in the received head field.

5. The RTP TS determines the head field value using the RTP SN.

6. The recovered header is delivered to the upper layer along with the payload, and the HC context is updated.

Hereinafter, the operation of the UE and the RNC according to the present invention will be described in detail with reference to FIG. 8. 8 illustrates a method of transmitting feedback information generated in the header restorer of the UE to the header compressor of the RNC using an RRC connection in an MBMS service environment in which PDCP operates in ROHC U-mode. A state in which the feedback information should be transmitted is referred to as a context request triggering condition (CRTC). Hereinafter, the CRTC will be described.

The CRTC refers to a condition under which the header restorer of the UE transmits feedback information (information for requesting HC) to the header compressor of the RNC, and in the following case, the CRTC is considered to be satisfied.

CRTC 1 (Context Request Triggering Condition 1): The case where the header restorer of the UE requests the entire contents of the HC to the header compressor of the RNC. CRTC 1 is considered a case where a header compressed packet is received in a state in which HC is not configured in the header decompressor of the UE (No Context). For example, if the UE of FIG. 6 does not receive any of the IR packets transmitted in the HC initialization process, the UE is still in a No Context state at the end of the HC initialization process. On receipt, CRTC 1 is considered to have occurred.

CRTC 2: This is a situation where the header restorer of the UE should request a part of the HC from the header compressor of the RNC. When the header restorer performs the header restore operation in a state other than the No Context, it is determined that CRTC 2 occurs when n attempts to restore the header have failed. The k and n values are given by the RTP SN shown in FIG. 7 of the header restorer when the header restorer is configured.

When the CRTC 1 or the CRTC 2 occurs, the header restorer of the UE notifies the contents of the RNC connection to the header compressor of the RNC. The header compressor looks at the type of CRTC notified from the header restorer to determine what information should be transmitted to the header restorer.

In the mobile communication system serving the MBMS, the header compressor of the RNC is configured in the PDCP entity of the RNC, and the header restorer of the UE is configured in the PDCP entity of the UE. The PDCP entities are configured through MTCH during MBMS RB setup. In step 805, the header compressor of the RNC transmits MBMS data to a header restorer of the UE through MTCH. The MBMS data is data whose header is compressed if the HC initialization process has already been performed, and may be an IR packet if the HC initialization process is in progress.

In step 810, the UE PDCP determines whether a CRTC has occurred. The CTRC is generated when a header restorer located in the UE PDCP receives a packet other than an IR packet in a No Context state (CRTC 1), or fails to restore m of m times of headers (CRTC 2). In FIG. 8, it is assumed that CTRC has occurred in the UE PDCP. When the CTRC is generated, the UE PDCP sends a primitive CPDCP-STATUS-IND to the UE RRC in step 815. The CPDCP-STATUS-IND primitive includes a CRTC code. The CRTC code is a parameter indicating the type of the CRTC and has one of the CRTC 1 and the CRTC 2. If the CRTC code is CRTC 2, the CRTC code transmits the RTP serial number (hereinafter, referred to as LATEST RTP SN) of the header that was most recently successfully restored, together with the CID (Context ID). That is, if the CRTC 1 occurs, the CPDCP-STATUS-IND includes only CRTC code information called CRTC 1, and if the CRTC 2 occurs, the CPDCP-STATUS-IND includes CRTC 2, CID, and CRTC code information called LATEST RTP SN. do.

In step 820, the UE RRC transmits an RRC message called PDCP CONTEXT REQUEST to the RNC RRC. If the UE was operating in an idle mode, the RRC connection setup process is preceded. The PDCP CONTEXT REQUEST message includes the following information.

MBMS ID: The identifier of the MBMS service. Identifier same as that used during MBMS RB setup.

RB ID: The identifier of the RB providing the MBMS service. This is the same identifier as the RB identifier used in the MBMS RB setup process.

CRTC code: CRTC code information from CPDCP-STATUS-IND

The MBMS ID and the RB ID correspond one-to-one with the PDCP entity that processes the MTCH data in the RNC. If any PDCP entity is configured through the MBMS RB setup process for the MBMS service, the PDCP entity is identified through the MBMS ID and RB ID used in the MBMS RB setup process.

In step 825, the RNC RRC identifies the PDCP entity using the MBMS ID and the RB ID of the received PDCP CONTEXT REQUEST message, and transfers a primitive CPDCP-CONTEXT-REQ to the corresponding PDCP entity. The CPDCP-CONTEXT-REQ includes a CRTC code. In step 830, the RNC PDCP delivers a primitive called CPDCP-CONTEXT-RES to the RNC RRC. The CPDCP-CONTEXT-RES primitive includes CONTEXT INFO. The CONTEXT INFO is information related to the HC managed by the header compressor of the RNC PDCP and is information to be delivered to the header restorer of the UE. The RNC PDCP, having received the CPDCP-CONTEXT-REQ message of step 825, determines the contents of the CONTEXT INFO according to the delivered CRTC code.

In step 835, the RNC RRC delivers a PDCP CONTEXT RESPONSE message to the UE RRC. The PDCP CONTEXT RESPONSE message includes the following information.

MBMS ID: The identifier of the MBMS service. Identifier same as the MBMS identifier used in the PDCP CONTEXT REQUEST message.

RB ID: The identifier of the RB providing the MBMS service. Identifier same as the RB identifier used in the PDCP CONTEXT REQUEST message.

CONTEXT INFO: CONTEXT INFO in CPDCP-CONTEXT-RES (830)

In step 840, the UE RRC delivers a CPDCP-CONFIG-REQ primitive to the UE PDCP, and the CPDCP-CONFIG-REQ primitive includes CONTEXT INFO of the PDCP CONTEXT RESPONSE message. The UE PDCP updates the stored HC using the delivered CONTEXT INFO. If the cause of the CRTC in step 810 is resolved through the HC update in step 840, the UE PDCP normally performs a header restore operation from step 845. That is, if CRTC 1 occurs in step 810, the header restorer does not receive the IR packet, and because of this, there is no HC information. Therefore, in step 840, the entire HC is received. If CRTC 2 occurs in step 810, some HC information of the header restorer has not been received, and thus HC information required in step 840 will be received. In step 850, the header compressor and the header restorer having performed the above-described processes perform header compression and header restoration operations while transmitting and receiving the MBMS data.

9 illustrates operations performed on a UE PDCP according to the present invention. Hereinafter, an operation performed in the UE PDCP will be described in detail with reference to FIG. 9. The UE PDCP configures an MBMS RB and restores a header of data received through the MTCH. In step 905, the UE PDCP receives MBMS data through MTCH. In step 910, the UE PDCP attempts to recover the header of the received MBMS data using the HC stored in the header decompressor. If the attempt result header restoration is successful, go to step 915; if the attempt result header restoration fails, go to step 920;

In step 915, the UE PDCP transfers successfully restored header and data to a higher layer, and moves to step 930. In step 920, the UE PDCP discards the data that fails to recover the header and determines whether the CRTC is satisfied. That is, it is determined whether the cause of the header restoration failure corresponds to CTRC1 or CTRC 2. If the cause of the failure corresponds to CTRC1 or CTRC 2, the method proceeds to step 925. If the cause of the failure does not correspond to CTRC1 or CTRC 2, the procedure goes to step 930. In step 925, the UE PDCP delivers CPDCP-STATUS-IND to the UE RRC to obtain HC information of the UE header compressor. The primitive includes a CRTC code. As described above, if the CRTC 1, the primitive is composed of a CRTC code, and if the CRTC 2, the primitive is composed of a CRTC code, a CID, and a LATEST RTP SN.

The UE PDCP performing the step 925 moves to step 930. In step 930, the UE PDCP determines whether there is further packet data to be header restored. If there is more header to be restored as a result of the determination, the flow proceeds to step 905. If there is no header to be restored as a result of the determination, it ends.

In FIG. 9, the UE PDCP is limited to the case in which the UE transmits a message to the UE RRC. However, the UE PDCP updates the HC of the header decompressor using the HC information transmitted from the UE. That is, when the HC information requested by the UE PDCP is transmitted through a CPDCP-CONFIG-REQ message, the HC stored in the header decompressor is updated using the transmitted HC.

10 illustrates operations performed in the UE RRC. Hereinafter, an operation performed in the UE RRC according to the present invention will be described with reference to FIG. 10. In step 1005, the UE RRC receives a CPDCP-STATUS-IND primitive from the UE PDCP. In addition, the UE RRC checks the identifier of the PDCP entity of the UE PDCP that delivered the CPDCP-STATUS-IND. As described above, the PDCP entity identifier is an identifier and an RB identifier of an MBMS service corresponding to the MTCH to which the PDCP entity belongs.

In step 1010, the UE RRC configures a PDCP CONTEXT REQUEST message and transmits the configured PDCP CONTEXT REQUEST message to the RNC RRC. The PDCP CONTEXT REQUEST message includes the MBMS ID, RB ID, and CRTC code identified in step 1005. If the UE is operating in the RRC idle mode in step 1005, the UE RRC first performs the RNC RRC and RRC connection setup procedure. Signaling Radio Bearers (SRBs) are configured between the UE and the RNC through the RRC connection setup process. The SRB is an RB (radio bearer) configured between the RNC and the UE to transmit and receive the RRC message. One UE may have a plurality of SRBs, and each of the SRBs may have a unique transmission characteristic. For example, SRB 1 transmits an RRC message to RLC UM, and SRB 2 transmits an RRC message to RLC AM.

The UE RRC transmitting the PDCP CONTEXT REQUEST message determines whether a PDCP CONTEXT RESPONSE message is received in step 1015. If the PDCP CONTEXT RESPONSE message is received as a result of the determination, go to step 1020. If the PDCP CONTEXT RESPONSE message is not received, the process moves to step 1015 and waits until the PDCP CONTEXT RESPONSE message is received.

The UE RRC receiving the PDCP CONTEXT RESPONSE message identifies a PDCP entity to which CONTEXT INFO is delivered using the MBMS ID and the RB ID of the received message. In step 1020, the UE RRC delivers to the PDCP entity identifying the CPDCP-CONFIG-REQ having the CONTEXT INFO of the received PDCP CONTEXT RESPONSE message as a parameter.

11 illustrates the operation of the RNC RRC in accordance with the present invention. The RNC RRC that receives the PDCP CONTEXT REQUEST message in step 1105 identifies a PDCP entity to receive CONTEXT INFO from the RNC PDCP using the MBMS ID and the RB ID of the message. In step 1110, the RNC RRC delivers CPDCP-CONTEXT-REQ to the PDCP entity indicated by the MBMS ID and RB ID of the PDCP CONTEXT REQUEST message. In the primitive, CRTC code information of a PDCP CONTEXT REQEUST message is inserted. The RNC RRC, which has delivered the CPDCP-CONTEXT-REQ to the PDCP entity, determines whether CPDCP-CONTEXT-RES is received. If the CPDCP-CONTEXT-RES is received as a result of the determination, the process moves to step 1120. If the CPDCP-CONTEXT-RES is not received, the process moves to step 1115 and waits until the CPDCP-CONTEXT-RES is received.

In step 1120, the RNC RRC inserts CONTEXT INFO of CPDCP-CONTEXT-RES into a PDCP CONTEXT RESPONSE message and transmits the PDCP CONTEXT RESPONSE message to the UE RRC using a reliable SRB.

12 illustrates the operation of the RNC PDCP in accordance with the present invention. In step 1205, the RRC PDCP receives the CPDCP-CONTEXT-REQ. In step 1210, the CRTC code information included in the CPDCP-CONTEXT-REQ is checked. If the CRTC code information is CRTC 1, the control proceeds to step 1215. If the CRTC code information is CRTC 2, the procedure goes to step 1225. In step 1215, the RRC PDCP inserts HC_current into a CONTEXT INFO parameter. The RNC PDCP manages one HC set for one CID, and the HC set is configured as follows.

HC set for specific CID = [HC_current, HC_RTP SN x, HC_RTP SN x-1, ....]

The HC_current means the most recent HC, and the HC_RTP SN x means HC when the RTP SN is x. The RNC PDCP stores not only HC_current but also HC_RNT SN x, which are past HC values, depending on the situation (for example, when there is sufficient space in the storage space). The past HC information is used when constructing a response primitive for CRTC 2. In step 1220, the RNC PDCP delivers the CPDCP-CONTEXT-RES including the CONTEXT INFO parameter created in step 1215 to the UE RRC and terminates.

In step 1225, the RNC PDCP calculates the HC_diff corresponding to the CID. As described above, the RNC PDCP includes one HC set for one CID and uses information included in the HC set corresponding to one CID when calculating the HC_diff. The HC_diff is a set of values corresponding to the HC_current and the HC_LATEST RTP SN included in the CRTC 2. The LATEST RTP SN is an RTP SN of a packet that the header restorer of the UE most recently succeeded. In order to correct the difference between the HC of the UE header restorer and the HC_current of the RNC header compressor, it is necessary to inform the header restorer of values corresponding to the HC_current and the HC_LATEST RTP SN. If the HC_LATEST RTP SN is not available in the header compressor, the header compressor considers HC_diff as the entire dynamic part of HC_current.

In step 1230, the RNC PDCP inserts the HC_diff calculated in step 1225 into CONTEXT INFO. In step 1235, the RNC PDCP inserts the CONTEXT INFO into the CPDCP-CONTEXT-RES and delivers it to the UE RRC and ends.

8 to 12 use the RRC message when the header compressor of the RNC delivers the HC information to the header restorer of the UE. If the number of UEs requesting HC information for a certain period is small, one-to-one information transfer using the RRC message is valid. However, when the number of UEs requesting the HC information is large, there is an inefficiency that the RRC message should be delivered by the number of UEs. FIG. 13 illustrates a method of transmitting an IR packet, an IR DYN packet, or a UOR-2 packet through MTCH without using the RRC message when the number of UEs for which the RNC requests HC information is large.

FIG. 13 illustrates a process in which a UE requests retransmission for an IR packet to an RNC according to the present invention. Operations performed in steps 1305 to 1320 of FIG. 13 are the same as operations performed on steps 805 to 820 of FIG. 8. In step 1325, the RNC RRC determines whether to use a user plane or the RRC message for updating HC information. Referring to FIG. 13, when the user plane update triggering condition (UPUC) is satisfied, the HC information is transmitted using the user plane, and when the UPUC is not satisfied, the RRC message is used. Whether the UPUC is satisfied may be performed by an RRC entity, a PDCP, or a separate entity. In FIG. 13, it is assumed that the RRC entity determines whether the UPUC is satisfied. Whether the UPUC is satisfied is determined by the number of UEs that have requested the HC information among UEs located in the same cell for a predetermined time. In order to determine whether the UPUC is satisfied, two parameters, T_1 and a triggering point, are required. The T_1 is a period required to determine whether the UPUC is satisfied, and the triggering point is the number of PDCP CONTEXT REQUESTs transmitted by UEs located in the same cell for satisfying the UPUC.

The determination of whether the UPUC is satisfied is as follows, and the determination is performed in units of cells. That is, the operation of the T_1 timer, the number of PDCP CONTEXT REQUESTs, and the like are related to one cell.

[UPUC Satisfaction Algorithm]

1. The RNC RRC operates the T_1 timer at the time when the first PDCP CONTEXT REQUEST is received after transmitting the HC information for a specific cell, and sets the # OF REQUEST counter to 1.

2. The RNC RRC increments the # OF REQUEST counter by 1 each time a PDCP CONTEXT REQUEST received by another UE located in the same cell as the UE is located.

3. The RNC RRC considers the UPUC satisfied if the # OF REQUEST counter is greater than or equal to the Triggering point before the T_1 timer expires.

4. The RNC PDCP considers that the UPUC is not satisfied if the # OF REQUEST counter is less than the triggering point even when the T_1 timer is terminated.

If the UPUC is not satisfied as a result of the determination of 1325, the HC information is transmitted to the UE using an RRC message by the operation as shown in FIG. 8. As a result of the determination, if the UPUC is satisfied, the HC information is transmitted to the corresponding UEs using the MTCH configured in the user plane as shown in FIG. 13. Hereinafter, from step 1330, it is assumed that the UPUC is satisfied. In step 1330, the RNC RRC delivers a CPDCP-CONTEXT UPDATE-REQ primitive to the RNC PDCP. If the RNC PDCP corresponding to the MTCH is configured for each cell, the CPDPC-CONTEXT UDPATE-REQ is transmitted to the RNC PDCP in charge of the corresponding cell to which the HC information is to be transmitted. If only one PDCP corresponding to the MTCH is configured in the RNC, the CPDCP-CONTEXT UPDATE-REQ primitive includes an identifier for identifying a cell to which HC information is to be transmitted. Due to the CPDCP-CONTEXT UPDATE-REQ primitive, MBMS data containing the HC information is transmitted through MTCH. In this case, MBMS data containing the HC information should be transmitted only to a cell satisfying UPUC.

The CPDCP-CONTEXT UPDATE-REQ includes CRTC code information, and the CRTC code information is determined as follows. In step 1320, UPUC is satisfied only when UEs having a triggering point or more transmit a PDCP CONTEXT REQUEST message in the same cell, and the PDCP CONTEXT REQUEST message includes a CRTC code, and sets the CRTC codes as a CRTC code set. This is called.

1. In the CRTC code set, the CRTC code checks whether CRTC 2 exists.

2. In 1, if CRTC 2 exists, it moves to 4, and if not, moves to 3.

3. Insert CRTC 1 information CRTC 1 into CPDCP-CONTEXT UPDATE-REQ.

4. Insert CRTC 2 and LATEST RTP SN into CRTC code in the CPDCP-CONTEXT UPDATE-REQ. The LATEST RTP SN is the smallest LATES RTP SN value in the CRTC code set.

In step 1340, the RNC PDCP transmits an IR packet, an IR-DYN packet, or a UOR-2 packet. The situation in which the respective packets are transmitted is as follows. If the CRTC code received in step 1330 is CRTC 1, the RNC PDCP transmits an IR packet through MTCH. The IR packet is a packet including both the static part, the dynamic part, and other parts of the HC shown in FIG. 7. If the CRTC code received in step 1330 is CRTC 2 and has the RNC PDCP HC_LATEST RTP SN, the RNC PDCP calculates HC_diff. The calculated HC_diff is transmitted using a UOR-2 packet. The UOR-2 packet is a packet including only a necessary part of the dynamic part through an extension field. In the extended field of the UOR-2 packet, there are flags corresponding to each part of the dynamic part, and the presence or absence of each part is indicated through the flag. Accordingly, the header compressor of the RNC can selectively transmit the HC information to be newly updated using the UOR-2 packet. If the CRTC code received in step 1330 is CRTC 2 and the RNC PDCP does not have the HC_LATEST RTP SN, the RNC PDCP transmits an IR-DYN. The IR-DYN packet is a packet including only the dynamic part of the HC shown in FIG.

The IR packet, the IR-DYN packet, or the UOR-2 packet transmitted in step 1340 may be transmitted several times to increase the reception probability of the UE. In step 1345, the MBMS data of which the header is compressed is transmitted.

As the case where the HC initialization failure may occur, the UE has not received HC information due to a poor radio environment during the HC initialization process. However, the same problem may occur in a UE that is going to subscribe to the service while the service is already in progress. Hereinafter, a problem that may occur to a UE who wants to subscribe to the service while the service is in progress will be described with reference to FIG. 14.

In step 1405, the UE receives MBMS service from the CRNC. That is, since the HC initialization process is already performed, the CRMC compresses and transmits the header of MBMS data, and the UE is supported by the MBMS service by restoring the header of the compressed MBMS data. In step 1410, the UE transmits a message for requesting MBMS service to SGSN. That is, the UE transmits a message requesting subscription to an ongoing service. In step 1415, the SGSN transmits a response message for the subscription request of the UE. In step 1415, the SGSN transmits an acceptance message for the subscription request of the UE.

The SGSN transmitting the accept message in step 1415 notifies the SRNC that the UE requesting to join the MBMS service is located in step 1420 and the SRNC wants to request to join the MBMS service. If the SRNC and the CRNC are different entities, separate signaling is required between the SRNC and the CRNC. However, in the present invention, it is assumed that the SRNC and the CRNC are the same entity. In step 1425, the CRNC delivers information about layer 1 and layer 2 of the MBMS service provided by the cell where the UE is located. The UE configures a radio channel through which the MBMS service is provided using the information transmitted in step 1425, and receives the MBMS service using the configured radio channel.

However, the CRNC uses a compressed header in supporting the MBMS service. In other words, the CRNC supports the MBMS service using the compressed header from step 1405. However, since the UE is not informed of the compressed HC context, the UE cannot receive the MBMS service delivered by the CRNC. That is, even if the UE receives data desired by the user through a wireless channel without any problem, the UE cannot restore the compressed header and thus cannot receive the MBMS service delivered by the CRNC. Step 1430 shows that the UE cannot restore the header of the received MBMS data. The UE has no choice but to discard the received MBMS data until the IRNC periodically transmits the IR packet (step 1445).

Hereinafter, a solution for solving the problem of FIG. 14 will be described with reference to FIGS. 15 to 18. First, a first embodiment for solving the problem of FIG. 14 will be described with reference to FIGS. 15 to 16.

Since steps 1410 to 1420 of FIG. 15 are the same as steps 1410 to 1420 of FIG. 14, description thereof will be omitted. In step 1525, the CRNC that recognizes the UE requesting to join the ongoing MBMS service transmits configuration information of the radio channel in which the MBMS service is provided. The configuration information of the radio channel includes not only information about layer 1 and layer 2 but also HC context information of the provided MBMS service. The UE stores the HC context received in step 1525. In step 1530, the UE receives MBMS data in which the header transmitted by the CRNC is compressed, and restores the received data using the stored HC context information.

As described above, when the CRNC of FIG. 15 provides radio channel configuration information for a specific MBMS service to an arbitrary UE, the CRNC first determines whether the specific MBMS service is in progress in a cell where the arbitrary UE is located. As a result of the determination, if the specific MBMS service is in progress, the HC context information is included in the radio channel configuration information transmitted to the arbitrary UE.

Even if the arbitrary UE subscribes to the service while the service is in progress, if the MBMS service data is not transmitted in the cell where the UE is located, the UE may receive the HC context information through the PTM as shown in FIG. 13. . In addition, if the cell in which the arbitrary UE is located transmits data of the MBMS service to the PTP, the random UE receives the HC context information through the PTP. That is, FIG. 15 is limited to the case where the MBMS service is transmitted to the PTM, and the MBMS data is already transmitted in the cell where the UE requesting the subscription is located. Hereinafter, the operation of the CRNC of FIG. 15 will be described with reference to FIG. 16.

In step 1605, the CRNC recognizes that UE x that has requested a subscription for a certain MBMS service y has occurred, and that the cell where the UE x is located is z. The fact that the UE x that requested the subscription has occurred is information that the CRNC always recognizes. As described above, the UE that wants to receive the MBMS service performs a subscription process with the SGSN. The SGSN performing the subscription process transmits a notification message to the RNC in which the UE requests to subscribe to the MBMS service in progress. The notification message includes the identifier of the MBMS service that the UE intends to receive. Upon receiving the notification message, the CRNC determines whether the MBMS service is provided to the PTM in the cell where the UE is located. The provision of the service to the PTM means that the service is transmitted through the common channel.

In step 1610, the CRNC generates an MBMS radio bearer setup message so that the UE x can receive the MBMS service in cell z. The MBMS radio bearer setup message includes radio channel configuration information. The radio channel configuration information includes PDCP configuration information, RLC configuration information, MAC configuration information, and physical layer configuration information. In addition to the configuration information, the HC context information is also included. In step 1615, the CRNC transmits the generated MBMS radio bearer setup message to the UE x. Upon receiving the message, the UE first configures a PDCP entity, an RLC entity, a MAC entity, and a physical layer according to PDCP configuration information, RLC configuration information, MAC configuration information, and physical layer configuration information. The UE delivers the HC context information to the configured PDCP entity, and the PDCP entity configures the HC context using the received HC context information. The UE recovers MBMS data with the compressed header sent by the CRNC using the configured HC context.

FIG. 17 illustrates a second embodiment for solving the problem of FIG. 14. In step 1705, the UE performs a subscription process with the SGSN. A detailed description of the subscription process is as described above. In step 1710, the CRNC RRC recognizes that a UE requesting to join an ongoing MBMS service has occurred. The step 1710 can be known through the notification message transmitted by the SGSN as described in step 1420 of FIG. In step 1715, the CRNC RRC transmits an MBMS radio bearer setup message to the UE RRC. A PDCP entity, an RLC entity, a MAC entity, and a physical layer are configured according to the MBMS radio bearer setup message PDCP configuration information, RLC configuration information, MAC configuration information, and physical layer configuration information.

In step 1720, the CRNC RRC notifies that the UE requesting subscription to the MBMS service in progress to the CRNC PDCP has occurred. In step 1725, the CRNC PDCP transmits an IR packet to the cell where the UE requesting the subscription is located. The UE PDCP receives the IR packet transmitted in step 1725 and initializes the HC context using the received IR packet. The UE PDCP then recovers MBMS data with the compression header transmitted by the CRNC PDCP. In FIG. 15, a method of including HC context information for header restoration is proposed and transmitted in an MBMS radio bearer setup message, but in FIG. 17, a scheme for transmitting through an IR packet which is information necessary for header restoration is proposed. That is, FIG. 17 proposes a method of transmitting an IR packet for a header recovery at regular intervals and transmitting an IR packet even before the predetermined period when an IR packet is required due to a UE subscribed to an MBMS service.

FIG. 18 illustrates a third embodiment for solving the problem of FIG. 14. 18 illustrates a method of periodically transmitting HC context information for UEs requesting subscription to an ongoing MBMS service. As described above, the RNC multicasts a control message related to the MBMS service through the MCCH. In this case, the RNC periodically transmits MBMS radio bearer information of the MBMS service being serviced for each cell in order to guarantee the mobility of the UE. The MBMS radio bearer information includes PDCP configuration information, RLC configuration information, and MAC configuration information according to each service.

In step 1805 or 1815, the CRNC includes HC context information in MBMS radio bearer information transmitted periodically to ensure mobility of the UE. In step 1810, the UE requesting to join the ongoing MBMS service occurs. The UE receives MBMS radio bearer information periodically transmitted in step 1815 and HC context information included in the MBMS radio bearer information. In step 1815, the UE configures a PDCP entity, an RLC entity, a MAC entity, and a physical layer using MBMS radio bearer information, and initializes an HC context using HC context information.

As described above, the method of periodically transmitting the HC context is effectively used to guarantee the mobility of the UE. When the UE moves from one cell to another cell, it should receive the MCCH and obtain configuration information of the MBMS service that it wants to receive. However, the content of the HC context is the same only the difference between the RTP SN and the RTP TS for the same service. If the RTP SN and the RTP TS of the current cell and the RTP SN and the RTP TS of the previous cell are different and the HC context information is not received in the current cell, the UE cannot restore the compressed header. However, when the HC context information is periodically transmitted through the MCCH as shown in FIG. 18, the moving UE can acquire the RTP SN and the RTP TS using the periodically transmitted HC context information, thereby performing header restoration. Will be. When generating the HC context information included in the periodically transmitted MBMS radio bearer information in consideration of the mobility of the UE, only the RTP SN and the RTP TS may be generated instead of generating all the information necessary for the HC context.

As described above, in the present invention, a UE that does not receive HC context information through an IR packet may request retransmission of the HC context information, and receive the MBMS service using the HC context information received by the request. have. As a result, the UE can be efficiently supported by the MBMS service. In addition, by transmitting the HC context information in different paths according to the number of UEs requesting retransmission of the HC context, it is possible to efficiently use radio resources.

1 is a diagram illustrating a structure of a general mobile communication system.

2 is a diagram illustrating a structure of a Uu interface between a wireless network controller or a user terminal.

3 illustrates the structure of a multimedia broadcasting / multicasting service (MBMS) system.

4 is a diagram illustrating an operation between nodes of a mobile communication system supporting an MBMS service.

5 is a diagram illustrating a process of compressing a header of MBMS packet data in a wireless network controller and restoring a compressed header in a user terminal.

FIG. 6 is a diagram illustrating an operation of a mobile communication system supporting MBMS service using header context information.

7 illustrates the structure of a header compression context (HC context) used for header compression / restore.

8 is a diagram illustrating an operation of a user terminal re-requesting header compression context information and a wireless network controller retransmitting header compression context information according to the present invention.

9 is a diagram illustrating the operation of a packet data convergence protocol of a user terminal supported by an MBMS service according to the first embodiment of the present invention.

10 is a diagram illustrating an operation of a radio resource controller of a user terminal supported by an MBMS service according to the present invention.

11 is a diagram illustrating an operation of a radio resource controller of a radio network controller supporting an MBMS service according to the present invention.

12 is a diagram illustrating an operation of a packet data convergence protocol of a wireless network controller supporting an MBMS service according to the present invention.

FIG. 13 is a diagram illustrating an operation of a user terminal re-requesting header compression context information and a wireless network controller retransmitting header compression context information according to a second embodiment of the present invention.

14 is a diagram illustrating a problem occurring in a user terminal requesting to subscribe to an ongoing MBMS service.

FIG. 15 illustrates a first embodiment for solving the problem of FIG. 14 in accordance with the present invention. FIG.

FIG. 16 is a diagram illustrating an operation performed in the wireless network controller of FIG. 15. FIG.

FIG. 17 illustrates a second embodiment for solving the problem of FIG. 14 in accordance with the present invention. FIG.

FIG. 18 illustrates a third embodiment for solving the problem of FIG. 14 in accordance with the present invention. FIG.

Claims (20)

In a mobile communication system comprising a wireless network controller supporting a packet data service and a user terminal supporting a packet data service transmitted from the wireless network controller, a header compression context for compressing a header of packet data in the wireless network controller is provided. In the transmission method, Searching whether the header compression context requesting retransmission from the user terminal is stored; Determining whether to transmit all or part of the found header compression context information according to the header compression context that requested retransmission; And transmitting all or part of the header compression context according to the determination. The method as claimed in claim 1, wherein the requested header compression context is transmitted using a dedicated channel when the number of user terminals requesting retransmission of the header compression context for a predetermined time is less than the set number. The method as claimed in claim 1, wherein the requested header compression context is transmitted using a common channel when the number of user terminals requesting retransmission of the header compression context during the set time is not less than the set number. . The method as claimed in claim 1, wherein when all of the header compression contexts are requested, all of the header compression context information currently used by the wireless network controller is transmitted. The method as claimed in claim 1, wherein the header reconstruction context information is received from the user terminal at the same time as the partial request of the compression context. 6. The method of claim 5, wherein the wireless network controller transmits only a value corresponding to a difference between the header compression context information currently used and the transmitted header decompression context information when a part of the header compression context is requested. Way. In a mobile communication system comprising a wireless network controller supporting a packet data service and a user terminal receiving a packet data service transmitted from the wireless network controller, a packet received by the information stored in a header compression context at the user terminal In the method for restoring the header of the data, Requesting retransmission of all or part of the header compression context according to the cause of the error if the header restoration fails; Restoring the header of the received packet data using the header compression context received by the request. 8. The method as claimed in claim 7, wherein the header restoration context information for restoring the header of the most recently received packet data is transmitted simultaneously with the partial request of the compression context. In a mobile communication system comprising a wireless network controller supporting a packet data service and a user terminal supporting a packet data service transmitted from the wireless network controller, a header compression context for compressing a header of packet data in the wireless network controller is provided. In the transmission method, Requesting retransmission of all or part of a header compression context by the user terminal when an error occurs in the header restoration; Searching whether the header compression context requesting retransmission from the user terminal is stored; Determining whether to transmit all or part of the found header compression context information according to the header compression context that requested the retransmission, and transmitting all or part of the header compression context according to the determination; And restoring a header of the received packet data by using a received header compression context. The method as claimed in claim 9, wherein the requested header compression context is transmitted using a dedicated channel when the number of user terminals requesting retransmission of the header compression context for a predetermined time is less than the set number. 10. The method of claim 9, wherein the requested header compression context is transmitted using a common channel when the number of user terminals that request retransmission of the header compression context for the set time is not less than the set number. . 10. The method as claimed in claim 9, wherein when all of the header compression contexts are requested, all of the header compression context information currently used by the wireless network controller is transmitted. The method as claimed in claim 9, wherein the header reconstruction context information is received from the user terminal at the same time as the partial request of the compression context. 15. The method of claim 13, wherein when requesting a part of the header compression context, the wireless network controller transmits only a value corresponding to a difference between header compression context information currently used and the transmitted header decompression context information. Way. In a mobile communication system including a wireless network controller supporting a packet data service and a user terminal supporting a packet data service transmitted from the wireless network controller, a header of packet data is compressed to a user terminal requesting a packet data service being serviced. In the method for transmitting a header compression context for Searching for a header compression context of packet data serving a cell in which the user terminal is located; And transmitting the found header compression context to the user terminal. The method as claimed in claim 15, wherein the header compression context is included in information for configuring a radio channel for transmitting the packet data. The method as claimed in claim 16, wherein the information for configuring the radio channel is periodically transmitted at a set time. 18. The method as claimed in claim 17, wherein the information for configuring the radio channel varies according to characteristics of a cell in which the packet data is serviced. The method of claim 15, wherein the header compression context is transmitted through a transmission path separate from a transmission path of information for configuring a wireless channel for transmitting the packet data. 20. The method of claim 19, wherein the header compression context is transmitted through a dedicated channel.