BlogLuồng SMS qua giao diện SGs (SMS over SGs) — Tài liệu kỹ thuật tổng hợp
Bố cục bài viết
Luồng SMS qua giao diện SGs (SMS over SGs) — Tài liệu kỹ thuật tổng hợp
1. Kiến trúc tổng quan & các giao diện liên quan
2. Luồng MO-SMS (UE gửi SMS đi)
3. Luồng MT-SMS (mạng gửi SMS đến UE)
4. Tính cước (Charging)
5. Bảng giao thức báo hiệu theo từng chặng
6. Giao diện SGs có “đọc” được nội dung tin nhắn không?
Kết luận ngắn gọn
6.1 Về mặt chức năng — MME “mù nội dung”
6.2 Về mặt kỹ thuật — dữ liệu có mã hoá end-to-end không?
7. Các trường metadata “nhìn thấy được” — chi tiết theo lớp đóng gói
7.1 Cấu trúc lồng nhau (nesting) — “lột củ hành”
7.2 Luồng đầy đủ MO-SMS — annotate “ai thấy gì” tại mỗi hop
7.3 Bảng tổng hợp “ai thấy gì” tại mỗi node
Kết luận cốt lõi
Trang này
Sunex
14/08/2026 · 10 phút đọc
Ngày tạo
14/08/2026
Cập nhật
Lượt xem
25
Đọc
10m
Luồng SMS qua giao diện SGs (SMS over SGs) — Tài liệu kỹ thuật tổng hợp
Tham chiếu chuẩn: 3GPP TS 23.272, TS 24.011, TS 29.118, TS 32.250/298
1. Kiến trúc tổng quan & các giao diện liên quan
Uu S1-MME(NAS) SGs (SCTP) MAP-C (SS7/SIGTRAN)
┌─────┐ ┌─────────┐ ┌─────────┐ ┌───────────┐ ┌─────────┐
│ UE │◄────►│ eNodeB │◄──────►│ MME │◄──────►│ MSC/VLR │◄──────►│ HLR/HSS │
└─────┘ └─────────┘ └─────────┘ └─────┬─────┘ └─────────┘
│ MAP-E (SS7/SIGTRAN)
▼
┌─────────────┐
│ SMSC/SMS-GMSC│
└──────┬──────┘
CAP(CAMEL)/Diameter Ro │ Ga/Bx (CDR file/GTP')
▼
┌───────────────────┐
│ OCS (prepaid) / │
│ CGF → Billing Med. │
└───────────────────┘
2. Luồng MO-SMS (UE gửi SMS đi)
UE eNodeB MME MSC/VLR SMSC OCS/CGF
| | | | | |
|1.CP-DATA | | | | |
| (RP-DATA/ | | | | |
| SMS-SUBMIT) | | | | |
|──────────────►| | | | |
| |2.S1AP | | | |
| | NAS-Transport| | | |
| |─────────────►| | | |
| | |3.SGsAP-UPLINK- | | |
| | | UNITDATA | | |
| | |───────────────►| | |
| | | |4.MAP MO- | |
| | | | ForwardSM | |
| | | |──────────────►| |
| | | | |5.CAP InitialDP-|
| | | | | SMS (prepaid) │
| | | | |───────────────►|
| | | | |◄───────────────|
| | | | |6.trừ cước real-|
| | | | | time / hoặc |
| | | | | ghi CDR offline|
| | | | | → CGF (Ga/Bx) │
| | | | |───────────────►|
| | | | |7.Forward tới |
| | | | | thuê bao đích |
| | | |◄──────────────|(RP-ACK) |
| | |8.SGsAP-DOWNLINK| | |
| | | UNITDATA(ACK) | | |
| | |◄───────────────| | |
| |9.NAS Downlink| | | |
| | Transport | | | |
|◄──────────────|◄─────────────| | | |
|10.CP-ACK | | | | |
| (RP-ACK) | | | | |
3. Luồng MT-SMS (mạng gửi SMS đến UE)
SMSC/GMSC HLR/HSS MSC/VLR MME eNodeB UE
| | | | | |
|1.SRI-SM | | | | |
| (MAP) | | | | |
|──────────────►| | | | |
|◄──────────────| | | | |
|2.trả về IMSI+ | | | | |
| đ/c MSC/VLR | | | | |
|3.MAP MT- | | | | |
| ForwardSM | | | | |
|──────────────────────────────►| | | |
| | |4.(nếu UE idle) | | |
| | | SGsAP-PAGING- | | |
| | | REQUEST | | |
| | |───────────────►|4b.S1AP Paging | |
| | | |───────────────►|4c.Paging |
| | | | |────────────►|
| | | | |◄────────────|
| | | |◄───────────────|Service Req |
| | |5.SGsAP Service | | |
| | | Request/UE- | | |
| | | Activity-Ind | | |
| | |◄───────────────| | |
| | |6.SGsAP- | | |
| | | DOWNLINK- | | |
| | | UNITDATA | | |
| | | (CP-DATA/ | | |
| | | RP-DATA) | | |
| | |───────────────►|7.NAS Downlink | |
| | | | Transport | |
| | | |───────────────►|─────────────►|
| | | | | |8.SMS-DELIVER
| | | | |◄────────────|CP-ACK/RP-ACK
| | |◄───────────────|◄───────────────| |
|◄──────────────────────────────|9.MAP FSM-ACK | | |
|10.Ghi CDR "Delivery" (giao | | | |
| thành công) → CGF/Billing | | | |
4. Tính cước (Charging)
| Điểm sinh cước | Thời điểm | Cơ chế |
|---|---|---|
| SMSC | Nhận SMS-SUBMIT từ MO | Sinh SMS-MO-CDR (offline, TS 32.250) |
| SMSC ↔ OCS | Trước khi submit, nếu thuê bao trả trước | CAP (CAMEL Phase 3/4) – InitialDP-SMS → trừ tiền real-time; hoặc Diameter Ro/Gy nếu SMSC theo kiến trúc mới |
| SMSC | Giao SMS thành công tới máy nhận | Sinh SMS-MT-CDR (thường không tính phí bên nhận, trừ roaming) |
| SMSC → CGF | Định kỳ / theo lô | Ga interface (GTP′) hoặc Bx (file-based) đẩy CDR sang CGF → Billing Mediation → Rating Engine → Hóa đơn |
| MSC/VLR | Song song | Có thể sinh thêm bản ghi phụ trợ phục vụ thống kê lưu lượng SGs, nhưng cước chính nằm ở SMSC |
5. Bảng giao thức báo hiệu theo từng chặng
| Chặng | Giao diện | Giao thức |
|---|---|---|
| UE ↔ eNodeB | Uu | RRC |
| eNodeB ↔ MME | S1-MME | S1AP (bọc NAS) |
| UE ↔ MSC (xuyên qua MME) | — | CP/RP layer (TS 24.011) chứa TPDU SMS |
| MME ↔ MSC/VLR | SGs | SGsAP trên SCTP (TS 29.118) |
| MSC ↔ HLR/HSS | C | MAP (SRI-SM) |
| MSC ↔ SMSC | E | MAP (MO/MT-ForwardSM) qua SS7/SIGTRAN (M3UA) |
| SMSC ↔ OCS | — | CAP (CAMEL) hoặc Diameter Ro/Gy |
| SMSC ↔ CGF | Ga/Bx | GTP′ hoặc file transfer (TS 32.295/298) |
Điểm mấu chốt: SGs chỉ là “đường ống” chuyển tiếp CP-DATA/RP-DATA giữa UE và MSC/VLR qua MME — MME không đọc nội dung SMS, không tham gia tính cước; toàn bộ logic điều hướng (HLR query), sinh CDR và charging real-time đều nằm ở cặp MSC/VLR ↔ SMSC ↔ OCS/CGF.
6. Giao diện SGs có “đọc” được nội dung tin nhắn không?
Kết luận ngắn gọn
SGs không đọc/xử lý nội dung trong luồng hoạt động bình thường — nhưng cần phân biệt giữa chức năng logic và khả năng kỹ thuật (exposure).
6.1 Về mặt chức năng — MME “mù nội dung”
SGsAP (TS 29.118) mang SMS theo kiểu container trong suốt (transparent container):
SGsAP-UPLINK-UNITDATA
└── IE: NAS Message Container
└── CP-DATA
└── RP-DATA
└── TPDU (SMS-SUBMIT/DELIVER)
└── TP-User-Data ← nội dung text thật sự
- MME chỉ thấy IE “NAS Message Container” như một chuỗi byte đóng gói (opaque octet string), không parse CP/RP/TP layer.
- Nhiệm vụ của MME là relay: eNodeB (S1AP) → SGsAP → MSC/VLR, và ngược lại.
- MSC/VLR ở chặng SGs xử lý CP/RP layer để relay đúng transaction, nhưng không nhất thiết giải mã TP-User-Data — việc decode text chỉ có ý nghĩa thật sự ở hai đầu cuối: UE và SMSC.
6.2 Về mặt kỹ thuật — dữ liệu có mã hoá end-to-end không?
| Lớp | Có mã hoá bảo mật không? |
|---|---|
| UE ↔ MME (NAS) | Có — NAS Security (EEA/EIA) mã hoá & toàn vẹn |
| MME ↔ MSC/VLR (SGs/SCTP) | Không mã hoá ở tầng ứng dụng theo chuẩn — bảo mật dựa vào IPsec/physical security của mạng lõi (trusted domain), không phải end-to-end encryption |
→ Sau khi MME giải mã NAS container để relay, payload ở dạng cleartext trong nội bộ mạng lõi. Đây cũng là cơ sở kỹ thuật cho Lawful Interception (LI) tại các điểm này theo yêu cầu pháp lý — chứ MME/MSC theo thiết kế không có tác vụ chủ động “đọc” nội dung.
7. Các trường metadata “nhìn thấy được” — chi tiết theo lớp đóng gói
7.1 Cấu trúc lồng nhau (nesting) — “lột củ hành”
┌─────────────────────────────────────────────────────────────────┐
│ SGsAP-UPLINK-UNITDATA ← MME ĐỌC ĐƯỢC lớp ngoài cùng │
│ ├─ IMSI ✅ VISIBLE (MME đọc thẳng) │
│ └─ NAS-Message-Container ─────┐ │
│ │ ⚠️ Với MME: OPAQUE octet string│
│ ┌───────────────────────────▼─────────────────────────────┐ │
│ │ CP-DATA ← MSC/VLR ĐỌC ĐƯỢC lớp này │ │
│ │ ├─ Transaction ID ✅ VISIBLE │ │
│ │ └─ RP-DATA ─────────────┐ │ │
│ │ ┌───────────────────▼───────────────────────────┐ │ │
│ │ │ RP-DATA │ │ │
│ │ │ ├─ RP-Originator Addr (MSISDN gửi) ✅ VISIBLE │ │ │
│ │ │ ├─ RP-Destination Addr (SMSC/số nhận)✅VISIBLE │ │ │
│ │ │ └─ TPDU ─────────────┐ │ │ │
│ │ │ ┌────────────────▼────────────────────┐ │ │ │
│ │ │ │ TP-DA (số đích) ✅ VISIBLE │ │ │ │
│ │ │ │ TP-DCS (bảng mã) ✅ VISIBLE │ │ │ │
│ │ │ │ TP-UDL (độ dài) ✅ VISIBLE │ │ │ │
│ │ │ │ TP-VP (thời hạn) ✅ VISIBLE │ │ │ │
│ │ │ │ TP-User-Data (nội dung) 🔒 CHỈ ĐỌC Ở │ │ │ │
│ │ │ │ UE & SMSC │ │ │ │
│ │ │ └───────────────────────────────────────┘ │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └───────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
7.2 Luồng đầy đủ MO-SMS — annotate “ai thấy gì” tại mỗi hop
UE eNodeB MME MSC/VLR SMSC/SMSC-side OCS
│ │ │ │ │
│──RRC/NAS───►│ │ │ │
│ (mã hoá │──S1AP──────►│ │ │
│ NAS-sec) │ NAS-PDU │ │ │
│ │ │ [MME giải mã NAS-sec tại đây] │
│ │ │ │ │
│ │ │ ┌──────────────────────────────────┐ │
│ │ │ │ MME THẤY: │ │
│ │ │ │ ✅ IMSI │ │
│ │ │ │ ⚠️ NAS Container = OPAQUE │ │
│ │ │ │ (không parse CP/RP/TPDU) │ │
│ │ │ └──────────────────────────────────┘ │
│ │ │──SGsAP-UPLINK-UNITDATA─────────────►│
│ │ │ (IMSI + container nguyên vẹn) │
│ │ │ │ │
│ │ │ │ ┌────────────────┐ │
│ │ │ │ │ MSC/VLR THẤY: │ │
│ │ │ │ │ ✅ TI (CP) │ │
│ │ │ │ │ ✅ RP-Orig/Dest│ │
│ │ │ │ │ ✅ TP-DA,DCS, │ │
│ │ │ │ │ UDL,VP │ │
│ │ │ │ │ 🔒 TP-User-Data│ │
│ │ │ │ │ (không cần │ │
│ │ │ │ │ decode để │ │
│ │ │ │ │ relay) │ │
│ │ │ │ └────────────────┘ │
│ │ │ │──MAP MO-ForwardSM──►│
│ │ │ │ (TPDU đầy đủ) │
│ │ │ │ │
│ │ │ │ ┌───────────────────┐
│ │ │ │ │ SMSC THẤY TẤT CẢ: │
│ │ │ │ │ ✅ TP-OA (gửi) │
│ │ │ │ │ ✅ TP-DA (nhận) │
│ │ │ │ │ ✅ TP-DCS,UDL,VP │
│ │ │ │ │ ✅ TP-User-Data │
│ │ │ │ │ (SMSC BẮT BUỘC │
│ │ │ │ │ decode để định │
│ │ │ │ │ tuyến & tương │
│ │ │ │ │ thích SMPP/USSD/ │
│ │ │ │ │ OTA nếu cần) │
│ │ │ │ └────────┬──────────┘
│ │ │ │ │
│ │ │ │ ┌────────▼──────────┐
│ │ │ │ │ Ghi CDR: │
│ │ │ │ │ ✅ A-number │
│ │ │ │ │ ✅ B-number │
│ │ │ │ │ ✅ Timestamp │
│ │ │ │ │ ✅ Số segment │
│ │ │ │ │ 🚫 KHÔNG lưu nội │
│ │ │ │ │ dung (thường lệ)│
│ │ │ │ └────────────────────┘
7.3 Bảng tổng hợp “ai thấy gì” tại mỗi node
| Node | Đọc IMSI/MSISDN? | Đọc TP-DA/DCS/VP/UDL? | Đọc TP-User-Data (nội dung)? |
|---|---|---|---|
| eNodeB | ❌ (chỉ relay RRC/S1AP, NAS đã mã hoá) | ❌ | ❌ |
| MME | ✅ (IMSI ở IE ngoài) | ❌ (nằm trong opaque container) | ❌ |
| MSC/VLR | ✅ | ✅ | ❌ (không cần để relay, dù packet đã cleartext trong core) |
| SMSC | ✅ | ✅ | ✅ (bắt buộc, vì phải xử lý logic: forward, OTA, USSD gateway, content filtering nếu có) |
| OCS (nếu CAMEL) | ✅ (A-number) | ✅ (thường chỉ cần độ dài để tính số segment/cước) | ❌ (OCS chỉ cần biết “tính bao nhiêu tiền”) |
| CGF/Billing | ✅ | ✅ | ❌ |
Kết luận cốt lõi
Ranh giới rõ ràng nằm ở TP-User-Data — mọi trường còn lại (DA, OA, DCS, VP, UDL, timestamp, TI, IMSI) đều là metadata bắt buộc phải lộ ra ở các node trung gian để hệ thống hoạt động và tính cước đúng, kể cả khi hệ thống không có nhu cầu nghiệp vụ đọc nội dung tin nhắn thật.