IP Library Granted Patent US 7,978,616
Granted Patent B2
US 7,978,616 · App. 12/405,677 · Granted Jul 12, 2011

Method for transmitting PDCP status report

Assignee: LG Electronics Inc.
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 7,978,616
App. No.
12/405,677
Granted
Jul 12, 2011
Kind
B2
Abstract

A method of transmitting PDCP (Packet Data Convergence Protocol) status reports, is performed by a mobile terminal by receiving, from an upper layer, a request for PDCP (Packet Data Convergence Protocol) re-establishment; detecting whether there are any out-of-sequence PDCP SDUs (service data units) stored; and if there is at least one out-of-sequence PDCP SDU stored, allocating a bitmap field of length in bits equal to the number of PDCP SNs from and not including the first out-of-sequence PDCP SDU up to and including a last out-of-sequence PDCP SDU.

Claims (47)

1. A method of handling PDCP (Packet Data Convergence Protocol) status reports, the method comprising:

receiving, from an upper layer, a request for PDCP re-establishment;

detecting whether there are any out-of-sequence PDCP SDUs (service data units) stored;

if there is at least one out-of-sequence PDCP SDU stored, allocating a bitmap field to have a length based on PDCP sequence numbers (SNs) from and not including a first out-of-sequence PDCP SDU up to and including a last out-of-sequence PDCP SDU; and

if a last PDCP SDU is a first missing PDCP SDU, allocating the bitmap field to have the length of 0.

2. The method of claim 1 , wherein if there is no out-of-sequence PDCP SDU stored, the step of allocating the bitmap field is not performed.

3. The method of claim 1 , wherein the PDCP SDUs are stored in a buffer.

4. The method of claim 1 , wherein the steps are performed for a RLC (Radio Link Control) AM (Acknowledged Mode).

5. The method of claim 1 , wherein the PDCP re-establishment occurs for HO (handover) situations.

6. The method of claim 1 , wherein the PDCP status report includes an FMS (First Missing Sequence number) field.

7. The method of claim 6 , further comprising:

setting the FMS field to the PDCP SN of the first missing PDCP SDU.

8. The method of claim 7 , wherein a value of a particular bit in the bitmap field is 0 means that a PDCP SDU having a sequence number that equals a position N of the particular bit plus a value of the FMS field was unsuccessfully received, and

wherein the position N is an integer starting from 1.

9. The method of claim 1 , wherein the bitmap field having a value of 1 indicates that a corresponding PDCP SDU was successfully received.

10. The method of claim 1 , wherein the bitmap field having a value of 0 indicates that a corresponding PDCP SDU was unsuccessfully received.

11. The method of claim 1 , wherein a value of a particular bit in the bitmap field is 1 means that a PDCP SDU having a sequence number that equals a position N of the particular bit plus a value of the FMS (First Missing Sequence number) field was successfully received, and

wherein the position N is an integer starting from 1.

12. A method of processing a PDCP (Packet Data Convergence Protocol) status report, the method comprising:

receiving, from an upper layer, a request for PDCP re-establishment;

generating a PDCP status report by setting an FMS (First Missing Sequence number) field, wherein the FMS field is set to the PDCP sequence number of the first missing PDCP SDU (Service Data Unit); and

if there are out-of-sequence PDCP SDUs stored, allocating a bitmap field having a length depending on the PDCP sequence numbers related to the first missing PDCP SDU through the last out-of-sequence PDCP SDUs; and

if a last PDCP SDU is a first missing PDCP SDU, allocating the bitmap field a length of 0.

13. The method of claim 12 , wherein a bitmap is generated for the bitmap field based on the PDCP sequence numbers from and not including the first missing PDCP SDU up to and including the last out-of-sequence PDCP SDUs, rounded up to an octet.

14. The method of claim 12 , wherein a bitmap is not generated for the bitmap field if the bitmap field is allocated the length of 0.

15. The method of claim 12 , wherein each bit in the bitmap indicates whether or not at least one of reception and decompression of a corresponding PDCP SDU is correct.

16. The method of claim 12 , wherein the allocating of the bitmap field results in a variable length for the bitmap field.

17. The method of claim 12 , wherein the PDCP status report is further generated by filling the bitmap field with zeros (0) and ones (1), with a 0 bit indicating that a corresponding PDCP SDU was successfully received and a 1 bit indicating that a corresponding PDCP SDU was unsuccessfully received.

