Tìm hiểu PUCCH/PDCCH, C-RNTI và luồng báo hiệu LTE VoLTE/SMS

Bài viết tổng hợp lại một chuỗi câu hỏi–trả lời xoay quanh cách LTE xác định vị trí kênh điều khiển (PUCCH/PDCCH), cơ chế C-RNTI/blind decoding, và luồng báo hiệu thực tế của cuộc gọi VoLTE cũng như SMS/silent SMS ở tầng radio.

1. PUCCH Format 1 — vị trí kênh vật lý

Dựa theo bài viết ShareTechnote về PUCCH Format 1 Location, có 4 phần chính:

• Vị trí PUCCH: nằm gần 2 biên băng thông, nhảy qua lại giữa 2 biên theo từng slot (frequency hopping). Công thức tính PRB nằm ở 3GPP TS 36.211 mục 5.4.3, các tham số RRC liên quan ở TS 36.213 mục 10.1.2.1 và TS 36.331 (PUCCH-Config).
• Ảnh hưởng của tham số: diễn giải trực quan công thức bằng hình vẽ, đối chiếu Hình 5.4.3-1 trong 36.211.
• Tạo tín hiệu PUCCH Format 1: 3 bước — tạo y(n) bằng cyclic shift Zadoff-Chu, trải phổ tạo z(i) bằng orthogonal cover code (N_SF=4), ánh xạ vào resource element.
• Vị trí PUCCH của nhiều UE: dùng tham số n1_PUCCH = n_CCE + N1_PUCCH. Vì N1_PUCCH là tham số chung toàn cell còn n_CCE là UE-specific, nên vị trí PUCCH tự động khác nhau giữa các UE mà không cần báo hiệu riêng.

2. PUCCH vs PDCCH — khác nhau ở chiều truyền

ACK/NACK bắt buộc đi qua PUCCH vì đó là phản hồi từ UE lên eNB — PDCCH chỉ đi một chiều ngược lại. Công thức tính vị trí PUCCH “mượn” n_CCE của PDCCH chỉ vì đây là cách suy ra vị trí ngầm (implicit), tiết kiệm băng thông báo hiệu, không phải PDCCH mang ACK/NACK.

3. Wireshark và giới hạn ở PHY layer

Wireshark chỉ dissect được các layer có cấu trúc byte rõ ràng: MAC-LTE, RLC-LTE, PDCP-LTE, LTE-RRC — không có filter nào cho PUCCH/PDCCH/CCE vì đây là khái niệm PHY (cách ánh xạ bit vào sóng vô tuyến), không tồn tại dưới dạng “gói tin”.

Một số filter hữu ích:

lte-rrc                                    # tất cả bản tin LTE RRC
lte-rrc.systemInformationBlockType1        # SIB1
lte-rrc.si                                 # SystemInformation (chứa SIB2, SIB3...)
lte-rrc.rrcConnectionSetup
lte-rrc.rrcConnectionReconfiguration
mac-lte / rlc-lte / pdcp-lte

Điều kiện tiên quyết: Wireshark chỉ dissect được các layer này nếu file capture dùng đúng định dạng UDP framing đặc biệt (do công cụ test như Amarisoft, IxCatapult DCT2000 phát ra), hoặc bật heuristic dissector — bắt gói qua Ethernet/Wi-Fi thông thường sẽ không tự nhiên ra được các layer LTE.

Nguyên tắc cốt lõi: pcap không tự “mất” thông tin PHY — thông tin đó chưa từng được ghi vào file ngay từ đầu, vì sau khi PHY giải mã xong, tọa độ vật lý (PRB, CCE) không còn ý nghĩa với layer trên.

4. C-RNTI: layer nào, có mã hóa không, lưu ở đâu

• Layer: C-RNTI được RRC (Layer 3) cấp phát (qua RRCConnectionSetup), MAC (Layer 2) dùng làm địa chỉ, PHY (Layer 1) mượn để scramble CRC của PDCCH. Không thuộc riêng 1 layer.
• Không mã hóa: RRCConnectionSetup được gửi trước khi AS security bật, nên C-RNTI luôn là cleartext. Ngay cả sau khi bật security, RNTI vẫn không bị mã hóa vì PHY/MAC cần đọc trực tiếp để định tuyến.
• Lưu ở đâu: được lưu trong RRC context của cả UE và eNB, tồn tại suốt thời gian UE ở RRC_CONNECTED trong 1 cell. Khi handover, UE được cấp C-RNTI mới; khi về RRC_IDLE, C-RNTI được giải phóng.
• Không nằm trong MAC PDU với luồng dữ liệu DL-SCH/UL-SCH thông thường — chỉ có 3 ngoại lệ chứa RNTI dưới dạng bit thật: Random Access Response (Temporary C-RNTI), C-RNTI MAC Control Element, và newUE-Identity trong RRC Reconfiguration lúc handover.

