Đi sâu Layer 2 của LTE và 5G NR cho người mới: PDCP, RLC (TM/UM/AM) và cấu trúc MAC PDU

Dành cho ai? Người đã đọc bài tổng quan Radio Protocol Stack 5G NR cho người mới (hoặc đã biết sơ về các lớp PDCP/RLC/MAC) và muốn hiểu bên trong từng lớp đến mức đọc được header và capture. Sau bài này bạn sẽ: vẽ được cấu trúc PDU của PDCP, RLC, MAC; giải thích được RLC TM/UM/AM khác nhau thế nào; hiểu tại sao có cả ARQ lẫn HARQ; và tự tính được một gói IP 1000 byte biến thành bao nhiêu byte trên Transport Block. Bài viết nói về cả LTE lẫn 5G NR, đặt cạnh nhau ở những chỗ khác biệt.

1. Layer 2 là gì và dữ liệu “lồng” nhau thế nào?

Layer 2 (L2) của giao diện vô tuyến gồm ba lớp: PDCP → RLC → MAC (5G NR thêm SDAP phía trên PDCP ở user plane). Mỗi lớp nhận SDU từ lớp trên, thêm header của mình để thành PDU, rồi giao xuống lớp dưới. PDU của lớp trên chính là SDU của lớp dưới — giống búp bê Matryoshka:

IP packet (1000 B)
 └─ [SDAP hdr][ IP packet ]                      ← SDAP PDU  (chỉ NR, 1 B header)
     └─ [PDCP hdr][ SDAP PDU ]                   ← PDCP PDU  = RLC SDU
         └─ [RLC hdr][ PDCP PDU ]                ← RLC PDU   = MAC SDU
             └─ [MAC subhdr][ RLC PDU ] ...      ← MAC subPDU, nhiều subPDU = 1 MAC PDU = Transport Block
                 └─ PHY: + CRC, mã hóa kênh, điều chế → sóng vô tuyến

Ví dụ xuyên suốt của bài: UE gửi 1 gói IP 1000 byte lên mạng trên một DRB (uplink, 5G NR, RLC AM 12-bit SN, không bật integrity cho DRB). Cuối bài ta sẽ cộng từng header.

Chia việc của L2 theo một câu: PDCP lo “an toàn và đánh số”, RLC lo “chia kiện và đảm bảo đến nơi”, MAC lo “ai được đi khi nào và gói gọn vào chuyến”.

2. PDCP — Packet Data Convergence Protocol

(LTE: TS 36.323; NR: TS 38.323)

2.1 PDCP làm gì?

Vì sao cần nén header? Một gói thoại VoLTE/VoNR có payload chỉ khoảng 30–40 byte nhưng header IPv4 + UDP + RTP đã là 20 + 8 + 12 = 40 byte (IPv6 là 60 byte). ROHC (Robust Header Compression) nén phần header lặp lại xuống còn 1–3 byte — tiết kiệm gần một nửa băng thông cho dịch vụ thoại.

2.2 Cấu trúc PDCP PDU

PDCP Data PDU — DRB, SN 12 bit (NR và LTE):

Bit:   7   6   5   4   3   2   1   0
     ┌───┬───┬───┬───┬───┬───┬───┬───┐
 B1  │D/C│ R │ R │ R │   SN (cao, 4 bit) │
     ├───┴───┴───┴───┴───┴───┴───┴───┤
 B2  │         SN (thấp, 8 bit)       │
     ├───────────────────────────────┤
 B3… │   Data  (PDCP SDU, đã mã hóa)  │
     ├───────────────────────────────┤
     │ MAC-I (4 B, chỉ khi bật integrity) │
     └───────────────────────────────┘

• D/C: 1 = Data PDU, 0 = Control PDU.
• SN 12 bit → header 2 byte. SN 18 bit (NR; LTE từ bản phát hành sau) → header 3 byte (D/C + 5 bit R + 2 bit SN cao, rồi 2 byte SN).
• SRB (NR): 4 bit R + 4 bit SN cao | 8 bit SN thấp rồi Data rồi MAC-I 4 byte (luôn có). (MAC-I ở đây là Message Authentication Code for Integrity của PDCP — không liên quan MAC layer.)
• LTE SRB dùng SN 5 bit (header 1 byte); LTE DRB dùng SN 7 hoặc 12 bit.

PDCP Control PDU (D/C = 0): có trường PDU type 3 bit — 000 = PDCP status report (báo gói nào đã nhận: FMC First Missing COUNT + bitmap), 001 = ROHC feedback.

2.3 SN, HFN và COUNT — vì sao mã hóa không bị lặp?

SN chỉ 12 hoặc 18 bit nên sẽ quay vòng (wrap-around) sau 4096 hoặc 262144 gói. Để mã hóa không lặp, PDCP dùng bộ đếm 32 bit:

COUNT (32 bit) = HFN (phần cao, Hyper Frame Number) ‖ SN (phần thấp, đi theo header)

Chỉ SN được truyền trên không; HFN hai đầu tự đếm riêng (mỗi lần SN quay vòng thì HFN tăng 1). Mã hóa thực hiện như sau:

keystream = NEA( key, COUNT, BEARER, DIRECTION, LENGTH )
ciphertext = plaintext  XOR  keystream

• key: khóa mã hóa AS (K_UPenc cho DRB, K_RRCenc cho SRB, dẫn xuất từ khóa của lõi).
• BEARER: số nhận dạng bearer; DIRECTION: 0 = UL, 1 = DL → hai chiều dùng keystream khác nhau.
• Thuật toán: NEA1 = SNOW 3G, NEA2 = AES-CTR, NEA3 = ZUC, NEA0 = không mã hóa (LTE tương ứng EEA0–EEA3).
• Toàn vẹn tính MAC-I 32 bit bằng NIA1/2/3 (SNOW 3G / AES-CMAC / ZUC) trên header + data với cùng kiểu đầu vào (key, COUNT, BEARER, DIRECTION).
• Vì COUNT tăng đơn điệu nên gói phát lại (replay) bị phát hiện, và không bao giờ dùng cùng keystream hai lần với cùng khóa.

⚠ Nếu hai đầu lệch HFN (ví dụ do mất đồng bộ khi handover lỗi), mọi gói sau đó giải mã ra rác và RRC/NAS fail. Đây là lỗi thường gặp khi tự viết stack hoặc dựng lab.

2.4 Sắp xếp lại và loại trùng (reordering)

Phía nhận giữ các biến trạng thái (tên trong TS 38.323):

• RX_NEXT: COUNT của gói kế tiếp dự kiến nhận.
• RX_DELIV: COUNT của gói đầu tiên chưa giao cho lớp trên (đang chờ).
• RX_REORD: mốc dùng với timer.

Quy tắc dễ hiểu: gói nào đến đúng thứ tự thì giao ngay; gói đến sớm (có “lỗ” phía trước) thì giữ lại và bật timer t-Reordering; hết timer mà lỗ vẫn chưa được lấp thì bỏ qua lỗ và giao tiếp những gói đang giữ. Gói có COUNT đã giao rồi (hoặc nhỏ hơn RX_DELIV) bị loại — đó là cách loại trùng.

Với RLC AM, PDCP chỉ phải sắp xếp lại trong những tình huống đặc biệt (handover, dual connectivity, re-establishment) vì RLC đã giao tuần tự — trừ NR, nơi RLC không còn sắp xếp lại nên PDCP gánh toàn bộ.

2.5 Những cơ chế “nâng cao”

• discardTimer: gói nằm trong bộ đệm PDCP phát quá lâu (hết hạn trễ) thì bỏ — vô nghĩa khi gửi thoại đã trễ 300 ms.
• PDCP re-establishment (khi handover, hoặc RLF phục hồi): đặt lại ROHC, áp khóa mới, gửi lại những PDCP PDU chưa được RLC xác nhận (nếu DRB dùng AM) — nhờ vậy handover không mất dữ liệu (lossless handover).
• Status report: sau handover, bên nhận gửi PDCP status report để bên gửi biết chính xác gói nào đã đến, tránh gửi lại thừa.
• PDCP duplication (NR; LTE-A cho một số trường hợp): cùng một gói gửi qua hai đường (hai RLC entity/hai carrier), bên nhận loại trùng — tăng độ tin cậy cho URLLC.
• Split bearer (dual connectivity): một DRB đi qua hai trạm (master/secondary); PDCP là nơi “chia” và “gộp” luồng, nên reordering càng quan trọng.

