5G 悖論:為何海外「滿格訊號」不等於上網速度?
在海外旅行時,很少有比這種情況更令人沮喪的經歷:站在東京澀谷十字路口的霓虹燈廣告牌下、穿梭於倫敦希斯路機場的抵港大堂,或是在紐約時代廣場準備叫 Uber 時,手機明明顯示著「5G」滿格訊號,但瀏覽器卻不斷顯示連線逾時,通訊軟件的載入圖示亦轉個不停。
這種訊號強度圖示與實際網絡傳輸速度(Throughput)之間的巨大落差,在電訊領域中被稱為 「5G 悖論」(5G Paradox)。要理解箇中原因,必須先將手機狀態欄所顯示的測量數值,與數據在國際網絡傳輸的實際方式分開來看。
+-----------------------------------------------------------------------------+
| 手機實際上測量的內容 |
+-----------------------------------------------------------------------------+
| [手機裝置] <===== 射頻無線鏈路 (Layer 1 實體層) =====> [本地基站] |
| * 測量指標:RSRP、RSSI、SINR(訊號格數) |
| * 狀態:5/5 滿格(極佳的射頻 RF 連線) |
+-----------------------------------------------------------------------------+
|
| 回傳網絡 (Backhaul) / 傳輸路由
v
+-----------------------------------------------------------------------------+
| 網絡瓶頸真正發生的位置 |
+-----------------------------------------------------------------------------+
| [本地基站] ---> [IPX 交換中心] ---> [歸屬地分組網關] ---> 互聯網 (Internet) |
| * Layer 3 IP 路由與封包轉發 (Packet Forwarding) |
| * 頻寬配額、QCI 優先次序及國際傳輸節點瓶頸 |
+-----------------------------------------------------------------------------+Layer 1(實體射頻層)vs. Layer 3(封包路由層)
手機上顯示的四格或五格訊號,僅代表 Layer 1(實體無線接入網 / RAN) 的連線狀態。手機主要依據以下各項射頻(RF)指標來計算出訊號格數:
- RSRP(Reference Signal Received Power,參考訊號接收功率): 從鄰近手機發射基站(5G 為 gNodeB,LTE 為 eNodeB)接收到的原始訊號功率。
- RSSI(Received Signal Strength Indicator,接收訊號強度指示): 接收到的整體寬頻功率總和,包含背景雜訊與干擾。
- SINR(Signal-to-Interference-plus-Noise Ratio,訊噪比): 無線電訊道的連線質素。
滿格訊號僅代表手機與當地基站天線之間擁有暢通無阻、衰減極低的無線電連線。這絕不代表該基站具備足夠的回傳頻寬容量(Backhaul Capacity),亦不代表網絡已為你的裝置分配了數據頻寬。
+--------------------------+-----------------------------------------------------------+
| 指標 / 網絡層級 | 負責控制的範疇 |
+--------------------------+-----------------------------------------------------------+
| Layer 1(RAN / 射頻層) | 訊號格數、與本地基站天線的原始連線穩定度。 |
| Layer 2(數據鏈路層) | 數據幀傳輸(Frame Transmission)、本地無線排程調度優先級。 |
| Layer 3(網絡 / IP 層) | 實際數據吞吐量(Throughput)、IP 封包傳輸與路由路徑。 |
+--------------------------+-----------------------------------------------------------+即使你的手機與當地電訊商(例如日本 NTT Docomo 或英國 EE)建立了極佳的 Layer 1 握手連線,你的數據封包仍必須通過 Layer 3(網絡路由層) 傳輸。如果該基站小區同時擠滿了兩萬名本地用戶,或者連接基站與核心網絡的回傳光纖鏈路已達飽和,你的數據封包就會被排在調度隊列的最尾端。
漫遊傳輸瓶頸:IPX 與歸屬地路由(Home Routing)
國際旅遊 eSIM 引入了另一層技術複雜性:漫遊網絡架構(Roaming Architecture)。當你使用旅遊 eSIM 上網時,數據並非直接從當地網絡出口接入互聯網,而是通常需要經過漫長的國際漫遊傳輸鏈路:
- 本地接入(Local Access): 手機透過 Layer 1 無線電接入造訪國的當地電訊商 RAN 基站。
- IPX 封裝(IPX Encapsulation): 當地電訊商將你的數據封包進行封裝,並透過 IPX(IP eXchange) 運營商網絡(由 Syniverse、BICS 或 Tata Communications 等跨國中轉商營運)轉發出境。
- 歸屬地核心網路由(Home Routed Core / S8HR): 在標準的「歸屬地路由」架構下,你的所有網絡流量必須一路傳回發行該 eSIM 的虛擬網絡運營商(MVNO)核心網(通常設於香港、波蘭、法國或以色列),然後才正式連接至公共互聯網。
- 返回路徑(Return Path): 你請求的互聯網數據必須沿著這條跨大洲路線原路折返,才能傳送回你的手機。
在這條跨越多國節點的長途鏈路中,只要任何一段出現封包遺失(Packet Loss)、延遲飆升(Latency Spike)或頻寬限制,即使手機畫面自豪地顯示著「5G 滿格」,你的實際網速亦會直接跌至零。
為何在擠塞區域「智能限速底線」至關重要?
當網絡面臨高峰擠塞或觸發公平使用限制時,一般旅遊 eSIM 通常會將用戶頻寬狠削至 128kbps,甚至將優先級降至極低,導致封包遺失率高達 80% 以上。在 128kbps 的極速限制下,現代加密 TLS 握手連線幾乎必然逾時失敗,導致 Google Maps、Uber 叫車確認及流動電子支付等關鍵工具全面癱瘓。
為解決這項痛點,經優化的漫遊服務商(如 MollySIM)採用了直連路由架構,並設定了大幅領先業界的 384kbps 公平使用政策(FUP) 最低基準。透過維持 384kbps 的網速下限(達到業界標準的 3 倍),核心數據封包(如向量地圖渲染、Apple Pay Token 交換以及 WhatsApp 文字訊息)依然能保有足夠的傳輸速率穩定運行,徹底避免因本地線路擠塞而導致網絡完全斷線的窘境。
解構 QCI:電訊商網絡優先次序降級(Deprioritization)的運作真相
🇯🇵 日本 高速 eSIM & 电话卡方案
无需插卡开箱即用,支持热点共享,即使高速流量用尽也可维持 Google 地图/移动支付顺畅运行。
要明白為何你的旅遊 eSIM 慢到無法上網,而站在身旁的當地居民卻能順暢串流播放 4K 影片,我們必須跳出訊號格數的迷思,深入了解無線資源分配層(Radio Resource Allocation)。流動網絡對待不同數據封包並非一視同仁。相反,3GPP 國際架構標準透過 4G LTE 中的 QoS Class Identifiers (QCI) 以及 5G 獨立組網(SA)中的 5G QoS Identifiers (5QI) 來界定流量等級。
當手機連接到當地基站(LTE 的 eNodeB 或 5G 的 gNodeB)時,造訪國電訊商的策略與計費規則功能單元(PCRF)會為其分配一個具備特定數值優先級的 EPS Bearer(承載通道)。這個優先等級決定了數據封包在實體無線電頻譜中的實際發送先後順序。
QCI/5QI 階級層次:漫遊用戶的真實處境
每個流動網絡連線都處於嚴格的優先等級之中,從最關鍵的語音通道一路排列到最低等級的背景數據。然而,外來漫遊流量(Inbound Roaming)——即幾乎所有市售的旅遊 eSIM——在電訊商系統中幾乎全被歸類在最底層。
| 服務質素標識 (QCI) | 資源類型 | 優先級別 | 封包延遲預算 | 目標封包丟失率 | 典型應用場景描述 |
|---|---|---|---|---|---|
| QCI 1 | GBR(保證比特率) | 2 | 100 ms | $10^{-2}$ | 關鍵任務語音通話(VoLTE / VoNR)。 |
| QCI 5 | Non-GBR | 1 | 100 ms | $10^{-6}$ | IMS 核心信令(呼叫建立、網絡握手協議)。 |
| QCI 6 | Non-GBR | 6 | 300 ms | $10^{-6}$ | 本地 Tier-1 頂級月費計劃用戶數據(如主要電訊商高級計劃)。 |
| QCI 7 | Non-GBR | 7 | 100 ms | $10^{-3}$ | 中階本地月費用戶數據、手機遊戲及互動視訊。 |
| QCI 8 | Non-GBR | 8 | 300 ms | $10^{-6}$ | 標準本地增值卡(Prepaid)及本地優質 MVNO 數據。 |
| QCI 9 | Non-GBR | 9 | 300 ms | $10^{-6}$ | 外來國際漫遊用戶、標準旅遊 eSIM 及被降級的非優先數據。 |
比例公平排程:基站如何「丟棄」你的封包?
基站會將可用的無線電頻段細分為極微小的時間與頻率單位,稱為 實體資源區塊(Physical Resource Blocks,簡稱 PRB)。基站內部的排程器每秒會執行數百次 比例公平演算法(Proportional Fair, PF),將這些 PRB 分配給已連線的設備。
在低至中度網絡負載下,排程器可以輕鬆滿足所有接入設備的需求。然而,當你身處高密度人流區域(如國際機場抵港大堂、繁忙時間的轉乘地鐵站或大型演唱會場地),PRB 資源利用率會達到 100% 飽和狀態。
一旦資源飽和,排程器就會啟動嚴格的資源分配控制:
- 緩衝隊列分配(Queue Buffer Allocation): 排程器會優先處理 QCI 6 與 7 的隊列。標記為 QCI 9 的設備(例如旅遊 eSIM)會被排在緩衝區的最末端。
- 緩衝區膨脹與 TCP 延遲(Bufferbloat & Latency): 由於 QCI 9 封包必須長時間等待傳輸空檔,往返時間(RTT)會劇增。原本正常的 40ms Ping 值會在短時間內飆升至 1,500ms 以上。
- 尾端丟棄(Tail Dropping): 若基站的傳入緩衝區完全被填滿,排程器會執行「尾端丟棄」機制——直接將低優先級的封包丟棄,完全不讓其進入無線電鏈路。
- TCP 退避惡性循環(TCP Backoff): 手機作業系統會將大量丟包視為嚴重網絡故障,自動大幅縮小 TCP 視窗大小,最終令實際下載速度歸零。
如何突破旅途中的網絡降級瓶頸?
由於當地網絡運營商在流量高峰期必然優先照顧本地高消費月費用戶,漫遊用戶遭受嚴重降級實屬常見。普通旅遊 eSIM 往往雪上加霜,既被歸入最底層的 QCI 9,更設有嚴苛的 128kbps 限速門檻;而針對效能進行深度優化的計劃則能透過降低封包傳輸損耗與提升底線頻寬,大幅減輕影響。
例如 MollySIM 重新構建了傳輸路由,極大化減少多重轉發延遲,並嚴格維持 384kbps 公平使用政策(FUP)最低限速——這是傳統旅遊 eSIM 128kbps 上限的三倍之多。當 128kbps 連線因降級而無法完成基本安全加密握手時,384kbps 的基準速度依然能提供足夠的封包速率,讓 Google Maps 導航、Uber 叫車定位與 Apple Pay 認證順暢完成而不致超時。
「無限數據」背後的真相:公平使用政策(FUP)與限速機制
「無限數據」(Unlimited Data)是國際漫遊市場上最常被濫用的營銷術語。當廉價 eSIM 服務商宣傳無限高速數據時,往往在條款深處隱藏了嚴格的公平使用政策(Fair Usage Policy,簡稱 FUP)。在現實中,由於外國電訊商收取的漫遊批發成本極高,幾乎沒有任何消費級旅遊 eSIM 能在海外網絡上提供真正無限制、不降速的高速數據。
相反,用戶往往在耗盡每日特定配額(通常在 500MB 至 2GB 之間)後,就會立即面臨人為設置的硬性頻寬限制。
限速底層架構:PCRF 與 Session AMBR
網絡降級(Deprioritization)會隨基站擁擠度動態浮動,而主動限速(Throttling)則是直接在分組核心網(Packet Core)中執行的硬性軟件速度上限:
- 流量計費監控(Traffic Accounting): 當你傳輸數據時,在線計費系統(Online Charging System, OCS) 會持續統計你已使用的數據量。
- 策略觸發執行(Policy Execution): 一旦用量達到每日上限,策略與計費規則功能單元(PCRF)(在 5G SA 核心網中為 PCF)便會向分組數據網網關(PGW)或用戶面功能(UPF)發送動態策略變更指令。
- 頻寬強行限制(Bandwidth Clamping): 核心網絡會立即更新你的 APN-AMBR(接入點名稱聚合最大比特率)。這會即時將上下載速度鎖定在遠低於正常無線電水平的極限——最常見的是 128kbps 甚至災難級的 64kbps。
為何 128kbps 與 64kbps 會讓現代 App 完全崩潰?
傳統漫遊商經常辯稱 128kbps 已「足夠應付基本文字通訊和緊急瀏覽」。但從現代網絡架構的角度來看,這種說法完全脫離現實。
現代手機 App 已不再傳輸輕量級的純文字,每次通訊都包覆了龐大的加密協議和前端框架:
- TLS/SSL 安全握手失敗: 建立任何安全連線都需要交換加密憑證與公鑰(通常需要 6KB 至 12KB 的握手數據)。在延遲高且被限速在 64kbps 或 128kbps 的漫遊鏈路上,光是完成初始握手就需要數秒。手機作業系統與應用程式設有嚴格的逾時中斷機制(通常為 5 至 10 秒),往往在成功接收到任何實際內容前就已判定連線逾時。
- 向量地圖切片(Vector Tiles)載入停滯: Google Maps 和 Apple Maps 現已全面採用 Mapbox 向量切片(MVT)技術,而非以前預先壓縮的點陣圖。被限速至 128kbps 的連線根本無法及時下載這些向量數據包,導致用戶在導航時地圖呈現一片空白。
- API 頻繁輪詢與憑證過期: 叫車平台(Uber、Grab)及電子錢包(Apple Pay、Google 錢包)需要高頻率發送 API 請求以同步 GPS 定位並驗證交易憑證。在嚴重限速的網絡下,這些請求會被卡死在發送隊列中,頻繁彈出「網絡連線錯誤」的警告。
不同限速等級下的真實應用實測
| 手機應用場景 / 服務 | 64 kbps(極度限速) | 128 kbps(傳統 eSIM 限速標準) | 384 kbps(MollySIM 優化 FUP 底線) |
|---|---|---|---|
| 純文字通訊(WhatsApp、Signal) | 勉強可用(文字有延遲) | 正常使用 | 順暢秒傳 |
| 安全 TLS/SSL 協議握手 | ❌ 經常超時中斷 | ⚠️ 極不穩定(高失敗率) | ✅ 穩定秒開 |
| 地圖導航與向量切片(Google Maps、Waze) | ❌ 完全無法載入 | ❌ 圖磚頻繁超時空白 | ✅ 圖磚載入流暢、路線即時更新 |
| 叫車應用(Uber、Grab、Bolt) | ❌ API 逾時報錯 | ⚠️ 易斷線 / 叫車失敗 | ✅ 正常載入司機位置與叫車 |
| 手機感應支付(Apple Pay / Google 錢包) | ❌ 交易 Token 驗證失敗 | ⚠️ 間歇性授權失敗 | ✅ 即時完成扣款授權 |
| VoIP 語音通話(WhatsApp / FaceTime Audio) | ❌ 嚴重斷音 / 機械人雜音 | ⚠️ 掉包嚴重(15-25% 丟失率) | ✅ 通話清晰(Opus 編碼穩定) |
重塑合理 FUP 架構帶來的真正實用性
能否在限速後維持基礎可用性,核心取決於電訊商如何設定底層策略限制。傳統「無限數據」產品常將用戶困在毫無用處的 64kbps/128kbps 泥沼中,而先進的網絡服務商則會重新調校 PCRF 規則,確保即使高速數據耗盡,關鍵生活工具依然能維持連線。
透過確立 384kbps 的 FUP 最低保障速率,MollySIM 提供了市面標準 3 倍的頻寬。這個 384kbps 的黃金速率能確保 SSL/TLS 憑證秒速交換、向量導航地圖順暢更新,以及流動支付 API 正常運作——確保你在耗盡每日額度時,絕不會在異國街頭陷入完全失聯的困境。
全面剖析:數據限速(Throttling)vs. 網絡降級(Deprioritization)
雖然這兩種情況在手機上的直觀表現都是網絡變慢,但 硬性限速(Hard Throttling) 與 動態降級(Dynamic Deprioritization) 其實發生在流動網絡截然不同的技術層級。
硬性限速是由核心網絡的 PCRF 及 UPF 層級所執行的確定性軟件速度封頂。一旦你的預設高速數據用盡,無論當前基站有多空閒,你的最高傳輸速度都會被強制壓制。
相對地,網絡降級則是動態、暫時性、且由無線接入網(RAN)資源調度所驅動。外遊漫遊 eSIM 的服務等級(QCI 8 或 QCI 9)通常低於當地原生合約用戶(QCI 6 或 7)。當某個基站出現擁擠時,基站排程器會優先將無線電資源區塊(RRB)分配給本地主力用戶,漫遊用戶的封包則會被延後甚至直接丟棄。
| 網絡架構比較維度 | 硬性限速(FUP 額度用盡) | 動態網絡降級(QCI 優先級偏低) |
|---|---|---|
| 主要觸發條件 | 賬戶數據使用量達到計劃上限 | 基站網絡塞車、用戶密度過高、QCI 權重較低 |
| 網絡執行節點 | 核心網絡(PCRF / PGW / UPF 流量整形) | 無線接入網(eNodeB / gNodeB 基站排程器) |
| 傳輸速率表現 | 固定速度上限(如 64kbps、128kbps 或 384kbps) | 波動極大:在高速與接近斷線之間劇烈跳動 |
| 延遲與 RTT 影響 | 基礎 RTT 正常,但因封包排隊導致 App 應用層延遲 | 網絡 RTT 延遲飆升(500ms–2500ms),嚴重緩衝膨脹 |
| 封包丟失率 | 極低(封包僅被延後發送,不會被主動丟棄) | 極高(在無線射頻接口處直接丟棄突發封包) |
| 恢復正常機制 | 續訂計劃、購買加購包或等待每日額度重置 | 離開擁擠區域、更換基站或等待尖峰時段過去 |
受限網絡環境下的應用程式實測基準
為了讓大家了解不同限制對實際旅行的影響,我們針對三種不同狀態進行了主流應用的基準測試:市面常見限速(128kbps)、MollySIM 優化 FUP(384kbps) 以及 嚴重網絡降級(擁擠基站)。
+---------------------------------------------------------------------------------------+
| 應用程式運作表現實測基準 |
+----------------------+--------------------+--------------------+----------------------+
| 測試應用 / 服務 | 128kbps 傳統限速 | 384kbps 優化限速 | 動態網絡降級環境 |
+----------------------+--------------------+--------------------+----------------------+
| Google Maps 向量圖磚 | 需時 18–35 秒載入 | 2–4 秒平滑渲染 | 頻繁出現逾時空白 |
| WhatsApp 語音通話 | 斷斷續續 / 嚴重卡頓 | 清晰(Opus 編碼) | 嚴重抖動 / 機械雜音 |
| Uber 叫車 / API 請求 | 驗證超時 / 叫車失敗 | 快速叫車成功 | 司機定位中斷遺失 |
| 1080p 影片串流播放 | 完全無法播放 (ABR) | 僅有聲音 / 240p | 嚴重卡頓並無限緩衝 |
+----------------------+--------------------+--------------------+----------------------+1. Google Maps 向量導航與路線規劃
- 在 128kbps 硬性限速下: 向量地圖切片(Protobuf 格式)無法同步下載。在地圖上拖動至新區域會出現大片灰色網格,重新規劃路線需要 25 至 40 秒以上,HTTP/2 多路複用鏈路頻繁卡死。
- 在 384kbps 硬性限速下: 每個視窗的向量數據大小約為 20–50KB,MollySIM 的 384kbps 底線能在 1.5 至 3 秒內載入完畢。TLS 保持長連線狀態,自動跳過衛星空照圖圖層,轉向導航流暢更新無卡頓。
- 在動態網絡降級下:
🇯🇵 日本 高速 eSIM & 电话卡方案
无需插卡开箱即用,支持热点共享,即使高速流量用尽也可维持 Google 地图/移动支付顺畅运行。