Phần này trình bày kĩ thuật phân tích để I-CSCF và S-CSCF tìm ra địa chỉ của HSS–nơi lưu trữ dữ liệu thuê bao để nhận dạng thuê bao. Kĩ thuật phân tích này không được sử dụng tại mạng chỉ có một HSS
Ở bản tin REGISTER và MT INVITE, I-CSCF truy vấn HSS để có dữ liệu đặc tả thuê bao như vị trí hiện tại hay tham số nhận thực. Điều này cũng phải được thiết lập nhờ đăng kí trên S-CSCF. Trong trường hợp có nhiều hơn một HSS độc lập trong mạng, thì HSS mà chứa thông tin người dùng đang cần thiết cần phải được tìm thấy. Để biết tên của HSS, I-CSCF và S-CSCF truy vấn tới thực thể chức năng vị trí thuê bao (SLF).
Bộ vị trí thuê bao được truy nhập thông qua giao diện Dx Diameter. Giao diện Dx Diameter là giao diện chuẩn giữa CSCF và SLF.
Giao diện Dx cung cấp:
Một sự vận hành để truy vấn vào bộ định vị thuê bao từ I-CSCF hoặc từ S- CSCF.
Một sự đáp ứng để cung cấp tên HSS về phía I-CSCF hoặc về phía S-CSCF. Bằng việc gửi lên giao diện Dx bản tin Dx-SLF-Query mà I-CSCF hoặc S- CSCF yêu cầu một nhận dạng thuê bao của thuê bao mà nó đang tìm trong HSS. Bằng cách gửi lên giao diện Dx bản tin Dx-SLF-RESP mà SLF đáp ứng được tên HSS. I- CSCF hoặc S-CSCF tương ứng tiếp tục truy vấn HSS đã lựa chọn đó. Như một tùy chọn tại thời điểm đăng kí, I-CSCF có thể chuyển tiếp tên của HSS tới S-CSCF để đơn giản hóa thủ tục S-CSCF tìm HSS của thuê bao. Tùy chọn này có thể được sử dụng ở mạng chỉ có một HSS đơn.
2 bản tin được đưa ra được sử dụng trong giao diện Dx:
Yêu cầu thông tin vị trí Location-Info-Request (LIR) – yêu cầu tìm HSS
Trả lời thông tin vị trí Location-Info-Request (LIA) – Trả lời vị trí HSS
Định dạng của bản tin thanh toán: yêu cầu thông tin vị trí và trả lời vị trí được định nghĩa trong giao thức cơ bản Diameter.
Nhóm 1 _ D11VT7 51
Những biểu tượng sau được sử dụng trong bản tin:
<AVP> nói rằng các AVP bắt buộc này được gán cố định trong bản tin
{AVP} cho biết một AVP bắt buộc trong bản tin
[AVP] cho biết rằng AVP tùy chọn trong bản tin
*AVP cho biết rằng nhiều sự kiện có thể có trong một AVP
Bản tin định vị ví trí (LIR) (chỉ định trường mã lệnh đặt thành 302 và bit R được đặt trong trường cờ) (3GPP).
Định dạng bản tin LIR:
<Diameter header: 302, REQ, PXY, 16777216> <Session-Id> {Vendor-Specific-Application-Id} {Auth- Session-State} {Origin-Host} {Origin-Realm} [Destination-Host] {Destinaiton-Realm} *[Supported-Features] {Public-Identity} *[AVP] *[Proxy] *[Routed-Record]
Yêu cầu này bao gồm:
Nhận dạng người dùng công khai – bao gồm nhận dạng từ trường yêu cầu URI của phương thức SIP.
Thông tin định tuyến – bao gồm địa chỉ của HSS nếu I-CSCF nhận biết. Nếu I- CSCF không biết địa chỉ của HSS, khi đó nó kể đến vị trí đích.
Nhóm 1 _ D11VT7 52
HSS trả lời với một lệnh trả lời thông tin vị trí (LIA).
Lệnh Trả lời thông tin vị trí (LIA), với mã lệnh đặt thành 302, và bit R được sẽ bị xóa trong trường cờ, đáp ứng lại bản tin LIR.
Định dạng bản tin LIA:
<Diameter header: 302, REQ , PXY, 16777216> <Session-Id> [Result-Code] {Vendor-Specific-Application-Id} {Experimental-Result} {Auth- Session-State} {Origin-Host} {Origin-Realm} *[Supported-Features] {Public-Identity} [Server - Capabilities] *[AVP] *[Failed-AVP] *[Proxy - Info] *[Routed-Record] Câu trả lời này bao gồm:
Kết quả - thông báo kết quả của lệnh LIR.
Tên hoặc các khả năng S-CSCF – sau cùng được trả lời nếu người dùng không có tên S-CSCF được gán, mặt khác URI SIPcủa S-CSCF được trả lời.
Giá trị của Mã kết quả AVP
a. Thành công (adsbygoogle = window.adsbygoogle || []).push({});
Nhóm 1 _ D11VT7 53
HSS cho I-CSCF biết rằng:
- Người dùng được cấp quyền để đăng kí với nhận dạng công khai; - Một S-CSCF sẽ được gán tới người dùng;
2. Dịch vụ chưa đăng kí DIAMETER_UNTERGISTERED_SERVICE HSS cho I-CSCF biết rằng:
- nhận dạng công khai không được đăng kí nhưng có các dịch vụ liên quan tới trạng thái chưa đăng kí;
- Một S-CSCF sẽ được gán tới người dùng;
2. DIAMETER_SUCCESS_SERVER_NAME_NOT_STORE HSS cho I-CSCF biết rằng:
- kết thúc đăng kí được đưa ra;
- S-CSCF không được lưu trữ trong HSS; 4. DIAMETER_SERVER_SELECTION
HSS cho I-CSCF biết rằng:
- Người dùng được cấp quyền để đăng kí với nhận dạng công khai này; - Một S-CSCF đã được gán cho các dịch vụ liên quan tới trạng thái chưa
đăng kí rồi;
- Có thể cần thiết để gán một S-CSCF mới tới người dùng;
b. Lỗi
1. DIAMETER_ERROR_USER_UNKNOW Bản tin được nhận từ một người dùng lạ mặt;
2. DIAMETER_ERROR_IDENTITIES_DONT_MATCH
Một bản tin được nhận với một nhận dạng công khai và một nhận dạng cá nhân của người dùng, và server xác định rằng nhận dạng công khai không tương ứng với nhận dạng cá nhân;
2. DIAMETER_ERROR_IDENTITY_NOT_REGISTERED
Một truy vấn đối với thông tin vị trí được nhận từ một nhận dạng công khai mà không được đăng kí trước đó;
4. DIAMETER_ERROR_ROAMING_NOT_ALLOWED
Người dùng không được phép chuyển vùng trong mạng khách; 5. DIAMETER_ERROR_ IDENTITY_ALREADY_REGISTERED
Nhóm 1 _ D11VT7 54
Nhận dạng được đăng kí với server được gán rồi và trạng thái đăng kí không cho phép chèn vào;
6. DIAMETER_ERROR_TOO_MUCH_DATA
Số lượng dữ liệu tới bên nhận vượt quá dụng lượng;
7. DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA
S-CSCF cho HSS biết rằng nhận được dữ liệu chứa thông tin không được nhận ra hoặc hỗ trợ; 2.2.2 Đăng kí trên SLF P-CSCF I-CSCF SLF HSS 3. Tìm trong cơ sở dữ liệu SLF Đăng kí 2. Truy vấn Dx- SLF 4. Đáp ứng Dx- SLF Mạng nhà 5. Truy vấn Cx
Hình 2.8: Đăng kí trên SLF (trường hợp 1)
1. I-CSCF nhận một yêu cầu đăng kí và bây giờ phải truy vấn vị trí dữ liệu của thuê bao.
2. I-CSCF gửi một Dx-SLF-Query tới SLF chứa các tham số nhận dạng thuê bao đặt trong yêu cầu REGISTER. (adsbygoogle = window.adsbygoogle || []).push({});
3. SLF tìm trong cơ sở dữ liệu của nó nhận dạng thuê bao được truy vấn. 4. SLF trả lời dữ liệu của thuê bao cùng với tên HSS.
Nhóm 1 _ D11VT7 55 I-CSCF S-CSCF SLF HSS 3. Tìm trong cơ sở dữ liệu SLF Đăng kí 2. Truy vấn Dx- SLF 4. Đáp ứng Dx- SLF Mạng nhà
Hình 2.9: Đăng kí trên SLF(trường hợp 2)
1. I-CSCF gửi yêu cầu REGISTER tới S-CSCF. và bây giờ phải truy vấn vị trí dữ liệu của thuê bao.
2. S-CSCF gửi Dx-SLF-QUERY tới SLF với các tham số nhận dạng thuê bao đặt trong yêu cầu đăng kí.
3. SLF tìm trong cơ sở dữ liệu của nó nhận dạng thuê bao được truy vấn. 4. SLF trả lời dữ liệu của thuê bao kèm với tên của HSS.
2.2.3 Mời UE trên SLF X-CSCF I-CSCF SLF HSS X-CSCF I-CSCF SLF HSS 3. Tìm trong cơ sở dữ liệu SLF 1. Mời 2. Truy vấn Dx- SLF 4. Đáp ứng Dx- SLF Mạng nhà Hình 2.10: Mời UE trên SLF
1. I-CSCF nhận yêu cầu INVITE và bây giờ phải truy tìm vị trí dữ liệu của thuê bao.
2. I-CSCF gửi Dx-SLF-QUERY tới HSS chứa các tham số nhận dạng thuê bao được đặt trong yêu cầu INVITE.
Nhóm 1 _ D11VT7 56
4. SLF trả lời dữ liệu thuê bao cùng với tên của HSS.
Để ngăn cản dịch vụ SLF sai, SLF có thể được phân phối trên nhiều Server. Một vài phương pháp có thể được đặt để tìm ra các server này.
2.3. Khởi tạo phiên
Khi một người dùng A muốn có một phiên với người dùng B, UE A tạo ra yêu cầu INVITE SIP và gửi yêu cầu này qua điểm tham chiếu Gm tới P-CSCF. P-CSCF xử lý yêu cầu: ví dụ như P-CSCF giải nén yêu cầu và kiểm ra nhận dạng người dùng khởi tạo trước khi chuyển tiếp yêu cầu qua điểm tham chiếu Mw tới S-CSCF. S-CSCF xử lý yêu cầu, thực hiện điều khiển dịch vụ bao gồm tương tác với các server ứng dụng (AS) và cuối cùng quyết định điểm vào nhà vận hành mạng nhà của người dùng B dựa trên nhận dạng người dùng B trong yêu cầu INVITE SIP. Hình 2.11 Lưu đồ thiết lập phiên IMS mức cao. S-CSCF HSS I-CSCF S-CSCF Mạng nhà của người dùng B Mạng nhà của người dùng A 4.Tìm S-CSCF 5. INVITE 10. 183 6-7. INVITE 1-2. INVITE 12. 183 3. INVITE 11. 183 P-CSCF P-CSCF 13. 183 9. 183
Hình 2.11: Lưu đồ thiết lập phiên IMS mức cao.
I-CSCF nhận yêu cầu qua điểm tham chiếu Mw và liên hệ với HSS qua điểm tham chiếu Cx của giao thức Diameter để tìm S-CSCF đang phục vụ người dùng
B.Yêu cầu này được chuyển qua điểm tham chiếu Mw tới S-CSCF. S-CSCF thực hiện trách nhiệm xử lý thiết bị đầu cuối phiên, tính đến cả tương tác với các server ứng dụng (AS) và cuối cùng thực hiện chuyển giao yêu cầu tới P-CSCF qua điểm tham chiếu Mw. Sau khi xử lý (ví dụ nén và kiểm tra cá nhân), P-CSCF sử dụng điểm tham chiếu Gm để chuyển giao yêu cầu INVITE SIP tới UE B. UE B tạo ra một câu trả lời theo chiều ngược lại tới UE A theo tuyến đã được tạo (ví dụ UE B -»P-CSCF -> S- CSCF -> I-CSCF -> S-CSCF -> P-CSCF -> UE A).
Sau một vài hành trình quay trở về, cả hai UE hoàn thành thiết lập phiên và có thể bắt đầu kích hoạt ứng dụng (ví dụ chơi cờ). Trong khi thiết lập phiên nhà vận hành có thể điều khiển sử dụng kênh mang dành cho lưu lượng phương tiện.
Nhóm 1 _ D11VT7 57
Trong quá trình khởi tạo phiên này ta thấy rằng I-CSCF liên hệ với HSS qua điểm tham chiếu Cx của giao thức Diameter để tìm S-CSCF đang phục vụ người dùng B.
2.4 Tính cước
Có hai kiến trúc tính cước đó là tính cước trực tuyến và tính cước ngoại tuyến.
2.4.1 Kiến trúc tính cước
Kiến trúc IMS hỗ trợ cả hai khả năng tính cước trực tuyến và tính cuớc ngoại tuyến. Tính cước trực tuyến là quá trình tính cước ở các thực thể IMS, như là một server ứng dụng (AS) tương tác với hệ thống tính cước trực tuyến. Hệ thống tính cước trực tuyến tương tác thời gian thực với tài khoản của người sử dụng và điều khiển hoặc giám sát tính cước liên quan tới sử dụng dịch vụ: ví dụ, AS truy vấn hệ thống tính cước trực tuyến trước khi cho phép thiết lập phiên hoặc nhận thông tin về một người sử dụng có thể tham gia vào một hội nghị trong bao lâu. Tính cước ngoại tuyến là một quá trình tính cước ở đó thông tin tính cước được tập hợp chủ yếu sau phiên và hệ thống tính cước không tác động thời gian thực đến dịch vụ đang sử dụng. Trong mô hình này một người dùng nhận được một hóa đơn trong hàng tháng, chỉ ra các khoản phí tổn phải chịu trong một giai đoạn riêng. Nhờ có các các mô hình tính cước tự nhiên khác của các giải pháp kiến trúc khác nhau được đòi hỏi.
2.4.2 Kiến trúc tính cước ngoại tuyến
Điểm trung tâm trong kiến trúc tính cước ngoại tuyến là chức năng tập hợp tính cước (CCF – Charing Collection Function). CCF nhận thông tin tính toán từ các thực thể IMS qua điểm tham chiếu Rf. Hơn nữa CCF xử lý dữ liệu nhận được và sau đó xây dựng và định dạng bản ghi dữ liệu cước CDR (charing data record) hiện thời. CDR được chuyển tới hệ thống hóa đơn, nhận được nhờ cung cấp CDR cuối cùng, cùng với thông tin tính cước nhận được từ các nguồn khác như là (ví dụ chức năng cổng tính cước, hoặc CGF-Charing Gateway Function). Hình 2.12 mô tả kiến trúc tính cước ngoại tuyến trong một trường hợp ở nơi cả hai phần chủ gọi và phần bị gọi đều đang sử dụng chuyển vùng IMS. Khi người dùng không chuyển vùng ở đó sẽ duy nhất một CCF liên quan.
Nhóm 1 _ D11VT7 58
Bp
hách (B) Hệ thống hóa đơn Hệ thống hóa đơn
Hệ thống hóa đơn Hệ thống hóa đơn CCF CCF CCF CCF CGF CGF Bi Rf AS AS MRFC MRFC S-CSCF S-CSCF I-CSCF I-CSCF BGCF BGCF MGCF MGCF P-CSCF P-CSCF GGSN GGSN SGSN SGSN Nhà (A) Nhà (B) Khách (A) Rf Bi Rf Rf Bi Bp Ga Ga Khách (B) (adsbygoogle = window.adsbygoogle || []).push({});
Hình 2.12: Kiến trúc tính cước IMS ngoại tuyến
a. Chức năng tập hợp tính cước CCF
Cách sử dụng của CCF cho phép một nhà vận hành có điểm tham chiếu đơn hướng về hệ thống hóa đơn, CCF chuyển giao thông tin tính cước từ các thực thể IMS (AS, MRFC, S-CSCF, I-CSCF, P-CSCF, BGCF, MGCF) tới các hệ thống hóa đơn tự chọn của nhà vận hành mạng. Các chức năng chính của CCF là:
Tập hợp thông tin thanh toán từ các thực thể IMS và tạo thông tin thanh toán chung;
Tương quan, hợp nhất, lọc các trường không cần thiết và thêm vào thông tin nhà vận hành riêng biệt để nhận thông tin thanh toán;
Tạo các CDR sau khi tiền xử lý;
Chuyển các CDR tới hệ thống hóa đơn;
Đệm CDR khi hệ thống hóa đơn bận;
CCF có thể thực hiện như là một trung tâm, phần tử mạng riêng hoặc như là một chức năng tích hợp cứ trú trong các thực thể IMS. Có một CCF đơn giảm bớt tải của thực thể IMS bởi vì nó không cần thiết để đệm và hoàn trả các CDR hiện thời.
Nhóm 1 _ D11VT7 59
b. Chức năng cổng tính cước
CGF trong miền chuyển mạch gói (PS) cung cấp một cơ chế để chuyển giao thông tin tính cước từ các node SGSN và GGSN tới các hệ thống hóa đơn đã được chọn của nhà vận hành mạng. Các chức năng chính của CGF cho miền PS là nguyên lý tương đương cho các CCF sử dụng trong miền IMS. Một điểm khác là CGF nhận các CDR hợp lệ từ SGSN và GGSN.
c. Hệ thống hóa đơn
CCF và CGF gửi các CDR tới hệ thống hóa đơn tạo ra hóa đơn thực sự (ví dụ gửi tới thuê bao mỗi tháng một lần). Hóa đơn sẽ bao gồm ví dụ số phiên, đích, khoảng thời gian và loại phiên (âm thanh, hình ảnh).
d. Điểm tham chiếu Rf (Diameter)
Nguyên lý cơ bản
Chức năng tính cước ngoại tuyến dựa trên thông tin báo cáo từ các nút mạng IMS dựa trên việc nhận một vài phương pháp SIP khác nhau hoặc bản tin ISUP, đa số thông tin liên quan đến thanh toán được chứa trong những bản tin này. Báo cáo này được tiến hành bằng việc gửi bản tin yêu cầu thanh toán Diameter (ACR) (Bắt đầu, chuyển tiếp và dừng) từ các nút IMS tới CCF.
Diameter client sử dụng ACR bắt đầu, chuyên tiếp và dừng trong các thủ tục có liên quan đến các phiên SIP. Người dùng sử dụng các ACR sự kiện cho các phiên SIP không thành công và cho các thủ tục phiên không liên quan.
Nhà vận hành lựa chọn các bản tin phương pháp SIP hoặc ISUP để khởi động ACR. Tuy nhiên, hai mục bắt buộc đã được định nghĩa:
Bất cứ khi nào 200 OK SIP, xác nhận một INVITE SIP khởi tạo, được nhận hoặc MGFC nhận một trả lời ISUP, ACR sẽ bắt đầu được gửi tới CCF.
Bất cứ khi nào nhận được BYE SIP hoặc MGCF nhận một xóa ISUP, sẽ dừng gửi ACR tới CCF.
Bảng 2.3 mô tả tất cả các ACR có thể được gửi từ một P-CSCF, I-CSCF, S- CSCF, MGCF hoặc BGCF. Một danh sách nút cụ thể ACR, với các AVP được mô tả chi tiết trong phần sau.
Nhóm 1 _ D11VT7 60 Bảng 2.3: Bản tin yêu cầu thanh toán khởi sự bởi SIP hoặc bản tin ISUP
cho tất cả các nút IMS trừ MRFC và AS
Bản tin Diameter
Khởi sự bởi SIP/Bản tin ISUP Bắt buộc/
Cấu hình
ACR (bắt đầu)
SIP 200 OK xác nhận một khởi tạo SIP
(adsbygoogle = window.adsbygoogle || []).push({});