การสร้าง CPID

GTAF ใช้คีย์ผู้ใช้เพื่อระบุตัวตนของสมาชิกเมื่อสื่อสารกับ DPA แอปพลิเคชันที่มีสิทธิ์เข้าถึง MSISDN ของผู้ใช้จะใช้ 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. ผู้ให้บริการอาจใช้ฟังก์ชันการตรวจสอบแพ็กเก็ตแบบละเอียดเพื่อระบุคำขอและแทรกหมายเลขโทรศัพท์ของผู้ใช้ลงในคำขอเป็นส่วนหัว HTTP
4. ปลายทาง CPID จะรับคำขอ สร้าง CPID และส่ง CPID กลับไปยัง UE พร้อมค่า Time to Live (TTL) ที่ระบุระยะเวลาที่ UE ใช้ CPID นี้ได้

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

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

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

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

GET CPID_URL?app={app_id}

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

คำขอไปยังปลายทาง CPID อาจมีส่วนหัว Accept-Language หากมี ส่วนหัว สตริงที่มนุษย์อ่านได้ในการอัปเดตที่ DPA ส่ง โดยใช้ Mobile Data Plan Sharing API จะต้องใช้การตั้งค่าที่ระบุไว้ใน คำขอ CPID

ทุกครั้งที่ไคลเอ็นต์ส่งคำขอ GET CPID_URL ไคลเอ็นต์จะต้องได้รับ CPID ใหม่ หากสร้าง CPID สำเร็จ ปลายทาง CPID จะต้องแสดงการตอบกลับ 200 OK เนื้อหาการตอบกลับต้องมีอินสแตนซ์ของ 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, ภาษาที่ไคลเอ็นต์ส่งในส่วนหัว Accept-Language และการประทับเวลาความละเอียดสูง แล้วเข้ารหัสผ่าน AES โดยใช้secretคีย์ การประทับเวลาควรสอดคล้องกับเวลาที่ CPID หมดอายุ เอาต์พุตที่เข้ารหัสจะเข้ารหัสแบบ Base64 นอกจากนี้ เมื่อใช้ CPID ใน URL จะต้องเข้ารหัส URL เพื่อจัดการอักขระพิเศษ (/+=) ที่ใช้ใน Base64 โดยเฉพาะอย่างยิ่งเมื่อ GTAF เรียกใช้ DPA หรือเมื่อ DPA เรียกใช้ Mobile Data Plan Sharing API จะต้องเข้ารหัส URL ของ CPID

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

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

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

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

ความพร้อมใช้งานและข้อกำหนดด้านความจุ

หากไคลเอ็นต์เรียก CPID ไม่ได้ ก็จะเข้าถึงข้อมูลจาก Mobile Data Plan API ไม่ได้ ด้วยเหตุนี้ ผู้ประกอบการต้องใช้มาตรการที่จำเป็น เพื่อให้มั่นใจว่าปลายทาง 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 พร้อมสาเหตุของข้อผิดพลาด INVALID_NUMBER
3. หากคำขอไปยังปลายทาง CPID มีรูปแบบไม่ถูกต้องในลักษณะอื่นๆ ปลายทาง CPID ต้องแสดง HTTP 400 โดยมี ERROR_CAUSE_UNSPECIFIED เป็นสาเหตุ
4. สำหรับสาเหตุของข้อผิดพลาดอื่นๆ ระบบจะยอมรับรหัสข้อผิดพลาดของ HTTP ที่เข้ากันได้ โดยเฉพาะอย่างยิ่ง HTTP 500 เป็นสาเหตุของข้อผิดพลาดที่เหมาะสมสำหรับความล้มเหลวภายในที่ปลายทาง CPID