Tổng hợp: SMS Roaming, Tính cước CAMEL/OCS và Kiến trúc báo hiệu SS7

Mục lục

1. Luồng SMS Roaming MO qua SS7 (kèm OCS)
2. Luồng SMS Roaming MT qua SS7: Direct Routing vs Home Routing
3. Home Routed vs Local Breakout — có áp dụng cho SMS không?
4. Cơ chế tính cước: vì sao roaming Reserve trước, nội mạng charge sau
5. Vấn đề bảo mật: SMS Spoofing trên SS7
6. Phân tích chi tiết từng layer SS7 cho MAP: MO-ForwardSM
7. Sơ đồ đóng gói đầy đủ kèm chi tiết TPDU (sm-RP-UI)
8. MTP1/2/3, SCCP, TCAP có cố định cho mọi báo hiệu SS7 không?
9. ISUP — báo hiệu thiết lập cuộc gọi thoại trên SS7
10. ISUP vs BICC — phân biệt Bearer Independent Call Control
11. Phân tích thực chiến: trace CAMEL của một cuộc gọi thoại
12. Xác minh bằng pcap thật: MO hay MT? Đính chính bằng bằng chứng ASN.1
13. Tổng hợp toàn bộ báo hiệu của cuộc gọi (từ pcap)
14. Cuộc gọi này là SIP, BICC hay TDM?

1. Luồng SMS Roaming MO qua SS7 (kèm OCS)

Thuê bao (MS) đang ở VPLMN, gửi SMS về SMSC của HPLMN. Giả định thuê bao prepaid, có SMS-CSI cấu hình sẵn trong HLR.

 MS(roaming)      VMSC/VLR (VPLMN)         gsmSCF/OCS (HPLMN)         SMSC (HPLMN)
     |                   |                          |                      |
     |--CP-DATA/RP-DATA->|                          |                      |
     |  (SMS-SUBMIT,     |                          |                      |
     |   chứa đ/c SMSC)  |                          |                      |
     |                   |                          |                      |
     |             [VMSC check SMS-CSI              |                      |
     |              -> có trigger CAMEL O-SMS]      |                      |
     |                   |--CAP: InitialDPSMS------>|                      |
     |                   |  (SS7 TCAP/SCCP, GT      |                      |
     |                   |   định tuyến về HPLMN)   |                      |
     |                   |                    [OCS: RESERVE credit,        |
     |                   |                     áp tariff cho SMS]          |
     |                   |<-CAP: Continue/Connect---|                      |
     |                   |   SMS (hoặc ReleaseSMS   |                      |
     |                   |   nếu bị chặn/hết tiền)  |                      |
     |                   |--MAP: MO-ForwardSM------------------------------>|
     |                   |   (SS7 TCAP/SCCP, GT tới SMSC HPLMN)             |
     |                   |                          |               [SMSC forward tới B]
     |                   |<-MAP: forwardSM-ack------------------------------|
     |                   |--CAP: EventReportSMS---->|                      |
     |                   |  (OCS: COMMIT hoặc ROLLBACK)                     |
     |<-CP-ACK/RP-ACK----|                          |                      |

Ghi chú:

• MS ↔ VMSC dùng RP/CP layer (không phải SS7 thuần); từ VMSC trở đi là SS7 thật (MAP, CAP trên TCAP/SCCP).
• Không có CAMEL trigger (postpaid): VMSC forward thẳng MO-ForwardSM, cước tính offline qua CDR.
• ReleaseSMS (hết tiền/bị chặn) khiến VMSC không forward, trả lỗi RP-ERROR về MS.

2. Luồng SMS Roaming MT qua SS7: Direct Routing vs Home Routing

2.1. Direct Routing (truyền thống)

 SMSC (HPLMN)          HLR (HPLMN)          VMSC/VLR (VPLMN)        MS(roaming)
     |--MAP: SRI-SM-------->|                       |                    |
     |                [HLR trả về MSC address hiện tại]                  |
     |<-MAP: SRI-SM-ack-----|                       |                    |
     |  (IMSI + MSC/VMSC address ở VPLMN)           |                    |
     |--MAP: MT-ForwardSM------------------------->|                    |
     |                      |                 [VMSC check T-CSI]        |
     |                      |                       |--CP-DATA/RP-DATA-->|
     |                      |                       |<-CP-ACK/RP-ACK-----|
     |<-MAP: forwardSM-ack--------------------------|                    |

