Tải Nghiên cứu và phát triển chức năng HSS và SLF cho kiến trúc IMS
LỜI NÓI ĐẦU
Trong những năm qua xu hướng hội tụ mạng Internet, mạng di động và mạng PSTN đang là xu hướng được quan tâm hàng đầu trong lĩnh vực thông tin liên lạc. Nhiều kiến trúc mới đã ra đời trong quá trình phát triển hợp nhất các mạng với mục đích tạo ra một mạng IP duy nhất. Phân hệ IP Multmdia Subsystem (IMS) là một trong những kiến trúc đã ra đời trong xu thế phát triển đó. Với IMS, người dùng có thể liên lạc khắp mọi nơi nhờ tính di động của mạng di động và đồng thời có thể sử dụng những dịch vụ hấp dẫn từ mạng Internet. IMS đã thực sự trở thành chìa khóa để hợp nhất mạng di động và mạng Internet. IMS đồng thời cũng trở thành một phân hệ trong mô hình mạng thế hệ mới (NGN) của tất cả các hãng sản xuất các thiết bị viễn thông và các tổ chức chuẩn hóa trên thế giới.
Viện FOKUS ( Fraunhofer Institute for Open Communication Systems) đã đưa ra dự án OpenIMS. Đây là một dự án mã nguồn mở xây dựng mạng lõi IMS, rất phù hợp cho việc nghiên cứu IMS của sinh viên.
Trong thời gian thực tập tài phòng Lab C9-411 của bộ môn kỹ thuật thông tin, được sự hướng dẫn của TS Nguyễn Tài Hưng, tui đã chọn đề tài tốt nghiệp cho mình “Nghiên cứu và phát triển chức năng HSS và SLF cho kiến trúc IMS”. Đề tài liên quan nhiều đến thông tin người dùng và các dịch vụ của nhà cung cấp. Đây là những vấn đề lớn, rất quan trọng trong một mạng viễn thông.
Qua đây tui cũng xin gửi lời Thank chân thành tới TS Nguyễn Tài Hưng, TS Nguyễn Hữu Thanh và TS Nguyễn Văn Tiến đã giúp đỡ nhiệt tình cho cá nhân tui cũng như tất cả các bạn sinh viên tại phòng Lab C9-411 hoàn thành đồ án của mình.
tui xin chân thành cảm ơn!
Hà nội, ngày 21 tháng 05 năm 2008
TÓM TẮT ĐỒ ÁN
Xu hướng hội tụ mạng internet mạng di động và mạng điện thoại cố định đang ngày một trở nên cần thiết và được chú trọng. Phân hệ IMS ra đời như là một kiến trúc để đạt được mục đích đó.
Việc nghiên cứu và phát triển các chức năng của khối HSS và SLF trong kién trúc IMS có ý nghĩa quan trọng trong hoạt động của mạng IMS. Khối HSS chứa toàn bộ thông của tin người dùng gắn liền với các thông tin dịch vụ. Do vậy đồ án của tui tập trung nghiên cứu lý thuyết và có mô phỏng trên thực tế về các phần sau:
Thông tin người dùng: Nghiên cứu cấu trúc của thông tin người dùng trong IMSGiao thức Diameter: Là giao thức bao trùm lên hầu hết các hoạt động của khối HSS như: quá trình đăng ký, chứng thực, cấp quyền, tính cước, khởi tạo cuộc gọi của người dùng
MỤC LỤC
LỜI NÓI ĐẦU 1
TÓM TẮT ĐỒ ÁN 2
ABSTRACT. 3
MỤC LỤC 4
DANH SÁCH HÌNH VẼ. 7
DANH SÁCH TỪ VIẾT TẮT. 10
Chương 0 GIỚI THIỆU ĐỀ TÀI 12
0.1 Tầm quan trọng của đề tài 12
0.2 Nội dung nghiên cứu của đề tài 12
Chương 1 TỔNG QUAN KIẾN TRÚC IMS. 14
1.1 Vị trí và vai trò của phân hệ IMS trong kiến trúc mạng di động 3G 14
1.2 Các yêu cầu của IMS. 15
1.2.1 Hỗ trợ việc thiết lập các phiên Multimedia IP. 15
1.2.2 Hỗ trợ cơ chế để thỏa thuận QoS. 15
1.2.3 Hỗ trợ làm việc liên kết với mạng Internet và mạng chuyển mạch kênh (PSTN) 16
1.2.4 Hỗ trợ chuyển vùng. 16
1.2.5 Hỗ trợ điều khiển dịch vụ. 16
1.2.6 Hỗ trợ phát triển các dịch vụ. 17
1.2.7 Hỗ trợ đa truy nhập. 17
1.3 Tổng quan về các giao thức sử dụng trong IMS. 17
1.3.1 Giao thức điều khiển phiên. 17
1.3.2 Giao thức hỗ trợ chứng thực, cấp quyền, tính cước. 18
1.3.3 Các giao thức khác. 19
1.4 Tổng quan kiến trúc IMS. 19
1.4.2 CSCF - Call/Session Control Function. 21
1.4.3 Cơ sở dữ liệu : HSS và SLF. 24
1.4.4 AS (Application server) 25
1.4.5 MRF. 27
1.4.6 BGCF. 27
1.4.7 IMS-ALG và TrGW . 27
1.4.8 PSTN/CS gateway. 28
1.4.9 Mạng chủ và mạng khách. 30
1.5 Nhận dạng người dùng trong IMS. 32
1.5.1 Nhận dạng người dùng cá nhân. 34
1.5.2 Mối liên hệ giữa nhận dạng người dùng cá nhân và nhận dạng người dùng công cộng. 34
1.5.3 Nhận dạng dịch vụ công công. 36
1.5.4 SIM, USIM và ISIM trong 3GPP. 36
Chương 2 GIAO THỨC HỖ TRỢ CHỨNG THỰC, CẤP QUYỀN, TÍNH CƯỚC TRONG IMS 41
2.1 Chứng thực và cấp quyền trong IMS. 41
2.2 Giao thứ Diameter 42
2.2.1 Cấu trúc bản tin Diameter 45
2.2.2 Cặp giá trị thuộc tính. 47
2.2.3 Địa chỉ AAA và AAAS. 49
2.2.4 Giao thức Diameter cơ bản. 50
2.2.5 Các AVP trong giao thức Diameter cơ bản. 54
2.3 Giao diện Cx và Dx. 57
2.3.1 Những lệnh trong Diameter ứng dụng cho giao diện Cx. 58
2.3.2 Các AVP trong Diameter ứng dụng cho giao diện Cx. 65
2.4 Thông tin người dùng. 70
2.4.1 Cấu trúc tổng quát thông tin người dùng. 70
2.4.2 Nhận dạng công cộng. 72
2.4.3 Cấp quyền cho mạng lõi dịch vụ. 72
2.4.4 Tiêu chuẩn sàng lọc ban đầu. 73
2.5 Giao diện Sh. 75
2.5.1 Dữ liệu người dùng trên giao diện Sh. 75
2.5.2 Các lệnh định nghĩa trên Diameter ứng dụng cho giao diện Sh. 76
2.5.3 Các AVP định nghĩa trong Diameter ứng dụng cho giao diện Sh. 79
2.6 Tính cước. 81
Chương 3 PHẦN MỀM OPENIMS. 82
3.1 Giới thiệu chung về phần mềm OpenIMS của FOKUS. 82
3.2 Fokus Home Subcriber Server ( FHoSS ) 86
Chương 4 CÁC MÔ PHỎNG 91
4.1 Tạo và đăng ký người dùng mới 91
4.2 Cơ sở dữ liệu người dùng trên mysql 93
4.3 Cấu hình các dịch vụ. 96
4.4 Thống kê các bản tin Diameter trong quá trình đăng ký. 98
KẾT LUẬN 100
PHỤ LỤC 101
TÀI LIỆU THAM KHẢO 104
Để tải bản Đầy Đủ của tài liệu, xin Trả lời bài viết này, Mods sẽ gửi Link download cho bạn sớm nhất qua hòm tin nhắn.
Ai cần download tài liệu gì mà không tìm thấy ở đây, thì đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí
Bản tin CER và CEA
CFR (Capabilities Exchange Request)
CFA (Capabilities Exchange Answer)
Là bản tin trao đổi đầu tiên giữa hai nút Diameter, khi kết nối vận chuyển chỉ được khởi tạo một đầu. Hai bản tin này mang các thông tin về nhận dạng của nút và các thông số về lưu trữ của nó ( phiên bản của giao thức, sự hỗ trợ Diameter ứng dụng, cơ cấu hỗ trợ bảo mật…)
Bản tin DWR và DWA
DWR (Device Watchdog Request)
DWA (Device Watchdog Answer)
Nó cần thiết cho giao thức Diameter để tìm được các lỗi của tầng vận chuyển và tầng ứng dụng ngay khi có thể, do đó sẽ đưa ra được phản ứng thích hợp. Diameter có thể cung cấp việc xác định các lỗi này là dựa trên cơ chế watchdog của tầng ứng dụng. Trong suốt chu kỳ vận chuyển lưu lượng giữa hai nút Diameter, nếu như một nút gửi yêu cầu mà không nhận được hồi đáp trong một khoảng thời gian nào đó, khi ấy vẫn đủ để tìm ra lỗi ở tầng vận chuyển hay tầng ứng dụng. Tuy nhiên trong trường hợp bị thất lạc nhiều gói qui định thì không thể tìm ra lỗi được. Diameter giải quyết vấn đề này qua việc điều tra tầng vận chuyển và tầng ứng dụng của các nút Diameter trung gian bằng cách gửi bản tin DWR. Sự thiếu vắng của bản tin phản hồi DWA sẽ là cơ sở để xác định nguyên nhân gây lỗi.
Bản tin DPR và DPA
DPR (Disconnect Peer Request)
DPA (Disconnect Peer Answer)
Một nút Diameter có thể khởi tạo kết nối với nút Diameter ngang hàng khác, trong khi nút đó có thể lại muốn chấm dứt kết nối. Trong trường hợp này nút Diameter gửi bản tin Disconect-Peer-Request (DPR) tới nút nối với nó để báo rằng chuẩn bị chấm dứt kết nối. Bản tin DPR cũng mang ý nghĩa yêu cầu nút ngang hàng kia không khởi tạo lại kết nối trừ khi cần thiết ( ví dụ trong trường hợp chuyển tiếp bản tin).
Bản tin RAR và RAA
RAR (Re-Authentication-Request)
RAA (Re-Authentication-Answer)
Đôi lúc, đặc biệt là khi một phiên đã chấm dứt từ rất lâu, Diameter server có thể yêu cầu người dùng chứng thực lại để đảm bảo tính an ninh, bảo mật. Một Diameter server muốn chứng thực lại người dùng sẽ gửi bản tin Re-Auth-Request tới Diameter client. Diameter client sẽ hồi đáp bằng bản tin Re-Auth-Answer.
Bản tin STR và STA
STR (Session Termination Request)
STA (Session Termination Answer)
Một Diameter client gửi thông cáo về Diameter server biết rằng có một người dùng đã rất lâu không sử dụng dịch vụ, để thực hiện như vậy, Diameter client gửi bản tin Session-Termination-Request (STR). Diameter server trả lời bằng bản tin Session-Termination-Answer (STA).
Ví dụ nếu server quay số thông báo rằng thông báo rằng kết nối quay số đã bị ngưng sử dụng thì Diameter client sẽ gửi bản tin STR tới Diameter server.
Các AVP trong giao thức Diameter cơ bản
Mỗi một yêu cầu và hồi đáp định nghĩa những cặp giá trị thuộc tính (AVPs) được trình bày trong bản tin. Một vài AVP có thể là tùy trọn riêng trong yêu cầu hay hồi đáp, số khác là bắt buộc.
Sự có mặt hay không của những AVP định nghĩa chuẩn phụ thuộc vào những yêu cầu và hồi đấp thực tế. Ví dụ AVP tên là Authorization-Lifetime như trong bảng dưới thể hiện thời gian mà trong đó sự chứng thực một người dùng còn hiệu lực.
Danh sách đầy đủ của các AVP trong giao thức Diameter cơ bản rất dài. Danh sách đầy đủ có trong RFC 3588. Chúng ta sẽ tìm hiểu một vài AVP quan trọng, thường xuyên xuất hiện trong các bản tin Diameter
AVP chứa các thông tin về chứng thực, cấp quyền và tính cước. Trường AVP-Code gồm 32 bit xác định các thuộc tính
Attribute-Name
Code
Data-Type
User-Name
1
UTF8String
Session-Id
263
UTF8String
Redirect-Host
292
DiamURI
Host-IP-Address
257
Address
Class
25
OctetString
Accounting-Record-Number
485
Unsigned32
Auth-Application-Id
258
Unsigned32
Authorization-Lifetime
291
Unsigned32
Vendor-Id
266
Unsigned32
…
…
…
Một số AVP
AVP có tên User-Name biểu thị tên của người dùng trong một miền. AVP này có cấu trúc dựa trên Nhận Dạng Truy cập Mạng (Network Access Identifier – NAI) được định nghĩa trong RFC 2486 [45]. Một NAI có định dạng theo kiểu username hay username@realm. Trong IMS AVP User-Name chứa nhận dạng người dùng cá nhân (Private User Identity).
Mọi bản tin hồi đáp Diameter đều chứa một AVP có tên Result-Code. Giá trị của AVP Result-Code biểu thị yêu cầu vừa gửi có thành công hay không và nó trả lại một danh sách các giá trị có thể của AVP tùy thuộc vào từng yêu cầu và hồi đáp thực tế.
AVP có tên Origin-Host, mang đầy đủ thông tin về tên miền đủ điều kiện của nút Diameter phát sinh ra yêu cầu.
AVP có tên Destination-Host biểu thị thông tin về tên miền đủ điều kiện của Diameter server nơi tên người dùng được định nghĩa. Thỉnh thoảng người dùng không biết được tên hiện tại của server, nhưng biết về miền quản lý nơi tên người dùng là hợp lệ. Trong trường hợp này AVP Destination-Realm được sử dụng.
Bản tin yêu cầu Diameter có thể đi qua proxy hay không. Có một cờ trong phần tiêu đề của bản tin biểu thị bản tin đó có phải đi qua proxy hay không. Những bản tin có thể đi qua proxy sẽ được những proxy định tuyến tới mạng đích. Bởi vậy một yêu cầu có thể đi qua proxy thì luôn luôn chứa AVP Destination-Realm. Những bản tin không thể qua proxy sẽ được định tuyến ngay đến chặng tiếp theo và nó không bao giờ được chuyển tiếp.
Môt AVP quan trọng khác có tên Session-ID. Nó chứa một nhận dạng bao trùm cho một phiên. Tất cả các bản tin trong cùng một phiên sẽ đều có cùng một giá trị AVP Session-ID giống nhau.
Một nhóm AVP có tên Vendor-Specific-Application-Id chứa xác nhận về một ứng dụng Diameter được định nghĩa cụ thể. Vendor-Specific-Application-Id chứa một AVP Auth-Application-Id hay một Acct-Application-Id, mặc dù vậy chỉ một trong hai số chúng có mặt tại một thời điểm. AVP có tên Auth-Application-Id sẽ mang thông số về chứng thực và cấp quyền của ứng dụng. AVP có tên Acct-Application-Id sẽ mang thông tin về tính cước của ứng dụng. Vendor-Specific-Application-Id cũng chứa một AVP có tên Vendor-Id.
AVP có tên Auth-Session-State biểu thị Diameter client có muốn xác nhận trạng thái của một phiên Diameter đặc biệt, liên quan hay không. Diameter client sử dụng AVP này như là một yêu cầu, và Diameter server sẽ trả lời cũng bằng AVP đó trong bản tin hồi đáp.
Một nhóm các AVP khác có tên Proxy-Info chứa các AVP : Proxy-Host và Proxy-State, nó cũng có thể chứa một vài AVP khác. Nó cho phép một agent chưa được công nhận vẫn có một trạng thái trong yêu cầu. Hồi đáp tương ứng cũng sẽ có cùng AVP đó, bởi vậy một agent chưa được công nhận vẫn có thể lấy được thông tin trạng thái và tiếp tục quá trình trong phiên Diameter. AVP có tên Proxy-Host chứa tên của chính proxy chèn thông tin. AVP có tên Proxy-State chứa một dữ liệu ẩn được viết ra mà chỉ có chính proxy đó mới đọc được.
Một relay hay một proxy agent gắn thêm vào một AVP có tên Route-Record tới tất cả các yêu cầu. AVP Route-Record chứa nhận dạng của nút Diameter gửi yêu cầu. Điều này cho phép phát hiện vòng lập. Nó cũng cho phép Diameter server kiểm tra và cấp quyền đường đi cho một yêu cầu.
Giao diện Cx và Dx
Giao diện Cx được xây dựng để kết nối một I-CSCF hay một ...
Download miễn phí Nghiên cứu và phát triển chức năng HSS và SLF cho kiến trúc IMS
LỜI NÓI ĐẦU
Trong những năm qua xu hướng hội tụ mạng Internet, mạng di động và mạng PSTN đang là xu hướng được quan tâm hàng đầu trong lĩnh vực thông tin liên lạc. Nhiều kiến trúc mới đã ra đời trong quá trình phát triển hợp nhất các mạng với mục đích tạo ra một mạng IP duy nhất. Phân hệ IP Multmdia Subsystem (IMS) là một trong những kiến trúc đã ra đời trong xu thế phát triển đó. Với IMS, người dùng có thể liên lạc khắp mọi nơi nhờ tính di động của mạng di động và đồng thời có thể sử dụng những dịch vụ hấp dẫn từ mạng Internet. IMS đã thực sự trở thành chìa khóa để hợp nhất mạng di động và mạng Internet. IMS đồng thời cũng trở thành một phân hệ trong mô hình mạng thế hệ mới (NGN) của tất cả các hãng sản xuất các thiết bị viễn thông và các tổ chức chuẩn hóa trên thế giới.
Viện FOKUS ( Fraunhofer Institute for Open Communication Systems) đã đưa ra dự án OpenIMS. Đây là một dự án mã nguồn mở xây dựng mạng lõi IMS, rất phù hợp cho việc nghiên cứu IMS của sinh viên.
Trong thời gian thực tập tài phòng Lab C9-411 của bộ môn kỹ thuật thông tin, được sự hướng dẫn của TS Nguyễn Tài Hưng, tui đã chọn đề tài tốt nghiệp cho mình “Nghiên cứu và phát triển chức năng HSS và SLF cho kiến trúc IMS”. Đề tài liên quan nhiều đến thông tin người dùng và các dịch vụ của nhà cung cấp. Đây là những vấn đề lớn, rất quan trọng trong một mạng viễn thông.
Qua đây tui cũng xin gửi lời Thank chân thành tới TS Nguyễn Tài Hưng, TS Nguyễn Hữu Thanh và TS Nguyễn Văn Tiến đã giúp đỡ nhiệt tình cho cá nhân tui cũng như tất cả các bạn sinh viên tại phòng Lab C9-411 hoàn thành đồ án của mình.
tui xin chân thành cảm ơn!
Hà nội, ngày 21 tháng 05 năm 2008
TÓM TẮT ĐỒ ÁN
Xu hướng hội tụ mạng internet mạng di động và mạng điện thoại cố định đang ngày một trở nên cần thiết và được chú trọng. Phân hệ IMS ra đời như là một kiến trúc để đạt được mục đích đó.
Việc nghiên cứu và phát triển các chức năng của khối HSS và SLF trong kién trúc IMS có ý nghĩa quan trọng trong hoạt động của mạng IMS. Khối HSS chứa toàn bộ thông của tin người dùng gắn liền với các thông tin dịch vụ. Do vậy đồ án của tui tập trung nghiên cứu lý thuyết và có mô phỏng trên thực tế về các phần sau:
Thông tin người dùng: Nghiên cứu cấu trúc của thông tin người dùng trong IMSGiao thức Diameter: Là giao thức bao trùm lên hầu hết các hoạt động của khối HSS như: quá trình đăng ký, chứng thực, cấp quyền, tính cước, khởi tạo cuộc gọi của người dùng
MỤC LỤC
LỜI NÓI ĐẦU 1
TÓM TẮT ĐỒ ÁN 2
ABSTRACT. 3
MỤC LỤC 4
DANH SÁCH HÌNH VẼ. 7
DANH SÁCH TỪ VIẾT TẮT. 10
Chương 0 GIỚI THIỆU ĐỀ TÀI 12
0.1 Tầm quan trọng của đề tài 12
0.2 Nội dung nghiên cứu của đề tài 12
Chương 1 TỔNG QUAN KIẾN TRÚC IMS. 14
1.1 Vị trí và vai trò của phân hệ IMS trong kiến trúc mạng di động 3G 14
1.2 Các yêu cầu của IMS. 15
1.2.1 Hỗ trợ việc thiết lập các phiên Multimedia IP. 15
1.2.2 Hỗ trợ cơ chế để thỏa thuận QoS. 15
1.2.3 Hỗ trợ làm việc liên kết với mạng Internet và mạng chuyển mạch kênh (PSTN) 16
1.2.4 Hỗ trợ chuyển vùng. 16
1.2.5 Hỗ trợ điều khiển dịch vụ. 16
1.2.6 Hỗ trợ phát triển các dịch vụ. 17
1.2.7 Hỗ trợ đa truy nhập. 17
1.3 Tổng quan về các giao thức sử dụng trong IMS. 17
1.3.1 Giao thức điều khiển phiên. 17
1.3.2 Giao thức hỗ trợ chứng thực, cấp quyền, tính cước. 18
1.3.3 Các giao thức khác. 19
1.4 Tổng quan kiến trúc IMS. 19
1.4.2 CSCF - Call/Session Control Function. 21
1.4.3 Cơ sở dữ liệu : HSS và SLF. 24
1.4.4 AS (Application server) 25
1.4.5 MRF. 27
1.4.6 BGCF. 27
1.4.7 IMS-ALG và TrGW . 27
1.4.8 PSTN/CS gateway. 28
1.4.9 Mạng chủ và mạng khách. 30
1.5 Nhận dạng người dùng trong IMS. 32
1.5.1 Nhận dạng người dùng cá nhân. 34
1.5.2 Mối liên hệ giữa nhận dạng người dùng cá nhân và nhận dạng người dùng công cộng. 34
1.5.3 Nhận dạng dịch vụ công công. 36
1.5.4 SIM, USIM và ISIM trong 3GPP. 36
Chương 2 GIAO THỨC HỖ TRỢ CHỨNG THỰC, CẤP QUYỀN, TÍNH CƯỚC TRONG IMS 41
2.1 Chứng thực và cấp quyền trong IMS. 41
2.2 Giao thứ Diameter 42
2.2.1 Cấu trúc bản tin Diameter 45
2.2.2 Cặp giá trị thuộc tính. 47
2.2.3 Địa chỉ AAA và AAAS. 49
2.2.4 Giao thức Diameter cơ bản. 50
2.2.5 Các AVP trong giao thức Diameter cơ bản. 54
2.3 Giao diện Cx và Dx. 57
2.3.1 Những lệnh trong Diameter ứng dụng cho giao diện Cx. 58
2.3.2 Các AVP trong Diameter ứng dụng cho giao diện Cx. 65
2.4 Thông tin người dùng. 70
2.4.1 Cấu trúc tổng quát thông tin người dùng. 70
2.4.2 Nhận dạng công cộng. 72
2.4.3 Cấp quyền cho mạng lõi dịch vụ. 72
2.4.4 Tiêu chuẩn sàng lọc ban đầu. 73
2.5 Giao diện Sh. 75
2.5.1 Dữ liệu người dùng trên giao diện Sh. 75
2.5.2 Các lệnh định nghĩa trên Diameter ứng dụng cho giao diện Sh. 76
2.5.3 Các AVP định nghĩa trong Diameter ứng dụng cho giao diện Sh. 79
2.6 Tính cước. 81
Chương 3 PHẦN MỀM OPENIMS. 82
3.1 Giới thiệu chung về phần mềm OpenIMS của FOKUS. 82
3.2 Fokus Home Subcriber Server ( FHoSS ) 86
Chương 4 CÁC MÔ PHỎNG 91
4.1 Tạo và đăng ký người dùng mới 91
4.2 Cơ sở dữ liệu người dùng trên mysql 93
4.3 Cấu hình các dịch vụ. 96
4.4 Thống kê các bản tin Diameter trong quá trình đăng ký. 98
KẾT LUẬN 100
PHỤ LỤC 101
TÀI LIỆU THAM KHẢO 104
Để tải bản Đầy Đủ của tài liệu, xin Trả lời bài viết này, Mods sẽ gửi Link download cho bạn sớm nhất qua hòm tin nhắn.
Ai cần download tài liệu gì mà không tìm thấy ở đây, thì đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí
Tóm tắt nội dung tài liệu:
ứa các thông tin giúp cho Diameter server có thể ghi lại các sự kiện trước khi đưa ra các lệnh hay chuẩn bị chấm dứt dịch vụ.Bản tin CER và CEA
CFR (Capabilities Exchange Request)
CFA (Capabilities Exchange Answer)
Là bản tin trao đổi đầu tiên giữa hai nút Diameter, khi kết nối vận chuyển chỉ được khởi tạo một đầu. Hai bản tin này mang các thông tin về nhận dạng của nút và các thông số về lưu trữ của nó ( phiên bản của giao thức, sự hỗ trợ Diameter ứng dụng, cơ cấu hỗ trợ bảo mật…)
Bản tin DWR và DWA
DWR (Device Watchdog Request)
DWA (Device Watchdog Answer)
Nó cần thiết cho giao thức Diameter để tìm được các lỗi của tầng vận chuyển và tầng ứng dụng ngay khi có thể, do đó sẽ đưa ra được phản ứng thích hợp. Diameter có thể cung cấp việc xác định các lỗi này là dựa trên cơ chế watchdog của tầng ứng dụng. Trong suốt chu kỳ vận chuyển lưu lượng giữa hai nút Diameter, nếu như một nút gửi yêu cầu mà không nhận được hồi đáp trong một khoảng thời gian nào đó, khi ấy vẫn đủ để tìm ra lỗi ở tầng vận chuyển hay tầng ứng dụng. Tuy nhiên trong trường hợp bị thất lạc nhiều gói qui định thì không thể tìm ra lỗi được. Diameter giải quyết vấn đề này qua việc điều tra tầng vận chuyển và tầng ứng dụng của các nút Diameter trung gian bằng cách gửi bản tin DWR. Sự thiếu vắng của bản tin phản hồi DWA sẽ là cơ sở để xác định nguyên nhân gây lỗi.
Bản tin DPR và DPA
DPR (Disconnect Peer Request)
DPA (Disconnect Peer Answer)
Một nút Diameter có thể khởi tạo kết nối với nút Diameter ngang hàng khác, trong khi nút đó có thể lại muốn chấm dứt kết nối. Trong trường hợp này nút Diameter gửi bản tin Disconect-Peer-Request (DPR) tới nút nối với nó để báo rằng chuẩn bị chấm dứt kết nối. Bản tin DPR cũng mang ý nghĩa yêu cầu nút ngang hàng kia không khởi tạo lại kết nối trừ khi cần thiết ( ví dụ trong trường hợp chuyển tiếp bản tin).
Bản tin RAR và RAA
RAR (Re-Authentication-Request)
RAA (Re-Authentication-Answer)
Đôi lúc, đặc biệt là khi một phiên đã chấm dứt từ rất lâu, Diameter server có thể yêu cầu người dùng chứng thực lại để đảm bảo tính an ninh, bảo mật. Một Diameter server muốn chứng thực lại người dùng sẽ gửi bản tin Re-Auth-Request tới Diameter client. Diameter client sẽ hồi đáp bằng bản tin Re-Auth-Answer.
Bản tin STR và STA
STR (Session Termination Request)
STA (Session Termination Answer)
Một Diameter client gửi thông cáo về Diameter server biết rằng có một người dùng đã rất lâu không sử dụng dịch vụ, để thực hiện như vậy, Diameter client gửi bản tin Session-Termination-Request (STR). Diameter server trả lời bằng bản tin Session-Termination-Answer (STA).
Ví dụ nếu server quay số thông báo rằng thông báo rằng kết nối quay số đã bị ngưng sử dụng thì Diameter client sẽ gửi bản tin STR tới Diameter server.
Các AVP trong giao thức Diameter cơ bản
Mỗi một yêu cầu và hồi đáp định nghĩa những cặp giá trị thuộc tính (AVPs) được trình bày trong bản tin. Một vài AVP có thể là tùy trọn riêng trong yêu cầu hay hồi đáp, số khác là bắt buộc.
Sự có mặt hay không của những AVP định nghĩa chuẩn phụ thuộc vào những yêu cầu và hồi đấp thực tế. Ví dụ AVP tên là Authorization-Lifetime như trong bảng dưới thể hiện thời gian mà trong đó sự chứng thực một người dùng còn hiệu lực.
Danh sách đầy đủ của các AVP trong giao thức Diameter cơ bản rất dài. Danh sách đầy đủ có trong RFC 3588. Chúng ta sẽ tìm hiểu một vài AVP quan trọng, thường xuyên xuất hiện trong các bản tin Diameter
AVP chứa các thông tin về chứng thực, cấp quyền và tính cước. Trường AVP-Code gồm 32 bit xác định các thuộc tính
Attribute-Name
Code
Data-Type
User-Name
1
UTF8String
Session-Id
263
UTF8String
Redirect-Host
292
DiamURI
Host-IP-Address
257
Address
Class
25
OctetString
Accounting-Record-Number
485
Unsigned32
Auth-Application-Id
258
Unsigned32
Authorization-Lifetime
291
Unsigned32
Vendor-Id
266
Unsigned32
…
…
…
Một số AVP
AVP có tên User-Name biểu thị tên của người dùng trong một miền. AVP này có cấu trúc dựa trên Nhận Dạng Truy cập Mạng (Network Access Identifier – NAI) được định nghĩa trong RFC 2486 [45]. Một NAI có định dạng theo kiểu username hay username@realm. Trong IMS AVP User-Name chứa nhận dạng người dùng cá nhân (Private User Identity).
Mọi bản tin hồi đáp Diameter đều chứa một AVP có tên Result-Code. Giá trị của AVP Result-Code biểu thị yêu cầu vừa gửi có thành công hay không và nó trả lại một danh sách các giá trị có thể của AVP tùy thuộc vào từng yêu cầu và hồi đáp thực tế.
AVP có tên Origin-Host, mang đầy đủ thông tin về tên miền đủ điều kiện của nút Diameter phát sinh ra yêu cầu.
AVP có tên Destination-Host biểu thị thông tin về tên miền đủ điều kiện của Diameter server nơi tên người dùng được định nghĩa. Thỉnh thoảng người dùng không biết được tên hiện tại của server, nhưng biết về miền quản lý nơi tên người dùng là hợp lệ. Trong trường hợp này AVP Destination-Realm được sử dụng.
Bản tin yêu cầu Diameter có thể đi qua proxy hay không. Có một cờ trong phần tiêu đề của bản tin biểu thị bản tin đó có phải đi qua proxy hay không. Những bản tin có thể đi qua proxy sẽ được những proxy định tuyến tới mạng đích. Bởi vậy một yêu cầu có thể đi qua proxy thì luôn luôn chứa AVP Destination-Realm. Những bản tin không thể qua proxy sẽ được định tuyến ngay đến chặng tiếp theo và nó không bao giờ được chuyển tiếp.
Môt AVP quan trọng khác có tên Session-ID. Nó chứa một nhận dạng bao trùm cho một phiên. Tất cả các bản tin trong cùng một phiên sẽ đều có cùng một giá trị AVP Session-ID giống nhau.
Một nhóm AVP có tên Vendor-Specific-Application-Id chứa xác nhận về một ứng dụng Diameter được định nghĩa cụ thể. Vendor-Specific-Application-Id chứa một AVP Auth-Application-Id hay một Acct-Application-Id, mặc dù vậy chỉ một trong hai số chúng có mặt tại một thời điểm. AVP có tên Auth-Application-Id sẽ mang thông số về chứng thực và cấp quyền của ứng dụng. AVP có tên Acct-Application-Id sẽ mang thông tin về tính cước của ứng dụng. Vendor-Specific-Application-Id cũng chứa một AVP có tên Vendor-Id.
AVP có tên Auth-Session-State biểu thị Diameter client có muốn xác nhận trạng thái của một phiên Diameter đặc biệt, liên quan hay không. Diameter client sử dụng AVP này như là một yêu cầu, và Diameter server sẽ trả lời cũng bằng AVP đó trong bản tin hồi đáp.
Một nhóm các AVP khác có tên Proxy-Info chứa các AVP : Proxy-Host và Proxy-State, nó cũng có thể chứa một vài AVP khác. Nó cho phép một agent chưa được công nhận vẫn có một trạng thái trong yêu cầu. Hồi đáp tương ứng cũng sẽ có cùng AVP đó, bởi vậy một agent chưa được công nhận vẫn có thể lấy được thông tin trạng thái và tiếp tục quá trình trong phiên Diameter. AVP có tên Proxy-Host chứa tên của chính proxy chèn thông tin. AVP có tên Proxy-State chứa một dữ liệu ẩn được viết ra mà chỉ có chính proxy đó mới đọc được.
Một relay hay một proxy agent gắn thêm vào một AVP có tên Route-Record tới tất cả các yêu cầu. AVP Route-Record chứa nhận dạng của nút Diameter gửi yêu cầu. Điều này cho phép phát hiện vòng lập. Nó cũng cho phép Diameter server kiểm tra và cấp quyền đường đi cho một yêu cầu.
Giao diện Cx và Dx
Giao diện Cx được xây dựng để kết nối một I-CSCF hay một ...