การสร้าง CPID

GTAF ใช้คีย์ผู้ใช้เพื่อระบุผู้สมัครใช้บริการเมื่อสื่อสารกับ DPA แอปพลิเคชันที่มีสิทธิ์เข้าถึง MSISDN ของผู้ใช้สามารถใช้เป็น user_key ได้ ในทางกลับกัน แอปพลิเคชันที่ไม่มีสิทธิ์เข้าถึง MSISDN จะต้องสร้างตัวระบุแพ็กเกจผู้ให้บริการ (CPID) โดยไม่ต้องค้นหา MSISDN ของผู้ใช้ เราจะอธิบายกลไกที่สร้าง CPID ดังต่อไปนี้

ขั้นตอนการเรียก CPID

รูปที่ 2: โฟลว์การโทรเพื่อสร้าง CPID

1. แอปพลิเคชันของ Google ใน UE ใช้ API ภายในของ Google เพื่อดึง URL ของปลายทาง CPID จาก GTAF ผู้ให้บริการจะระบุที่อยู่ IP สาธารณะและ MCC+MNC ของซิมการ์ดที่ใช้งานอยู่ของลูกค้า ในกรณีของ MVNO นั้น Google จะใช้ SPN และ GID1 เพื่อกําหนด MVNO
2. ไคลเอ็นต์จะออกคําขอ HTTP GET ไปยังปลายทาง CPID โอเปอเรเตอร์อาจ ส่งคําขอผ่าน HTTPS
3. โอเปอเรเตอร์ MAY จะใช้ฟังก์ชันการตรวจสอบแพ็กเก็ตโดยละเอียดเพื่อระบุคําขอ และแทรกหมายเลขโทรศัพท์ของผู้ใช้เป็นคําขอเป็นส่วนหัว HTTP
4. ปลายทาง CPID ได้รับคําขอ สร้าง CPID และแสดงผล CPID ไปยัง UE พร้อม Time to Live (TTL) ซึ่งระบุระยะเวลาที่ UE สามารถใช้ CPID นี้ได้

นอกจากนี้ โอเปอเรเตอร์ MAY ยังใช้ที่อยู่ IP แทนชื่อโดเมนใน URL ปลายทาง CPID ในกรณีที่เลือกใช้ได้ ที่อยู่ IP อาจอยู่ในพื้นที่ส่วนตัว แต่ลูกค้า Google ต้องติดต่อภายในเครือข่ายของผู้ให้บริการได้

โอเปอเรเตอร์ SHALL จะให้ข้อมูลต่อไปนี้แก่ Google ซึ่งเป็นส่วนหนึ่งของกระบวนการเริ่มต้นใช้งาน

1. CPID_URL ที่แอปพลิเคชันจะติดต่อเพื่อขอ CPID ต้องมี CPID_URL 1 รายการ แต่โอเปอเรเตอร์จะระบุ URL ได้หลายรายการเพื่อเพิ่มความพร้อมใช้งาน
2. รายการคํานําหน้า IP ที่ผู้ให้บริการเป็นเจ้าของและรหัสประเทศบนอุปกรณ์เคลื่อนที่ (MCC) และเครือข่ายมือถือ (MNC) ที่โอเปอเรเตอร์ต้องการแมปกับ CPID_URL หากโอเปอเรเตอร์ใช้ SPN หรือ GID1 เพื่อแยก MVNO ในเครือข่ายของตน โอเปอเรเตอร์ SHALL จะให้ข้อมูลนี้ด้วยเช่นกัน Google จะใช้ข้อมูลนี้เพื่อจับคู่ลูกค้ากับจุดสิ้นสุด CPID ที่เกี่ยวข้องดังที่แสดงในขั้นตอนที่ 1 ของรูปที่ 2

รูปแบบของคําขอคือ GET CPID_URL สําหรับเหตุผลเดิม ปลายทาง CPID ควรรองรับคําขอต่อไปนี้ได้

GET CPID_URL?app={app_id}