Nhược điểm: SMSC/entity nước ngoài biết trực tiếp IMSI + MSC address thật → dễ bị khai thác spoofing/spam quốc tế.

2.2. SMS Home Routing (phổ biến hiện nay)

 SMSC (HPLMN)      SMS-Router/IP-SM-GW (HPLMN)      HLR (HPLMN)     VMSC/VLR (VPLMN)
     |--MAP: SRI-SM-------->|                            |                  |
     |                [SMS-Router "giả lập" là MSC,      |                  |
     |                 trả về địa chỉ CHÍNH NÓ]          |                  |
     |<-MAP: SRI-SM-ack-----|                            |                  |
     |--MAP: MT-ForwardSM-->|                            |                  |
     |                [SMS-Router tự query lại HLR,      |                  |
     |                 áp rule lọc fraud/spam/filter]    |                  |
     |                      |--MAP: SRI-SM (nội bộ)----->|                  |
     |                      |<-MAP: SRI-SM-ack-----------|                  |
     |                      |--MAP: MT-ForwardSM--------------------------->|
     |                      |<-MAP: forwardSM-ack-------------------------- |
     |<-MAP: forwardSM-ack--|                            |                  |

Ưu điểm: Ẩn thông tin định tuyến thật, cho phép lọc chống spoofing/spam/firewall SS7 trước khi tới VMSC thật.

3. Home Routed vs Local Breakout — có áp dụng cho SMS không?

• “Home Routed”/“Local Breakout” là thuật ngữ gốc dành cho định tuyến thoại roaming trong VoLTE/IMS (GSMA IR.65: S8HR, Local Breakout, Home Routed).
• MO-SMS trên SS7 luôn là “home routed” về bản chất vì địa chỉ SMSC cố định trong SIM, luôn trỏ về HPLMN — không tồn tại khái niệm local breakout.
• MT-SMS có 2 kiểu định tuyến thật (Direct Routing / SMS Home Routing — mục 2) nhưng dùng tên gọi khác, không phải “Local Breakout”.
• Khái niệm Local Breakout/Home Routed/S8HR chỉ thực sự áp dụng đúng nghĩa cho SMSoIP chạy trên hạ tầng IMS (SIP/IMS core), khác hoàn toàn kiến trúc SS7.

4. Cơ chế tính cước: vì sao roaming Reserve trước, nội mạng charge sau

4.1. Mô hình Reserve → Render → Commit/Refund (3GPP TS 32.240)

4.2. So sánh Domestic vs Roaming

5. Vấn đề bảo mật: SMS Spoofing trên SS7

5.1. Các vấn đề chính

1. Không xác thực Calling Party — MO-ForwardSM không kiểm tra bên gửi có phải VMSC hợp lệ hay không; OA (Originating Address)/Sender ID có thể bị giả mạo tùy ý.
2. Rò rỉ thông tin qua SRI-SM — trả về IMSI thật + địa chỉ MSC cho bất kỳ ai truy vấn, dùng để định vị hoặc chuẩn bị SMS interception.
3. Giả mạo Global Title — SCCP dựa hoàn toàn vào GT khai báo, không có PKI/chữ ký số xác thực.
4. SS7-as-a-Service — truy cập SS7 hợp pháp bị bán/cho thuê trái phép (GT leasing).
5. Thiếu kiểm tra chéo giữa các bản tin — không đối chiếu vị trí thật (VLR) với bản tin đến.

5.2. Bảng hệ quả

5.3. Biện pháp giảm thiểu

• SMS Home Routing (mục 2.2).
• SS7 Firewall (GSMA FS.11, FS.19) — kiểm tra tính hợp lệ GT, chặn bản tin bất thường.
• Category 1/2/3 filtering theo GSMA.
• Sender ID Registration/Whitelisting tại SMSC.
• Dịch chuyển dần sang SMSoIP/RCS trên IMS.

5.4. Vì sao spoof được — cửa vào thật sự nằm ở đâu

Kết luận: một khi đã có một điểm truy cập hợp lệ vào mạng SS7, hầu như mọi trường logic ở layer SCCP/TCAP/MAP phía trên đều có thể tự do điền tùy ý — vì SS7 được thiết kế trên nguyên tắc “trust-by-default” giữa vài chục nhà mạng, không có cơ chế xác thực nội dung logic.

6. Phân tích chi tiết từng layer SS7 cho MAP: MO-ForwardSM

6.1. Chồng giao thức và tương ứng OSI

6.2. Kịch bản ví dụ

