Ảo giác 5G: Băng thông so với Độ trễ và Lý do sóng căng đét vẫn bị giật lag

Mọi du khách quốc tế đều từng trải qua nghịch lý công nghệ hiện đại này: bạn vừa bước xuống sau chuyến bay dài tại Tokyo, London hay Bangkok, kích hoạt eSIM du lịch và nhìn lên thanh trạng thái điện thoại. Màn hình hiển thị 4 vạch sóng 5G căng đét. Bạn mở Speedtest chạy thử và kim đo vọt lên mức ấn tượng: 120 Mbps tốc độ tải xuống.

Thế nhưng, ngay khi bạn cố gắng đặt xe trên Grab hoặc Uber, xác nhận vé tàu điện hay phê duyệt thông báo xác thực hai yếu tố (2FA) từ ứng dụng ngân hàng, giao diện lại treo cứng với vòng xoay tải trang vô tận.

Vấn đề này bắt nguồn từ sự hiểu lầm căn bản về hiệu năng mạng di động: sự nhầm lẫn giữa cường độ tín hiệu sóng, băng thông với độ trễ mạng (latency).

`` +-----------------------------------------------------------------------------------+ | ẢO GIÁC 5G: Băng thông cao ≠ Tốc độ phản hồi nhanh | | | | [Điện thoại] === Kết nối 5G nội địa (Nhanh: 5ms) ===> [Trạm phát sóng nội địa] | | | | | v (Nút thắt độ trễ) | | [Máy chủ đích] <=== Vòng lặp chuyển vùng 6.000+ dặm === [Mạng lõi Gateway gốc] | +-----------------------------------------------------------------------------------+ ``

Cột sóng so với Băng thông (Throughput) so với Thời gian khứ hồi (RTT)

Để chẩn đoán lý do kết nối mạng có cảm giác ì ạch, chúng ta cần phân tách 3 lớp truyền tải dữ liệu di động chính:

  1. Cường độ tín hiệu (RSRP/RSSI): Các vạch sóng trên điện thoại chỉ đo lường liên kết Tần số Vô tuyến (RF) vật lý giữa thiết bị của bạn và trạm phát sóng di động nội địa gần nhất (gNodeB trên 5G hoặc eNodeB trên 4G LTE). Nó thể hiện điện thoại thu nhận sóng từ trạm tốt ra sao, chứ không phản ánh hạ tầng mạng internet phía sau trạm xử lý dữ liệu nhanh thế nào.
  2. Băng thông / Thông lượng (Throughput / Mbps): Được đo bằng Megabit trên giây (Mbps), đại diện cho dung lượng thể tích của đường ống dữ liệu. Đường truyền 100 Mbps cho phép tải các tập tin liên tục dung lượng lớn — như xem phim 4K trên Netflix — một cách mượt mà sau khi quá trình đệm dữ liệu bắt đầu.
  3. Độ trễ (Ping / Round-Trip Time - RTT): Đo bằng mili-giây (ms), độ trễ là khoảng thời gian vật lý cần thiết để một gói dữ liệu truyền từ smartphone đến máy chủ từ xa và nhận lại phản hồi xác nhận (ACK).
Chỉ sốĐo lường điều gìTác động đến thực tế khi đi du lịch
Băng thông cao, Độ trễ cao (ví dụ: 100 Mbps / ping 650 ms)Đường ống dữ liệu rộng nhưng thời gian phản hồi chậm chạpXem video trực tuyến vẫn tải tốt, nhưng các app tương tác (Uber, Bản đồ, Apple Pay) sẽ bị lỗi hoặc giật lag nghiêm trọng.
Băng thông thấp, Độ trễ thấp (ví dụ: 5 Mbps / ping 35 ms)Đường ống dữ liệu hẹp nhưng phản hồi gần như tức thìTải trang web ngay lập tức, mã 2FA xác thực tức thì và định vị dẫn đường duy trì độ mượt mà liên tục.

Tại sao các ứng dụng tương tác bị lỗi trên đường truyền có độ trễ cao

Các ứng dụng di động hiện đại không gửi một luồng dữ liệu duy nhất liên tục; chúng dựa vào hàng chục lệnh gọi API (API calls) và quy trình bắt tay bảo mật tuần tự, diễn ra chớp nhoáng.

