Cấu trúc báo hiệu RRC/PCCH trong LTE

Bài viết này tổng hợp lại toàn bộ kiến thức về cơ chế báo hiệu PCCH, RRC, RNTI và các thủ tục liên quan trong mạng LTE — từ cấu trúc bản tin paging chi tiết cho tới việc UE thiết lập kết nối vô tuyến qua Random Access.

1. PCCH trong ngăn xếp giao thức LTE

PCCH (Paging Control Channel) là một kênh logic downlink, dùng để mang bản tin paging từ mạng tới UE khi UE đang ở trạng thái RRC_IDLE. Chuỗi ánh xạ kênh:

PCCH (kênh logic)
   ↓
PCH  (kênh truyền tải)
   ↓
PDSCH (kênh vật lý) — được chỉ thị bởi PDCCH scramble với P-RNTI

Vì PCCH là kênh broadcast dùng chung cho nhiều UE, eNB không thiết lập kết nối RRC riêng để gửi paging — UE ở RRC_IDLE chỉ cần “thức dậy” đúng Paging Occasion (PO) để giải mã PDCCH/P-RNTI rồi đọc PDSCH tương ứng.

2. Cấu trúc bản tin RRC Paging (PCCH-Message)

Theo 3GPP TS 36.331, bản tin Paging gồm các trường chính:

Mỗi PagingRecord gồm:

S-TMSI = MMEC (8 bit) + M-TMSI (32 bit) — cho phép định danh UE mà không lộ IMSI thật.

3. Cơ chế Paging Frame / Paging Occasion (DRX)

UE chỉ cần nghe PDCCH tại các thời điểm cố định gọi là Paging Occasion (PO), nằm trong Paging Frame (PF), thay vì nghe liên tục. Tham số quảng bá trong SIB2 (PCCH-Config):

• defaultPagingCycle (T) — chu kỳ mặc định (rs32/64/128/256 frame)
• nB — hệ số xác định số lượng PO trong mỗi PF

Công thức (TS 36.304):

N  = min(T, nB)
SFN thỏa: SFN mod T = (T div N) × (UE_ID mod N)
UE_ID = IMSI mod 1024

4. RRC là gì và quan hệ với PCCH

RRC (Radio Resource Control) là giao thức Layer 3, quản lý toàn bộ vòng đời kết nối vô tuyến: trạng thái UE (IDLE/CONNECTED), cấu hình vô tuyến, đo đạc, handover.

Điểm quan trọng cần làm rõ: RRC không “chứa” PCCH. Quan hệ đúng là:

• RRC là giao thức — soạn ra nội dung bản tin (Paging, System Info, cấu hình riêng…)
• PCCH là một kênh logic — “đường ống” vận chuyển loại bản tin Paging cụ thể xuống lớp dưới

RRC (giao thức, Layer 3)
   ↓ chọn kênh logic tương ứng với loại bản tin
BCCH | PCCH | CCCH | DCCH   (kênh logic, ranh giới Layer 2/3)
   ↓
PCH / DL-SCH  (kênh truyền tải)
   ↓
PDSCH  (kênh vật lý)

PCCH chỉ tồn tại và có ý nghĩa khi UE ở RRC_IDLE — vì lúc đó UE chưa có kênh riêng, mạng phải dùng “loa chung” để gọi. Khi UE đã RRC_CONNECTED, mọi báo hiệu đi qua DCCH (kênh riêng, hai chiều).

Về bản chất, kênh logic đóng vai trò gần giống “nhãn phân loại + ghép kênh” (classification & multiplexing) hơn là “định tuyến” theo nghĩa network routing — không có khái niệm chọn đường qua nhiều node trung gian.

5. Bảng các kênh logic chính

6. Địa chỉ hóa trên giao diện vô tuyến: RNTI

Radio về bản chất là quảng bá (broadcast) — không có “dây riêng” giữa eNB và từng UE. Việc UE nhận đúng dữ liệu của mình dựa trên cơ chế “quảng bá + lọc theo địa chỉ”, dùng RNTI (Radio Network Temporary Identifier).

6.1. TTI, PDCCH, PDSCH, CRC

• TTI (Transmission Time Interval): đơn vị lập lịch cơ bản = 1 subframe = 1ms
• PDCCH: vùng điều khiển đầu mỗi subframe (1-3 ký hiệu OFDM), mang DCI
• PDSCH: vùng dữ liệu thật, chiếm phần còn lại của subframe
• CRC: mã kiểm tra lỗi — với DCI, CRC còn bị XOR (scramble) với RNTI trước khi gửi, nên vừa xác nhận toàn vẹn dữ liệu vừa xác nhận đúng UE nhận

6.2. Cơ chế “blind decoding”

UE thử giải mã các vị trí PDCCH khả dĩ (search space), tính CRC cho từng khả năng, so với các RNTI đang theo dõi (C-RNTI riêng, cộng thêm P-RNTI/SI-RNTI/RA-RNTI khi cần) — khớp thì đọc tiếp, không khớp thì bỏ qua.

6.3. Các loại RNTI

Lưu ý quan trọng: P-RNTI không “định danh” UE nào cả — nó chỉ báo “đây là bản tin paging”. Định danh thật (S-TMSI/IMSI) nằm trong nội dung bản tin RRC, không nằm ở giá trị RNTI.

6.4. C-RNTI khi IDLE → CONNECTED và khi Handover

C-RNTI không kế thừa từ P-RNTI. Khi UE chuyển sang CONNECTED, nó nhận Temporary C-RNTI (TC-RNTI) qua Random Access, xác nhận thành C-RNTI chính thức sau bước Contention Resolution.