5. XOR và cơ chế scramble CRC bằng RNTI

XOR (Exclusive OR): giống nhau → 0, khác nhau → 1. Tính chất quan trọng: (A XOR B) XOR B = A — đây là cơ sở của scrambling.

Quy trình:

1. eNB tính CRC của DCI, sau đó CRC_đã_scramble = CRC_gốc XOR C-RNTI.
2. UE thử gỡ: CRC_thử = CRC_nhận_được XOR C-RNTI_của_mình, so với CRC tính lại từ DCI vừa giải mã.
3. Khớp → đây là PDCCH của mình; không khớp → bỏ qua.

Đây là scrambling (kỹ thuật đánh dấu, dùng khóa công khai), không phải ciphering thật sự về bảo mật (dùng khóa bí mật + thuật toán mật mã).

6. Mã hóa ở Layer 2 khi RRC_CONNECTED

Layer 2 của LTE gồm 3 sub-layer: MAC, RLC, PDCP.

• Chỉ PDCP thực hiện ciphering (EEA0/1/2/3) — áp dụng cho nội dung RRC trên SRB1/SRB2 và dữ liệu user trên DRB. PDCP cũng làm integrity protection cho SRB (DRB thường không có).
• RLC và MAC header luôn cleartext — RLC cần đọc SN để ARQ, MAC cần đọc RNTI/LCID để định tuyến.
• RRC_CONNECTED không đồng nghĩa “đã mã hóa”: có khoảng thời gian đầu (RRCConnectionSetup, RRCConnectionSetupComplete) vẫn cleartext, cho tới khi thủ tục AS Security Mode Command hoàn tất.

7. CCE và cơ chế Blind Decoding chi tiết

CCE (Control Channel Element) = đơn vị tài nguyên PDCCH: 1 CCE = 9 REG = 36 RE. PDCCH chiếm 1/2/4/8 CCE liên tiếp (Aggregation Level), tùy điều kiện kênh.

UE không biết trước PDCCH nằm ở đâu, phải thử tại các vị trí trong Search Space (Common Search Space cho DCI chung, UE-specific Search Space tính từ RNTI + số subframe). Với mỗi vị trí ứng viên:

1. Giải channel coding → DCI_bits + CRC_nhận_được.
2. Tính CRC_ứng_viên = CRC_nhận_được XOR RNTI_của_mình.
3. So với CRC tính lại từ DCI_bits — khớp → nhận; sai → thử vị trí khác.

Xác suất false alarm ước tính khoảng 1/2^16 (~0.0015%), đủ nhỏ để coi là an toàn thống kê.

Tham chiếu 3GPP: TS 36.213 clause 9 (Physical downlink control channel procedures), công thức search space cụ thể ở clause 9.1.1.

8. Sniffer có thể bắt được C-RNTI không?

Có, theo 2 cách:

1. Đọc trực tiếp lúc cấp phát: RRCConnectionSetup là cleartext (trước khi bật security) → sniffer bắt bản tin này trên Common Search Space (dùng RA-RNTI/SI-RNTI đã biết trước theo spec) → đọc thẳng giá trị C-RNTI mới.
2. Brute-force: vì RNTI chỉ 16-bit (65536 giá trị), việc thử hết là khả thi về tính toán (khác hẳn brute-force khóa AES 128/256-bit).

Đây là thiết kế có chủ đích: RNTI chỉ để định tuyến trong 1 cell, không phải để bảo mật danh tính hay nội dung. Cái được bảo vệ thật sự là danh tính lâu dài (IMSI/IMEI, thay bằng GUTI/TMSI) và nội dung dữ liệu (PDCP ciphering). Biết RNTI chỉ giúp theo dõi traffic pattern, không đọc được nội dung đã mã hóa và không map trực tiếp ra danh tính.

9. SRB vs DRB — SIP/RTP nằm ở đâu

LTE phân biệt 2 loại radio bearer:

SIP/RTP hoàn toàn “vô hình” với LTE radio — chỉ là nội dung IP packet chạy trong DRB, đi qua DL-SCH/UL-SCH → PDSCH/PUSCH giống hệt RRC signaling, khác nhau ở logical channel và EPS Bearer/QCI đi kèm (QCI=5 cho SIP signaling, QCI=1 GBR cho RTP voice).

PDCCH không nằm trên cùng luồng dữ liệu mà chạy song song, độc lập: PDCCH nằm ở control region (1-3 symbol đầu của subframe), PDSCH nằm ở data region (các symbol còn lại) — PDCCH chỉ mang DCI (metadata vị trí/MCS), không chứa MAC PDU thật.