Khi mở ứng dụng gọi xe hoặc điều hướng, điện thoại của bạn sẽ khởi tạo bắt tay mã hóa TLS 1.3, xác thực chứng chỉ bảo mật, gửi tọa độ địa lý, tải các ô bản đồ thời gian thực và truy vấn giá cước động. Nếu mạng có RTT 600ms, một quy trình cần 6 lượt phản hồi qua lại tuần tự sẽ mất gần 4 giây chỉ để đàm phán kết nối — bất kể tốc độ tải xuống của bạn là 10 Mbps hay 500 Mbps.

``` Chuỗi yêu cầu TLS/API tương tác (6 lượt khứ hồi x Độ trễ):

```

Độ trễ cấu trúc này cũng là lý do vì sao chính sách bóp băng thông nghiêm ngặt lại gây ức chế lớn cho du khách. Nhiều nhà cung cấp eSIM du lịch giá rẻ bóp kết nối xuống mức tê liệt 128 kbps khi bạn dùng hết dung lượng tốc độ cao hàng ngày — mức tốc độ sàn kết hợp với ping cao khiến các kết nối HTTPS bị ngắt hoàn toàn do quá thời gian chờ (timeout). Ngược lại, các nhà cung cấp dữ liệu cấp 1 hiện đại như MollySIM duy trì mức sàn Chính sách sử dụng công bằng (FUP) tối ưu ở 384 kbps. Ở mức 384 kbps — gấp ba lần tiêu chuẩn thị trường — các lượt bắt tay mạng thiết yếu cho việc điều hướng trên Google Maps, nhắn tin và xác thực Apple Pay vẫn hoàn thành ổn định ngay cả khi dung lượng tốc độ cao chính đã cạn kiệt.

"Thủ phạm" thực sự: Định tuyến gói tin chuyển vùng quốc tế

Nếu trạm phát sóng 5G nội địa chỉ cách bạn chưa đầy 1 km, tại sao điện thoại của bạn lại phải chịu độ trễ như thời kỳ mạng quay số dial-up?

Điểm nghẽn hiếm khi nằm ở phổ tần không dây nội địa. Thay vào đó, nó nằm ở cách các gói dữ liệu được định tuyến qua các biên giới quốc tế. Khi sử dụng eSIM du lịch thông thường, lưu lượng truy cập của bạn thường bị đẩy vào kiến trúc chuyển vùng viễn thông cũ kỹ, chuyển tiếp yêu cầu đi nửa vòng trái đất trước khi phản hồi ngược lại thiết bị.

Đi sâu vào kỹ thuật: Cách chuyển vùng Home-Routed (HR) tạo ra Ping cao

Instant QR Delivery • Native 5G • 384kbps FUP Protection

🇯🇵 Japan High-Speed Travel eSIM & SIM Plans

Instant QR code activation, hotspot enabled, with guaranteed 384kbps fallback speed to keep Maps & Digital Wallets active.

View Japan Plans & Pricing ➔Rakuten Japan SIM ➔

Để hiểu lý do eSIM du lịch có cảm giác chậm chạp dù đầy sóng, bạn cần xem xét kiến trúc chuyển vùng di động theo tiêu chuẩn 3GPP. Khi bạn sử dụng dữ liệu di động ở nước ngoài, điện thoại sẽ tương tác với hai thực thể viễn thông riêng biệt:

  1. VPLMN (Visited Public Land Mobile Network): Mạng di động nội địa tại điểm đến cung cấp kết nối vô tuyến vật lý (ví dụ: NTT Docomo ở Nhật Bản, Vodafone ở Anh hoặc AT&T ở Mỹ).
  2. HPLMN (Home Public Land Mobile Network): Nhà mạng gốc phát hành hồ sơ IMSI (Định danh thuê bao di động quốc tế) được tích hợp trong eSIM của bạn.

Chuyển vùng định tuyến về nước gốc (Home-Routed - HR) so với Xuất dữ liệu nội địa (Local Breakout - LBO)

Ngành viễn thông dựa vào hai phương thức chính để xử lý lưu lượng thuê bao quốc tế:

Kiến trúc chuyển vùngLuồng dữ liệuĐộ trễ điển hìnhNơi dữ liệu xuất ra Internet
Home-Routed (HR)Thiết bị $\rightarrow$ VPLMN $\rightarrow$ Đường hầm GTP mã hóa $\rightarrow$ Cáp quang biển $\rightarrow$ Mạng lõi HPLMN $\rightarrow$ Internet350ms – 900msQuốc gia gốc của IMSI (ví dụ: Ba Lan, Áo, Hồng Kông)
Local Breakout (LBO)Thiết bị $\rightarrow$ VPLMN $\rightarrow$ Gateway phân vùng nội địa (UPF/PGW) $\rightarrow$ Internet15ms – 60msQuốc gia bạn đang đứng thực tế

`` [Điện thoại của bạn] │ (Sóng 5G nội địa) ▼ [Trạm phát sóng nội địa / VPLMN] │ │ ◄── Đường hầm GTP mã hóa qua cáp quang xuyên đại dương (8.000+ dặm) ▼ [Cổng gói tin HPLMN (PGW/UPF) tại quốc gia xa xôi] │ ▼ [Máy chủ Internet công cộng] ``

Dưới kiến trúc chuyển vùng Home-Routed (HR) tiêu chuẩn — cấu hình mặc định được khoảng 90% đại lý bán lẻ eSIM du lịch giá rẻ sử dụng — mạng khách (VPLMN) không được phép cho gói tin của bạn xuất thẳng ra internet.

Thay vào đó, mọi truy vấn DNS, đồng bộ TCP và bắt tay TLS đều bị đóng gói bên trong một phiên GTP (GPRS Tunneling Protocol). Phiên này được định tuyến qua mạng trao đổi IP (IPX) bán buôn quốc tế và các tuyến cáp quang xuyên biển trở về Packet Data Network Gateway (PGW) (trên 4G LTE) hoặc User Plane Function (UPF) (trên 5G) của nhà mạng gốc. Chỉ sau khi chạm tới cổng gateway tại quê nhà đó, yêu cầu của bạn mới thực sự đi ra internet công cộng.

Tác động trong thực tế: Từ Tokyo đến Warsaw và quay lại

Hãy hình dung một kịch bản phổ biến: bạn hạ cánh tại Sân bay Narita ở Tokyo và kết nối với trạm phát sóng 5G của SoftBank hoặc Docomo bằng một eSIM du lịch thông thường mua trên mạng.

Đằng sau hậu trường, nhà cung cấp eSIM giá rẻ đó có thể đang bán lại IMSI bán buôn từ một nhà mạng ở Ba Lan hoặc Israel để giảm giá vốn. Khi bạn tìm kiếm đường đi tàu điện ngầm ở Shibuya:

  1. Điện thoại gửi yêu cầu đến trạm phát sóng ở Tokyo (~15ms).
  2. Trạm phát sóng Tokyo đóng gói gói tin và định tuyến qua cáp quang ngầm Á - Âu đến PGW ở Warsaw (~230ms).
  3. PGW tại Warsaw truy vấn máy chủ Google, nhận dữ liệu và truyền qua đường hầm xuyên lục địa trở lại Tokyo (~230ms).
  4. Tổng thời gian khứ hồi: 475ms+, chỉ cho một gói tin đơn lẻ chưa nén.

Vì các ứng dụng di động hiện đại thực thi hàng chục lệnh gọi API tuần tự để dựng một giao diện, đường vòng vật lý này biến một thao tác vốn chỉ mất chớp mắt thành vòng xoay chờ đợi 4 đến 6 giây.

`` Tokyo (Vị trí thực tế) ──► Mạng lõi Warsaw (GTP Exit) ──► Máy chủ nội dung Tokyo └────────────────── 9.200 km × 2 = Độ trễ ping cực cao ──────────────────┘ ``

Các triệu chứng phụ: Lệch vị trí địa lý (Geolocation) và Lỗi xác thực bảo mật

Độ trễ cao không phải là tác dụng phụ duy nhất của luồng dữ liệu Home-Routed. Do lưu lượng truy cập kết thúc tại gateway HPLMN, các máy chủ bên ngoài sẽ nhìn thấy địa chỉ IP công cộng của bạn đến từ quốc gia của nhà mạng gốc, chứ không phải nơi bạn đang đứng.

Khi định tuyến trễ cao kết hợp với việc bóp băng thông, kết nối sẽ sập hoàn toàn. Nếu nhà mạng giảm tốc độ xuống 128 kbps qua đường hầm GTP 500ms, tỷ lệ mất gói tin sẽ tăng vọt và quá trình bắt tay HTTPS sẽ bị hủy trước khi hoàn tất.

Đây là lý do tại sao các nhà cung cấp tối ưu như MollySIM thiết kế các cổng xuất dữ liệu (breakout) khu vực độ trễ thấp, đồng thời bảo vệ kết nối bằng mức sàn Chính sách sử dụng công bằng (FUP) 384 kbps ổn định. Ngay cả khi bạn đã dùng hết dung lượng tốc độ cao chính, việc giữ độ trễ thấp và băng thông ở 384 kbps (gấp 3 lần tiêu chuẩn cũ) đảm bảo các dịch vụ thiết yếu, thông báo đẩy và ứng dụng dẫn đường luôn hoạt động bình thường mà không bị timeout.

Hệ lụy thực tế: Độ trễ cao làm tê liệt VoIP, Điều hướng bản đồ và Công việc từ xa như thế nào

Độ trễ cao không chỉ là một con số đơn lẻ trên màn hình đo tốc độ; trong thực tế, nó là nhân tố gây lỗi dây chuyền trên mọi lớp của ngăn xếp mạng hiện đại. Khi Thời gian khứ hồi (RTT) vật lý tăng từ mức tối ưu 30ms lên 600ms do định tuyến GTP xuyên lục địa, trải nghiệm người dùng không chỉ chậm đi theo đường thẳng — nó sụp đổ theo cấp số nhân dưới sức nặng của các giao thức truyền tải tiêu chuẩn.

``` Xuất dữ liệu nội địa chuẩn (RTT thấp): Thiết bị [Tokyo] <--- 35ms ---> PGW nội địa / Máy chủ [Tokyo] Kết quả: Đàm phán TCP/TLS chớp nhoáng, truyền dữ liệu tức thì

Chuyển vùng Home-Routed truyền thống (Đường vòng RTT cao): Thiết bị [Tokyo] <==== 350ms ====> PGW gốc [Châu Âu] <==== 250ms ====> Máy chủ app [Tokyo] Kết quả: RTT gốc 600ms; Bắt tay TCP + TLS mất hơn 1,8 giây trước khi truyền byte đầu tiên ```

Yếu tố nhân bội thời gian bắt tay ở cấp độ giao thức

Mỗi kết nối bảo mật mới đều yêu cầu một chuỗi đàm phán qua lại trước khi dữ liệu ứng dụng có thể truyền đi:

  1. Bắt tay 3 bước TCP (TCP 3-Way Handshake): Yêu cầu trọn vẹn 1 RTT (SYN, SYN-ACK, ACK).
  2. Đàm phán mật mã TLS 1.3: Yêu cầu thêm 1 RTT nữa (ClientHello, ServerHello, Key Exchange). Các phiên bản TLS 1.2 cũ hơn yêu cầu tới 2 RTT.
  3. Yêu cầu đa hợp HTTP/2 hoặc HTTP/3: Yêu cầu thêm các lượt khứ hồi nếu xảy ra hiện tượng nghẽn đầu hàng (head-of-line blocking) hoặc phân mảnh MTU.

Trên kết nối nội địa có ping 30ms, việc thiết lập socket bảo mật chỉ mất khoảng 60ms đến 90ms. Nhưng trên eSIM du lịch bị định tuyến kém với ping nền 550ms, việc thiết lập chính socket bảo mật đó sẽ mất hơn 1,6 đến 2,2 giây trước khi một byte nội dung nào được hiển thị. Nếu xảy ra mất gói tin trên trạm phát sóng bị nghẽn, bộ đếm thời gian truyền lại TCP (RTO) sẽ kích hoạt lùi cấp số nhân, khiến kết nối bị đóng băng nhiều giây.


1. Suy giảm chất lượng cuộc gọi VoIP và Video (WhatsApp, Zoom, FaceTime, Zalo)

Giao tiếp âm thanh và video thời gian thực dựa trên các giao thức UDP như RTP (Real-time Transport Protocol)WebRTC. Không giống như tải tập tin, giọng nói thời gian thực không thể đệm trước vài giây dữ liệu; nó đòi hỏi gói tin phải đến liên tục, chuẩn xác trong khung thời gian khắt khe dưới 150ms (tiêu chuẩn ITU-T G.114).

Chỉ số mạngHiệu năng tối ưuTác động của định tuyến đường vòng (>450ms RTT)
Bộ đệm JitterKhung động 20–50msBộ đệm cạn kiệt; các gói đến muộn bị hủy, gây mất tiếng, đứt chữ
Codec âm thanhOpus / AAC-ELD ở bitrate caoCodec tự hạ xuống bitrate thấp nhất (ví dụ: 6 kbps), gây giọng nói biến dạng "như robot"
Khử tiếng vangHội tụ nhanhBộ khử tiếng vang âm học thất bại do luồng âm thanh phản hồi bị lệch pha
Trạng thái cuộc gọiPhiên ổn địnhTín hiệu heartbeat của SIP/WebSockets bị mất, kích hoạt vòng lặp "Đang kết nối lại..."

Khi ping vọt qua ngưỡng 400ms, nhịp hội thoại sẽ bị phá vỡ. Hai bên vô tình nói đè lên nhau, bộ đệm jitter loại bỏ các gói tin bị trễ, và codec video làm rơi các khung hình chính (keyframes), dẫn đến hiện tượng vỡ hình nghiêm trọng và đứng màn hình.


2. Tải bản đồ trực tiếp và Điều phối xe công nghệ (Google Maps, Uber, Grab)

Các ứng dụng điều hướng hiện đại không tải toàn bộ bản đồ trong một tập tin duy nhất; chúng truyền hàng trăm ô vector nhỏ, các nút mạng lưới giao thông và siêu dữ liệu địa điểm (POI) bất đồng bộ qua nhiều kết nối HTTPS đồng thời.


3. Năng suất làm việc từ xa và Lỗi xác thực doanh nghiệp

Đối với những người đi công tác và kỹ sư làm việc từ xa, RTT cao phá hủy hoàn toàn các luồng công việc cốt lõi:


Giải pháp: Độ trễ thấp kết hợp Băng thông khả dụng thực tế

Khi độ trễ được giữ ở mức thấp thông qua định tuyến khu vực trực tiếp, thông lượng dữ liệu sẽ hoạt động ổn định — ngay cả trong điều kiện tốc độ thấp. Các nhà cung cấp eSIM truyền thống thường bóp băng thông người dùng xuống 128 kbps trên đường truyền có độ trễ cao, gây mất gói tin và làm tê liệt hoàn toàn các dịch vụ quan trọng.

Ngược lại, các dịch vụ tối ưu hiệu năng hiện đại như MollySIM triển khai điểm xuất dữ liệu Edge nội địa kết hợp với mức sàn Chính sách sử dụng công bằng (FUP) 384 kbps. Do 384 kbps cung cấp băng thông gấp 3 lần mức bóp 128 kbps cũ, các dịch vụ thiết yếu như tải bản đồ vector trên Google Maps, xác thực token Apple Pay và gọi điện thoại qua WhatsApp vẫn duy trì đủ băng thông cùng tốc độ phản hồi gói tin nhanh để vận hành trơn tru mà không bị timeout.

Khắc phục sự cố kỹ thuật: 5 bước thực tế để giảm độ trễ eSIM

Nếu bạn đang ở nước ngoài và gặp phải tình trạng tải trang chậm, ứng dụng không phản hồi hoặc ping tăng đột biến, bạn không nhất thiết phải chấp nhận hiệu năng kém đó. Mặc dù khoảng cách vật lý đến gateway quyết định mức sàn của độ trễ, nhưng các cài đặt thiết bị chưa chuẩn, việc chọn sai đối tác chuyển vùng và trễ DNS đệ quy thường cộng thêm hàng trăm mili-giây không cần thiết.

Hãy làm theo quy trình chẩn đoán 5 bước sau để tối ưu hóa ngăn xếp vô tuyến trên máy và loại bỏ các nút thắt độ trễ nhân tạo.


Bước 1: Chọn mạng thủ công (PLMN) để ép kết nối đối tác Tier-1

Hầu hết cấu hình eSIM du lịch đều để chế độ Chọn mạng tự động (Automatic Network Selection), vốn hoạt động dựa trên thuật toán Định tuyến chi phí thấp nhất (Least-Cost Routing - LCR). Thay vì kết nối bạn đến trạm phát sóng nhanh nhất, thiết bị có thể bị khóa vào một nhà mạng đối tác hạng dưới chỉ vì họ cung cấp giá dữ liệu bán buôn rẻ nhất cho bên trung gian.

