Luận văn thạc sĩ kỹ thuật 104
P-CSCF Theresa sẽ gửi cho UE Theresa thông tin liên quan đến nhóm các dòng media trong SDP offer thứ hai ở yêu cầu PRACK:
v=0 o=- 1357924 1357924 IN IP6 5555::1:2:3:4 s=- c=IN IP6 5555::1:2:3:4 t=907165275 0 a=group:SRF 1 m=audio 3458 RTP/AVP 97 98 a=mid: 1 a=rtpmap:97 AMR-WB a=rtpmap:98 telephone-event m=video 3400 RTP/AVP 99 a=mid: 1 a=rtpmap:99 H.261 m=video 0 RTP/AVP 98
Dòng a=group:SRF 1 chỉ ra rằng tất cả các luồng media trong nhóm này sẽ được chuyển bằng một PDP context (SRF – Single Reservation Flow).
Dòng a=mid:1 cho phép P-CSCF chỉ dẫn các UE thực hiện nhóm các luồng truyền thông vào một PDP context.
2.2.5.6.3 Chia luồng
P-CSCF thấy nó cần chia luồng, vì thế nó thêm mào đầu liên quan đến thông tin nhóm dòng media vào SDP answer ở phản hồi 200 (OK) và gửi lại UE Tobias:
v=0 o=- 1357924 1357924 IN IP6 5555::5:6:7:8 s=- c=IN IP6 5555::5:6:7:8 t=907165275 0 a=group:SRF 1 a=group:SRF 2
Luận văn thạc sĩ kỹ thuật 105 m=audio 4011 RTP/AVP 97 98 a=mid: 2 a=rtpmap:99 H.261 m=video 0 RTP/AVP 98 2.2.5.6.4 Chính sách truyền thông
Nếu mạng không hỗ trợ loại phương tiện truyền thông hoặc mã mà UE yêu cầu ở PDP thì P-CSCF hoặc S-CSCF được quyền từ chối phiên.
Nếu S-CSCF phát hiện ra có một loại media không được mạng hỗ trợ hoặc có một mã không được mạng hỗ trợ nằm trong SPD offer, thì S-CSCF sẽ từ chối yêu cầu bằng gửi lại phản hồi 488 (Not Acceptable Here) (ta biết rằng các loại mã này hoặc các loại media này đã được thỏa thuận giữa hai UE nhưng đến đây nó cần phải thỏa mãn cả
mạng IMS nữa). Khi ấy UE cần gửi một SDP khác có chứa các tham số hợp lý.
2.2.5.7 Sự trao đổi thông tin liên quan đến tính cước cho phiên
Kể từ khi dữ liệu lưu lượng truyền thông được truyền qua PDP context, GGSN sẽ thực hiện đo đạt tính cước lượng dữ liệu truyền qua PDP context. Những bản tin tính cước
được GGSN ghi dựa theo GPRS Charing ID (GCID) được tạo bởi mạng truy nhập. GGSM sẽ gửi các GCID qua điểm tham chiếu Go để tới P-CSCF. P-CSCF sẽ tính cước các luồng media đã được truyền trên các media PDP context đã thiết lập, P- CSCF sẽ tạo IMS Charing ID (ICID) dựa vào GCID (có thể hình dung rằng GCID tính cước lưu lượng còn ICID tính cước tổng dựa vào từng loại lưu lượng cho audio hay video thì cước sẽ khác nhau). Sau đó P-CSCF gửi ICID về CCF mạng thường trú của user (P-CSCF tải vềđịa chỉ của CCF từ S-CSCF nhờ mào đầu P-Charing-Address, S- CSCF có được địa chỉ của CCF từ HSS nhờ thông tin của gói Diameter SAA khi user thực hiện đăng ký).
Luận văn thạc sĩ kỹ thuật 106
pc1:8642 ps1:7531 pc1:2622 ps1:1511
Luận văn thạc sĩ kỹ thuật 107 2.2.5.7.1 ICID – IMS Charing ID
Khi P-CSCF Tobias nhận được yêu cầu INVITE, nó sẽ tạo một ICID mới và đặt nó trong mào đầu P-Charing-Vector của yêu cầu INVITE:
INVITE sip:Theresa@home2.hu SIP/2.0 P-Charging-Vector: icid-value=
“AyretyUodm+602IrT5tAFrbHLso=023551025”
S-CSCF Tobias nhận được yêu cầu INVITE, nó sẽ thêm vào nhận dạng interoperator gốc (IOI – Origination Interoperation Identifer) vào mào đầu P-Charing-Vector:
INVITE sip:theresa@home2.hu SIP/2.0 P-Charging-Vector: icid-value=
“AyretyU0dm+602IrT5tAFrbHLso=023551025” ;orig-ioi=home1.fr
S-CSCF mạng thường trú của Theresa sẽ lưu lại IOI này và xóa nó khỏi yêu cầu INVITE. Đến P-CSCF Theresa, mào đầu P-Charing-Vector sẽ bị xóa đi. Tất cả các thực thể liên quan đến tính cước sẽ lưu giữ ICID.
Khi nhận được phản hồi 183 cho yêu cầu INVITE từ phía UE của Theresa, P-CSCF Theresa sẽ thêm vào mào đầu P-Charing-Vector. Khi S-CSCF của There nhận được phản hồi đó, nó sẽ thêm vào thông tin IOI của kết cuối:
SIP/2.0 183 Session in Progress P-Charging-Vector: icid-value=
“AyretyU0dm+602IrT5tAFrbHLso=023551025” ;term-ioi=home2.hu
Tiếp theo cũng sẽ tương tự như với yêu cầu INVITE.
2.2.5.7.2 Sự tương quan giữa GCID và ICID
Nhưđã biết, sau khi Resource Reservation thành công, UE Tobias sẽ gửi yêu cầu UPDATE cho UE Theresa có chứa mào đầu P-Charing-Vector có các thông tin:
ICID
Các tham số tính cước như: GCID, địa chỉ của GGSN, pdp-sig chỉ ra PDP context đó có là signalling hay không, nhận dạng luồng truyền thông, thẻ trao quyền.
Luận văn thạc sĩ kỹ thuật 108
UPDATE sip:[5555::5:6:7:8]:1006 SIP/2.0 P-Charging-Vector:icid-value= “AyretyU0dm+602IrT5tAFrbHLso=023551024” ;ggsn=[5555::4b4:3c3:2d2:1e1]; ; pdp-sig=no;gcid=723084271 ;auth-token=example-auth-token1 ;flow-id=1 ;ggsn=[5555::4b4:3c3:2d2:1e1] ;pdp-sig=no;gcid=723084372 ;auth-token=example-auth-token1 ;flow-id=2
Chú ý là có hai PDP context được dùng cho việc truyền các luồng media nên có hai gcid trong yêu cầu trên.
S-CSCF Tobias nhận được yêu cầu đó, nó lưu lại và xóa tất cả các mào đầu liên quan
đến tính cước ở yêu cầu trên, rồi thêm vào các tham số IOI trước khi gửi nó đến S- CSCF của Theresa:
UPDATE sip:[5555::5:6:7:8]:1006 SIP/2.0 P-Charging-Vector: icid-value=
“AyretyU0dm+602IrT5tAFrbHLso=023551024” ;orig-ioi=home1.fr
;term-ioi=home2.hu
S-CSCF của Theresa nhận được yêu cầu đó, nó lưu lại và xóa các IOI trong yêu cầu
đó, rồi gửi tới P-CSCF của Theresa.
Trong ví dụ này, UE Theresa đã thực hiện được Resource Reservation nên sau khi nó nhận được yêu cầu UPDATE, UE Theresa sẽ gửi lại phản hồi 200 (OK) có chứa P- Charing-Vector:
SIP/2.0 200 OK
P-Charing-Vector: icid-value=
“AyretyU0dm+602IrT5tAFrbHLso=023551024” ;ggsn=[5555::802:53:58:6]
Luận văn thạc sĩ kỹ thuật 109
;pdp-sig=no ;gcid=306908949
;auth-token=example-auth-token2 ;flow-id=2
Quá trình tiếp tục tương tự: S-CSCF Theresa nhận được phản hồi đó, nó sẽ lưu lại các thông tin của mào đầu P-Charing-Vector, đồng thời xóa các thông tin liên quan đến gcid và các tham số khác liên quan đến tính cước trừ icid, thêm vào các ioi rồi gửi phản hồi đó đi. S-CSCF Tobias nhận được phản hồi đó, nó sẽ lưu lại và xóa ioi khỏi phản hồi, thêm các thông tin vào P-Charing-Vector rồi gửi tới P-CSCF Tobias nằm ở
mạng tạm trú. Cuối cùng P-CSCF Tobias nhận được phản hồi đó, nó sẽ lưu lại các thông tin của mào đầu P-Charing-Vector rồi xóa nó khỏi phản hồi trước khi gửi cho UE Tobias.
Chú ý đối với yêu cầu INVITE, khi S-CSCF nhận được nó, S-CSCF sẽ truy vấn chuẩn bộ lọc để tìm được AS phục vụ user và gửi yêu cầu INVITE đến AS đó nhưđã đề cập. Sở dĩ phải truy vấn AS vì AS chứa cơ sở dữ liệu phục vụ dịch vụ - tiếng chuông chẳng hạn. Nếu yêu cầu INVITE này được thiết lập khi Resource Reservation đã đạt được – vì yêu cầu này được thiết lập ở giao dịch thứ hai chẳng hạn – khi user muốn thêm một dịch vụ nữa vào phiên. Nếu vậy thì các thủ tục đối với thông tin cước đều được thực hiện như trên.
2.2.5.7.3 Ví dụ một số trường hợp Đối với tính cước offline
Luận văn thạc sĩ kỹ thuật 110
Hình 2-51: UE nằm ở mạng tạm trú thiết lập phiên.
Luận văn thạc sĩ kỹ thuật 111
Hình 2-52: UE nằm ở mạng thường trú thiết lập phiên 2.2.5.8 Giải phóng phiên
Giả sử Theresa là người muốn kết thúc phiên, cô ấy thực hiện bấm nút kết thúc cuộc gọi, UE Theresa sẽ gửi yêu cầu BYE:
BYE sip:[5555:1:2:3:4]:1357 SIP/2.0 Route: <sip:pcscsf2.home2.hu;1r> Route: <sip:scscf2.home2.hu;1r> Route: <sip:scscf1.home1.fr;1r> Route: <sip:pcscf1.visited1.fi;1r>
Luận văn thạc sĩ kỹ thuật 112
To: “Your Brother” <sip:tobi@brother.com>; tag=veli
From: “My beloved Sister” <sip:Theresa@sister.com>;tag=schwester
UE Tobias cũng sẽ bỏ PDP context của nó ngay khi nhận được yêu cầu BYE. Nó sẽ
phản hồi bằng 200 (OK). Các S-CSCF và AS cũng xóa bỏ các thông tin liên quan đến phiên và dialog.
Trường hợp P-CSCF thực hiện giải phóng phiên đã khởi tạo – khi nó nhận ra UE đã bị
mất sóng và không thể kết nối với mạng được, khi đó P-CSCF cần gửi yêu cầu BYE
đến phía UE ở xa (UE không bị mất sóng):
BYE sip:[5555::1:2:3:4]:1357 SIP/2.0 Route: <sip:scscf2.home2.hu;1r> Route: <sip:scscf1.home1.fr;1r> Route: <sip:pcscf1.visited1.fi;1r>
To: “Your Brother” <sip:tobi@brother.com>;tag=veli
From: “My beloved Sister” <sip:Theresa@sister.com>;tag=schwester
Trường hợp user dùng hình thức tính cước online – thuê bảo trả trước, đang thực hiện phiên dịch vụ thì tài khoản bị hết tiền thì S-CSCF sẽ thực hiện giải phóng phiên đã khởi tạo. Khi đó S-CSCF sẽ gửi yêu cầu BYE tới UE của user đó:
BYE sip:[5555::1;2:3:4]:1357 SIP/2.0 Route: <sip:pcscf1.visited1fi;1r>
To: “Your Brother” <sip:tobi@brother.com>;tag=veli
From: “My beloved Sister” <sip:Theresa@sister.com>;tag=schwester
Và yêu cầu BYE thứ hai tới user đối phương:
BYE sip:[5555:1:2:3:4]:1006 SIP/2.0 Route: <sip:scscf2.home2.hu;1r> Route: <sip:pcscf2.home2.hu;1r>
From: “Your Brother” <sip:tobi@brother.com>;tag=veli
Luận văn thạc sĩ kỹ thuật 113
CHƯƠNG III: PHÁT TRIỂN DỊCH VỤ GIÁ TRỊ GIA TĂNG LOCATOR - ADVERTISE CỦA
MOBIFONE TRÊN NỀN IMS 3.1 Hoàn cảnh ra đời dịch vụ
Tuấn Anh, một du khách Hồ Chí Minh lần đầu ra Hà Nội, vẫn còn bỡ ngỡ với Thủđô,
đang say mê dạo quanh ngắm cảnh Hồ Gươm thì trời đã chập choạng tối. Cầm chiếc Iphone 4G trên tay, Tuấn Anh quay số đến địa chỉ
nhanghi@locaadvert.mobifone.com.vn , ngay lập tức màn hình Iphone của Tuấn Anh hiển thị danh sách các nhà nhỉ mà xung quanh gần vị trí Tuấn Anh đứng, thật tiện lợi bởi những thông tin nhà mạng Mobifone cung cấp ngay tức thì.
Một buổi chiều thứ 7 cuối tháng, đang lang thang thả bước trên con phố Tràng Tiền xinh đẹp, bỗng chiếc điện thoại xinh xắn của Hương đổ chuông tít tít, tưởng anh chàng nào nhắn tin, Hương lôi điện thoại ra thì thấy màn hình hiển thị những lời quảng cáo hấp dẫn từ Siêu thị Tràng Tiền Palaza với hàng loạt mặt hàng mỹ phẩm saleoff mà Hương rất thích, thật đúng dịp nhận lương Hương thỏa thích mua sắm.
3.2Thiết kế, dịch vụ
3.2.1 Cấu trúc hệ thống liên quan đến dịch vụ Locator-advertise
Access Network IMS Core HSS P- CSCF UE S- CSCF LOCAADVERT AS I- CSCF UE Hình 3-1 Mô hình hệ thống VAS_IMS Các thành phần của hệ thống Locator- advertise :
Luận văn thạc sĩ kỹ thuật 114
3.2.1.1 Module Locator
Để truy vấn được dữ liệu của dịch vụ, các server LBS của hệ thống có các kết nối đến các tổng đài GMSC của mạng GSM để có thể truy cứu được các vị trí của các thuê bao hoặc có thể truy cứu được qua các hệ thống GPS.
3.2.1.2 Module Advertise.
Để đưa ra dịch vụ quảng cáo cho các UE đòi hỏi sự hỗ trợ của một hệ thống Mobile Advertising. Hệ thống Mobile Advertising thực hiện hợp nhất việc upload và quản lý nội dung quảng cáo bằng cách cung cấp thống nhất một cổng thông tin và giao diện tương tác (portal và interactive interfaces) cho advertisers, advertising agents, và audience. Hệ thống Mobile Advertising cũng thực hiện việc quản lý thống nhất các kênh phân phối quảng cáo và phát hành quảng cáo.
Hệ thống MobileAD được thiết kếđểđạt được 4 mục tiêu cơ bản:
Chuẩn hoá dịch vụ hiện tại cung cấp bởi khu vực quảng cáo di động và giải quyết vấn
đề của tin nhắn SMS spam.
Mở rộng nguồn thu của cho các nhà mạng bằng cách giúp các nhà mạng dần dần phát triển từ các dịch vụ truyền thông đơn nhất cũng gặt hái lợi nhuận khổng lồ từ việc hỗ
trợ các doanh nghiệp tiếp thị thương hiệu của họđến đông đảo thuê bao.
Thiết lập thống nhất các cổng thông tin cho quản lý tập trung việc phân phối quảng cáo di động.
Cung cấp một phương pháp tiếp cận mới, một nguồn thu lợi nhuận mới thông qua việc gửi nội dung quảng cáo đến người dùng điện thoại di động với các dịch vụ trung tâm
để nâng cao kinh nghiệm sử dụng dịch vụ cho đối tượng người sử dụng
3.2.2 Sựđăng ký dịch vụ
Dịch vụ Locaadvert có hai tính năng cơ bản, đó là tính năng tìm kiểm các thực thể như
NHÀ HÀNG, KHÁCH SẠN, NGÂN HÀNG, MÁY ATM, …. và tính năng nhận thông tin quảng cáo từ một chủ thể nào đó như một công ty, hay một siêu thị.
Do vậy, khách hàng muốn sử dụng được dịch vụ chẳng hạn muốn nhận đước các bản tin quảng cáo.. ,thì khách hàng sẽ phải đăng ký dịch vụ Locator- advertise.
Thông tin của khách hàng đăng ký dịch vụ Locator - advertise được lưu trữ thành các profile trên phần tử HSS của hệ thống.
Luận văn thạc sĩ kỹ thuật 115 UE P-CSCF I-CSCF HSS S-CSCF (1) REGISTER (5) REGISTER (2) REGISTER (3) Diameter UAR (18) 200 OK (4) Diameter UAA (6) Diameter MAR (7) Diameter MAA (8) 401 Unauthorized (9) 401 Unauthorized (10) 401 Unauthorized (11) REGISTER (12) REGISTER (13) Diameter UAR (14) Diameter UAA (15) REGISTER (16) Diameter SAR (17) Diameter SAA (19) 200 OK (20) 200 OK Hình 3-2 Quá trình đăng ký dịch vụ
Luận văn thạc sĩ kỹ thuật 116
Luận văn thạc sĩ kỹ thuật 117
Hình 3-4 Quá trình IMS Client nhận bản tin từ AS
3.3 Kết quả nghiên cứu
- Tìm hiểu được công nghệ IMS
- Dịch vụ mới chỉ mang đến được ở mức nghiên cứu, có ý nghĩa trong thực tiễn.
- Hướng phát tiển tiếp theo: nâng cao chức năng, tính đa dạng dịch vụ của hệ thống, cải tiến nhiều ứng dụng trên Locator-Advertise Application Server.
+ Giả sử trên các Application Server có nhiều cơ sở dữ liệu profile, chẳng hạn tôi
đang là thành viên của của forum dientuvietnam chẳng hạn, khi tôi đăng ký profile của mình trên hệ thống, lúc đó chẳng hạn tôi đến một vùng nào đó hệ thống có thể gửi thông tin về các thành viên trên forum cùng với tôi hay những tiện ích tương tự như
Luận văn thạc sĩ kỹ thuật 118
KẾT LUẬN
Trong thời đại ngày nay, Internet có vai trò ngày càng quan trọng trong lĩnh vực viễn thông, chính vì vậy IMS – sự kết hợp giữa điện thoại di động truyền thống và mạng internet hứa hẹn sẽ đem lại nhiều lợi ích cho cả người sử dụng lẫn nhà cung cấp dịch vụ. Trong thời gian thực hiện luận văn, dưới sự tận tình của PGS.TS. Nguyễn Hữu Thanh, tác giả đã nắm được những kiến thức về kiến trúc IMS và hiểu cách phát triển các dịch vụ mới trên nền kiến trúc IMS
Trong luận văn, tôi đã cố gắng xây dựng một dịch vụ mới có tính thiết thực trong cuộc sống. Tuy nhiên kết quảđạt được chỉ mới dừng lại mức nghiên cứu dịch vụ.
Luận văn thạc sĩ kỹ thuật 119
TÀI LIỆU THAM KHẢO
[1] Gonzalo Camarillo & Miguel A.Garcia-Martin, The 3G IP Multimedia Subsystem: Merging The Internet And The Cellular Worlds, Second Edition, John Wiley & Sons, Ltd, 2006.
[2] Alan B.Johnston, SIP: Understanding the session initiation protocol, second edition, Artech House telecommunications library, 2004.
[3] Miikka Poikselkä and Georg Mayer, The IMS: IP Multimedia Concepts and Services, Second Edition, Hisham Khartabil and Aki Nitác giải © 2006 John Wiley & Sons, Ltd. ISBN: 0-470-01906-9
[4] Rfc 3725, Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)
[5] 820-4281, SunGlassFish Communications Server 1.5 AdministrationGuide, SunMicrosysttác giảs, Inc. 4150Network Circle Santa Clara, CA 95054 U.S.A.
[6] Presence, Vishal Kumar Singh and Henning Schulzrinne April 10, 2006, Columbia Computer Science.
[8] Rfc 3327, Session Initiation Protocol (SIP) Extension Header Field
[9] http://www.iptel.org [10] http://tech-invite.com
[11] http://uctimsclient.berlios.de [12] https://sailfin.dev.java.net