Các đầu cuối dùng thông tin SRF trong các mô tả phiên để xác định số luồng Resource Reservation cần được thiết lập. Khi mạng truy nhập là GPRS, mỗi luồng dành tài nguyên (Resource Reservation)là một PDP Context (ngữ cảnh PDP, hoặc dạng PDP). Một đầu cuối thiết lập một PDP để trao đổi báo hiệu SIP sau khi thực hiện liên kết GPRS (hình 2-38). Thông tin được mạng lưu về việc PDP này chứa địa chỉ IP của đầu cuối và các đặc tính QoS của PDP chứa loại lưu lượng. Có bốn loại lưu lượng: Best Effort, Interactive, Streaming, và Conversational. PDP dùng cho báo hiệu SIP luôn thuộc loại Conversation.
Luận văn thạc sĩ kỹ thuật 78
Hình 2-38: Sự kích hoạt PDP Context
Các đầu cuối IMS thiết lập thêm các PDP Context để gủi và nhận phương tiện truyền thông (hình 2-39). Số PDP Context được thêm (các PDP Context thứ cấp) tùy thuộc vào các giới thiệu nhận được từ P-CSCF ở các dòng SRF a=group. Các PDP Context thứ cấp dùng cùng địa chỉ IP như PDP Context sơ cấp, nhưng chúng có thể sẽ chứa những đặc tính QoS khác nhau.
Hình 2-39: Kích hoạt PDP context thứ cấp 2.2.4.3 Sự trao quyền bởi Mạng
Các đầu cuối có thẻ trao quyền nhận được từ PDF trong các gói tin Activate Secondary PDP Context Request – yêu cầu PDP Context thứ cấp kích hoạt. SGSN nhận được gói tin này và dùng MAP kiểm tra thông tin thuê bao của user trong HSS. Nếu đầu cuối yêu cầu nhiều băng thông hơn so với thuê bao của user cho phép (thuê bao mà nhà cung cấp cho phép người dùng sử dụng dịch vụ), SGSN sẽ gửi một yêu cầu tạo PDP
Luận văn thạc sĩ kỹ thuật 79
Context đến GGSN. Gói tin này chứa thẻ trao quyền nhận được ở gói tin (1). GGSN nhận được thẻ này ởở gói tin (2) của hình 2-40 và gửi nó đến PDF trong bản tin COPS REQ (3). PDF phản hồi bằng bản tin DEC (4) có chứa các đặc tính QoS và các nhận dạng những luồng gói dùng PDP Context.
Hình 2-40: Mạng trao quyền QoS
GGSN dùng các bộ lọc gói đểđảm bảo rằng chỉ các luồng gói đã trao quyền là được gửi. Các nhận dạng các luồng gói gồm năm Tuple chứa các địa chỉ nguồn đích, các cổng nguồn và đích. Ví dụ, một PDP Context có thể chỉ mang lưu lượng gửi đến địa chỉ IP của UE ở xa. Nếu GGSN không triển khai loại bộ lọc này thì user có thể dùng một PDP Context đã trao quyền bởi PDF cho một mục đích khác.
GGSN sau khi nhận được bản tin DEC (4), nó trả lại một bản tin RTP (5) đến PDF chỉ
ra rằng nó sẽ tuân theo chính sách của PDF. Sau đó, nó sẽ nhận thực PDP Context đã yêu cầu (6).
2.2.4.4 QoS trong mạng
GGSN nhận được lưu lượng từ một đầu cuối trên PDP Context, sẽ phân công nó một DSCP hợp lý và gửi DSCP đó vào mạng theo cấu trúc DiffServ (hình 2-41). DSCP tương ứng với một PDP Context riêng biệt được phân công dựa trên các luật cấu hình tĩnh trong GGSN. Khi RSVP được dùng, GGSN có thể dùng thông tin mang trong báo hiệu RSVP để quyết định DSCP nào sẽđược dùng.
DiffServ Network
GGSN PDP Context
Hình 2-41: Ánh xạ thông tin PDP Context đến các DSCP nhờ GGSN
(*) Đối với RSVP, Các điểm Endpoint hay điểm cuối gửi các bản tin RSVP yêu cầu QoS cho luồng thông tin. Các Router nhận được các gói tin này sẽ lấy được những mô
Luận văn thạc sĩ kỹ thuật 80 tả về luồng thông tin (ví dụ như các địa chỉ truyền tải nguồn và đích – các địa chỉ IP và port của nguồn và đích), và sẽ thực thi chính sách hợp lý đối với các gói tin thuộc luồng đó. Các gói RSVP cần theo cùng đường dẫn mà các gói của luồng thông tin (ví dụ, các gói RTP mang voice)
RSVP gồm hai cơ chế: gói PATH được gửi và gói RESV được nhận (hình 2-42). Khi điểm cuối A gửi các gói RTP chứa voice tới điểm cuối B, thì A sẽ gửi theo đường đó gói PATH. Các gói PATH sẽ được lưu tại các nút mà nó đi qua. Điều này cho phép các gói RESV được định tuyến trở về điểm cuối A theo hướng ngược lại trên lộ trình mà gói PATH đã đi qua (cơ chế tương tự như SIP đã thực hiện đối với mào đầu Via).
Hình 2-42: Cơ chế RSVP
Khi Router nhận được các gói RESV thì QoS sẽđược thực hiện, vì thếđiểm cuối B, nơi nhận các gói RTP sẽđược đáp ứng QoS phù hợp. Router sẽ lưu lại nội dung của RESV trong một khoảng thời gian nào đó, nếu hết hạn mà Router chưa nhận được RESV mới thì thông tin của RESV cũ sẽ bị xóa đi, sẽ giúp ích trong trường hợp điểm cuối thay đổi QoS.
Hạn chế của cấu trúc dùng RSVP là mạng phải lưu trữ nhiều thông tin trạng thái. Các Router cần lưu trữ các thông tin trạng thái về mọi luồng và cần thực hiện kiểm tra lại thông tin đó mỗi khi định tuyến một gói tin nào đó.
Cấu trúc DiffServ khắc phục một số vấn đề đối với cấu trúc RSVP. Các Router DiffServ cần giữ tối thiểu thông tin trạng thái cho phép chúng quyết định cư xửđối với các gói tin nhanh hơn. Cách cư xủ này tùy theo PHBs (Per-Hop Behaviors) được định nghĩa bởi 8 bit mã DSCPs (Differentiated Services Codepoints). Các gói IP mang DSCPs ở mào đầu của nó, ở IPv4 thì DSCP nằm ở mào đầu Type of Service (hình 2- 43), ở IPv6 thì DSCP nằm ở mào đầu Traffic Class (hình 2-44).
Luận văn thạc sĩ kỹ thuật 81
Hình 2-43: Gói IPv4.
Hình 2-44: Gói IPv6.
2.2.5 Nghiên cứu vấn đề quản lý phiên truyền dẫn trong IMS
Một phiên truyền dẫn ởđây được hiểu theo nghĩa của một giao dịch hoàn thiện tức là cả một quá trình từ khi UE bắt đầu tham gia tạo một phiên dịch vụ IMS (sau khi đã
được đăng ký, và trao quyền) đến khi kết thúc phiên dịch vụđó. Vì vậy quản lý phiên truyền dẫn sẽ liên quan đến cả quá trình tạo lập, nắm giữ và giải phóng phiên, nó gồm một loạt các vấn đề từ việc nhận dạng chủ gọi – bị gọi, định tuyến, chọn lựa mã truyền thông, điều khiển phương tiện truyền thông, tính cước, và giải phóng phiên. Để nắm
được thông suốt và cũng để gắn với thực tế, chúng ta sẽ trình bầy những điều này thông qua ví dụ về một phiên hoàn thiện được tạo lập giữa Tobias và Theresa (sau khi họđã đăng ký và được trao quyền - mục 2.2.1 đã đề cập), qua một loạt các bước:
• UE của Tobias tạo yêu cầu INVITE chứa nhận dạng public user (đã đăng ký ở
thủ tục đăng ký) của Theresa
• Tất cả các bản tin SIP cần phải đi qua P-CSCF và S-CSCF của cả hai user
• Tất cả các bản tin SIP được gửi qua IPsec ASs đã được thiết lập giữa UE và P- CSCF
Luận văn thạc sĩ kỹ thuật 82
• UE đồng ý dùng cùng một bộ mã hóa cho luồng truyền thông sẽđược truyền
• Các mạng sẽ trao quyền truyền thông cho phiên, vì thế các user có thể dự chữ
các tài nguyên liên quan
• Cả hai UE thực hiện Resource Reservation (nhưđã giới thiệu ở vấn đề QoS).
• Các thực thể mạng sẽ gửi thông tin tính cước đến hệ thống tính cước.
• UE của Theresa sẽ nhận được tín hiệu chuông, Theresa sẽ chấp nhận phiên, và phiên được thiết lập thành công.
Sau khi kết thúc cuộc gọi, UE của bên đặt máy trước (kết thúc trước) sẽ gửi yêu cầu BYE tới UE khia, và phiên sẽ kết thúc. Hình 2-45 là toàn bộ phiên này.
Luận văn thạc sĩ kỹ thuật 84
Hình 2-45: Phiên truyền dẫn 2.2.5.1 Các nhận dạng chủ gọi vài bị gọi
Sau khi đã được mạng nhận thực, đăng ký và trao quyền, UE sẽ có khả năng được tham gia dịch vụ. UE của Tobias sẽ gửi yêu cầu INVITE chứa nhận dạng public user của Tobias để đảm bảo cho mạng nhận dạng user và thực thi đúng các dịch vụ cho user. Nhận dạng này sẽ nằm ở mào đầu P-Asserted-Identity. Các nhận dạng public user của bị gọi cũng được chỉ định để mạng thực thi đúng các dịch vụ cho bị gọi, sẽ
nằm ở P-Asserted-Identity của phản hồi đầu tiên (trả lời yêu cầu INVITE).
INVITE sip:theresa@home2.hu SIP/2.0
From: “Your Brother” <sip:tobi@brother.com>;tag=veli To: “My beloved Sister” <sip:theresa@sister.com> P-Preferred-Identity: <sip:tobias@home1.fr> Privacy: None
2.2.5.1.1 Sự nhận dạng user chủ gọi
UE chủ gọi gửi yêu cầu chứa mào đầu P-Preffered-Identity, có chứa thông tin nhận dạng public user đã được đăng ký. Đểẩn đi nhận dạng (của Tobias) thì cần đặt Privacy có giá trị “id”. Thực hiện điều này sẽ làm P-CSCF của Theresa xóa bỏ P-Preffered- Identity của Tobias trước khi gửi đến UE của Theresa, vì thế Theresa chỉ nhìn thấy nhận dạng của Tobisa ở mào đầu From.
P-CSCF phía chủ gọi sẽ nhận được yêu cầu INVITE, nó kiểm tra yêu cầu nhận được có qua IPsec SA hay không, nếu không thì P-CSCF sẽ từ chối yêu cầu. Sau đó P- CSCF sẽ chèn P-Assered-Identity ở INVITE thay cho P-Preffered-Identity.
Nếu P-Preffered-Identity chứa URI có là nhận dạng public user đã được đăng ký (bằng cách kiểm tra thông tin trạng thái đăng ký của user) đã được dùng từ trước hay không. Nếu đúng, P-CSCF sẽ thay nội dung của P-Perffered-Identity vào làm nội dung của P-Assered-Identity.
Nếu mào đầu P-Preffered-Identity không chứa nhận dạng public user đã đăng ký hiện thời (nhận dạng đã được đăng ký và vẫn đang dùng kể từ lần tham gia phiên trước đó) thì P-CSCF sẽ xóa mào đầu đó và chèn vào mào đầu P-Assered-Identity có chứa nhận dạng public user mặc định của user
INVITE sip:theresa@home2.hu SIP/2.0
From: “Your Brother” <sip:tobias@brother.com> tag=veli P-Asserted-Identity: <sip:tobias@home1.fr>
Luận văn thạc sĩ kỹ thuật 85
Privacy: None
S-CCSF nhận được yêu cầu INVITE trên, nó sẽ thực hiện kiểm tra trạng thái đăng ký và trao quyền của các nhận dạng public user được chỉ ra ở mào đầu. S-CSCF có thể điền thêm thông tin cho mào đầu P-Asserted-Identity rồi tiếp túc gửi đi. Nếu S-CSCF và mạng của Theresa không cùng nằm trong một miền thì S-CSCF sẽ xóa mào đầu này nếu ở yêu cầu có Privacy là “id”.
INVITE sip:theresa@home2.hu SIP/2.0
From: “Your Brother” <sip:tobi@brother.com>;tag=veli To: “My beloved Sister” <sip:Theresa@sister.com>
P-Asserted-Identity: <sip:tobias@home1.fr>, <tel:+44123456789> Privacy: None
P-CSCF của Theresa phải kiểm tra giá trị của mào đầu Privacy, nếu Privacy có giá trị
“id” thì nó sẽ xóa mào đầu này trước khi gửi bản tin đến UE của Theresa. Nếu UE của Theresa nhận được mào đầu này trong yêu cầu INVITE nó sẽ hiển thị tên thực của người gọi cho Theresa (tên thực của Tobias).
2.2.5.1.2 Sự nhận dạng của user bị gọi
Để ý đến yêu cầu INVITE, thấy request URI: INVITE sip: theresa@home2.hu SIP/2 .0. Dựa vào URI này, S-CSCF của Theresa sẽ kiểm tra sự tồn tại của nhận thực public user này có là nhận dạng hiện tại đã được đăng ký và trao quyền hay không. Nếu hiện tại Theresa không đăng ký bằng nhận dạng này, thì S-CSCF sẽ gửi lại phía chủ gọi bản tin 404 (Not Found) phản hồi cho yêu cầu INVITE và cuộc gọi sẽ bị hỏng. Lúc đó, tùy theo tiêu chuẩn lọc đối với user chưa đăng ký, bản tin INVITE sẽ được gửi forward
đến hộp thư thoại của Theresa.
S-CSCF của Theresa nhận được yêu cầu INVITE, nếu thỏa các điều kiện trên, nó sẽ
thay nhận dạng public user ở request URI cũ bởi địa chỉ liên lạc đã được đăng ký của Theresa, và để vẫn giữa được nhận dạng cũ, S-CSCF sẽ thêm vào mào đầu P-Called- Party-ID.
INVITE sip:[5555::5:6:7:8]:1006 SIP/2.0 P-Called-Party-ID: sip:Theresa@home2.hu
Sau khi nhận được yêu cầu INVITE, UE của Theresa sẽ gửi lại mào đầu P-Preffered- Identity (chứa nhận dạng public user của Theresa) ở phản hồi đầu tiên cho yêu cầu INVITE (gói 183 Session in Progress).
Luận văn thạc sĩ kỹ thuật 86
From: “Your Brother” <sip:tobi@brother.com>;tag=veli
To: “My beloved Sister” <sip:Theresa@sister.com>;tag=schwester P-Preferred-Identity: <sip:Theresa@home2.hu>
Privacy: None
Sau đó tiến trình thực hiện tương tụ như đã đề cập đối với hướng từ Tobias, nhưng theo chiều ngược lại.
2.2.5.2 Định tuyến
2.2.5.2.1 Phân biệt giữa phiên, dialog, các giao dịch và nhánh branch
Thuật ngữ “phiên” mô tả kết nối truyền thông giữa các user (ví dụ Tobias muốn gửi các luồng audio và video đến Theresa). Sự truyền thông này gọi là “bearer level”: các gói RTP được gửi từ hai UE đến GGSN và GGSN sẽ thực hiện truyền các gói này một cách trực tiếp qua mạng. Phiên ở đây được thiết lập dựa trên SIP và báo hiệu SDP (giao thức mô tả phiên) được truyền trên mặt bằng điều khiển “control plane”.
SIP dialog là báo hiệu giữa hai UE cần để thiết lập, điều chỉnh và giải phóng phiên đa phương tiện. Một dialog bắt đầu được thiết lập với yêu cầu INVITE và tồn tại đến hết kết thúc phiên bằng phản hồi 200 (OK) cho yêu cầu BYE. Mọi dialog đều được nhận dạng bằng giá trị chứa ở mào đầu Call-ID và các nhãn tag ở mào đầu To và From của các yêu cầu SIP
From: “Your Brother” <sip:tobi@brother.com>;tag=veli
To: “My beloved Sister” <sip:Theresa@home2.hu>;tag=schwester Call-ID:apb03a0s0s09dkjdfglkj49555
Một giao dịch SIP gồm một yêu cầu SIP và tất cả các phản hồi liên quan đến yêu cầu
đó. Ví dụ để thiết lập phiên, UE của Tobias gửi một yêu cầu INVITE đến UE của Theresa và sẽ nhận được phản hồi 100 (Trying) từ P-CSCF, phản hồi 183 (Session in Progress) và 180 (Ringing) và 200 (OK) từ UE của Theresa. Như vậy có năm bản tin cho giao dịch đó, và cả năm bản tin đêu thuộc một dialog và có cùng số Csep.
From: “Your Brother” <sip:tobi@brother.com>;tag=veli To: “My beloved Sister”
<sip:Theresa@home2.hu>;tag=schwester Call-ID:apb03a0s09dkfglkj49555
Luận văn thạc sĩ kỹ thuật 87
Mọi thực thể như UE và các CSCF dùng tham số Branch dùng để nhận dạng sự tương quan giữa các phản hồi và yêu cầu. Ví dụ P-CSCF sẽ thêm vào tham số này ở mào đầu Via để nhận dạng giao dịch INVITE ở P-CSCF:
INVITE sip:Theresa@home2.hu SIP/2.0
Via: SIP/2.0/UDP pcscf1.visited1.fr;branch=9pctb
2.2.5.2.2 Định tuyến yêu cầu INVITE
UE của Tobias sẽ chèn vào yêu cầu INVITE khởi tạo một số mào đầu liên quan đến
định tuyến:
INVITE sip :theresa@home2.hu SIP/2.0
Via : SIP/2.0/UDP [5555 ::1 :2 :3 :4] :1357 ;branch=8uetb Route : <sip :[5555 ::a :b :c :d] :7531 ;fr>
Route : <sop :orig@scscf1.home1.fr ;lr> Contact : <sip :[5555 ::1 :2 :3 :4] :1357>
Ta biết rằng ở quá trình đăng ký và nhận thực, UE sẽđặt địa chỉ của nó ở mào đầu Via
để nhận được tất cả các đáp ứng của giao dịch đó, UE đặt địa chỉ của nó ở mào đầu Contact để UE đằng xa có thể liên lạc với nhau.
Sau khi đã thiết lập được IPsec SAs, UE của Tobias sẽđặt địa chỉ port đã được bảo vệ
(1357) ở mào đầu Contact, đặt địa chỉ port đã được bảo vệ của nó tại mào đầu Via để
có thể nhận được tất cả các phản hồi qua port được bảo vệ đó. Địa chỉ của port được bảo vệ của P-CSCF (7531) được đặt ở mào đầu Route đầu tiên để P-CSCF có thể nhận
được tất cả các yêu cầu của UE qua cổng bảo kết hợp bảo mật đó. Các mào đầu To và From không được dùng cho mục đích định tuyến mà nó chỉ có mục đích nhận dạng. Khi nhận được yêu cầu, P-CSCF sẽ thực hiện: xóa mào đầu Route thứ nhất liên quan
đến địa chỉ của P-CSCF, kiểm tra xem thông tin định tuyến chứa ở trong yêu cầu có theo đúng như thông tin định tuyến P-CSCF đã lưu trữ trong quá trình đăng ký hay không, đặt thêm địa chỉ của nó ở mào đầu Via trên cùng (sẽ giúp nhận được các gói phản hồi), thêm vào mào đầu Record-Route và đặt địa chỉ của nó vào đó (giúp tất cả
các gói tin đều phải đi qua P-CSCF này), rồi gửi cho S-CSCF của Tobias:
INVITE sip:Theresa@home2.hu SIP/2.0
Via: SIP/2.0/UDP pcscf1.visited1.fr;branch=9pctb Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;branch=8uetb Record-Route: <sip:pcscf1.visites1.fr;lr>
Luận văn thạc sĩ kỹ thuật 88
Route: <sio:org@scscf1.home1.fr.lr> Contact: <sip:[5555::1:2:3:4]:1357>
S-CSCF của Tobias nhận được yêu cầu đó, nó sẽ xóa mào đầu Route liên quan đến địa chỉ của chính S-CSCF đó và thực hiện các thủ tục (*). S-CSCF tiếp tục định tuyến yêu cầu INVITE sang I-CSCF của Theresa (S-CSCF của Tobias dựa vào DNS để tìm địa chỉ của I-CSCF). Nếu S-CSCF biết được khả năng định tuyến của I-CSCF thì nó sẽ
thêm địa chỉ của I-CSCF vào mào đầu Route và thực hiện gửi theo SIP, tuy nhiên vì S-