Trang này được dịch bởi Cloud Translation API.

Thiết lập CPID

GTAF sử dụng khóa người dùng để xác định người đăng ký khi giao tiếp với DPA. Các ứng dụng có quyền truy cập vào MSISDN của người dùng có thể sử dụng làm khoá người dùng. Mặt khác, các ứng dụng không có quyền truy cập vào MSISDN, cần thiết lập mã nhận dạng gói của nhà mạng (CPID) mà không tìm thấy MSSDN của người dùng. Trong những nội dung sau đây, chúng tôi mô tả cơ chế thiết lập một CPU.

Luồng cuộc gọi CPID

Hình 2: Luồng cuộc gọi để thiết lập CPID.

Một ứng dụng của Google trong UE sử dụng một API nội bộ của Google để truy xuất URL của điểm cuối CPID từ GTAF. Nhà cung cấp dịch vụ được xác định bằng địa chỉ IP công khai của máy khách và MCC+MNC của thẻ SIM đang hoạt động. Trong trường hợp MVNO, Google sẽ sử dụng SPN và GID1 để xác định MVNO
Máy khách gửi yêu cầu GET HTTP cho điểm cuối CPID. Toán tử CÓ THỂ hỗ trợ gửi yêu cầu qua HTTPS.
Toán tử CÓ thể sử dụng chức năng Kiểm tra gói sâu của họ để xác định yêu cầu và chèn số điện thoại của người dùng vào yêu cầu dưới dạng tiêu đề HTTP.
Điểm cuối CPID nhận được yêu cầu, tạo CPID và trả về CPID cho UE cùng với thời gian tồn tại (TTL) cho biết thời gian mà UE có thể sử dụng CPU này.

Nhà cung cấp dịch vụ cũng có thể sử dụng địa chỉ IP thay vì tên miền trong URL điểm cuối CPID (nếu muốn). Các địa chỉ IP CÓ THỂ ở trong không gian địa chỉ riêng tư nhưng phải được khách hàng của Google truy cập bên trong mạng của nhà cung cấp dịch vụ.

Toán tử SHALL cung cấp cho Google những thông tin sau trong quá trình tham gia:

CPID_URL mà các ứng dụng sẽ liên hệ để nhận CPID. Một CPID_URL là bắt buộc nhưng toán tử có thể cung cấp nhiều URL để tăng khả năng truy cập.
Danh sách tiền tố IP mà nhà điều hành sở hữu và Mã quốc gia trên thiết bị di động (MCC) và Mã mạng di động (MNC) mà nhà điều hành muốn liên kết với CPID_URL đã cung cấp. Nếu nhà mạng sử dụng SPN hoặc GID1 để phân biệt MVNO trong mạng của họ, thì toán tử SHALL cũng cung cấp thông tin này. Google sẽ sử dụng thông tin này để so khớp khách hàng với các điểm cuối CPID tương ứng, như trình bày trong Bước 1 của Hình 2.

Định dạng của yêu cầu là: GET CPID_URL Vì lý do cũ, điểm cuối CPID phải có thể hỗ trợ yêu cầu như sau:

GET CPID_URL?app={app_id}

Điểm cuối CPID có thể bỏ qua tham số URL {app_id} khi tạo CPU. Tuy nhiên, hàm PHẢI có khả năng xử lý yêu cầu chứa tham số.

Yêu cầu đến điểm cuối CPID CÓ THỂ bao gồm tiêu đề Accept-Language. Nếu tiêu đề được đưa vào thì các chuỗi có thể đọc được trong các bản cập nhật mà DPA gửi bằng API Chia sẻ gói dữ liệu di động PHẢI sử dụng chế độ cài đặt được cung cấp trong yêu cầu CPU.

Mỗi khi khách hàng đưa ra yêu cầu GET CPID_URL, PHẢI PHẢI nhận được CPID mới. Nếu việc tạo CPID thành công, điểm cuối CPID PHẢI trả về phản hồi 200 OK. Phần nội dung phản hồi PHẢI chứa một thực thể của CPIDResponse.

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

CPID trả về PHẢI hợp lệ trong ttlSeconds, ngay cả khi người đăng ký đã yêu cầu các CPID khác sau đó. Bạn nên sử dụng giá trị TTL là 30 ngày nhưng không ít hơn 14 ngày để có trải nghiệm người dùng tốt nhất. GTAF sẽ mã hoá CPU theo RFC2396 trong các lệnh gọi tiếp theo tới DPA.

Tạo CPID

Cách đề xuất cho điểm cuối CPID để tạo CPID là:

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