Bằng cách chọn thủ công một nhà mạng quốc gia cấp 1 (Tier-1) tại địa phương (ví dụ: SoftBank hoặc NTT Docomo ở Nhật Bản; EE ở Anh; Telstra ở Úc; Viettel/Vinaphone ở Việt Nam), bạn sẽ lập tức nhận được quyền ưu tiên vô tuyến cao hơn, dung lượng đường truyền tốt hơn và kết nối peering vượt trội.

`` ┌─────────────────────────────────────────────────────────────┐ │ Quy trình chọn mạng thủ công │ │ │ │ iOS: Cài đặt ➔ Mạng di động ➔ [Chọn eSIM] │ │ ➔ Lựa chọn mạng ➔ Tắt "Tự động" │ │ ➔ Chờ 30-60 giây ➔ Chọn nhà mạng Tier-1 thủ công │ │ │ │ Android: Cài đặt ➔ Mạng & Internet ➔ SIM ➔ [Chọn eSIM] │ │ ➔ Tự động chọn mạng (Tắt) │ │ ➔ Chọn nhà mạng Tier-1 từ danh sách quét được │ └─────────────────────────────────────────────────────────────┘ ``


Bước 2: Kiểm tra thông số APN và Kích hoạt Dual-Stack IPv4/IPv6

Tên điểm truy cập (APN) bị sai hoặc dùng loại mặc định sẽ ép lưu lượng di động đi qua các proxy đóng gói thứ cấp, làm tăng ping của bạn. Hơn nữa, việc chạy ngăn xếp chỉ có IPv4 lỗi thời sẽ tạo thêm độ trễ do Carrier-Grade NAT (CGNAT), trong khi ngăn xếp chỉ có IPv6 cấu hình kém sẽ gây ra việc chuyển đổi giao thức 464XLAT liên tục.

  1. Truy cập vào cài đặt Tên điểm truy cập (APN) trên cấu hình mạng di động của bạn.
  2. Xác nhận trường APN khớp chính xác với thông số hiện tại từ nhà cung cấp (ví dụ: dùng tên máy chủ riêng thay vì các chuỗi mặc định).
  3. Nếu dùng Android, hãy đặt cả Giao thức APN (APN protocol)Giao thức chuyển vùng APN (APN roaming protocol) thành IPv4/IPv6. Thao tác này kích hoạt định danh dual-stack gốc, bỏ qua các gateway biên dịch của nhà mạng.

Bước 3: Thay thế DNS chậm của nhà mạng bằng DNS Anycast mã hóa

Khi chuyển vùng, nhiều nhà mạng di động sẽ điều hướng các truy vấn tên miền của bạn đến các máy chủ DNS đệ quy có độ trễ cao đặt tại thị trường gốc của họ. Điều này đồng nghĩa với việc mỗi lần bắt tay HTTP/3 và TLS đều phải đợi hơn 300ms cho việc phân giải DNS khứ hồi trước khi quá trình truyền dữ liệu thực sự bắt đầu.

Bằng cách ghi đè DNS hệ thống bằng một dịch vụ DNS Anycast mã hóa — chẳng hạn như Cloudflare (1.1.1.1) hoặc Google (8.8.8.8) qua DNS-over-HTTPS (DoH) hoặc DNS-over-TLS (DoT) — các truy vấn tên miền của bạn sẽ được xử lý tại máy chủ Edge gần nhất chỉ dưới 15ms.

Hệ điều hànhĐường dẫn cấu hình khuyến nghịMáy chủ đích / IP
Android (10+)Cài đặt ➔ Mạng & Internet ➔ DNS riêng tư (Private DNS)1dot1dot1dot1.cloudflare-dns.com hoặc dns.google
iOS (14+)Cài đặt cấu hình DoH/DoT đã xác minh hoặc dùng App 1.1.1.1Engine mã hóa Cloudflare / Quad9 gốc

Bước 4: Bật/Tắt chế độ máy bay để tái tạo ngữ cảnh PDP mới

Modem di

Instant QR Delivery • Native 5G • 384kbps FUP Protection

🇯🇵 Japan High-Speed Travel eSIM & SIM Plans

Instant QR code activation, hotspot enabled, with guaranteed 384kbps fallback speed to keep Maps & Digital Wallets active.

View Japan Plans & Pricing ➔Rakuten Japan SIM ➔