Nghiên cứu và mô phỏng hệ thống IMS trên nền mạng NGN

ang mạng IMS. I-CSCF thực hiện chức năng như một Redirect Server, giao tiếp với S-CSCF của mạng khác khi UE sử dụng dịch vụ liên mạng. Client Client trong giao thức SIP chính là UE, là các thiết bị mà người dùng sử dụng để khởi tạo yêu cầu SIP đến các Server. Thiết bị này có thể là Hardphone hay Softphone. Hardphone là các thiết bị phần cứng hỗ trợ chuẩn SIP như điện thoại IP. Softphone là phần mềm hỗ trợ chuẩn SIP như Express Talk, Sidefisk,… hay hỗ trợ cả IMS như: Mercuro IMS Client, UCT Client, OpenIC_Lite,. . . Bản tin SIP SIP sử dụng các bản tin để khởi tạo, hiệu chỉnh và kết thúc phiên giữa các người dùng. Bảng 4.1: Bản tin yêu cầu SIP Bản tin Ý nghĩa INVITE Khởi tạo một phiên ACK Khẳng định rằng client đã nhận được bản tin đáp ứng cho bản tin INVITE BYE Yêu cầu kết thúc phiên CANCEL Yêu cầu kết thúc phiên Register Đầu cuối SIP đăng ký với Register server OPTIONS Đầu cuối SIP đăng ký với Register server INFO Sử dụng để tải các thông tin Bảng 4.2: Bản tin đáp ứng SIP Bản tin Ý nghĩa 1xx Các bản tin chung 2xx Thành công 3xx Chuyển địa chỉ 4xx Yêu cầu không được đáp ứng 5xx Sự cố Server 6xx Sự cố toàn mạng GIAO THỨC DIAMETER Tổng quan về giao thức Diameter Ban đầu, con người muốn truy cập vào internet đến một Server cụ thể nào đó, người đó phải cung cấp thông tin về user name và password. Trong hầu hết các trường hợp, thông tin về user name và password không được lưu ở máy chủ đáp ứng truy cập mà được lưu ở một nơi khác, có thể là Lightweight Directory Access Protocol. Do đó nảy sinh vấn đề cần một giao thức truyền thông đáng tin cậy để trao đổi thông tin giữa máy chủ truy cập và máy lưu thông tin về user name và password. Vì thế, vào 1995 RADIUS ra đời, được dùng để chứng thực, quản lý quyền truy cập dịch vụ, thông tin tài khoản người dùng. Khi công nghệ di động ngày càng phát triển thì RADIUS không đáp ứng được yêu cầu về QoS và không hỗ trợ chuyển vùng. Điều này là một trở ngại lớn trong sự phát triển dịch vụ. Một yêu cầu đặt ra là tìm ra một công nghệ mới không chỉ đáp ứng được tính năng của RADIUS mà còn khắc phục được những nhược điểm của giao thức này. Đến 1996, IETF chuẩn hóa Diameter trong RFC 3588. Giao thức này thỏa mãn các yêu cầu đặt ra ở trên. Hình 4.2: Giao thức Diameter Giao thức Diameter chia ra 2 phần: Diameter Base Protocol và Diameter Application. Diameter Base Protocol cần thiết cho việc phân phối các đơn vị dữ liệu, khả năng thương lượng, kiểm soát lỗi và khả năng mở rộng. Diameter Application định nghĩa những ứng dụng dữ liệu riêng. Tại thời điểm này, ngoài ứng dụng chuẩn trong RFC3588, một số ứng dụng đã được định nghĩa như: Mobile IP, NASREQ, EAP, Diameter điều khiển tính phí và ứng dụng Diameter trong giao thức SIP,… Diameter là giao thức truyền thông hoạt động trên giao diện Sh giữa HSS, AS, S-CSCF. Cấu trúc giao thức Diameter Trong Diameter có 3 thành phần chính là Server, Client và Agent. Client là một thiết bị ở biên, thực hiện các truy vấn và sử dụng dịch vụ. Một Diameter Agent thực hiện chức năng như một Proxy, Relay, Redirect Agent va dịch các bản tin. Diameter Server quản lý các yêu cầu về AAA cho một hệ thống. Diameter Replay Agent Diameter Relay Agent là một thực thể chấp nhận các yêu cầu và định tuyến các bản tin đến một thực thể khác dựa trên thông tin tìm được trong bản tin như tên miền đích đến của bản tin. Thông tin định tuyến này được thực hiện dựa vào bảng định tuyến được lưu trữ tại các nút mạng. Bảng định tuyến này chứa các trường sau: tên miền, mã ứng dụng, hoạt động cục bộ, nhận dạng Server, cấu hình tĩnh hoăc động, thời gian hết hạn. Mã ứng dụng được dùng như trường quan trọng thứ 2 để tìm kiếm một entry. Trường hoạt động cục bộ chứa một trong bốn giá trị: Local, Relay, Proxy, Redirect. Dựa vào trường này mà Diamter Relay sẽ biết xử lý gói tin hay chuyển tiếp gói tin. Trường nhận dạng Server để xác định nút mạng kế tiếp cần đi đến. Cấu hình tĩnh hay động cho biết entry này được cấu hình tĩnh hoặc tự động tìm ra nút kết tiếp. Nếu là cấu hình động thì có thời gian hết hạn mà entry đó phải được cập nhật lại. Tổng hợp những yêu cầu đến các miền khác nhau và phân bố gói tin đến đích thích hợp giúp giảm nhẹ cấu hình máy chủ truy cập cũng như thuận tiện cho việc thay thế, thêm hoặc bỏ máy chủ truy cập. Diameter Relay Agent thay đổi bản tin bằng cách chèn vào hoặc bỏ các thông tin định tuyến mà không thay đổi bất kì phần nào khác của bản tin. Relay Agent sẽ không duy trì trạng thái phiên mà chỉ duy trì trạng thái giao dịch để thực hiện chức năng Accouting. Diameter Proxy Agent Giống như Relay, Proxy Agent định tuyến các bản tin Diameter sử dụng bảng định tuyết. Tuy nhiên, giữa hai thành phần có sự khác nhau về cách thay đổi bản tin để thực hiện chính sách Diameter Redirect Agent Diameter Reditect Agent thực hiện việc đinh tuyến các bản tin sang tên miền khác. Nó cũng sử dụng bảng định tuyến để xác định chặng tiếp theo của đường đi đến đích đã được yêu cầu. Thay tự vì định tuyến những yêu cầu, Redirect Agent sẽ đáp ứng lại địa chỉ của chặng kết tiếp để Proxy Agent định tuyến. Diameter Translation Agent Diameter Translation Agent là thành phần thực hiện việc chuyển đổi dịch vụ giữa Diameter và một giao thức thực hiện chức năng AAA khác. Translation Agent sử dụng để tương thích với các dịch vụ trên cơ sở hạ tầng mạng sẵn có phỗ biến như RADIUS, TACACS,…. Bản tin Bản tin Diameter chứa một header và một số cặp giá trị thuộc tính AVP. Header gồm nhiều trường với dữ liệu dạng nhị phân giống header của giao thức IP. Hình 4.3: Cấu trúc bản tin trong giao thức Diameter Diameter Header chứa các trường: vertion, Message Length, application ID, Hop-by-hop Identifier, end-to-end identifier. Trường vertion cho biết phiên bản hiện tại của giao thức là 1. Message cho biết chiều dài bản tin. Appliction ID chứa loại ứng dụng được phục vụ. Hai trường cuối dùng để xác định người dùng và địa chỉ chặng kế tiếp trong đường đi. AVP chứa thông tin chứng thực, ủy quyền, và thông tin về tài khoản người dùng để định tuyến, bảo mật, thông tin cấu hình có liên quan đến yêu cầu và đáp ứng bản tin. Mỗi AVP chứa AVP header và AVP data. AVP Header chứa AVP code để xác định thuộc tính của trường Vendor-ID, AVP length: chiều dài của AVP data, AVP Flag qui định về mã hóa, có nhận hay chuyển bản tin,… Trường AVP data có thể là rỗng hoặc nhiều octet chứa thông tin về thuộc tính cụ thể. Định dạng và chiều dài của trường này được xác định bởi trường AVP Code và AVP Length. Định dạng của trường này là một trong những dạng dữ liệu chuẩn sau đây: OctetString, Interger32, Interger64, Unsigned32, Unsigned64, Float32, Float64, Grouped… Để tìm hiểu kỹ về các dạng dữ liệu này, người xem có thể tham khảo [RFC 3588]. Trong trường hợp cần có một dạng dữ liệu cơ bản mới cho AVP Data thì một phiên bản RFC mới hơn phải được tạo ra. Khả năng kiểm soát lỗi của giao thức Diameter Lỗi trong giao thức Diameter chia thành 2 loại: lỗi giao thức và lỗi ứng dụng Lỗi giao thức Xảy ra ở cấp độ giao thức cơ bản như lỗi định tuyến. Khi xuất hiện lỗi, bit E trong trường Command Flag của Diameter Header trong bản tin đáp ứng sẽ được bật lên 1 và gởi trở lại theo đường đến. Hình 4.4: Lỗi giao thức trong Diameter Lỗi ứng dụng Xảy ra ở các ứng dụng của Diameter như chứng thực User, mất gói AVP. Khi xuất hiện lỗi, bit R trong Command Flag trong bản tin đáp ứng được bật lên 1 và gởi lại cho User khởi tạo không thông qua Agent Hình 4.5: Lỗi ứng dụng trong giao thức Diameter Các bản tin đáp ứng lại trong trường hợp có lỗi: Bảng 4.3: Bản tin đáp ứng trong trường hợp có lỗi xảy ra GIAO THỨC COPS Tổng quan về giao thức COPS COPS là giao thức được IETF chuẩn hóa nhằm thực hiện việc quản lý, cấu hình và áp đặt chính sách. Giao thức này hoạt động theo mô hình Client-Server. Nó định nghĩa một giao thức yêu cầu và đáp ứng một cách đơn giản trong việc trao đổi thông tin chính sách và quyết định chính sách giữa server và Client. Trong đó điểm thực hiện chính sách PEP được xem là Client và server là điểm quyết định chính sách PDP. Và một thành phần đặc biệt là điểm quyết định chính sách cục bộ LPDP, nó thay thế cho PDP trong việc liên lạc với PEP khi PDP không được tìm thấy. COPS điều khiển chính sách theo 2 mô hình chính: Outsourcing PEP chỉ định một PDP bên ngoài chịu trách nhiệm xử lý những sự kiện gởi ra từ PEP. Mô hình này cho thấy sự tương quan one-to-one giữa những sự kiện ở PEP và những quyết định từ một PDP. Configuration Không giống như mô hình trước, là không có sự ánh xạ trực tiếp những sự kiện tại PEP và những quyết định từ PDP. PDP có thể cấu hình những sự kiện bên ngoài được khởi tạo bởi một PEP bất kỳ và sự kiện gởi từ PEP có thể được xử lý bởi PDP cùng khối với nó hoặc PDP thuộc khối khác. Xét về mặt thời gian thì mô hình này linh động hơn mô hình outsourcing. COPS sử dụng phương thức truyền TCP để truyền những bản tin đáng tin cậy giữa PEP và PDP. Không giống như giao thức client - server khác, cặp bản tin yêu cầu - đáp ứng này phải phù hợp với cặp bản tin yêu cầu - đáp ứng khác. Ở đây, server có thể áp áp đặt chính sách cho client và xóa những chính sách trên client nếu chính sách đó không còn phù hợp nữa. PEP khởi tạo kết nối TCP đến PDP, PEP gởi yêu cầu và nhận những quyết định chính sách từ PDP và sự liên lạc giữa PEP và PDP là sự trao đổi yêu cầu, đáp ứng. Tuy nhiên PDP hoặc PEP có thể gởi đi những bản tin độc lập, ví dụ như PDP gởi những quyết định tới PEP bắt buộc PEP thay đổi những chính sách được PDP chấp nhận trước đó (không phải bản tin đáp ứng cho những yêu cầu của PEP) và PEP có thể gởi những bản tin báo cáo về trạng thái cho PDP. Sự mở rộng có thể được mô tả trong phần định dạng bản tin và những phần tử mang dữ liệu về chính sách không cần yêu cầu bất kỳ thay đổi nào trong giao thức. COPS được sử dụng trong liên lạc giữa khối PDF và GGSN, tạo sự kết nối giữa mạng IMS và mạng GPRS nhằm cung cấp mức độ bảo mật các bản tin cho việc xác thực, bảo vệ toàn vẹn bản tin. COPS cũng có thể tái sử dụng giao thức về bảo mật như IPSEC hoặc TLS để xác thực và bảo vệ kênh truyền giữa PEP và PDP. Hình 4.6: Mô hình COPS Bản tin COPS Bản tin của giao thức COPS gồm COPS Header và Object format COPS Header Hình 4.7: COPS header Version (4bits): chỉ phiên bản của giao thức COPS đang được dùng, hiện nay đang sử dụng COPS version 1 Flags (4bits): mặc định là 0, cờ flag đặt lên 1 khi bản tin gởi đi là bản tin DEC, khi đó PDP gởi bản tin DEC đáp ứng lại yêu cầu của bản tin REQ do PEP gởi ra. Op Code (8 bits): cho biết hoạt động của COPS. Bảng 4.4: Các loại Op code trong COPS header Giá trị Loại Nơi chốn Tên Mô tả 1 REQ PEP→PDP Request Yêu cầu quyết định từ PDP và thiết lập một client handle nhằm xác định tình trạng phù hợp cho PEP 2 DEC PDP→PEP Decision Trả lại một hoặc nhiều quyết định (đáp ứng) cho một yêu cầu 3 RPT PEP→PDP Report state Báo cáo lại cho PDP biết là PEP đã nhận được đáp ứng của PEP hay chưa và thông báo sự thay đổi trạng thái của PEP 4 DRQ PEP→PDP Delete request state Thông báo cho PDP biết là 5 SSQ PDP→PEP Synchronize state request PDP gởi cho PEP để đồng bộ dữ liệu 6 OPN PEP→PDP Client-Open 7 CAT PDP→PEP Client- Accept 8 CC PEP→PDP PDP→PEP Client-Close Cho biết phần tử Client-type không được hỗ trợ 9 KA PEP→PDP PDP→PEP Keep-Alive Kiểm tra sự tồn tại của PDP/PEP 10 SSC PEP→PDP Synchronize complete Thông báo sự đồng bộ thành công Client-type (16 bits): cho biết chính sách áp dụng cho Client và xác định những thực thể liên quan. 16 bit s có giá trị trong khoảng 0x8000 - 0xFFFF. Đối với bản tin KA thì Client-type phải đặt là 0. Message Length (32 bits): bao gồm header chuẩn và phần tử rút gọn và độ dài chỉ trong 4bytes. Object format Hình 4.8: Object format của bản tin COPS Length: chiều dài của Object format C-num (8 bits): cho biết lớp thông tin chứa đựng trong object Bảng 4.5: Trường C-Num trong Object format của bản tin COPS C-num Tên Nơi chốn Mô tả 1 Handle Most Giá trị duy nhất để xác định trạng thái được cài đặt 2 Context REQ, DEC Cho biết phần tử nào tạo ra những truy vấn 3 In interface REQ Địa chỉ và giao tiếp bên trong của PEP 4 Out interface REQ Địa chỉ và giao tiếp bên bên ngoài của PEP 5 Reason code DRQ Cho biết lý do các yêu cầu bị xóa 6 Decision DEC Quyết định do PDP tạo ra 7 LPDP decision DEC Quyết định do LPDP tạo ra 8 Error CC Xác định giao thức bị lỗi 9 Client-specific info REQ, DEC, RPT, OPN Thông tin về Client 10 Keep-Alive timer CAT Giá trị bộ đếm thời gian 11 PEP identification OPN Xác định PEP cho PDP 12 Report type RPT Loại báo cáo về trạng thái yêu cầu, nó phải tương ứng với handle cụ thể 13 PDP redirect address CC PDP có thể chuyển tiếp trực tiếp PEP đến PDP khác 14 Last PDP address OPN Địa chỉ của PDP mà PEP kết nối lần cuối 15 Accounting timer CAT Xác định thời gian cho việc tính phí 16 Message integrity Any Chuỗi số và sự kiểm bản tin chứng thực nhằm đảm bảo sự bảo mật cho những yêu cầu GIAO THỨC MEGACO/H.248 Tổng quan về giao thức MEGACO/H.248 MEGACO được phát triển bởi IETF (đưa ra vào cuối năm 1998), còn H.248 được đưa ra vào tháng 5/1999 bởi ITU-T. Sau đó cả IETF và ITU-T cùng hợp tác thống nhất giao thức điều khiển MG, kết quả là vào tháng 6/2000 chuẩn MEGACO/H.248 ra đời. MEGACO/H.248 cung cấp một giải pháp toàn diện cho việc điều khiển các MG. Giao thức này hỗ trợ đa phương tiện và các dịch vụ hội thoại nâng cao đa điểm các cú pháp lập trình được nâng cao nhằm tăng hiệu quả cho các tiến trình đàm thoại, hỗ trợ cả việc mã hoá text và binary và thêm vào việc mở rộng các định nghĩa cho các gói tin. MEGACO/H.248 là giao thức báo hiệu giữa Softswitch hoặc MGC với MG (Trunking Media Gateway, Lines Media Gateway hoặc IP Phone Media Gateway). MEGACO/H.248 điều khiển MG để kết nối các luồng từ ngoài. MEGACO/H.248 tương tự với MGCP về mặt cấu trúc và mối liên hệ giữa bộ điều khiển và cổng gateway, tuy nhiên MEGACO/H.248 hỗ trợ đa dạng hơn các loại mạng (ví dụ ATM). Hình 4.9: MEGACO/H.248 kết nối điều khiển Gateway Trong phân hệ IMS, giao thức này hoạt động trên điểm tham chiếu Mn, Mp giao tiếp MRFC với MRFP và MGCF với IMS-MGW Cấu trúc Gateway trong MEGACO/H.248 Hình 4.10: Cấu trúc Gateway trong MEGACO/H.248 MGC: cung cấp báo hiệu SIP hoặc H.323 và thực hiện ánh xạ giữa các giao thức báo hiệu mạng chuyển mạch kênh truyền thống và giao thức báo hiệu IP. MG: cung cấp sự ánh xạ media và chức năng chuyển mã. Nó kết thúc tín hiệu chuyển mạch kênh và tín hiệu media gói và thực hiện chuyển địa chỉ SG: cung cấp môi trường báo hiệu giữa miền IP và miền chuyển mạch kênh truyền thống. Termination và Context MEGACO có hai khái niệm mang tính trừu tượng là: Termination và Context Termination Termination là một thực thể luận lý trên MG như là các nguồn hoặc các luồng điều khiển, … Termination có duy nhất một số nhận dạng (Termination ID) được phân phối bởi MG ở thời điểm chúng được tạo ra. Termication còn biểu hiện cho các thực thể vật lý có thời gian tồn tại bán thường trú như một kênh TDM Termination cũng biểu diễn cho các luồng thông tin ngắn hạn như là các luồng RTP, thường tồn tại trong thời gian chúng được sử dụng. Các tín hiệu có thể áp dụng lên các Termination, các tín hiệu này như là các thông báo. Các Termination cũng có thể được lập trình để phát hiện các sự kiện. Context Context là một sự kết hợp giữa một số Termination. Có một Context đặc biệt được gọi là Context rỗng. Nó chứa các Termination không kết hợp với các Termination khác. Các Termination rỗng có thể có các tham số được khảo sát hoặc sửa đổi và có thể có các sự kiện xảy ra trên chúng. Số lượng Termination lớn nhất trong một Context phụ thuộc vào MG. Chẳng hạn, MG chỉ đưa ra kết nối điểm điểm thì có thể chỉ cho phép hai Termination trên một Context. Các MG hỗ trợ các cuộc hội nghị đa điểm có thể cho phép 3 hoặc nhiều Termination trên một Context. Hoạt động của MEGACO/H.248 Quá trình hoạt động của luồng giao thức MEGACO/H.248 như sau: Bước 1: MGC gửi bản tin Modify đến MG A và MG B để yêu cầu Termination phát hiện nhấc máy. Bước 2: Lệnh Modify được công nhận Bước 3: GW A phát hiện sự nhấc máy và gửi cho MGC. Bước 4: Xác nhận việc nhấc máy Bước 5: MGC ghi nhận sự kiện và gởi bản tin đên MG đê xác nhận sự kiện này. Bước 6, 7: GW A tích lũy các chữ số được quay từ người dùng và gởi các số này đến MGC trong lệnh Notify. Bước 8: MGC công nhận việc nhận các chữ số. Bước 9: MGC quyết định chuỗi số đúng và tạo cuộc gọi. Nó gởi lệnh Add đến MGA để tạo Context. Bước 10: GW A trả lời MGC và đặt tên Context, định bộ nhận dạng Termination RTP (RTP/ID). Bước 11: dựa vào thông tin nhận được từ GWA, MGC gởi lệnh Add chứa thông tin về số bên gọi, bộ mã hóa, … đến GWB. Bước 12: GWB trả lời lại lệnh Add với một Context mới gởi đến MGC Bước 14: MGC dùng lệnh Modify để yêu cầu chuông. Bản tin cũng yêu cầu GWA tìm kiếm sự nhấc máy. Bước 15: User B nhấc máy, cuộc gọi đã được thiết lập, RTP Streaming được truyền 2 chiều từ A sang B. Bước 16: Khi một trong hai bên gác máy ( ở đây ví dụ là bên A), bản tin Modify yêu cầu kêt thúc cuộc gọi được gới đến MGC Bước 17: MGC nhận được yêu cầu và gởi bản tin Rely đáp ứng Bước 18, 19: Lệnh Subtract được gởi từ MGC đến hai GW yêu cầu hủy kết nối (hủy Termination từ một Context). Sau khi nhận được bản tin Rely từ hai Gateway thì kết thúc hoàn toàn một phiên gọi. Hình 4.11: Luồng giao thức của MEGACO/H.248 CHƯƠNG 5: CÁC BƯỚC TIẾN LÊN XÂY DỰNG IMS Để tiết kiệm chi phí và đảm bảo phục vụ liên tục cho các thuê bao hiện có, nhà khai thác mạng không xây dựng mới hạ tầng mà tận dụng cơ sở hạ tầng hiện có và thực hiện chuyển đổi từng bước. Mỗi nhà khai thác có phương pháp, lộ trình chuyển đổi riêng theo hoàn cảnh và đặc tính riêng của họ. Tuy vậy, cách thức chuyển đổi lên NGN đều dựa vào mô hình phân lớp NGN như đề cập ở chương trước. Việc chuyển đổi này được thực hiện thông qua một hoặc nhiều bước tùy vào mức độ mở rộng của từng giải pháp. ĐỐI VỚI MẠNG CỐ ĐỊNH Giai đoạn 1: Tạo ra khối chức năng mô phỏng PSTN/ISDN Phương thức chuyển đổi từ PSTN/ISDN sang PBN được sử dụng nhiều nhất đó là mạng PSTN/ISDN và PBN cùng tồn tại trong giai đoạn chuyển giao. Giải pháp này được thực hiện thông qua 2 bước [10]. Bước 1: Tại bước này một vài tổng đài nội hạt LE được thay thế bằng các AG. Các chức năng của LE sẽ được cung cấp bởi AG và CS. Các thiết bị truy nhập khác như: thiết bị truy nhập hoặc các thiết bị truy nhập từ xa của người sử dụng và các tổng đài nội bộ PABX kết nối với các tổng đài LE đã bị thay thế sẽ kết nối trực tiếp với AG. Trong bước này cũng có thể triển khai các AG bổ sung để cung cấp dịch vụ cho các thuê bao mới. Các TG và SG được triển khai để phối hợp kết nối giữa PBN và mạng PSTN/ISDN của các nhà cung cấp dịch vụ khác. Tất cả các AG và TG được điều khiển bởi CS. Bước 2: Trong bước này, tất cả các tổng đài nội hạt LE còn lại sẽ được thay thế bằng các AG và các tổng đài chuyển tiếp TE sẽ được loại bỏ, các chức năng của TE sẽ được thực hiện tại CS. Các TG và SG được triển khai để phối hợp kết nối giữa PBN và mạng PSTN/ISDN của các nhà cung cấp dịch vụ khác. Tất cả các AG và TG được điều khiển bởi CS Giai đoạn 2: Sử dụng đồng thời cả mạng hiện tại và khối mô phỏng Trong giai đoạn này mạng được chuyển đổi lên kiến trúc mạng lõi NGN. Các thuê bao sẽ sử dụng trực tiếp các thiết bị đầu cuối NGN hoặc các thiết bị đầu cuối truyền thống kết nối thông qua NGN-AG để kết nối với mạng. Cấu trúc mạng theo NGN cho phép mạng mới có thể cung cấp, bên cạnh các dịch vụ tương tự như các dịch vụ được cung cấp bởi mạng PSTN/ISDN, các dịch vụ NGN khác cho các đầu cuối NGN. Các TG và SG được triển khai để phối hợp kết nối giữa mạng NGN với mạng PSTN/ISDN của các nhà cung cấp dịch vụ khác. Giai đoạn 3: Mạng NGN Trong giai đoạn cuối cùng này, các khối softswitch trong mạng phỏng tạo hay mô phỏng PSTN/ISDN còn lại sẽ được bổ sung các tính năng của các CSCF. Cơ sở dữ liệu người dùng được tập trung tại các nút HSS. Chức năng SLF cũng được triển khai để giúp cho việc xác định thông tin thuê bao. Chức năng NASS cũng cần đuợc bổ sung để có thể quản lý thuê bao xDSL kết nối vào mạng. Khả năng liên vận giữa mạng di động và cố định được đảm bảo ở mức tối đa. ĐỐI VỚI MẠNG DI ĐỘNG Giai đoạn 1: Gói hoá mạng di động Mạng di động hiện tại của VNPT gồm phần mạng lõi chuyển mạch kênh (cho dịch vụ thoại) và phần lõi chuyển mạch gói (cho dịch vụ truyền số liệu). Bước đầu tiên trong lộ trình phát triển mạng là tích hợp lưu lượng thoại và lưu lượng truyền số liệu vào mạng lõi IP có hỗ trợ QoS. Các bước cần thực hiện là: Xây dựng mạng lõi IP có hỗ trợ chất lượng dịch vụ. Tách MSC thành MSC server và MGW. Giai đoạn này chưa đem lại sự thay đổi nào trong dịch vụ thuê bao. Tuy nhiên, việc tích hợp lưu lượng vào một mạng lõi IP sẽ giúp giảm chi phí vận hành mạng một cách đáng kể, hỗ trợ việc giảm cước phí dịch vụ thoại, tăng tính cạnh tranh cho nhà cung cấp dịch vụ.  Giai đoạn 2: Bổ sung chức năng điều khiển phiên Việc chuyển đổi được tiếp tục với việc bổ sung thêm chức năng CSCF vào lớp điều khiển mạng thông qua các bước sau: Chuyển đổi chức năng của MSC server thành MGCF (có nhiệm vụ chuyển đổi báo hiệu SS7/IP thành báo hiệu SIP, và điều khiển các media gateway trong mạng). Bổ sung CSCF vào lớp điều khiển. Bổ sung chức năng chuyển đổi giữa báo hiệu IN với báo hiệu của IMS (IM SSF), cho phép giao tiếp giữa CSCF với dịch vụ IN hiện có. Nâng cấp khối HLR thành HSS. Nâng cấp thiết bị đầu cuối di động để hỗ trợ IMS (hỗ trợ SIP, VoIP). Nếu cần thiết, nâng cấp mạng truy nhập vô tuyến lên 3/4G. Có thể thấy là trong giai đoạn này, lưu lượng thoại và lưu lượng số liệu vẫn được chuyển tải trên 2 mạng riêng (mặc dù vẫn trong cùng một mạng chuyển tải IP chung). Giai đoạn 3: Hoàn thiện lớp điều khiển IMS Chuyển đổi mạng của giai đoạn 2 thành mạng tuân thủ IMS (3GPP Release 7) theo các bước sau: MGW không kết nối trực tiếp với RNC mà kết nối qua mạng GPRS. Các chức năng cần thiết khác như PEF (tại GGSN) hay PDF cũng cần được bổ sung (tại P-CSCF). Nâng cấp thiết bị di động đầu cuối để hỗ trợ IP QoS. Tại thời điểm này, mạng di động và mạng cố định có thể hoạt động liên vận hoàn toàn và hỗ trợ di động giữa hai mạng. Cấu hình mạng có thể chỉ gồm một hoặc hai phần điều khiển IMS trong toàn bộ mạng. Hội tụ mạng là một xu hướng quan trọng đối với một nhà khai thác mạng cố định và di động. Để làm được điều này, chúng em đề xuất việc phát triển mạng cố định và mạng di động một cách đồng thời. Mục tiêu cuối cùng là hai mạng có thể hoạt động liên thông cả về truyền tải cũng như dịch vụ dựa trên kiến trúc chuẩn IMS. CHƯƠNG 6: DEMO MÔ HÌNH MÔ PHỎNG NGN Trong chương này, chúng em thực hiện một mô hình mạng NGN hoàn chỉnh từ lớp ứng dụng đến lớp truy cập. Toàn bộ phần mô phỏng sử dụng theo IP và tên gọi theo mô hình như sau: Hình 6.1: Mô hình mô phỏng mạng NGN Với mô hình này, người dùng có thể thực hiện thoại, thoại hình ảnh, chat, truyền dữ liệu hay xem IPTV-VoD khi kết nối với mạng lõi IMS. Lớp ứng dụng sẽ là một máy tính sử dụng hệ điều hành Fedora core 9 đóng vai trò là một AS tích hợp IPTV-VoD. Lớp điều khiển được mô phỏng trên một máy tính khác sử dụng hệ điều hành Ubuntu 8.10. Lớp truyền tải sử dụng máy tính thứ ba, mô phỏng mạng lõi MPLS trên phần mềm GNS3. Cuối cùng, lớp truy nhập, một hoặc nhiều máy client sử dụng softphone hỗ trợ IMS. Như vậy, phần demo có thể mô phỏng một giao dịch thật sự gần giống trong thực tế. LỚP ỨNG DỤNG: MÔ PHỎNG IPTV – VOD Giới thiệu Xu hướng phát triển mạng thế hệ sau NGN hiện nay là chuyển từ Softswitch sang IMS do IMS đem lại khả năng cung ứng dịch vụ đa phương tiện cho người sử dụng đầu cuối mà không bị phụ thuộc vào vị trí, công nghệ truy nhập mạng và vào thiết bị đầu cuối của người sử dụng. IMS hỗ trợ các loại hình dịch vụ khác nhau (thoại, dữ liệu, hình ảnh và khả năng tích hợp của cả ba loại hình dịch vụ nói trên - Tripple Play mà điển hình là dịch vụ IPTV), các công nghệ mạng và các thiết bị đầu cuối. Đặc biệt, trên nền tảng IMS, yếu tố di động và truy nhập không dây trở nên khả thi, càng tạo điều kiện cho IPTV phát triển thành một trong những dạng dịch vụ Quad-Play. Nhiều nhà cung cấp dịch vụ đã bắt đầu triển khai các dịch vụ triple play trên DSL, trong đó IPTV là một thành phần dịch vụ quan trọng. Tuy nhiên mỗi dịch vụ trong nhóm dịch vụ triple play này (như IPTV, VoIP) lại có cơ cấu điều khiển dịch vụ, các hệ thống hỗ trợ tính cước và điều hành riêng của nó, điều này làm tăng sự phức tạp của toàn thể kiến trúc dịch vụ triple play. Hơn nữa, các nhà cung cấp dịch vụ cần phải phân biệt dịch vụ của mình với các nhà cung cấp dịch vụ khác có cùng nhóm dịch vụ. Vì thế việc nghiên cứu về các nền tảng tương tác dịch vụ IPTV và IMS đã ra đời nhằm làm giảm độ phức tạp của mạng và mô hình kiến trúc của IPTV. Kiến trúc IPTV trên nền IMS có thể cung cấp các dịch vụ IPTV được điều khiển và xử lý bởi IMS và có thể chuyển tiếp độc lập các dịch vụ IPTV với mạng truyền tải IP bên dưới. Cách cấu hình IPTV trên IMS Trong chương trình mô phỏng này máy Application Server và Media Streaming server được cài trên hai máy riêng biệt nhưng đều sử dụng hệ điều hành Fedora core 9. Qua quá trình thử nghiệm một số hệ điều hành nguồn mở khác, chúng em nhận thấy Fedora là phiên bản hoạt động ổn định, hỗ trợ nhiều dịch vụ, rất thích hợp cho việc triển khai các ứng dụng mới về sau. Khi một UE đã đăng ký yêu cầu sử dụng IPTV-VoD thì quá trình thực hiện như sau: Bước 1: UE gởi bản tin yêu cầu INVITE chứa tên dịch vụ cần sử dụng đến P-CSCF Bước 2: P-CSCF chuyển tiếp bản tin yêu cầu qua lớp điều khiển đến AS sau khi chứng thực được người dùng. Bước 3: AS kiểm tra yêu cầu để xác định kênh mà UE yêu cầu và kiểm tra trong cơ sở dữ liệu xem có khả năng đáp ứng hay không. Nếu đáp ứng được, AS gởi đáp ứng 200 OK chứa địa chỉ của Media Server chứa kênh mà UE yêu cầu. Bước 4: UE gởi bản tin gởi yêu cầu bằng giao thức RTSP đến Media Server chứa kênh muốn yêu cầu. Bước 5: Luồng truyền thông RTP sẽ truyền qua lại giữa UE và Media Server khi UE sử dụng dịch vụ. Các bước cấu hình IPTV như sau: Hình 6.2: Mô hình IPTV- VoD Server Bước 1: Cấu hình AS Server Cài đặt các gói phụ thuộc: libosip2-3.2.0.tar.gz libeXosip2-3.2.0.tar.gz Sửa thông tin trong .bash để dịch vụ khởi động cùng hệ thống: LIBDIR=/usr/local/lib LD_LIBRARY_PATH=$LIBDIR:/usr/lib export LD_LIBRARY_PATH Tải về và cài đặt gói UCTIPTV_ADVANCED bằng lệnh make tại: https://developer.berlios.de/project/showfiles.php?group_id=7844 Chình sửa tập tin key-value-file để ánh xạ tên kênh mà UE yêu cầu đến Media Server thích hợp. Tập tin này có thể nằm ở đường dẫn /usr/share/iptv khi cài trực tiếp từ internet hoặc nằm tại thư mục cài đặt nếu cài bằng gói. Chỉnh file có nội dung như sau: channel1 value>rtsp://media_server_address.domain:8000/requested_channel Trong đó, media_server_address.domain là địa chỉ Media Server. Trong mô hình này là 192.168.1.201 hay iptv.ims.vn. Chạy AS: dùng key-value-file vừa tạo ở bước trên bằng lệnh: #./uctiptv_as key_value_file Bước 2: Cấu hình Media Server Darwin Streaming Server (DSS) là một sản phẩm của hãng Apple dùng để phân phối các nội dung đa phương tiện. Đây là một phần mềm miễn phí, có cả phiên bản chạy trên Windows và Linux. Bản mới nhất hiện nay là 6.0.3. Với bản này, quá trình cấu hình có phức tạp hơn. Trong bài mô phỏng này sử dụng bản 5.5.5 được xem là chạy ổn định nhất. Tải DSS tại: Tạo nhóm qtss và người dùng qtss thuộc nhóm qtss có mật khẩu là 123. Đây là người dùng mặc định được yêu cầu để cài đặt DSS. Sau khi cài đặt thành công, chúng ta có thể gán quyền quản lý cho người dùng khác. # groupadd qtss # useradd –g qtss qtss # passwd qtss Cài đặt DSS: di chuyển đến đường dẫn chứa DSS tải về Giải nén: # tar -xzvf DarwinStreamingSrvr5.5.5-Linux.tar.gz Cài đặt: #./Install Chạy DSS: # /usr/local/sbin/streamingadminserver.pl Tập tin cấu hình: /etc/streaming/streamingadminserver.conf Khi mở tập tin này, ta sẽ thấy port mặc định để UE kết nối vào DSS là 554, 7070, 8000, 8001. Ta có thể thay đổi port mặc định này. Kiểm tra xem port 1220, port điều khiển DSS, đã hoạt động chưa # netstat -an | grep 1220 Đường dẫn chứa các tập tin nhạc, phim mặc định: /usr/local/movies Ta có thể truy nhập và cấu hình DSS thông qua giao diện web: với user là qtss, password là 123. Sau khi thực hiện các bước cấu hình cơ bản ban đầu, ta được giao diện như sau: Hình 6.3: Giao diện web của DSS Với giao diện này, ta có thể tắt hoặc mở DSS bằng nút Disable Server, có được một số thông tin cơ bản như IP 192.168.1.201, phiên bản DSS, lưu lượng media. Ngoài ra, còn có các tiện ích rất hữu dụng cho người quản lý: Connected Users: cho biết thông tin các kết nối đến DSS tại thời điểm đó. Thông tin bao gồm: IP của UE, bit Rate, dung lượng truyền, tỉ lệ mất gói, thời gian kết nối và kết nối đến tài nguyên nào. General Settings: các thiết lập cơ bản gồm: mật khẩu, nơi chứa tài nguyên, số kết nối tối đa cho phép, băng thông tối đa cho phép, phương pháp chứng thực, Port Settings: cho phép kết nối đến IPTV Server qua port 80 Relay Settings: định nghĩa các máy Server khác có thể làm điểm trung gian để chuyển tiếp nội dung đa phương tiện Log Settings: chứa các ghi nhận sự kiện của DSS, phục vụ đắc lực cho người quản lý. Playlists: định nghĩa các kênh cho người dùng sử dụng. Bước 3: Cấu hình HSS chuyển các yêu cầu sử dụng IPTV đến AS Trong bước này, ta phải thực hiện như sau: Khai báo một AS tên “IPTV” hoạt động tại port 8010 Tạo một trigger point để lọc và chuyển những yêu cầu sử dụng iptv dựa vào địa chỉ UE gởi đến. Ví dụ: Khi UE gởi yêu cầu: sip: channel1@iptv.ims.vn thì dựa vào phần iptv.ims.vn mà HSS hoặc S-CSCF sẽ chuyển yêu cầu này đến AS. Liên kết AS “IPTV” và trigger point vừa tạo bằng chức năng Initial Fillter Criteria. Tạo một iFC để chứa các thông tin dịch vụ mặc định. Các bước được thực hiện như hình sau: Hình 6.4: Cấu hình AS Hình 6.5: Cấu hình Trigger Point Hình 6.6: Cấu hình filter Hình 6.7: Cấu hình HSS để chuyển yêu cầu sử Sau khi hoàn tất các bước trên, trên phân hệ IMS sẽ chuyển các yêu cầu có dạng @iptv.ims.vn sang máy chủ ứng dụng. Máy AS đã mở port 8010 lắng nghe và chờ kết nối. Khi có yêu cầu từ client, AS sẽ tra trong tập tin key_value_file và gởi lại đáp ứng địa chỉ của Media Server. Khi đó, client sẽ sử dụng trực tiếp từ Media Server qua giao thức RTSP và RTP bằng port: 554, 7070, 8000 hoặc 8001. LỚP ĐIỀU KHIỂN: OPENIMSCORE Giới thiệu Open IMS Core là một dự án mã nguồn mở của viện FOKUS của Đức bao gồm: Call Session Control Functions (CSCFs). Home Subscriber Server (HSS) tuy nhiên ở dạng thu gọn và được gọi là FHoSS. Cách xây dựng IMS core Bước 1: cài đặt các phần mềm cần thiết từ source code [5] Tạo thư mục chứa các file cài đặt #mkdir /opt/OpenIMSCore #cd /opt/OpenIMSCore #mkdir FHoSS #mkdir ser_ims Tải source code #apt-get install subversion #svn checkout OpenIMSCore /FHoSS/trunk FHoSS #svn checkout OpenIMSCore /ser_ims/trunk ser_ims #apt-get install sun-java6-jdk mysql-server libmysqlclient15-dev libxml2-dev bind9 antflexbison # cd FHoSS # ant compile deploy # cd .. # cd ser_ims # make install-libs all # cd .. Bước 2: chỉnh sửa file cơ sở dữ liệu #vi /opt/OpenIMSCore/ser_ims/cfg/icscf.sql Thay đổi open-ims.test thành ims.vn Thêm 2 users: grant delete,insert,select,update on icscf.* to icscf@192.168.1.200 identified by 'heslo'; grant delete,insert,select,update on icscf.* to provisioning@192.168.1.200 identified by 'provi'; #vi /opt/OpenIMSCore/FHoSS/scripts/hss_db.sql Thêm user: grant delete,insert,select,update on hss_db.* to hss@192.168.1.200 identified by 'hss'; #vi /opt/OpenIMSCore/FHoSS/scripts/userdata.sql Thay đổi open-ims.test thành ims.vn Bước 3: thay đổi cấu hình các file *.cfg, *.xml, *.sh Copy file cấu hình: #cp ser_ims/cfg/*.cfg #cp ser_ims/cfg/*.xml #cp ser_ims/cfg/*.sh Chạy lệnh sau để thay đổi thông tin về domain và ip ./configurator.sh pcscf.cfg icscf.cfg icscf.xml scscf.cfg scscf.xml ser_ims/cfg/icscf.sql FHoSS/deploy/DiameterPeerHSS.xml FHoSS/deploy/hss.properties FHoSS/scripts/hss_db.sql FHoSS/scripts/userdata.sql Domain name: ims.vn IP Address: 192.168.1.200 File to changeFile to change ["all" for everything, "exit" to quit]: all changing Bước 4: thiết lập cơ sở dữ liệu Tạo một account root pass 123 #mysqladmin -u root password 123 Tạo cơ sở dữ liệu: #cd /opt/OpenIMSCore #mysql –uroot –p< ser_ims/cfg/icscf.sql #mysql –uroot –p< FHoSS/scripts/hssdb.sql #mysql –uroot –p< FHoSS/scripts/userdata.sql Bước 5: thay đổi cấu hình cho FHoSS Vào đường dẫn: /opt/OpenIMSCore/FHoSS/deploy/* Thay đổi các thông tin: Domain name: chuyển open-ims.test bằng ims.vn IP: chuyển 127.0.0.1 thành 192.168.1.200 Cấu hình DNS, vào đường dẫn: /etc/bind File cấu hình zone thuận như sau: $ORIGIN ims.vn. $TTL 1W @ 1D IN SOA ims.vn. root.ims.vn. ( 2006101001 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum 1D IN NS ns ns 1D IN A 192.168.1.200 pcscf 1D IN A 192.168.1.200 _sip.pcscf 1D SRV 0 0 4060 pcscf _sip._udp.pcscf 1D SRV 0 0 4060 pcscf _sip._tcp.pcscf 1D SRV 0 0 4060 pcscf icscf 1D IN A 192.168.1.200 _sip 1D SRV 0 0 5060 icscf _sip._udp 1D SRV 0 0 5060 icscf _sip._tcp 1D SRV 0 0 5060 icscf ims.vn. 1D IN A 192.168.1.200 ims.vn. 1D IN NAPTR 10 50 "s" "SIP+D2U" "" _sip._udp ims.vn. 1D IN NAPTR 20 50 "s" "SIP+D2T" "" _sip._tcp scscf 1D IN A 192.168.1.200 _sip.scscf 1D SRV 0 0 6060 scscf _sip._udp.scscf 1D SRV 0 0 6060 scscf _sip._tcp.scscf 1D SRV 0 0 6060 scscf trcf 1D IN A 192.168.1.200 _sip.trcf 1D SRV 0 0 3060 trcf _sip._udp.trcf 1D SRV 0 0 3060 trcf _sip._tcp.trcf 1D SRV 0 0 3060 trcf bgcf 1D IN A 192.168.1.200 _sip.bgcf 1D SRV 0 0 7060 bgcf _sip._udp.bgcf 1D SRV 0 0 7060 bgcf _sip._tcp.bgcf 1D SRV 0 0 7060 bgcf mgcf 1D IN A 192.168.1.200 _sip.mgcf 1D SRV 0 0 8060 mgcf _sip._udp.mgcf 1D SRV 0 0 8060 mgcf _sip._tcp.mgcf 1D SRV 0 0 8060 mgcf hss 1D IN A 192.168.1.200 ue 1D IN A 192.168.1.200 iptv 1D IN A 192.168.1.201 media 1D IN A 192.168.1.202 pcrf 1D IN A 192.168.1.200 clf 1D IN A 192.168.1.200 File cấu hình zone nghịch như sau: $TTL 604800 @ IN SOA ims.vn. root.ims.vn. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; IN NS ims.vn. 200 IN PTR ims.vn. 201 IN PTR iptv.ims.vn. 202 IN PTR media.ims.vn Cấu hình tập tin resolv.conf để thiết lặp máy ims core làm DNS Vào đường dẫn /etc/resolv.conf, thêm dòng sau: nameserver 192.168.1.200 Khởi động lại dịch vụ: #/etc/init.d/bind9 restart Bước 6: Khởi động IMS #cd /opt/OpenIMSCore Start pcscf #./pcscf.sh Listen port: 192.168.1.200:4060 Hình 6.8: Giao diện hoạt động của P-CSCF Start icscf #./icscf.sh Listen port: 192.168.1.200:5060 Hình 6.9: Giao diện hoạt động của I-CSCF Start scscf #./scscf.sh Listen port: 192.168.1.200:6060 Hình 6.10: Giao diện hoạt động của S-CSCF Start FHoSS #./fohss.sh Listen port: 192.168.1.200:3868 Listen port for Diameter Cx from ICSCF: 192.168.1.200:3869 Listen port for Diameter Cx from SCSCF: 192.168.1.200:3870 Listen port for Tomcat webserver: 192.168.1.200:8090 Hình 6.11: Giao diện hoạt động của HSS Hình 6.12: Giao diện quản lý user của HSS Lệnh kiểm tra port: netstat -an | grep 4060 netstat -an | grep 5060 netstat -an | grep 6060 netstat -an | grep 3868 netstat -an | grep 3869 netstat -an | grep 3870 netstat -an | grep 8090 LỚP TRUYỀN TẢI: MPLS Giới thiệu MPLS được hình thành bởi IETF trong RFC 3031[4]. MPLS là một công nghệ lai kết hợp những đặc điểm tốt nhất giữa định tuyến lớp 3 và chuyển mạch lớp 2 cho phép chuyển tải các gói rất nhanh trong mạng lõi và định tuyến tốt ở các mạng biên bằng cách dựa vào nhãn. MPLS là một biện pháp linh hoạt để giải quyết những vấn đề gặp nhiều khó khăn trong mạng hiện nay như: tốc độ, quy mô, chất lượng dịch vụ (QoS), quản trị và kỹ thuật lưu lượng. MPLS thể hiện một giải pháp thông minh để đáp ứng những đòi hỏi dịch vụ và quản lý dải thông cho mạng IP thế hệ sau dựa trên mạng đường trục. MPLS giải quyết những vấn đề liên quan đến tính quy mô và định tuyến (dựa trên QoS) và có thể tồn tại trên mạng ATM và mạng Frame-Relay đang tồn tại. Chính vì thế, MPLS được ưu tiên chọn lựa làm mạng lõi truyền tải cho mô hình mạng NGN. Trong phần demo này mạng lõi MPLS được cài đặt theo mô hình như đã nêu ở phần trên. Các thông số, lệnh cài đặt được trình bày chi tiết trong bài báo cáo “QoS trong MPLS” Một số lệnh kiểm tra cấu hình MPLS trên Router Cisco 7200 Sau khi cấu hình MPLS hoàn chỉnh, ta có thể kiểm tra bằng các lệnh sau: Thực hiện trên router CORE3: CORE3#sh mpls interfaces Interface IP Tunnel BGP Static Operational FastEthernet1/0 Yes (ldp) Yes No No Yes FastEthernet1/1 Yes (ldp) Yes No No Yes FastEthernet2/0 Yes (ldp) Yes No No Yes FastEthernet2/1 Yes (ldp) Yes No No Yes CORE3#show mpls ldp discovery Local LDP Identifier: 3.3.3.3:0 Discovery Sources: Interfaces: FastEthernet1/0 (ldp): xmit/recv LDP Id: 1.1.1.1:0 FastEthernet1/1 (ldp): xmit/recv LDP Id: 4.4.4.4:0 FastEthernet2/0 (ldp): xmit/recv LDP Id: 5.5.5.5:0 FastEthernet2/1 (ldp): xmit/recv LDP Id: 6.6.6.6:0 CORE3#show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or VC or Tunnel Id Switched interface 16 Pop Label 6.6.6.6/32 0 Fa2/1 192.168.8.2 17 Pop Label 192.168.11.0/24 0 Fa2/1 192.168.8.2 18 Pop Label 192.168.9.0/24 0 Fa1/1 192.168.5.2 Pop Label 192.168.9.0/24 0 Fa2/1 192.168.8.2 19 Pop Label 4.4.4.4/32 0 Fa1/1 192.168.5.2 20 Pop Label 192.168.7.0/24 0 Fa1/1 192.168.5.2 Pop Label 192.168.7.0/24 0 Fa2/0 192.168.6.2 21 Pop Label 192.168.4.0/24 0 Fa1/1 192.168.5.2 22 Pop Label 5.5.5.5/32 0 Fa2/0 192.168.6.2 23 Pop Label 192.168.10.0/24 0 Fa2/0 192.168.6.2 24 Pop Label 1.1.1.1/32 0 Fa1/0 192.168.3.1 25 Pop Label 192.168.2.0/24 0 Fa1/0 192.168.3.1 29 28 2.2.2.2/32 0 Fa1/0 192.168.3.1 29 2.2.2.2/32 0 Fa1/1 192.168.5.2 30 31 5.5.5.5 1 [21] 0 Fa1/0 192.168.3.1 31 Pop Label 2.2.2.2 1 [8] 0 Fa2/0 192.168.6.2 32 Pop Label 2.2.2.2 3 [8] 0 Fa2/0 192.168.6.2 33 Pop Label 2.2.2.2 5 [8] 0 Fa2/0 192.168.6.2 LỚP TRUY NHẬP: CLIENT Giới thiệu Client chính là UE đã đề cập ở phần trên. Hiện nay có rất nhiều phần mềm có chức năng thực hiện các yêu cầu dịch vụ cho UE như: Mercuro Client, UCT Client và OpenIC_Lite, IMS Communicator, Counterpath X-lite…. Trong phần demo này, chúng em dùng phần mềm UCT IMS Client để kết nối với IMS Core. UCT IMS Client hỗ trợ các tính năng như: Audio Call Chat Video Call Hỗ trợ XCAP/XDMS, đây là Server ứng dụng dùng quản lý chính sách và dữ liệu người dùng như danh bạ, các dịch vụ đã thực hiện,… Hỗ trợ QoS Tùy chỉnh Codec giúp chất lượng thoại, video tốt hơn. Hỗ trợ Buddy list và Presence Chứng thực bằng AKA và MD5 Hỗ trợ IPTV Có chứng năng như PDP và PEP. Cài đặt UCT client Cài các gói phụ thuộc:[6] Linux-based operating system libosip2 (3.0.3 with version 1.0.10 and 2.2.3 earlier versions) libexosip2 (3.0.3 with version 1.0.10 and 2.2.3 earlier versions) libgtk2-0 libxml2 libcurl3 libgstreamer0.10-0 libgstreamer-plugins-base0.10 libvlc0 vlc Cài UCT IMS client từ gói .deb # dpkg -i uctimsclient1.0.12.deb Cấu hình UCT IMS Client: Sau khi cấu hình thành công IMS, hệ thống đã tạo sẵn hai người dùng có tên là Bob@ims.vn và Alice@ims.vn. Do đó, ngay sau khi cài đặt, ta có thể sử dụng ngay chính người dùng tên Bob và Alice để thực hiện dịch vụ như: đăng ký, xóa đăng ký, gọi, xem iptv ( channel 1, 2, 3),… Hình 6.13: Giao diện của trình Option và IPtv trong UCT IMS client. Trong hình trên, tab Options, ta có thể đăng ký với hệ thống với tên sử dụng là Alice ( Register as Alice) hoặc Bob ( Register as Bob). Sau đó, Bob hoặc Alice có thể gọi cho nhau. Trong tab IPtv đã liệt kê sẵn ba channel và có thể xem ở chế độ toàn màn hình. Hình 6.14: Giao diện của UCT IMS client khi Bob đã đăng ký Nếu có người dùng mới (người dùng phải được tạo ra trước tại HSS), ở đây ta cấu hình một người dùng tên Chau, có khóa nhận dạng người dùng chung là chau@ims.vn, ta tiến hành như sau: Vào Options/Preferences: Hình 6.15: Giao diện cấu hình Preferences: tab Profile và IMS Hình 6.16: Giao diện cấu hình Preferences: tab Media và XDMS Tab Profile cho phép cấu hình: các dịch vụ, tinh năng của từng người dùng Tab IMS: cấu hình các thông số chứng thực và tên miền Tab Media: cấu hình địa chỉ IPTV Server và các thông số truyền thông đa phương tiện. Tab XDMS: chỉ ra tập tin cấu hình Xcap Server Sau đó chọn Register là người dùng tên chau đăng ký vào hệ thống như hình đưới đây: Hình 6.17: Người dùng tên chau mới tạo ra đã đăng ký vào hệ thống Lúc này, người dùng này đã được một S-CSCF phục vụ có thể sử dụng được các dịch vụ mà hệ thống cung cấp. Kết quả mô phỏng UE đăng ký Phần này thực hiện việc đăng ký của người dùng tên Bob vào hệ thống. Địa chỉ hiện tại của Bob là 192.168.1.100. Luồng thông tin đăng ký sẽ đi từ UE à P-CSCF àI-CSCF. Lúc này, I-CSCF sẽ gởi bản tin UAR để truy vấn HSS có S-CSCF nào sẵn sang cấp phép cho thuê bao mới hay không. Nếu như I-CSCF không được cung cấp tên S-CSCF thì sẽ gởi bản tin LIR đến HSS để yêu cầu các thông tin liên quan đến S-CSCF đang hoạt động để phục vụ cho UE. S-CSCF được chọn sẽ gởi bản tin MAR để thông báo là nó sẽ phụt trách thuê bao đó. Cuối cùng, S-CSCF sẽ yêu cầu HSS cho phép được tải các thông tin liên quan đến thuê bao bằng cách gởi bản tin SAR. Tại Client: Đầu tiên Client nhận bản tin Unauthoried báo thất bại. Bản tin này cũng kèm theo các thông số bảo mật trao đổi giữa UE và P-CSCF. Khi Client gởi đăng ký lần hai, các thông số truyền thông và bảo mật được thiết lập thì nhận được bản tin OK và SAR báo đăng ký thành công: Hình 6.18: Bob đăng ký thành công vào hệ thống ims.vn Tại P-CSCF: Khi Bob@ims.vn đăng ký: Hình 6.19: Giao diện P-CSCF khi UE đăng ký Tại S-CSCF: khi Bob sử dụng UCT IMS Client đăng ký thành công: Hình 6.20: Giao diện S-CSCF khi Bob đăng ký thành công Tại HSS: xử lý các bản tin LIR, UAR, MAR và SAR như đã nêu ở trên để thực hiện việc đăng ký cho Bob@ims.vn và gán một S-CSCF phục vụ UE này. Hình 6.21: Giao diện HSS khi Bob đăng ký Hình 6.22: Giao diện Web của HSS: UE đăng ký thành công được gán một S-CSCF UE thực hiện cuộc gọi Alice và Bob đều đã đăng ký vào miền ims.vn. Alice tại địa chỉ 192.168.1.8 khởi tạo cuộc gọi đến Bob có IP là 192.168.1.100. Luồng thông tin yêu cầu thiết lập phiên được chuyển từ UE à P-CSCF à S-CSCF à định tuyến đến UE bị gọi. Do cả Bob và Alice đều thuộc mạng ims.vn nên S-CSCF sẽ truy vấn HSS để tìm ra S-CSCF và trạng thái của Bob. Nếu Bob đã đăng ký, HSS sẽ đáp ứng bản tin LIR cung cấp địa chỉ S-CSCF phục vụ thuê bao này. Cuối cùng, sau khi thỏa thuận các thông số truyền thông thì phiên được thiết lập giữa Alice và Bob. Tại UCT IMS Client của Alice, bản tin INVITE được gởi đến P-CSCF qua port 4060. Bản tin này chứa địa chỉ của Bob. Khi xác định được Bob thì UE nhận được chuông 180 Ringing. Khi Bob đồng ý cuộc gọi thì Alice sẽ nhận được đáp ứng 200 OK và phiên SUBSCRIBE được thiết lập. Hình 6.23: Giao diện UCT IMS Client phía Alice khi Alice khởi tạo cuộc gọi đến Bob Hình 6.24: Giao diện UCT IMS Client phía Bob báo có cuộc gọi đến từ Alice. Hình 6.25: Giao diện S-CSCF khi Alice và Bob thực hiện cuộc gọi. UE sử dụng dịch vụ IPTV Với người dùng IMS, IPTV VoD là một dịch vụ được hỗ trợ rất tốt. Ngay chính trong giao diện của UCT IMS Client có công cụ để sử dụng dịch vụ dễ dàng. Đối dịch vụ IPTV cơ bản, IPTV Server phát quảng bá ba kênh 1, 2, 3 . Người dùng chỉ cần chọn kênh là có thể sử dụng được dịch vụ. Khi phát triển IPTV trên quy mô lớn hơn, chúng ta có thể triển khai thêm nhiều kênh, đồng thời hỗ trợ dịch vụ VoD. Mỗi khi người dùng kết nối đến IPTV – VoD Server thì sẽ tự động nhận được danh sách các chương trình đang phát. Người dùng chọn chương trình rồi nhập tên chương trình đó vào URI trên UCT IMS Client. IMS Core sẽ phân tích yêu cầu rồi chuyển yêu cầu đó đến máy chủ IPTV đáp ứng cho người dùng. Trong phần demo này, UE thực hiện gởi yêu cầu xem IPTV channel1 thì nhập: sip:channel1@iptv.ims.vn hoặc sử dụng dịch vụ VoD thì sử dụng địa chỉ của DSS: rtsp://media.ims.vn:8000/sample_300kbit.mp4 Hình 6.26: Giao diện VLC khi client sử dụng dịch vụ VoD Mở giao diện web quản lý DSS, mục Connected User, người quản trị sẽ biết những người dùng nào đang kết nối, đang sử dụng tài nguyên nào, tỉ lệ lỗi… giúp cho việc quản lý dễ dàng và có thể khắc phụ sự cố nhanh nhất. Hình 6.27: Giao diện DSS khi có người dùng kết nối Nhận xét Tóm lại, chỉ với các phần mềm nguồn mở như trên, cùng với một số kiến thức nhất định về mạng và viễn thông, chúng ta hoàn toàn có thể dựng hệ thống tổng đài ở mức cơ bản và cung cấp dịch vụ IPTV – VoD. Quá trình mô phỏng thực hiện trên các máy tính cấu hình ở mức trung bình. Phần mềm GNS3 (miễn phí) giúp xây dưng hệ thống router chuyển mạch nhãn MPLS. Phần mềm UCT IMS Client đóng vai trò Client sử dụng dịch vụ. Tất cả các yếu tố trên kết hợp lại, tạo nên một mô hình NGN hoàn chỉnh phục vụ đắc lực cho nghiên cứu phát triển mạng thế hệ mới tại các trung tâm, trường học, phòng nghiên cứu và phát triển,… Tuy vậy, do một số yếu tố khách quan như: các gói phần mềm phụ thuộc không được tích hợp với nhau, các phiên bản phần mềm nguồn mở đổi mới liên tục, sử dụng nhiều thiết bị ảo nên băng thông không được đảm bảo cho các dịch vụ thời gian thực và số người nghiên cứu chưa nhiều đã gây ra một số khó khăn cho quá trình mô phỏng và triển khai trong thực tế. Chúng em hi vọng các yếu tố trên sẽ được khắc phục, nhanh chóng đưa IMS trên nền mạng NGN được triển khai rộng rãi, đem lại lợi ích cho mọi người. CHƯƠNG 7: TỔNG KẾT VÀ HƯỚNG PHÁT TRIỂN Với nội dung đặt ra là tìm hiểu kiến trúc IMS trên nền mạng NGN, luận văn đã đưa ra được kiến trúc tổng quát nhất của một phân hệ IMS theo tiêu chuẩn của tổ chức 3GPP. Bên cạnh đó, luận văn cũng đã lý giải vai trò, nhiệm vụ, chức năng của các thành phần, giao diện, và một số thủ tục thực hiện trong phân hệ IMS. Hơn nữa, bài báo cáo còn trình bày phương pháp xây dựng mạng IMS từ nền tảng mạng hiện có. Đây là môt trong những điểm khác biệt với đề tài khác. Với mục tiêu đặt ra, đề tài đã thực hiện được các nội dung sau: Tìm hiểu về kiến trúc mạng IMS trên nền mạng lõi NGN để thấy được vai trò hội tụ mạng và tích hợp dịch vụ của phân hệ này. Hội tụ mạng và tích hợp dịch vụ là vấn đề then chốt khi xây dụng mạng NGN. Trình bày các thủ tục sử dụng dịch vụ để thấy được hoạt động của phân hệ này trong NGN. Nội dung này giúp người đọc hiểu sâu hơn và kiểm chứng lại chức năng các thực thể trong phân hệ. Luận văn đã giới thiệu một số giao thức chính sử dụng trong phân hệ IMS, đặc biệt là giao thức SIP và Diameter. Đây là hai giao thức dựa trên nền text tạo nên sự khác biệt giữa IMS và các hệ thống khác. Luận văn đã nêu lên tình hình mạng viễn thông hiện tại và đưa ra đề xuất từng bước xây dựng hệ thống IMS trên nền mạng NGN dựa trên hạ tầng mạng hiện tại. Giới thiệu và xây dựng thành công mô hình mạng NGN bao gồm: client truy cập, mạng lõi MPLS để truyền dẫn, IMSCore điểu khiển dịch vụ và máy chủ ứng dụng IPTV Server. Với mô hình này, client có thể truy cập để thực hiện đầy đủ dịch vụ Tripple Play như: thoại, video call, chat, truyền nhận dữ liệu, xem IPTV,… Kết hợp với đề tài “QoS over Tripple Play” đảm bảo chất lượng dịch vụ từ đầu cuối đến dầu cuối. Do tích chất thực hiện luận văn nằm ở mức nền tảng trong nghiên cứu về IMS, nên đề tài này giới hạn ở những nội dung trên. Nếu có điều kiện, chúng em sẽ tiếp tục nghiên cứu phát triển các vấn đề sau: Xây dựng hệ thống tính phí hoàn chỉnh. Tính phí là một ưu điểm lớn của IMS so với các hệ thống khác. IMS cung cấp khả năng tính cước phức tạp hơn nhiều so với hệ thống tài khoản trả trước hay trả sau, ví dụ như việc tính cước theo từng dịch vụ sử dụng hay phân chia cước giữa các nhà cung cấp dịch vụ và nhà cung cấp mạng. Người sử dụng sẽ chỉ nhận một bảng tính cước phí duy nhất từ một nhà cung cấp mạng thường trú. Bảo mật trong IMS: nghiên cứu vấn đề bảo mật trong IMS tránh các nguy cơ tấn công từ internet, tích hợp với đề tài hệ thống phát hiện và phòng chống xâm nhập IDP trên nên tảng mã nguồn mở Mở rộng dịch vụ: Bổ sung thêm các dịch vụ khác như internet di động tốc độ cao, xem video trực tuyến,… Triển khai IMS trên nền IPv6: IPv4 đang dần cạn kiệt. Do đó, khi triển khai IMS trên thực tế, mỗi thiết bị có một IP. Như thế, IPv6 là giải pháp khả thi nhất. IMS trên nền mạng NGN là một công nghệ mạng tiên tiến, có thể định hướng phát triển theo hướng hội tụ mạng di động và cố định trong tương lai. Việc xây dựng phân hệ này giúp cho nhà khai khác sẽ đủ năng lực cung cấp các loại hình dịch vụ đa phương tiện cho người dùng đầu cuối. Với những đặc tính như thế, IMS đang là tiêu điểm nghiên cứu phát triển của nhiểu tổ chức chuẩn hóa viễn thông và công ty điện tử tin học. Với phạm vi của một đề tài tốt nghiệp, bài báo cáo không thể trình bày hết mọi khía cạnh của IMS. Tuy vậy, chúng em hi vọng rằng với những kết quả đạt được trong luận văn sẽ phần nào giúp cho người đọc dễ dàng tiếp cận công nghệ IMS. Chúng em chân thành cảm ơn! TÀI LIỆU THAM KHẢO [1] Miikka Poikselka, George Mayer, Hisham Khartabil and Aki Niemi, “The IMS – IP Multimedia Concepts and Services,” John Wiley & Sons 2nd. [2] Gilles Bertrarfd, “The IP Multimedia subsystem in Next Generation Networks,” newspapers, 2007. [3] Miikka Poikselka, George Mayer, Hisham Khartabil and Aki Niemi, “The IMS – IP Multimedia Concepts and Services in the Mobile Domain,” John Wiley & Sons. [4] Luc De Ghein, “MPLS Fundamentals,” No.1897 [5]Web: Open Source IMS: [6]Web: UCT IMS Client: [7]Web: diễn đàn VNTelecom, chủ đề “IMS – IP Multimedia Subsystem” [8]Web: diễn đàn VNTelecom, chủ đề “Open IMS Core”: [9]Web: diễn đàn Ubuntu Việt Nam: [10]Web: