nghiên cứu và phát triển chức năng hss và slf cho kiến trúc ims

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 ĐẦUTrong 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, tôi đã 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 tôi cũng xin gửi lời cảm ơn 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 tôi 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.

Tôi xin chân thành cảm ơn!

Hà nội, ngày 21 tháng 05 năm 2008

Sinh viên: Đào Anh Hà

TÓM TẮT ĐỒ ÁNXu 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 tôi 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 IMS

Đào Anh Hà – Điện tử 4 – K48 -ĐHBKHN 1


Giao 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…



ABSTRACTNowadays, the tendency of converging the Internet and the Cellular Worlds not

only becomes more and more essential. Therefore, IMS architecture is created to achieve this goal.

Researching and developing HSS and SLF functions take important role in IMS operation. In addition, HSS contains complete user and service profiles. As a result, my thesis is concentrated on studying about following theories and practical simulations:

User information: Researching about the structure of user profiles in IMS architecture

Diameter protocol: a crucial protocol used in almost HSS activities including registering, authentication, authorization, accounting, initiating user call…



MỤC LỤCLỜ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



DANH SÁCH HÌNH VẼChương 0 GIỚI THIỆU ĐỀ TÀI.....................................................................12

Chương 1 TỔNG QUAN KIẾN TRÚC IMS...................................................14

Hình 1.1 Kiến trúc của mạng UMTS..................................................14

Hình 1.2 Tổng quan kiến trúc IMS......................................................20

Hình 1.3 Cấu trúc của HSS..................................................................24

Hình 1.4 Application Server................................................................26

Hình 1.5 IMS-ALG và TrGW.............................................................28

Hình 1.6 PSTN/CS Getway giao tiếp với một mạng CS.....................29

Hình 1.7 P-CSCF đặt tại mạng khách..................................................31

Hình 1.8 P-CSCF đặt tại mạng chủ.....................................................32

Hình 1.9 Mối liên hệ giữa nhận dạng người dùng cá nhân và công cộng trong Realese 5................................................................................35

Hình 1.10 Mối liên hệ giữa nhận dạng người dùng cá nhân và công cộng trong Release 6.................................................................................35

Hình 1.11 Cấu trúc đơn giản hóa của USIM.........................................37

Hình 1.12 Cấu trúc của ứng dụng ISIM................................................39

Chương 2 GIAO THỨC HỖ TRỢ CHỨNG THỰC, CẤP QUYỀN, TÍNH CƯỚC TRONG IMS...........................................................................................41

Hình 2.1 Sơ đồ xác thực và cấp quyền trong IMS...............................42

Hình 2.2 Giao thức Diameter cơ bản và các ứng dụng........................43

Hình 2.3 Cấu trúc bản tin Diameter.....................................................46

Hình 2.4 Cấu trúc của AVP.................................................................48

Hình 2.5 Các lệnh cơ bản của Diameter..............................................51

Hình 2.6 Một số AVP..........................................................................55

Hình 2.7 Các lệnh định nghĩa bởi Diameter ứng dụng cho giao diện Cx..............................................................................................59

Hình 2.8 Bản tin UAR/UAA, MAR/MAA, SAR,SAA trong quá trình đăng ký ..............................................................................................61

Hình 2.9 Bản tin LIR/LIA và bản tin SAR/SAA.................................63

Hình 2.10 Bản tin RTR/RTA.................................................................64

Hình 2.11 Bản tin PPR/PPA..................................................................65

Hình 2.12 Các AVP định nghĩa bởi Diameter ứng dụng cho giao diện Cx ..............................................................................................66



Hình 2.13 Cấu trúc thông tin người dung..............................................71

Hình 2.14 Cấu trúc tiêu chuẩn sàng lọc ban đầu...................................73

Hình 2.15 Danh sách lệnh được định nghĩa bởi Diameter ứng dụng cho giao diện Sh ..............................................................................................77

Hình 2.16 Bản tin UDR/ UDA..............................................................77

Hình 2.17 Bản tin PUR/PUA.................................................................78

Hình 2.18 Bản tin SNR/SNA và bản tin PNR/PNA..............................79

Hình 2.19 Các AVP định nghĩa bởi Diameter ứng dụng cho giao diện Sh ..................................................................................................

80

Chương 3 PHẦN MỀM OPENIMS.................................................................82

Hình 3.1 Các thành phần của OpenIMS..............................................83

Hình 3.2 OpenIMS Client khi chạy lần đầu tiên.................................84

Hình 3.3 FHoSS trong OpenIMS........................................................86

Hình 3.4 Giao diện web quản lý FHoSS.............................................87

Hình 3.5 Trang cấu hình nhận dạng người dùng cá nhân....................88

Hình 3.6 Trang cấu hình thông tin dịch vụ..........................................89

Hình 3.7 Cấu trúc thư mục của FHoSS...............................................89

Chương 4 CÁC MÔ PHỎNG..........................................................................91

Hình 4.1 Cấu hình thông số IMSU......................................................91

Hình 4.2 Cấu hình thông số IMPI........................................................92

Hình 4.3 Cấu hình thông số IMPU......................................................93

Hình 4.4 Cơ sở dữ liệu trong FhoSS...................................................94

Hình 4.5 Sơ đồ thực thể liên kết rút gọn của cơ sở dữ liệu trong FHoSS ..................................................................................................

95

Hình 4.6 Một số máy chủ ứng dụng đã khởi tạo và chạy thử..............96

Hình 4.7 Một số điểm kích hoạt đã tạo................................................97

Hình 4.8 Một số tiêu chuẩn lọc ban đầu đã được tạo..........................98

Hình 4.9 Một số bản tin trong quá trình đăng ký................................99



DANH SÁCH TỪ VIẾT TẮT

3GPP3rd Generation Partnership Project

Dự án cộng tác mạng thế hệ thứ 3

AAAAuthentication Authorization Accounting

Chứng thực, cấp quyền, tính cước

AS Application Server Máy chủ ứng dụng

AuC Authetication Center Trung tâm nhận thực

AVP Atribute Value Pair Cặp giá trị thuộc tính

CSCFCall/Session Control Function

Khối chức năng điều khiển phiên và cuộc gọi

DNS Domain Name System Hệ thống tên miền

FQDNFully Qualified Domain Name

Tên miền đủ điểu kiện

GGSNGetway GPRS Suport Node

Cổng hỗ trợ nút GPRS

GPRSGeneral Packet Radio Service

Dịch vụ chuyển gói rộng khắp qua sóng vô tuyến

HLR Home Location Register Bộ đăng ký vị trí máy chủ

HSS Home Subcriber Server Máy chủ thuê bao

IANAInternet Assigned Numbers Authority

Tổ chức cấp phát số hiệu internet

IETFInternet Engineering Task Force

Lực lượng quản lý kỹ thuật

IFC Initial Filter Criteria Tiêu chuẩn sàng lọc ban đầu



IMSIP Multimedia Subsystem

Phân hệ IP đa phương tiện

IMSIInternational Mobile Subscriber Identity

Nhận dạng thuê bao di động quốc tế

IP Internet Protocol Giao thức mạng

IPsecInternet Protocol security

Giao thức bảo mật mạng

ITUInternational Telecommunication Union

Hiệp hội viễn thông quốc tế

MRF Media Resource Funtion Chức năng tài nguyên media

MSCMobile Switching Center

Trung tâm chuyển mạch di động

PDFPolicy Decision Function

Khối chức năng giải quyết chính sách

RADIUSRemote Authentication Dial In User Service

Dịch vụ chứng thực cuộc gọi người dùng từ xa

RTPReal-Time Transport Protocol

Giao thức vận chuyển thời gian thực

SDPSession Description Protocol

Giao thức mô tả phiên

SGSNServing GPRS Support Node

Nút hỗ trợ phục vụ GPRS

SIPSession Initiation Protocol

Giao thức khởi tạo phiên

SLFSubcriber Location Function

Khối chức năng vị trí thuê bao

SP Service Point Điểm dịch vụ

TP Triger Point Điểm kích hoạt dịch vụ

UMTSUniversal Mobile Telecommunication System

Hệ thống viễn thông di động quốc tế



Chương 0 GIỚI THIỆU ĐỀ TÀI0.1 Tầm quan trọng của đề tài

Ngày nay, với sự phát triển không ngừng của khoa học kỹ thuật đặc biệt là trong lĩnh vực viễn thông, các dịch vụ được phát triển ngày càng trở nên phong phú, đa dạng. Sự ra đời và phát triển nhanh chóng của Internet càng tạo ra nền tảng cho việc phát triển cho rất nhiều dịch vụ. Với mong muốn kết hợp các dịch vụ Internet và các dịch vụ di động truyền thống, các nhà phát triển đã không ngừng nghỉ trong việc sáng tạo ra các kiến trúc mạng mới, các công nghệ mới nhằm thực hiện mục đích này. Sự ra đời của phân hệ IMS trong kiến trúc mạng 3G chính là bước phát triển quan trọng trong quá trình hợp nhất các dịch vụ đó.

Việc quản lý các dịch vụ, đưa dịch vụ đến với người dùng, quản lý thông tin người dùng, tính cước… có vai trò quan trọng trong quá trình triển khai IMS.

Thông tin người dùng phải được xây dựng sao cho có thể dễ dàng xác lập và thay đổi các gói dịch vụ khác nhau cho từng người dùng tùy theo nhu cầu. Cấu trúc thông tin người dùng phải đồng nhất cho nhiều loại thiết bị đầu cuối khác nhau.

Vấn đề an ninh, bảo mật, chứng thực, cấp quyền, tính cước cũng cần được quan tâm một cách kỹ lưỡng. Bởi lẽ trong hoàn cảnh hiện nay khi công nghệ thông tin phát triển như vũ bão thì đi kèm với nó cũng tiềm ẩn rất nhiều nguy cơ như virus, hacker, trộm cắp tài khoản, trộm cước…

0.2 Nội dung nghiên cứu của đề tài

Với mục đích nghiên cứu phát triển khối HSS và IFC cho kiến trúc IMS, đề tài của tôi bao gồm các nội dung chính sau:

Chương 1 Tổng quan kiến trúc IMS: Tìm hiểu về kiến trúc IMS, các thành phần, chức năng của từng thành phần và kiến trúc triển khai

Chương 2 Giao thức hỗ trợ chứng thực, cấp quyền, tính cước trong IMS: Trình bày về giao thức Diameter và cấu trúc cơ sở dữ liệu người dùng.

Chương 3 Phần mềm OpenIMS: Giới thiệu về mã nguồn mở OpenIMS của viện FOKUS, trong đó tập trung vào modul FHoSS quản lý cơ sở dữ liệu người dùng

Chương 4 Các mô phỏng: Trình bày các công việc làm được trong việc mô phỏng, chạy thử phần mềm OPENIMS

Chương 5 Kết luận: Các kết luận và hướng phát triển của đề tài.



Chương 1 TỔNG QUAN KIẾN TRÚC IMS

Trong chương này ta sẽ tìm hiểu về vị trí và vai trò của phân hệ IMS trong kiến trúc mạng di động 3G, những yêu cầu khi xây dựng phân hệ IMS và tổng quan về các giao thức, các thành phần chức năng và các cách nhận dạng người dùng trong kiến trúc IMS.

1.1 Vị trí và vai trò của phân hệ IMS trong kiến trúc mạng di động 3G

Mạng di động 3G được phân chia logic thành mạng truy nhập (Access Network) và mạng lõi (Core Network). Phía trên cơ sở hạ tầng mạng là nền tảng dịch vụ được sử dụng để tạo ra các dịch vụ khác nhau. Hình 1.1 chỉ ra kiến trúc mạng 3G UMTS.

Hình 1.1 Kiến trúc của mạng UMTS

Mạng hỗ trợ hai kiểu mạng truy nhập khác nhau:

- Base-station System (BSS) là mạng truy cập GSM

- Radio Network Subsystem (RNS) là mạng truy cập UMTS.



Mạng lõi bao gồm miền chuyển mạch kênh (CS) và miền chuyển mạch gói (PS). Hai miền này khác nhau trong cách chúng xử lý dữ liệu. Miền chuyển mạch kênh dành sẵn các kênh cho lưu lượng của người dùng. Do đó được sử dụng cho các dịch vụ thời gian thực và dịch vụ hội đàm như dịch vụ thoại và dịch vụ hội nghị video. Miền chuyển mạch gói được sử dụng cho các ứng dụng dữ liệu gói từ đầu cuối đến đầu cuối như truyền file, truy cập web và e-mail.

Phân hệ IMS như trong hình vẽ là một phần trong miền chuyển mạch gói. Chức năng của IMS là cung cấp các dịch đa phương tiện trên nền IP, bao gồm các dịch vụ thời gian thực như trong miền chuyển mạch kênh. Do đó IMS sẽ làm cho miền chuyển mạch kênh dần dần được thay thế trong tương lai.

1.2 Các yêu cầu của IMS

IMS được xây dựng và phát triển với mục đích phải kết hợp được những xu hướng công nghệ mới nhất, làm cho mô hình Internet - Mobile trở thành hiện thực, tạo ra một nền tảng chung để phát triển các dịch vụ multimedia đa dạng và tạo ra nhiều lợi nhuận hơn trong việc thúc đẩy khách hàng sử dụng miền chuyển mạch gói trong 3G. Để đạt được những mục đích đó thì IMS đã được định nghĩa như là một nền tảng kiến trúc để truyền tải các dịch vụ multimedia IP tới người dùng cuối. Nền tảng đó phải thực hiện được những yêu cầu sau:

1.2.1 Hỗ trợ việc thiết lập các phiên Multimedia IP

IMS có thể truyền tải các dịch vụ đa dạng.Yêu cầu này nhấn mạnh sự cần thiết để cung cấp các dịch vụ chính được truyền tải bởi IMS đó là các phiên multimedia qua mạng chuyển mạch gói. Kiểu media trong trường hợp này có thể là audio hoặc video. Truyền thông multimedia đã được chuẩn hóa trong các chuẩn hóa trước đây của 3GPP nhưng những kiểu truyền thông multimedia này được thực hiện qua mạng chuyển mạch kênh chứ không phải qua mạng chuyển mạch gói.

1.2.2 Hỗ trợ cơ chế để thỏa thuận QoS

QoS là một trong các vấn đề quan trọng nhất của IMS. QoS cho một phiên multimedia cụ thể được quyết định bởi nhiều nhân tố như băng thông lớn nhất. Băng thông lớn nhất có thể được cấp phát cho người dùng dựa trên đăng ký của người dùng hoặc dựa trên tình trạng hiện tại của mạng.

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)

Hỗ trợ làm việc liên kết vơi Internet là một yêu cầu rõ ràng. Mạng Internet sẽ là đích đến của hàng triệu phiên multimedia được bắt đầu trong IMS. Khi yêu cầu này đạt được thì số lượng các phiên multimeda sẽ được tăng lên đáng kể.

IMS đồng thời cũng hỗ trợ làm việc liên kết với mạng PSTN. Những thiết bị đầu cuối IMS đầu tiên sẽ có khả năng kết nối đồng thời với mạng chuyển mạch kênh và mạng chuyển mạch gói. Vì thế khi một người dùng muốn gọi cho một người dùng khác ở trong PSTN hay ở trong mạng di động thì thiết bị đầu cuối IMS chọn miền chuyển mạch kênh để sử dụng.



Mặc dù yêu cầu làm việc liên kết với mạng chuyển mạch kênh là một yêu cầu không bắt buộc nhưng hầu hết các thiết bị đầu cuối IMS sẽ hỗ trợ miền chuyển mạch kênh. Vì thể yêu cầu này có thể được xem như yêu cầu dài hạn.

1.2.4 Hỗ trợ chuyển vùng

Hỗ trợ chuyển vùng là một yêu cầu cơ bản kể từ mạng di động thế hệ thứ hai. Chuyển vùng giúp người dùng có thể liên lạc khi sang một mang khách. IMS thừa kế yêu cầu này giúp người dùng duy trì kết nối khi di chuyển sang đất nước khác.

1.2.5 Hỗ trợ điều khiển dịch vụ

IMS giúp nhà cung cấp dịch vụ có thể đưa ra những chính sách với những dịch vụ mà họ cung cấp cho người dùng. Có thể chia những dịch vụ này thành 2 loại:

+ Những chính sách áp dụng chung đối với tất cả người sử dụng trong mạng.

+ Những chính sách áp dụng riêng lẻ đối với những người dùng cụ thể.