Điểm cuối CPID nối nối SSDSDN, ngôn ngữ do ứng dụng khách gửi trong tiêu đề Chấp nhận bằng ngôn ngữ, cũng như dấu thời gian độ phân giải cao và mã hoá thông qua AES bằng khoá secret. Dấu thời gian PHẢI tương ứng với thời gian mà CPID hết hạn. Đầu ra đã mã hoá là mã hoá Base64. Hơn nữa, khi được dùng CPID trong một URL, bạn PHẢI mã hoá URL để xử lý các ký tự đặc biệt (/+=) trong Base64. Cụ thể là khi GTAF gọi DPA hoặc khi DPA gọi API Chia sẻ gói dữ liệu di động, CPID PHẢI được mã hóa URL.

Tuỳ thuộc vào tình huống của các nhà cung cấp dịch vụ cụ thể, bạn nên triển khai điểm cuối CPID. Một thách thức cụ thể thường gặp phải là truy cập vào MSISDN tại điểm cuối CPID. Chúng tôi rất sẵn lòng chia sẻ các bài học kinh nghiệm về toán tử giới thiệu. Vui lòng liên hệ với chúng tôi nếu bạn gặp khó khăn.

Bộ nhớ CPI

CPID được tạo bằng cơ chế mô tả ở trên không cần phải được lưu trữ trong cơ sở dữ liệu. Thông tin liên quan để xử lý các lệnh gọi đến DPA có thể bắt nguồn từ CPID.

Khi DPA nhận được lệnh gọi từ GTAF về trạng thái hoặc ưu đãi của gói, bạn có thể lấy MSISDN bằng cách giải mã CPID và trích xuất MSISDN.
Thời gian hết hạn của CPID có thể được dẫn xuất bằng cách giải mã CPID, sau đó trích xuất dấu thời gian hết hạn.

Phạm vi cung cấp và yêu cầu về hạn mức

Nếu khách hàng không thể truy xuất CPID, thì họ không thể truy cập vào thông tin từ API gói dữ liệu di động. Vì lý do này, toán tử SHALL sẽ thực hiện các biện pháp cần thiết để đảm bảo khả năng sử dụng điểm cuối CPID. Những biện pháp như vậy bao gồm việc có nhiều phiên bản của điểm cuối CPID và các hàm DPI, đồng thời có tính năng dự phòng thực tế, trang web và mạng cho cả hai hàm, đồng thời đảm bảo cung cấp tài nguyên và dung lượng hệ thống đầy đủ. Hơn nữa, điểm cuối CPID cũng như hàm DPI chèn tiêu đề phải có đủ dung lượng để xử lý khả năng tải của tất cả ứng dụng Google yêu cầu CPID. Điểm cuối CPID có thể sử dụng các giá trị lớn hơn trong trường ttlSeconds để giảm tần suất tạo điểm cuối cho CPID.

Các trường hợp lỗi

Nếu xảy ra lỗi, điểm cuối CPID PHẢI trả về lỗi HTTP với nội dung phản hồi PHẢI chứa một phiên bản của ErrorResponse. Một thông báo lỗi hiệu quả sẽ bao gồm thông tin có thể giúp bạn gỡ lỗi nguyên nhân gây ra lỗi. Ví dụ: trong trường hợp CPID đã hết hạn, bao gồm việc tạo CPID và thời gian hết hạn sẽ giúp chúng tôi xác nhận rằng điểm cuối CPID đang hoạt động như thiết kế.

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

Tuỳ theo trường hợp, bạn phải trả về điểm cuối CPID:

Nếu nhận được yêu cầu CPID cho người dùng không thuộc mạng của nhà cung cấp dịch vụ (ví dụ: người dùng thuộc về một nhà cung cấp dịch vụ khác nhưng đang chuyển vùng trên mạng do điểm cuối CPID này phân phát) hoặc chưa chọn chia sẻ thông tin gói dữ liệu với Google, thì điểm cuối CPID PHẢI trả về mã trạng thái HTTP 403 với nguyên nhân USER_ROAMING, USER_OPT_OUT hoặc INELIGIBLE_FOR_SERVICE
Nếu nhận được một yêu cầu CPID có số điện thoại không hợp lệ, thì điểm cuối CPID PHẢI trả về HTTP 400 kèm theo nguyên nhân lỗi INVALID_NUMBER.
Nếu yêu cầu đến điểm cuối CPID không đúng định dạng theo bất kỳ cách nào khác, điểm cuối CPID PHẢI trả về HTTP 400 với nguyên nhân ERROR_CAUSE_UNSPECIFIED.
Đối với các nguyên nhân lỗi khác, mọi mã lỗi HTTP tương thích đều được chấp nhận. Cụ thể, HTTP 500 là nguyên nhân gây ra lỗi phù hợp cho mọi lỗi nội bộ tại điểm cuối CPID.