Sniffer bắt RNTI ở PDCCH — không phân biệt SRB/DRB tại bước này. Muốn phân biệt, phải giải thêm PDSCH tại vị trí PDCCH chỉ ra, đọc LCID trong MAC subheader (LCID=0: CCCH, LCID=1,2: DCCH/SRB, LCID≥3: DTCH/DRB) — MAC subheader luôn cleartext dù payload bên trong đã bị PDCP mã hóa.

Thứ tự đúng: DRB phải được “khai sinh” bằng 1 bản tin RRC Reconfiguration (đi qua SRB) trước, UE mới biết cách xử lý dữ liệu đến trên LCID đó — đây là bước làm 1 lần khi thiết lập cuộc gọi. Còn PDCCH thì luôn phải có mặt ở MỌI lần truyền (mỗi subframe), bất kể SRB hay DRB, suốt cuộc gọi.

10. Luồng báo hiệu MT Call (Mobile Terminated) đầy đủ

IMS Core nhận INVITE → MME → Paging (P-RNTI trên PDCCH)
        ↓
UE (IDLE) nhận Paging → Random Access (RACH)
        ↓
RRC Connection Setup → UE được cấp C-RNTI
        ↓
NAS: Service Request → Security Mode Command (bật ciphering)
        ↓
RRC Connection Reconfiguration → thiết lập Dedicated Bearer (QCI=1) cho thoại
        ↓
SIP signaling qua bearer đó (183 Ringing, PRACK...) → UE đổ chuông
        ↓
200 OK → ACK → RTP voice chạy trên bearer QCI=1

11. SMS và Silent SMS — có kích hoạt PDCCH/Paging không?

Có — về mặt Paging/RACH/RRC Setup, SMS (kể cả silent SMS) kích hoạt y hệt luồng của cuộc gọi thoại ở giai đoạn đầu, vì đây là cơ chế bắt buộc để đưa UE từ IDLE sang CONNECTED.

Khác biệt duy nhất: SMS luôn nằm gọn trong SRB2 (NAS Direct Transfer), không bao giờ cần mở DRB — nên phiên kết nối ngắn hơn nhiều so với thoại (không có bước RRC Reconfig thiết lập DRB, không có RTP kéo dài).

“Silent” chỉ là 1 flag (Data Coding Scheme “Type 0”) báo cho OS máy nhận xử lý ngầm — flag này chỉ được đọc SAU KHI toàn bộ luồng radio (Paging → RACH → C-RNTI → RRC Setup → Security → NAS Transport) đã chạy xong. Đây là nguyên lý của kỹ thuật silent SMS tracking: không cần đọc nội dung SMS đã mã hóa, chỉ cần biết “eNB vừa Paging UE này” là đủ xác nhận vị trí gần đúng của thiết bị tại 1 thời điểm.

Lưu ý quan trọng: kỹ thuật này chỉ hoạt động đáng tin cậy khi UE đang RRC_IDLE. Nếu UE đã ở RRC_CONNECTED sẵn (ví dụ đang duyệt web), SMS đến sẽ không cần Paging/RACH/RRC Setup lại — eNB gửi thẳng PDCCH dùng C-RNTI có sẵn, khiến quá trình nhanh hơn và thiếu hẳn tín hiệu “đánh thức” đặc trưng để suy luận vị trí.

12. Xây dựng Lab quan sát luồng MT Call (không cần RF thật)

Kiến trúc đề xuất: srsRAN mô phỏng qua ZMQ (không SDR/RF thật) + Open5GS (EPC) + Kamailio (IMS core), dựa theo dự án mã nguồn mở herlesupreeth/docker_open5gs trên GitHub — hỗ trợ sẵn cả chế độ RF-simulated (ZMQ) lẫn Over-The-Air.

Các thành phần chính:

• Core Network: open5gs (MME/SGW/PGW/HSS/PCRF)
• IMS: kamailio + pyhss (HSS cho Cx interface) + rtpengine
• RAN: srsRAN_4G (eNB + UE mô phỏng qua ZMQ)

Cách quan sát song song cả báo hiệu và hành vi nội bộ:

• Báo hiệu (RRC, NAS, S1AP, Diameter, GTP-U, SIP/SDP, RTP): bắt bằng tshark/Wireshark trên interface Docker tương ứng, real-time.
• Hành vi nội bộ (quyết định scheduler, blind decode, quyết định Paging…): xem qua docker logs -f <container> của từng thành phần (srsenb, srsue, mme, kamailio) song song với pcap.

Giới hạn của mô phỏng ZMQ: protocol stack chạy đúng 100% logic thật, nhưng không có fading/interference/tranh chấp tài nguyên do RF thật — không quan sát được HARQ retransmission do lỗi kênh hay handover do di chuyển.

13. Tài liệu tham khảo 3GPP theo từng chủ đề

Nên đọc TS 36.300 (Overall description E-UTRAN) trước tiên để có bức tranh tổng quan, trước khi đi sâu vào từng spec chi tiết ở trên.