Ims - IP Multimedia Subsystem

xóa đăng kí từ mặt phẳng điều khiển dịch vụ và thực hiện bất kì các thủ tục điều khiển dịch vụ hợp lí nào. Thông tin này có thể bao gồm cả lí do xóa đăng ký. Bước 2: S-CSCF gởi bản tin Deregister xóa đăng ký về phía P-CSCF và cập nhật cơ sở dữ liệu bên trong của nó để xóa đăng kí UE. Lí do xóa đăng ký cũng được truyền đi nếu có thể Bước 3: P-CSCF sẽ thông báo cho UE lý do xóa đăng ký trừ khi không kết nối được với UE Bước 4: P-CSCF gửi đáp ứng tới S-CSCF và cập nhật cơ sở dữ liệu bên trong của nó để xóa đăng ký của UE. Bước 5: Khi có thể, UE gửi một đáp ứng tới P-CSCF để báo nhận xóa đăng kí. Một UE không có khả năng giao tiếp hoặc nằm ngoài P-CSCF sẽ không thể trả lời cho yêu cầu xóa đăng kí. P-CSCF sẽ thực hiện xóa đăng kí trong bất kì trường hợp Bước 6: Tùy thuộc vào nhà khai thác, S-CSCF có thể gửi là bản tin Cx-put (nhận dạng thuê bao chung, nhận dạng thuê bao riêng, xóa tên S-CSCF) hoặc Cx-Put (nhận dạng thuê bao chung, nhận dạng thuê bao riêng, giữ tên S-CSCF) với thuê bao không đăng kí dài lâu ở S-CSCF. Sau đó HSS sẽ xóa hoặc giữ lại tên của S-CSCF cho thuê bao đó tùy theo yêu cầu. Trong cả hai truờng hợp đó, trạng thái nhận dạng thuê bao được lưu trữ như chưa được đăng kí ở HSS. Nếu như tên của S-CSCF được giữ lại thì HSS sẽ cho phép xóa sự phục vụ của S-CSCF bất cứ lúc nào. Bước 7: HSS sẽ gửi Cx-Put Resp tới S-CSCF để báo nhận sự gửi Cx-Put. Thủ tục thiết lập phiên trong mạng IMS Thủ tục thiết lập phiên giữa 2 mạng IMS Khi một thuê bao IMS (UE#1) cần thiết lập phiên đến một thuê bao IMS khác (UE#2) thì quá trình thiết lập phiên được thực hiện như sau: Hình 111Các bước thực hiện việc xóa đăng ký được thực hiện bởi S-CSCF Bước 1: Sau khi biết được địa chỉ của P-CSCF#1, UE#1 gởi bản tin INVITE đến P-CSCF Bước 2: P-CSCF#1 kiểm tra các thông số truyền thông. Nếu các thông số không phù hợp với chính sách mạng IMS đưa ra, P-CSCF#1 sẽ loại bỏ việc khởi tạo phiên. Bước 3: P-CSCF#1 chuyển tiếp bản tin INVITE đến S-CSCF#1 mà UE#1 đã biết khi đăng ký. Bước 4: S-CSCF#1 có thể truy cập AS để kiểm tra và đáp ứng yêu cầu về dịch vụ cho UE Bước 5: S-CSCF chuyển tiếp bản tin đến I-CSCF#2 Bước 6: I-CSCF#2 truy vấn HSS để tìm địa chỉ của S-CSCF#2 ứng với UE#2 Bước 7: I-CSCF#2 chuyển tiếp bản tin INVITE đến S-CSCF#2 Bước 8: S-CSCF có thể truy cập AS để kiểm tra và đáp ứng các dịch vụ mà bản tin INVITE yêu cầu Bước 9: S-CSCF chuyển bản tin INVITE đến P-CSCF#2 theo địa chỉ đã thiết lập khi UE#2 đăng ký Bước 10: P-CSCF#2 sẽ kiểm tra các thông số trong bản tin INVITE. Nếu những thông số không phù hợp với chính sách đặt ra thì sẽ từ chối thiết lập phiên Bước 11: P-CSCF#2 chuyển bản tin INVITE đến UE#2 Bước 12-17: tín hiệu chuông được chuyển từ UE#2 đến UE#1 Bước 18: thiết lập các thông số dự trữ tài nguyên Bước 19: UE#2 chấp nhận thiết lập phiên bằng cách gởi bản tin 200 OK đến P-CSCF#2 Bước 20: Tùy thuộc vào chính sách của nhà khai thác dịch vụ mà P-CSCF#2 sẽ cho phép tài nguyên cần thiết Bước 21-24: bản tin 200 OK được chuyển về UE#1 Bước 25: Tùy thuộc vào chính sách của nhà khai thác dịch vụ mà P-CSCF#1 sẽ cho phép tài nguyên cần thiết Bước 26: Bản tin 200 OK được gởi từ P-CSCF đến UE#1 Bước 27-31: Bản tin ACK được gởi từ UE#1 đến UE#2 để xác nhận thiết lập phiên Bước 32: Cuộc gọi được thiết lập, luồng thông tin đa phương tiện truyền giữa UE#1 và UE#2 Thủ tục thiết lập cuộc gọi giữa mạng IMS và mạng PSTN Hình 112Mô hình thiết lập cuộc gọi giữa UE (IMS) và UE (PSTN) Các bước thực hiện Hình 113Các bước thiết lập cuộc gọi giữa UE (IMS) và UE (PSTN) Bước 1: UE gởi bản tin INVITE đến P-CSCF để khởi tạo phiên, sau đó P-CSCF dựa vào tên S-CSCF đã được gán cho UE trong bản tin mà sẽ chuyển tiếp bản tin đến S-CSCF tương ứng. Bước 2: S-CSCF thực hiện bất kì một logic điều khiển dịch vụ nào phù hợp để thiết lập phiên Bước 3: S-CSCF thực hiện phân tích địa chỉ đích để xác định được rằng thuê bao đích thuộc PSTN và phải chuyển yêu cầu tới BGCF. Bước 4: BGCF xác định MGCF ở cùng mạng, vì vậy cần phải lựa chọn một MGCF phù hợp. Yêu cầu INVITE được chuyển tới MGCF. Thông tin kết cuối PSTN được chuyển đi sau. Bước 5-7: Các khả năng truyền thông của thuê bao đích được phản hồi theo tuyến báo hiệu như trả lời SDP, như các thủ tục kết cuối PSTN. Bước 8: Người khởi tạo quyết định đưa ra các phương tiện truyền thông và chuyển tiếp thông tin này tới S-CSCF bằng các thủ tục khởi tạo. Bước 9-10: S-CSCF chuyển tiếp SDP đã được đưa ra tới các điểm đầu cuối phía kết cuối như các thủ tục kết cuối PSTN thông qua phiên đã thiết lập. Bước 11-13: Các điểm đầu cuối phía kết cuối trả lời SDP đã đưa ra và bản tin thông báo này được chuyển qua phiên đã thiết lập tới các điểm đầu cuối phía khởi tạo. Bước 14-16: Khi điểm đầu cuối phía khởi tạo hoàn thành thủ tục đặt trước tài nguyên, nó sẽ gửi thông báo đặt trước tài nguyên thành công tới S-CSCF bằng các thủ tục khởi tạo và được chuyển tới điểm đầu cuối phía kết cuối thông qua tuyến phiên. Bước 17-19: Điểm đầu cuối phía kết cuối bao nhận kết quả và thông báo này được chuyển tới điểm đầu cuối phía khởi tạo thông qua tuyến phiên. Bước 20-21: Điểm đầu cuối phía kết cuối phát ra bản tin báo hiệu chuông và chuyển tiếp nó tới BGCF, sau đó BGCF chuyển tiếp bản tin tới S-CSCF. Bước 22: S-CSCF chuyển tiếp bản tin báo hiệu chuông đó tới người khởi tạo bằng các thủ tục khởi tạo. Bước 23: Khi người dùng đích trả lời, các kết quả của thủ tục kết cuối được chứa trong đáp ứng SIP 200 OK tới BGCF. Bước 24-25: BGCF chuyển thông tin này tới S-CSCF và sau đó nó được chuyển tiếp tới điểm đầu cuối phía khởi tạo. Bước 26: Bản tin 200 OK được đáp trả lại điển đầu cuối khởi tạo bằng các thủ tục khởi tạo từ điểm đầu cuối kết cuối. Bước 27: Điểm đầu cuối phía khởi tạo gửi báo nhận cuối cùng tới S-CSCF bằng các thủ tục khởi tạo. Phần VI: Các giao thức sử dụng trong hệ thống IMS SIP Tổng quan về SIP Định nghĩa SIP Theo định nghĩa của IETF, SIP là “giao thức báo hiệu lớp ứng dụng mô tả việc khởi tạo, thay đổi và huỷ các phiên kết nối tương tác đa phương tiện giữa những người sử dụng”. SIP có thể sử dụng cho rất nhiều các dịch vụ khác nhau trong mạng IP như dịch vụ thông điệp, thoại, hội nghị, email, dạy học từ xa, quảng bá, … SIP sử dụng khuôn dạng text, một khuôn dạng thường gặp trong mạng IP. Nó kế thừa các các nguyên lý và khái niệm của các giao thức Internet như HTTP và SMTP. Nó được định nghĩa như một giao thức client-server, trong đó các yêu cầu được phía client đưa ra và các đáp ứng được server trả lời. SIP sử dụng một số kiểu bản tin và các trường header của HTTP, xác định nội dung luồng thông tin theo header. Đặc điểm SIP Đơn giản và có khả năng mở rộng SIP có rất ít bản tin, không có các chức năng thừa nhưng SIP có thể sử dụng đẻ thiết lập những phiên kết nối phức tạp như hội nghị. Đơn giản, gọn nhẹ, dựa trên khuôn dạng text, SIP là giao thức ra đời sau khắc phục được nhược điểm của các giao thức trước đây. Các thực thể proxy server, registrar server, redirect server, location server,… là các thực thể logic, hay đơn giản chúng là các phần mềm có thể chạy trên các máy chủ khác nhau. Do đó hệ thống SIP rất dễ dàng nâng cấp. Hỗ trợ tối đa sự di động của đầu cuối Do có Proxy server, Registrar server và Redirect server, hệ thống luôn nắm được vị trí chính xác của thuê bao. Một người sử dụng có thể đăng nhập vào bất kỳ hệ thống đầu cuối nào (máy tính để bàn, máy tính xách tay, PDA, điện thoại SIP) tại bất kỳ địa điểm nào đều có khả năng hoạt động như nhau. Dễ dàng tạo tính năng mới và dịch vụ mới Là giao thức khởi tạo phiên trong mạng chuyển mạch gói, SIP cho phép tạo ra những tính năng mới hay dịch vụ mới một cách nhanh chóng. CPL và CGI là một số công cụ để thực hiện điều này. SIP hỗ trợ các dịch vụ thoại như call waiting, call forwarding, call blocking, …. SIP là một công cụ hỗ trợ hấp dẫn đối với điện thoại IP SIP có thể hoạt động vô trạng thái hoặc có trạng thái. Vì vậy, sự hoạt động vô trang thái cung cấp sự mở rộng tốt do các server không phải duy trì thông tin về trạng thái cuộc gọi một khi sự giao dịch đã được xử lý. SIP có thể sử dụng nhiều dạng hoặc cú pháp giao thức chuyển siêu văn bản HTTP, vì vậy, nó có thể hoạt động trên các trình duyệt một cách thuận lợi. Bản tin SIP có phần nội dung bản tin thì có thể linh động thay đổi, nó có thể là bất cứ cú pháp nào. Vì vậy, nó có thể được mô tả theo nhiều cách. Chẳng hạn, nó có thể được mô tả với sự mở rộng như Internet đa mục đích MINE hoặc ngôn ngữ đánh dấu mở rộng XML. SIP nhận dạng một người dùng với bộ định vị tài nguyên đồng nhất URL, vì vậy nó cung cấp cho người dùng khả năng khởi tạo cuộc gọi bằng cách nhấp vào một liên kết trên trang web. Chức năng chính User location: xác định hệ thống kết cuối để sử dụng cho việc truyền thông. User availability: xác định trạng thái tính sẵn sàng của thuê bao bị gọi để bắt đầu thiết lập đường truyền. User capabilities: xác định phương tiện và các thông số truyền dẫn được sử dụng. Call setup: thiết lập các thông số của phiên cho cả thuê bao gọi và thuê bao bị gọi. Call handling: tạo, kết thúc, và sửa đổi phiên. Các thành phần chính Một khía cạnh khác biệt của SIP đối với các giao thức xử lý cuộc gọi IP khác là không dùng khái niệm Gateway hay bộ điều khiển Gateway mà dựa vào mô hình server/client. UA UA là một điểm cuối giao tiếp với người dùng và hoạt động đại diện cho người dùng. UA là một ứng dụng chứa cả UAC và UAS. UAC là phần người sử dụng được dùng để khởi tạo một yêu cầu SIP tới server SIP hoặc UAS. UAS là một ứng dụng server giao tiếp với người dùng khi yêu cầu SIP được chấp nhận và trả lại một đáp ứng đại diện cho người dùng. Server Là một chương trình ứng dụng chấp nhận các bản tin yêu cầu từ Client để phục vụ các yêu cầu này và gửi trả các đáp ứng cho các yêu cầu đó. Ta có các loại server sau: Proxy server Là thành phần trung gian, hoạt động như là một server khi nhận các yêu cầu SIP từ Client hoặc với vai trò là một Client khi nó gởi các bản tin yêu cầu thay mặt cho các Client đến các Server kế tiếp trong mạng (có thể là một proxy server khác hoặc là một UAS ). Một proxy có thể dịch bản tin và nếu cần thiết nó có thể tạo lại bản tin yêu cầu SIP trước khi chuyển chúng đến server khác hoặc một UA. Trong trường hợp này trường Via trong bản tin đáp ứng, yêu cầu chỉ ra các proxy trung gian tham gia vào tiến trình xử lý yêu cầu. Proxy server nhận một yêu cầu từ client và quyết định server kế tiếp mà yêu cầu sẽ đi đến. Proxy này có thể gửi yêu cầu đến một server khác, một Redirect server hoặc UAS. Đáp ứng sẽ được truyền cùng đường với yêu cầu nhưng theo chiều ngược lại. Hình 121Proxy Server Ví dụ hoạt động của Proxy server: Hình 122Hoạt động của Proxy Server Hoạt động của Proxy server được trình bày như trong hình. Client SIP userA@yahoo.com gửi bản tin INVITE cho userB@hotmail.com để mời tham gia cuộc gọi. Từng bước được mô tả như sau: Bước 1: userA@yahoo.com gửi bản tin INVITE cho UserB ở miền hotmail.com, bản tin này đến proxy server SIP của miền hotmail.com (Bản tin INVITE có thể đi từ Proxy server SIP của miền yahoo.com và được Proxy này chuyển đến Proxy server của miền hotmail.com). Bước 2: Proxy server của miền hotmail.com sẽ tham khảo server định vị (Location server) để quyết định vị trí hiện tại của UserB. Bước 3: Server định vị trả lại vị trí hiện tại của UserB (giả sử là UserB@hotmail.com). Bước 4: Proxy server gửi bản tin INVITE tới userB@hotmail.com. Proxy server thêm địa chỉ của nó trong một trường của bản tin INVITE. Bước 5: UAS của UserB đáp ứng cho server Proxy với bản tin 200 OK. Bước 6: Proxy server gửi đáp ứng 200 OK trở về userA@yahoo.com. Bước 7: userA@yahoo.com gửi bản tin ACK cho UserB thông qua proxy server. Bước 8: Proxy server chuyển bản tin ACK cho userB@work. Bước 9: Sau khi cả hai bên đồng ý tham gia cuộc gọi, một kênh RTP/RTCP được mở giữa hai điểm đầu cuối để truyền tín hiệu thoại. Bước 10: Sau khi quá trình truyền dẫn hoàn tất, phiên làm việc bị xóa bằng cách sử dụng bản tin BYE và ACK giữa hai điểm đầu cuối. Redirect server Là một server chấp nhận một yêu cầu SIP, ánh xạ địa chỉ trong yêu cầu thành một địa chỉ mới và trả lại địa chỉ này trở về client. Không giống như Proxy server, nó không khởi tạo một yêu cầu SIP và không chuyển các yêu cầu đến các Server khác. Redirect server không chuyển yêu cầu nhưng sẽ chỉ định client tiếp xúc trực tiếp với server kế tiếp, đáp ứng gửi lại client chứa địa chỉ của server kế tiếp. Nó không hoạt động được như là một client, nó không chấp nhận cuộc gọi. Hình 123Redirect Server Hoạt động của Redirect Server Hình 124Hoạt động của Redirect Server Các bước cụ thể được trình bày như sau: Bước 1: Redirect server nhân được yêu cầu INVITE từ người gọi (Yêu cầu này có thể đi từ một proxy server khác). Bước 2: Redirect server truy vấn server định vị địa chỉ của B. Bước 3: Server định vị trả lại địa chỉ của B cho Redirect server. Bước 4: Redirect server trả lại địa chỉ của B đến người gọi A. Nó không phát yêu cầu INVITE như proxy server. Bước 5: User Agent bên A gửi lại bản tin ACK đến Redirect server để xác nhận sự trao đổi thành công. Bước 6: Người gọi A gửi yêu cầu INVITE trực tiếp đến địa chỉ được trả lại bởi Redirect server (đến B). Người bị gọi B đáp ứng với chỉ thị thành công (200 OK), và người gọi đáp trả bản tin ACK xác nhận. Cuộc gọi được thiết lập. Ngoài ra SIP còn có các mô hình hoạt động liên mạng với SS7 (đến PSTN) hoặc là liên mạng với chồng giao thức H.323. Registrar Là một server chấp nhận yêu cầu đăng ký. Một Registrar được xếp đặt với một Proxy hoặc một server gửi lại và có thể đưa ra các dịch vụ định vị. Registrar được dùng để đăng ký các đối tượng SIP trong miền SIP và cập nhật vị trí hiện tại của chúng. Loại server này thường nằm ở gần hoặc nằm trong những loại server khác như là location server. Location server Cung cấp chức năng phân giải tên cho SIP Proxy hoặc Redirect Server. Sever này có thuật toán để phân giải tên. Các cơ chế này bao gồm một database của nhà đăng ký hoặc truy nhập đến những công cụ phân giải tên được sử dụng phổ biến như whois, LDAP, hoặc các hệ thống hoạt động độc lập khác. Registrar server có thể là một thành phần con của location server; registrar server chịu trách nhiệm một phần trong việc populating database mà được liên kết với location server Cấu trúc bản tin SIP Bản tin SIP có ba phần: startline, header, và message body Hình 125Cấu trúc bản tin SIP Start line Startline có 2 loại: Request và Response Start Line Syntax Request Method Request – URI SIP - Version Response SIP-Version Status-Code Response-Phrase Hình 126Cấu trúc phần start line trong bản tin SIP 12.3.1.1 Các trường trong bản tin Request Trường method Bảng 121Trường method trong bản tin SIP Request Trường Method Chức năng INVITE Khởi tạo một phiên (client gởi thông điệp đến Server) ACK Khẳng định rằng client đã nhận được bản tin đáp ứng cho bản tin INVITE OPTIONS Sử dụng để xác định năng lực của server BYE Yêu cầu kết thúc phiên CANCEL Huỷ yêu cầu đang nằm trong hàng đợi REGISTER Đầu cuối SIP đăng ký với Register server SUBSCRIBE The calling party requests an update regarding the presence information of the called party. NOTIFY Đưa ra trạng thái cập nhật những mô tả về thuê bao MESSAGE Sử dụng gởi bản tin tức thời SIP-URI Địa chỉ SIP hay còn được gọi là bộ định vị tài nguyên chung URL, tồn tại dưới dạng user@host. Phần user trong phần địa chỉ có thể là tên người dùng hoặc số điện thoại. Phần host có thể là tên miền hoặc địa chỉ mạng. ví dụ các địa chỉ SIP Bảng 122Bảng ví dụ các SIP URL SIP URL Format sip:user@reskit.com sip:user@reskit.com;transport=TCP sip:user@172.16.20.54 sip:+1-425-707-9796@reskit.com;user=phone sip:marketing@reskit.com;maddr=225.0.2.1;ttl=64 12.3.1.2 Bản tin SIP Respone có các trường Status code (có 6 loại) Bảng 123Trường Status Code trong bản tin SIP Response Status code Response category Ý nghĩa 1xx Informational Thông báo cho biết yêu cầu đang được tiến hành 2xx Success Mã thông báo yêu cầu đã hoàn tất và thành công 3xx Redirection Mã định hướng lại 4xx Client Error Mã thông báo yêu cầu của client bị sai hoặc hệ thống không hoàn tất được 5xx Server Error Mã cho biết yêu cầu hợp lệ nhưng server không thể hoàn tất được 6xx Global Failures Báo hiệu rằng yêu cầu không được thi hành bởi bất cứ server nào Các Response-Phrase tương ứng với các loại status code Bảng 124Các Response-Phrase tương ứng với các loại status code Status Code Response Category Response Phrase Ý nghĩa 100 Informational Trying đang thử 180 Informational Ringing Đang đổ chuông 181 Informational Call is being forwarded Cuộc gọi đang được chuyển hướng 182 Informational Queued Đang xếp hàng đợi 200 Success OK thành công 300 Redirection Multiple choices Có nhiều lựa chọn 301 Redirection Moved permanently Đã dời đi vĩnh viễn 302 Redirection Moved temporarily Đã tạm thời dời đi 303 Redirection See other xem phần khác 305 Redirection Use proxy Dùng Proxy 380 Redirection Alternative service Dịch vụ thay thế 400 Client Error Bad request Yêu cầu sai 401 Client Error Unauthorized Không được quyền 402 Client Error Payment required Yêu cầu trả tiền 403 Client Error Forbidden Cấm 404 Client Error Not found Không tìm thấy 405 Client Error Method not allowed Phương thức không được phép 406 Client Error Not acceptable Không được chấp nhận 407 Client Error Proxy authentication required Cần có sự cấp phép cho proxy 408 Client Error Request timeout Yêu cầu bị hết giờ 409 Client Error Conflict Xung đột 410 Client Error Gone Người dùng đã từng tồn tại, nhưng không còn ở đây nữa 411 Client Error Length required 413 Client Error Request entity too large Đơn vị yêu cầu quá lớn 414 Client Error Request-URI too large URI của yêu cầu quá dài 415 Client Error Unsupported media type Kiểu phương tiện không được hỗ trợ 420 Client Error Bad extension Phần mở rộng không đúng 480 Client Error Temporarily not available Tạm thời không hoạt động 481 Client Error Call leg/transaction does not exist Cuộc gọi/Giao dịch không tồn tại 482 Client Error Loop detected Phát hiện thấy lặp 483 Client Error Too many hops Quá nhiều chặng trung chuyển 484 Client Error Address incomplete Địa chỉ không hoàn chỉnh 485 Client Error Ambiguous Tối nghĩa 486 Client Error Busy here Đang bận 500 Server Error Internal server error Lỗi bên trong máy chủ 501 Server Error Not implemented Phương thức yêu cầu SIP này chưa được khai báo ở đây 502 Server Error Bad gateway Gateway sai 503 Server Error Service unavailable Dịch vụ không có 504 Server Error Gateway time-out Máy chủ bị hết giờ 505 Server Error SIP version not supported Phiên bản không được hỗ trợ: máy chủ không hỗ trợ phiên bản giao thức SIP này 600 Global Failures Busy everywhere Tất cả mọi nơi đều bận 603 Global Failures Decline Từ chối 604 Global Failures Does not exist anywhere Không tồn tại ở bất cứ đâu 606 Global Failures Not acceptable Không được chấp nhận Header SIP có 4 loại header: general header, entity header, request header, và respone header. 2 loại đầu xuất hiện trong cả 2 loại bản tin, 2 cái sau xuất hiện trong loại bản tin là request hoặc response. Một start line cho phép đi kèm với một hoặc nhiều header. Tùy theo bản tin là request hay response mà ta dùng header cho phù hợp. Bảng 125 Các Header trong bản tin SIP General Entity Request Response Accept Content-encoding Authorization Allow Accept-encoding Content-length Contact Proxy-authenticate Accept-language Content-type Hide Retry-after Call-ID Max-forwards Server Contact Organization Unsupported Cseq Priority Warning Date Proxy-authorization WWW-authenticate Encryption Proxy-require Expires Route From Require Record-route Response-key Time stamp Subject To User-agent Via Message Body SIP message body: Phần thân (body) của bản tin SIP chứa những mô tả phiên giống như phần mô tả trong SDP. Một mô tả phiên gồm có 3 phần: mô tả phiên (a single session description), mô tả thời gian (zero or more time descriptions), and mô tả về truyển dẫn (zero or more media descriptions) Hình 127Cấu trúc phần thân bản tin SIP Session (phiên) Bảng 126 Trường mô tả phiên trong phần thân của bản tin SIP Type Value v Protocol version o Owner/creator and session identifier s Session name i Session information u Uniform Resource Identifier (URI) of description e E-mail address p Phone number c Connection information b Bandwidth information z Time zone adjustments a Zero or more session attribute lines Time (thời gian) Bảng 127 Trường thời gian trong phần thân của bản tin SIP Type Value t Time the session is active r Zero or more repeat times Media (truyền dẫn) Bảng 128 Trường truyền dẫn trong phần thân bản tin SIP Type Value m Media name and transport address i Media title c Connection information b Bandwidth information k Encryption key a Zero or more media attribute lines Ví dụ bản tin SIP Bản tin yêu cầu (request) Hình 128Bản tin SIP Request Bản tin đáp ứng (response) Hình 129Bản tin SIP Response DIAMETER Tổng quan về 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 (LDAP). 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. 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 Base Protocol sử dụng cả Transmission Control Protocol (TCP) [RFC0793] và Stream Control Transmission Protocol (SCTP)[RFC2960] để truyền dữ liệu. Tuy nhiên SCTP thường được sử dụng hơn trong các kết nối có định hướng giữa các thành phần Diameter. SCTP cũng là một giao thức dựa trên nền IP không khác nhiều so với TCP. SCTP được phát triển sau và có cấu trúc phức tạp hơn TCP. SCTP được thiết kế để sử dụng trong điều kiện yêu cầu độ tin cậy và gần thời gian thực. Tuy nhiên, tại thời điểm hiện tại, SCTP chưa được sử dụng rộng rãi trong mạng truyền tải của các mạng. Diameter sử dụng Internet Protocol Security (IPSec) [RFC2401] và Transport Layer Security (TLS) [RFC2246] để bảo mật kết nối. Các thành phần chính Diameter là giao thức ngang hàng peer-to-peer, tại bất kỳ một thành phần nào cũng có thể thiết lập một yêu cầu. 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. Thông tin tên miền được chứa trong bản tin UE gởi đến và là trường đầu tiên UE sử dụng để tìm kiếm một entry. Mã ứng dụng ứng trường vendor ID trong bản tin Diameter. Mã này được định nghĩa bởi IANA, mỗi ứng dụng có một ID khác nhau. Ví dụ: 0 bản tin Diameter 1 NASREQ 2 Mobile-IP 3 Chức năng tài khoả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. They are similar to relay agents in that message routing is based on a Diameter routing table, but different in that they also modify the messages by implementing policy enforcement (e.g., resource usage enforcement, admission control or provisioning). Since policy enforcement always requires an understanding of the offered service, proxy agents need to support specific Diameter applications as well as the Diameter Base Protocol. Hình 131 Diameter Proxy Agent định tuyến các bản tin dựa vào bảng định tuyến Diameter Redirect Agent Hình 132 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 Hình 133 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, …. Cấu trúc bản tin Diameter 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 134Cấu trúc bản tin Diameter Cấu trúc header của Diameter được mô tả trong hình sau: Hình 135Cấu trúc header của Diameter Version: được thiết lập bằng 1 ứng với phiên bản hiện nay của giao thức Diameter là 1. Command Flags: trường này dài 8 bit. Có dạng RPETrrrr, có ý nghĩa như sau: R (request): nếu bằng 1, đây là bản tin yêu cầu. Nếu bằng 0 là bản tin đáp ứng. P (proxiable): nếu bằng 1, bản tin có thể chuyển tiếp bởi Proxy, Relay hoặc Redirect. Nếu bằng 0 thì bản tin sẽ được xử lý tại nút E (error): Nếu bằng 1, bản tin đáp ứng chứa lỗi giao thức, và bản tin sẽ không phù hợp với mô tả ABNF. Nếu bằng 0 trong bản tin yêu cầu và không lỗi. T (potentially re-transmitted masage): Bit này bằng 1 khi liên kết bị đứt, bản tin yêu cầu bị trùng hoặc không có trả lời từ Server r: dự trữ, luôn bằng 0 Command Code: trường này dài 24 bit, được quản lý bởi IANA, giá trị từ 0- 24 dùng riêng cho RADIUS, 16777214 và16777215 dùng thí nghiệm, các số còn lại dùng trong giao thứcDIAMETER. Một số Command Code được liệt kê trong bảng sau: Bảng 131 Command Code trong Diameter Application-ID: dài 32 bit, dùng để xác định tên ứng dụng do IANA quản lý. Ứng dụng có thể là một ứng dụng dành cho việc chứng thực, một ứng dụng quản lý tài khoản người dùng hoặc một ứng dụng cụ thể của một nhà sản xuất nào đó. Nó là một dáy số từ 0x00000001 đến 0x00ffffff. Sau đây là một số Application-ID: Bản tin Diameter chung 0 NASREQ 1 Mobile-IP 2 Chức năng Accounting trong Diameter 3 Relay 255 Application ID trong header phải giống với nội dung chứa trong AVP. Hop-by-Hop Identifier: dài 32 bit, giúp phù hợp giữa bản tin yêu cầu và đáp ứng trong 1 kết nối trong 1 thời gian End-to-end Identifier: xác định bản tin bị trùng AVP 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. Hình 136 Cấu trúc AVP 14.3.2.1 AVP header Trường AVP Code: dài 32 bit, được quản lý bởi IANA, dùng để xác nhận các thuộc tính với trường Vendor-ID. Giá trị từ 0-255 dùng để tương thích vói RADIUS, các giá trị còn lại dùng trong DIAMETER Trường AVP Flag dài 8 bit, có dạng VMPrrrrr, mỗi bit có ý nghĩa như sau: Bit V (vendor -ID): nếu bằng một thì thông tin sẽ được đề cập trong trường Vendor-ID, ngược lại trường Vendor-ID rỗng. Bit M (Mandatory): UE sẽ không nhận bản tin này nếu bit này bằng 0. Bit P (Protect): nếu bằng 1 thì bản tin được yêu cầu mã hóa end-to-end. Bit r: dự trữ Trường AVP length: chiều dài AVP data. 14.3.2.2 AVP data 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. Ngoài việc sử dụng các dạng dữ liệu cơ bản, trường này còn có thể sử dụng các định dạng dữ liệu khác nhau theo ứng dụng. Có một số dạng dữ liệu theo ứng dụng như sau: Address: dạng dữ liệu này được tạo ra từ dạng OctetString ( dạng dữ liệu cơ bản). Nó có thể là dạng địa chỉ 32 bit (Ipv4) hoặc 128 bit (IPv6). Time: dạng dữ liệu này được tạo ra từ OctetString. Chuỗi (string) phải dài bốn octet. Dạng dữ liệu này giống định dạng của SNTP [RFC 2030] Diameter Identity: dạng dữ liệu này được tạo ra từ OctetString, dùng để xác định sự duy nhất của một nút trong mạng, tránh trường hợp có nhiều đường kết nối đến một nút dẫn đến trình trạng bị lặp trong định tuyến. Nội dung chuỗi dữ liệu trong kiểu này là FQDN của một nút Diameter. Ngoài ra còn có các dạng dữ liệu khác như: UTF8String, DiameterURI, Enumerated, IPFilterRule, QoSFilterRule, … [RFC 3588] Bảo mật trong bản tin Diameter Client trong giao thức Diameter phải hổ trợ chuẩn IPSec và có thể hổ trợ TLS. Server phải hổ trợ cả 2 chuẩn trên. Để bảo mật, khuyến nghị rằng nên sử dụng IPSec ở các nút trong cùng một miền như giữa Client và Proxy và sử dụng TSL để bảo mật khi có giao dịch giữa các miền với nhau. Khi sử dụng TSL, hai phía phải thương lượng một Cipher key theo một trong các thuật toán sau: RC4_128_MD5 RC4_128_SHA 3DES_EDE_CBC_SHA AES_128_CBC_SHA Kiểm soát lỗi 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 137 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 138 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 132 Bản tin đáp ứng trong trường hợp có lỗi xảy ra Kết nối và phiên trong Diameter Hình 139 Luồng lưu lượng kết nối các thực thể Diameter Quá trình thiết lập đến kết thúc một giao dịch trong Diameter thực hiện qua các bước sau: Bước 1: Client gởi bản tin Capabilities-Exchange-Request (CER) để yêu cầu thiết lập kết nối bằng cách sử dụng giao thức truyền TCP hoặc SCTP. Bước 2: Server đáp ứng lại bởi bản tin Capabilities-Exchange-Answer (CEA). Trong quá trình, giao thức bảo mật (IPSec hoặ TSL) được thương lượng chọn lựa Bước 3: Kết nối sẵn sàng cho việc truyền thông bản tin giữa Client và Server. Bước 4, 5: Nếu không có bản tin nào được gởi thì đến một khoảng thời gian, Client sẽ gởi DWR và chờ đáp ứng DWA. Bước 6, 7: Hủy kết nối có thể được một trong hai bên thực hiện bằng cách gởi DPR và nhận về đáp ứng DPA. Dịch vụ trong Diameter DIAMETER là giao thức độc lập, không thiết kế để hoạt động trên một ứng dụng cụ thể nào. Tùy thuộc vào ứng dụng mà các bản tin và dịch vụ có ít nhiều thay đổi. Tuy vậy, Diameter có ba dịch vụ chính là: chứng thực, ủy quyền và tài khoản. Chứng thực và ủy quyền là hai dịch vụ kết hợp với nhau trong giao thức Diameter. Client là phía khởi tạo yêu cầu hai dịch vụ trên, phụ thuộc vào nội dung yêu cầu trong AVP mà Server sẽ đáp ứng theo những cách khác nhau. Hai dịch vụ này cung cấp chế độ bảo mật và thông số cho quá trình bảo mật thông tin chứng thực. Client và Server sử dụng hai dịch vụ trên để hiểu đuợc các thông tin đã đươc mã hoá của nhau như mật khẩu chẳng hạn. Chứng thực và ủy quyền cũng giúp Client phát hiện sự giả mạo của gói tin đáp ứng. Thêm vào đó, nó được sử dụng để chuyển mật khẩu thành một dạng nào đó, ngăn chặn việc làm lộ mật khẩu của người dùng trong các bản tin Diameter. Những dịch vụ này còn tạo ra thông số ngẫu nhiên gởi đến Client. Client dùng thông số chứng thực của minh( mật khẩu, khóa nhận dạng riêng) băm với số này qua thuật toán MD5. Sau đó gởi gói tin chứa kết quả sau khi băm tới Server để so sánh hai kết quả sau khi băm. Chứng thực thì chỉ có thành công hoặc thất bại, trong khi đó dịch vụ ủy quyền còn dựa vào trạng thái dịch vụ là Statefull hoặc Stateless. Với trạng thái Statefull thì Server sẽ giữ lại trạng thái của phiên và có sự giới hạn về thời gian của phiên ủy quyền. Thời gian này không được vượt quá thời gian phiên ủy quyền và thời gian mở rộng thêm. Khi hết thời gian này, hoặc Client, hoặc Server sẽ hủy kết nối và bắt buộc Client phải nhận sự ủy quyền lại. Ngược lại, trong trạng thái Stateless, Server chỉ duy trì trạng thái dịch vụ mà không duy trì trạng thái phiên. Diameter Base Protocol cung cấp dịch vụ tài khoản đến Diameter Application. Khi một Accouting Session chưa được kích hoạt, sẽ không có nguồn tài nguyên nào được dự trữ sẵn cho cả Client và Server. Khi một bản tin Accounting Request kích hoạt Accouting Session thành công, một Accounting Record rơi vào một trong 2 danh sách: Dịch vụ tính theo thời gian: có thời gian bắt đầu và kết thúc rõ ràng. Đối với dịch vụ này, cước phí được tính khi dịch vụ bắt đầu và ngưng tính khi dịch vụ kết thúc. Dịch vụ tính theo lần: tính phí theo số lần sử dụng dịch vụ, không quan tâm đến thời gian. So sánh giao thức Diameter và giao thức RADIUS Bảng 133 So sánh giao thức Diameter và giao thức RADIUS COPS Giới thiệu về 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 giữa server quyết định chính sách và Client của nó. 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 (events) ở 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. Hình 141Mô hình cops 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 giá trị 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/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 Hình 142COPS giữa PDF và GGSN/SBC Chức năng chính của COPS Giao thức này giao việc cho Client hỗ trợ cho mô hình Client/Server. Trong đó Client sẽ gởi những bản tin: yêu cầu, cập nhật, và xóa tới PDP và PDP gởi trả những quyết định cho PEP. COPS sử dụng phương thức TCP để trao đổi bản tin giữa Server và Client nên ta không cần bổ sung thêm chức năng hỗ trợ việc liên lạc có đảm bảo giữa Server và Clients. COPS thực hiện việc quản lý, cấu hình, và thực thi các chính sách COPS cung cấp mức độ bảo mật các bản tin cho việc xác thực, phát lại bảo vệ, 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. COPS cho phép Server áp dụng chính sách cho Client hoặc xóa chính sách đang thực thi trên Client nếu nó không còn được sử dụng nữa. Bản tin COPS Bản tin COPS gồm có một header và các thực thể theo sau. Hình 143Cấu trúc bản tin COPS COPS header Hình 144COPS 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 141 Các loại Op code trong COPS header Giá trị Loại Nơi chốn (where) 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à determines the interpretation of the accompanying typed objects 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 145Object format của bản tin COPS Length (16bits) C-num (8 bits): cho biết lớp thông tin chứa đựng trong object Bảng 142 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 C-type (8 bits): có giá trị được đặt dựa trên C-num, typically identifies the subtype or version of the information contained in the object. MEGACO/H.248 Tổng quan về 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. Hình 151Quá trình chuẩn hóa MEGACO/H248 MEGACO/H248 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 packets. Megaco/H.248 là giao thức báo hiệu giữa Softswitch/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/H248 hỗ trợ đa dạng hơn các loại mạng (ví dụ ATM). Hình 152 MEGACO/H248 kết nối điều khiển Gateway Cấu trúc Gateway trong MEGACO/H.248 Hình 153Cấu trúc Gateway trong MEGACO/H248 MGC (Media Gateway Control): 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 (Media Gateway): 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 (Signalling Gateway): 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 Termination ngắn hạn được tạo bởi lệnh Add và được hủy bỏ bởi lệnh Subtract. Ngược lại, một Termination vật lý được thêm vào và bỏ ra khỏi một Context bằng cách chúng được lấy ra hoặc đưa vào một Context rỗng tương ứ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. Lệnh Add dùng để thêm Termination vào Context. Nếu MGC không chỉ định một Context tồn tại để Termination được thêm vào thì MG sẽ tạo một Context mới. Lệnh Subtract dùng để xóa bỏ Termination ra khỏi một Context. Termination cũng có thể được di chuyển từ Context này sang một Context khác với lệnh Move. Một Termination chỉ tồn tại trong một Context ở một thời điểm. 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. MEGACO có thể được dùng để tạo Context và sửa đổi các giá trị tham số của Context đang tồn tại. MEGACO có các lệnh để thêm Termination vào Context, bỏ Termination ra khỏi Context và di chuyển Termination giữa các Context. Context bị xóa hoàn toàn khi Termianation còn lại sau cùng bị xóa bỏ hoặc di chuyển khỏi context. Các thuộc tính của Context: ContextID: giá trị duy nhất trong mỗi MG Topology: mô tả các luồng truyền thông giữa các Termination và ngõ vào ra của MG Priority: độ ưu tiên, ưu tiên cho lưu lượng trong MG khi có nhiều Context phải được điều khiển đồng thời Gọi khẩn cấp: cung cấp khả năng điều khiển ưu tiên cho cuộc gọi khẩn cấp Một số lệnh trong MEGACO/H.248 Bảng 151 Một số lệnh trong giao thức MEGACO Hoạt động của MEGACO/H.248 Hình 154Luồng giao thức của MEGACO/H248 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 2 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 2 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ừ 2 Gateway thì kết thúc hoàn toàn một phiên gọi. Phần VII: Tổng kết Với nội dung đưa ra là tìm hiểu kiến trúc IMS trên nền mạng NGN, bài tìm hiểu này đã đư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ài viết 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 tìm hiều còn trình bày các giao thức truyền thông sử dụng trong phận hệ này, đặc biệt là giao thức SIP. Đây là giao thức được 3GPP chọn là giao thức báo hiệu chính trong mạng lõi IMS. IMS là một đề tài đang được sự quan tâm tìm hiểu của các tổ chức chuẩn hóa viễn thông và các công ty điện tử tin học. Phân hệ IMS sẽ là một xu hướng phát triển tất yếu của nền viễn thông trong nước nói riêng và trên thế giới nói chung. Xây dựng thành công hệ thống này sẽ mang lại lợi ích lớn cho cả nhà khai thác mạng và người dùng. Trong phạm vi bài tìm hiểu này, chúng tôi chỉ đưa ra cái nhìn tổng quát nhất về phương thức hoạt động của IMS trên nền mạng NGN. Chúng tôi sẽ tiếp tục phát triển bài tìm hiểu này thành một đề tài hoàn chỉnh kèm theo sản phẩm là một mô hình lab có tính ứng dụng cao. Tài liệu tham khảo 1. The IMS: IP Multimedia Concepts and Services, Second Edition Miikka Poikselkä, Georg Mayer Hisham Khartabil and Aki Niemi © 2006 John Wiley & Sons 2. 3GPP TS 23.228 v9.0.0 (06/2009): “IP Multimedia Subsystem” 3. 3GPP TS 23.002 V9.1.0 (2009-09): “Network Architecture” 4. Performance of Signalling Compression in the Third Generation Mobile Network, Jouni Mäenpää, 7.6.2005 5. IMS over NGN, Nguyễn Văn Quân, D2001VT 6. RFC 3261: "SIP: Session Initiation Protocol" 7. 3GPP TS 29. 229: "Cx and Dx Interfaces based on the Diameter protocol, Protocol details". 8. IMS AAA Server Administration Guide, Juniper Networks SRC-AAA Engine, Release 1.0, December 2007 9. Tích hợp mạng di động và cố định theo hướng NGN, Trần Trung Hiếu 10. 3GPP TS 29. 228: "IP Multimedia (IM) Subsystem Cx and Dx Interfaces, Signalling flows and message contents" 11. RFC 2543: SIP: Session Initial Protocol 12. RFC 3588: Diameter Base Protocol 13. UMTS Networks Architecture, Mobility and Services, Second Edition, Heikki Kaaranen Oy Aqua Records Ltd, Finland, Ari Ahtiainen Nokia Research Center, Finland, Lauri Laitinen Nokia Research Center, Finland, Siama ¨k Naghian Nokia Networks, Finland, Valtteri Niemi Nokia Research Center, Finland, John Wiley & Sons Ltd 14. Giao thức H.248, Trung tâm Ứng dụng công nghệ mới - Viện KHKT Bưu điện 15. int/ net/home/index.aspx 16. 17. 18. 19. 20.