Những chính sách chung bao gồm một số các giới hạn do các nhà cung cấp dịch vụ đưa ra như giới hạn sử dụng các bộ codec dung lượng lớn như G711 trong mạng của họ Thay vào đó họ có thể áp dụng những bộ codec dung lượng nhỏ như AMR.

Những chính sách riêng lẻ ngược lại được gắn với mỗi một người dùng cụ thể. Ví dụ khi một người dùng có thể có một vài đăng ký để sử dụng các dịch vụ IMS mà không bao gồm video. Thiết bị đầu cuối IMS có thể hỗ trợ video nhưng trong trường hợp người dùng cố gắng để bắt đầu một phiên multimedia mà bao gồm video thì nhà cung cấp sẽ chặn phiên này.

1.2.6 Hỗ trợ phát triển các dịch vụ

Yêu cầu này ảnh hưởng mạnh mẽ đến thiết kế kiến trúc IMS.Yêu cầu này khẳng định rằng các dịch vụ IMS không cần phải tiêu chuẩn hóa. Nó đánh dấu một cột mốc quan trọng trong thiết kế mạng di động, bởi vì trước đây, tất cả các dịch vụ riêng lẻ hoặc là phải chuẩn hóa hoặc là được thực hiện độc quyền. Thậm chí khi một dịch vụ đã được chuẩn hóa, cũng không có một đảm bảo chắc chắn dịch vụ sẽ làm việc khi chuyển vùng sang một mạng khác. IMS giúp cho triển khai các dịch vụ mới đến người dùng nhanh hơn. Trước đây, sự chuẩn hóa các dịch vụ và công việc kiểm tra gây ra sự chậm chễ đáng kể trong việc triển khai dịch vụ. IMS làm giảm đáng kể sự chậm trễ này bằng cách tiêu chuẩn hóa khả năng dịch vụ thay vì chuẩn hóa dịch vụ riêng lẻ.

1.2.7 Hỗ trợ đa truy nhập

Yêu cầu này giới thiệu các phương thức truy nhập khác ngoài GPRS.IMS chỉ là một mạng IP và do đó bất cứ một mạng truy nhập nào cũng có thể cung cấp sự truy nhập tới nó. IMS có thể được truy nhập từ mạng WLAN (Wireless Local Area Network), từ một ADSL …

1.3 Tổng quan về các giao thức sử dụng trong IMS

Kiến trúc IMS do 3GPP phát triển dựa trên các giao thức IP được chuẩn hóa bởi IETF. Giao thức IP bao gồm các giao thức về điều khiển phiên, các giao thức về chứng thực, cấp quyền và tính toán (AAA) và một số các giao thức khác.



1.3.1 Giao thức điều khiển phiên

Các giao thức điều khiển cuộc đóng vai trò chìa khóa trong bất kì một hệ thống điện thoại nào. Trong mạng chuyển mạch kênh, các giao thức điều khiển cuộc gọi quan trọng nhất là TUP (Telephony User Part, ITU-T khuyến nghị Q.721), ISUP ( ISDN User Part, ITU-T, khuyến nghị Q.761) và BICC (Bearer Independent Call Control, ITU-T khuyến nghị Q.1901).

SIP đã được chọn là giao thức điều khiển phiên cho IMS trong nhiều giao thức điều khiển phiên phiên dựa trên IP khác như BICC và H323. SIP được IETF chuẩn hóa trong RFC 3261 (Request for Command). SIP tuân theo mô hình khách - chủ (client-server). SIP được thiết kế dựa trên các nguyên lý cơ bản từ hai giao thức HTTP, SMTP. Nên SIP thừa kế hầu hết các đặc tính quan trọng của hai giao thức này. Điều này tạo ra sức mạnh cho nó bởi HTTP và SMTP là các giao thức đã rất thành công trong mạng Internet. Không giống như H323 và BICC, SIP không phân biệt giao diện người dùng tới mạng (User-to-Network) với giao diện mạng với mạng (Network-to-Network). Trong mô hình SIP chỉ có một giao thức duy nhất hoạt động thông suốt. Ngoài ra SIP là một giao thức dưới dạng văn bản do đó nó dễ dàng mở rộng, gỡ rối và phát triển các dịch vụ.

1.3.2 Giao thức hỗ trợ chứng thực, cấp quyền, tính cước

Diameter dựa trên RFC 3588 được chọn là giao thức AAA trong mạng IMS. Diameter được phát triển từ giao thức RADIUS (RFC 2865) là một giao thức được sử dụng phổ biến trong Internet để thực hiện chứng thực, cấp quyền và tính cước. Ví dụ khi một người dùng quay số đến một nhà cung cấp dịch vụ Internet, máy chủ truy nhập mạng sử dụng RADIUS để chứng thực cấp quyền cho user.

Diameter bao gồm một giao thức cơ bản và giao thức này được bổ sung bởi các Diameter ứng dụng. Các Diameter ứng dụng là các tùy biến hoặc là các mở rộng Diameter để phù hợp với các môi trường cụ thể.

IMS sử dụng Diameter trong nhiều giao diện, mặc dù vậy các giao diện này có thể sử dụng các ứng dụng Diameter khác nhau. Ví dụ IMS sử dụng một Diameter ứng dụng trong quá trình thiết lập cuộc gọi nhưng lại sử dụng một Diameter ứng dụng khác trong tính cước.

1.3.3 Các giao thức khác

Bên cạnh SIP và Diameter, IMS còn sử dụng nhiều giao thức khác. Giao thức dịch vụ chính sách mở thông thường COPS (Common Open Policy Service) được dùng để truyền tải chính sách giữa các điểm quyết định dịch vụ PDPs (Policy Decision Points) và các điểm thực hiện chính sách ( Policy Enforcement Points).

H.248 (ITU-T khuyến nghị H.248) được sử dụng bởi các nút báo hiệu để điều khiển các nút trong mặt phẳng media.

RTP (Real-Time Transport Protocol, RFC 3550) và RCTP (RTP Control Protocol, RFC 3550) dùng để truyền tải media như video và audio.



1.4 Tổng quan kiến trúc IMS

IMS không được chuẩn hoá theo các nút mà dựa trên chức năng. Điều này có nghĩa là kiến trúc IMS là một tập hợp các chức năng được liên kết với nhau bởi các giao diện. Các chức năng có thể được kết hợp lại trong môt nút hoặc một chức năng thể được tách ra thực hiện trong 2 nút hoặc nhiều hơn. Thông thường các nhà cung cấp thường thực hiện một chức năng trong mỗi nút riêng lẻ.

Hình 1.1 Tổng quan kiến trúc IMS

Hình vẽ 1.2 thể hiện tổng quan kiến trúc IMS. Trong hình vẽ này các giao diện báo hiệu trong IMS được thể hiện bằng hai hoặc ba chữ cái.

Bên phải của hình vẽ là các thiết bị IMS. Phía dưới là thiết bị di động IMS thường được gọi là thiết bị người dùng UE. Thiết bị đầu cuối IMS kết nối tới mạng chuyển mạch gói thông qua liên kết vô tuyến. IMS đồng thời cũng hỗ trợ các kiểu truy nhập và các thiết bị khác như PDA (Personal Digital Assistant) và máy tính. Các thiết bị này có thể truy nhập qua ADSL hoặc WLAN.

Phần còn lại của hình vẽ chỉ ra các nút chức năng khác trong kiến trúc lõi của IMS bao gồm:

+ Cơ sở dữ liệu người dùng: HSS (Home Subcriber Servers) và SLF (Subcriber Location Function).

+ Chức năng điều khiển phiên, cuộc gọi: CSCF (Call /Sesion Control Function)

+ Chức năng liên quan đến nguồn media: MRF (Media Resource Fuction) bao gồm bộ điều khiển chức năng nguồn media MRFC (Media Resource Function Controller) và bộ xử lý chức năng nguồn media MRFP (Media Resource Function Processor).

+ BGCF (Breakout Gateway Control Function).



+ PSTN gateway bao gồm SGW (Signalling Gateway), MGCF (Media Gateway Controller Function) và MGW (Media Gateway).

1.4.2 CSCF - Call/Session Control Function.

CSCF là một SIP server. Nó là thành phần cơ bản nhất trong kiến trúc IMS.

CSCF xử lý báo hiệu SIP. Có ba kiểu khác nhau của CSCF:

+ Proxy –CSCF (P-CSCF)

+ Serving –CSCF (S-CSCF)

+ Interrogating –CSCF I-CSCF)

Mỗi CSCF có những chức năng đặc biệt của chúng. Tất cả góp phần tạo thành bộ máy định tuyến bản tin SIP. Ngoài ra chúng có thể gửi các thông tin tính cước tới chức năng tính cước ngoại tuyến.

1.4.2.1 P-CSCF

P-CSCF là điểm liên lạc đầu tiên giữa thiết bị đầu cuối và mạng IMS. Trong mô hình của SIP thì P-CSCF đang làm việc như một oubound/inbound SIP proxy server. Tất cả các bản tin SIP được khởi tạo bởi một thiết bị đầu cuối IMS hoặc gửi đến thiết bị đầu cuối IMS đều phải đi qua P-CSCF. P-CSCF chuyển tiếp các bản tin SIP: yêu cầu và hồi đáp theo các hướng phù hợp hoặc là đi tới thiết bị IMS hoặc là tới mạng IMS.

P-CSCF được chỉ định cho các thiết bị đầu cuối IMS trong quá trình đăng ký và không thay đổi trong quá trình này.

P-CSCF bao gồm nhiều chức năng khác nhau và một trong số chúng liên quan tới bảo mật. Nó thiết lập một số liên kết đảm bảo IPsec với các thiết bị đầu cuối IMS. Những liên kết bảo mật Ipsec này đảm bảo sự toàn vẹn thực thể, ví dụ như khả năng để dò tìm nội dung của bản tin có bị thay đổi từ khi nó được tạo ra hay không.

Một khi P-CSCF đã chứng thực người dùng (như là một phần của sự thiết lập liên kết bảo mật) thì các nút khác trong mạng không cần phải thực hiện các chứng thực người dùng khác nữa vì chúng tin tưởng vào P-CSCF. Sự xác nhận của P-CSCF còn có các chức năng khác như cung cấp các dịch vụ cho các cá nhân và các bản ghi tính cước.

Một chức năng khác nữa của P-CSCF là chúng kiểm tra sự chính xác của bản tin SIP yêu cầu được gửi bởi thiết bị đầu cuối IMS. Chức năng này giúp ngăn chặn các thiết bị đầu cuối gửi các bản tin SIP không chính xác.

P-CSCF bao gồm một bộ phận nén và giải nén các bản tin SIP (thiết bị đầu cuối IMS cũng bao gồm chức năng này). Bản tin SIP đôi khi có thể rất lớn. Trong khi gửi một bản tin qua một kết nối băng thông rộng chỉ mất một thời gian ngắn thì việc gửi một bản tin SIP qua một kênh băng thông hẹp, như một kết nối vô tuyến chẳng hạn, sẽ mất một vài giây. Cơ chế dùng để rút ngắn thời gian truyền một bản tin là nén bản tin lại, truyền qua liên kết vô tuyến và giải nén bên phía nhận.

P-CSCF có thể bao gồm một PDF. PDF cấp quyền sử dụng media và quản lý QoS trên mặt phẳng media.



P-CSCF đồng thời tạo ra các thông tin tính cước tới các nút thu thập thông tin tính cước.

Với mục đích mở rộng và tạo ra dư thừa để dự phòng thông thường trong một mạng IMS có nhiều P-CSCF. Mỗi một P-CSCF phục vụ một số thiết bị đầu cuối IMS phụ thuộc vào dung lượng của nó.

P-CSCF có thể được đặt tại mạng khách hoặc mạng chủ. Trong trường hợp mạng chuyển mạch gói dựa trên GPRS thì P-CSCF luôn đặt trong cùng một mạng với GGSN. Vì vậy GGSN và P-CSCF có thể cùng đặt tại mạng khách hoặc tại mạng chủ.

1.4.2.2 I-CSCF

I-CSCF là SIP proxy được đặt tại biên của miền quản trị. Địa chỉ của I-CSCF luôn được liệt kê trong các bản ghi DNS của miền. Khi một SIP server tuân theo các thủ tục SIP để tìm chặng SIP tiếp theo cho một bản tin SIP sẽ nhận được địa chỉ của I-CSCF trong miền đích.

Ngoài chức năng là một SIP server, I-CSCF còn có một giao diện tới SLF và HSS. Giao diện này dựa trên giao thức Diameter. Qua giao diện này I-CSCF truy vấn các thông tin về vị trí của người dùng và định tuyến các bản tin SIP tới địa chỉ phù hợp.

I-CSCF còn có chức năng mã hóa một phần bản tin SIP đang chứa đựng những thông tin nhạy cảm về miền, như số lượng các server trong miền, tên DNS và dung lượng của chúng.

Một mạng IMS thường bao gồm nhiều I-CSCF cho mục đích mở rộng và tạo dư thừa.

I-CSCF thường nằm tại mạng chủ, mặc dù trong một số trường hợp đặc biệt nó có thể được đặt tại mạng khách.

1.4.2.3 S-CSCF

S-CSCF là nút trung tâm trong mặt phẳng báo hiệu. Ngoài chức năng là một SIP server, S-CSCF còn đóng vai trò là một SIP registrar. Nó duy trì một gán kết giữa vị trí của người dùng (như địa chỉ IP của thiết bị đầu cuối mà người dùng đăng nhập) và địa chỉ SIP của người dùng trong bản ghi.

Giống như I-CSCF, S-CSCF cũng đồng thời thực hiện giao diện tới HSS để thực hiện các mục đích sau:

+ Tải về các vector chứng thực của người dùng đang truy nhập vào mạng. S-CSCF sử dụng các vector này để chứng thực người dùng.

+ Tải về hồ sơ người dùng từ HSS. Hồ sơ người dùng bao gồm hồ sơ dịch vụ .

+ Thông báo cho HSS rằng S-CSCF này sẽ phục vụ người dùng trong khoảng thời gian đăng ký.

Tất cả báo hiệu SIP mà thiết bị đầu cuối IMS gửi và nhận đều đi qua S-CSCF .

S-CSCF giám sát từng bản tin SIP và quyết định xem báo hiệu SIP sẽ đi qua một hay nhiều server ứng dụng hoặc để định tuyến tới đích cuối cùng.



Một trong những chức năng chính của S-CSCF là cung cấp chức năng định tuyến bản tin SIP. Nếu một người dùng quay một số điện thoại thay vì một SIP URI thì S-CSCF cung cấp dịch vụ chuyển đổi địa chỉ, thường dựa trên DNS E.164 Number Translation (IETF).

S-CSCF đồng thời thi hành các chính sách của nhà điều hành mạng. Ví dụ một người dùng không có quyền để thiết lập một loại phiên cụ thể như phiên video chẳng hạn. Nói cách khác, S-CSCF ngăn chặn người dùng thực hiện những dịch vụ không được cho phép.

S-CSCF luôn luôn nằm tại mạng chủ.

1.4.3 Cơ sở dữ liệu : HSS và SLF

HSS và SLF là hai cơ sở dữ liệu chính trong kiến trúc IMS.

HSS lưu trữ dữ liệu cho tất cả các thuê bao và tất cả dữ liệu liên quan đến dịch vụ của IMS. Dữ liệu được lưu trữ trong HSS bao gồm nhận dạng, thông tin đăng ký thuê bao, tham số truy nhập và thông tin kích hoạt dịch vụ. Thông tin nhận dạng gồm có hai loại: Nhận dạng người dùng công cộng và nhận dạng người dùng cá nhân. Nhận dạng người dùng cá nhân được sử dụng cho mục đích đăng ký và cấp quyền, trong khi đó nhận dạng người dùng công cộng được người dùng sử dụng để liên lạc với những người dùng khác. Các tham số truy nhập IMS được khởi tạo để thết lập một phiên và bao gồm các thông số giống như chứng thực người dùng, cấp quyền chuyển vùng và tên của S-CSCF phụ trách người dùng. Thông tin kích họat dịch vụ cho phép thực hiện các dịch vụ SIP.

HSS cũng bao gồm một số các chức năng của bộ đăng ký vị trí chủ (HLR) và trung tâm nhận thực (AuC).

Hình 1.1 Cấu trúc của HSS

Chức năng HLR hỗ trợ các thực thể trong miền chuyển mạch gói như SGSN và GGSN. Điều này cho phép các thuê bao truy nhập tới các dịch vụ trong miền chuyển mạch gói. HLR đồng thời cũng hỗ trợ các thực thể trong miền chuyển mạch kênh như MSC/MSC servers. Điều này cũng cho phép các thuê bao có thể truy nhập các dịch vụ trong miền chuyển mạch kênh và hỗ trợ chuyển vùng tới những mạng có miền chuyển mạch kênh.



