Source: https://patents.google.com/patent/US8416678B2/en
Timestamp: 2019-09-17 05:11:18
Document Index: 159012817

Matched Legal Cases: ['Application No. 60', 'Application No. 10', 'art 2', 'Application No. 200880102631', 'Application No. 200880107176', 'Application No. 200880107676', 'Application No. 200880107904', 'Application No. 2008801163460', 'Application No. 20088017173', 'Application No. 200980100119', 'Application No. 200980100119', 'Application No. 200980109358', 'Application No. 08766509', 'Application No. 08011263', 'Application No. 08766423', 'Application No. 09722068', 'Application No. 11009737', 'Application No. 10', 'Application No. 097123135']

US8416678B2 - Method for repairing an error depending on a radio bearer type - Google Patents
Method for repairing an error depending on a radio bearer type Download PDF
US8416678B2
US8416678B2 US12/739,282 US73928208A US8416678B2 US 8416678 B2 US8416678 B2 US 8416678B2 US 73928208 A US73928208 A US 73928208A US 8416678 B2 US8416678 B2 US 8416678B2
US12/739,282
US20100246382A1 (en
2008-10-29 Priority to US12/739,282 priority patent/US8416678B2/en
2008-10-29 Priority to PCT/KR2008/006375 priority patent/WO2009057941A2/en
2010-04-22 Assigned to LG ELECTRONICS INC. reassignment LG ELECTRONICS INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LEE, YOUNG DAE, YI, SEUNG JUNE, CHUN, SUNG DUCK, PARK, SUNG JUN
2010-09-30 Publication of US20100246382A1 publication Critical patent/US20100246382A1/en
2013-04-09 Publication of US8416678B2 publication Critical patent/US8416678B2/en
The present application is a national stage of PCT International Application
No. PCT/KR2008/006375, filed Oct. 29, 2008, and claims the benefit of U.S. Provisional Application No. 60/983,304, filed Oct. 29, 2007. The present national stage application also claims the benefit of Korean Patent Application No. 10-2008-0106298, filed Oct. 29, 2008.
FIG. 1 is a diagram illustrating an example of a method of performing ciphering in a PDCP layer. A PDCP layer of a transmitting side generates ciphered data by covering original data with a MASK. The MASK is a code varied for each of the aforementioned packets. Covering original data with a MASK means that XOR operation for each bit is performed for the original data with respect to MASK. A PDCP layer of a receiving side, which has received the ciphered data, deciphers the original data by again covering the original data with a MASK. The MASK has 32 bits and is generated from several input parameters. In particular, in order to generate different values for respective packets, COUNT is generated using PDCP SN varied depending on PDCP PDU. The COUNT is used as one of MASK generation input parameters. In addition to the COUNT, examples of the MASK generation input parameters include ID value (bearer of FIG. 1) of a corresponding RB, Direction having an uplink or downlink value, and a ciphering key (CK) exchanged between a user equipment and a network during RB establishment.
FIG. 2 is a diagram illustrating an example of a method of performing integrity protection in a PDCP layer. Similarly to the aforementioned ciphering procedure, in an integrity protection procedure, parameters, such as COUNT based on PDCP SN, bearer which is ID value of RB, Direction having an uplink or downlink value, and integrity protection key (IK) exchanged between a user equipment and a network during RB establishment, are used. A specific code, i.e., MAC-I (Message Authentication Code-Integrity) is generated using the above parameters. The integrity protection procedure is different from the aforementioned ciphering procedure in that the generated MAC-I is added to PDCP PDU not undergoing XOR operation with original data. The PDCP layer of the receiving side, which has received the MAC-I, generates XMAC-I using the same input parameter as that used in the PDCP layer of the transmitting side. Afterwards, XMAC-I is compared with MAC-I, and if two values are equal to each other, it is determined that the data have integrity. If not so, it is determined that the data have been changed.
If a security error occurs for some reason, since the receiving side cannot recover the original data even if it receives the data from the transmitting side, the received data continue to come into disuse. RB of a user plane (i.e., data RB: DRB) performs header compression after deciphering the received PDCP PDUs. At this time, if deciphering is performed using a wrong MASK, error continues to occur during header decompression, whereby the received PDCP PDUs continue to come into disuse. RB of a control plane (i.e., signaling RB: SRB) performs integrity verification after deciphering the received PDCP PDUs. At this time, if deciphering is performed using a wrong MASK or comparison is performed using a wrong XMAC-I, error continues to occur during integrity verification, whereby the received PDCP PDUs continue to come into disuse.
Accordingly, if a security error occurs, the user equipment and/or the network regards it as a serious problem and thus re-establishes RRC connection between them and re-establishes security. If RRC connection is re-established, all SRBs and all DRBs are also re-established.
For example, security error may occur as an input parameter used for a security algorithm in a transmitting side is not identical with that in a receiving side. A hyper frame number (HFN), which is one of input parameters, may be varied depending on the transmitting side and the receiving side. This error occurs in a corresponding RB if a large number of PDCP SDUs (service data units) are damaged. This is because that HFN corresponding to the MSB of COUNT increases by one if the PDCP SN corresponding to the LSB of COUNT returns to 0 after reaching a maximum value. That is, if the PDCP SDU is damaged within the range that a PDCP SN is a wrap-around, HFN de-synchronization occurs. Also, when an error occurs in a lower layer, wherein the error is not found even by a cyclic redundancy code (CRC) check, HFN de-synchronization may occur if PDCP SN value exceeds an effective range.
Accordingly, the present invention is directed to a method of re-establishing a radio bearer in a wireless communication system, which substantially obviates one or more problems due to limitations and disadvantages of the related art.
An object of the present invention is to provide a method of ensuring quality of service (QoS) in a wireless communication system and using radio resources efficiently.
Still another object of the present invention is to provide a method of performing communication between a user equipment and a network to repair an error of a radio bearer.
Further still another object of the present invention is to provide a communication method of re-synchronizing de-synchronized specific parameters of a radio bearer.
It is to be understood that the technical solutions to be achieved by the present invention will not be limited to the aforementioned description, and another technical solutions, which are not described, will be apparent to those skilled in the art to which the present invention pertains, from the following detailed description of the present invention.
First, it is possible to ensure quality of service (QoS) in the wireless communication system and efficiently use radio resources.
Second, it is possible to efficiently repair an error occurred in a radio bearer.
Third, it is possible to provide a communication procedure between a user equipment and a network for repairing an error of a radio bearer.
Finally, it is possible to re-synchronize de-synchronized specific parameters of a radio bearer.
FIG. 1 is a diagram illustrating an example of a method of applying a ciphering function of security functions performed in a PDCP layer to a packet;
FIG. 3 is a diagram illustrating a network structure of an E-UMTS (Evolved Universal Mobile Telecommunications System);
FIG. 5A and FIG. 5B are schematic views illustrating a control plane and a user plane of a radio interface protocol between a user equipment (UE) and E-UTRAN;
FIG. 6A and FIG. 6B are diagrams illustrating structures of second layers for a downlink and an uplink;
FIG. 9 is a flow chart illustrating an example of a method of repairing an error of a radio bearer in accordance with one embodiment of the present invention;
FIG. 10 is a detailed flow chart illustrating the flow chart of FIG. 9;
FIG. 11 is a diagram illustrating an example of a method of repairing a security error of a data radio bearer in accordance with one embodiment of the present invention;
FIG. 12 is a diagram illustrating an example of a method of repairing a security error of a data radio bearer in accordance with another embodiment of the present invention; and
FIG. 3 is a diagram illustrating a network structure of UMTS to which the embodiment of the present invention is applied. An E-UMTS is a system evolving from the conventional WCDMA (Wideband Code Division Multiple Access) UMTS and its basic standardization is currently handled by the 3GPP (3rd Generation Partnership Project). The E-UMTS can also be called an LTE (Long Term Evolution) system. Release 7 and Release 8 of 3GPP technical specifications (3rd Generation Partnership Project; Technical Specification Group Radio Access Network) can be referred to obtain detailed information of technical specification about the UMTS and the E-UMTS.
Referring to FIG. 3, the E-UMTS includes a user equipment (UE), a base station, and an access gate (AG) located at the end of the E-UTRAN and connected with an external network. Generally, the base station can simultaneously transmit multi-data streams for broadcast service, multicast service, and/or unicast service. The AG may be divided into a user traffic processing part and a control traffic processing part. At this time, the AG for processing user traffic and the AG for processing control traffic can communicate with each other using a new interface. One or more cells exist in one eNB. An interface for transmitting user traffic or control traffic can be used between eNBs. A core network (CN) can include an AG and a network node for user subscription of a user equipment (UE0. An interface for identifying E-UTRAN from CN can be used. The AG manages mobility of a user equipment in a unit of tracking area (TA). The TA includes a plurality of cells. If the user equipment moves from a specific TA to another TA, the user equipment notifies the AG that the TA where the user equipment is located has been changed.
FIG. 4 is a schematic view illustrating a mobile communication system, i.e., an E-UTRAN (UMTS terrestrial radio access network) to which the embodiment of the present invention is applied. The E-UTRAN system is a system evolving from the existing UTRAN system. The E-UTRAN includes base stations eNBs, which are connected with each other through X2 interface. The eNB is connected with the user equipment through a radio interface, and is connected with an evolved packet core (EPC) through S1 interface.
FIG. 5A and FIG. 5B illustrate structures of a control plane and a user plane of a radio interface protocol between a user equipment and UTRAN (UMTS Terrestrial Radio Access Network) based on the 3GPP radio access network standard. The radio interface protocol horizontally includes a physical layer, a data link layer, and a network layer, and vertically includes a user plane for data information transfer and a control plane for signaling transfer. The protocol layers in FIG. 5A and FIG. 5B can be classified into L1 (first layer), L2 (second layer), and L3 (third layer) based on three lower layers of the open system interconnection (OSI) standard model widely known in the communications systems.
The physical layer as the first layer provides an information transfer service to an upper layer using a physical channel. The physical layer (PHY) is connected to a medium access control (hereinafter, abbreviated as ‘MAC’) layer above the physical layer via a transport channel. Data are transferred between the medium access control layer and the physical layer via the transport channel. The transport channel is divided into a dedicated transport channel and a common transport channel depending on channel sharing. Also, data are transferred between different physical layers, and more particularly, between one physical layer of a transmitting side and the other physical layer of a receiving side via the physical channel. The physical channel of the E-UMTS is modulated in accordance with an orthogonal frequency division multiplexing (OFDM) scheme, and uses time and frequency as radio resources.
The RLC layer of the second layer serves to perform segmentation and concatenation of data received from its upper layer to control a size of the data so that the lower layer transmits the data to a radio period. Also, the RLC layer of the second layer provides three action modes, i.e., a transparent mode (TM), an unacknowledged mode (UM), and an acknowledged mode (AM) to ensure various quality of services (QoS) required by each radio bearer (RB). In particular, the AM RLC layer performs a retransmission function through automatic repeat and request (ARQ) for reliable data transmission.
A radio resource control (hereinafter, abbreviated as ‘RRC’) layer located on a lowest part of the third layer is defined in the control plane only and is associated with configuration, re-configuration and release of radio bearers (hereinafter, abbreviated as ‘RBs’) to be in charge of controlling the logical, transport and physical channels. To this end, the RRC layer allows the user equipment and the network to exchange RRC message with each other. If the RRC layer of the user equipment is RRC connected with the RRC layer of the radio network, the user equipment is in RRC connected mode. If not so, the user equipment is in RRC idle mode.
In this case, the RB means a service or logical path provided by the second layer for the data transfer between the user equipment and the UTRAN. Generally, establishing RB means that features of a radio protocol layer and channel required for a specific service are defined and their detailed parameters and action methods will be established. The RB is divided into a signaling RB (SRB) and a data RB (DRB). The SRB is used as a path for transmitting RRC message in a control plane, and the DRB is used as a path for transmitting user data in a user plane. Referring to FIG. 6A and FIG. 6B, RBs are illustrated at the upper end of a PDCP entity existing in a plurality logical paths allocated to respective users.
Robust header compression (ROHC) which is a representative header compression scheme used in the LTE system is used to reduce header information of real-time packets such as real-time transport protocol (RTP)/user datagram protocol (UDP)/Internet protocol (IP). The RTP/UDP/IP packets mean that headers related to RTP, UDP and IP are fixed to data transferred from the upper layer. A header of the RTP/UDP/IP packets includes various kinds of information required for data to be transferred to a destination through Internet and decompressed there. Generally, the header of the RTP/UDP/IP packets has a size of 40 bytes in case of IPv4 (IP version 4) and 60 bytes in case of IPv6 (IP version 6). If the header of the RTP/UDP/IP packets is compressed using the ROHC, since the header of 40 or 60 bytes is reduced to 1˜3 bytes, it is noted that gain remarkably occurs.
FIG. 9 is a flow chart illustrating an example of a method of repairing an error of a radio bearer in accordance with one embodiment of the present invention. Referring to FIG. 9, if RRC connection is established, the user equipment or the network establishes RB as occasion demands (S910). The RB is established by the third layer, i.e., RRC layer, may be DRB or SRB depending on the user plane or the control plane. The RB may be established initially between the user equipment and the network, or may newly be established in a state that several RBs have already been established. Afterwards, the user equipment or the network identifies whether an error has occurred in the RB established in the step S910 (S920). If the error is not identified, the step S920 continues to be repeated. If it is identified that the error has occurred in the RB established in the step S910, the RB is only re-established or all RBs established between the user equipment and the network are re-established depending on the type of the RB (S930).
Referring to FIG. 10, the user equipment or the network continues to identify whether an error has occurred in the established RB (S1010). The method of identifying that an error has occurred in the RB is not limited especially. For example, whether an error has occurred in the RB can be identified depending on the type of RB as following. In case of SRB, if a predetermined number of packet data are continuously failed in integrity verification of PDCP, the error may be regarded as security failure. Similarly, in case of DRB, if a predetermined number of packet data are continuously failed in header compression of PDCP, the error may be regarded as security failure. The predetermined number of packet data can be designated by the upper layer or the network.
If the security error has occurred in the RB, the user equipment or the network identifies the type of RB where the security error has occurred (S1020). Namely, the user equipment or the network identifies that the RB is SRB or DRB. According to the embodiment of the present invention, the security error is repaired depending on the type of the RB, i.e. SRB and DRB. Namely, the method of repairing the error in case of SRB is different from the method of repairing the error in case of DRB. The methods of repairing the error will be described later in steps S1030 and S1040. The reason why the security error is repaired depending on each of SRB and DRB is that the SRB is more important than the DRB in view of security. In other words, since the SRB is a passage where RRC message which controls the user equipment is exchanged between the user equipment and the network, if an error has occurred in the SRB, RRC connection between the user equipment and the network cannot be relied upon. Accordingly, it is safer in view of security to newly re-establish RRC connection. However, if the security error occurs in the DRB, it would be more efficient to repair the security error of a corresponding RB except for the other RBs in view of service.
If it is identified that the security error has occurred in the SRB, all RBs of the user equipment are re-established (S1030). For example, the user equipment or the network can re-establish all RBs of the user equipment by re-establishing RRC connection. Namely, the user equipment or the network re-establishes RRC connection after releasing the RRC connection. In this case, all RBs of the user equipment are re-established. Also, security parameters are all newly re-established so that they are applied to all RBs.
On the other hand, if it is identified that the security error has occurred in the DRB, security error repair is performed for the specific DRB (S1040). For example, the user equipment or the network can re-establish the DRB only. For another example, the user equipment or the network can repair the security error by synchronizing desynchronized parameter values associated with the security error with each other. Herein, de-synchronization means that the parameter values of the transmitting side and the receiving side become different from each other. Also, synchronization means that that the desynchronized parameter values of the transmitting side and the receiving side become consistent with a specific value.
Examples of the parameter values associated with the security error include, as illustrated in FIG. 1 and FIG. 2, CK (ciphering key), IK (integrity protection key), COUNT (i.e., HFN+PDCP SN), bearer (i.e., RB ID), and Direction. If there is difference in any one of the above parameter values between the transmitting side and the receiving side, the security error occurs. For example, if COUNT (i.e., HFN+PDCP SN) is desynchronized, the user equipment and the network synchronize the desynchronized COUNT (i.e., HFN+PDCP SN). Since the COUNT includes HFN and PDCP SN and the PDCP SN is included in a header of packet data, synchronizing the COUNT means synchronizing HFN.
Referring to FIG. 11, RRC connection is established between the user equipment and the network (S1110). Afterwards, the network identifies that a security error has occurred in the specific DRB (S1120). Whether a security error has occurred in the DRB can be identified by identifying whether a predetermined number of data packets have continuously failed in header compression. Afterwards, the network transmits a first message to the user equipment, wherein the first message indicates that the security error has occurred (S1130). The first message includes at least one of HFN of a transmitting PDCP entity (Tx HFN_EUTRAN) and HFN of a receiving PDCP entity (Rx HFN_EUTRAN) used in the network. The user equipment re-configures a specific DRB where the security error has occurred, with the HFN_EUTRAN after receiving the first message (S1140). Afterwards, the user equipment transmits a second message to the network in response to the first message (S1150).
Referring to FIG. 12, RRC connection is established between the user equipment and the network (S1210). The network identifies that a security error has occurred in the DRB (S1220). Afterwards, the network transmits a first message to the user equipment, wherein the first message indicates that the security error has occurred (S1230). The user equipment re-configures a specific DRB where the security error has occurred, with a specific value HFN_RESET, which is previously determined, after receiving the first message (S1240). The HFN_RESET is equally applied to the user equipment and the network. The HFN_RESET may be indicated by the upper layer of the PDCP layer or the network. Afterwards, the user equipment transmits a second message to the network in response to the first message (S1250). The network which has received the second message determines that the user equipment has re-configured the DRB where the security error has occurred, with the HFN_RESET, and re-configures its DRB where the security error has occurred, with the HFN_RESET (S1260).
Referring to FIG. 13, RRC connection is established between the user equipment and the network (S1310). The network identifies that a security error has occurred in the DRB (S1320). Afterwards, the network transmits a first message to the user equipment, wherein the first message indicates that the security error has occurred (S1330). The user equipment transmits a second message to the network in response to the first message after receiving the first message (S1350). The second message includes at least one of HFN of a transmitting PDCP entity (Tx HFN_UE) and HFN of a receiving PDCP entity (Rx HFN_UE) used in the user equipment. The network which has received the second message re-configures the specific DRB where the security error has occurred, with the HFN_UE included in the second message (S1360).
The steps illustrated in FIG. 11 to FIG. 13 can be performed through PDCP PDU or RRC signaling. Hereinafter, each case will be described in more detail. The user equipment and the network are assumed to function in a same manner as illustrated in FIG. 11 to FIG. 13. However, if the user equipment identifies that the security error has occurred in the specific DRB, the user equipment and the network are functioned in opposite to functions illustrated in FIG. 11 to FIG. 13.
A. Synchronization of HFN Using PDCP Reset Procedure
i. The PDCP layer of the network configures a first PDCP PDU which indicates that a security error has occurred, if it determines that the security error has occurred in the DRB. For convenience, the first PDCP PDU will be referred to as RESET PDU. Afterwards, the network transmits the PDCP RESET PDU to a peer PDCP layer of the user equipment (S1130, S1230, and S1330 in FIG. 11 to FIG. 13). The RESET PDU can include HFN of the transmitting PDCP entity (Tx HFN_EUTRAN) and/or HFN of the receiving PDCP entity (Rx HFN_EUTRAN) of the network (S1130 in FIG. 11).
ii. The PDCP layer of the user equipment, which has received RESET PDU, recognizes that the security error has occurred in a peer PDCP layer of the network. Afterwards, the user equipment can re-configure its HFN (Tx HFN_UE and/or Rx HFN_UE). As illustrated in FIG. 11 to FIG. 13, the user equipment which has received RESET PDU can be operated by the three following cases.
in the case that HFN of the network is included in PDCP RESET PDU:
Case 1. HFN of the PDCP layer is re-configured equally to the network (S1140 in FIG. 11)
in the case that HFN of the network is not included in PDCP RESET PDU:
Case 2. HFN of the PDCP layer is re-configured to a previously determined value (S1240 in FIG. 12)
Case 3. HFN of the PDCP layer is used without change
iii. After performing a required operation in accordance with the above three cases, the user equipment configures a second PDCP PDU in response to the RESET PDU and transmits the second PDCP PDU to the network (S1150, S1250 and S1350 in FIG. 11 to FIG. 13). For convenience, the second PDCP PDU will be referred to as RESET ACK PDU. In case of the Case 3, the RESET ACK PDU includes HFN of the transmitting PDCP entity (Tx HFN_UE) and/or HFN of the receiving PDCP entity (Rx HFN_UE) of the user equipment (S1350 in FIG. 13).
iv. If the network receives the RESET ACK PDU, the network recognizes that the PDCP layer of the user equipment has performed the operation required to repair the security error of the DRB. Afterwards, the operation of the network can be performed by the following three cases.
Case 1. HFN of the PDCP layer is used without change.
Case 2. HFN of the PDCP layer is re-configured to a previously determined value (S1260 in FIG. 12).
Case 3. HFN of the PDCP layer is re-established equally to the user equipment (S1360 in FIG. 13).
i. The PDCP layer of the network notifies the upper layer, i.e., RRC layer that a security error has occurred in the PDCP layer, if it determines that the security error has occurred in the PDCP layer. The RRC layer identifies that the security error relates to what RB, using information of RB establishment. If the type of the RB is SRB, the network starts the procedure of re-establishing RRC connection. If the type of the RB is DRB, the network configures a first RRC message, which indicates that the security error has occurred in the DRB, and transmits the first RRC message to the user equipment (S1130, S1230, and S1330 in FIG. 11 to FIG. 13). For example, the first RRC message may be a message for releasing RRC connection. The first RRC message can include HFN of the transmitting PDCP entity (Tx HFN_EUTRAN) and/or HFN of the receiving PDCP entity (Rx HFN_EUTRAN), where the security error has occurred (S1130 in FIG. 11). If the security error has occurred in several PDCP layer simultaneously, the first RRC message can include information of several RBs (including SRB) where the security error has occurred.
ii. The user equipment, which has received the first RRC message, recognizes that the security error has occurred in the DRB of the network. Afterwards, the user equipment can re-establish DRB indicated by the first RRC message. Also, the user equipment can re-configure HFN (Tx HFN_UE and/or Rx HFN_UE) of the DRB. As illustrated in FIG. 11 to FIG. 13, the user equipment which has received the first RRC message can be operated by the three following cases.
in the case that HFN of the network is included in the first RRC message:
in the case that HFN of the network is not included in the first RRC message:
Case 2. the indicated DRB is re-configured to a previously determined value (S1240 in FIG. 12)
Case 3. the indicated DRB is used without change
iii. After performing a required operation in accordance with the above three cases, the user equipment configures a second RRC message in response to the first RRC message and transmits the second RRC message to the network (S1150, S1250 and S1350 in FIG. 11 to FIG. 13). In case of the Case 3, the second RRC message includes HFN (Tx HFN_UE and/or Rx HFN_UE) of the user equipment.
iv. If the network receives the second RRC message, the network recognizes that the user equipment has performed the operation required to repair the security error of the DRB. Afterwards, the operation of the network can be performed by the following three cases.
Case 1. DRB where the error has occurred is used without re-establishment.
Case 2. DRB where the error has occurred is re-configured to a previously determined HFN (S1260 in FIG. 12).
Case 3. DRB where the error has occurred is re-configured HFN of the user equipment (S1360 in FIG. 13).
As described above, according to the embodiment of the present invention, if the security error has occurred in the PDCP layer of the receiving side, different kinds of solutions are suggested depending on the type of RB, whereby service quality is prevented from being deteriorated unnecessarily.
1. A method of re-establishing one or more radio bearers at a user equipment in a wireless communication system, the method comprising:
establishing one or more data radio bearers and one or more signaling radio bearers;
receiving a message indicating that an error has occurred in a radio bearer; and
re-establishing only the radio bearer only when the radio bearer is a data radio bearer; and
re-establishing all of the one or more data radio bearers and the one or more signaling radio bearers when the radio bearer is a signaling radio bearer,
wherein if the message includes a value for a security-related parameter, one or more corresponding radio bearers are re-established using the received value for the security-related parameter,
wherein if the message does not include any value for the security-related parameter, one or more corresponding radio bearers are re-established using a pre-defined value for the security-related parameter.
3. The method of claim 1, wherein re-establishing the one or more corresponding radio bearers includes synchronizing a desynchronized value for the security-related parameter between the user equipment and a network.
4. The method of claim 1, wherein the security-related parameter includes a hyper frame numbers (HFN).
5. The method of claim 1, wherein the message is a packet data convergence protocol (PDCP) data unit or a radio resource control (RRC) signaling message.
6. The method of claim 4, wherein the HFN includes at least one of a transmitting HFN and a receiving HFN.
7. The method of claim 1, wherein re-establishing all of the one or more data radio bearers and the one or more signaling radio bearers includes re-establishing RRC connection.
US12/739,282 2007-10-29 2008-10-29 Method for repairing an error depending on a radio bearer type Active US8416678B2 (en)
US20100246382A1 US20100246382A1 (en) 2010-09-30
US8416678B2 true US8416678B2 (en) 2013-04-09
US12/739,282 Active US8416678B2 (en) 2007-10-29 2008-10-29 Method for repairing an error depending on a radio bearer type
US20150036593A1 (en) * 2012-03-13 2015-02-05 Ntt Docomo, Inc. Mobile station and radio base station
JP2009520125A (en) 2005-12-15 2009-05-21 ピーター・マーロウ Artificial flowers which the motion is given
US20090203374A1 (en) 2008-01-31 2009-08-13 Lg Electronics Inc. Method for sending status information in mobile telecommunications system and receiver of mobile telecommunications
US20080151830A1 (en) 1999-09-16 2008-06-26 Nokia Corporation Allocation of radio resources from a network in a packet switched data transmission
US20070153788A1 (en) 2001-11-24 2007-07-05 Lg Electronics Inc Method for transmitting packet data in communication system
US20060252445A1 (en) 2003-09-03 2006-11-09 Lg Electronics Inc. Method of controlling transmission power of retransmission packet and mobile terminal using the same
US20100177733A1 (en) 2007-09-11 2010-07-15 Lg Electronics Inc. Method for transmitting status report of pdcp layer in mobile telecommunications system and receiver of mobile telecommunications
3GPP TS 25.321, pp. 2-11.
3GPP TS 36.321, pp. 2-19.
3GPP TS 36.322 V8. 0. 0, Dec. 20, 2007, pp. 11-12, 20-30, URL segment and/or concatenate the RLC SDUs in accordance to the TB size selected by MAC at the particular transmission opportunity notified by MAC.
3GPP TSG RAN WG2 #59bis, pp. 2-24.
3GPP TSG RAN WG2#55, Consideration on UL buffer reporting, Oct. 13, 2006, pp. 1-2.
3GPP TSG-RAN WG1 #47bis, Jan. 2007.
3GPP TSG-RAN WG1 #48bis, pp. 1-4.
3GPP TSG-RAN WG1 #49bis, pp. 1-5.
3GPP TSG-RAN WG2 #59bis, pp. 1-3.
3GPP TSG-RAN WG2 #59bis, pp. 1-5.
3GPP TSG-RAN WG2 Meeting #53, Shanghai, China, Redundant retransmission restraint in RLC-AM, Discussion, Decision, May 8-12, 2006, pp. 1-6.
3GPP TSG-RAN WG2#58bis Meeting, Optimized Buffer Status Reporting, Jun. 25-29, 2007, pp. 1-6.
3GPP TSG-RAN WG2#59.
3GPP TSG-RAN2 Meeting #59, pp. 1-103.
3GPP TSG-RAN2 Meeting #59bis, pp. 1-3.
3GPP TSG-RAN-WG2 Meeting #58bis.
3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Terrestial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) (Release 8), F-06921, XP050377638.
Abeta, S., et al., Super 3G Technology Trends Part 2: Research on Super 3G Technology, NNT DoCoMo Tech Journal, vol. 8 No. 3, pp. 55-62.
Alcatel-Lucent: "PDCP status report carrying LIS only", 3GPP Draft; R2-08902, 3RD Generation Partnership Project (3GPP), Mobile Competence Centre; 650, Route Des Lucioles; F-06921 Sophia-Antipolis Cedex; France, vol. RAN WG2, no, Sorrento, Italy: Feb. 4, 2008, XP050138711.
ASUSTek, "On-line recovery of HFN synchronization due to RLC UM SN problem," 3GPP TSG-RAN WG2 Meeting #44 R2-041940, Oct. 2004. pp. 1-4.
ASUSTek, "Summary of HFN de-synchronization problem off-line email discussion," 3GPP RSG RAN WG2 #46 Tdoc R2-050318, Feb. 2005. pp. 1-4.
CATT: "Notification scheme for system information Change," 3 GPP DRAFT; R2-071870, 3rd. Generation Partnership Project (3GPP), vol. RAN WG2, No. Kobe, Japan; May 4, 2007, XP050134764.
Chinese Office Action (Application No. 200880102631.7), dated Jun. 20, 2012.
Chinese Office Action (Application No. 200880107176.X) dated Apr. 13, 2012, with English translation.
Chinese Office Action (Application No. 200880107676.3), dated Sep. 7, 2012, with English translation.
Chinese Office Action (Application No. 200880107904.7), dated Jul. 30, 2012.
Chinese Office Action (Application No. 2008801163460), dated Jun. 20, 2012.
Chinese Office Action (Application No. 20088017173.6), dated Jul. 3, 2012.
Chinese Office Action (Application No. 200980100119.3), dated Feb. 5, 2013.
Chinese Office Action (Application No. 200980100119.3), dated Jun. 18, 2012.
Chinese Office Action (Application No. 200980109358.5), dated Nov. 26, 2012.
Cohen R Ed, "An improved SSCOP-like scheme for avoiding unnecessary retransmissions and achieving ideal throughput," Proceedings of IEEE INFOCOM. Conference on Computer Communications, Fifteenth Annual Joint Conference of the IEEE Computer and Communications Societies. Networking the Next Generation. San Francisco, Mar. 1996, vol. 2, XP010158150.
Correction to PDCP Status Report, 3GPP-TSG RAN WG2 61bis, R2-081594; Mar. 24, 2008), pp. 1-8, XP002624627.
EP Office Action dated Aug. 31, 2011 from related technology application EP Application No. 08766509.
Ericcson, Basic Principles for the Scheduling Request in LTE, 3gPP TSG RAN WG2 #54, Aug. 28-Sep. 1, 2006, pp. 1-2.
Ericcson, Nokia Cororation, Nokia Siemens Networks, Qualcomm Europe, Samsung, NTT DoCoMo, Inc., Framework for Scheduling Request and Buffer Status Reporting, Nov. 5-9, 2007, pp. 1-4.
Ericsson, Clarification to the handling of large RLC status reports, 3GPP TSG-RAN2 Meeting #61bis R2-082018, Mar. 31, 2008.
Ericsson, Scheduling Request in E-UTRAN, 3GPP Draft, R1-070471, Jan. 10, 2007, pp. 1-11.
European Search Report (Application No. 08011263), dated Dec. 7, 2012.
European Search Report (Application No. 08766423.1), dated Nov. 5, 2012.
European Search Report (Application No. 09722068.5) dated May 24, 2012.
European Search Report (Application No. 11009737) dated Mar. 27, 2012.
Ghosh, A., et al., Random Access Design for UMTS Air-Interface Evolution, IEEE Xplore, Apr. 22-25, 2007, pp. 1041-1045.
GSM: Global System for Mobile Communications, Digital cellular telecommunications system (Phase 2+); Functional stage 2 description of Location Services (LCS) in GERAN (3GPP TS 43.059 version 7.3.0 Release 7), May 2007, pp. 1-70.
Jiang, ASUSTeK Computer Inc., HFN de-synchronization detection with Integrity Protection scheme in a wireless communications. U.S. Appl. No. 60/863,800. *
Korean Office Action (Application No. 10-2009-0022158) dated Apr. 24, 2012, with English translation.
LG Electronics Inc., "Discussion on BCCH Update," 3GPP DRAFT; R2-072736 Mechanism for BCCH Update, 3rd Generation Partnership Project (3GPP), vol. RAN WG2, No. Orlando, USA; Jun. 22, 2007, XP050135517.
LG Electronics Inc., NTT DoCoMo, ACK-SN setting for short Status PDU, 3GPP TSG-RAN WG2 #62 R2-082133, May 5, 2008.
LG Electronics Inc., NTT DoCoMo, ACK—SN setting for short Status PDU, 3GPP TSG-RAN WG2 #62 R2-082133, May 5, 2008.
LG Electronics Inc., UE state transition in LTE-ACTIVE, 3GPP Draft, R2-061002, Mar. 23, 2006, pp. 1-3.
LG Electronics Inc., UE state transition in LTE—ACTIVE, 3GPP Draft, R2-061002, Mar. 23, 2006, pp. 1-3.
LG Electronics Inc.: "Correction of status reporting coding", 3GPP TSG RAN WG2 61, R2-0809, Feb. 5, 2008, pp. 1-3, XP 002634626.
LG Electronics Inc: Correction to Polling Procedure, 3GPP Draft; R2-081588 Correction to Polling Procedure, 3rd Generation Partnership Project (3GPP) XP050139320, Mar. 24, 2008.
LG Electronics, Delivery of LTE System Information, 3GPP TSG-RAN WG2 Ad Hoc Meeting on LTE, Jun. 27-30, 2006, pp. 1-4.
LG Electronics, Update of eUtran PCDP specification, R2-081390, 3GPP Feb. 22, 2008.
Meeting #61bis R2-081700, Mar. 31, 2008, URL, R2-081700.
Motorola, Concentration-free Intra-LTE Handover, 3GPP Draft, R2-070730, Feb. 9, 2007, pp. 1-3.
Motorola, Synchronized Random Access Channel and Scheduling Request, 3GPP TSG RAN1#47, Nov. 6-10, 2006, pp. 1-3.
Nokia, System Information Distribution, 3GPP TSG-RAN WG2 Ad Hoc Meeting on LTE, Jun. 27-30, 2006, pp. 1-3.
Notice of Allowance—Issued for U.S. Appl. No. 13/107,232 on Jan. 30, 2013 by the United States Patent and Trademark Office.
NTT DoCoMo et al.: "Uplink synchronization maintenance," 3GPP Draft; R2-072014. 3rd Generation Partnership Project (3GPP), Mobile Competence Centre: May 4, 2007, XP050134889.
NTT DoCoMo, Funitsu, Mitsubishi Electric, NED, Sharp, Toshiba Corporation, Scheduling Request Transmission Method for E-UTRA Uplink, 3gPP TSG RAN WG1 Meeting #47, Nov. 6-10, 2006, pp. 1-6.
NTT DoCoMo, Inc. "BUFFER Status Report and Scheduling Request triggers," 3GPP TSG-RAN WG2 #59, R2-073574, Aug. 20-24, 2007, entire document.
Office Action dated Jul. 13, 2011, for U.S. Appl. No. 12/363,007.
Office Action dated Jul. 14, 2011, for U.S. Appl. No. 12/143,607.
Office Action dated Nov. 16, 2010 in related U.S. Appl. No. 12/733,179.
Russian Office Action dated Dec. 2, 2011, with English translation.
Taiwan Office Action dated Feb. 17, 2012.
Taiwan Office Action dated Oct. 28, 2011 (Application No. 097123135 with translation).
Texas Instruments, UL Synchronization Management and Maintenance in E-UTRA, Draft, R1-072198, May 1, 2007, pp. 1-7.
Texas Instruments, UL Synchronization Management in LTE-ACTIVE, R1-071478, Mar. 21, 2007, pp. 1-4.
Texas Instruments, UL Synchronization Management in LTE—ACTIVE, R1-071478, Mar. 21, 2007, pp. 1-4.
TSG-RAN WG2 Meeting #60.
U.S. Appl. No. 12/406,677, Notice of Allowance dated Mar. 4, 2011.
U.S. Appl. No. 12/733,179, Office Action dated Mar. 4, 2011.
U.S. Appl. No. 60/944,662, dated Jun. 18, 2007, inventor Tsyoshi Kashima.
U.S. Appl. No. 60/976,139, Wang, et al.
U.S. Appl. No. 61/006,348 dated Jan. 8, 2008, inventors Li-Cheng Lin et al.
U.S. Appl. No. 61/019,058, Sammour et al.
U.S. Final Office Action (U.S. Appl. No. 12/672,835), dated Aug. 30, 2012.
U.S. Notice of Allowance (U.S. Appl. No. 13/150,892), dated Aug. 24, 2012.
U.S. Office Action (U.S. Appl. No. 12/451,795) dated Apr. 2, 2012.
U.S. Office Action (U.S. Appl. No. 12/452,733) dated Jun. 11, 2012.
U.S. Office Action (U.S. Appl. No. 12/452,905), dated Dec. 3, 2012.
U.S. Office Action (U.S. Appl. No. 12/602,763) dated May 11, 2012.
U.S. Office Action (U.S. Appl. No. 12/668,199), dated Aug. 24, 2012.
U.S. Office Action (U.S. Appl. No. 12/671,020) dated Apr. 18, 2012.
U.S. Office Action (U.S. Appl. No. 12/671,020), dated Feb. 14, 2013.
U.S. Office Action (U.S. Appl. No. 12/671,020), dated Oct. 3, 2012.
U.S. Office Action (U.S. Appl. No. 12/672,835) dated Apr. 5, 2012.
U.S. Office Action (U.S. Appl. No. 12/672,999) dated Dec. 29, 2011.
U.S. Office Action (U.S. Appl. No. 12/672,999) dated May 1, 2012.
U.S. Office Action (U.S. Appl. No. 12/677,945), dated Aug. 14, 2012.
U.S. Office Action (U.S. Appl. No. 12/682,841) dated Jun. 13, 2012.
U.S. Office Action (U.S. Appl. No. 12/699,022) dated Jan. 12, 2012.
U.S. Office Action (U.S. Appl. No. 12/733,179), dated Oct. 31, 2012.
U.S. Office Action (U.S. Appl. No. 12/738,625), dated Oct. 24, 2012.
U.S. Office Action (U.S. Appl. No. 12/933,538), dated Nov. 23, 2012.
U.S. Office Action dated Feb. 23, 2012, for U.S. Appl. No. 12/682,841.
U.S. Office Action dated Feb. 24, 2012, for U.S. Appl. No. 12/665,324.
U.S. Office Action dated Feb. 3, 2012, for U.S. Appl. No. 12/363,007.
U.S. Office Action dated Mar. 1, 2012, for U.S. Appl. No. 12/667,860.
U.S. Office Action dated Nov. 14, 2011 (U.S. Appl. No. 12/452,793).
U.S. Office Action dated Nov. 29, 2011 (U.S. Appl. No. 12/678,487).
U.S. Office Action dated Nov. 4, 2011 (U.S. Appl. No. 12/234,574).
U.S. Office Action dated Nov. 9, 2011 (U.S. Appl. No. 12/452,733).
U.S. Office Action dated Oct. 28, 2011 (U.S. Appl. No. 12/452,495).
U.S. Office Action for U.S. Appl. No. 12/452,733 dated Jan. 8, 2013.
UALCOMM Europe, Further Details on RACH Procedure, 3GPP TSG-RAN WG1 #48, R1-070649, Jan. 12-16, 2007, entire document.
United Kingdom Office Action dated Feb. 21, 2012, for Application No. GB1002893.4.
Universal Mobile Telecommunications System (UMTS); Radio Link Control (RLC) protocol specification (3GPP TS 25.322 version 4.10.0 Release 4); ETSI TS 125 322, XP014016803, Sep. 1, 2003.
US Office Action (U.S. Appl. No. 12/673,741), dated Jul. 19, 2012.
US Office Action dated Sep. 14, 2011 from related technology application U.S. Appl. No. 12/452,183.
US Office Action dated Sep. 14, 2011 from related technology application U.S. Appl. No. 12/452,464.
US Office Action dated Sep. 28, 2011 from related technology U.S. Appl. No. 12/452,592.
US Office Action dated Sep. 29, 2011 from related technology U.S. Appl. No. 12/673,004.
US8848583B2 (en) * 2009-04-20 2014-09-30 Huawei Technologies Co., Ltd. Communication method and apparatus for header compression
US9485005B2 (en) * 2012-03-13 2016-11-01 Ntt Docomo, Inc. Mobile station and radio base station
CN103458402B (en) 2017-04-12 Evolved Universal Terrestrial Radio Access Network and communication method and user equipment
US20100118889A1 (en) 2010-05-13 Method of transmitting data in a wireless communication system
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:YI, SEUNG JUNE;LEE, YOUNG DAE;CHUN, SUNG DUCK;AND OTHERS;SIGNING DATES FROM 20100319 TO 20100325;REEL/FRAME:024274/0246