จาก MRT ใต้ดินสู่สังคมไร้เงินสด: คู่มือ eSIM การเดินทางและการชำระเงินดิจิทัลในสิงคโปร์ (2026)

ฟิสิกส์ของเครือข่ายใต้พิภพ: เจาะลึกโครงสร้างพื้นฐาน MRT ใต้ดินระดับลึกของสิงคโปร์

โครงข่ายรถไฟฟ้า Mass Rapid Transit (MRT) ของสิงคโปร์ถือเป็นหนึ่งในสิ่งมหัศจรรย์ทางวิศวกรรมโยธา แต่ในทางกลับกัน มันคือสภาพแวดล้อมที่โหดร้ายอย่างยิ่งสำหรับคลื่นความถี่วิทยุ (RF) เมื่อโครงข่ายขยายตัว เส้นทางรางรถไฟก็ยิ่งดำดิ่งลึกลงไปใต้พื้นผิวดินเขตร้อน โดย สาย Downtown Line (DTL) มีสถานีอย่าง Bencoolen ที่อยู่ลึกใต้ดินถึง 43 เมตร ในขณะที่ สาย Thomson-East Coast Line (TEL) ซึ่งปัจจุบันเปิดให้บริการครอบคลุมส่วนต่อขยายเฟส 4 และ 5 ตลอดแนวชายฝั่งตะวันออก และ สาย North East Line (NEL) ล้วนลำเลียงผู้โดยสารในระดับความลึก 30 ถึง 45 เมตร ใต้ชั้นหินแข็ง ดินเหนียวใต้ทะเล (Marine Clay) และท่อส่งน้ำทะเลหนาทึบ

ณ ระดับความลึกเหล่านี้ เสาสัญญาณมหภาคระดับพื้นดิน (eNodeB/gNodeB) ทั่วไปที่ทำงานบนคลื่น 900MHz (B8) หรือ 3.5GHz (n78) ไม่สามารถทะลุทะลวงโครงสร้างคอนกรีตเสริมเหล็กที่หนาราวกับบังเกอร์ได้ การรักษาการเชื่อมต่อ 5G และ 4G ให้ต่อเนื่องจึงจำเป็นต้องอาศัยระบบนิเวศโทรคมนาคมใต้ดินแบบ Multi-Operator โดยเฉพาะ

สถาปัตยกรรมคลื่นวิทยุใต้ดิน: DAS, Leaky Feeders และระบบ Neutral Host

เพื่อให้ครอบคลุมสัญญาณระดับกิกะบิตอย่างต่อเนื่องในพื้นที่ใต้ดิน องค์การขนส่งทางบกสิงคโปร์ (LTA) ได้กำหนดให้ผู้ให้บริการเครือข่ายมือถือหลัก (Singtel, StarHub และ M1) ใช้โครงสร้างพื้นฐานร่วมกัน (Shared Infrastructure)

1. ระบบสายอากาศแบบกระจายศูนย์ (Distributed Antenna Systems - DAS): ภายในโถงจำหน่ายตั๋วและชานชาลาหลายระดับ จะมีการติดตั้งเสาอากาศ DAS แบบรอบทิศทางและแบบแผง เพื่อกระจายกำลังส่ง RF จากห้องควบคุมอุปกรณ์ใต้ดิน ป้องกันปัญหาจุดอับสัญญาณรอบเสาค้ำยันขนาดใหญ่และช่องบันไดเลื่อน
2. ระบบสายเคเบิลรั่วกระจายสัญญาณ (Leaky Feeder Coaxial Cable): ภายในอุโมงค์ระหว่างสถานี เสาอากาศแบบจุดทั่วไปจะใช้การไม่ได้เนื่องจากความโค้งของอุโมงค์และการบดบังของขบวนรถ วิศวกรจึงขึงสาย Leaky Feeder ตลอดแนวผนังอุโมงค์ สายโคแอกเชียลชนิดพิเศษนี้มีร่องที่เจาะไว้เฉพาะบนปลอกหุ้มด้านนอก เพื่อแพร่กระจายสนามคลื่น RF เข้าสู่ตู้โดยสารอย่างต่อเนื่องแม้ขบวนรถจะวิ่งด้วยความเร็วสูงถึง 80 กม./ชม.
3. สถานีฐานรับส่งสัญญาณใต้ดิน (Subterranean BTS): สายเคเบิลใยแก้วนำแสงความจุสูงจะเชื่อมต่อระบบกระจายคลื่นเหล่านี้เข้ากับยูนิต BTS ใต้ดินโดยตรง ซึ่งช่วยกำจัดการสูญเสียสัญญาณจากการเดินสายเคเบิลแนวดิ่งระยะไกล

คอขวดของการสลับสัญญาณ (Handover): เหตุใดโปรไฟล์โรมมิ่งจึงเกิด Packet Loss สูง

แม้จะมีโครงสร้างพื้นฐานล้ำสมัย แต่นักเดินทางต่างชาติมักประสบปัญหาค่า Latency พุ่งสูง แอปจ่ายเงินค้าง หรือสัญญาณขาดหายชั่วขณะระหว่างนั่งรถไฟ MRT สิ่งนี้เกิดขึ้นที่ระดับ Network Protocol ในระหว่างการสลับเสาสัญญาณอย่างรวดเร็ว (Cell Handover)

เมื่อขบวนรถ MRT เคลื่อนตัวออกจากชานชาลาใต้ดินเข้าสู่อุโมงค์ อุปกรณ์ของผู้ใช้ (UE) จะต้องทำการ Handover สลับสัญญาณระหว่าง DAS ของสถานีไปยังสาย Leaky Feeder ของอุโมงค์ทันที หากข้อมูลของคุณถูกส่งผ่านระบบโรมมิ่งระหว่างประเทศแบบมาตรฐาน ซึ่งทุกแพ็กเก็ตข้อมูลต้องเดินทางไกลหลายพันกิโลเมตรกลับไปยังเกตเวย์ประเทศต้นทาง (เช่น ยุโรป อเมริกา หรือออสเตรเลีย) ก่อนจะวนกลับมายังเซิร์ฟเวอร์ในสิงคโปร์ ค่าเวลาหน่วงไปกลับ (Round-Trip Time - RTT) จะพุ่งสูงขึ้นมหาศาล

ในสภาวะที่ค่า RTT สูง การสลับสัญญาณอย่างรวดเร็วจะทำให้เกิด Packet Loss และเกิดภาวะ TCP Retransmission Timeout สำหรับผู้โดยสาร ความล่าช้าทางเทคนิคนี้จะส่งผลโดยตรงต่อการใช้งานจริง: ประตูอัตโนมัติแตะจ่ายเงินไม่ผ่านเพราะกระเป๋าเงินดิจิทัลต้องพึ่งพาการยืนยันตัวตนออนไลน์ หรือแอปนำทางสูญเสียพิกัดแบบเรียลไทม์ระหว่างสถานี

การรักษาการส่งข้อมูลชำระเงินและระบบนำทางใต้ดินให้เสถียร

หากคุณใช้ดาต้าจนติดเพดานนโยบายการใช้งานอย่างเป็นธรรม (FUP) บน eSIM ท่องเที่ยวทั่วไป ความเร็วจะถูกบีบลงเหลือเพียง 64kbps หรือ 128kbps ในสภาพแวดล้อมใต้ดินที่มีปัญหา Jitter จากการสลับสัญญาณอยู่แล้ว แบนด์วิธระดับ 128kbps จะทำให้ Apple Pay, Google Wallet และ Google Maps ล้มเหลวโดยสิ้นเชิงเนื่องจากเกิด SSL Handshake Timeout

เพื่อรับมือกับการลดทอนของสัญญาณใต้ดิน โซลูชันเทคโนโลยีการเดินทางอย่าง MollySIM จึงได้นำระบบ Local Breakout Nodes มาใช้ พร้อมกำหนด ความเร็วขั้นต่ำหลังติด FUP ไว้ที่ 384kbps ซึ่งเร็วกว่าคู่แข่งรุ่นเก่าถึง 3 เท่า แบนด์วิธสำรองนี้เพียงพอต่อการตรวจสอบความถูกต้องของการเข้ารหัสโทเค็นชำระเงินแบบไร้สัมผัส และช่วยให้ระบบนำทางแบบสดทำงานต่อไปได้ ทำให้คุณไม่ติดอยู่ที่ประตูกั้นรถไฟใต้ดินลึก 40 เมตรอย่างแน่นอน