Thuê bao Viettel +84987654321 roaming tại Singapore, gửi SMS về +84912000111, qua SMSC +84850888666.

• IMSI: 452012345678901
• VMSC (SingTel) Point Code: 2-100-3
• STP quốc tế phía VN Point Code: 3-050-1

6.3. MTP2 — Message Signal Unit (MSU)

| F | BSN/BIB | FSN/FIB | LI | SIO | SIF (chứa MTP3+SCCP+TCAP+MAP) | CK | F |

6.4. MTP3 — Routing Label

⚠️ OPC/DPC chỉ định tuyến từng chặng, không phải địa chỉ logic đầu-cuối.

6.5. SCCP — định tuyến logic toàn cầu qua Global Title

STP dịch GT qua Global Title Translation (GTT) để tìm Point Code thật/GT trung gian tiếp theo — đây là cơ chế cho phép SMS “xuyên biên giới” đến đúng SMSC dù người gửi đang roaming.

6.6. TCAP — khung giao dịch

Transaction Portion: Package Type (Begin/Continue/End), OTID. Dialogue Portion: Application-context-name (OID, ví dụ shortMsgMO-Relay-Context). Component Portion: Component Type (Invoke/ReturnResult/ReturnError/Reject), Invoke ID, Operation Code (opCode=46 → mo-ForwardSM), Parameters (ASN.1 BER).

6.7. MAP — MO-ForwardSM-Arg

7. Sơ đồ đóng gói đầy đủ kèm chi tiết TPDU (sm-RP-UI)

╔══════════════════════════════════════════════════════════════════════════╗
║ MTP LEVEL 2 — MSU: F|BSN,BIB|FSN,FIB|LI|SIO(0x03=SCCP)|SIF|CK|F           ║
║  ┌────────────────────────────────────────────────────────────────────┐  ║
║  │ MTP LEVEL 3 — OPC=2-100-3, DPC=3-050-1, SLS=5, SI=3 (SCCP)          │  ║
║  │  ┌──────────────────────────────────────────────────────────────┐  │  ║
║  │  │ SCCP — UDT: CdPA(GT=84850888666,SSN=8) CgPA(GT=84987654321)   │  │  ║
║  │  │  ┌────────────────────────────────────────────────────────┐  │  │  ║
║  │  │  │ TCAP: Begin/OTID=0x1A2B3C4D, AC=shortMsgMO-Relay-Context│  │  │  ║
║  │  │  │  ┌──────────────────────────────────────────────────┐  │  │  │  ║
║  │  │  │  │ Invoke: InvokeID=1, opCode=46 (mo-ForwardSM)      │  │  │  │  ║
║  │  │  │  │  ┌────────────────────────────────────────────┐  │  │  │  │  ║
║  │  │  │  │  │ MAP MO-ForwardSM-Arg                        │  │  │  │  │  ║
║  │  │  │  │  │  sm-RP-DA = 84850888666 (SMSC)               │  │  │  │  │  ║
║  │  │  │  │  │  sm-RP-OA = 84987654321 (thuê bao A)         │  │  │  │  │  ║
║  │  │  │  │  │  imsi = 452012345678901                      │  │  │  │  │  ║
║  │  │  │  │  │  moreMessagesToSend = FALSE                  │  │  │  │  │  ║
║  │  │  │  │  │  sm-RP-UI = SMS-SUBMIT TPDU (TS 23.040):      │  │  │  │  │  ║
║  │  │  │  │  │  ┌────────────────────────────────────────┐  │  │  │  │  │  ║
║  │  │  │  │  │  │ Octet1: TP-MTI=01(SUBMIT) RD=0 VPF=00   │  │  │  │  │  │  ║
║  │  │  │  │  │  │         SRR=0 UDHI=0 RP=0                │  │  │  │  │  │  ║
║  │  │  │  │  │  │ TP-MR = 0x05                             │  │  │  │  │  │  ║
║  │  │  │  │  │  │ TP-DA: Len=11 Type=0x91 Digits=84912000111│ │  │  │  │  │  ║
║  │  │  │  │  │  │ TP-PID = 0x00 (SMS thường)               │  │  │  │  │  │  ║
║  │  │  │  │  │  │ TP-DCS = 0x00 (GSM 7-bit)                │  │  │  │  │  │  ║
║  │  │  │  │  │  │ TP-UDL = 26 ký tự                        │  │  │  │  │  │  ║
║  │  │  │  │  │  │ TP-UD  = "Chao ban, day la SMS test"     │  │  │  │  │  │  ║
║  │  │  │  │  │  │          (GSM 7-bit packed)              │  │  │  │  │  │  ║
║  │  │  │  │  │  └────────────────────────────────────────┘  │  │  │  │  │  ║
║  │  │  │  │  └────────────────────────────────────────────┘  │  │  │  │  ║
║  │  │  │  └──────────────────────────────────────────────────┘  │  │  │  ║
║  │  │  └────────────────────────────────────────────────────────┘  │  │  ║
║  │  └──────────────────────────────────────────────────────────────┘  │  ║
║  └────────────────────────────────────────────────────────────────────┘  ║
╚══════════════════════════════════════════════════════════════════════════╝

Bảng chi tiết TPDU (TS 23.040)

Lưu ý mã hóa: SMS có dấu (VD tiếng Việt) → TP-DCS=0x08 (UCS-2), mỗi ký tự 2 byte → tối đa 70 ký tự/segment thay vì 160 ký tự GSM 7-bit.

Điểm mấu chốt về spoof: từ SCCP CgPA/CdPA đến sm-RP-OA, imsi, TP-DA/TP-UD — tất cả là trường ASN.1/octet string do bên gửi tự soạn, không có chữ ký/checksum xác thực xuyên suốt các layer.

8. MTP1/2/3, SCCP, TCAP có cố định cho mọi báo hiệu SS7 không?

Vì sao ISUP là ngoại lệ: ISUP chỉ cần định tuyến giữa các tổng đài kế cận (Point Code), không cần định tuyến logic toàn cầu như MAP (SMSC ở HPLMN bất kỳ) → không cần GT-based routing (SCCP), cũng không cần khung giao dịch TCAP.

TCAP là “người vận chuyển mù”: khung TCAP cố định, nhưng nội dung Operation Code/Parameter bên trong hoàn toàn phụ thuộc Application-Context-Name để biết đang là MAP, CAP hay INAP.

9. ISUP — báo hiệu thiết lập cuộc gọi thoại trên SS7

9.1. Vì sao ISUP không cần SCCP/TCAP

9.2. Chồng giao thức

MTP3 Routing Label (OPC, DPC, SLS, SI=5 ISUP)
  → ISUP Message trực tiếp: CIC, Message Type (IAM/ACM/ANM...),
    Mandatory Fixed Part, Mandatory Variable Part, Optional Part

9.3. Kịch bản ví dụ — IAM (Initial Address Message)

A (+84987654321, Viettel) gọi B (+84912000111, VinaPhone), CIC=45, MSC Viettel PC=1-020-5, MSC VinaPhone PC=1-030-2.

Lưu ý: ISUP không mang thoại; CIC chỉ là ID logic trỏ tới timeslot TDM đã đấu nối vật lý từ trước — bearer thật truyền song song, tách biệt (Common Channel Signaling).

9.4. Chuỗi bản tin đầy đủ

 MSC A                                        MSC B
   |--------- IAM (CIC=45, số B, số A) --------->|
   |<-------- ACM (Address Complete) ------------|
   |<-------- CPG (Call Progress, optional) -----|
   |<-------- ANM (Answer) ----------------------|   ← bắt đầu tính cước
   |========= Thoại 2 chiều qua CIC=45 ==========|
   |--------- REL (Release) --------------------->|
   |<-------- RLC (Release Complete) -------------|

10. ISUP vs BICC — phân biệt Bearer Independent Call Control

Kiến trúc NGN điển hình:

MSC-Server A -- BICC (SIGTRAN) -- MSC-Server B     [chỉ báo hiệu: IAM, APM, ACM, ANM]
     |                                    |
     └─ H.248/Megaco điều khiển Media Gateway ─┘
              [RTP thoại thật đi trực tiếp giữa 2 Media Gateway,
               KHÔNG qua MSC-Server]

11. Phân tích thực chiến: trace CAMEL của một cuộc gọi thoại

Trace ban đầu (ảnh chụp) cho thấy giao dịch CAMEL O-BCSM/T-BCSM giữa cổng 1051 và 1800:

Giả thuyết ban đầu (chỉ dựa vào tên operation, chưa xem tham số): nghi ngờ đây là cuộc gọi MO, và cuộc gọi bị cắt do hết tiền (vì ReleaseCall đến ngay sau ApplyChargingReport).

Giả thuyết này sau đó được kiểm chứng lại bằng file pcap thật ở mục 12 — và hóa ra sai một phần quan trọng.