AuC lưu trữ chìa khóa bí mật cho mỗi một thuê bao di động. Chìa khóa này được sử dụng để tạo ra dữ liệu bảo mật linh động cho mỗi một thuê bao. Dữ liệu được sử dụng cho sự nhận thực lẫn nhau giữa mạng và IMSI (International Mobile Subscriber Identity). Dữ liệu bảo mật cung cấp sự toàn vẹn thực thể và mã hóa thông tin liên lạc qua đường vô tuyến giữa thiết bị đầu cuối và mạng.

Một mạng có thể có nhiều hơn một HSS, phụ thuộc vào số lượng thuê bao và khả năng của các thiết bị và tổ chức của mạng.

Nếu mạng có một HSS không cần phải có SLF (Subscription Location function). Ngược lại nếu mạng có nhiều hơn một HSS nhất thiết phải có SLF. SLF là một cơ sở dữ liệu đơn giản dùng để ánh xạ địa chỉ thuê bao với HSS tương ứng quản lý thuê bao đó. Khi một nút khác truy vấn SLF với đầu vào là một địa chỉ thuê bao thì sẽ nhận được địa chỉ của HSS tương ứng chứa các thông tin liên quan đến thuê bao như là đầu ra.

HSS và SLF thực hiện giao thức Diameter với các ứng dụng Diameter xác định cho IMS.

1.4.4 AS (Application server)

AS là các thực thể SIP đảm nhận và thực hiện các dịch vụ. Phụ thuộc vào dịch vụ thực tế mà AS có thể hoạt động ở các chế độ SIP proxy, SIP UA hoặc SIP B2BUA. AS giao tiếp với S-CSCF bằng SIP

Hình 1.1 Application Server



AS gồm ba loại:

SIP AS: Đây là các AS cơ sở thực hiện các dịch vụ multimedia dựa trên SIP. Các dịch vụ IMS mới sẽ được phát triển trong SIP AS.

OSA-SCS (Open Service Access-Service Capability Server): Đây là AS cung cấp giao diện tới các ứng dụng nền tảng OSA. Nó thừa kế tất cả các khả năng của dịch vụ mở, đặc biệt khả năng để truy nhập một cách bảo mật vào các mạng bên ngoài. Nút này một mặt đóng vai trò là AS và mặt khác là một giao diện giữa OSA AS và giao diện lập trình ứng dụng OSA.

IM-SSF ( IP Multimedia Service Switching Function): AS này cho phép tái sử dụng dịch vụ CAMEL (Customized Application for Mobible Network Enhanced Logic) được phát triển cho GSM. IM-SSF cho phép

một gsmSCF (GSM Service Control Function) điều khiển một phiên IMS. Một mặt đóng vai trò là một AS và mặt kia đóng vai trò là chuyển mạch dịch vụ giao tiếp với gsmSCF dựa trên giao thức CAP (CAMEL Application Part).

AS có thể được đặt tại mạng chủ hoặc tại mạng của một nhà cung cấp thứ ba. Trong trường hợp AS được đặt ngoài mạng chủ thì nó không giao tiếp với HSS.

1.4.5 MRF

MRF (Media Resource Funtion) cung cấp nguồn media trong mạng chủ. MRF cung cấp khả năng để play thông báo, trộn các luồng media với nhau, chuyển đổi giữa các loại mã khác nhau, thu thập thống kê và làm các công việc phân tích media khác.

MRF được chia thành MRFC và MRFP. MRFC (Media Resource Funtion Control) đóng vai trò như một SIP User Agent và có một giao diện tới S-CSCF. MRFC điều khiển nguồn tài nguyên trong MRFP (Media Resource Funtion Processor) thông qua giao diện H.248. MRFP thực hiện tất cả chức năng liên quan đến media như play và trộn media.

MRF luôn luôn đặt tại mạng chủ.

1.4.6 BGCF

BGCF (Breakout Getway Control Function) là một thành phần SIP server cơ bản bao gồm chức năng định tuyến dựa trên số điện thoại. BGCF chỉ được sử dụng trong những phiên mà bắt đầu từ một thiết bị đầu cuối IMS tới một người dùng trong mạng chuyển mạch kênh như PSTN hoặc là PLMN.

Hai chức năng chính của BCCF:

+ Lựa chọn mạng thích hợp trong trường hợp làm việc với miền chuyển mạch kênh.

+ Lựa chọn PSTN/CS gateway phù hợp

1.4.7 IMS-ALG và TrGW

IMS hỗ trợ cả IPv4 và IPv6. Ở một số điểm trong phiên multimedia IP việc làm việc chéo giữa hai phiên bản có thể xảy ra. Để tránh cho các thiết bị đầu cuối không phải hỗ



trợ các chức năng để có thể làm việc liên kết, IMS bổ sung thêm hai thực thể mới đó là: IMS – Application Layer Gateway (IMS-ALG) và Transition Gateway (TrGW). IMS-ALG xử lý các vấn đề về báo hiệu (SIP, SDP …), còn TrGW xử lý lưu lượng media (RTP, RCTP).

Hình 1.1 IMS-ALG và TrGW

Hình 1.5 thể hiện mối quan hệ giữa IMS-ALG và TrGW. IMS-ALG thực hiện chức năng như một SIP B2BUA bằng cách duy trì hai chặng báo hiệu độc lập. Một chặng hướng tới bên trong mạng IMS và chặng còn lại hướng vào mạng khác. Mỗi chặng này sử dụng các phiên bản IP khác nhau. Thêm vào đó, IMS-ALG ghi lại SDP bằng cách thay đổi các địa chỉ IP và các port number tạo ra bởi các thiết bị đầu cuối với một hoặc nhiều địa chỉ IP và port number phân bổ cho TrGW. Điều này cho phép lưu lượng media được định tuyến tới TrGW.

IMS-ALG giao tiếp với I-CSCF với các luồng lưu lượng tới và với S-CSCF cho các luồng lưu lượng đi thông qua giao diện Mx.

TrGW là một NAT-PT/NAPT-PT (Network Address Port Translator-Protocol Translator). TrGW được cấu hình với một tập hợp các địa chỉ IP, được phân bổ tự động cho một phiên đã cho. TrGW thực hiện sự chuyển đổi media giữa IPv4 và IPv6.

1.4.8 PSTN/CS gateway

PSTN gateway cung cấp giao diện hướng tới mạng chuyển mạch kênh, cho phép các thiết bị đầu cuối IMS gọi và nhận các cuộc gọi từ PSTN và tới PSTN.



Hình 1.1 PSTN/CS Getway giao tiếp với một mạng CS

PSTN gateway cung cấp giao diện hướng tới mạng chuyển mạch kênh, cho phép các thiết bị đầu cuối IMS gọi và nhận các cuộc gọi từ PSTN và tới PSTN.

PSTN gateway được phân chia thành những thành phần chức năng sau:

+ SGW (signalling gateway): Signalling gateway giao tiếp với mặt phẳng báo hiệu của mạng chuyển mạch kênh. SGW thực hiện sự chuyển đổi giao thức mức thấp. SGW thay thế các giao thức bậc thấp MTP (ITU-T khuyến nghị Q.701) bằng SCTP/IP (Stream Control Transmission Protocol, RFC 2960). Vì vậy, SGW chuyển đổi ISUP (ITU-T khuyến nghị Q.761) hoặc BICC (Bearer-Independent Call Control) trên nền

MTP (Message Transfer Part) thành ISUP (ISDN User Part) hoặc BICC trên nền SCTP/IP (Stream Control Tranmission Protocol/Internet Protocol).

+ MGCF (Media GateWay Control Function): MGCF là nút trung tâm của PSTN/CS gateway. Nó thực hiện chuyển đổi giao thức và ánh xạ SIP (giao thức điều khiển cuộc gọi trong IMS) thành ISUP/IP hoặc BICC/IP. Ngoài ra, MGCF còn điều khiển nguồn tài nguyên trong MGW (Media GateWay). Giao thức được sử dụng giữa MGCF và MGW là H.248.

+ MGW: (Media Gateway) giao tiếp với mặt phẳng media của PSTN. Một mặt MGW có khả năng gửi và nhận mdeia IMS trên nền RTP (Real-time Transport Protocol). Mặt khác MGW sử dụng một hoặc nhiều khe thời gian PCM để kết nối tới mạng chuyển mạch kênh. Thêm vào đó, MGW thực hiện việc chuyển đổi mã khi mà thiết bị đầu cuối IMS không hỗ trợ các codec được sử dụng bởi mạng chuyển mạch kênh. Một tình huống phổ biến thường xảy ra là thiết bị đầu cuối IMS sử dụng mã AMR (Adaptive Multi-Rate) trong khi đó thiết bị đầu cuối PSTN sử dụng mã G.711.



1.4.9 Mạng chủ và mạng khách

IMS mượn một vài khái niệm của GSM và GPRS như mạng chủ và mạng khách. Khi chúng ta sử dụng điện thoại di động trong khu vực ta cư trú là ta đang sử dụng hạ tầng do các nhà điều hành mạng cung cấp. Cơ sở hạ tầng này hình thành mạng chủ.

Mặt khác, khi chúng ta chuyển vùng ra ngoài khu vực che phủ của mạng chủ, chúng ta sử dụng cơ sở hạ tầng được cung cấp bởi một nhà điều hành khác. Hạ tầng này được gọi là mạng khách.

Để sử dụng được mạng khách thì các nhà điều hành mạng khách và mạng chủ phải có một thỏa thuận với nhau. Các thỏa thuận này có thể là giá cước cuộc gọi, chất lượng dịch vụ hoặc là phương thức qui đổi bảng tính cước.

Hầu hết các nút đặt tại mạng chủ nhưng có những nút có thể đặt tại mạng khách hoặc mạng chủ. Đó là nút P-CSCF. Kiến trúc IMS cho phép hai cấu hình khác nhau cho P-CSCF, tùy thuộc vào vị trí của P-CSCF ở mạng khách hay mạng chủ.

Thêm nữa khi mạng truy nhập kết nối IP là mạng GPRS thì vi trị của P-CSCF phụ thuộc vị trí của GGSN. Trong tình huống chuyển vùng, GPRS cho phép vị trí của GGSN hoặc ở trong mạng khách hoặc ở trong mạng chủ (Bình thường SGSN luôn ở mạng khách).

Trong IMS cả GGSN và P-CSCF phải nằm trong cùng một mạng. Điều này cho phép P-CSCF điều khiển GGSN qua giao diện Go. Khi cả P-CSCF và GGSN nằm trong cùng một mạng thì giao diện Go luôn luôn là giao diện hoạt động bên trong và làm cho sự hoạt của nó đơn giản hơn.

Hình 1.7 chỉ ra cấu hình trong đó P-CSCF nằm trong mạng khách. Cấu hình này là giai đoạn tiếp theo của IMS bởi vì nó yêu cầu IMS phải thực hiện từ mạng khách.

Hình 1.1 P-CSCF đặt tại mạng khách



Không thể mong đợi việc tất cả các mạng trên thế giới đều triển khai IMS cùng một lúc. Do đó cũng không thể mong chờ tất cả các mạng thành phần sẽ cập nhật các GGSN theo cùng một chuẩn tại cùng một thời điểm và cùng bắt đầu cung cấp dịch vụ IMS. Vì vậy chúng ta chỉ có thể mong đợi sớm có sự triển khai IMS mà P-CSCF ở trong mạng chủ như hình 1.8.

Hình 1.8 chỉ ra một cấu hình hiện tại khi cả P-CSCF và GGSN nằm trong cùng mạng chủ. Cấu hình này không yêu cầu sự hỗ trợ IMS từ mạng khách. Mạng khách không cần phải có GGSN tuân theo tiêu chuẩn 3GPP release 5. Mạng khác chỉ cần cung cấp liên lạc vô tuyến và SGSN. Vì vậy, cấu hình này được thực hiện từ những ngày đầu của IMS.

Hình 1.2 P-CSCF đặt tại mạng chủ

Tuy nhiên cấu hình này có những bất lợi so với cấu hình trên bởi vì lưu lượng media phải đi qua mạng chủ rồi mới được định tuyến đến mạng khách. Điều này gây ra độ trễ lớn.

1.5 Nhận dạng người dùng trong IMS

Bất cứ một mạng nào đều phải có khả năng để nhận dạng người dùng một cách duy nhất. Đây là một thuộc tính cho phép một máy điện thoại có thể rung chuông khi chúng ta quay một chuỗi số trong mạng PSTN.

Trong mạng PSTN, thuê bao được nhận ra bởi một số điện thoại. Số điện thoại được gán cho một thuê bao bao gồm các phần: phần cục bộ, mã vùng và mã quốc tế. Phụ thuộc vào đích gọi đến là nội hạt, trong quốc gia hay đi quốc tế mà số điện thọai có thể ngắn hoặc dài. Thêm vào đó khi một dịch vụ mới được cung cấp thường có



những số đặc biệt để nhận dạng dịch vụ như 113 chẳng hạn. IMS cũng cung cấp cơ chế để nhận dạng dịch vụ.

Nhận dạng người dùng công cộng

Trong IMS có một cách tiền định để nhận dạng người dùng. Một thuê bao IMS được phân bổ một hay nhiều nhận dạng người dùng công cộng. Nhà điều hành chủ chịu trách nhiệm phân phối nhận dạng người dùng công cộng tới mỗi thuê bao IMS. Một nhận dạng người dùng công cộng có thể là SIP URI hoặc một TEL URI. Nhận dạng người dùng công cộng được sử dụng để làm những thông tin liên lạc trên tấm card giao dịch .

Trong IMS, nhận dạng người dùng công cộng được sử dụng để định tuyến báo hiệu SIP.

Nhận dạng người dùng công cộng tương ứng với số MSISDN ( Mobile Subcriber ISDN Number) trong GSM.

Khi nhận dạng người dùng công cộng chứa một SIP URI, nó thường có dạng : sip:[email protected], mặc dù các nhà điều hành IMS có thể thay đổi cấu trúc này và địa chỉ theo cách của họ. Thêm vào đó, nó có thể bao gồm một số điện thoại trong một SIP URI sử dụng định dạng như sau:

SIP :[email protected] ; user=phone

Định dạng này là cần thiết bởi vì SIP yêu cầu rằng URI trong khi đăng ký phải là một SIP URI. Vì vậy nó không có khả năng đăng ký một TEL URI trong SIP, mặc dù nó có khả năng đăng ký một SIP URI mà chứa một số điện thoại.

TEL URI là một dạng khác của nhận dạng người dùng công cộng. Đây là một TEL URI thể hiện một số điện thoại quốc tế:

tel:+1-212-555-0293

TEL URI cần thiết để có thể gọi từ một thiết bị đầu cuối IMS tới một điện thoại trong PSTN, bởi vì số điện thoại PSTN được thể hiện bởi những chữ số. Mặt khác, TEL URI cũng cần thiết nếu một thuê bao PSTN muốn thực hiện một cuộc gọi tới một người dùng trong IMS, bởi vì người dùng PSTN chỉ có thể bấm những chữ số.

Mỗi người dùng sẽ được phân bố ít nhất một SIP URI và một TEL URI. Lý do để phân bổ nhiều nhận dạng công cộng là một người dùng có thể có nhiều nhóm liên lạc như gia đình, bạn bè, đồng nghiệp…Có thể mỗi nhóm người sẽ biết được các nhận dạng công cộng khác nhau của người dùng đó. Điều này thuận tiện cho việc kích hoạt những dịch vụ liên quan.

Trong IMS một bản tin đăng ký SIP có thể đăng ký nhiều nhận dạng người dùng công cộng để tiết kiệm thời gian đăng ký và băng thông.

1.5.1 Nhận dạng người dùng cá nhân

Mỗi thuê bao IMS được gán cho một nhận dạng người dùng cá nhân. Không giống nhận dạng người dùng công cộng, nhận dạng người dùng cá nhân không có dạng SIP URIs hay TEL URIs, mà có dạng NAI (Network Access Identifier,RFC 2486). Định dạng của NAI là [email protected]



Nhận dạng người dùng cá nhân không để định tuyến bản tin SIP mà dành riêng cho mục đích nhận thực và nhận dạng đăng ký thuê bao. Nhận dạng người dùng cá nhân thực hiện chức năng giống như IMSI (International Mobile Subcriber Identifier) trong GSM Người dùng không cần phải biết nhận dạng người dùng cá nhân, bởi vì nó được lưu trữ trong một thẻ thông minh, giống như IMSI được lưu trong SIM .

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.