C-RNTI cố định trong suốt phiên CONNECTED tại 1 cell (dùng cho cả DL và UL). Khi handover sang cell khác, C-RNTI bị đổi hoàn toàn — vì nó chỉ có ý nghĩa cục bộ trong phạm vi 1 cell (MAC scheduler của mỗi cell tự quản lý không gian định danh riêng):

eNB nguồn → Handover Request (X2) → eNB đích
eNB đích cấp C-RNTI mới → gửi ngược qua Handover Ack
eNB nguồn đóng gói vào RRCConnectionReconfiguration (Handover Command) → UE
UE đồng bộ tới cell mới, dùng C-RNTI mới

7. DCI (Downlink Control Information)

DCI là nội dung thực tế nằm trong PDCCH. Một DCI chứa: vị trí resource block, MCS, HARQ process number, NDI, Redundancy Version, TPC command…

7.1. DCI Format

Vì nhu cầu thông tin khác nhau giữa các tình huống, DCI có nhiều format:

UE biết dùng format nào dựa vào Transmission Mode đang cấu hình (RRC chỉ định) và loại RNTI đang giám sát.

7.2. Phát hiện Uplink/Downlink

Format 0 (UL) và Format 1A (DL) có cùng kích thước bit (thiết kế cố ý để giảm số lần blind decoding). Phân biệt bằng 1 bit cờ (flag) trong chính nội dung DCI: bit = 0 → Format 1A (DL); bit = 1 → Format 0 (UL).

Ở cấp khung truyền, phân biệt DL/UL theo kiểu song công:

8. Thủ tục Random Access: MSG1 – MSG5

Đây là quy trình UE dùng để lấy được C-RNTI và thiết lập kết nối RRC ban đầu.

Lưu ý: theo TS 36.321, thủ tục RACH chuẩn chỉ có 4 bước (MSG1-MSG4). “MSG5” là cách gọi phổ biến trong thực tế để chỉ bước RRC tiếp theo ngay sau khi RACH hoàn tất.

Với Non-contention based Random Access (dùng khi handover), chỉ cần MSG1-MSG2 vì preamble được cấp riêng, không có tranh chấp.

9. Ứng dụng thực tế: Silent SMS và VoLTE (SIP)

9.1. Silent SMS khi UE đã CONNECTED

Nếu UE đã RRC_CONNECTED, mạng không cần paging lại — SMS được gửi thẳng qua kênh báo hiệu đã có sẵn (DCCH, qua thủ tục NAS Transport).

9.2. Luồng SMS đầy đủ (MT-ForwardSM → CP-DATA)

MT-ForwardSM là thao tác MAP/Diameter, chỉ tồn tại giữa SMSC và MME (lõi mạng), UE không tham gia giao thức này. MME bóc nội dung SMS bên trong, đóng gói lại theo NAS:

SM-TL (nội dung SMS thật)
   → SM-RL → RP-DATA
   → SM-CP → CP-DATA
   → NAS message (DL NAS Transport)
   → RRC DL Information Transfer
   → gửi qua DCCH

Mã hóa CP-DATA — 2 lớp độc lập:

→ Ngay cả khi eNB bị chiếm quyền và giải mã lớp AS, nội dung SMS thật vẫn không đọc được nếu thiếu khóa NAS.

9.3. SIP trong VoLTE — khác hoàn toàn với SMS

PCCH/RRC Paging không bao giờ chứa nội dung SIP. Paging chỉ “đánh thức” UE; SIP đi qua user-plane, không phải NAS:

SIP INVITE đến (từ P-CSCF)
   → MME nhận Downlink Data Notification
   → Paging qua PCCH (chỉ chứa S-TMSI, KHÔNG chứa SIP)
   → UE Service Request → RRC_CONNECTED, thiết lập bearer (QCI=5)
   → SIP INVITE thật gửi qua Dedicated Radio Bearer (DRB)
      mã hóa PDCP (AS security) + có thể thêm IPsec ESP (lớp IMS, theo TS 33.203)

9.4. UE giải mã DRB để lấy SIP như thế nào

PHY   → giải mã PDSCH
MAC   → xác định đúng DRB (Logical Channel ID)
RLC   → ráp lại đúng thứ tự
PDCP  → giải mã AS security (K_UPenc) → ra gói IP nguyên vẹn
IP    → (giải mã thêm IPsec ESP nếu có)
UDP   → cổng 5060
SIP   → nội dung đọc được, chuyển cho ứng dụng IMS client

Một khi đã qua PDCP để lấy được gói IP, phần còn lại (IP/UDP/SIP) xử lý hoàn toàn như một ngăn xếp mạng dữ liệu thông thường, tách biệt khỏi thế giới báo hiệu RRC.

10. Kiến trúc eNodeB — số lượng cell

3GPP không quy định số cell cố định cho mỗi eNodeB:

• Phổ biến nhất: 3 cell/eNodeB (site 3 sector, mỗi sector ~120°)
• Có thể tăng lên 6, 9… nếu multi-carrier trên mỗi sector
• Small cell/femtocell: thường chỉ 1 cell
• Giới hạn địa chỉ theo ECGI: eNB ID (20 bit) + Cell ID (8 bit) → tối đa lý thuyết 256 cell/eNB

Mỗi cell trong cùng 1 eNodeB hoạt động độc lập về vô tuyến (PCI riêng, RNTI riêng, PDCCH/PDSCH riêng) dù chung phần cứng xử lý.

Tổng kết