12. Xác minh bằng pcap thật: MO hay MT? Đính chính bằng bằng chứng ASN.1

Dùng tshark decode toàn bộ tham số InitialDPArg và EventReportBCSMArg.

12.1. Bằng chứng quyết định

eventTypeBCSM: termAttemptAuthorized (12)   → DP12, thuộc T-BCSM
eventTypeBCSM: tAnswer (15)                 → tiền tố "t" = terminating
eventTypeBCSM: tDisconnect (17)             → tiền tố "t" = terminating

→ Đây là cuộc gọi MT (Terminating), không phải MO như suy đoán ban đầu (nếu là MO phải là collectedInfo(2), oAnswer, oDisconnect).

12.2. Thông tin trích từ InitialDPArg

12.3. Đính chính giả thuyết “hết tiền”

ApplyChargingArg: maxCallPeriodDuration = 1800 giây (Reserve rất rộng rãi)
eventReportBCSM (tDisconnect): releaseCause = 16 = "Normal call clearing"
Thời lượng thực tế Answer→Disconnect: ~107 giây (<< 1800 giây Reserve)

→ Cuộc gọi kết thúc bình thường do một bên gác máy, KHÔNG phải do hết credit. ReleaseCall chỉ là bước đóng phiên CAMEL đúng thủ tục sau khi đã nhận báo cáo Disconnect.

Bảng so sánh trước/sau khi có bằng chứng thật

13. Tổng hợp toàn bộ báo hiệu của cuộc gọi (từ pcap)

Lọc đúng theo TCAP Dialogue ID: Begin otid=03ed7726 (initialDP) ↔ otid=38035cfc (SCF tự cấp).

Các bản tin loại trừ (thuộc dialogue/TCAP OTID khác, KHÔNG phải cuộc gọi này): activityTest/releaseCall (otid=2002edd4), requestReportBCSMEvent+connect (otid=340b0bed — cuộc gọi khác đang xử lý song song), 2× noteMM-Event GSM MAP (otid khác, serviceKey=1 khác serviceKey=12 của cuộc gọi này).

Chồng giao thức thực tế:

Transport:  SCTP (thay cho MTP1/2/3 truyền thống — SIGTRAN)
Network:    M3UA (đóng vai trò MTP3)
Routing:    SCCP (GT + SSN=CAP)
Session:    TCAP (Begin/Continue/End)
Ứng dụng:   CAP v3 (initialDP, RRBE, applyCharging, continue,
                     eventReportBCSM ×2, applyChargingReport, releaseCall)

14. Cuộc gọi này là SIP, BICC hay TDM?

Kết quả kiểm tra trực tiếp

Toàn bộ 4560 frame trong pcap chỉ gồm SCTP→M3UA→SCCP→TCAP→CAMEL/GSM MAP, và một nhánh TCP/TLS hoàn toàn không liên quan (cổng 5701=Hazelcast, 8086=InfluxDB, 27017=MongoDB — hạ tầng nội bộ OCS/mediation). Không có frame ISUP, BICC, hay SIP nào trong file.

Vì sao đây là điều bình thường

Giao diện CAP giữa gsmSSF (MSC) và gsmSCF (SCP/OCS) tách biệt vật lý hoàn toàn khỏi giao diện thiết lập kênh thoại thật (ISUP/BICC/SIP) giữa các tổng đài:

MSC/MSC-Server
   ├── CAP (qua SIGTRAN) ──► SCP/OCS       ← nằm trong pcap này
   └── Call control tới tổng đài kế tiếp   ← KHÔNG nằm trong pcap này
        (ISUP TDM, hoặc BICC, hoặc SIP-I/SIP)

CAMEL được thiết kế “bearer-agnostic” — hoàn toàn không phụ thuộc/không tiết lộ công nghệ chuyển mạch bên dưới.

Manh mối duy nhất — không đủ kết luận

bearerCapability: 3.1kHz audio, Circuit mode, 64kbit/s — là định dạng IE kiểu Q.763/ISUP cổ điển, nhưng ISUP, BICC, và cả SIP-I (khi đóng gói ISUP trong SIP) đều dùng chung định dạng này → không phân biệt được.

Muốn xác định chính xác cần gì

Kết luận: Không thể xác định SIP/BICC/TDM chỉ từ file pcap chứa lớp CAP này — cần một bản capture khác tại đúng điểm thiết lập cuộc gọi thật.