Nhà điều hành phân bổ một hoặc nhiều nhận dạng người dùng công cộng và một nhận dạng người dùng cá nhân cho mỗi người dùng. Trong trường hợp của GSM/UMTS thẻ thông minh lưu trữ nhận dạng người dùng cá nhân và ít nhất một nhận dạng người dùng công cộng. HSS lưu trữ đồng thời nhận dạng người dùng công cộng và nhận dạng người dùng cá nhân.

Mối quan hệ giữa một thuê bao IMS, một nhận dạng người dùng công cộng và một nhận dạng người dùng cá nhân được chỉ ra trên hình 1.9. Một thêu bao IMS được cung cấp chỉ duy nhất một nhận dạng người dùng cá nhân và nhiều nhận dạng người dùng công cộng.

3GPP release 6 đã mở rộng mối quan 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 như được chỉ ra trong hình 1.10. Một thuê bao IMS không chỉ được phân bố một mà nhiều nhận dạng người dùng cá nhân. Trong trường hợp của UMTS, chỉ có một nhận dạng người dùng cá nhân được lưu trong thẻ thông minh, nhưng người dùng có thể có nhiều thẻ và chứng được lắp vào trong các thiết bị khác nhau.

Hình 1.1 Mối liên hệ giữa nhận dạng người dùng cá nhân và công cộng trong Realese 5



Hình 1.2 Mối liên hệ giữa nhận dạng người dùng cá nhân và công cộng trong Release 6

1.5.3 Nhận dạng dịch vụ công công

Khái niệm nhận dạng dịch vụ công cộng được giới thiệu trong release 6 của 3GPP. Không giống nhận dạng người dùng công cộng, được phân bố tới người dùng, một nhận dạng dịch vụ công cộng được phân bố cho một dịch vụ được nắm giữ bởi một AS. Ví dụ một AS phục vụ một phòng chat được nhận dạng bởi một nhận dạng dịch vụ công cộng.

1.5.4 SIM, USIM và ISIM trong 3GPP

UICC (Universal Integrated Circuit Card) là trung tâm trong thiết kế thiết bị đầu cuối 3GPP. UICC là một thẻ thông minh có thể di chuyển được, lưu trữ một số dữ liệu như thông tin đăng ký thuê bao, mã nhận thực, sổ địa chỉ và các tin nhắn. Nếu không có UICC thì thiết bị đầu cuối chỉ có thể gọi các số khẩn cấp.

UICC cho phép người dùng dễ dàng di chuyển thông tin đăng ký thuê bao của họ sang thiết bị mới bằng cách lắp thẻ thông minh sang thiết bị đó. UICC là một khái niệm chung định nghĩa các đặc tính của thẻ thông minh.

UICC có thể bao gồm một vài ứng dụng logic như SIM, USIM (Universal Subscriber Identity Module), ISIM (IP multimedia Services Identity Module). UICC còn có các ứng dụng khác như là sổ điện thoại.

1.5.4.1 SIM

SIM lưu trữ một tập hợp các tham số như thông tin đăng ký người dùng, mã nhận thực và các tin nhắn. Nó là thành phần cơ bản nhất trong các thiết bị đầu cuối để chúng có thể hòa mạng. Mặc dù khái niệm UICC và SIM là có thể thay đổi cho nhau, UICC ám chỉ đến thẻ vật lý trong khi đó SIM nói đến một ứng dụng đơn lẻ nằm trong UICC .SIM được sử dụng rộng rãi trong mạng GSM.



1.5.4.2 USIM

USIM là một ứng dụng khác nằm trong UICC. USIM cung cấp một tập hợp các tham số bao gồm thông tin đăng ký thuê bao, thông tin nhận thực, phương pháp thanh toán và lưu trữ tin nhắn.USIM được sử dụng để truy nhập mạng UMTS.

Các thiết bị đầu cuối trong mạng chuyển mạch gói và chuyển mạch kênh cần phải có USIM để hoạt động được trong mạng 3G. Rõ ràng, cả SIM và USIM có thể cùng tồn tại đồng thời trong UICC để thiết bị đầu cuối có thể sử dụng đồng thời mạng GSM và UMTS.

Hình 1.1 Cấu trúc đơn giản hóa của USIM

USIM lưu giữ các thông số sau đây:

IMSI: IMSI là một nhận dạng mà được phân bố đến mỗi người dùng. IMSI chỉ được sử dụng để nhận dạng người dùng cho mục đích nhận thực. Nhận dạng người dùng cá nhân tương đương với IMSI.

MSISDN: Trường này lưu trữ một hoặc nhiều số điện thoại được cấp cho người dùng. Nhận dạng người dùng công cộng tương đương với MSISDN.

CK(Ciphering Key) và IK( Integrity Key): Đó là những chìa khóa được sử dụng cho mục đích mã hóa và bảo vệ sự toàn vẹn thực thể qua giao diện vô tuyến.



USIM lưu trữ riêng biệt chìa khóa được sử dụng trong mạng chuyển mạch kênh và chìa khóa trong mạng chuyển mạch gói.

Bí mật dài hạn: USIM lưu trữ bí mật dài hạn được sử dụng cho mực đích nhận thực và cho việc tính toán chìa khóa toàn vẹn và chìa khóa mã được sử dụng giữa thiết bị đầu cuối và mạng.

SMS( Short Message Service): USIM lưu trữ các bản tin ngắn và các thông tin liên quan như người gửi, người nhận và trạng thái.

Các tham số SMS: Trường này trong USIM lưu giữ thông tin cấu hình liên quan tới dịch vụ SMS, như địa chỉ của trung tâm tin nhắn hoặc các giao thức được hỗ trợ.

Các thông số MMS: Trường này lưu trữ dữ liệu cấu hình liên quan đến dịch vụ MMS, như địa chỉ của MMS server và địa chỉ của MMS gateway.

1.5.4.3 ISIM

Một ứng dụng thứ ba có thể hiện diện trong UICC là ISIM. ISIM có vai trò đặc biệt quan trọng trong IMS, bởi vì nó chứa một tập hợp các thông số được sử dụng làm chứng thực người dùng, nhận dạng người dùng, cấu hình thiết bị đầu cuối khi thiết bị đầu cuối hoạt động trong mạng IMS. ISIM có thể tồn tại cùng SIM, USIM hoặc cả hai.

Hình 1.1 Cấu trúc của ứng dụng ISIM.



Các tham số thích hợp được lưu trữ trong ISIM bao gồm:

Nhận dạng người dùng cá nhân: ISIM lưu trữ nhận dạng người dùng cá nhân phân bố cho người dùng. Chỉ có một nhận dạng người dùng cá nhân được lưu trữ trong ISIM.

Nhận dạng người dùng công cộng: ISIM lưu trữ một hoặc nhiều SIP URI của nhận dạng người dùng công cộng phân bổ tới người dùng.

URI của miền mạng chủ: ISIM lưu trữ SIP URI mà chứa tên miền mạng chủ. Thông tin này được sử dụng trong suốt thủ tục đăng ký. Có thể chỉ có một URI tên miền của mạng chủ được lưu trong ISIM.

Bí mật dài hạn: ISIM lưu trữ một bí mật dài hạn được sử dụng cho mục đích nhận thực và tính toán mã toàn vẹn và mã mã hóa sử dụng giữa mạng và thiết bị đầu cuối. Thiết bị đầu cuối sử dụng mã toàn vẹn để bảo vệ sự toàn vẹn báo hiệu SIP mà thiết bị đầu cuối gửi và nhận từ P-CSCF. Nếu báo hiệu được mã hóa, thiết bị đầu cuối IMS sử dụng mã mã hóa để mã hóa và giải mã báo hiệu SIP mà thiết bị đầu cuối gửi và nhận từ P-CSCF.

Tất cả những thông tin trên chỉ có thể đọc, có nghĩa là người dùng không thể thay đổi giá trị của chúng.

Như vậy truy nhập tới mạng IMS dựa trên ISIM hoặc USIM.Mặc dù USIM cũng có thể nhưng sử dụng ISIM vẫn tốt hơn vì nó được thiết kế dành riêng cho IMS. Bởi vì tính bảo mật thấp của SIM, nó không được sử dụng để sử dụng để truy nhập tới mạng IMS.

Chương 2 GIAO THỨC HỖ TRỢ CHỨNG THỰC, CẤP QUYỀN, TÍNH CƯỚC TRONG IMS



Giao thức AAA được hiểu là Authentication (chứng thực), Authorization (cấp quyền), Accouting (tính cước). Xác thực và cấp quyền có một mối liên hệ tổng quát trong IMS. Trong khi tính cước lại là một chức năng riêng biệt được thực hiện từng nút khác nhau trong mạng. Đó cũng chính là lý do để ta nghiên cứu tách bạch hai nhóm đối tượng này.

2.1 Chứng thực và cấp quyền trong IMS

Hình 2.1 thể hiện sơ đồ của chức năng xác thực và cấp quyền trong IMS. Có ba giao diện triển khai xác thực và cấp quyền đó là các giao diện Cx, Dx, Sh.

Giao diện Cx nối giữa HSS và I-CSCF hay S-CSCF. Khi có nhiều hơn một HSS trong mạng thì cần phải có SLF (Subscription Locator Funtion) để giúp I-CSCF hay S-CSCF xác định chính xác HSS nào đang lưu trữ thông tin người dùng.

Giao diện Dx nối một I-CSCF hay S-CSCF tới một SLF.

Giao diện Sh nối giữa một HSS và một SIP Application Server hay một OSA Service Capability Server ( để hoàn thành mô tả về các loại Application Server trong IMS).

Trong tất cả các giao diện này, giao thức sử dụng để liên lạc giữa các nút là giao thức Diameter (được chuẩn hóa trong RFC 3588).

Hình 2.1 Sơ đồ xác thực và cấp quyền trong IMS

2.2 Giao thức Diameter

Diameter là một giao thức tầng ứng dụng dựa trên RFC 3588 được chọn là giao thức AAA trong mạng IMS.

+ Authentication: Chứng thực



+ Authorization: Cấp quyền

+ Accounting: Tính cước

Diameter được phát triển từ giao thức RADIUS (RFC 2865) là một giao thức được sử dụng phổ biến trong Internet để thực hiện chứng thực, cấp quyền và tính cước. Ví dụ khi một người dùng quay số đến một nhà cung cấp dịch vụ Internet, máy chủ truy nhập mạng sử dụng RADIUS để chứng thực cấp quyền cho user.

Giao thức Diameter được chia thành 2 phần là giao thức Diameter cơ bản và Diameter ứng dụng.

Giao thức Diameter cơ bản bao gồm những chức năng chính và triển khai ở mọi điểm sử dụng Diameter, không phụ thuộc vào những ứng dụng cụ thể. Giao thức Diameter cơ bản cần thiết cho việc khởi tạo các đơn vị dữ liệu Diameter, điều chỉnh khả năng, bắt lỗi và cung cấp khả năng mở rộng.

Một Diameter ứng dụng định nghĩa một chức năng ứng dụng cụ thể và đơn vị dữ liệu. Mỗi một Diameter ứng dụng được tách rời độc lập nhau

Nhiều ứng dụng là mở rộng của các chức năng cơ bản trong giao thức Diameter. Ví dụ như ứng dụng cho Network Access Server, Server Configurations, Mobile Ipv4, Credit Control hay SIP applications. Những ứng dụng này có thể phát triển thêm khi cần thiết. Hình 2.2 thể hiện mối quan hệ giữa giao thức Diameter cơ bản và một vài ứng dụng.

Hình 2.1 Giao thức Diameter cơ bản và các ứng dụng

Giao thức Diameter cơ bản sử dụng cả TCP và STCP để truyền tải, trong đó STCP được ưu tiên hơn.

IMS sử dụng Diameter trong nhiều giao diện , mặc dù vậy các giao diện này có thể sử dụng các ứng dụng Diameter khác nhau.Ví dụ IMS sử dụng một ứng dụng Diameter trong quá trình thiết lập cuộc gọi nhưng lại sử dụng một ứng dụng Diameter khác trong tính cước.



Giao thức Diameter cơ bản định nghĩa ra một vài thực thể chức năng để thực hiện các thao tác AAA:

Diameter client: Thực thể chức năng, nằm ở bên rìa của mạng, thực hiện các công việc truy nhập điều khiển ( ví dụ như Network Access Servers ).

Diameter Server: Thực thể chức năng thực hiện công việc xử lý các yêu cầu về chứng thực, cấp quyền và tính cước cho các vùng miền.

Proxy: Thực thể chức năng thực hiện nhiệm vụ chuyển tiếp các bản tin Diameter, thiết lập các chính sách để giải quyết mối quan hệ về sử dụng và phân phát tài nguyên.

Relay: Thực thể chức năng thực hiện chuyển tiếp bản tin Diameter dựa trên các thông tin quan hệ định tuyến và bảng định tuyến vùng. Một Relay tiêu biểu cho tính trong suốt. Nó chỉ có thể sửa đổi (chèn hoặc xóa đi) các thông tin về quan hệ định tuyến trong bản tin Diameter chứ không thể sửa đổi các dữ liệu khác.

Redirect agent: Thực thể chức năng dùng để chỉ dẫn client liên lạc một cách với server.

Translation agent: Thực thể chức năng thực hiện giao thức vận chuyển giữa giao thức Dameter và các giao thức AAA khác ví dụ như RADIUS.

Diameter node: Thực thể chức năng nói chung triển khai giao thức Diameter và hoạt động như một Diameter client, Diameter server, relay, redirect agent, hay translation agent.

Diameter là giao thức ngang hàng ( peer-to-peer ) chứ không phải giao thức dạng chủ / tớ. Có nghĩa là từ mọi nút Diameter đều có thể gửi yêu cầu tới các nút khác. Một Diameter client không phải là thực thể chức năng chỉ gửi yêu cầu cũng như một Diameter server không phải là thực thể chức năng chỉ gửi trả lời khi có yêu cầu. Thay vì thế một Diameter client là thực thể chức năng có tính chất điều khiển truy nhập, trong khi Diameter server là thực thể chức năng thực hiện việc chứng thực và cấp quyền. Trong Diameter, cả Diameter client và Diameter server đều có thể gửi hoặc nhận các yêu cầu cũng như hồi đáp.

Bản tin Diameter ở một trong hai dạng yêu cầu và hồi đáp. Một yêu cầu được trả lời bởi một hồi đáp. Ngoại trừ một vài trường hợp đặc biệt, nói chung yêu cầu Diameter luôn luôn được trả lời, vì vậy bên gửi yêu cầu luôn nhận được thông tin chính xác về kết quả của yêu cầu đó. Trong trường hợp có lỗi, bên gửi có thể dễ dàng phát hiện và gửi lại. Diameter là một giao thức mã hóa nhị phân (binary encoded protocol).

2.2.1 Cấu trúc bản tin Diameter

Hình 2.3 thể hiện cấu trúc bản tin Diameter. Một bản tin Diameter bao gồm 20 octet tiêu đề và một số các cặp giá trị thuộc tính (Atribute Value Pairs - AVPs). Chiều dài của phần tiêu đề là cố định trong mọi bản tin Diameter. Còn số lượng các AVPs thì thay đổi phụ thuộc vào từng bản tin Diameter, mỗi một AVPs sẽ chứa dữ liệu về chứng thực, cấp quyền hay tính cước.



Hình 2.2 Cấu trúc bản tin Diameter

+ Trường version cho biết phiên bản của Diameter

+ Trường Message length cho biết chiều dài của bản tin Diameter bao gồm cả phần tiêu đề ( header )

+ Trường tiếp theo là Command Flags bao gồm 8 bits cho biết loại bản tin Diameter :

Nếu bit R ( Request ) được bật thì loại bản tin là yêu cầu, ngược lại là bản tin trả lời.

Nếu bit P ( Proxiable ) được bật thì bản tin sẽ được chuyển qua proxy server hoặc relay server hoặc redirect server, ngược lại bản tin sẽ chỉ chuyển trong nội bộ

Nếu bit E ( Error ) được bật thì chứng tỏ bản tin có chứa lỗi

Nếu bit T được bật thì bản tin này là bản tin truyền lại

4 bit còn lại chưa được sử dụng và thường được đặt về 0

+ Trường Command-Code: độ dài 24 bit cho biết lệnh nào sẽ được thực hiện trong bản tin Diameter, Mã số các lệnh này được quản lý bởi Internet Assigned Numbers Authority ( IANA ) bao gồm các lệnh cho giao thức Diameter cơ bản và cho Diameter ứng dụng.



