Nhiều ứng dụng ngày nay đòi hỏi cao về vấn đề đảm bảo thông lượng, độ trễ và độ tin cậy khi thực thi trên mạng. Đa phương tiện là một ứng dụng điển hình. Ứng dụng đa phương tiện yêu cầu cao về chất lượng, trong khi đó ngày càng có nhiều ứng dụng loại này được truyền qua mạng không dây và qua vệ tinh. Mạng không dây và đặc biệt là truyền thông vệ tinh có một số hạn chế như có độ trễ cao, băng thông hẹp, v.v. Khi truyền trong môi trường này cần có cơ chế điều khiển và tránh tắc nghẽn phù hợp. Phần này của bài đồ án sẽ trình bày về một khả năng ứng dụng giao thức RCSaM cho truyền tin qua vệ tinh, cụ thể là cho ứng dụng truyền Video theo yêu cầu (VideoaonaDemand).
5.2. RCS!M trong ứng dụng Video!on!Demand qua vệ tinh
RCSaM cho ứng dụng VideoaonaDemand qua vệ tinh được mô tả trong hình 5.2.1:
Hình 5.2.1: Mô hình hệ thống truyền video theo yêu cầu Mô tả ứng dụng
Trong ứng dụng VideoaonaDemand điển hình, một Video Server làm nhiệm vụ lưu trữ các video clips. Từ máy đầu cuối, người dùng có thể truy nhập vào kho lưu trữ video clips để chọn các video clips yêu thích theo yêu cầu. Ứng dụng có thể được xây dựng theo mô hình Client/Server. Video Server đảm nhiệm vai trò server còn ứng dụng phía người dùng đảm nhiệm vai trò Cient, hiển thị video clips trên màn hình đầu cuối người dùng.
Như đã trình bày trong chương 3 và 4, giao thức RCSaM hoàn toàn có thể phù hợp cho việc truyền các thông tin đa phương tiện qua kênh truyền vệ tinh với nhu cầu đảm bảo chất lượng dịch vụ, và có thể áp dụng cho thiết kế ứng dụng này.Nguyên tắc triển khai RCSaM cho ứng dụng videoaonademand sẽ được trình bày trong phần tiếp theo. Máy đầu cuối người dùng Video Server Kho dữ liệu Video Vệ tinh Trạm mặt đất Trạm mặt đất
Bản chất các video clips là chuỗi các ảnh liên tiếp, được lưu trữ trên Video Server dưới dạng các tệp tin. Chương trình Video Server đọc các tệp tin này, chia các ảnh ra các gói tin, có thể chọn các phương thức mã hóa nén ảnh thích ứng như JPEG hoặc MPEG tùy theo khả năng đáp ứng của băng thông kênh truyền và theo yêu cầu phía người dùng đầu cuối. Chương trình video client phía máy đầu cuối người dùng có thể chọn lựa các phương thức mã hóa nén ảnh nói trên và hiển thị video clips trên màn hình người dùng.
Ứng dụng có thể được thực hiện qua hai pha: pha 1 là giai đoạn người dùng gửi yêu cầu (tín hiệu điều khiển) đến Video Server để chọn lựa video clips, kiểu mã hóa,, v.v. Pha 2 là giai đoạn truyền luồng video thực sự. Tuy nhiên, để đơn giản hóa, trong chương 5 chỉ đưa ra thử nghiệm coi ở Video Server chỉ có một video clip.
5.3. Triển khai giao thức RCS!M cho ứng dụng Video!on! demand
Chương 3 và 4 đã trình bày về nguyên tắc hoạt động của RCSaM và thực thi RCSaM với bộ công cụ mô phỏng NSa2. Trong chương này, bài đồ án sẽ trình bày khả năng triển khai giao thức RCSaM trong thực tế và cho một ứng dụng cụ thể.
Nói chung, việc triển khai một giao thức trong thực tế cần đảm bảo được các quy tắc về cú pháp, ngữ cảnh và đồng bộ trong truyền thông để điều khiển hoặc cho phép kết nối, truyền thông và truyền dữ liệu giữa hai máy đầu cuối.
Trong các ứng dụng đa phương tiện truyền thống, giao thức truyền tải thường được thiết kế ở lớp giao vận hoặc lớp ứng dụng, hoặc thậm chí có thể được thiết kế ở tầng trung gian, nghĩa là đặt giao thức đó ở trên tầng giao vận và dưới tầng ứng dụng, nhằm phát huy ưu điểm của hai cách nói trên. Giao thức được đặt ở tầng giao vận (như UDP, TCP) cung cấp giao diện API (Application Programming Interface) cho người sử dụng phát triển ứng dụng. Các giao diện này thường được biểu thị qua các sockets. Những giao thức đặt ở lớp ứng dụng thường gắn với một ứng dụng cụ thể (ví dụ như ứng dụng Realplayer). Ưu điểm của cách này là mỗi giao thức gắn liền với từng ứng dụng và không cần thay đổi TCP, UDP. Do gắn với từng ứng dụng cụ thể nên giao thức phụ thuộc vào ứng dụng, khi thay đổi ứng dụng thì phải thay đổi giao thức cho phù hợp.
Tuy nhiên, có thể có một cách thứ ba để thực thi triển khai giao thức trong thực tế là đặt giao thức ở trên tầng giao vận và dưới tầng ứng dụng. Cách này kết hợp các ưu điểm của hai cách trên: Tốc độ nhanh; Tận dụng được lớp chức năng phần mềm sẵn có của UDP và TCP (nghĩa là trong suốt với ứng dụng); Phục vụ nhiều ứng dụng khác nhau trong cùng một loại truyền tin đa phương tiện; Không phá vỡ tính hệ thống của mô hình phân lớp OSI. Nhưng do có thêm phần đóng gói dữ liệu nên cũng cần quan tâm đến vấn đề overhead có thể làm giảm lưu lượng truyền.
Truyền tin đa phương tiện có đặc trưng yêu cầu cao về chất lượng dịch vụ như độ trễ, hiệu năng, chất lượng dịch vụ nói chung và UDP, TCP không đảm bảo được được các yêu cầu trên. Từ những ưu và nhược điểm của các cách thiết kế giao diện, để ứng dụng giao thức RCSaM vào truyền tin vệ tinh, giao thức RCSaM có thể triển khai trên tầng giao vận và dưới tầng ứng dụng gồm một tầng trung gian có giao diện cung cấp cho phía ứng dụng và sử dụng các dịch vụ của lớp UDP. Mặt khác, việc triển khai RCSaM như trên cho phép giao thức RCSaM tồn tại song song với các giao thức sẵn có của kiến trúc TCP/IP, tương thích với cơ chế điều khiển luồng chống tắc nghẽn sử dụng thuật toán tăng giảm phổ biến trên mạng. Hình 5.2.1 thể hiện khả năng ứng dụng giao thức RCSaM vào trong thực tế và vị trí của RCSaM trong mô hình phân lớp TCP/IP.
Hình 5.3.1: Giao thức RCSaM trong mô hình phân lớp TCP/IP
Ứng dụng RCSaM để truyền video cho ứng dụng VideoaonaDemand như hình 5.3.2.
Hình 5.3.2: Mô hình ứnh dụng RCSaM để truyền video cho ứng dụng Videoaona Demand
Thiết kế Header của RCS!M trong thực tế
Hình 5.3.1 là ví dụ về khả năng triển khai phần Header cho RCSaM trong thực tế. Header của RCSaM có kích thước cố định để đơn giản hóa việc xử lý ở mỗi node. Bốn bit đầu của header RCSaM để nhận dạng gói là gói RCSaM. Các trường khác trong phần Header gồm: trường chiều dài gói tin, số trình tự gói tin, mỗi gói có thể có một nhãn thời gian (timestamp) để kiểm tra thời gian phát gói (có thể dùng trường này để tính thời gian gói gửi và nhận), trường tổng kiểm tra (checksum) header của RCSa M.
Ứng dụng Kiến trúc hạ tầng mạng (wireless, vệ tinh) IP TCP UDP RCSaM IP UDP RCSaM Video Client (Decoder) IP UDP RCSaM Video Server (Encoder) Kênh vệ tinh
Bảng 5.3.1: Header của gói RCSaM Triển khai chương trình bên video server
Video Server đóng vai trò nguồn phát của RCSaM. Video Server tạo kết nối và thiết lập thời gian timeout. Video Server tính toán tốc độ truyền và bắt đầu gửi các gói dữ liệu. Trong quá trình gửi gói nếu phát hiện có mất gói, Video Server điều chỉnh tốc độ và xác định nguyên nhân mất gói. Sau khi xác định được lý do mất gói, Video Server sẽ chuyển sang các trạng thái thích hợp. Chi tiết thuật toán như đã trình bày ở chương 3.
Triển khai chương trình bên video client
Video Client đóng vai trò của nguồn thu. Video Client tạo kết nối và thiết lập thời gian timeout và chờ nhận gói tin phía Video Server. Trong quá trình nhận các gói tin, Video Client gửi lại các phản hồi cho Video Server. Các phản hồi của Video Client giúp Video Server biết được chất lượng của đường truyền để có những điều chỉnh phù hợp. Khi nhận được các thông tin phía Video Server, Video Client hiển thị các hình ảnh trên màn hình của máy đầu cuối. Phần chương trình hiển thị cho Video Client có thể được xây dựng dựa trên một chương trình ứng dụng mã nguồn mở có tên là nv [13]. Màn hình của ứng dụng trên máy đầu cuối người dùng được minh họa như trong các hình 5.3.3, hình 5.3.4 và hình 5.3.5.
Hình 5.3.3: Chức năng Encoding Hình 5.3.4: Chức năng Panels reserved
Timestamp Packet Length
Local ID
Header Checksum Packet Sequence Number RCSaM Version unused
Hình 5.3.5: Màn hình hiển thị
Trên các hình, Address là địa chỉ IP của Video Server. Port là cổng truy cập thông tin (có thể chọn giá trị bất ký từ 0001 đến 9999). Chan là số hiệu kênh (có thể chọn tùy ý). TTL là số chặng (hop) dự tính từ máy trạm Client đến máy Server. Các trường bên dưới hiển thị các tín hiệu điều khiển hình ảnh Video. Thực đơn VideoSource để chọn nguồn phát là Video hoặc tệp video. Encodings để chọn chế độ mã hóa từ Server và hiển thị trên màn hình Video Client. Panels cho phép hiển thị thông tin và trạng thái điều khiển cho tín hiệu video thu được (adsbygoogle = window.adsbygoogle || []).push({});
5.4. Kết luận chương
Chương 5 trình bày về một khả năng ứng dụng của RCSaM cho Videoaona Demand. Các thuật toán triển khai cho RCSaM trong thực tế về căn bản tương tự như thuật toán đã trình bày trong chương 3. Phần ứng dụng để hiển thị VideoaonaDemand sử dụng chương trình nv (network video) để minh họa cho việc truyền Videoaona Demand qua mạng vệ tinh với giao thức RCSaM.
Kết luận và hướng phát triển
Cùng với các hệ thống cáp quang, cáp biển, cáp mặt đất, hệ thống thông tin vệ tinh mang đến những ứng dụng mới cho các dịch vụ viễn thông và Internet băng rộng. Tuy nhiên, do truyền tín hiệu qua không gian, truyền thông vệ tinh phải đối đầu với các thách thức kỹ thuật như: trễ truyền lớn, băng thông hạn hẹp, nhiễu. v.v. Tín hiệu truyền qua không gian bị suy giảm, bị nhiễu do môi trường, điều kiện thời tiết, v.v. Mặt khác, ngày nay con người sử dụng ngày càng nhiều dịch vụ truyền đa phương tiện. Các dịch vụ đa phương tiện có những đòi hỏi khắt khe về chất lượng dịch vụ. Để đảm bảo chất lượng dịch vụ cho truyền tin qua vệ tinh, cần có những cơ chế điều khiển phù hợp. Chính vì thế nghiên cứu và phát triển cơ chế đảm bảo QoS đang là một trong những vấn đề thiết thực hiện nay trong truyền tin đa phương tin qua vệ tinh.
Chủ đề đặt ra đối với đồ án tốt nghiệp là nghiên cứu các vấn đề và giải pháp tới nay trong truyền thông đa phương tiện qua mạng thông tin vệ tinh, nghiên cứu giải pháp đảm bảo chất lượng truyền đa phương tiện qua vệ tinh.
Qua nghiên cứu và thực hiện, bài đồ án đã đạt được những kết quả sau:
+ Nghiên cứu tổng quan về hệ thống thông tin vệ tinh, khảo sát những vấn đề liên quan trong truyền thông vệ tinh.
+ Nghiên cứu tìm hiểu về công nghệ truyền thông vệ tinh và vấn đề chất lượng dịch vụ, hệ thống hóa một số vấn đề trong đảm bảo chất lượng dịch vụ khi truyền đa phương tiện qua vệ tinh.
+ Nghiên cứu, thiết kế cơ chế điều khiển truyền tin đảm bảo QoS qua vệ tinh RCSaM trên cơ sở cải tiến cơ chế RCS: RCSaM chạy trực tiếp trên UDP thay vì gián tiếp qua RTP như RCS, qua đó giảm được Overhead và góp phần tăng thông lượng; Khắc phục hạn chế của RCS trong ước tính RTT (RCS không ước tính RTT).
+ Thực hiện mô phỏng RCSaM bằng bộ công cụ mô phỏng NSa2 và đánh giá kết quả mô phỏng thử nghiệm.
+ Trình bày một khả năng ứng dụng RCSaM vào thực tế qua một ứng dụng Videoa onaDemand (truyền video theo yêu cầu qua vệ tinh).
Những kết quả mô phỏng và thử nghiệm trong bài cho thấy có thể áp dụng triển khai giao thức RCSaM vào thực tế để truyền thông tin đa phương tiện qua mạng vệ tinh đảm bảo yêu cầu chất lượng dịch vụ cho các ứng dụng và đảm bảo tương thích với những ứng dụng sẵn có sử dụng TCP hoặc UDP.
Trong thời gian có hạn và trong khuôn khổ một bài đồ án tốt nghiệp, kết quả đạt được của bài không tránh khỏi còn có những hạn chế như: Đánh giá mức độ hoạt động
ổn định của giao thức; Thử nghiệm giao thức với nhiều loại dịch vụ đa phương tiện khác nhau; Giả lập một kênh vệ tinh với mô hình nguồn lỗi sát với thực tế hơn; Triển khai thử nghiệm truyền tín hiệu video online với mạng vệ tinh thực tế. Đây cũng là những hướng có thể triển khai nghiên cứu tiếp trong tương lai của bài đồ án.
Tài liệu tham khảo
1. Bradford W. Parkinson. "GPS Eyewitness: The Early Years" GPS World 5, no. 9, 9/1994, 32a45
2. Ian F. Akyildiz, Fellow, IEEE, Özgür B. Akan, Member, IEEE, and Giacomo Morabito, A Rate Control Scheme for Adaptive Real]Time Applications in IP Networks With Lossy Links and Long Round Trip Times, IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 13, NO. 3, JUNE 2005.
3. I. F. Akyildiz, M. Johnson, G. Morabito, S. Palazzo and J. Tang, Research Issues for Transport Protocols in Satellite IP Networks, Submitted for publication, November 2000.
4. Ivan A. Getting. "The Global Positioning System", IEEE Spectrum, 12/1993, 36a 47.
5. J. Tang, G. Morabito, I. F. Akyildiz and M. Johnson, RCS: A Rate Control Scheme for Real]Time Traffic in Networks with High Bandwidth]Delay Products and High Bit Error Rates, To appear IEEE Infocom 2001, Alaska, April 2001.
6. Johnson, Nicolas L. "GLONASS Spacecraft", GPS World 5, no. 11, 11/1994, 51a 58.
7. Joe Montana, Introduction to Satellite Communications, George Mason University.
8. KS. Nguyễn Đình Lương biên dịch, PGS.PTS. Phạm Văn Đương hiệu đính, “Công nghệ thông tin vệ tinh” Nhà xuất bản khoa học và kỹ thuật (1997).
9. McGraw Hill, SatelliteCommunications 3rd Editon, 2002. 10.McGraw Hill, SatelliteCommunications 2nd Editon.
11.Higbie, Paul R. and Norman K. Blocker. "Detecting Nuclear Detonations with GPS", GPS World 5, no. 2, 2/1994, 48a50.
12.R. Rejaie, M. Handley, and D. Estrin, RAP: An end]to]end rate]based congestion control mechanism for realtime streams in the internet, in Proc. IEEE INFOCOM, vol. 3, Mar. 1999, pp. 1337–1345.
13.Ron Frederick: Experiences with real_time software video compression, Xerox PARC, July 22, 1944
compr essi on
14.Wysocki, Joseph, Lt. Col. "GPS and Selective Availability a The Military Perspective" GPS World 2, no. 7, 7&8/1991, 38a44
15.Wernher Von Braun and Frederick I. Ordway III, History of Rocketry & Space Travel, 1975. (adsbygoogle = window.adsbygoogle || []).push({});
Internet
16.http://www.sbv.gov.vn/CdeCNTT/TinDiendanCNTT.asp?tin=266 “TCP/IP Nâng cao chất lượng a Trên đường truyền vệ tinh địa tĩnh”
17.http://www.garmin.com/aboutGPS/ “What is GPS”
18.http://www.vnexpress.net/Vietnam/Khoaahoc/2003/07/3B9C9FC6/ “Hoạt động của hệ thống định vị toàn cầu GPS (X.O. (theo Wheels24))”.
19.http://www2.vietnamnet.vn/cntt/vienthong/2005/01/369657/ “Lùi thời điểm phóng vệ tinh Vinasat đến 2007”.
20.http://www.linktionary.com/s/satellite.html “Satellite Communication Systems”. 21.http://www.cesti.gov.vn/left/stinfo/thanh_tuu_khcn/khcn_trongnuoc/2005/2_2005/
tintn2_010205 “Việt Nam sẽ chế tạo vệ tinh nhỏ”.
22.http://www.tuoitre.com.vn/Tianyon/Index.aspx?ArticleID=177640&ChannelID=1 7 “Việt Nam "đủ lực" triển khai công nghệ vũ trụ” Theo Nhân dân, Nông thôn ngày nay.
23.http://www.tapchibcvt.gov.vn/News/PrintView.aspx?ID=17271 ”Trễ và tạp âm trên đường truyền TCP/IP qua vệ tinh địa tĩnh, Hồng Minh ”.
24.http://www.vti.com.vn/showCat.asp?CatID=37 “VSAT IP”.
25.www.vnpt.com.vn/support.asp?ids=1&ide=74 “Dịch vụ VSAT TDM /TDMA”. 26.http://www.hanoipc.evn.com.vn/EVNShow/tintuc1.asp?InforID=5148&CategoryI
D=880&Pos=880&rCount=898 “Sắp có dịch vụ băng rộng vệ tinh iPSTAR” theo: Quản trị mạng a Thùy Linh sưu tầm.
27.http://www.techmartvietnam.com.vn/news/200408106286259289/2005031435715 60778/tmnews_view “ Tháng 7 năm 2005: Việt Nam có dịch vụ VSAT băng rộng”, Nguồn: "Báo ND điện tử", 4/3/2005.
28.http://nile.wpi.edu/NS/ “NS by example”.
29.http://www.hq.nasa.gov/office/pao/History/satcomhistory.html “David J. Whalen,
Communications Satellites: Making the Global Village Possible”.
30.http://www.redsword.com/GPS/old/sum_his.htm#references “History of Satellite Navigation”.
31.http://www.tapchibcvt.gov.vn/viaVN/vienthonginternet/2006/5/16337.bcvt “VSATaIP mạng thông tin băng rộng qua vệ tinh thế hệ mới”.
32.http://www.boeing.com/defenseaspace/space/bss/what_is_a_satellite.pdf “What is a satelite”.
33.http://www.vnexpress.net/Vietnam/Khoaahoc/2004/10/3B9D7F96/ “Lùi thời điểm phóng vệ tinh Vinasat”.
34.http://vietnamnet.vn/cntt/vienthong/2005/03/385992/ “7/2005: VN có dịch vụ VSAT băng rộng”.
35.http://vngt.caigi.com/dichvu.html “Điện thoại trên nền IP”.
36.http://en.wikipedia.org/wiki/Quality_of_service “Quality of service”.
37.http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/qos.htm “Quality of Service Networking”
Phụ lục
P.1. Kết quả đo tốc độ truyền tin khi không có lỗi kênh