3. RLC — Radio Link Control

(LTE: TS 36.322; NR: TS 38.322)

3.1 Ba chế độ

TM thực chất là “đường thông qua”: RLC không làm gì cả, SDU vào thế nào PDU ra thế ấy. UM là “gửi và hy vọng” nhưng vẫn phân mảnh/ghép lại được. AM là chế độ đầy đủ nhất.

Theo dõi một DRB cụ thể bằng cấu hình rlc-Config trong RRC: um-Bi-Directional hoặc am kèm độ dài SN và các timer.

3.2 Phân mảnh (segmentation) — cốt lõi của RLC

Kích thước gói IP và kích thước tài nguyên MAC cấp phát hiếm khi khớp nhau. RLC cắt SDU thành các mảnh vừa với grant hiện tại. Mỗi PDU của NR có trường SI (Segmentation Info) 2 bit:

Mảnh không phải mảnh đầu (SI = 10 hoặc 11) có thêm trường SO (Segment Offset, 16 bit) cho biết mảnh này bắt đầu ở byte thứ mấy của SDU gốc, để bên nhận ghép lại đúng chỗ.

LTE dùng trường FI (Framing Info) và LI (Length Indicator) khác chút, vì RLC LTE còn ghép (concatenate) nhiều SDU vào một PDU. NR bỏ ghép nên đơn giản hơn: một RLC PDU chứa tối đa một SDU (hoặc một mảnh của nó).

3.3 RLC TM

Không header, không SN. Chỉ cần nhớ: SRB0 (RRCSetupRequest/RRCSetup, kênh CCCH), paging, system information đều đi qua RLC TM.

3.4 RLC UM — header

NR (TS 38.322):

UM, SN 6 bit, SDU nguyên vẹn (SI=00):         | SI(2) | R(6) |                      → 1 byte, không có SN
UM, SN 6 bit, có phân mảnh (SI≠00):           | SI(2) | SN(6) |  [SO 16 bit nếu SI=10/11]
UM, SN 12 bit, có phân mảnh:                  | SI(2) | R(2) | SN[11:8](4) | SN[7:0](8) | [SO 16 bit]

Bên nhận UM dùng timer t-Reassembly: chờ các mảnh còn thiếu; hết timer thì bỏ SDU dang dở (không xin gửi lại).

3.5 RLC AM — header

NR AM, SN 12 bit (AMD PDU):
Bit:  7    6    5 4   3 2 1 0
    ┌────┬────┬─────┬──────────┐
 B1 │D/C │ P  │ SI  │ SN[11:8] │
    ├────┴────┴─────┴──────────┤
 B2 │       SN[7:0]            │
    ├──────────────────────────┤
 B3…│ [SO 16 bit, nếu SI=10/11] │
    │        Data               │
    └──────────────────────────┘
NR AM, SN 18 bit: D/C P SI R R SN[17:16] | SN[15:8] | SN[7:0]  → header 3 byte

• D/C: 1 = Data PDU, 0 = Control PDU (Status PDU).
• P (Poll): bên gửi “hỏi” bên nhận: hãy gửi status report cho tôi.
• LTE AM: D/C | RF | P | FI(2) | E | SN(10) → header cố định 2 byte, cộng thêm các LI nếu ghép nhiều SDU.

3.6 ARQ của RLC AM hoạt động thế nào?

Ý tưởng: bên gửi giữ lại mọi AMD PDU đã gửi cho đến khi được xác nhận; bên nhận báo cho bên gửi biết mình đã nhận gì, thiếu gì.

Bên nhận → Status PDU (control PDU, D/C = 0, CPT = 000):

• ACK_SN: “mọi SN nhỏ hơn ACK_SN tôi đã nhận đủ, trừ những SN liệt kê trong NACK”.
• NACK_SN: các SN bị thiếu (kèm SOstart/SOend nếu chỉ thiếu một đoạn của SDU).

Khi nào bên gửi đặt bit P (poll)? (tham số RRC)

• Đã gửi pollPDU PDU hoặc pollByte byte kể từ lần poll trước;
• PDU này là PDU cuối cùng trong bộ đệm (không còn gì để gửi);
• Timer t-PollRetransmit hết hạn mà chưa nhận được status.