+ Trường Application – ID xác định loại ứng dụng Diameter nào mà bản tin sẽ được gửi đi, có thể là giao thức Diameter cơ bản hay 1 Diameter ứng dụng nào khác.

+ Trường Hop-by-Hop identifier chứa giá trị được đặt vào của từng chặng trong bản tin yêu cầu. Bản tin trả lời sẽ có cùng 1 số Hop-by-Hop identifier với bản tin yêu cầu, do vậy một nút Diameter sẽ dễ dàng so sánh bản tin yêu cầu với bản tin trả lời tương ứng.

+ Trường End-to-End identifier sẽ mang một giá trị cố định không thay đổi khi các bản tin yêu cầu được truyền đi, điều này nhằm xác định các bản tin yêu cầu giống nhau, nút Diameter sẽ gửi lại bản tin trả lời với giá trị End-to-End identifier giống như giá trị nhận được trong bản tin yêu cầu.

2.2.2 Cặp giá trị thuộc tính

Cũng giống như bản tin RADIUS, bản tin Diameter chứa các cặp giá trị thuộc tính (Atribute Value Pairs - AVPs). AVP sẽ chứa dữ liệu trong đó. Hình 2.4 mô tả cấu trúc của AVP. Mỗi AVP bao gồm các trường :

+ AVP Code

+ Flags

+ AVP Length

+ Vendor-ID

+ Data

Hình 2.1 Cấu trúc của AVP

AVP Code kết hợp với trường Vendor-ID sẽ xác định duy nhất một thuộc tính. Sự thiếu vắng của trường Vendor-ID hoặc giá trị trường này được đặt về 0 biểu thị đây AVP chuẩn theo lý thuyết được định nghĩa trong IETF. Số AVP Code 1 đến 255 xác định các thuộc tính đã được định nghĩa trong RADIUS, AVP Code từ 256 trở lên xác định các thuộc tính được định nghĩa riêng trong Diameter



Trường Flags biểu thị :

+ Sự cần thiết mã hóa để bảo đảm an ninh trong quá trình truyền điểm-điểm

+ Hỗ trợ AVP có tính chất bắt buộc hay là tùy chọn. Nếu bên gửi thông báo rằng có hỗ trợ AVP là bắt buộc và bên thu không hiểu AVP đó thì yêu cầu Diameter sẽ bị từ chối

+ Tùy chọn trường Vendor-ID có hiển thị hay không

Trường AVP Length biểu thị độ dài của AVP, bao gồm AVP Code, AVP Length, Flags, Vendor-ID (nếu có) và trường Data

Trường Data chứa một vài loại dữ liệu đặc biệt về thuộc tính. Độ dài của trường Data có thể là không hoặc nhiều byte. Độ dài của dữ liệu có thể biết được nhờ trường AVP Length.

Giao thức Diameter cơ bản chỉ rõ một vài định dạng dữ liệu của trường Data : OctetString, Integer32, Integer64, Unsigned32, Unsigned64, Float32, Float64, và Grouped. Hầu hết trong số đó là cùng một loại. Kiểu Grouped AVP là một AVP có trường dữ liệu là một chuỗi các AVP khác.

Những AVP có Code từ 1 đến 255 xác định các thuộc tính đã được định nghĩa trong RADIUS, AVP có Code từ 256 trở lên là AVP được định nghĩa trong Diameter. AVP-Code được quản lý bởi IANA

Giao thức Diameter cho phép các ứng dụng có thể xác định định dạng dữ liệu AVP. Giao thức cơ bản đã định nghĩa sẵn một vài dữ liệu AVP, những loại quan trọng nhất như:

Địa chỉ để vận chuyển một địa chỉ IPv4 hay một địa chỉ IPv6

Thời gian để miêu tả ngày giờ

UTF8String để trình bày xâu, chuỗi theo bảng mã Unicode : UTF-8

DiameterIdentity để vận chuyển đầy đủ tên miền của nút Diameter

DiameterURI để vận chuyển các AAA URI hay AAAS URI

Enumerated, một bảng số để miêu tả một vài ngữ nghĩa nào đó

2.2.3 Địa chỉ AAA và AAAS

Giao thức AAA có thể sử dụng một aaa URI hay một aaas URI để xác định tài nguyên AAA. Aaas URI biểu thị rằng việc vận chuyển tin cậy phải được sử dụng. Cú pháp của những URI này như sau :

"aaa://" FQDN [ port ] [ transport ] [ protocol ]

"aaas://" FQDN [ port ] [ transport ] [ protocol ]



port = ":" 1*DIGIT

transport = ";transport=" transport-protocol

protocol = ";protocol=" aaa-protocol

transport-protocol = ( "tcp" / "sctp" / "udp" )

aaa-protocol = ( "diameter" / "radius" /

"tacacs+" )

Trong đó FQDN là Fully Qualified Domain Name. Những URI có thể được chèn vào bằng tùy chọn số cổng, một tùy chọn về giao thức vận chuyển hoặc một tùy chọn giao thức để truy cập tài nguyên AAA. Nếu như số cổng không khớp với số cổng mặc định của giao thức Diameter (3868) thì nó sẽ lờ đi. Nếu như thông số về vận chuyển không xuất hiện, giao thức Diameter cũng lờ đi. Phải chú ý rằng aaa URI và aaas URI có thể điều chỉnh thích hợp với Diameter, RADIUS và các giao thức khác.

Ví dụ về các aaa URI và aaas URI :

aaa://server.home1.net

aaas://server.home1.net

aaa://server.home1.net:8868

aaa://server.home1.net;transport=tcp;protocol=diameter

2.2.4 Giao thức Diameter cơ bản

Chúng ta đã thấy bản tin Diameter là một trong hai loại yêu cầu hoặc hồi đáp. Một yêu cầu và hồi đáp tương ứng của nó được xác định bởi trường Command-Code trong tiêu đề bản tin. Trường Command-Code là một số biểu thị phương thức mà Diameter server muốn tiến hành. Một yêu cầu và hồi đáp tương ứng của nó đều có cùng số Command-Code, do vậy cần có cờ Command-Flags để phân biệt yêu cầu và hồi đáp.

Giao thức Diameter cơ bản (RFC 3588 [60]) đã chỉ rõ các Command-Code đầu tiên. Một ứng dụng có thể được mở rộng từ những lệnh cơ bản và thêm vào đó những ứng dụng mới. Hình 2.5 liệt kê các các yêu cầu và hồi đáp được định nghĩa trong giao thức Diameter cơ bản.

Command-Name Abbreviation Command-Code

Abort-Session-Request ASR 274

Abort-Session-Answer ASA 274

Accounting-Request ACR 271

Accounting-Answer ACA 271



Capabilities-Exchange-Request CER 257

Capabilities-Exchange-Answer CEA 257

Device-Watchdog-Request DWR 280

Device-Watchdog-Answer DWA 280

Disconnect-Peer-Request DPR 282

Disconnect-Peer-Answer DPA 282

Re-Auth-Request RAR 258

Re-Auth-Answer RAA 258

Session-Termination-Request STR 275

Session-Termination-Answer STA 275

Hình 2.1 Các lệnh cơ bản của Diameter

2.2.4.1 Bản tin ASR và ASA

ASR (Abort Session Request)

ASA (Abort-Session Answer)

Đây là lệnh cần thiết cho Diameter server khi muốn ngừng cung cấp dịch vụ tới người dùng. Bởi vì có những nguyên do mới sẽ xuất hiện không thể biết trước được khi phiên đã được cấp quyền. Đó có thể là hết tài khoản, lý do an ninh, bảo mật, hoặc một lý do nào khác. Khi một Diameter server quyết định thông báo tới Diameter client về việc ngừng cung cấp dịch vụ, Diameter server sẽ gửi bản tin Abort-Session-Request (ASR) tới Diameter client. Diameter client sẽ trả lời bằng bản tin Abort-Session-Answer (ASA).

2.2.4.2 Bản tin ACR và ACA

ACR (Accounting Request)

ACA (Accounting Answer)

Một nút Diameter có thể cần thiết phải thông báo về tình trạng tài khoản cho Diameter server cung cấp dịnh vụ tính cước. Giao thức Diameter cung cấp lệnh Accouting-Request (ACR), nhờ đó Diameter client có thể thông báo tình trạng sử dụng dịch vụ cho Diameter server. Lệnh này sẽ chứ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 hoặc chuẩn bị chấm dứt dịch vụ.

2.2.4.3 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…)

2.2.4.4 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.

2.2.4.5 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).

2.2.4.6 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.

2.2.4.7 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.

2.2.5 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 hoặc 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

… … …

Hình 2.1 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 hoặc 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 hoặc 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 hoặc 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.

2.3 Giao diện Cx và Dx

Giao diện Cx được xây dựng để kết nối một I-CSCF hoặc một S-CSCF tới một HSS. Tương tự như vậy giao diện Dx cũng được xây dựng để kết nối một I-CSCF hoặc một S-CSCF tới một HSS hoặc một SLF. Điểm khác biệt duy nhất giữa hai giao diện này là việc triển khai SLF như một Diameter redirect agent, ngược lại HSS như một Diameter server. Trong trường hợp này cả I-CSCF và S-CSCF đề hoạt động như Diameter client.

Trong mạng nếu có nhiều hơn một HSS, những Diameter client (S-CSCF, I-CSCF ) cần phải liên hệ với SLF để tìm xem HSS nào trong mạng lưu trữ thông tin về người dùng ứng với nhận dạng công cộng của người dùng đó (Public User Identity). Các lệnh của Diameter từ S-CSCF hay I-CSCF gửi tới HSS và SLF là như nhau. SLF hoạt động như một Diameter redirect agent và chứa bảng tham chiếu các nhận dạng người dùng công cộng với HSS tương ứng lưu trữ thông tin người dùng đó. Khi nhận được yêu cầu SLF sẽ trả lời bằng bản tin có chứa AVP : Redirect-Host. AVP này chứa địa chỉ của HSS mà S-CSCF hay I-CSCF cần liên hệ. I-CSCF và S-CSCF sau đó sẽ chuyển tiếp bản tin Diameter tới HSS đó.



Bởi vì bản tin Diameter đi qua giao diện Cx và Dx là như nhau, giao diện Dx có thể coi như trong suốt để mô tả sự tương tác với giao diện Cx. Trong phần này ta chỉ nói đến giao diện Cx với HSS, nhưng mô tả này cũng tương tự như giao diện Dx với SLF.

Cần chú ý rằng P-CSCF không triển khai trên cả hai giao diện Cx và Dx.

Với những người dùng đặc biệt I-CSCF và S-CSCF sử dụng giao diện Cx và Dx để thực hiện các chức năng :

Xác định 1 S-CSCF đã tồn tại cho người dùng

Tải về vector chứng thực của người dùng. Những vector này được lưu trong HSS

Cấp quyền cho người dùng khi người dung để truy cập mạng

Lưu vào HSS địa chỉ của S-CSCF đang xác định người dùng

Cho HSS biết về trạng thái đăng ký của người dùng

Tải về thông tin người dùng từ HSS, thông tin có thể được lọc theo các tiêu chuẩn

Cập nhật thông tin người dùng từ HSS vào S-CSCF khi thông tin này được thay đổi

Cung cấp thông tin cần thiết cho I-CSCF để lựa chọn S-CSCF

Giao diện Cx và Dx triển khai như là ứng dụng theo chuẩn giao thức Diameter được gọi là Diameter ứng dụng cho giao diện Cx (Diameter Application for the Cx interface). Ứng dụng này được trình bày cụ thể trong 3GPP TS 29.228 [21] và 3GPP TS 29.229 [12]. Diameter ứng dụng cho giao diện Cx không được chuẩn hóa trong IETF, nhưng IETF đã cấp quyền cho 3GPP Release 5.

Diameter ứng dụng cho giao diện Cx có đặc điểm cơ bản của ứng dụng AAA cho SIP server.

2.3.1 Những lệnh trong Diameter ứng dụng cho giao diện Cx

Như đã nói, I-CSCF và S-CSCF có một số chức năng thực hiện qua giao diện Cx và Dx. Để thực hiện những chức năng này Diameter ứng dụng cho giao diện Cx cần định nghĩa ra những lệnh mới (yêu cầu và hồi đáp). Hình 2.7 là danh sách các lệnh mới trong Diameter ứng dụng cho giao diện Cx.



Command-Name Abbreviation Command-Code

User-Authorization-Request UAR 300

User-Authorization-Answer UAA 300

Server-Assignment-Request SAR 301

Server-Assignment-Answer SAA 301

Location-Info-Request LIR 302

Location-Info-Answer LIA 302

Multimedia-Auth-Request MAR 303

Multimedia-Auth-Answer MAA 303

Registration-Termination-Request RTR 304

Registration-Termination-Answer RTA 304

Push-Profile-Request PPR 305

Push-Profile-Answer PPA 305

Hình 2.1 Các lệnh định nghĩa bởi Diameter ứng dụng cho giao diện Cx

2.3.1.2 Bản tin UAR và UAA

UAR (User Authentication Request)

UAA (User Authentication Answer)

Một I-CSCF gửi một bản tin UAR khi I-CSCF nhận được yêu cầu SIP REGISTER từ một thiết bị đầu cuối IMS. Có một vài lý do để I-CSCF gửi bản tin UAR tới HSS:

HSS đầu tiên sẽ lọc nhận dạng người dùng công cộng (Public User Identity) chứa trong yêu cầu SIP REGISTER. Ví dụ HSS kiểm tra thấy rằng nhận dạng người dùng công cộng đó được cấp cho một thuê bao phù hợp trong mạng và thuê bao đó không bị khóa.

HSS cũng kiểm tra xem mạng nhà có đồng ý liên kết với một mạng khác có P-CSCF đang hoạt động. Điều này cho phép mạng chứa P-CSCF nạp thông tin từ mạng nhà.

I-CSCF cũng cần xác định có hay không một S-CSCF sẵn sàng chỉ định tới nhận dạng người dùng công cộng chờ đăng ký trước khi I-CSCF chuyển tiếp yêu cầu SIP REGISTER tới S-CSCF đó. Nếu không có một S-CSCF nào chỉ định tới nhận dạng người dùng công cộng thì I-CSCF sẽ nhận được một tập hợp yêu cầu lưu trữ trong S-CSCF, như vậy I-CSCF có thể lựa chọn môt S-CSCF thích hợp.



Yêu cầu SIP REGISTER phân ra thành loại mang thông tin xác nhận người dùng công cộng và loại mang thông xác nhận người dùng cá nhân. HSS sẽ kiểm tra xem xác nhận người dùng công cộng có thể sử dụng với xác nhận người dùng cá nhân hay không, đây là chức năng xác thực của HSS.

Hình 2.8 mô tả một quá trình đăng ký. Khi I-CSCF nhận được yêu cầu SIP REGISTER (2), nó gửi bản tin Diameter URA tới HSS (3). HSS gửi lại một bản tin Diameter User Authorization Answer (UAA) (4), sau đó I-CSCF sẽ bắt đầu quá trình đăng ký. Quá trình này cũng tương tự như (13) và (14). Sau đó I-CSCF không lưu giữ trạng thái trong quá trình đăng ký. Hơn nữa đến lúc DNS chia tải thì I-CSCF nhận được yêu cầu SIP REGISTER (2) có thể không phải là I-CSCF nhận được yêu cầu SIP REGISTER (12) nữa.

HSS gửi bản tin UAA chứa một mã AVP trả về sẽ giúp I-CSCF xác định được tiếp tục quá trình đăng ký hay hủy bỏ nó. Quá trình đăng ký được cấp quyền trong bản tin UAA có chứa những AVP mà có thể giúp I-CSCF xác định có một S-CSCF sẵn sàng chỉ định tới người dùng hoặc nếu không thì I-CSCF sẽ chọn một S-CSCF mới.

Hình 2.1 Bản tin UAR/UAA, MAR/MAA, SAR,SAA trong quá trình đăng ký



2.3.1.3 Bản tin MAR và MAA

MAR (Multimedia-Auth-Request)

MAA (Multimedia-Auth-Answer)

Hình 2.8 cũng mô tả bản tin Diameter MAR và MAA. Khi S-CSCF nhận được một yêu cầu khởi tạo SIP REGISTER, nó sẽ tiến hành xác thực người dùng IMS. Tuy nhiên trong lần đăng ký đầu tiên S-CSCF không có vector xác thực để xác thực người dùng. Những veator này được lưu trong HSS. S-CSCF gửi bản tin MAR tới HSS với chức năng nhận lại những véc tơ xác thực. Thực tế S-CSCF ghi lại những SIP URI lưu trong dữ liệu người dùng ở HSS. Do vậy các CSCF hoặc là Application Server khác có thể lấy URI của S-CSCF cấp cho từng người dùng một bằng cách truy vấn HSS.