ปลายทาง CPID จะไม่สนใจพารามิเตอร์ของ URL {app_id} เมื่อสร้าง CPID แต่จะต้องสามารถจัดการคําขอที่มีพารามิเตอร์ได้

คําขอที่ส่งไปยังปลายทาง CPID อาจประกอบด้วยส่วนหัว Accept-Language หากมีส่วนหัวรวมอยู่ด้วย สตริงที่มนุษย์อ่านเข้าใจได้ในอัปเดตที่ DPA ส่งโดยใช้ API การแชร์แพ็กเกจอินเทอร์เน็ตมือถือต้องใช้การตั้งค่าที่ระบุไว้ในคําขอ CPID

ทุกครั้งที่ไคลเอ็นต์ส่งคําขอ GET CPID_URL จะต้องมี CPID ใหม่ หากการสร้าง CPID สําเร็จ ปลายทาง CPID จะต้องแสดงผลการตอบกลับ 200 เนื้อหาการตอบกลับจะต้องมีอินสแตนซ์ของ CPIDResponse

{
    "cpid": "<CPID_string>",
    "ttlSeconds": 2592000
}

CPID ที่แสดงต้องใช้งานได้เป็นเวลา ttlSeconds แม้ว่าผู้ติดตามจะขอ CPID อื่นๆ หลังจากนั้นก็ตาม Google ขอแนะนําให้ใช้ค่า TTL เป็นเวลา 30 วัน แต่ไม่น้อยกว่า 14 วันเพื่อประสบการณ์ของผู้ใช้ที่ดีที่สุด GTAF จะเข้ารหัส CPID ตาม RFC2396 ในการเรียก DPA ครั้งต่อๆ ไป

การสร้าง CPID

วิธีที่แนะนําสําหรับปลายทาง CPID ในการสร้าง CPID มีดังนี้

CPID_string = Base64(AES(MSISDN + TimeStamp + language, secret))

ปลายทาง CPID เชื่อมต่อ MSISDN ซึ่งเป็นภาษาที่ไคลเอ็นต์ส่งในส่วนหัวที่ยอมรับได้สําหรับภาษา และการประทับเวลาที่มีความละเอียดสูงและเข้ารหัสผ่าน AES โดยใช้คีย์ secret การประทับเวลาควรสอดคล้องกับเวลาที่ CPID หมดอายุ ส่วนเอาต์พุตที่เข้ารหัสจะเข้ารหัสแบบ Base64 นอกจากนี้ เมื่อใช้ CPID ใน URL URL นั้นจะต้องเข้ารหัส URL เพื่อจัดการสัญลักษณ์พิเศษ (/+=) ที่ใช้ใน Base64 โดยเฉพาะอย่างยิ่งเมื่อ GTAF เรียกใช้ DPA หรือเมื่อ DPA เรียกใช้ API การแชร์ข้อมูล แพ็กเกจมือถือ CPID จะต้องเข้ารหัส URL

การใช้งานปลายทาง CPID อาจไม่ใช่การดําเนินการที่เหมาะสม ทั้งนี้ขึ้นอยู่กับสถานการณ์ของโอเปอเรเตอร์นั้นๆ ความท้าทายอย่างหนึ่งที่เจอบ่อยคือการเข้าถึง MSISDN ที่ปลายทาง CPID เรายินดีแชร์บทเรียน เกี่ยวกับโอเปอเรเตอร์การเริ่มต้นใช้งานที่ได้รับ โปรดติดต่อเราหากคุณมีปัญหาอะไร

พื้นที่เก็บข้อมูล CPID

CPID ที่สร้างขึ้นโดยใช้กลไกที่อธิบายไว้ข้างต้นไม่จําเป็นต้องจัดเก็บไว้ในฐานข้อมูล ข้อมูลที่เกี่ยวข้องสําหรับการจัดการกับ DPA สามารถดึงมาจาก CPID

1. เมื่อ DPA ได้รับการโทรติดต่อจาก GTAF เพื่อดูสถานะหรือข้อเสนอของแผน MSISDN อาจมาจากการถอดรหัส CPID และการดึงข้อมูล MSISDN
2. เวลาหมดอายุของ CPID อาจมาจากการถอดรหัส CPID และจึงยกเว้นการประทับเวลาวันหมดอายุ

ข้อกําหนดด้านความพร้อมและความจุ

หากลูกค้าเรียกดู CPID ไม่ได้ ก็จะเข้าถึงข้อมูลจาก API แพ็กเกจอินเทอร์เน็ตมือถือไม่ได้ ด้วยเหตุนี้ โอเปอเรเตอร์ SHALL จะใช้มาตรการที่จําเป็นเพื่อให้แน่ใจว่าความพร้อมใช้งานของ CPID มาตรการดังกล่าวรวมถึงฟังก์ชันปลายทาง CPID และฟังก์ชัน DPI หลายอินสแตนซ์ และมีการสํารองทางกายภาพ เว็บไซต์ และเครือข่ายทั้ง 2 รายการ และดูแลให้ทรัพยากรและความจุของระบบเพียงพอ นอกจากนี้ ปลายทาง CPID รวมไปถึงฟังก์ชัน DPI ที่แทรกส่วนหัวจะต้องมีความจุเพียงพอเพื่อรองรับภาระงานของไคลเอ็นต์ Google ทั้งหมดที่ขอ CPID ปลายทาง CPID สามารถใช้ค่าที่ใหญ่ขึ้นในช่อง ttlSeconds เพื่อลดความถี่ที่สร้าง CPID

กรณีข้อผิดพลาด

หากเกิดข้อผิดพลาด ปลายทาง CPID ต้องแสดงข้อผิดพลาด HTTP ที่มีเนื้อหาของการตอบกลับที่ต้องมีอินสแตนซ์ของ ErrorResponse ข้อความแสดงข้อผิดพลาดที่ดีควรมีข้อมูลที่ช่วยคุณแก้ไขข้อบกพร่องของข้อผิดพลาดนั้นๆ ได้ เช่น ในกรณีที่ CPID หมดอายุ รวมถึงการสร้าง CPID และเวลาหมดอายุจะช่วยให้เรายืนยันได้ว่าปลายทาง CPID ทํางานตามที่ออกแบบมา

{
    "errorMessage": "<error message>",
    "cause": "USER_ROAMING"
}

ปลายทาง CPID ต้องส่งคืนสิ่งต่อไปนี้โดยขึ้นอยู่กับสถานการณ์

1. หากได้รับคําขอ CPID สําหรับผู้ใช้ที่ไม่ได้อยู่ในเครือข่าย (เช่น ผู้ใช้อยู่ในโอเปอเรเตอร์อื่นแต่โรมมิ่งในเครือข่ายที่ปลายทาง CPID นี้แสดง) หรือผู้ที่ไม่ได้เลือกแชร์ข้อมูลแผนข้อมูลกับ Google ปลายทาง CPID จะต้องส่งคืนรหัสสถานะ HTTP 403 พร้อมกับ USER_ROAMING, USER_OPT_OUT หรือ INELIGIBLE_FOR_SERVICE เนื่องจาก
2. หากคําขอ CPID ได้รับคําขอจากหมายเลขโทรศัพท์ที่ไม่ถูกต้อง จุดสิ้นสุด CPID ของ HTTP 400 จะต้องแสดงข้อผิดพลาด
3. หากคําขอที่ส่งไปยังปลายทาง CPID มีรูปแบบอื่นไม่ถูกต้อง จุดสิ้นสุด CPID ต้องส่งคืน HTTP 400 โดยมี ERROR_CAUSE_UNSPECIFIED
4. สําหรับข้อผิดพลาดอื่นๆ รหัสข้อผิดพลาดของ HTTP ที่เข้ากันได้สามารถยอมรับได้ โดยเฉพาะอย่างยิ่ง HTTP 500 คือข้อผิดพลาดที่เหมาะสมสําหรับความล้มเหลวภายในที่ปลายทาง CPID