Khi nào bên nhận gửi Status PDU?

• Nhận PDU có bit P = 1;
• Phát hiện “lỗ” quá lâu (t-Reassembly hết hạn) — kết luận PDU đó đã mất;
• Luôn bị t-StatusProhibit chặn: không gửi status quá dày.

Ví dụ: gửi SN 10, 11, 12, 13 (13 có P=1). SN 12 bị mất. Bên nhận đáp Status PDU: ACK_SN = 14, NACK_SN = 12. Bên gửi gửi lại SN 12 (có thể phân mảnh lại nếu grant nhỏ hơn — re-segmentation), xóa 10, 11, 13 khỏi bộ đệm.

Khi AM “hết cách”: nếu một PDU đã gửi lại quá maxRetxThreshold lần mà vẫn không được xác nhận, RLC báo lên RRC → coi là Radio Link Failure (RLF) → UE chạy RRC re-establishment. Đây là lý do một đường truyền xấu kéo dài làm cuộc gọi/kết nối bị rớt.

Cửa sổ truyền (window): bên gửi không được gửi quá một “cửa sổ” SN (một nửa không gian SN) so với PDU cũ nhất chưa xác nhận — tránh nhầm SN khi quay vòng.

3.6b Các tham số RLC AM bạn sẽ thấy trong RRC

3.7 So sánh RLC LTE và NR

4. MAC — Medium Access Control

(LTE: TS 36.321; NR: TS 38.321)

4.1 MAC làm gì?

1. Ánh xạ kênh logic ↔ kênh truyền tải.
2. Ghép/tách (multiplexing/demultiplexing) SDU của nhiều kênh logic thành một MAC PDU = Transport Block (TB).
3. Lập lịch & báo cáo lập lịch: SR, BSR, PHR.
4. HARQ.
5. Random Access.
6. Điều khiển: DRX, Timing Advance, kích hoạt SCell, ưu tiên kênh logic (LCP).

4.2 Cấu trúc MAC PDU của NR

MAC PDU = chuỗi các MAC subPDU liên tiếp. Mỗi subPDU gồm subheader + payload (payload là MAC SDU, MAC CE, hoặc padding). Điểm quan trọng nhất: subheader nằm ngay trước payload của nó (interleaved).

MAC PDU (NR)
┌──────────┬───────────┬──────────┬───────────┬──────────┬─────────┐
│ subhdr 1 │ payload 1 │ subhdr 2 │ payload 2 │   ...    │ padding │
└──────────┴───────────┴──────────┴───────────┴──────────┴─────────┘
  └──────── subPDU 1 ────────┘└──────── subPDU 2 ────────┘

Ba dạng subheader (NR):

(a) R/F/LCID/L, L = 8 bit  (payload ≤ 255 B)  → 2 byte:
    | R | F=0 | LCID (6 bit) |   L (8 bit)   |

(b) R/F/LCID/L, L = 16 bit (payload > 255 B)  → 3 byte:
    | R | F=1 | LCID (6 bit) |      L (16 bit)      |

(c) R/LCID  (MAC CE kích thước cố định, padding)  → 1 byte, KHÔNG có L:
    | R | R | LCID (6 bit) |

• LCID (6 bit): cho biết payload là SDU của kênh logic nào (giá trị 1–32), hay là MAC CE nào, hay là padding.
• F (Format): 0 = trường L dài 8 bit, 1 = dài 16 bit.
• L: độ dài payload tính bằng byte.
• Trong downlink, MAC CE thường đặt trước các SDU; trong uplink, MAC CE thường đặt sau SDU (trước padding).

Một số LCID đáng nhớ (NR):

(Chỉ liệt kê các giá trị chính; danh sách đầy đủ ở TS 38.321 mục 6.2.1. Ví dụ UL còn có LCID 57 = Single Entry PHR.)

Một số MAC CE quan trọng:

• Short BSR (1 byte): LCG ID (3 bit) + Buffer Size (5 bit) — báo bộ đệm của một nhóm kênh logic (LCG, Logical Channel Group). Long BSR: bitmap LCG + buffer size cho nhiều LCG (NR có 8 LCG).
• C-RNTI MAC CE (2 byte): UE khai báo C-RNTI của mình, dùng trong random access/recovery.
• UE Contention Resolution Identity (6 byte, DL): gNB lặp lại 48 bit đầu của CCCH SDU mà UE gửi ở Msg3; UE so khớp để biết mình (chứ không phải UE khác) thắng tranh chấp. Đây chính là cách RRCSetupRequest (Msg3) và RRCSetup (Msg4) gắn với nhau ở tầng MAC.
• Timing Advance Command: gNB bảo UE phát sớm hơn bao nhiêu để sóng đến đúng khe thời gian.

4.3 MAC PDU của LTE để so sánh

MAC PDU (LTE)
┌─────────────────────────────┬────────────┬──────────────────┬─────────┐
│  MAC header                 │ MAC CEs    │   MAC SDUs       │ padding │
│  [subhdr1][subhdr2]...[subhdrN]          │                  │         │
└─────────────────────────────┴────────────┴──────────────────┴─────────┘

• Tất cả subheader dồn lên đầu PDU, rồi mới đến MAC CE và SDU.
• Subheader LTE: R R E LCID (1 byte) + F L (nếu cần). Bit E (Extension) báo “phía sau còn subheader nữa”. Subheader cuối chỉ có R R E LCID.
• LCID 5 bit.

Vì sao NR đổi? Với kiểu LTE, muốn dựng MAC PDU phải biết toàn bộ các SDU để viết header ở đầu. Với kiểu NR, từng subPDU độc lập → có thể bắt đầu xử lý/dựng từng phần ngay (ví dụ chuẩn bị RLC PDU, MAC subPDU trước khi nhận grant), phù hợp yêu cầu trễ thấp.

4.4 Quy trình lập lịch uplink — “xin xe rồi báo hàng”

 UE                                   gNB
  │  (có dữ liệu mới, chưa có grant)   │
  │── SR (PUCCH) ─────────────────────►│  "Tôi có dữ liệu cần gửi"
  │◄───────────── UL grant (DCI) ──────│  cấp tài nguyên nhỏ
  │── BSR (MAC CE) + một ít dữ liệu ──►│  "Tôi còn N byte, thuộc LCG k"
  │◄───────────── UL grant (DCI) ──────│  cấp đủ theo BSR
  │── Dữ liệu (MAC PDU) ──────────────►│

• SR (Scheduling Request): bit báo hiệu trên PUCCH. Nếu chưa có PUCCH cấu hình thì UE dùng random access.
• BSR: MAC CE nằm trong MAC PDU, báo lượng dữ liệu đang chờ.
• LCP (Logical Channel Prioritization): khi grant đến, UE điền Transport Block theo ưu tiên của từng kênh logic, có PBR (Prioritised Bit Rate) bảo đảm tối thiểu và BSD (Bucket Size Duration) giới hạn. SRB và dữ liệu thoại thường được ưu tiên.

4.5 HARQ và ARQ — hai tầng sửa lỗi, đừng nhầm

HARQ cơ bản: mỗi HARQ process chạy kiểu stop-and-wait (gửi → chờ ACK/NACK); để không phí thời gian chờ, có nhiều process chạy song song. DCI chứa HARQ process ID, NDI (New Data Indicator — bit đảo khi là dữ liệu mới, giữ nguyên khi là gửi lại) và RV.

4.6 Random Access trong góc nhìn MAC

4 bước (NR cũng có bản 2 bước từ Release 16):

1. Msg1: UE gửi preamble (PRACH).
2. Msg2: gNB trả RAR (Random Access Response) có UL grant + Timing Advance + TC-RNTI tạm thời.
3. Msg3: UE gửi MAC PDU chứa CCCH SDU (ví dụ RRCSetupRequest) hoặc C-RNTI MAC CE.
4. Msg4: gNB gửi MAC PDU chứa UE Contention Resolution Identity (lặp lại CCCH SDU) để giải quyết tranh chấp.

5. Ví dụ tính byte: gói IP 1000 B → Transport Block

Giả định (NR, uplink): DRB dùng RLC AM 12-bit SN, PDCP SN 12 bit, không integrity DRB, có SDAP header.

Bước 1 — qua các lớp trên (khi grant đủ lớn):

Giả sử gNB cấp Transport Block 1020 B. MAC PDU được điền:

┌────────────────────────────────┬──────────────────┬──────────────────────┐
│ subPDU dữ liệu (DRB)           │ subPDU Short BSR │ subPDU Padding        │
│ [3 B hdr][1005 B RLC PDU]      │ [1 B hdr][1 B CE]│ [1 B hdr][9 B pad]    │
│        = 1008 B                │      = 2 B       │      = 10 B           │
└────────────────────────────────┴──────────────────┴──────────────────────┘
                                         Tổng = 1008 + 2 + 10 = 1020 B ✔

PHY sau đó thêm CRC (24 bit với TB lớn hơn 3824 bit), chia code block, mã hóa LDPC, điều chế và gửi đi.

Bước 2 — nếu grant chỉ 600 B (RLC phải phân mảnh):

• RLC SDU (PDCP PDU) = 1003 B.
• TB 600 B: subheader MAC 3 B → RLC PDU tối đa 597 B. Header RLC AM của mảnh đầu = 2 B (SI = 01, không có SO) → mảnh đầu mang 595 B dữ liệu.
• Còn lại 1003 − 595 = 408 B → gửi ở lần cấp phát tiếp theo, mảnh cuối: SI = 10, SO = 595, header = 2 + 2 = 4 B → RLC PDU = 412 B, cộng subheader MAC 3 B = 415 B.
• Cả hai mảnh có cùng RLC SN; bên nhận ghép lại bằng SO. Nếu mảnh đầu mất, Status PDU sẽ NACK đúng SN đó kèm SOstart/SOend để chỉ xin gửi lại đoạn thiếu.

Overhead tổng cho trường hợp 1 (không phân mảnh): 1 + 2 + 2 + 3 = 8 byte trên 1000 byte dữ liệu ≈ 0,8% (chưa kể CRC/PHY và ROHC có thể giảm bớt header IP).

6. Nhìn thấy trong Wireshark

Với pcap có MAC context (srsRAN/OAI hoặc log của UE/gNB):

Cách đọc nhanh một DRB: mở mac-nr để biết subPDU thuộc LCID nào → tra RRCReconfiguration ra LCID đó ứng với DRB nào, rlc-Config là AM hay UM → đọc RLC SN/poll/status → xuống PDCP đọc SN.

7. Hiểu nhầm hay gặp

• “SN của PDCP và RLC là một.” Không. Hai bộ đếm độc lập; PDCP SN gắn với gói IP, RLC SN gắn với RLC PDU (và một mảnh dùng chung SN của SDU gốc).
• “MAC gửi lại gói RLC bị mất.” Không. MAC chỉ có HARQ (gửi lại Transport Block ở mức PHY/MAC). Gói mất “thật” (HARQ bó tay) do RLC AM gửi lại.
• “MAC-I là của lớp MAC.” Không. MAC-I (Message Authentication Code–Integrity) là của PDCP; nó trùng chữ “MAC” với lớp MAC hoàn toàn tình cờ.
• “RLC UM không cần SN.” UM có SN khi có phân mảnh; SDU nguyên vẹn thì không cần (header chỉ có SI).
• “Header RLC/MAC có mã hóa.” Không. Chỉ PDCP mã hóa (phần data, và với SRB cả MAC-I); header của RLC/MAC truyền rõ.
• “LCID của DRB cố định.” Không. LCID của SRB là cố định (1, 2, 3…), còn DRB do mạng gán qua RRCReconfiguration.

8. Tóm tắt để nhớ

Một câu cho mỗi lớp: PDCP bảo vệ và đánh số; RLC chia kiện và bảo đảm đến nơi; MAC điều độ chuyến xe và sửa lỗi nhanh.

Tài liệu tham khảo

• 3GPP TS 38.323 (NR PDCP), TS 38.322 (NR RLC), TS 38.321 (NR MAC), TS 37.324 (SDAP), TS 38.331 (RRC).
• 3GPP TS 36.323 (LTE PDCP), TS 36.322 (LTE RLC), TS 36.321 (LTE MAC).
• 3GPP TS 33.501 (bảo mật 5G — thuật toán NEA/NIA), TS 33.401 (bảo mật LTE — EEA/EIA).
• ShareTechnote — 5G NR Radio Protocol Stack Architecture.
• Bài tổng quan trên wiki: Radio Protocol Stack 5G NR cho người mới và Mô hình giao thức vô tuyến LTE.