2.3.1.4 Bản tin SAR và SAA

SAR (Server Asignment Request)

SAA (Server Asignment Answer)

Cũng trong hình 2.8 ta thấy có bản tin SAR và SAA. Khi S-CSCF thực sự xác thực được người dùng (nhận dạng người dùng cá nhân) nhận dạng người dùng công cộng sẽ được đăng ký và trở thành như một địa chỉ. Khi đó S-CSCF gửi bản tin SAR tới HSS để thông báo rằng người dùng đang được đăng ký tại S-CSCF. S-CSCF cũng yêu cầu thêm thông tin người òung. HSS đính kèm thông tin người dùng và gửi lại trong bản tin SAA.

S-CSCF cũng gửi bản tin SAR tới HSS khi người dùng trong một thời gian dài không đăng ký tới S-CSCF, như vậy HSS có thể biết được trạng thái đăng ký của người dùng. S-CSCF có thể yêu cầu HSS tiếp tục để cho S-CSCF lưu thông tin người dùng đến khi thực sự người dùng không đăng ký nữa. Quyết định cuối cùng thuộc về HSS, bởi vì HSS sẽ có hoặc không cho phép S-CSCF chỉ định tới thông tin người dùng. Cho phép S-CSCF chỉ định tới thông tin người dùng nghĩa là S-CSCF được lưu trữ thông tin người dùng. Sau khi đăng ký có thể không cần đòi hỏi tải thông tin người dùng từ HSS về nữa.

2.3.1.5 Bản tin LIR và LIA

LIR (Location Information Request)

LIA (Location Information Answer)

Khi một I-CSCF nhận được yêu cầu SIP mà không chứa trường định tuyến trỏ tới chặng tiếp theo, I-CSCF sẽ không biết S-CSCF nào sẽ là S-CSCF được chỉ định tới người dùng. Khi nhận được yêu cầu SIP như vậy I-CSCF sẽ gửi bản tin Location-Info-Request (LIR) tới HSS. HSS trả lời bằng bản tin Location-Info-Answer (LIA). Lệnh trong bản tin LIA sẽ chỉ ra URI của S-CSCF chỉ định tới người dùng đó. Nếu như không có S-CSCF nào chỉ định tới người dùng đó thì sau đó HSS sẽ đưa ra một danh sách các S-CSCF có thể lưu trữ để cho I-CSCF có thể lựa chọn cho người dùng này.

Theo như hình 2.9 một I-CSCF nhận được yêu cầu SIP mà không chứa thông tin định tuyến trong đó, nó gửi bản tin Diameter LIR tới HSS. HSS trả lời bằng bản tin



Diameter LIA trong đó chứa địa chỉ của S-CSCF chỉ định tới người dùng. Do đó I-CSCF chuyển tiếp yêu cầu INVITE tới S-CSCF.

Hình 2.1 Bản tin LIR/LIA và bản tin SAR/SAA

2.3.1.6 Bản tin RTR và RTA

RTR (Registration Termination Request)

RTA (Registration Termination Answer)

Trong quá trình quản lý hoạt động mạng có thể có một hoặc nhiều nhận dạng công cộng được cung cấp cho một người dùng. Khi điều này xảy ra thì HSS gửi một bản tin Registration-Termination-Request (RTR) tới S-CSCF mà người dùng đăng ký.

Hình 2.10 mô tả một HSS đang gửi một bản tin RTR tới S-CSCF với chức năng đăng ký lại một hoặc nhiều nhận dạng người dùng công cộng. S-CSCF sẽ thông báo cho tất cả các thuê bao về trạng thái đăng ký của nó, trong trường hợp này là P-CSCF và thiết bị đầu cuối IMS. Với ví dụ dưới đây, cả P-CSCF và đầu cuối IMS đều nhận được thông báo về trạng thái đăng ký, S-CSCF gửi cho P-CSCF (3), gửi cho đầu cuối IMS (5) và (6).



Hình 2.1 Bản tin RTR/RTA

2.3.1.7 Bản tin PPR và PPA

PPR (Push Profile Request)

PPA (Push Profile Answer)

HSS có thể thay đổi thông tin người dùng, ví dụ như khi một dịch vụ mới được cấp cho người dùng, khi đó trong thông tin người dùng cần có thay đổi trong tiêu chuẩn sàng lọc (filter criteria). Khi thông tin người dùng được cập nhật thì HSS sẽ gửi bản tin PPR tới S-CSCF chỉ định người dùng đó, bản tin này chứa thông tin cập nhật cho thông tin người dùng. Hình 2.11 là một ví dụ về bản tin PPR và PPA.

Hình 2.1 Bản tin PPR/PPA

2.3.2 Các AVP trong Diameter ứng dụng cho giao diện Cx

Diameter ứng dụng cho giao diện Cx định nghĩa một số AVP mới. Hình là danh sách các thuộc tính mới và Code của nó. Trường Vendor-ID của tất cả những AVP này được đặt giá trị 10415, xác định theo 3GPP.



Attribute NameAVP Code

Section defined

Value Type

Visited-Network-Identifier 600 6.3.1 OctetString

Public-Identity 601 6.3.2 UTF8String

Server-Name 602 6.3.3 UTF8String

Server-Capabilities 603 6.3.4 Grouped

Mandatory-Capability 604 6.3.5 Unsigned32

Optional-Capability 605 6.3.6 Unsigned32

User-Data 606 6.3.7 OctetString

SIP-Number-Auth-Items 607 6.3.8 Unsigned32

SIP-Authentication-Scheme 608 6.3.9 UTF8String

SIP-Authenticate 609 6.3.10 OctetString

SIP-Authorization 610 6.3.11 OctetString

SIP-Authentication-Context 611 6.3.12 OctetString

SIP-Auth-Data-Item 612 6.3.13 Grouped

SIP-Item-Number 613 6.3.14 Unsigned32

Server-Assignment-Type 614 6.3.15 Enumerated

Deregistration-Reason 615 6.3.16 Grouped

Reason-Code 616 6.3.17 Enumerated

Reason-Info 617 6.3.18 UTF8String

Charging-Information 618 6.3.19 Grouped

Primary-Event-Charging-Function-Name 619 6.3.20 DiameterURI

Secondary-Event-Charging-Function-Name 620 6.3.21 DiameterURI

Primary-Charging-Collection-Function-Name

621 6.3.22 DiameterURI

Secondary-Charging-Collection-Function-Name

622 6.3.23 DiameterURI

User-Authorization-Type 623 6.3.24 Enumerated

User-Data-Already-Available 624 6.3.26 Enumerated



Confidentiality-Key 625 6.3.27 OctetString

Integrity-Key 626 6.3.28 OctetString

User-Data-Request-Type 627 6.3.25 Enumerated

Supported-Features 628 6.3.29 Grouped

Feature-List-ID 629 6.3.30 Unsigned32

Feature-List 630 6.3.31 Unsigned32

Supported-Applications 631 6.3.32 Grouped

Hình 2.1 Các AVP định nghĩa bởi Diameter ứng dụng cho giao diện Cx

AVP có tên Visited-Network-Identifier chứa xác nhận về mạng nơi P-CSCF nằm trong đó. Một I-CSCF tham chiếu trường tiêu đề P-Visited-Network-ID trong một bản tin yêu cầu SIP REGISTER tới AVP có tên Visited-Network-Identifier. Mạng nhà có thể cấp quyền cho thiết bị đầu cuối IMS để sử dụng P-CSCF trong mạng đó.

AVP có tên Public-Identity mang một nhận dạng người dùng công cộng ( SIP URI hoặc TEL URI)

AVP có tên Server-Name chứa URI của nút SIP server ( ví dụ như URI của S-CSCF )

Server-Capabilities là một nhóm các AVP với chức năng chính chứa những yêu cầu về năng lực của S-CSCF sẽ được phục vụ người dùng. HSS sẽ chuyển những năng lực này này tới I-CSCF, để I-CSCF có thể lựa chọn một S-CSCF thích hợp cho người dùng.

AVP có tên Mandatory-Capability biểu thị một năng lực để lựa chọn S-CSCF trong việc triển khai, trong khi AVP có tên Optional-Capability lại chứa năng lực của S-CSCF có thể được triển khai một cách tùy chọn. Cả hai AVP này đều được lặp đi lặp lại sao cho đạt hiệu quả cao nhất. Năng lực này được biểu diễn bằng một số nguyên. Sự hoạt động của mạng nhà cũng được chỉ định năng lực bằng các số nguyên, đấy là một quyết định đúng đắn vì giao diện Cx chỉ sử dụng trong mạng nhà. Ví dụ năng lực của S-CSCF khi thực hiện mã Java có thể được phân cho mức năng lực là 1, năng lực của S-CSCF khi chạy các kịch bản SIP CGI có thể được phân mức năng lực là 2, và cứ thế.

AVP có tên User-Data chứa thông tin người dùng. Thông tin người dùng sẽ được mô tả kỹ hơn ở phần sau.

S-CSCF muốn biết có bao nhiêu véc tơ chứng thực mà nó muốn nhận từ HSS cho từng người dùng riêng biệt, thông tin đó chứa trong AVP có tên SIP-Number-Auth-Items. HSS cũng sử dụng AVP này để thông báo có bao nhiêu vector chứng thực mà nó thực sự gửi đi.

SIP-Auth-Data-Item là một nhóm các AVP chứa các AVP sau :



SIP-Item-Number

SIP-Authentication-Scheme

SIP-Authenticate

SIP-Authorization

SIP-Authentication-Context

Confidentiality-Key

Integrity-Key.

Khi bản tin Diameter mang nhiều hơn một AVP có tên SIP-Auth-Data-Item và S-CSCF không biết về thứ tự xử lý chúng thì HSS sẽ đặt một số thứ tự trong AVP có tên SIP-Item-Number nằm trong mỗi SIP-Auth-Data-Item

AVP có tên SIP-Authentication-Scheme biểu thị sự chứng thực có hệ thống sử dụng cho chứng thực trong bản tin SIP. 3GPP Release 5 chỉ định nghĩa hệ thống chứng thực là Digest-AKAv1-MD5

AVP có tên SIP-Authenticate thường được dùng bởi HSS để gửi giá trị mà S-CSCF chèn vào trường tiêu đề SIP WWW-Authenticate của hồi đáp 401 UnauthorizeDiameter. Khi người dùng được chứng thực thì thiết bị đầu cuối IMS sẽ gửi một yêu cầu SIP chứa một trường tiêu đề Authorization. Giá trị của tiêu đề này không gửi cho HSS trừ khi có lỗi trong việc đồng bộ hóa. Trong trường hợp đó S-CSCF sẽ sao lưu tiêu đề SIP Authorization vào AVP có tên SIP-Authorization.

AVP có tên SIP-Authentication-Context thường được sử dụng để mang một phần của yêu cầu SIP hoàn chỉnh tới S-CSCF phục vụ cho cơ chế chứng thực.

Hai AVP là Confidentiality-Key and Integrity-Key chứa những chìa khóa độc lập để S-CSCF mã hóa /giải mã hoặc bảo vệ /kiểm tra bản tin SIP được gửi đi hoặc gửi đến từ thiết bị đầu cuối IMS. HSS gửi những chìa khóa này tới S-CSCF cũng trong những AVP này, S-CSCF sẽ chèn nó vào như là một hệ thống thông số mã hóa trong trường tiêu đề SIP WWW-Authenticate và sau đó P-CSCF sẽ bỏ chúng đi.

S-CSCF thông báo lí do kết nối với HSS trong AVP có tên Server-Assignment-Type. Những lí dó có thể là yêu cầu thông tin người dùng, người dùng đăng ký, đăng ký lại hoặc hủy đăng ký; sau một khoảng thời gian chờ trong quá trình đăng ký; việc quản lý xóa đăng ký; một lỗi trong quá trình chứng thực hoặc do chờ đợi quá lâu…

Khi HSS xóa đăng ký của người dùng, nó gửi thông tin tới S-CSCF trong AVP có tên Deregistration-Reason. Deregistration-Reason là một nhóm các AVP chứa các AVP :Reason-Code và Reason-Info. AVP có tên Reason-Code là một mã số để xác định lí do việc xóa đăng ký khởi tạo trong mạng, đó có thể là do việc ký kết chấm dứt hoạt động hoặc do S-CSCF mới đã chỉ định tới người dùng. Còn Reason-Info chứa dạng xâu ký tự có thể đọc được để mô tả lý do xóa đăng ký.

Charging-Information là một nhóm các AVP gửi tới S-CSCF các AAA URI của các nút Event Charging Function (ECF) và Charging Collection Function (CCF). Các



AAA URI của nút sơ cấp và thứ cấp được gửi tới S-CSCF và nút thứ cấp thường được dùng trong trường hợp có lỗi ở nút sơ cấp tương ứng. Charging-Information là một nhóm các AVP gồm có :

Primary-Event-Charging-Function-Name

Secondary-Event-Charging-Function-Name

Primary-Charging-Collection-Function-Name

Secondary-Charging-Collection-Function-Name

AVP có tên User-Authorization-Type biểu thị hình thực chứng thực mà một I-CSCF yêu cầu trong một bản tin UAR. Giá trị của nó thể hiện một đăng ký khởi tạo hay một đăng ký lại, một sự hủy đăng ký hoặc một “đăng ký kèm theo năng lực”. I-CSCF sử dụng giá trị “đăng ký kèm theo năng lực” khi S-CSCF hiện hành chỉ định tới người dùng mà không thể liên lạc được và khi I-CSCF yêu cầu năng lực của S-CSCF để tạo sự lựa chọn S-CSCF mới

Trong một bản tin SAR S-CSCF cũng có thể thông báo có HSS biết S-CSCF đã có thông tin người dùng hay chưa. S-CSCF làm được như vậy nhờ có AVP mang tên User-Data-Already-Available trong bản tin SAR.

2.3.2.1 Cách sử dụng các AVP có sẵn

Bên cạnh những AVP mà 3GPP xây dựng để hỗ chợ Diameter ứng dụng cho giao diện Cx, những yêu cầu và hồi đáp của ứng dụng cũng có thể sử dụng các AVP được định nghĩa trong giao thức Diameter cơ bản (RFC 3588 [60]). AVP quan trọng nhất mà 3GPP sử dụng được mô tả trong mục 2.2.5. Một AVP quan trọng nữa trong IMS là User-Name, nó luôn mang nhận dạng người dùng cá nhân.

2.4 Thông tin người dùng

2.4.1 Cấu trúc tổng quát thông tin người dùng

Thông tin người dung (User Profile) được lưu trữ trong HSS, chứa rất nhiều các thành phần khác nhau. S-CSCF sẽ tải thông tin này về khi người dùng đăng ký lần đầu tiên với S-CSCF đó. S-CSCF nhận thông tin người dùng chứa trong AVP (tên thuộc tính User-Data, AVP, có Code là 606) của bản tin Diameter SAA (Server-Assignment-Answer, có Command Code là 301). Nếu thông tin người dùng được thay đổi trong HSS trong khi người dung đang được đăng ký trên mạng thì HSS sẽ gửi bản tin cập nhật thông tin người dùng trong AVP User-Data của bản tin Diameter PPR (Push-Profile-Request có Command-Code là 305).



Hình 2.1 Cấu trúc thông tin người dung

Hình 2.13 thể hiện cấu trúc của thông tin người dùng. Một thông tin người dùng (user profile) cơ bản nhất là nhận dạng người dùng cá nhân (Private User Identify) tiếp theo một tập hợp các nhận dạng người dùng công cộng (Public User Identities) kết hợp với nhận dạng người dùng cá nhân đó.

Thông tin người dùng bao gồm nhiều thông tin dịch vụ (service profile). Mỗi một thông tin dịch vụ định nghĩa ra cách khởi tạo dịch vụ mà có thể dùng để lấy được nhận dạng người dùng công cộng. Thông tin dịch vụ được chia thành 4 phần :

+ Một hoặc nhiều nhận dạng công cộng ( Public Identifications)

+ Có hoặc không một tùy chọn cấp quyền cho mạng lõi dịch vụ (Core Network Service Authorization)

+ Không có hoặc có nhiều các tiêu chuẩn sàng lọc ban đầu (Initial Filter Criteria)

+ Không có hoặc có nhiều các tiêu chuẩn sàng lọc chia sẻ ban đầu (Shared Initial Filter Criteria)



2.4.2 Nhận dạng công cộng