18. A method of generating a PDCP (Packet Data Convergence Protocol) status report, the method comprising:

receiving, from an upper layer, a request for PDCP re-establishment; and

compiling a PDCP status report by,

setting an FMS (First Missing Sequence number) field to the PDCP sequence number of the first missing PDCP SDU (Service Data Unit), and

allocating a bitmap field with a length of 0, if a last PDCP SDU is a first missing PDCP SDU, and otherwise, allocating the bitmap field with a particular length that is based on PDCP sequence numbers from and not including the first missing PDCP SDU up to and including the last out-of-sequence PDCP SDUs, rounded up to the next multiple of 8.

19. The method of claim 18 , further comprising, prior to the compiling step, processing PDCP data PDUs received from the lower layer due to the re-establishment of the lower layers as a result of the request for PDCP re-establishment.

20. The method of claim 18 , wherein each bit in the bitmap indicates whether or not at least one of reception and decompression of a corresponding PDCP SDU is correct.

21. The method of claim 18 , wherein the PDCP status report is further complied by filling the bitmap field with zeros (0) and ones (1), with a 0 bit indicating that a corresponding PDCP SDU was successfully received and a 1 bit indicating that a corresponding PDCP SDU was unsuccessfully received.

22. A method of processing a PDCP (Packet Data Convergence Protocol) status report, the method comprising:

receiving, from an upper layer, a request for PDCP re-establishment;

generating a PDCP status report by,

setting an FMS (First Missing Sequence number) field to the PDCP sequence number of the first missing PDCP SDU (Service Data Unit), and

allocating a bitmap field with a length of 0, if a last PDCP SDU is a first missing PDCP SDU, or allocating the bitmap field with a particular length such that the particular length of the bitmap field is based on PDCP sequence numbers from and not including the first missing PDCP SDU up to and including the last out-of-sequence PDCP SDUs, rounded up to the next multiple of 8,

wherein the PDCP status report is further generated by filling the bitmap field with zeros (0) and ones (1), with a 0 bit indicating that a corresponding PDCP SDU was successfully received and a 1 bit indicating that a corresponding PDCP SDU was unsuccessfully received; and

transmitting, via a lower layer, the generated PDCP status report.

23. The method of claim 22 , wherein the steps are performed for a RLC (Radio Link Control) AM (Acknowledged Mode).

24. The method of claim 22 , wherein the PDCP re-establishment occurs for HO (handover) situations.

25. The method of claim 22 , wherein the PDCP status report is a PDCP Control PDU with a format including a D/C (Data/Control) field of 1 bit, followed by a PDU Type field of 3 bits, followed by the FMS field of 12 bits, and optionally followed by the bitmap field of 8 bits or a multiple thereof, and

wherein the bitmap field is selectively included based on the allocating step.

Assignments (4)
CORRECTIVE ASSIGNMENT TO CORRECT THE EXECUTION DATE AND ASSIGNMENT DOCUMENTATION PREVIOUSLY RECORDED AT REEL: 041016 FRAME: 0505. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Recorded Feb 9, 2017
From: THOMSON LICENSING, SAS; THOMSON LICENSING; THOMSON LICENSING S.A.; THOMSON LICENSING SA; THOMSON LICENSING S.A.S.
To: DOLBY LABORATORIES LICENSING CORPORATION
Reel/Frame 041752/0398 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jan 19, 2017
From: THOMSON LICENSING, SAS; THOMSON LICENSING; THOMSON LICENSING S.A.; THOMSON LICENSING SA; THOMSON LICENSING, S.A.S.
To: DOLBY LABORATORIES LICENSING CORPORATION
Reel/Frame 041016/0505 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jan 7, 2015
From: LG ELECTRONICS, INC.
To: THOMSON LICENSING SAS
Reel/Frame 034740/0868 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jun 5, 2009
From: CHUN, SUNG-DUCK; YI, SEUNG-JUNE; PARK, SUNG-JUN; LEE, YOUNG-DAE
To: LG ELECTRONICS INC.
Reel/Frame 022788/0472 →
Priority Claims (1)
KR 10-2009-0022158 · Mar 16, 2009 · national
Continuity (3)
Provisional Application 61037309 · Mar 17, 2008
Provisional Application 61038470 · Mar 21, 2008
Related Publication 20090238142A1 · Sep 24, 2009