CHƢƠNG 2 : CHUẨN DVB-IP
2.7 Quá trình truyền MPEG-2TS
Phần này sẽ nói về việc phân phát các dịch vụ DVB trên mạng IP. Quá trình khởi tạo đăng ký, cấu hình thiết bị đầu cuối (bao gồm cả địa chỉ IP chỉ định), ý nghĩa của việc phát hiện, và lựa chọn một dịch vụ DVB sẽ được nói trong phần khác của tài liệu này. Phần này sẽ tập trung và việc định dạng của dịch vụ trên mạng IP và yêu cầu trên mạng về việc truyền chính xác và thời gian truyền của dịch vụ. Để phù hợp với mục 4 đã trình bày ở trên mục 7 sẽ đi đôi với giao diện IPI-1 của thiết bị đầu cuối mạng.
Phần này cũng phác thảo để có được yêu cầu về nội dung thẳng tới máy nhà (DTH) phân phát trên IP.
2.7.1 Tóm lƣợc về luồng truyền
Phần này có thể sử dụng để gói gọn một luồng truyền MPEG-2, nó có thể chứa một chương trình đơn hoặc đa chương trình. Việc truyền này chứa nhiều Program Clock Reference (PCR) bằng cách định nghĩa, hằng số của luồng truyền bit dữ liệu. Luồng truyền chứa một đồng hồ đo liên quan tới tốc độ luồng truyền,giá trị này có thể là một hằng số cũng có thể biến đổi.
Chú ý: Tuy nhiên trong trường hợp tốc độ bít là biến đổi, tốc độ bit giữa các PCR là không đổi và được định nghĩa trong MPEG-2.
Content Service Provider (CSP) có thể nhận các luồng truyền dữ liệu (ví như từ vệ tinh) chứa rất nhiều chương trình. CSP được dùng để phân tách các luồng truyền và tạo ra các luồng truyền riêng biệt (SPTS) cho mỗi chương trình, hoặc để truyền Multiple Program Transport Stream (MPTS) để đảm bảo tính toàn vẹn của nó.
Tất cả các luồng truyền MPEG-2 sẽ được tóm lược trong RTP theo RFC 1889[23] kết hợp với RFC [34]. UDP đặc biệt sử dụng trong một vài hệ thống cũng sẽ không được sử dụng trong trường hợp này.
RTP luôn sử dụng số cổng UDP (trong RFC 1889[23]). Nếu thiết bị đầu cuối được áp dụng với một cổng RTP, nó sẽ được thay thế số cổng này thành một số cổng nhỏ hơn. Luồng RTCP trả về sẽ sử dụng một cổng tiếp theo (số thứ tự cổng lớn hơn).
Mỗi gói IP được định dạng theo chuẩn tiêu đề IP, một tiêu đề UDP, một tiêu đề RTP và một số nguyên của gói tin trong luồng truyền 188 byte MPEG-2. Như ta thấy trong hình 10 ở dưới đây, không có yêu cầu cho mỗi gói RTP trong một luồng để chứa cùng một số lượng của các gói trong luồng truyền dữ liệu. Nơi nhận sẽ sử dụng trường chiều dài trong tiêu đề UDP để đo số lượng gói tin truyền trong mỗi gói RTP.
Hình 16 - Định dạng nhỏ nhất của gói (Ipv4)
Số lượng của các gói trong luồng truyền có thể được lược trong mỗi gói IP và được giới hạn bởi kích thước tối đa của khối dữ liệu IP (65 535 octets cho Ipv4). Việc này nhằm mục đích kiểm soát giới hạn tối đa có thể truyền trên mạng. Nếu vượt quá MTU của mạng sẽ dẫn tới phân mảnh IP, và làm tăng hiệu ứng mất gói tin trên mạng. Nguyên nhân là do nếu một đoạn tin bị mất, các đoạn tin còn lại sẽ bị loại khỏi nơi nhận. Nó cũng đặt thêm tải lên bộ định tuyến và tái lắp ráp tại hệ thống đầu cuối.
Đối với Ethernet-based work, 1 492 bytes của MTU (IEEE 802.3 khung với LLC) hoặc 1 500 bytes (IEEE 802.3 khung không chứa LLC), số lượng các gói MPEG trên gói IP sẽ được giới hạn là 7 (tức là chiều dài tối đa của gói là: 1 356 bytes). Nơi lựa chọn tiêu đề IP hoặc RTP được sử dụng số của các gói MTS trên gói IP có thể ít hơn 7 đặt trong MTU.
Nếu tải RTP được thiết lập để tìm kiếm phân mảnh, thì bất cứ thiết bị đầu cuối không được hỗ trợ về phân mảnh thì không thể nhận được luồng dữ liệu này. Vì thế một đề nghị được đưa ra đó là các CSP thiết lập bit DF (do not Fragment) trong tiêu đề IP. Với bit này, các bộ định tuyến sẽ trả về một bản tin ICMP “fragmentation needed and DF set” nếu độ dài gói tin vượt quá MTU của mạng đích. CSP có thể hiệu chỉnh kích cỡ tải như bản tin đã nhận được. IP (RFC 791[12]) yêu cầu tất cả các máy chủ sẽ bắt buộc chấp nhận gói dữ liệu ít nhất là 575 octets
CSP có thể lựa chọn không kiểm tra tổng UDP và thiết lập giá trị này từ 0 (như là trên RFC 768[11]).
Hình 17 - Định dạng tiêu đề RTP
Loại tải sẽ được thiết lập từ MP2T giống như trong RFC 1890[24]
16 bit đếm thứ tự trong tiêu đề RTP sẽ được sử dụng bởi nơi nhận để yêu cầu cung cấp lại các gói đã được gửi đi, xoá các gói giống nhau, và dò tìm các gói bị thất lạc.
32 bit mốc thời gian trong tiêu đề RTP thu được từ nguồn đồng hồ 90kHz, nhưng không yêu cầu tồn tại, khoá đồng hồ tham chiếu tới một trong những chương trình trong luồng tải. Đồng hồ sẽ phù hợp với sự chính xác và giảm khó khăn cho hệ thống đồng hồ của MPEG 2 (như được định nghĩa trong ISO/IEC 13818-1 [62]).
Các trường khác được hoàn thành giống như trên RFC 1889[23] và RFC 2250[34]. Lựa chọn trường CSRC sẽ bị thiết bị đầu cuối bỏ qua.
Đối với hầu hết luồng truyền dữ liệu, các RTP/UDP/IP sử dụng 40 byte trên gói RTP là rất ít (chỉ chiếm 3% trong số 1 316 byte). Mặc dù các tiêu đề nén có thể mang lại lơi ích về tỉ lệ bit thấp, nhưng tăng độ phức tạp mà nơi đầu cuối không thể nhận được. Như vậy tiêu đề nén (như RFC 2508 [41]) sẽ không được sử dụng.
2.7.2 Giao thức điều khiển truyền thời gian thực- RTCP (Real-time Transport Control Protocol ) Transport Control Protocol )
RTP định nghĩa một giao thức thứ 2: RTCP. Nó được sử dụng để cung cấp thông tin phản hồi về chất lượng nhận tin của mạng tại từng điểm và cũng cho phép từng thành phần xác định các thành viên khác trong một đoạn tin.
Luồng RTP kết hợp sẽ luôn sử dụng cổng UDP chẵn, luồng RTCP sẽ sử dụng port number cao hơn
RTCP định nghĩa ra 2 bản tin, Bản tin báo cáo sẽ được phát đi bởi nơi gửi tới các đầu nhận và được dùng để khai báo về các trạng thái truyền cho nơi nhận (số lượng các gói và số lượng byte được gửi). Bản tin báo cáo được gửi định kỳ từ mỗi nơi
Giao diện IPI-1 không được hỗ trợ về bản tin báo cáo. Quyết định này dựa trên quy mô mạng, đối với việc triển khai quy mô lớn, quá trình tiếp nhận báo cáo có thể tạo ra lưu lượng lớn các truy cập của nơi gửi.
Giao diện IPI-1 được hỗ trợ bản tin báo cáo, các CSP được đề nghị gửi bản tin báo cáo đồng bộ luồng truyền một cách chính xác. Nếu các CSP chọn bản tin báo cáo để gửi trong thời gian lặp giữa các lần truyền không vượt quá 10s.
Đối với 2 ứng dụng RTCP cho phép nơi gửi chứa trường báo cáo nhận với bản tin báo cáo. Các trường này không bao gồm bản tin báo cáo được tạo ra bởi các CSP.
Nơi nhận có khả năng nhận và giải mã đồng thời các luồng truyền tin. Vấn đề ở đây là làm thế nào để đồng bộ hoá hai luồng với đồng hồ độc lập. Đối với ứng dụng này, nơi gửi báo cáo sẽ cần sử dụng để truyền tải các mối quan hệ giữa các giá trị: thời gian RTP và thời gian thực. Mỗi bản tin báo cáo gửi chứa 2 mốc thời gian đưa ra trong cùng một trường hợp, một là đồng hồ nguồn RTP và một cái kia là đồng hồ thời gian treo tường được xác định bởi giao thức thời gian mạng (Network Time Protocol-NTP)
Báo cáo gửi cho phép thiết bị đầu cuối tính toán về khoảng trống của 2 luồng truyền để giữ cho chúng được đồng bộ. Thiết bị đầu cuối không được hỗ trợ về NTP để đồng bộ đa luồng truyền. Các CSP sử dụng NTP để tạo ra các báo cáo gửi của chúng. Để kích hoạt quá trình đồng bộ tại nơi nhận, các CSP sẽ đồng bộ các đồng hồ NTP của chúng trong khoảng 20ms.
2.7.3 Ghi nhớ thông tin dịch vụ (SI)
Tất cả các luồng truyền sẽ tuân theo hệ thống MPEG-2 như các thông tin trong bảng:
Program Association Table (PAT) Program Map Table (PMT)
Các bảng này đưa ra các thông số phù hợp với DVB SI.
Các luồng truyền với lựa chọn SI (TS-optional SI), các bảng MPEG-2 và DVB đều được lựa chọn.
Luồng truyền SI với TS-optional được dự kiến sử dụng cho một vài trường hợp khi mà các nhà cung cấp muốn đưa ra các đề nghị nhưng nó không đủ khả năng hoặc không muốn sử dụng băng thông cho dịch vụ DVB mô tả dữ liệu thông thường.