Nhận dạng công cộng trong thông tin dịch vụ bao gồm nhận dạng người dùng công cộng kết hợp với thông tin dịch vụ tương ứng. Thông tin dịch vụ có thể dùng được cho tất cả danh sách nhận dạng trong nhận dạng công cộng. Mỗi một nhận dạng công cộng chứa 1 cờ để xác định xem nhận dạng người dùng công cộng có được kích hoạt hay không. Việc kích hoạt nhận dạng người dùng công cộng có thể được sử dụng cho quá trình đăng ký, nhưng không phải cho các bản tin SIP khác ( ví dụ như trong việc khởi tạo một phiên ). Do đó một nhận dạng công cộng sẽ chứa một trong hai thông tin khác như SIP URI hoặc TEL URI

2.4.3 Cấp quyền cho mạng lõi dịch vụ

Một thông tin dịch vụ cũng có thể chứa một cấp quyền cho mạng lõi dịch vụ, nó chứa thông tin xác nhận môi trường truyền của thuê bao (subcribered media profile identifier). Thông tin xác nhận môi trường truyền của thuê bao chứa một giá trị xác nhận tập hợp các thông số SDP (Session Description Protocol) mà người dùng được cấp quyền để yêu cầu. Thông tin nhận dạng được lưu trong thông tin dịch vụ, đó là một số nguyên; thông tin SDP thực sự được lưu trong S-CSCF. S-CSCF sử dụng thông tin xác nhận môi trường truyền của thuê bao để đặt một phần thông tin SDP mà có thể giúp S-CSCF kiểm soát thông tin SDP trong yêu cầu khởi tạo của người dùng. Ví dụ, một người dùng có thể không được cấp quyền sử dụng video. Trong trường hợp này, nếu người dùng đó khởi tạo một phiên mà SDP chứa luồng video thì S-CSCF sẽ từ chối phiên khi nó phát hiện ra rằng SDP đó không khớp với thông tin môi trường truyền thuê bao

2.4.4 Tiêu chuẩn sàng lọc ban đầu

Phần thứ ba lưu trong thông tin dịch vụ đó là tiêu chuẩn sàng lọc ban đầu (Initial Filter Criteria). Nó xác định bản tin SIP yêu cầu nào sẽ được đưa tới Application Server để cung cấp các dịnh vụ nhất định. Tiêu chuẩn sàng lọc sẽ xác định những dịch vụ có thể áp dụng để thu thập các nhận dạng người dung công cộng liệt kê trong thông tin dịch vụ.



Hình 2.1 Cấu trúc tiêu chuẩn sàng lọc ban đầu

2.5.4.1 Quyền ưu tiên

Thành phần đầu tiên trong tiêu chuẩn sàng lọc ban đầu là quyền ưu tiên (Priority). Trường Priority sẽ xác định tiêu chuẩn lọc nào được sử dụng. Các quyền ưu tiên sẽ được so sánh với nhau trong cùng một thông tin dịch vụ. S-CSCF sẽ chọn tiêu chuẩn lọc có quyền ưu tiên cao nhất (quyền ưu tiên có giá trị 1 sẽ được ưu tiên cao nhất). Sau khi đánh giá, S-CSCF tiếp tục với các tiêu chuẩn lọc có độ ưu tiên tiếp theo ( 2, 3,….).Trong cùng 1 thông tin dịch vụ, quyền ưu tiên của một tiêu chuẩn lọc là 1 số duy nhất và quan trọng nhất. Trong nhiều trường hợp nó không nhất thiết phải liên tục. Ví dụ quyền ưu tiên cao nhất có thể là 100, cao thứ hai có thể là 200. Điều này rất thuận tiện trong việc giành vị trí quyền ưu tiên cho các dịch vụ cung cấp về sau.

2.4.4.2 Trigger Point

Sau quyền ưu tiên, có thể có một Trigger Point. Trigger Point thể hiện sự cần thiết hay không việc chuyển bản tin SIP yêu cầu tới Server ứng dụng. Một Trigger Point là tập hợp của các tiêu chuẩn lọc riêng lẻ hay còn gọi là Service Point Trigger

Nếu không có Trigger Point nào thì mọi bản tin SIP sẽ được gửi đến Server ứng dụng một cách vô điều kiện



2.4.4.3 Trường thông tin Server ứng dụng

Trong phần này có chứa Application Server SIP URI, đây là địa chỉ của máy chủ ứng dụng sẽ nhận bản tin SIP yêu cầu nếu điều kiện mô tả trong Trigger Point được thỏa mãn.

Ngoài ra còn có trường Default Handing và trường Service Information

Tiêu chuẩn sàng lọc chia sẻ ban đầu

Phần cuối cùng trong thông tin dịch vụ là các tiêu chuẩn sàng lọc chia sẻ ban đầu (Shared Initial Filter Criteria ). Đây là một đặc điểm tùy chọn được yêu cầu hỗ trợ ở cả S-CSCF và HSS. Điển hình là rất nhiều người dùng trên mạng có thể chia sẻ các là tiêu chuẩn sàng lọc ban đầu ( Initial Filter Criteria ). Nó không phải là tối ưu nếu như người dùng luôn đăng ký tại S-CSCF, nó tải về một tiêu chuẩn sàng lọc ban đầu mà đã được tải về từ trước. Chia sẻ tiêu chuẩn sàng lọc ban đầu cho phép tạo cơ sở dữ liệu của tiêu chuẩn sàng lọc ban đầu thuộc về những người dùng. Cơ sở dữ liệu được lưu trữ trong cả S-CSCF và HSS. Mỗi một tiêu chuẩn sàng lọc chia sẻ ban đầu được xác định bởi một mã duy nhất. Khi một thông tin dịch vụ của người dùng chứa một hoặc nhiều tiêu chuẩn sàng lọc chia sẻ ban đầu, chỉ có mã xác định được tải về S-CSCF, S-CSCF sẽ lưu tiêu chuẩn sàng lọc chia sẻ ban đầu trước đó trong cơ sở dữ liệu của nó.

2.5 Giao diện Sh

Giao diện Sh được định nghĩa giữa một SIP AS hoặc một OSA-SCS với HSS. Nó cung cấp các chức năng về lưu trữ và phục hồi dữ liệu, như khi một Application Server tải dữ liệu từ HSS hoặc một Application Server đưa dữ liệu tới HSS. Những dữ liệu này có thể được xử lý bởi các tập lệnh hoặc được cấu hình bởi các thông số để áp dụng cho người dùng và từng dịch vụ đặc biệt. Giao diện Sh cũng cung cấp những dịch vụ về khai báo và xác nhận, bởi vậy AS có thể xác nhận sự thay đổi dữ liệu trong HSS. Khi dữ liệu thay đổi, HSS sẽ thông báo với Application Server.

Việc triển khai giao diện Sh được tùy chọn trong một Appliaction Server và phụ thuộc vào bản chất dịch vụ được cung cấp bởi Application Server: vài dịch vụ đòi hỏi phải tương tác với HSS, số khác thì không.

Giao thức sử dụng trên giao diện Sh vẫn là Diameter với việc bổ xung các Diameter ứng dụng ( mô tả trong 3GPP TS 29.328 [22] và 3GPP TS 29.329 [35]). Ứng dụng này được gọi là Diameter ứng dụng cho giao diện Sh. Việc xây dựng ứng dụng tuân theo các qui tắc của 3GPP, nó định nghĩa những lệnh mới và các AVP mới hỗ trợ cho các yêu cầu chức năng trên giao diện Sh.

2.5.1 Dữ liệu người dùng trên giao diện Sh

Giao diện Sh giới thiệu khái niệm dữ liệu người dùng gồm nhiều loại dữ liệu khác nhau. Hầu hết các bản tin Diameter qua giao diện Sh đều hoạt động trên vài dữ liệu người dùng khác nhau. Dữ liệu người dùng trong giao diện Sh có thể được chia thành một số dạng sau :



Repository data: AS sử dụng HSS để lưu dữ liệu trong suốt. Dữ liệu chỉ có thể hiểu được bởi chính những Application Server triển khai dịch vụ đó. Những dữ liệu này khác nhau tùy vào người dùng và tùy vào dịch vụ.

Public identifiers: danh sách các nhận dạng người dùng công cộng đã được chỉ định

IMS user state: trạng thái đăng ký của người dùng IMS. Những trạng thái đó có thể là đăng ký, chưa đăng ký, chờ đợi trong quá trình chứng thực, hoặc chưa đăng ký nhưng S-CSCF chỉ định tới người dùng đó.

S-CSCF name: chứa địa chỉ của S-CSCF chỉ định tới người dùng.

Initial filter criteria: chứa thông tin khởi tạo dịch vụ.

Location information: chứa vị trí người dùng nằm trong miền chuyển mạch kênh hay trong miền chuyển mạch gói.

User state: Chứa trạng thái người dùng nằm trong miền chuyển mạch kênh hay trong miền chuyển mạch gói.

Charging information: chứa địa chỉ của khối chức năng nạp

2.5.2 Các lệnh định nghĩa trên Diameter ứng dụng cho giao diện Sh

Giao diện Sh định nghĩa 8 bản tin Diameter mới để hỗ trợ cho các yêu cầu về chức năng của giao diện. Hình 2.15 là danh sách các lệnh mới định nghĩa trong Diameter úng dụng cho giao diện Sh.



Hình 2.1 Danh sách lệnh được định nghĩa bởi Diameter ứng dụng cho giao diện Sh

2.5.2.1 Bản tin UDR và UDA

UDR ( User-Data-Request)

UDA (User-Data-Answer)

Application Server gửi một bản tin UDR tới HSS để yêu cầu dữ liệu người dùng cho từng người dùng một. Dữ liệu người dùng có thể ở dạng được định nghĩa cho giao diện Sh. HSS trả lại dạng dữ liệu được yêu cầu trong bản tin UAA. Hình 2.16 miêu tả quá trình này

Hình 2.2 Bản tin UDR/ UDA

2.5.2.2 Bản tin PUR và PUA

PUR (Profile Update Request)

PUA (Profile Update Answer)

Application Server có thể chỉnh sửa loại dữ liệu và lưu chúng vào HSS. Để làm như vậy Application Server phải gửi bản tin PUR tới HSS. HSS sẽ trả lời hoạt động cất giữ của mình trong bản tin PUA. Hình 2.17 miêu tả quá trình này



Hình 2.1 Bản tin PUR/PUA

2.5.2.3 Bản tin SNR và SNA

SNR (Subcribe Notifications Request)

SNA (Subcribe Notifications Answer)

Application Server có thể xác nhận việc thay đổi dữ liệu người dùng bằng cách gửi bản tin SNR tới HSS. Loại dữ liệu người dùng được thông báo là hợp lệ gồm có: repository data, IMS user state, S-CSCF name, và initial filter criteria. HSS sẽ thông báo cho Application Server biết kết quả xác nhận qua bản tin SNA. Hình 2.18 mô tả quá trình này:

Hình 2.1 Bản tin SNR/SNA và bản tin PNR/PNA

2.5.2.4 Bản tin PNR và PNA

PNR (Push Notification Request)

PNA (Push Notification Answer)

Khi dữ liệu người dùng lưu trong HSS có thay đổi và Application Server cần được xác nhận những thay đổi này, HSS sẽ gửi bản tin PNR để thông báo với Application Server. Bản tin PNR chứa một bản sao sự thay đổi dữ liệu Application Server sau đó sẽ trả lời bằng bản tin PNA. Quá trình này cũng được mô tả trong hình 2.18.



2.5.3 Các AVP định nghĩa trong Diameter ứng dụng cho giao diện Sh

Diameter ứng dụng cho giao diện Sh định nghĩa ra một số AVP mới, hình dưới đấy liệt kê tên các AVP mới và mã của nó

Hình 2.1 Các AVP định nghĩa bởi Diameter ứng dụng cho giao diện Sh

User-Identity là một nhóm các AVP chứa xác nhận về người dùng, nó có thể là nhận dạng người dùng công cộng, trường hợp này nó chứa AVP có tên Public-Identity (AVP này mượn của Diameter ứng dụng cho giao diện Cx); hoặc có thể là số Mobile Subscriber Integrated Services Digital Network (MSISDN), trong trường hợp này nó chứa AVP có tên MSISDN.

AVP có tên User-Data chứa dữ liệu người dùng tùy theo định nghĩa dữ liệu người dùng cho giao diện Sh. Loại dữ liệu người dùng được mô tả trong AVP có tên Data-Reference, AVP này chứa giá trị tham chiếu của một vài loại dữ liệu người dùng khác nhau.

AVP có tên Service-Indication chứa xác nhận của dữ liệu lưu trong.

AVP có tên Subs-Req-Type chứa một mô tả về Application Server có xác nhận về thông báo dịch vụ trong HSS hay không.

AVP có tên Current-Location biểu thị một quá trình mang tên “kích hoạt vị trí phục hồi” có được khởi tạo hay không.

AVP có tên Server-Name hoàn toàn tương tự như AVP cùng tên trong Diameter ứng dụng cho giao diện Cx.

2.6 Tính cước

Tính cước được định nghĩa như là một tập hợp của sự tiêu thụ tài nguyên dữ liệu cho mục đích phân chia công suất, phân chia giá trị, sự kiểm định, và sự quảng cáo.

IMS sử dụng giao thức Diameter để truyền các thông tin tính cước. Các CSCF thông báo cho hệ thống tình cước biêt về loại hình và thời gian của phiên mà người dùng khởi tạo. Trên thực tế những thiết bị định tuyến thông báo cho hệ thống tính cước về môi trường truyền trong suốt phiên đó. Hệ thống tính cước kết hợp tất cả các thông tin tính cước liên quan tới từng người dùng để tình cước cho phù hợp.



Hệ thống tính cước sử dụng những nhận dạng duy nhất để làm tương đương những dữ liệu tính toán áp dụng cho từng phiên nhận được từ những thực thể khác nhau. Để cho các bản ghi tính cước được phát ra từ một bộ định tuyến và bởi một CSCF về cùng một phiên phải có cùng một nhận dạng duy nhất.



Chương 3 PHẦN MỀM OPENIMSNgày nay IMS (IP Multimedia Subsystem) cũng đã trong giai đoạn thử nghiệm

với nhiều doanh nghiệp trên khắp thế giới, các nỗ lực phát triển và nghiên cứu, đặc biệt đối với mạng NGN giống như việc tăng thêm nhiều hơn sự hỗ trợ trong 1 số lượng lớn khách hàng, đặc biệt cho việc phát triển các dịch vụ. Trong khi đã có nhiều dự án mã nguồn mở được thiết lập trong mảng VoIP cho các SIP clients, SIP client, proxy, stack và các công cụ xung quanh chuẩn SIP của IETF thì hiện nay thực tế vẫn chưa có 1 dự án mã nguồn mở nào tập trung cụ thể vào IMS.

Dự án mã nguồn mở OPEN SOURCE IMS Core nhằm mục đích đáp ứng sự thiếu hụt của các phần mềm mã nguồn mở cho IMS với những giải pháp linh động và có thể mở rộng được. Tính thích nghi và khả năng của các giải pháp này đã được chứng minh trong các dự án nghiên cứu và phát triển quốc gia và quốc tế. Mục đích của nó trong thời gian tiếp theo là tạo ra một cộng đồng các nhà phát triển cho phần core của mạng NGN. Phần mềm mã nguồn mở này là cho phép sự phát triển của các dịch vụ IMS và thử nghiệm các khái niệm xung quanh phần core IMS.

3.1 Giới thiệu chung về phần mềm OpenIMS của FOKUS

Là một dự án triển khai IMS trên mã nguồn mở của FOKUS (Fraunhofer Institute for Open Communication Systems )



Hình 3.1 Các thành phần của OpenIMS

Hình 3.1 mô tả các thành phần chính của OpenIMS

* Open Source IMS Core :

Đây là phần lõi của OpenIMS, nó gồm có 2 thành phần chính :

+ HSS (Home Subcriber Server): Trong OpenIMS gọi là FHoSS

+ Call Session Control Functions ( CSCFs ): Là khối trung tâm của mã nguồn mở Open Source IMS Core, khối này điều khiển bất kỳ báo hiệu IMS nào.

OpenIMSCore được đưa ra tại website http://openimscore.org/

Được phát triển tại website http://developer.berlios.de/projects/openimscore/

*Đầu cuối IMS (IMS Client)

Trong tất cả các thành phần của OpenIMS, IMS client là thành phần quyết định đánh giá sự thành công của IMS. Nó hoạt động như một môi trường đa ứng dụng để chứng minh khả năng phát triển dịch vụ trên mạng IMS. Có nhiều phần mềm IMS Client, bộ khung OpenIMS Client của FOKUS cung cấp giao diện lập trình được cho các nhà phát triển dịch vụ của IMS. Đặc điểm của OpenIMS Client :