ประตูกั้นไร้สัมผัสและกระเป๋าเงินดิจิทัลแบบเรียลไทม์: ความต้องการ Latency สำหรับ Apple Pay, SimplyGo และ SGQR

สิงคโปร์มีระบบขนส่งสาธารณะแบบ Open-Loop และโครงสร้างการชำระเงินย่อย (Micropayment) ที่เชื่อมโยงกันอย่างสมบูรณ์แบบที่สุดแห่งหนึ่งในโลก การใช้งานระบบนี้ได้อย่างราบรื่นจำเป็นต้องเข้าใจความแตกต่างทางเทคนิคระหว่างการแตะผ่าน NFC แบบพาสซีฟ กับการทำธุรกรรมดิจิทัลแบบแอกทีฟที่ต้องพึ่งพาเครือข่าย ในขณะที่บัตรเครดิตไร้สัมผัสแบบกายภาพจะประมวลผลค่าโดยสาร MRT ได้ในระดับมิลลิวินาทีผ่านกลไกออฟไลน์ ณ จุดแตะบัตร แต่กระเป๋าเงินดิจิทัลสมัยใหม่และการโอนเงินชำระค่าสินค้าแบบ Peer-to-Peer (P2P) จำเป็นต้องมีสัญญาณดาต้าที่แข็งแกร่งเพื่อป้องกันความล้มเหลวในการทำธุรกรรม

+---------------------------------------------------------------------------------------+
|                       ภาพรวมระบบการชำระเงินดิจิทัลของสิงคโปร์                           |
+---------------------------------------------------------------------------------------+
| รวดเร็ว (ออฟไลน์ / ใช้ Local NFC Token)    | ช้ากว่า (ใช้เน็ตมือถือเต็มรูปแบบ / มี Handshake) |
| Apple Pay Express Transit / SimplyGo  | SGQR ทั่วไป / PayNow / เติมเงินผ่าน 3DS ในแอป   |
| ข้อกำหนด Latency: <300ms บน NFC ภายในเครื่อง | ข้อกำหนด Latency: <80ms RTT ผ่าน 4G/5G          |
| หน้าที่ของเน็ต: รีเฟรชและซิงค์ Token         | หน้าที่ของเน็ต: TLS Handshake สด & เครือข่าย FAST|
+---------------------------------------------------------------------------------------+

SimplyGo ปะทะ Express Transit: การยืนยันสิทธิ์ล่วงหน้าแบบออฟไลน์ เทียบกับ การตรวจสอบแบบไดนามิก

ระบบ SimplyGo ขององค์การขนส่งทางบกสิงคโปร์ (LTA) ช่วยให้ผู้โดยสารสามารถแตะเข้า-ออกประตูกั้น MRT และรถประจำทางได้โดยใช้บัตรเครดิต/เดบิตแบบไร้สัมผัส EMV, Apple Pay หรือ Google Wallet โดยไม่ต้องซื้อบัตร EZ-Link แยก

