Nghiên cứu và phát triển chức năng HSS và SLF cho kiến trúc IMS

ứ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ụ. Bản tin CER và CEA CFR (Capabilities Exchange Request) CFA (Capabilities Exchange Answer) Là bản tin trao đổi đầu tiên giữa hai nút Diameter, khi kết nối vận chuyển chỉ được khởi tạo một đầu. Hai bản tin này mang các thông tin về nhận dạng của nút và các thông số về lưu trữ của nó ( phiên bản của giao thức, sự hỗ trợ Diameter ứng dụng, cơ cấu hỗ trợ bảo mật…) Bản tin DWR và DWA DWR (Device Watchdog Request) DWA (Device Watchdog Answer) Nó cần thiết cho giao thức Diameter để tìm được các lỗi của tầng vận chuyển và tầng ứng dụng ngay khi có thể, do đó sẽ đưa ra được phản ứng thích hợp. Diameter có thể cung cấp việc xác định các lỗi này là dựa trên cơ chế watchdog của tầng ứng dụng. Trong suốt chu kỳ vận chuyển lưu lượng giữa hai nút Diameter, nếu như một nút gửi yêu cầu mà không nhận được hồi đáp trong một khoảng thời gian nào đó, khi ấy vẫn đủ để tìm ra lỗi ở tầng vận chuyển hay tầng ứng dụng. Tuy nhiên trong trường hợp bị thất lạc nhiều gói qui định thì không thể tìm ra lỗi được. Diameter giải quyết vấn đề này qua việc điều tra tầng vận chuyển và tầng ứng dụng của các nút Diameter trung gian bằng cách gửi bản tin DWR. Sự thiếu vắng của bản tin phản hồi DWA sẽ là cơ sở để xác định nguyên nhân gây lỗi. Bản tin DPR và DPA DPR (Disconnect Peer Request) DPA (Disconnect Peer Answer) Một nút Diameter có thể khởi tạo kết nối với nút Diameter ngang hàng khác, trong khi nút đó có thể lại muốn chấm dứt kết nối. Trong trường hợp này nút Diameter gửi bản tin Disconect-Peer-Request (DPR) tới nút nối với nó để báo rằng chuẩn bị chấm dứt kết nối. Bản tin DPR cũng mang ý nghĩa yêu cầu nút ngang hàng kia không khởi tạo lại kết nối trừ khi cần thiết ( ví dụ trong trường hợp chuyển tiếp bản tin). Bản tin RAR và RAA RAR (Re-Authentication-Request) RAA (Re-Authentication-Answer) Đôi lúc, đặc biệt là khi một phiên đã chấm dứt từ rất lâu, Diameter server có thể yêu cầu người dùng chứng thực lại để đảm bảo tính an ninh, bảo mật. Một Diameter server muốn chứng thực lại người dùng sẽ gửi bản tin Re-Auth-Request tới Diameter client. Diameter client sẽ hồi đáp bằng bản tin Re-Auth-Answer. Bản tin STR và STA STR (Session Termination Request) STA (Session Termination Answer) Một Diameter client gửi thông cáo về Diameter server biết rằng có một người dùng đã rất lâu không sử dụng dịch vụ, để thực hiện như vậy, Diameter client gửi bản tin Session-Termination-Request (STR). Diameter server trả lời bằng bản tin Session-Termination-Answer (STA). Ví dụ nếu server quay số thông báo rằng thông báo rằng kết nối quay số đã bị ngưng sử dụng thì Diameter client sẽ gửi bản tin STR tới Diameter server. Các AVP trong giao thức Diameter cơ bản Mỗi một yêu cầu và hồi đáp định nghĩa những cặp giá trị thuộc tính (AVPs) được trình bày trong bản tin. Một vài AVP có thể là tùy trọn riêng trong yêu cầu hay hồi đáp, số khác là bắt buộc. Sự có mặt 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 … … … 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. 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. 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 Các lệnh định nghĩa bởi Diameter ứng dụng cho giao diện Cx 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. Bản tin UAR/UAA, MAR/MAA, SAR,SAA trong quá trình đăng ký 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. 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. 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. Bản tin LIR/LIA và bản tin SAR/SAA 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). Bản tin RTR/RTA 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. Bản tin PPR/PPA 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 Name AVP 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 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. 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. Thông tin người dùng 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). 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) 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 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 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ụ. Cấu trúc tiêu chuẩn sàng lọc ban đầu 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. 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 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ó. 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. 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 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. Danh sách lệnh được định nghĩa bởi Diameter ứng dụng cho giao diện Sh 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 Bản tin UDR/ UDA 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 Bản tin PUR/PUA 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: Bản tin SNR/SNA và bản tin PNR/PNA 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. 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ó 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. 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. PHẦN MỀM OPENIMS Ngà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. 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 ) 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 Được phát triển tại website *Đầ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 + 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… 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:ha@open-ims.test, đú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ụ ha@open-ims.test, đú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ụ * 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ờ + … 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 ) 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. 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 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ụ 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 - 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) 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…. 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 Cấu hình thông số IMSU * IMPI (IP Multimedia Private User Identity) + Nhận dạng cá nhân: ví dụ ha@open-ims.test + 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… 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:ha@open-ims.test + 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 Cấu hình thông số IMPU 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: 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 đó: 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 - ∞. 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ử: 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: 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 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 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 bob@open-ims.test 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 bob@open-ims.test 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ý. 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ỤC Phầ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