+ Xây dựng các IMS API chuẩn

+ Có khả năng thay đổi một cách mềm dẻo theo yêu cầu


http://developer.berlios.de/projects/openimscore/

http://openimscore.org/


+ Tương thích đa nền (Windows XP, Windows CE, Linux)

+ Được triển khai trên Java hoặc .NET

+ Dễ dàng kết nối với các thiết bị khác

+ Tuân theo các chuẩn IEFT, 3GPP, TISPAN…

Hình 3.2 OpenIMS Client khi chạy lần đầu tiên

Khi OpenIMS Client khởi động lần đầu tiên, nó sẽ hiện ra cửa sổ cho phép cấu hình.

Phần User Profile ta có thể cấu hình các thông số sau :

+ Display name: Tên ngưởi sử dụng sẽ được dùng trong ứng dụng

+ Public Identity: Nhận dàng công cộng, ví dụ sip:[email protected], đúng theo mẫu đã nói trong mục 1.5.1 (Nhận dạng người dùng công cộng)

+ Private Identity: Nhận dạng cá nhân, ví dụ [email protected], đúng theo mẫu trong mục 1.5.2 (Nhận dạng người dùng cá nhân)

+ Secret Key: Chìa khóa bảo mật, sẽ được sử dụng trong các quá trình chứng thực trên mạng.

Phần Server profile cho phép ta cấu hình :

+ Proxy IP: địa chỉ IP của máy chủ P-CSCF trong mạng, ví dụ 192.168.7.97

+ Port Nr: Số cổng của P-CSCF trong mạng, ví dụ 4060

+ Realm : Tên miền của mạng IMS, ví dụ open-ims.test

* Open IMS SIP AS ( SIPSEE – Sip Servlet Execution Environment )

Đây là SIP Application Server cung cấp sự hội tụ của 2 môi trường dịch vụ là SIP và HTTP cho việc xây dựng các dịch vụ


mailto:[email protected]


* Parlay X Gateway (OCS-X)

Cho phép các nhà phát triển dịch vụ tạo các ứng dụng qua web

* IMS Management

Kiến trúc IMS Management để quản lý và điều khiển mọi thành phần cần cho mạng lõi IMS

* XML Document Management Server ( XDMS )

Máy chủ cung cấp hướng dẫn người dung về thông tin dịch vụ và cách truy cập…

* Media Server :

Hỗ trợ các dịch vụ như :

+ Voicemail, lưu lại bản tin rồi gửi vào mail

+ Hội thảo ( Conferencing )

+ Nhạc chờ

+ …

3.2 Fokus Home Subcriber Server ( FHoSS )

Giới thiệu chung

Trong phần mềm OpenIMS do FOKUS phát triển, khối HSS được còn được gọi là FHoSS. ( Fokus Home Subcriber Server )

Hình 3.1 FHoSS trong OpenIMS

FHoSS được xây dựng như một dự án Java, dựa trên một số phần mềm mã nguồn mở khác như MySQL, Tomcat. Dữ liệu người sử dụng được lưu giữ trong cơ sở dữ liệu MySQL. Giao diện web để quản lý chạy trên Tomcat. FHoSS được xây dựng 3 giao diện dựa trên giao thức Diameter ( RFC 3588 ) :

+ Giao diện Sh để cho Application Server truy cập vào HSS

+ Giao diện Cx dung trong các quá trình đăng ký ( cụ thể là giao diện kết nối với I-CSCF và S-CSCF)

+ Giao diện Zh để thiết lập các kênh HTTPS tới các ứng dụng



Phần lõi của FHoSS là một HssDiameterStack. Nó sử dụng DiameterPeer để gửi yêu cầu tới các khối khác và nhận các yêu cầu cũng như hồi đáp theo kiểu CommandListener

Những dữ liệu của HSS được lưu trong một cơ sở dữ liệu. Cơ cấu (Framework) Hibernate persistence được sử dụng để xây dựng tầng truy cập dữ liệu. (Hibernate là một công nghệ rất phổ biến để xây dựng tầng truy cập cơ sở dữ liệu trong các dự án Java)

FHoSS được quản lý bằng giao diện web. Nó được triển khai dựa trên công nghệ servlet trong đó kết hợp với Apache Struts Web framework.

Hình 3.2 Giao diện web quản lý FHoSS

Giao diện web này gồm có các mục chính sau:

Home: Trang chủ

User Identities: cho phép cấu hình thông tin người dùng như IMPU (IP Multimedia Public Identity), IMPI (IP Multimedia Private Identity), IMSU (IMS Subscription) và liên kết các thông tin này lại, một IMPI có thể liên kết với nhiều IMPU



Hình 3.3 Trang cấu hình nhận dạng người dùng cá nhân

SERVICES: cấu hình thông tin dịch vụ

Hình 3.4 Trang cấu hình thông tin dịch vụ

Network Configuration: Cấu hình các thông tin về mạng

Cấu trúc phần mềm của FHoSS



-

Hình 3.5 Cấu trúc thư mục của FHoSS

- Gói main

+ Đây là gói chính để chạy ứng dụng HSS

+ Chứa file HSSContainer.java trong đó có hàm main() để bắt đầu ứng dụng

- Gói diam :

+ Xây dựng nhờ vào JavaDiameterPeer ở phía trên

+ Thực thi giao diẹn command listeners

+ Chứa Diameter Stack

- Gói auth :

+ Chứa file Milenage.java triển khai chức năng xác thực

- Gói db :

+ Chức tất cả các gói nhỏ liên quan đến cơ sở dữ liệu :

+ Gói model chứa tất cả các loại bảng dữ liệu

+ Gói op chứa các gói liên quan đến lớp DAO (Data Access Object )

+ Gói hibernate triển khai theo công nghệ hibernate trong java để kết nối với cơ sở dữ liệu

- Các gói cx, sh, zh triển khai các giao diện tương ứng, trong mỗi gói có chứa gói op bao gồm tất cả các phương thức cần dung cho giao diện đó

- Gói web xây dựng giao diện cho web quản lý FHoSS (hình 2.3)



Chương 4 CÁC MÔ PHỎNG

Chương này sẽ trình bày môt số công việc mô phỏng liên quan đến đề tài dựa trên phần mềm OPENIMS như: tạo người dùng mới, thực hiện cuộc gọi nhắn tin giữa các người dùng, kiêm tra các bản tin gửi và nhận từ khối HSS trong các quá trình hoạt động của người dùng và mạng….

4.1 Tạo và đăng ký người dùng mới

Để tạo thêm một người dùng mới trong cơ sở dữ liệu của HSS ta sử dụng giao diện web quản lý của phần mềm FHoSS.. Thông tin người dùng trong FHoSS gồm có các loại nhận dạng và các trường tương ứng bắt buộc sau:

* IMSU (IP Multimedia Subscription)

+ Tên người dùng

Hình 4.1 Cấu hình thông số IMSU

* IMPI (IP Multimedia Private User Identity)

+ Nhận dạng cá nhân: ví dụ [email protected]

+ Chìa khóa an ninh (Secret Key): là một chuỗi ký tự nào đó

+ Phương thức mã hóa : Digest-AKAv1. Digest-AKAv1 hay Digest-MD5…




Hình 4.2 Cấu hình thông số IMPI

* IMPU (IP Multimedia Public User Identity)

+ Nhận dạng công cộng: ví dụ sip:[email protected]

+ Thông tin dịch vụ (Service Profile). Thông tin dịch vụ được tạo, chỉnh sửa trong mục SERVCES như đã giới thiệu ở hình 3.7.

+ Loại IMPU (IMPU Type): thường là public_user_identity

Sau khi thiết lập đầy đủ, chính xác các trường bắt buộc trong ba loại nhận dạng trên thì cần phải liên kết chúng lại với nhau



Hình 4.3 Cấu hình thông số IMPU

4.2 Cơ sở dữ liệu người dùng trên mysql

Cơ sở dữ liệu trong phần mềm FHoSS là cơ sở dữ liệu quan hệ được xây dựng bao gồm 24 bảng như hình dưới đây:



Hình 4.1 Cơ sở dữ liệu trong FhoSS

Có thể đưa ra sơ đồ thực thể liên kết rút gọn bao gồm một số bảng cơ bản và các trường chính trong đó:



Hình 4.2 Sơ đồ thực thể liên kết rút gọn của cơ sở dữ liệu trong FHoSS

Ta có thể đối chiếu hình trên với hình 1.10: Mối liên hệ giữa nhận dạng cá nhân và nhận dạng công cộng trong Release 6, hình 2.13: Cấu trúc thông tin người dùng và hình 2.14: Cấu trúc tiêu chuẩn lọc ban đầu:

- Mỗi người dùng là một thuê bao IMS (bảng imsu)

- Quan hệ giữa bảng imsu và bảng impi là 1 - ∞ vì mỗi người dùng có thể có nhiều nhận cá nhân (bảng impi).

- Mỗi người dùng cũng có thể có nhiều nhận dạng cá nhân (bảng impu): Do đó quan hệ giữa bảng impi và bảng impu là quan hệ ∞ - ∞. Đúng như theo lý thuyết cơ sở dữ liệu quan hệ, để kết nối giữa hai bảng ∞ - ∞ cần phải có một bảng trung gian (bảng impi_impu).

- Quan hệ giữa bảng sp và bảng impu là quan hệ 1 - ∞ vì như trong hình 2.13 mỗi một Service Point (bảng sp) có thể nằm trong nhiều nhận dạng người dùng công cộng (bảng impu).

- Cũng theo hình 2.13 nhiều Service Point có thể nằm trong một Initial Filter Criteria (bảng ifc) và ngược lại. Như vậy quan hệ giữa bảng sp và bảng ifc là quan hệ ∞ - ∞, liên kết giữa chúng thông quan bảng sp_ifc.

- Theo hình 2.14 một IFC chỉ có thể có nhiều nhất một Trigger Point (bảng tp), quan hệ giữa bảng ifc và bảng tp là quan hệ 1 - 1.

- Quan hệ giữa bảng application_server và bản ifc là 1 - ∞ vì địa chỉ của một máy chủ ứng dụng có thể nằm trong nhiều IFC khác nhau.

- Trong một Trigger Point có thể có nhiều Service Point Trigger nên quan hệ giữa bảng tp và bảng spt là quan hệ 1 - ∞.



4.3 Cấu hình các dịch vụ

Trang cấu hình dịch vụ cho phép cấu hình các mục sau:

* Service Profiles : Tên các dịch vụ

* Application Servers: Máy chủ ứng dụng tương ứng với bảng application_server

Ví dụ các máy chủ ứng dụng đã được cấu hình và chạy thử:

Hình 4.1 Một số máy chủ ứng dụng đã khởi tạo và chạy thử

Trong đó:

+ default_as là máy chủ ứng dụng mặc định

+ media_as là máy chủ ứng dụng hỗ trợ dịch vụ hội thảo

+ iptv là máy chủ ứng dụng cho dịch vụ iptv (xem tv qua mạng IP)

* Trigger Points: Điểm kích hoạt, tương ứng với bảng tp:

Hình 4.2 Một số điểm kích hoạt đã tạo

+ cf_tp: điểm kích hoạt cho dịch vụ conference



+ c2d_tp: điểm kích hoạt cho dịch vụ click to dial

* Initial Filter Criteria: tương ứng với bảng ifc

Hình 4.3 Một số tiêu chuẩn lọc ban đầu đã được tạo

+ cf_ifc: tiêu chuẩn lọc ban đầu cho dịch vụ conference

+ c2d_ifc: tiêu chuẩn lọc ban đầu cho dịch vụ click to dial

4.4 Thống kê các bản tin Diameter trong quá trình đăng ký

Hệ thống dựng lên bao gồm:

+ Máy 1 (192.168.7.97): cài P-CSCF, I-CSCF và S-CSCF

+ Máy 2 (192.168.7.98): cài FHoSS, OpenIMS Client đăng ký người dùng [email protected]

Về lý thuyết quá trình đăng ký diễn ra như trong hình 2.8 và hình 2.9. Ta thấy đầu tiên client gửi bản tin đăng ký sip (7) tới I-CSCF.

Sau khi nhận được đăng ký, P-CSCF sẽ chuyển tiếp bản tin này tới I-CSCF (quá trình bắt gói tin được thực hiện tại Máy 2 nên không nhìn thấy bản tin chuyển tiếp này)

Khi nhận được bản tin đăng ký, I-CSCF sẽ gửi bản tin Diameter UAR tới FHoSS (8) để xác nhận xem người dùng [email protected] sẽ được S-CSCF nào phục vụ.

FHoSS trả lời bằng bản tin UAA (10) thông báo cho I-CSCF biết địa chỉ của S-CSCF phục vụ người dùng đang đăng ký.





Hình 4.1 Một số bản tin trong quá trình đăng ký

Nhận được bản tin UAA, I-CSCF biết được địa chỉ của S-CSCF nên chuyển bản tin đăng ký người dùng tới S-CSCF.

Sau khi nhận được bản tin đăng ký, S-CSCF tiến hành chứng thực người dùng, tuy nhiên vì đây là lần đăng ký đầu tiên nên S-CSCF chưa có các véc tơ chứng thực, do đó nó gửi bản tin MAR (11) tới HSS để tải véc tơ chứng thực về.

HSS gửi các véc tơ chứng thực về cho S-CSCF qua bản tin MAA (12).

S-CSCF gửi bản tin 401 unauthorized về cho người dùng, yêu cầu thông tin chứng thực từ người dùng (14)

Client bắt đầu đăng ký lại, các bản tin tương tự như trên: (17), (18) và (19)

Trong bản tin đăng ký lần này có chứa các thông tin chứng thực, khi S-CSCF so sánh thông tin đó với các véc tơ chứng thực tải về từ HSS. Nếu quá trình chứng thực thành công, S-CSCF sẽ gửi bản tin SAR (20) tới HSS thông báo đã chứng thực người dùng. HSS gửi bản tin SAA trả lời (23).

Quá trình đăng ký thành công, S-CSCF gửi bản tin SIP 200 OK về Client (25).



KẾT LUẬN

Kiến trúc IMS cho phép phát triển dịch vụ rất đa dạng, phong phú và có tính mở rộng lớn. Do đó việc xây dựng cấu trúc thông tin người dùng, quản lý thông tin người dùng và thông tin dịch vụ cần được đặc biệt chú trọng phát triển khi áp dụng mô hình và thực tế.

Do thời gian có hạn nên trong đồ án này tôi mới dừng lại ở việc tìm hiểu lý thuyết và nghiên cứu hoạt động của phần mềm mã nguồn mở OpenIMS

Tôi dự định hướng phát triển của đề tài gồm có các công việc sau :

Khối HSS mới chỉ được FOKUS xây dựng rất cơ bản, chưa có nhiều tính năng để có thể quản lý một khối lượng người dùng lớn khi mạng hoạt động trên thực tế. Do đó đề tài có thể tiếp tục phát triển thêm các chức năng của khối HSS dựa theo phần mềm mã nguồn mở FHoSS.

Khối SLF chưa đươc xây dựng trong phần mềm OPENIMS. Khi một mạng lớn với nhiều thuê bao phải cần nhiều khối HSS để quản lý thì không thể thiếu được khối SLF này. Đây cũng là một hướng phát triển của để tài.



PHỤ LỤCPhần phục lục đưa ra một số hình ảnh về cơ sở dữ liệu người dùng được hiển thị

qua công cụ quản trị co sở dữ liệu Mysql: phpMyAdmin

* Bảng impi: bảng nhận dạng người dùng cá nhân,



* Các bản ghi đã tạo của bảng impi:

* Bảng impu: bảng nhận dạng người dùng công cộng

* Các bản ghi đã tạo của bảng impu:



TÀI LIỆU THAM KHẢO

Gonzalo Camarillo and Miguel-Angel García-Martín, The 3G IP Multimedia Subsystem (IMS), John Wiley & Sons, 2006

Miikka Poikselka, Georg Mayer, Hisham Khartabil, Aki Niemi, IP Multimedia Concepts and Services, John Wiley & Sons, 2004

http://www.openimscore.org

http://www.fokus.fraunhofer.de/bereichsseiten/testbeds/ims_playground/

http://en.wikipedia.org


http://en.wikipedia.org/

http://www.fokus.fraunhofer.de/bereichsseiten/testbeds/ims_playground/

http://www.openimscore.org/

nghiên cứu và phát triển chức năng hss và slf cho kiến trúc ims

Documents