1. บัตรจริงและ Apple Pay Express Mode (Offline ODA): เมื่อใช้ Apple Pay ที่ตั้งค่า Express Transit การทำธุรกรรมจะใช้กลไก Offline Data Authentication (ODA) โดย Secure Element ในอุปกรณ์จะลงลายมือชื่อดิจิทัลที่ขั้วประตูกั้นภายใน 300 มิลลิวินาที จึงไม่จำเป็นต้องใช้สัญญาณเน็ตมือถือในเสี้ยววินาทีที่แตะ
2. การจัดเตรียม Device Token และการซิงค์สถานะ: กระเป๋าเงินดิจิทัลไม่สามารถออฟไลน์ได้ตลอดไป ระบบ Host Card Emulation (HCE) บน Android และการอัปเดตโทเค็นความปลอดภัยบน iOS จำเป็นต้องสื่อสารกับเซิร์ฟเวอร์ของผู้ออกบัตรอย่างสม่ำเสมอด้วย Latency ต่ำ หากอุปกรณ์ออฟไลน์ไประหว่างการเดินทางใต้ดินที่ยาวนาน หรือติดปัญหา Latency จากการโรมมิ่ง การหมุนเวียนโทเค็นอาจค้าง ส่งผลให้ขึ้นไฟแดงและเตือน "Card Not Accepted" ที่ประตูกั้นได้
3. การจัดการบัญชีในแอป: การเช็กรายละเอียดค่าโดยสาร การตั้งค่าเติมเงินอัตโนมัติ หรือการดูประวัติการเดินทางในแอป SimplyGo จำเป็นต้องมีการตรวจสอบผ่านคลาวด์ทันทีบนซ็อกเก็ต HTTPS ที่มี Latency ต่ำ

SGQR, PayNow และการสแกนจ่ายในศูนย์อาหารฮอว์เกอร์

ศูนย์อาหารและร้านค้าปลีกในสิงคโปร์ ตั้งแต่ Maxwell Food Centre ไปจนถึงร้านค้าตามสถานี MRT ล้วนพึ่งพาระบบ Singapore Quick Response Code (SGQR) ซึ่งรวมช่องทางการชำระเงินหลายรูปแบบ (PayNow, GrabPay, NETS, LiquidPay) ไว้ในคิวอาร์โค้ดเดียวตามมาตรฐาน EMVCo

การชำระเงินผ่าน SGQR คือธุรกรรมออนไลน์แบบสองทางที่เกิดขึ้นแบบสด:

• การเจรจา Real-Time TLS: การสแกน SGQR จะบังคับให้แอปธนาคารหรือกระเป๋าเงินดิจิทัล (เช่น Grab, DBS PayLah!, OCBC Digital) สร้าง Mutual TLS (mTLS) Handshake กับเกตเวย์การชำระเงิน เพื่อค้นหารูปแบบการชำระเงิน และส่งคำขอไปยังศูนย์หักบัญชี FAST (Fast And Secure Transfers)
• การยืนยันตัวตนชีวภาพ 3D-Secure (3DS 2.2+): การเติมเงินเข้ากระเป๋าเงินดิจิทัลเพื่อจ่ายค่าเดินทางจะทริกเกอร์หน้าต่างยืนยันตัวตนของธนาคาร หากอินเทอร์เน็ตมือถือมี Packet Loss หรือค่า RTT สูง เฟรมยืนยันตัวตนของธนาคารจะเกิด Timeout และทำให้เซสชันถูกระงับ

ความต้องการ Latency ของระบบการชำระเงินในสิงคโปร์

ตารางด้านล่างแสดงตัวชี้วัดประสิทธิภาพเครือข่ายที่จำเป็นสำหรับการชำระเงินรูปแบบต่างๆ ในสิงคโปร์โดยไม่เจอปัญหาเกตเวย์หลุด:

ผลกระทบเมื่อค่า Ping พุ่งสูง (>150ms) ในช่วงเวลาเร่งด่วน

ในช่วงเวลาเร่งด่วนเช้าและเย็นตามสถานีเปลี่ยนสายสำคัญ เช่น Jurong East, Raffles Place และ Orchard เสาสัญญาณเซลลูลาร์ต้องรองรับการสลับสัญญาณของผู้ใช้หลายหมื่นคนพร้อมกัน หากซิมต่างประเทศเราต์ทราฟฟิกกลับไปยังเกตเวย์ประเทศต้นทาง ค่า Ping เริ่มต้นจะพุ่งจาก 20ms ไปเป็นกว่า 250ms

ภายใต้เงื่อนไขเหล่านี้ จะเกิด Timeout ขั้นวิกฤต:

• ปัญหา TCP Retransmission ต่อเนื่อง: ในศูนย์อาหารฮอว์เกอร์ที่แออัด การสแกน SGQR ผ่านเน็ตที่มี Latency สูงจะทำให้เกิดการส่ง TCP SYN ซ้ำๆ ส่งผลให้เกตเวย์ตัดการเชื่อมต่อหลังหน้าจอหมุนค้างนาน 30 วินาที
• ประตูกั้นค้าง: หากกระเป๋าเงิน Android จำเป็นต้องดึงโทเค็นใหม่ผ่านการเชื่อมต่อที่ไม่เสถียรในจังหวะที่คุณเดินถึงประตูกั้น ค่า Ping ที่สูงจะทำให้ผู้โดยสารเดินสะดุดและเกิดแถวสะสมทันที

การแก้ปัญหาเหล่านี้ต้องอาศัยการรักษา Latency ให้อยู่ในระดับต่ำ การเลือกใช้บริการเชื่อมต่อประสิทธิภาพสูงอย่าง MollySIM ซึ่งมี Edge Routing ผ่านโหนด Local Breakout ในพื้นที่ จะช่วยลดปัญหา Jitter ได้อย่างสมบูรณ์ อีกทั้ง MollySIM ยังมี เพดาน FUP ขั้นต่ำ 384kbps ซึ่งสูงกว่ามาตรฐานทั่วไป 128kbps ถึงสามเท่า ช่วยให้มั่นใจได้ว่าการตรวจสอบโทเค็นแบบไดนามิก การยืนยัน 3DS และข้อมูล SGQR API จะผ่านฉลุยโดยไม่ทำให้คุณติดค้างที่หน้าประตู

เปรียบเทียบโครงสร้างพื้นฐานโทรคมนาคมสิงคโปร์: Singtel, StarHub, M1 และปัญหาคอขวดของทราฟฟิกโรมมิ่ง

การเชื่อมต่อใต้ดินของสิงคโปร์ต้องพึ่งพาระบบ Distributed Antenna System (DAS) ขั้นสูงที่ติดตั้งตลอดแนวรถไฟฟ้า MRT สายลึก เช่น Thomson-East Coast Line (TEL) และ Downtown Line (DTL) ซึ่งอยู่ลึกถึง 43 เมตรใต้ระดับน้ำทะเล แม้ว่าโครงสร้างพื้นฐานทางกายภาพจะบริหารจัดการโดยค่ายมือถือยักษ์ใหญ่ 3 ราย คือ Singtel, StarHub และ M1 แต่ประสิทธิภาพการใช้งานจริงของอุปกรณ์จะขึ้นอยู่กับเส้นทาง Core Routing ที่ตั้งค่าผ่าน Access Point Name (APN) ของซิมการ์ดเป็นหลัก

ตารางด้านล่างเปรียบเทียบโครงสร้างเครือข่าย Tier-1 ของสิงคโปร์กับโปรไฟล์โรมมิ่งทั่วไป พ็อกเก็ตไวไฟ และโซลูชันที่ปรับแต่งมาเป็นพิเศษ:

กลไกของปัญหาคอขวด "Roaming Trombone"

สาเหตุหลักที่ทำให้การชำระเงินผ่านมือถือใต้ดินล้มเหลวไม่ใช่เครือข่ายรับส่งสัญญาณวิทยุของสิงคโปร์ แต่เกิดจาก ปรากฏการณ์ Roaming Trombone (หรือ Packet Hairpinning)

เมื่อคุณเริ่มโอนเงินผ่าน SGQR หรือเดินผ่านประตูกั้น MRT โดยใช้ eSIM ท่องเที่ยวทั่วไป แพ็กเก็ตดาต้าของคุณต้องสร้างเซสชัน Transport Layer Security (TLS 1.3) ที่ปลอดภัยไปยังปลายทางของธนาคารในสิงคโปร์ (เช่น NETS, DBS PayLah! หรือระบบหลังบ้าน SimplyGo ของ LTA)

หาก eSIM ใช้ APN แบบ Home Routed (HR) ราคาประหยัดที่มีเซิร์ฟเวอร์อยู่ในยุโรปหรืออเมริกาเหนือ เส้นทางข้อมูลจะอ้อมโลกในลักษณะนี้:

1. ส่งสัญญาณขึ้น (Uplink): สมาร์ตโฟนเชื่อมต่อไปยัง Small Cell ใต้ดินของ Singtel หรือ StarHub ภายในอุโมงค์
2. ส่งผ่านสายเคเบิลใต้น้ำ: เกตเวย์ท้องถิ่นส่งต่อแพ็กเก็ต IP ข้ามทวีปผ่านสายเคเบิลใต้น้ำไปยัง Packet Data Network Gateway (P-GW) ที่ลอนดอน แฟรงก์เฟิร์ต หรือฮ่องกง
3. ส่งวนกลับมายังปลายทาง (Downlink Hairpin): หลังตรวจสอบสิทธิ์และจ่าย IP ที่คอร์เครือข่ายต้นทางแล้ว ข้อมูลจะถูกส่ง วนกลับมา ยังศูนย์แลกเปลี่ยนอินเทอร์เน็ตในสิงคโปร์เพื่อไปยังเครื่องรับชำระเงินของร้านค้า

การเดินทางอ้อมระยะทางกว่า 20,000 กิโลเมตรนี้ทำให้ค่า Round-Trip Time (RTT) พื้นฐานพุ่งจาก 15ms ไปแตะกว่า 300ms ในช่วงเวลาเร่งด่วนของ MRT ซึ่งสัญญาณ RF มีความผันผวนจากปรากฏการณ์ด็อปเปลอร์ (Doppler Shift) และการลดทอนของตู้รถไฟโลหะ ค่า RTT ที่สูงจะทำให้เกิดปัญหา TCP Window Starvation การทำ Handshake หลุด และระบบตัดการชำระเงินของร้านค้าทันที

การรักษาประสิทธิภาพการทำธุรกรรมเมื่อติด FUP

การใช้เน็ตความเร็วสูงจนหมดเป็นอีกหนึ่งคอขวดสำคัญ ผู้ให้บริการ eSIM ท่องเที่ยวทั่วไปส่วนใหญ่มักบังคับใช้ Fair Usage Policy (FUP) ที่จำกัดความเร็วเหลือเพียง 128kbps เมื่อใช้โควตาเน็ตความเร็วสูงรายวันหมด ที่ความเร็ว 128kbps แบนด์วิธทั้งหมดจะถูกกระบวนการเบื้องหลังของระบบปฏิบัติการและการซิงค์ข้อมูลดูดไปจนหมด ทำให้ไม่เหลือช่องสัญญาณสำหรับการแลกเปลี่ยนโทเค็นความปลอดภัยของกระเป๋าเงินดิจิทัล

ในทางตรงกันข้าม MollySIM มอบ ความเร็ว FUP ขั้นต่ำที่ 384kbps ซึ่งเร็วกว่ามาตรฐานอุตสาหกรรมถึง 3 เท่า ควบคู่ไปกับระบบ Regional Edge Breakout ที่มี Latency ต่ำ แบนด์วิธขั้นต่ำนี้รับประกันได้ว่ามีช่องสัญญาณเพียงพอสำหรับการโหลดแผนที่แบบเวกเตอร์ใน Google Maps ต่อเนื่องในพื้นหลัง การสร้างการยืนยันตัวตน 3D Secure (3DS) แบบไร้ความล่าช้า และการยืนยันสิทธิ์ด้วยไบโอเมตริกซ์ที่ประตูกั้นได้อย่างทันที โดยไม่ต้องกดซื้อแพ็กเกจเน็ตเสริม

ข้อได้เปรียบทางวิศวกรรมของ MollySIM: การเชื่อมต่อระดับ Tier-1 และการรับประกัน FUP 384kbps

เพื่อขจัดปัญหาเน็ตสะดุดใต้ดินและแอปชำระเงินค้าง โครงสร้างเครือข่ายต้องไม่พึ่งพาตัวแทนรวบรวมสัญญาณระดับรองหรือท่อส่งโรมมิ่งที่มี Latency สูง MollySIM ออกแบบการเชื่อมต่อในสิงคโปร์ผ่านโปรไฟล์ Localized Edge Breakout (LBO) ที่เชื่อมต่อโครงข่ายโดยตรงกับผู้ให้บริการ Tier-1 ชั้นนำของสิงคโปร์อย่าง Singtel และ StarHub

ด้วยการยืนยันตัวตนผู้ใช้ผ่าน Packet Gateways (P-GW/UPF) ที่ติดตั้งร่วมอยู่ ณ ศูนย์แลกเปลี่ยนอินเทอร์เน็ตสิงคโปร์ (SGIX) ค่า Latency ไปกลับจึงลดลงเหลือเพียงตัวเลขหลักเดียว (5ms ถึง 18ms) โปรไฟล์ที่ไร้อาการ Jitter นี้ยังคงเสถียรแม้จะอยู่ลึกลงไปในอุโมงค์ใต้ดินของสาย Downtown Line (DTL) และ Thomson-East Coast Line (TEL) ซึ่งความเร็วของขบวนรถและการสลับเสาสัญญาณอย่างหนาแน่นมักทำให้ซิมโรมมิ่งทั่วไปหลุดการเชื่อมต่อ

เจาะลึกการบีบความเร็วเน็ต: ทำไม 128kbps จึงทำให้ระบบการเดินทางล้มเหลว

ผู้ให้บริการ eSIM ท่องเที่ยวส่วนใหญ่โฆษณาว่า "เน็ตไม่อั้น" แต่ซ่อนเงื่อนไขจำกัดความเร็วด้วยนโยบายการใช้งานอย่างเป็นธรรม (FUP) เหลือเพียง 64kbps หรือ 128kbps เมื่อใช้โควตารายวันหมด

ในเมืองอัจฉริยะ ความเร็ว 128kbps แทบไม่ต่างอะไรกับการไม่มีสัญญาณ สมาร์ตโฟนยุคใหม่มีการรันระบบเบื้องหลังตลอดเวลา ไม่ว่าจะเป็น Apple Push Notification (APNs), Google Firebase Cloud Messaging (FCM), การซิงค์ iCloud/Google Drive และการรีเฟรชแอปเบื้องหลัง ซึ่งกระบวนการเหล่านี้กินแบนด์วิธคงที่ไปแล้ว 40kbps ถึง 70kbps

เมื่อถูกบีบความเร็วเหลือ 128kbps:

• แบนด์วิธที่เหลือสำหรับการใช้งานจริง: $\approx 58\text{ kbps } (\approx 7.25\text{ KB/s})$
• ขนาดข้อมูลการยืนยันตัวตน 3DS 2.0: $\approx 45\text{ KB}$ (ใบรับรองความปลอดภัย, Cryptographic Nonce, สคริปต์ iframe)
• เวลาที่ต้องใช้ประมวลผลที่ 128kbps: $>6.2\text{ วินาที}$ (เกินเกณฑ์ Timeout ของเกตเวย์ร้านค้า ส่งผลให้การชำระเงินถูกปฏิเสธ)
• การโหลดบล็อกแผนที่เวกเตอร์ (Google Maps): $\approx 120\text{ KB}$ ต่อบล็อก $\rightarrow$ ต้องใช้เวลากว่า $16.5\text{ วินาที}$ ทำให้แผนที่กลายเป็นตารางสีเทาว่างเปล่าขณะกำลังเดินออกจากสถานี MRT

บรรทัดฐานทางวิศวกรรม 384kbps: ประสิทธิภาพที่คำนวณได้จริง

MollySIM กำหนด ความเร็ว FUP ขั้นต่ำไว้ที่ 384kbps ซึ่งเร็วกว่ามาตรฐานทั่วไป 128kbps ถึง 3 เท่า ที่ความเร็ว 384kbps หลังจากหักลบการทำงานพื้นหลังของระบบปฏิบัติการแล้ว อุปกรณ์ของคุณจะยังคงมีแบนด์วิธสำหรับการส่งข้อมูลจริงอยู่ที่ ~314kbps (~39.25 KB/s)

┌────────────────────────────────────────────────────────────────────────┐
│ ความเร็ว FUP ขั้นต่ำของ MollySIM รวม 384kbps                           │
├───────────────────────────────┬────────────────────────────────────────┤
│ ทราฟฟิกเบื้องหลังของระบบปฏิบัติการ  │ แบนด์วิ