UNIVERSIDADE PRESBITERIANA MACKENZIE PROGRAMA DE P ´ OS-GRADUAC ¸ ˜ AO EM ENGENHARIA EL´ ETRICA E COMPUTAC ¸ ˜ AO
CELSO DA SILVA DINIZ
AN ´ ALISE DO PADR ˜ AO MMT PARA TRANSPORTE DE SERVIC ¸ OS DE TV DIGITAL
S˜ ao Paulo
2019
Celso da Silva Diniz
An´ alise do padr˜ ao MMT para transporte de servi¸ cos de TV digital
Disserta¸c˜ ao de Mestrado apresentada ao Programa de P´ os-Gradua¸c˜ ao em Engenharia El´ etrica e Computa¸c˜ ao da Universidade Presbiteriana Mackenzie, para obten¸c˜ ao do T´ıtulo de Mestre em Engenharia El´ etrica.
Orientador: Prof. Dr. Cristiano Akamine
S˜ ao Paulo
2019
Bibliotecária Responsável: Maria Gabriela Brandi Teixeira – CRB 8/ 6339
D583a
Diniz, Celso da Silva
Análise do padrão MMT para transporte de serviços de TV digital / Celso da Silva Diniz – São Paulo, 2019.
73 f.: il., 30 cm.
Dissertação (Mestrado em Engenharia Elétrica e Computação) - Universidade Presbiteriana Mackenzie - São Paulo, 2019.
Orientador: Prof. Dr. Cristiano Akamine Bibliografia: f. 71-73
1. MMT, MMTP 2.MPEG Media Transport 3. SBTVD 4.TV digital, serviço multimídia 5.
Protocolo de aplicação 6. Entrega híbrida
7. Radiodifusăo terrestre 8. Rede banda-larga9.Transporte de vídeo I. Akamine, Cristiano, orientador. II.Título.
CDD 621.3
Dedico este trabalho aos meus pais Celio e Concei¸ c˜ ao
que me educaram, e em especial ` a minha m˜ ae, que me
ensinou as primeiras letras. ` A minha esposa Isolina e
filha Larissa que sempre me apoiaram e incentivaram
nos meus estudos, com muito amor e carinho. E ` a
minha irm˜ a Cristina que orou constantemente para
supera¸ c˜ ao de meus desafios.
AGRADECIMENTOS
Agrade¸co ao meu orientador Professor Doutor Cristiano Akamine, pela confian¸ca de- positada em mim para o desenvolvimento deste trabalho e tamb´ em por todo o apoio, aux´ılio, paciˆ encia e conhecimento compartilhados comigo.
A Rede Nacional de Ensino e Pesquisa - RNP, pela concess˜ ` ao de minha bolsa de pesquisa e desenvolvimento oferecida.
Ao Programa de P´ os-Gradua¸c˜ ao em Engenharia El´ etrica e Computa¸c˜ ao (PPGEEC) da Universidade Presbiteriana Mackenzie, por todo o suporte para a realiza¸c˜ ao desta pesquisa, e a todo seu corpo docente.
Ao Fundo Mackenzie de Pesquisa (MackPesquisa) pelo apoio na publica¸c˜ ao de meu artigo no Congresso do IEEE.
Ao Laborat´ orio de TV Digital, por ter me cedido sua infraestrutura, literatura e recursos, sem os quais seria imposs´ıvel realizar o trabalho aqui descrito.
Aos professores, que me apoiaram e compartilharam seu conhecimento durante o per´ıodo de disciplinas.
A todos os colegas que de alguma forma contribuiram e me suportaram com valiosas informa¸c˜ oes, em especial, meus agradecimentos ao George Henrique Maranh˜ ao Garcia de Oliveira e Ricardo Seriacopi Raba¸ca.
E finalmente, meu profundo reconhecimento ao Professor Doutor Gustavo de Melo
Valeira, pelo incessante apoio, colabora¸c˜ ao e companheirismo recebido ao longo de todo
a elabora¸c˜ ao deste trabalho.
RESUMO
Um sistema de TV digital utiliza m´ etodos padronizados para compress˜ ao, multiplexa¸c˜ ao e transmiss˜ ao dos sinais audiovisuais e dados de conte´ udo. Especificamente na etapa de multiplexa¸c˜ ao, os sistemas mais difundidos atualmente se baseiam na norma inter- nacional do grupo MPEG (Moving Picture Experts Group) – ISO/IEC 13818-1 (2015).
Com o crescente volume de transmiss˜ oes de fluxos de v´ıdeo na Internet, seja por servi¸cos sob-demanda ou em tempo real, surgiu a necessidade do desenvolvimento de mecanis- mos/protocolos de transporte com maior flexibilidade e controle da qualidade do servi¸co transmitido. Para atender este novo segmento e tamb´ em garantir a evolu¸c˜ ao dos servi¸cos de televis˜ ao, foi desenvolvido um novo padr˜ ao ISO (International Organization for Stan- dardization). Esta disserta¸c˜ ao apresenta as principais caracter´ısticas e funcionalidades do novo padr˜ ao internacional MMT (MPEG Media Transport ), elaborado pela ISO, para transporte e entrega h´ıbrida de tr´ afego multim´ıdia de servi¸cos de TV digital em redes por radiodifus˜ ao e banda-larga. ´ E apresentada a arquitetura do MMT, assim como suas res- pectivas estruturas de dados, formata¸c˜ oes de protocolo e mensagens de controle. Tamb´ em
´ e proposta a implementa¸c˜ ao de um analisador de protocolos, espec´ıfico para o MMTP (MPEG Media Transport Protocol ), padronizado pela norma ISO/IEC 23008-1 (2017) e potencial substituto do protocolo MPEG-2 TS (MPEG-2 Transport Stream ), em opera¸c˜ ao nas atuais redes de televis˜ ao.
Palavras-chave:
MMT, MMTP, MPEG Media Transport, SBTVD, TV digital, servi¸ co multim´ıdia, protocolo de aplica¸ c˜ ao, entrega h´ıbrida, radiodifus˜ ao terrestre, rede
banda-larga, transporte de v´ıdeo.
ABSTRACT
A digital TV system uses standardized methods for compression, multiplexing and trans- mission of audiovisual signals and content data. Specifically in the multiplexing stage, the most widespread systems are currently based on the international standard of the MPEG group (Moving Picture Experts Group) – ISO/IEC 13818-1 (2015). With the increasing volume of video streaming on the Internet, whether through on-demand or real-time servi- ces, the need arose for the development of transport mechanisms / protocols with greater flexibility and control of the quality of the transmitted service. To meet this new segment and also ensure the evolution of television services, a new ISO (International Organization for Standardization) standard has been developed. This dissertation presents the main characteristics and functionalities of the new international standard MMT (MPEG Media Transport), developed by ISO, for the transportation and hybrid delivery of multimedia traffic of digital TV services in broadcast and broadband networks. The architecture of the MMT is presented, as well as its respective data structures, protocol formatting and control messages. It is also proposed the implementation of a protocol analyzer specific to MMTP (MPEG Media Transport Protocol ), standardized by ISO/IEC 23008-1 (2017) and potential substitute of the MPEG-2 Transport Stream protocol (MPEG-2 Transport Stream), in operation in the current television networks.
Keywords:
MMT, MMTP, MPEG Media Transport, SBTVD, Digital TV, multimedia
service, application protocol, hybrid delivery, terrestrial broadcast, broadband network,
video streaming.
Lista de Figuras
Figura 1 Pilha de protocolos MMT . . . . 6
Figura 2 Estrutura do Package MMT . . . . 8
Figura 3 Formato do
boxmmpu . . . . 10
Figura 4 Diagrama de um Asset/Area/View . . . . 11
Figura 5 Exemplo de um ADC . . . . 12
Figura 6 Encapsulamento de MPU . . . . 13
Figura 7 Estrutura do cabe¸calho de payload MMT - modo MPU . . . . 14
Figura 8 Cabe¸calho de DU para MFU com m´ıdia temporizada . . . . 15
Figura 9 Cabe¸calho de DU para MFU com m´ıdia n˜ ao-temporizada . . . . . 15
Figura 10 Estrutura do cabe¸calho de payload MMT - modo GFD . . . . 15
Figura 11 Estrutura do cabe¸calho de payload MMT - modo sinaliza¸c˜ ao . . . 15
Figura 12 Estrutura do pacote MMTP (V=0) . . . . 17
Figura 13 Estrutura do pacote MMTP (V=1) . . . . 17
Figura 14 Arquitetura FEC no padr˜ ao MMT . . . . 21
Figura 15 Modelo HRBM do protocolo MMT . . . . 26
Figura 16 Referencias das SLTs aos servi¸cos ATSC 3.0 . . . . 28
Figura 17 Uso da SLS para descoberta e aquisi¸c˜ ao de servi¸co . . . . 31
Figura 18 Exemplo de Pacote STLTP . . . . 33
Figura 19 Exemplo de Relacionamento entre os protocolos ATSC 3.0 . . . . . 34
Figura 20 Test Bed - MMT/ATSC 3.0 . . . . 37
Figura 21 Exemplo de Encapsulamento MMT e Transmiss˜ ao ATSC 3.0 . . . 38
Figura 22 Gera¸c˜ ao do Conte´ udo e Codifica¸c˜ ao ISOBMFF . . . . 39
Figura 23 Detalhamento da Codifica¸c˜ ao ISOBMFF . . . . 40
Figura 24 Codifica¸c˜ ao ISOBMFF n˜ ao-temporizada . . . . 41
Figura 25 Encapsulamento MPU . . . . 42
Figura 26 Encapsulamento m´ıdia n˜ ao-temporizada . . . . 43
Figura 27 Detalhe do box mmpu . . . . 44
Figura 28 Encapsulamento m´ıdia temporizada . . . . 45
Figura 29 Mensagem de sinaliza¸c˜ ao para entrega . . . . 46
Figura 30 Mensagem de sinaliza¸c˜ ao para consumo . . . . 47
Figura 31 Payload MMTP . . . . 48
Figura 32 Armazenamento MMT . . . . 49
Figura 33 Empacotamento MMT . . . . 50
Figura 34 AL-FEC . . . . 51
Figura 35 Fluxo protocolo MMTP . . . . 52
Figura 36 Scheduler ATSC 3.0 . . . . 53
Figura 37 Encapsulamento MMTP/ALPTP/BBP/STLTP . . . . 54
Figura 38 Pacote STLTP . . . . 55
Figura 39 Modula¸c˜ ao e transmiss˜ ao RF . . . . 56
Figura 40 Sistema MMT completo: transmiss˜ ao e recep¸c˜ ao . . . . 57
Figura 41 IDE - Microsoft Visual Studio 2017 . . . . 58
Figura 42 Tela - Analisador de Protocolo MMTP(Vers˜ ao inicial) . . . . 62
Figura 43 Tela Ampliada - Analisador de Protocolo MMTP(Vers˜ ao inicial) . 62 Figura 44 Tela - Analisador de Protocolo MMTP(Vers˜ ao atualizada) . . . . . 63
Figura 45 Tela Ampliada - Analisador de Protocolo MMTP(Vers˜ ao atualizada) 63
Figura 46 Tela - Protocolos IP/UDP . . . . 64
Figura 47 Tela - Payload MMT . . . . 65
Figura 48 Tela - Tipo de Payload MMT . . . . 65
Figura 49 Tela - MPU - Boxes ISOBMFF . . . . 66
Figura 50 Tela - Box ISOBMFF moof . . . . 66
Figura 51 Tela - Decodifica¸c˜ ao de Mensagens de Sinaliza¸c˜ ao . . . . 67
Figura 52 Tela - Mensagem ATSC 3.0 - bundle descriptor . . . . 67
Figura 53 Tela - Decodifica¸c˜ ao do timestamp no formato NTP . . . . 68
Figura 54 Gr´ afico - Amostras de Timestamps . . . . 68
Lista de Tabelas
Tabela 1 Tipos de dados e defini¸c˜ ao das unidades de dados (V=0) . . . . . 19
Tabela 2 Tipos de dados e defini¸c˜ ao das unidades de dados (V=1) . . . . . 20
Tabela 3 Formato geral das mensagens de sinaliza¸c˜ ao MMT . . . . 24
Tabela 4 Valores de identifica¸c˜ ao de mensagem (message id ) . . . . 24
Tabela 5 Valores de identifica¸c˜ ao de mensagem (message id ) - Continua¸c˜ ao 25 Tabela 6 Redefini¸c˜ ao do formato de cabe¸calho RTP para uso no STLTP . . 32
Tabela 7 Sintaxe do fluxo de bits para tabelas LLS . . . . 35
Tabela 8 Campos MMTP decodificados no analisador . . . . 61
Lista de Abreviaturas e Siglas
AAC Advanced Audio Coding ADC Asset Delivery Characteristics AEAT Advanced Emergency Alert Table
AL-FEC Application Layer - Forward Error Correction ALP ATSC 3.0 Link-Layer Protocol
API Application Programming Interface
ARQ-AC Automatic Repeat reQuest - ARQ Configuration ARQ-AF Automatic Repeat reQuest - ARQ Feedback ATSC Advanced Television Standards Comittee AU Access Unit
AVC Advanced Video Coding BBP Baseband Packet
BER Bit Error Rate CD Committee Draft
CI Composition Information CLI Cross Layer Interface
CODEC COdificador/DECodificador CRI Clock Relation Information
DASH Dynamic Adaptive Streaming over HTTP DCI Device Capability Information
DiffServ Differentiated Services DLL Dynamic Link Library
DSCP Differentiated Services Code Point DU Data Unit
DVB Digital Video Broadcasting
DWD Distribution Window Description FEC Forward Error Correction
GFD Generic File Delivery
GNU-GPL GNU General Public License GUI Graphical User Interface
HDTV High Definition TeleVision
HELD HTML Entry pages Location Description HEVC High Eficiency Video Coding
HRBM Hypothetical Receiver Buffer Model
HRBMR Hypothetical Receiver Buffer Model Removal HTML5 Hyper Text Markup Language - version 5 HTTP HyperText Transfer Protocol
IDE Integrated Development Environment IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol
ISDB-T Integrated Services Digital Broadcasting - Terrestrial ISO International Organization for Standardization
ISOBMFF ISO Base Media File Format JTC1 Joint Technical Committee 1 LDC Low Delay Consumption LLS Low-Level Layer Signalling LMTLink Mapping Table
LR License Revocation LS License Signalling
MC Measurement Configuration MFU Media Fragment Unit MMT MPEG Media Transport
MMTP MPEG Media Transport Protocol MPD Media Presentation Description MPEG Moving Picture Experts Group MPI MMT Presentation Information MPT MMT Package Table
MPU Media Processing Units
NAL Network Abstraction Layer
NAM Network Abstraction for Media
NAMF Network Aware Media Feedback
NTP Network Time Protocol
PA Package Access PCAP Packet CAPture PI Presentation Information PLP Physical Layer Pipe QoS Quality of Service RF Radio Frequency
ROUTE Real-Time Object delivery over Unidirectional Transport RQF Reception Quality Feedback
RTP Real Time Protocol RRT Rating Region Table SAP Stream Access Point
SBTVD Sistema Brasileiro de Televis˜ ao Digital SC29 Sub Committee 29
SHV Super High Vision SLS Service Layer Signalling SLT Service List Table
SSWR Security Software Request
STLTP Studio to Transmitter Link Tunneling Protocol TCP Transmission Control Protocol
T&M - Timing and Management TS Transport Stream
UDP User Datagram Protocol
USBD User Service Bundle Description
WG11 Work Group 11
Sum´ ario
1 INTRODUC¸ ˜AO 1
1.1 Objetivos . . . . 3
1.2 Justificativa . . . . 4
1.3 Metodologia . . . . 5
1.4 Estrutura e organiza¸c˜ ao do trabalho . . . . 5
2 MMT 6
2.1 Arquitetura e Modelo MMT . . . . 6
2.1.1 Modelo de dados MMT . . . . 8
2.2 Unidade de Processamento de M´ıdia - MPU . . . . 9
2.3 Informa¸c˜ ao de Composi¸c˜ ao - CI . . . . 10
2.4 Caracter´ısticas de Entrega de Assets - ADC . . . . 11
2.5 Encapsulamento da MPU . . . . 12
2.6 Payload MMT . . . . 13
2.7 Protocolo MMTP . . . . 16
2.8 Corre¸c˜ ao de Erros AL-FEC . . . . 20
2.9 Interface de Camada Cruzada - CLI . . . . 21
2.10 Sinaliza¸c˜ ao . . . . 22
2.10.1 Mensagens de sinaliza¸c˜ ao para consumo . . . . 22
2.10.2 Mensagens de sinaliza¸c˜ ao para entrega . . . . 23
2.11 Modelo de Buffer do Receptor Hipot´ etico - HRBM . . . . 26
3 ATSC 3.0 27
3.1 Modelo Conceitual de Servi¸cos . . . . 27
3.2 Redistribui¸c˜ ao . . . . 27
3.3 Sinaliza¸c˜ ao . . . . 28
3.3.1 Camada de Sinaliza¸c˜ ao de Servi¸cos - SLS (Service Layer Signaling) 28 3.3.2 Sinaliza¸c˜ ao de Baixo N´ıvel (Low Level Signaling - LLS ) . . . . 29
3.3.3 Sinaliza¸c˜ ao de Camada do Servi¸co (Service Layer Signaling - SLS) . 30 3.3.4 Protocolo de Tunelamento Circuito Est´ udio ao Transmissor (Studio to Transmitter Link Tunneling Protocol - STLTP) . . . . 32
4 DESENVOLVIMENTO DO ANALISADOR 36
4.1 Materiais e M´ etodos . . . . 36
4.2 Processo fim-a-fim: do encapsulamento MMT ` a transmiss˜ ao ATSC 3.0 . . . 38
4.3 Ferramentas de Software . . . . 58
4.4 Fases do Desenvolvimento . . . . 59
4.5 Aplica¸c˜ oes . . . . 59
4.6 Resultados . . . . 59
5 CONCLUS ˜AO 69
5.1 Trabalhos Futuros . . . . 69
5.2 Artigos Publicados . . . . 70
REFERˆENCIAS BIBLIOGR ´AFICAS 71
1 INTRODUC ¸ ˜ AO
Um sistema de TV por radiodifus˜ ao se comp˜ oe dos equipamentos de gera¸c˜ ao localiza- dos nas produtoras de programa¸c˜ ao (por exemplo as emissoras de TV), dos distribuidores de conte´ udo/retransmissores (ex.: operadoras de TV a cabo), dos meios de transmiss˜ ao (propaga¸c˜ ao terrestre a´ erea, terrestre por cabo ou via sat´ elite) e dos receptores (terminais de usu´ arios).
As cˆ ameras de est´ udio, microfones e mesas de edi¸c˜ ao, localizadas nas emissoras, geram os sinais audiovisuais, os quais ser˜ ao posteriormente processados para transmiss˜ ao remota aos usu´ arios finais.
Ao sinal de banda base, com alta taxa de bits originariamente gerada, s˜ ao aplicadas t´ ecnicas de compress˜ ao de dados, para melhor eficiˆ encia no armazenamento e na trans- miss˜ ao do ´ audio/v´ıdeo. Tal compress˜ ao ´ e realizada pelos elementos conhecidos como CODEC’s - COdificadores/DECodificadores, que reduzem a largura de banda na trans- miss˜ ao e otimizam a espectro de frequˆ encias ocupado pelos respectivos sinais. Para des- compress˜ ao, na outra extremidade ´ e utilizado tamb´ em o mesmo tipo de CODEC que efetuar´ a a decodifica¸c˜ ao dos sinais de som e imagem nos receptores dos usu´ arios.
Dentre os v´ arios padr˜ oes de compress˜ ao conhecidos, se destacam o MPEG-4 AVC/H.264 (MPEG-4 Advanced Video Coding ) e MPEG-H HEVC/H.265 (MPEG-H High Efficiency Video Coding) para codifica¸c˜ ao de v´ıdeo, al´ em do MPEG-4 AAC (MPEG-4 Advanced Au- dio Coding), MPEG-H Part 3 (3D Audio) e o Dolby Atmos, para compress˜ ao dos sinais de ´ audio. Os padr˜ oes MPEG-4 AVC/H.264 e MPEG-4 AAC, desenvolvidos pelo grupo de padroniza¸c˜ ao MPEG (Moving Picture Experts Group), s˜ ao muito empregados para transmiss˜ ao de TV de alta defini¸c˜ ao HDTV (High Definition TeleVision ) e tamb´ em s˜ ao utilizados no SBTVD (Sistema Brasileiro de Televis˜ ao Digital).
Ap´ os este processamento inicial do conte´ udo audiovisual, as informa¸c˜ oes devem ser
encapsuladas em estruturas de dados que forne¸cam suporte para transmiss˜ ao pelas re-
des de transporte at´ e o terminal de recep¸c˜ ao. Tais estruturas s˜ ao especificadas pelos
protocolos que padronizam os metadados que s˜ ao adicionados ao fluxos de dados (por
exemplo: cabe¸calhos, algoritmos de recupera¸c˜ ao de erros e formata¸c˜ ao de apresenta¸c˜ ao
dos conte´ udos) para transporte dos sinais multim´ıdia. Estes protocolos s˜ ao estruturados
em camadas, de maneira que cada camada na pilha de protocolos, realize fun¸c˜ oes bem espec´ıficas no tratamento das informa¸c˜ oes e sejam espelhadas em ambas pontas do canal de transporte (transmissores e receptores) para tr´ afego eficiente e acurado do conte´ udo.
Finalmente, este fluxo codificado de dados, ´ e repassado ` as camadas inferiores da pilha de protocolos, que adequam os respectivos sinais para entrega ` as interfaces f´ısicas dos circuitos el´ etricos respons´ aveis, pela modula¸c˜ ao e amplifica¸c˜ ao do sinal de radiofrequˆ encia (RF) para propaga¸c˜ ao atrav´ es das antenas de transmiss˜ ao no caso de transmiss˜ oes a´ ereas por radiodifus˜ ao terrestre, ou para transmiss˜ ao via cabos de fibras ´ opticas.
Na Europa e Estados Unidos as transmiss˜ oes comerciais de televis˜ ao digital se ini- ciaram em 1998 (DVB, 2013), (WIRED, 2017), (AKAMINE et al., 2006), enquanto no Jap˜ ao, a opera¸c˜ ao comercial teve in´ıcio em 2003 (YAMAZAKI; FUJII; ITAMI, 2005). Os primeiros servi¸cos de transmiss˜ ao de TV digital nos Estados Unidos utilizaram o padr˜ ao ATSC (Advanced Television Standards Comittee) que disponibilizou uma qualidade su- perior de ´ audio e v´ıdeo aos usu´ arios. Outros padr˜ oes foram propostos e adotados pelo mundo, como por exemplo o DVB (Digital Video Broadcasting ) na Europa e o ISDB-T (Integrated Services Digital Broadcasting - Terrestrial ) no Jap˜ ao. O Brasil iniciou os es- tudos da escolha de padr˜ ao para TV digital em 1994 e optou pelo desenvolvimento de um sistema pr´ oprio baseado no modelo japonˆ es, o qual foi nomeado IDSB-Tb. Todos estes padr˜ oes possuem em comum a utiliza¸c˜ ao do MPEG-2 System (ISO/IEC 13818-1, 2015) como suporte para transporte dos dados de ´ audio, v´ıdeo, aplica¸c˜ oes e guias de programa¸c˜ ao eletrˆ onica de TV.
O MPEG-2 TS (MPEG-2 Transport Stream ) se mostrou eficiente na transmiss˜ ao de
sinais de televis˜ ao por radiodifus˜ ao terrestre, cabo e sat´ elite, entretanto com o advento
e dissemina¸c˜ ao da rede Internet, surgiram novas tecnologias e aplica¸c˜ oes de tr´ afego mul-
tim´ıdia (dados, som e imagem) que permitiram a disponibilidade de servi¸cos sob demanda
de transmiss˜ ao de filmes e at´ e mesmo programa¸c˜ ao de TV via web. Todavia, devido ` as
caracter´ısticas intr´ınsecas do tr´ afego transmitido pelas redes baseadas no protocolo IP
(Internet Protocol ) (utilizado na web), tais como latˆ encia, taxa de erros e jitter (varia¸c˜ ao
no atraso de propaga¸c˜ ao), se fez necess´ ario o estudo de um novo protocolo de transporte
que se adaptasse melhor a estas restri¸c˜ oes, e tamb´ em que permitisse a integra¸c˜ ao das
redes de radiodifus˜ ao (broadcast ) e banda-larga (broadband) para distribui¸c˜ ao de servi¸cos
multim´ıdia.
Ent˜ ao surgiram diversas propostas para desenvolvimento de uma nova plataforma de servi¸cos (chamada de rede nova gera¸c˜ ao) que suportasse a transmiss˜ ao de informa¸c˜ oes multim´ıdia de forma integrada e h´ıbrida, ou seja, com o aproveitamento das melhores possibilidades de tr´ afego de cada uma das redes, simultaneamente e otimizada para uma variedade de dispositivos de recep¸c˜ ao (terminais de TV, computadores de mesa, tablets e telefones inteligentes), propiciando assim uma experiˆ encia de qualidade superior ao usu´ ario final.
Dentre estas propostas, o MMT (MPEG Media Transport ) se apresenta como um forte candidato a padr˜ ao universal das redes de TV digital de nova gera¸c˜ ao, j´ a que foi adotado para utiliza¸c˜ ao nos EUA (novo padr˜ ao ATSC 3.0) (YIM et al., 2016), (PARK; LIM; SUH, 2016), na Europa (DVB-S2) (DVB, 2013) e Jap˜ ao sistema SHV (Super High Vision ) (NHK, 2011), (YAMASHITA et al., 2012). Nos Estados Unidos, o ATSC 3.0 definiu o MMT como complementar ao protocolo ROUTE/DASH (Real-Time Object delivery over Unidirectional Transport/Dynamic Adaptive Streaming over HTTP) (WALKER et al., 2016).
A primeira vers˜ ao do padr˜ ao MMT foi publicada em Junho de 2014 e revisada em Agosto de 2017 pela ISO/IEC - JTC1 - SC 29/WG11 (International Organization for Standardization / International Electrotechnical Commission - Joint Technical Committee 1 - Sub Committee 29/Work Group 11 ) (ISO/IEC 23008-1, 2017).
Apesar da publica¸c˜ ao desta norma ISO, as implementa¸c˜ oes do padr˜ ao MMT ainda se encontram em fase inicial de desenvolvimento, devido principalmente ao elevado custo e forte impacto envolvidos na migra¸c˜ ao dos sistemas de transmiss˜ ao de TV digital em opera¸c˜ ao.
1.1 Objetivos
Considerando o contexto mencionado na Introdu¸c˜ ao, esta disserta¸c˜ ao visa analisar as novas funcionalidades disponibilizadas pelo padr˜ ao MMT para transmiss˜ ao de TV digital, atrav´ es da implementa¸c˜ ao de um analisador de protocolo espec´ıfico para este padr˜ ao.
Esta implementa¸c˜ ao foi realizada a partir do desenvolvimento de um programa es-
crito em linguagem C, e integrado como um m´ odulo complementar ao software Open Source Wireshark, largamente empregado nas atividades de an´ alise de pacotes e fluxos de protocolos.
Tamb´ em foi utilizado um ambiente de transmiss˜ ao e recep¸c˜ ao de sinais de TV digital no padr˜ ao ATSC 3.0, para gera¸c˜ ao e an´ alise do fluxo de testes do analisador proposto neste trabalho.
1.2 Justificativa
Ao se apresentar um analisador para o protocolo MMTP (MPEG Media Transport Protocol), baseado num pacote de software de licen¸ca aberta, se oferece uma op¸c˜ ao sem custo para an´ alise nas atividades de teste das funcionalidades do novo padr˜ ao MMT (ISO/IEC 23008-1, 2017), ampliando assim o suporte para o desenvolvimento de novas aplica¸c˜ oes de TV digital, baseadas nas seguintes caracter´ısticas:
(a) Servi¸cos h´ıbridos (broadcast/broadband ) - conte´ udos multim´ıdia (v´ıdeo/´ audio/dados) que possam ser transmitidos simultaneamente pelas redes de radiodifus˜ ao terrestre de TV digital e pela Internet (redes banda-larga baseadas no protocolo IP), com consequente otimiza¸c˜ ao na utiliza¸c˜ ao integrada nestas redes;
(b) Personaliza¸c˜ ao de conte´ udo/an´ uncios - programa¸c˜ ao personalizada pode ser dispo- nibilizada ao usu´ ario final do servi¸co, assim como as emissoras de TV podem inserir an´ uncios exclusivos e direcionados de acordo com o perfil consumidor do telespec- tador.
(c) Sincronismo na reprodu¸c˜ ao de m´ıdias em diferentes dispositivos - torna poss´ıvel oferecer o mesmo conte´ udo em tempo real n˜ ao somente para os receptores de TV, mas tamb´ em para equipamentos m´ oveis tais como: tablets, smartphones e terminais port´ ateis de televis˜ ao;
(d) Possibilidade de escolha multi-cˆ ameras - com esta nova tecnologia, o usu´ ario pode
assistir as imagens transmitidas sob v´ arios ˆ angulos de vis˜ ao, ou seja, alternando a
recep¸c˜ ao entre cˆ ameras localizadas em pontos distintos na gera¸c˜ ao do sinal de TV;
(e) Melhor qualidade de v´ıdeo e ´ audio - devido ao menor overhead (dados adicionais de controle na transmiss˜ ao) do protocolo MMTP, ´ e oferecido um payload (carga ´ util de informa¸c˜ ao) maior comparado ao protocolo MPEG-2 TS, considerando-se a mesma largura de banda.
Paralelamente, este trabalho pode tamb´ em contribuir na defini¸c˜ ao de novos padr˜ oes dos protocolos de transporte para evolu¸c˜ ao do SBTVD – rede de nova gera¸c˜ ao.
1.3 Metodologia
Para avaliar a potencialidade deste novo padr˜ ao, foi pesquisada e analisada a lite- ratura dispon´ıvel em publica¸c˜ oes especializadas, tais como artigos cient´ıficos da IEEE - Institute of Electrical and Electronics Engineers (Instituto dos Engenheiros Eletricis- tas e Eletrˆ onicos) e principalmente a norma internacional que definiu o sistema MMT - ISO/IEC 23008-1 (2017).
A partir do estudo citado, foi desenvolvido um procedimento complementar a um software de dom´ınio p´ ublico (licen¸ca Open-Source) para an´ alise do protocolo MMTP.
1.4 Estrutura e organiza¸ c˜ ao do trabalho
Na Se¸c˜ ao 2, ´ e apresentado todo o arcabou¸co t´ ecnico de suporte para compreens˜ ao dos conceitos definidos pelo padr˜ ao MMT, contemplando sua arquitetura e modelo da pilha de protocolos, assim como o formato do protocolo MMTP, esquema de corre¸c˜ ao de erros, apresenta¸c˜ ao de conte´ udo e mensagens de sinaliza¸c˜ ao. E na Se¸c˜ ao 3, uma breve descri¸c˜ ao do sistema ATSC 3.0 e algumas caracter´ısticas relacionadas a esta disserta¸c˜ ao.
Na Se¸c˜ ao 4, s˜ ao abordadas os materiais e m´ etodos aplicados neste trabalho, assim como um exemplo com detalhamento completo do processo de fim-a-fim, abrangendo desde o encapsulamento do protocolo MMT at´ e a efetiva transmiss˜ ao via interface a´ erea utili- zando o padr˜ ao ATSC 3.0. A seguir s˜ ao apresentadas as ferramentas e t´ ecnicas utilizadas no desenvolvimento, as suas diversas fases e os resultados alcan¸cados na implementa¸c˜ ao do analisador, escopo desta disserta¸c˜ ao.
E encerrando na Se¸c˜ ao 5 s˜ ao apresentadas as considera¸c˜ oes finais.
2 MMT
Inicialmente ´ e apresentado o modelo estrutural definido no padr˜ ao MMT (ISO/IEC 23008-1, 2017) e ent˜ ao, a seguir s˜ ao detalhados cada um dos componentes da arquitetura da camada de transporte e entrega de tr´ afego multim´ıdia em redes h´ıbridas.
2.1 Arquitetura e Modelo MMT (´ areas funcionais, ferramentas e interfaces) (ISO/IEC 23008-1, 2017)
O padr˜ ao MMT foi proposto para definir os requisitos da entrega de servi¸cos de TV digital, com suporte para multiplexa¸c˜ ao de diversos fluxos de m´ıdias codificadas (ex.:
´
audio, v´ıdeo e aplica¸c˜ oes), a partir do transporte em redes h´ıbridas de radiodifus˜ ao terres- tre/sat´ elite e redes banda larga baseadas no protocolo IP (ex.: Internet, TV por assinatura a cabo ou Video sob-demanda) (LIM et al., 2013).
A arquitetura MMT proposta pela ISO est´ a dividida em 3 ´ areas funcionais: for- mata¸c˜ ao da unidade de processamento de m´ıdia, entrega e sinaliza¸c˜ ao, conforme descrito na Figura 1.
Figura 1: Pilha de protocolos MMT.
Fonte: Traduzido do Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
A ´ area de formata¸c˜ ao da unidade de processamento de m´ıdia abrange as ferramentas que encapsulam as m´ıdias codificadas de ´ audio e v´ıdeo, al´ em das que propiciam a sin- croniza¸c˜ ao e ordenamento da apresenta¸c˜ ao das informa¸c˜ oes nos dispositivos de sa´ıda do usu´ ario.
Neste m´ odulo ´ e definida a estrutura l´ ogica do conte´ udo de m´ıdia, o formato do Package e das unidades de dados baseadas no padr˜ ao ISOBMFF (ISO Base Media File Format), especificado na norma ISO/IEC 14496-12 (2008).
O Package define o conjunto das componentes de encapsulamento dos conte´ udos de m´ıdia e o relacionamento entre estas componentes, para armazenar e entregar os conte´ udos de forma flex´ıvel e avan¸cada, tal que, seja facilitada tamb´ em a convers˜ ao entre os dados de armazenamento e entrega.
O padr˜ ao MMT tamb´ em se baseia em padr˜ oes j´ a conhecidos e amplamente utilizados na Internet, como por exemplo a linguagem de marca¸c˜ ao para hipertextos HTML5 (Hyper Text Markup Language - version 5 ), que suporta a apresenta¸c˜ ao do conte´ udo na camada de aplica¸c˜ ao.
Na ´ area funcional de entrega s˜ ao propostos um novo protocolo de transporte e entrega para a camada de aplica¸c˜ ao, chamado de MMTP - MPEG Media Transport Protocol, assim como o respectivo formato de payload (carga ´ util de informa¸c˜ ao) para este protocolo. O MMTP possui novas funcionalidades que suportam a multiplexa¸c˜ ao de v´ arios Packages e o transporte simultˆ aneo de streamings (conte´ udos de m´ıdia) e o download de arquivos no mesmo fluxo de dados.
E finalmente, esta nova norma ISO padroniza na ´ area funcional de sinaliza¸c˜ ao, a for-
mata¸c˜ ao de mensagens para gerenciamento da entrega e consumo dos dados de m´ıdia. As
mensagens de consumo s˜ ao utilizadas para sinalizar a estrutura de Package e as mensagens
de entrega, para configurar as opera¸c˜ oes do protocolo MMTP e sinaliza¸c˜ ao da estrutura
do payload MMT, provendo mecanismos de corre¸c˜ ao de erros atrav´ es do esquema AL-FEC
(Application Layer - Forward Error Correction ).
2.1.1 Modelo de dados MMT (ISO/IEC 23008-1, 2017)
Logicamente o modelo MMT se estrutura em macro-unidades chamadas Packages (pacotes de fluxo dos dados), as quais s˜ ao compostas por:
Um ou mais Assets, ou seja, itens contendo m´ıdias codificadas de conte´ udo, tais como
´
audio, v´ıdeo ou p´ aginas web, com carater´ısticas temporizadas ou n˜ ao-temporizadas (que exigem ou n˜ ao sincronismo na decodifica¸c˜ ao e apresenta¸c˜ ao dos respectivos conte´ udos). Cada Asset ´ e um agrupamento l´ ogico de MPU’s (Media Processing Units ) que compartilham o mesmo n´ umero de identifica¸c˜ ao de Asset (Asset ID);
Um ou mais ADC´s (Asset Delivery Characteristics), descritores de entrega de Assets (um ADC para cada respectivo Asset ), que indicam as caracter´ısticas de QoS (Quality of Service) de cada servi¸co para sinaliza¸c˜ ao ` as camadas inferiores de rede para transmiss˜ ao eficiente dos dados;
e um documento de Informa¸c˜ ao de Apresenta¸c˜ ao (PI - Presentation Information), que especifica a rela¸c˜ ao temporal e espacial entre os diversos Assets para consumo.
Este item ´ e detalhado na norma ISO/IEC 23009-1 (2014), que apresenta formatos de documentos PI, como por exemplo a associa¸c˜ ao de documentos HTML5 e CI’s (Composition Information) ou a utiliza¸c˜ ao de MPD’s (Media Presentation Descrip- tion ) especificada na norma ISO/IEC 23008-11 (2017).
A estrutura l´ ogica do Package MMT ´ e apresentada na Figura 2.
Figura 2: Estrutura do Package.
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
2.2 Unidade de Processamento de M´ıdia - MPU (Media Pro- cessing Unit )
A MPU ´ e um item que pode, independentemente de outras MPU’s, ser processado por uma entidade MMT (transmissora ou receptora) e consumida por um dispositivo de apresenta¸c˜ ao. O processamento de uma entidade MMT pode ser do tipo :
encapsulamento: forma¸c˜ ao do payload MMT a partir dos dados de m´ıdia codificados no padr˜ ao ISOBMFF, efetuado na entidade transmissora;
desencapsulamento: extra¸c˜ ao dos fluxo de m´ıdia codificada no padr˜ ao ISOBMFF, que ocorre na entidade receptora;
empacotamento: formata¸c˜ ao do pacote de protocolo MMTP para transmiss˜ ao do payload MMT;
desempacotamento de dados: recomposi¸c˜ ao do payload MMT, atrav´ es da decodi- fica¸c˜ ao na entidade de recep¸c˜ ao, dos pacotes transportados pelo protocolo MMTP.
As atividades de consumo incluem o processamento de m´ıdia (codifica¸c˜ ao e decodi- fica¸c˜ ao) e a apresenta¸c˜ ao dos conte´ udos de m´ıdia.
Cada MPU pode ser subdividida em sub-unidades chamadas MFU´s (Media Fragment Unit), ou seja, unidades menores que uma unidade de acesso - AU (Access Unit ), permi- tindo assim que a entidade transmissora possa realizar fragmenta¸c˜ ao dos dados enviados.
A sintaxe e semˆ antica da formata¸c˜ ao de cada MPU n˜ ao depende do tipo de m´ıdia transportado pela MPU, que pode conter dados formatados em outros padr˜ oes, tais como:
MPEG-4 AVC ou MPEG-2 TS.
Uma MPU deve transportar unidades integrais de AU’s, implicando que uma AU n˜ ao pode ser fragmentada em m´ ultiplas MPU’s para tr´ afegos de m´ıdias temporizadas. As m´ıdias n˜ ao-temporizadas tamb´ em deve ser transportadas em MPU’s com um ou mais itens de dados n˜ ao-temporizados para consumo dos dispositivos de apresenta¸c˜ ao.
A MPU ´ e identificada pelo par: Asset ID com seu respectivo n´ umero de sequˆ encia,
e quando envolver o tr´ afego de m´ıdias temporizadas, deve conter no m´ınimo um SAP
(Stream Access Point ), definido conforme norma ISO/IEC 14496-12 (2008).
O padr˜ ao MMT define um novo tipo de
boxISOBMFF espec´ıfico para arquivos que contenham MPUs: ”mmpu”, que cont´ em o identificador do Asset ao qual o respectivo MPU pertence - Asset ID) e tamb´ em informa¸c˜ oes adicionais deste MPU, com por exemplo o n´ umero de sequencia da MPU dentro do Asset (mpu sequence number).
O
boxmmpu tamb´ em pode ser utilizado para sinalizar se a MPU cont´ em ou n˜ ao todas as amostras de m´ıdia e MFUs, atrav´ es do
flagic (is complete) e a presen¸ca de um ADC dentro da MPU, com o
flagiap (is adc present).
O formato completo do
boxmmpu ´ e mostrado na Figura 3.
Figura 3: Formato do
boxmmpu.
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
Com esta estrutura o MMT oferece suporte ` a multiplexa¸c˜ ao de Assets, al´ em da agrega¸c˜ ao e fragmenta¸c˜ ao de MPU’s.
2.3 Informa¸ c˜ ao de Composi¸ c˜ ao - CI (ISO/IEC 23008-1, 2017)
A CI determina a rela¸c˜ ao espacial e temporal para utiliza¸c˜ ao das m´ıdias na recep¸c˜ ao, indicando a localiza¸c˜ ao e ordem da apresenta¸c˜ ao de cada conte´ udo na tela.
Ela ´ e transmitida atrav´ es das mensagens de sinaliza¸c˜ ao ou ent˜ ao integralmente num
´
unico arquivo no formato HTML5. A CI pode tamb´ em realizar o mapeamento do conte´ udo de uma tela para um ambiente de multi-telas.
Estruturalmente uma CI se comp˜ oe de uma regi˜ ao total da tela chamada View, a
qual ´ e subdivida em regi˜ oes chamadas Areas que cont´ em os Assets de m´ıdia, conforme
mostrado na Figura 4.
Figura 4: Diagrama de um Asset/Area/View.
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
2.4 Caracter´ısticas de Entrega de Assets - ADC (ISO/IEC 23008- 1, 2017)
Os ADC’s s˜ ao descri¸c˜ oes escritas em extens˜ oes da linguagem HTML5, contendo ele- mentos que descrevem os requerimentos e estat´ısticas de QoS dos Assets para entrega.
Eles podem ser descritores do tipo:
Descritores de QoS que definem os parˆ ametros de atraso e perda requeridos na entrega do servi¸co, que s˜ ao descritos pelos atributos: loss tolerance, jitter sensitivity, class of service e bidirection indicator ou;
Descritores de fluxos de bits (bitstreams ) que informam as estat´ısticas necess´ arias para controle de tr´ afego na entrega, os quais proveem parˆ ametros para imple- menta¸c˜ ao da pol´ıtica de tr´ afego modelo ”token bucket ”, como por exemplo: taxa sustent´ avel, tamanho de buffer, taxa de pico e tamanho m´ aximo de MFU, entre outros.
Na Figura 5, ´ e apresentado um exemplo de ADC.
Figura 5: Exemplo de um ADC.
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
2.5 Encapsulamento da MPU (ISO/IEC 23008-1, 2017)
Cada MPU ´ e encapsulada num arquivo formatado no padr˜ ao ISOBMFF, descrito na norma ISO/IEC 14496-12 (2008). Assim, o n´ umero de sequˆ encia e o Asset ID s˜ ao forne- cidos no campo ”mmpu”para identifica¸c˜ ao da MPU encapsulada neste arquivo. O campo
”sidx”pode ser utilizado para indexa¸c˜ ao dos fragmentos de MPU para m´ıdia temporizada.
Os campos ”ftyp”, ”styp”e ”moov”s˜ ao utilizados como dados de inicializa¸c˜ ao do arquivo.
O campo ”moov”deve tamb´ em conter todas as informa¸c˜ oes de configura¸c˜ ao do CO- DEC para decodifica¸c˜ ao e apresenta¸c˜ ao dos dados de m´ıdia da MPU. Dados de m´ıdia tem- porizada s˜ ao armazenados como uma ´ unica ”trak”(sub-campo trilha de m´ıdia no campo
”mdat”), enquanto as m´ıdias n˜ ao-temporizadas s˜ ao inseridas como parte do campo me- tadados no arquivo ISOBMFF.
Para o empacotamento de arquivos de m´ıdia temporizada, ´ e ainda inclu´ıdo o campo
”MMT hint track ”para fornecer as informa¸c˜ oes necess´ arias ao desencapsulamento da MPU
em formatos de payload e pacotes MMTP para transmiss˜ ao.
O MMT hint track, provˆ e tamb´ em as informa¸c˜ oes para fragmenta¸c˜ ao de uma MPU em sub-unidades MFU’s (Media Fragment Units), que s˜ ao amostras ou sub-amostras de m´ıdia, e s˜ ao compostas de um cabe¸calho e os respectivos dados de m´ıdia.
A estrutura do encapsulamento de MPU, ´ e ilustrada na Figura 6.
Figura 6: Encapsulamento de MPU. (a) M´ıdia temporizada, (b) M´ıdia n˜ ao-temporizada.
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
2.6 Payload MMT (ISO/IEC 23008-1, 2017)
O payload MMT ´ e definido como um formato gen´ erico empregado para empacota- mento e transporte de dados de m´ıdia, como MPU’s, objetos gen´ ericos e outras in- forma¸c˜ oes para consumo de um Package utilizando o protocolo MMTP. Este formato se aplica principalmente para transmiss˜ ao utilizando o protocolo MMT, por´ em como ele
´ e independente do tipo de CODEC das m´ıdias componentes, qualquer fluxo de dados
encapsulado no formato de MPU’s pode ser empacotado, segundo esse tipo de payload.
Assim al´ em do protocolo MMT, este payload pode ser transportado atrav´ es de outros protocolos de entrega de m´ıdia, como por exemplo, o RTP (Real Time Protocol ). Ele pode ser utilizado para empacotamento de MPU’s, mensagens de sinaliza¸c˜ ao e s´ımbolos de reparo para controle de erros – s´ımbolos FEC(Forward Error Correction).
Cada MPU ´ e mapeada como uma unidade de dados DU (Data Unit ) no payload MMT. E m´ ultiplas DU’s com o mesmo Asset ID podem ser agregadas num ´ unico payload, assim como uma ´ unica DU pode ser fragmentada em m´ ultiplos payloads. O tamanho de cabe¸calho do payload MMT ´ e fixo, quando n˜ ao possui campo de extens˜ ao de cabe¸calho (header extension ). O campo cabe¸calho ´ e vari´ avel quando s˜ ao realizadas agrega¸c˜ oes ou fragmenta¸c˜ oes no payload. O cabe¸calho do payload varia conforme o tipo de dados a ser transportado (indicado no campo de tipo no cabe¸calho do protocolo MMTP), assim como a semˆ antica de seus respectivos campos.
Assim, o cabe¸calho do payload pode ser de 3 tipos: modo MPU, modo entrega de arquivo gen´ erico e modo mensagem de sinaliza¸c˜ ao.
A Figura 7 mostra o formato do payload para o modo MPU. Enquanto, o formato das DU’s (Data Units ) para MFU’s (Movie Fragment Units) com m´ıdia temporizadas e n˜ ao-temporizadas, s˜ ao apresentados respectivamente nas Figuras 8 e 9.
Figura 7: Estrutura do cabe¸calho de payload MMT para modo MPU.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
length FT T f i A frag counter
MPU sequence number
DU length DU header . . .
DU payload .. .
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
Figura 8: Cabe¸calho de DU para MFU com m´ıdia temporizada.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
movie fragment sequence number sample number
offset priority dep counter
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
Figura 9: Cabe¸calho de DU para MFU com m´ıdia n˜ ao-temporizada.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
item ID
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
E finalmente, nas Figuras 10 e 11, pode-se visualizar as estruturas de cabe¸calho de payload, para os modos GFD (Generic File Delivery ) e de mensagens de sinaliza¸c˜ ao, respectivamente.
Figura 10: Estrutura do cabe¸calho de payload MMT para modo GFD.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
C L B CP RES TOI
TOI start offset
start offset
Generic File Delivery payload
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
Figura 11: Estrutura do cabe¸calho de payload MMT para modo mensagem de sinaliza¸c˜ ao.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
f i res H A frag counter MSG length (16+16*H) MSG payload
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
2.7 Protocolo MMTP (ISO/IEC 23008-1, 2017)
O protocolo MMTP (MPEG Media Transport Protocol ) ´ e um protocolo de camada de aplica¸c˜ ao projetado para entrega confi´ avel e eficiente de pacotes de m´ıdia, os cha- mados Packages. Ele foi desenhado para suportar tr´ afegos de m´ıdias temporizadas e n˜ ao-temporizadas, com multiplexa¸c˜ ao de fluxos, c´ alculo de jitter de rede baseado em amostras temporais (timestamps) e indica¸c˜ ao de requerimentos de QoS, caracter´ısticas estas essenciais para transporte e entrega dos v´ arios tipos de m´ıdias.
O MMTP pode ser transportado sobre protocolos existentes, tais como UDP (User Datagram Protocol) e IP nas camadas inferiores de rede, com cada pacote MMTP podendo transportar um ´ unico payload MMT. A fragmenta¸c˜ ao e agrega¸c˜ ao de payloads s˜ ao meca- nismos providos apenas atrav´ es dos formatos de cabe¸calhos dos pr´ oprios payloads, e por- tanto n˜ ao s˜ ao especificados no MMTP. O padr˜ ao MMT tamb´ em n˜ ao especifica o suporte ao controle de congestionamento do tr´ afego, que ´ e delegado aos aplicativos/protocolos de camadas de rede da entidade de transmiss˜ ao. Por´ em, o protocolo MMTP suporta a multiplexa¸c˜ ao dos dados de m´ıdia e mensagens de sinaliza¸c˜ ao no mesmo fluxo de pacotes MMTP.
O protocolo prevˆ e ainda suporte ` a prioriza¸c˜ ao de tr´ afego, nas camadas inferiores e nos elementos intermedi´ arios de rede, atrav´ es do mapeamento das informa¸c˜ oes dos cam- pos de prioridade do cabe¸calho MMTP, tais como: type of bitrate, sensitivity, tranmis- sion priority e flow label. Por exemplo, com uso de DiffServ (Differentiated Services - IETF RFC 2474) pode ser realizado o mapeamento dos 6 bits de valores DSCP (Differen- tiated Services Code Point) – campo DS do cabe¸calho IP, para a informa¸c˜ ao de prioriza¸c˜ ao definida no cabe¸calho do protocolo MMTP.
S˜ ao tamb´ em oferecidos meios para c´ alculo e remo¸c˜ ao do jitter introduzido pelas cama- das inferiores de rede, de forma que possa ser alcan¸cado um delay constante fim-a-fim na entrega dos pacotes. Atrav´ es da introdu¸c˜ ao do campo de timestamp no cabe¸calho MMTP, o jitter pode ser facilmente calculado, sem a necessidade de protocolos e informa¸c˜ oes adi- cionais de sinaliza¸c˜ ao.
Para empacotamento de uma MPU que contenha dados de m´ıdia temporizada, o
padr˜ ao MMT definiu no cabe¸calho MMTP, o campo tipo que relaciona diretamente a
modo de formata¸c˜ ao espec´ıfica do payload, e um campo de 2 bits (V) que indica o n´ umero de vers˜ ao do protocolo. Este ´ ultimo campo deve ser preenchido com o valor ”00”para compatibilidade com a norma ISO/IEC 23008-1 (2017), ou com o valor ”01”para suporte de QoS (Quality of Service). Nas Figuras 12 e 13, se encontram as estruturas do pacote MMTP(incluindo cabe¸calho, payload e complemento) respectivamente para V=0 e V=1.
Figura 12: Estrutura do pacote MMTP (V=0).
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
V=0 C FEC r X R RES type packet id
timestamp
packet sequence number packet counter header extension
payload data source FEC payload ID
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
Figura 13: Estrutura do pacote MMTP (V=1).
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
V=1 C FEC X R Q F E B I type packet id
timestamp
packet sequence number packet counter
r TB DS TP flow label extension header
payload data source FEC payload ID
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
A sintaxe dos campos do protocolo MMT, para a vers˜ ao 01, s˜ ao listadas a seguir:
V (VERSION NUMBER OF PROTOCOL): 00, 01 suporte a QoS;
C (PACKET COUNTER FLAG): 1-habilitado;
FEC (FEC TYPE): 0-Sem FEC, 1- pacote com identifica¸c˜ ao do payload FEC na origem – source FEC payload ID, 2- pacote de reparo FEC Modo 0, 3- pacote de reparo FEC Modo 1;
X (EXTENSION FLAG): 1- campo Header extension – extens˜ ao de cabe¸calho est´ a presente;
R (RAP FLAG): 1-Payload cont´ em um RAP(Random Access Point );
Q (QOS CLASSIFIER FLAG): 1-informa¸c˜ ao de QoS ´ e utilizada;
F (FLOW IDENTIFIER FLAG): 1-indica a presen¸ca do identificador de fluxo no pacote;
E (FLOW EXTENSION FLAG): 1-Mais do que 127 fluxos individuais + 1 byte no extension header ;
B (COMPRESSION FLAG): 0- header de tamanho m´ aximo, 1- header de tamanho reduzido;
I (INDICATOR FLAG): 1- indica que o header total deve ser usado como uma refe- rencia;
TYPE (TYPE OF PAYLOAD): 0x00- MPU, 0x01- generic object, 0x02- mensagem de sinaliza¸c˜ ao, 0x03- s´ımbolo de reparo, 0x04-3F - reservado;
PACKET ID : valor inteiro utilizado para distinguir um Asset;
TIMESTAMP : instante de entrega do pacote MMTP basedo no hor´ ario UTC – NTP vers˜ ao 4;
PACKET SEQUENCE NUMBER: valor inteiro de 32-bits usado para distinguir pa- cotes com o mesmo packet id ;
PACKET COUNTER: valor inteiro de 32-bits para contagem de pacotes MMTP;
RESERVED : reservado;
TYPE OF BITRATE : 00- taxa constante de bits, 01- taxa vari´ avel de bits, 10-11 - reservado;
DELAY SENSITIVITY : 111- conversacional, 110- fluxo ao vivo, 101- sens´ıvel a atraso,
100- interativo, 011- fluxo streaming, 010- servi¸co non-real-time, 000-001 - reservado;
TRANSMISSION PRIORITY : prioridade de transmiss˜ ao para pacote de m´ıdia, quando reliability flag = 0;
FLOW LABEL: identificador de fluxo – mapeado por opera¸c˜ ao de QoS na aplica¸c˜ ao ou atrav´ es do ADC - varia de 0 a 127;
EXTENSION HEADER: informa¸c˜ ao definida pelo usu´ ario;
PAYLOAD DATA: carga ´ util de dados;
SOURCE FEC PAYLOAD ID : campo de 32-bits usado somente com tipo de FEC = 1 para prote¸c˜ ao AL-FEC em FEC Payload ID modo 0.
E nas Tabelas 1 e 2, se apresentam os tipos de dados e respectivas unidades de dados, tamb´ em para campos de vers˜ ao igual a ”0”e ”1”.
Tabela 1: Tipos de dados e defini¸c˜ ao das unidades de dados (V=0).
Valor Tipo de dados Defini¸c˜ao da unidade de dados
0x00 MPU um fragmento formato-m´ıdia de MPU
0x01 objeto gen´ erico um objeto gen´ erico, por exemplo uma MPU completa, ou um objeto de qualquer outro tipo
0x02 mensagem de sinaliza¸c˜ ao uma ou mais mensagens de sinaliza¸c˜ ao, ou um fragmento de uma mensagem de sina- liza¸c˜ ao
0x03 s´ımbolo de reparo um s´ımbolo de reparo completo 0x04
∼0x1F reservado para uso ISO para uso ISO
0x20
∼0x3F reservado para uso privado para uso privado
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
Tabela 2: Tipos de dados e defini¸c˜ ao das unidades de dados (V=1).
Valor Tipo de dados Defini¸c˜ao da unidade de dados
0x0 MPU um fragmento formato-m´ıdia de MPU
0x1 objeto gen´ erico um objeto gen´ erico, por exemplo uma MPU completa, ou um objeto de qualquer outro tipo
0x2 mensagem de sinaliza¸c˜ ao uma ou mais mensagens de sinaliza¸c˜ ao, ou um fragmento de uma mensagem de sina- liza¸c˜ ao
0x3 s´ımbolo de reparo um s´ımbolo de reparo completo 0x4
∼0x9 reservado para uso ISO para uso ISO
0xA
∼0xF reservado para uso privado para uso privado Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
2.8 Corre¸ c˜ ao de Erros AL-FEC (ISO/IEC 23008-1, 2017)
O padr˜ ao MMT disponibiliza um mecanismo de corre¸c˜ ao posterior (ou a frente) de erros da camada de aplica¸c˜ ao chamado AL-FEC (Application Layer-Forward Error Cor- rection). Este mecanismo permite a recupera¸c˜ ao de erros pela entidade de recep¸c˜ ao a partir de s´ımbolos de corre¸c˜ ao e informa¸c˜ oes de codifica¸c˜ ao enviadas pela entidade de transmiss˜ ao do conte´ udo de m´ıdias. Ele funciona da seguinte forma:
Ap´ os empacotamento do payload MMT, estes pacotes s˜ ao enviados a um bloco respons´ avel pelo esquema FEC;
o bloco esquema FEC gera os s´ımbolos de corre¸c˜ ao FEC (baseado em algoritmos de codifica¸c˜ ao pr´ e-determinados) e as identifica¸c˜ oes dos payloads fonte e de corre¸c˜ ao FEC (source FEC payload ID e repair FEC payload ID ) e os devolve ao protocolo MMTP para transmiss˜ ao ` a entidade de recep¸c˜ ao remota;
o protocolo MMTP da entidade remota entrega recomposto individualmente, os
fluxos contendo os respectivos payloads fonte e de corre¸c˜ ao, que s˜ ao decodificados
com a mesma estrutura de c´ odigos FEC utilizada no envio. Esta informa¸c˜ ao de
configura¸c˜ ao da decodifica¸c˜ ao ´ e enviada separadamente nas mensagens espec´ıficas de sinaliza¸c˜ ao.
A entidade de transmiss˜ ao ´ e a respons´ avel pela sele¸c˜ ao dos Assets de m´ıdia (e conse- quentes pacotes MMT), aos quais ser˜ ao aplicados o mecanismo de FEC. Assim somente para este conjunto de pacotes pr´ e-selecionados na fonte, ser˜ ao transmitidos payloads adici- onais contendo s´ımbolos FEC de corre¸c˜ ao, para transporte pelos protocolos nas camadas inferiores de rede (UDP/IP). Na Figura 14, est´ a ilustrada a estrutura em blocos que mostra o processo de gera¸c˜ ao e envio do AL-FEC.
Figura 14: Arquitetura FEC no padr˜ ao MMT.
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
2.9 Interface de Camada Cruzada - CLI (ISO/IEC 23008-1, 2017)
A CLI (Cross Layer Interface ) fornece uma interface de comunica¸c˜ ao entre a ca-
mada de aplica¸c˜ ao e as camadas inferiores de rede e f´ısica, para controle da qualidade de
servi¸co (QoS). Esta interface se localiza nas entidades de comunica¸c˜ ao MMT e trocam in-
forma¸c˜ oes com as camadas inferiores em ambos sentidos. Ou seja, ocorrem comunica¸c˜ oes
da camada de aplica¸c˜ ao para as camadas inferiores (top-down ) e tamb´ em no sentido in-
verso (bottom-up). Tais informa¸c˜ oes s˜ ao abstra´ıdas, devido ` a variedade dos protocolos de transporte, utilizando-se o formato de abstra¸c˜ ao de rede para m´ıdias - NAM (Network Abstraction for Media). Segundo este modelo, as informa¸c˜ oes podem ser absolutas (abso- lute NAM ), tais como: a taxa de erros dos bits - BER (Bit Error Rate ), taxa dispon´ıvel de bits (available bitrate), utiliza¸c˜ ao de buffer (buffer fullness) ou atraso atual na rede (current delay ). Ou ainda, podem ser expressos em valores relativos (relative NAM ), como por exemplo: taxa relativa de bits (relative bitrate ), utiliza¸c˜ ao relativa de buffer (relative buffer fullness ) ou pico relativo da taxa de bits (relative peak bitrate ).
2.10 Sinaliza¸ c˜ ao (ISO/IEC 23008-1, 2017)
O padr˜ ao MMT define diversos formatos de mensagens de sinaliza¸c˜ ao para entrega e consumo de Packages. Estas mensagens podem transportar em seu conte´ udo: tabelas, descritores e informa¸c˜ oes adicionais espec´ıficas de cada tipo de sinaliza¸c˜ ao. As mensagens de sinaliza¸c˜ ao est˜ ao distribu´ıdas em dois grupos principais:
Mensagens de sinaliza¸c˜ ao para consumo;
Mensagens de sinaliza¸c˜ ao para entrega.
2.10.1 Mensagens de sinaliza¸c˜ao para consumo
Comp˜ oem este grupo, oito tipos de mensagens:
PA ( Package Access ) - mensagem para acesso ao Package;
MPI ( MMT Presentation Information ) - mensagem de PI MMT;
MPT ( MMT Package Table ) - mensagem de tabela do Package MMT;
CRI ( Clock Relation Information ) - mensagem de informa¸c˜ ao da rela¸c˜ ao de rel´ ogio;
DCI ( Device Capability Information ) - mensagem de informa¸c˜ ao da capacidade de dispositivo;
SSWR ( Security Software Request ) - mensagem de requisi¸c˜ ao do programa de
seguran¸ca;
LS ( License Signalling ) - mensagem de informa¸c˜ ao de licen¸ca;
LR ( License Revocation ) - mensagem de revoga¸c˜ ao de licen¸ca.
2.10.2 Mensagens de sinaliza¸c˜ao para entrega
Neste outro grupo, mais nove tipos de mensagens est˜ ao especificados:
HRBM ( Hypothetical Receiver Buffer Model ) - mensagem de configura¸c˜ ao do mo- delo hipot´ etico de buffer do receptor;
MC ( Measurement Configuration ) - mensagem da configura¸c˜ ao de medi¸c˜ ao;
ARQ-AC ( Automatic Repeat reQuest - ARQ Configuration ) - mensagem da con- figura¸c˜ ao de requisi¸c˜ ao repetida autom´ atica;
ARQ-AF ( Automatic Repeat reQuest - ARQ Feedback ) - mensagem do retorno de requisi¸c˜ ao repetida autom´ atica;
RQF ( Reception Quality Feedback ) - mensagem do retorno de qualidade da re- cep¸c˜ ao;
NAMF ( Network Aware Media Feedback ) - mensagem do retorno do parˆ ametro NAM : formato de m´ıdia compat´ıvel com a rede;
LDC ( Low Delay Consumption ) - mensagem de informa¸c˜ ao requerida para consumo de baixo atraso na decodifica¸c˜ ao e apresenta¸c˜ ao dos dados de m´ıdia;
HRBMR ( Hypothetical Receiver Buffer Model Removal ) - mensagem de informa¸c˜ ao para gerenciamento do buffer do HRBM: modelo hipot´ etico de buffer do receptor;
ADC ( Asset Delivery Characteristic ) - mensagem de informa¸c˜ ao para configura¸c˜ ao dos recursos de entrega na rede.
O formato geral das mensagens de sinaliza¸c˜ ao se encontra descrito na Tabela 3.
Tabela 3: Formato geral das mensagens de sinaliza¸c˜ ao MMT.
Sintaxe Valor Nº bits Mnemˆonico
signaling message ()
{message id
16 uimsbf
version
8 uimsbf
if(message id != PA message && message id !=
MPI message)
{lenght
16 uimsbf
}
else
{lenght
32 uimsbf
}
extension
message payload { }
}
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
E nas Tabelas 4 e 5, s˜ ao listados os valores de message id que identificam o tipo de mensagem.
Tabela 4: Valores de identifica¸c˜ ao de mensagem (message id).
Valores Descri¸c˜ao
0x0000 Mensagem PA 0x0001 – 0x0010 Mensagens MPI
Para um Package, s˜ ao alocados 16 valores cont´ıguos para mensagens MPI.
Se o valor ´ e igual a 16 (0x0010), a mensagem MPI transporta uma PI completa.
Se o valor ´ e igual a N, onde N = 1 a 15, a mensagem MPI transporta o Sub-conjunto (N-1) da PI.
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
Tabela 5: Valores de identifica¸c˜ ao de mensagem (message id ) - Continua¸c˜ ao.
Valores Descri¸c˜ao
0x0011 – 0x0020 Mensagens MPT
Para um Package, s˜ ao alocados 16 valores cont´ıguos para mensagens MPT.
Se o valor ´ e igual a 16 (0x0010), a mensagem MPT transporta uma MPT completa.
Se o valor ´ e igual a N, onde N = 1 a 15, a mensagem MPT transporta o Sub-conjunto (N-1) da MPT.
0x0021 – 0x01FF Reservado 0x0200 Mensagem CRI 0x0201 Mensagem DCI 0x0202 Mensagem SSWR 0x0203 Mensagem AL FEC
0x0204 Mensagem HRBM
0x0205 Mensagem MC
0x0206 Mensagem AC 0x0207 Mensagem AF 0x0208 Mensagem RQF 0x0209 Mensagem ADC
0x020A Mensagem de remo¸c˜ ao HRBM 0x020B Mensagem LS
0x020C Mensagem LR
0x020D Mensagem NAMF
0x020E Mensagem LDC
0x020F – 0x06FF Reservado para uso ISO (mensagem de comprimento de 16 bits) 0x0700 – 0x07FF Reservado para uso ISO (mensagem de comprimento de 32 bits) 0x0800 – 0x0FFF Reservado para uso privado
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
2.11 Modelo de Buffer do Receptor Hipot´ etico - HRBM (ISO/IEC 23008-1, 2017)
O HRBM (Hypothetical Receiver Buffer Model) ´ e um modelo hipot´ etico de receptor utilizado para garantir um atraso fim-a-fim constante, e tamb´ em de um limite de ocupa¸c˜ ao de mem´ oria para o armazenamento tempor´ ario (buffering ) dos pacotes entrantes MMT.
A entidade de transmiss˜ ao aplica este modelo para assegurar que qualquer opera¸c˜ ao de processamento realizada no fluxo dos pacotes MMT a serem enviados, estar´ a den- tro dos limites aceit´ aveis de recep¸c˜ ao na entidade da ponta final. Assim, a entidade de transmiss˜ ao calcula periodicamente as necessidades de atraso (delay) e tamanho do arma- zenamento intermedi´ ario (buffer ), enviando estes requerimentos ` a entidade de recep¸c˜ ao nas mensagens espec´ıficas de sinaliza¸c˜ ao.
Na entidade receptora, os buffers s˜ ao ajustados de acordo com as especifica¸c˜ oes rece- bidas. Estes buffers s˜ ao distribu´ıdos em:
buffers de decodifica¸c˜ ao FEC;
buffers de de-jitter;
buffers de desencapsulamento dos pacotes MMT.
A Figura 15, apresenta a ordem de trˆ ansito do fluxo MMT ao longo destes buffers, segundo o modelo HRBM.
Figura 15: Modelo HRBM do protocolo MMT.
Fonte: Padr˜ ao MMT (ISO/IEC 23008-1, 2017).
3 ATSC 3.0
3.1 Modelo Conceitual de Servi¸ cos (ATSC3 - A/300, 2017)
O sistema ATSC 3.0 ´ e estruturado em quatro camadas:
Aplica¸c˜ oes e Apresenta¸c˜ ao (Application and Presentation);
Gerenciamento (Management);
Protocolos (Protocols);
F´ısica (Physical).
O sistema oferece trˆ es possibilidades de servi¸cos:
(a) Programa¸c˜ ao linear tradicional;
(b) Programa¸c˜ ao linear avan¸cada - na qual pode-se ter m´ ultiplos v´ıdeos, ´ audio e close caption /subt´ıtulos que podem ser sincronizados e selecionados para apresenta¸c˜ ao no receptor e que tamb´ em pode ser enriquecida com aplica¸c˜ oes como jogos interativos or inser¸c˜ ao personalizada de an´ uncios;
(c) Servi¸cos baseados em aplica¸c˜ oes - nos quais um servi¸co pode ser iniciado a partir de uma aplica¸c˜ ao, assim como seu consumo, como por exemplo um servi¸co sob- demanda, em que o usu´ ario pode acessar e gerenciar uma base de dados de conte´ udo sob-demanda e assistir os t´ıtulos que ele tenha escolhido.
3.2 Redistribui¸ c˜ ao
O sinal ATSC pode ser redistribu´ıdo via rede broadband, nas situa¸c˜ oes em que o prove-
dor de servi¸cos local n˜ ao retransmite a programa¸c˜ ao completa de servi¸cos, assim os sinais
e componentes de determinados servi¸cos podem ser recuperados atrav´ es de streamings
IP. O sinal tamb´ em pode ser codificado com watermarks e fingerprints para assegurar
os direitos autorais do conte´ udo transmitido, atrav´ es do envio e recep¸c˜ ao das tabelas de
sinaliza¸c˜ ao.
3.3 Sinaliza¸ c˜ ao (ATSC3 - A/331, 2017)
Os servi¸cos ATSC 3.0 s˜ ao entregues baseados num modelo funcional de trˆ es camadas:
camada f´ısica, camada de entrega e camada de gerenciamento de servi¸cos.
A camada f´ısica provˆ e o transporte de sinais de sinaliza¸c˜ ao, an´ uncio de servi¸cos e fluxos de pacotes IP sobre redes broadcast e broadband.
A camada de entrega fornece os mecanismos de transporte dos fluxos de objetos, atrav´ es dos protocolos MMTP e ROUTE, sobre tr´ afego UDP/IP multicast em redes broadcast e sobre HTTP (HyperText Transfer Protocol ) / TCP (Transmission Control Protocol) / IP unicast em redes broadband.
A camada de gerenciamento de servi¸cos habilita a descoberta e aquisi¸c˜ ao dos variados tipos de servi¸cos transportados pelas camadas inferiores de entrega e f´ısica.
3.3.1 Camada de Sinaliza¸c˜ao de Servi¸cos - SLS (Service Layer Signaling)
A sinaliza¸c˜ ao de servi¸cos fornece as funcionalidades de aquisi¸c˜ ao e descri¸c˜ ao dos servi¸cos. Ela ´ e composta por dois tipos b´ asicos: sinaliza¸c˜ ao de bootstrap atrav´ es das tabelas de lista dos servi¸cos (Service List Table - SLT ) e pela sinaliza¸c˜ ao de camada dos servi¸cos (Service Layer Signaling - SLS ). A SLT provˆ e os meios para que o receptor possa determinar uma lista b´ asica de servi¸cos e assim iniciar a descoberta da respectiva SLS para cada servi¸co ATSC 3.0, conforme mostrado na Figura 16.
Figura 16: Referencias das SLTs aos servi¸cos ATSC 3.0.
Fonte: ATSC3 - A/331 (2017).
Especificamente para transporte via MMTP, a sinaliza¸c˜ ao SLS ´ e transmitida atrav´ es
das mensagens de sinaliza¸c˜ ao do pr´ oprio protocolo, em taxas diversas e adequadas para
suportar comuta¸c˜ ao e sintonia r´ apida de canais.
Os servi¸cos podem ser entregues tanto em segmentos ROUTE/DASH, quanto em MPUs utilizando o protocolo MMTP. Neste caso, a entrega se realiza atrav´ es de uma ou mais sess˜ oes MMTP, sendo que cada sess˜ ao pode ser composta de um ou v´ arios fluxos de pacotes contendo mensagens de sinaliza¸c˜ ao e/ou componentes de conte´ udo da m´ıdia.
Cada sess˜ ao MMTP ´ e identificada por um par espec´ıfico de endere¸co IP destino e porta UDP destino. Por sua vez, cada fluxo de pacotes MMTP (e seu respectivo componente de servi¸co) est´ a associado a um n´ umero ´ unico no escopo da sess˜ ao MMTP, chamado de packet id.
Propriedades comuns a cada fluxo de pacotes MMTP e certas propriedades espec´ıficas s˜ ao sinalizadas via SLS, enquanto as propriedades comuns a cada sess˜ ao MMTP s˜ ao informadas atrav´ es das mensagens de sinaliza¸c˜ ao MMT, transportadas na pr´ opria sess˜ ao.
3.3.2 Sinaliza¸c˜ao de Baixo N´ıvel (Low Level Signaling - LLS)
A LLS ´ e um tipo de sinaliza¸c˜ ao transportado diretamente no payload de pacotes IP, em endere¸cos/portas espec´ıficas e dedicadas para esta fun¸c˜ ao. Ela pode ser dos cinco tipos seguintes:
Tabela de Lista dos Servi¸cos (Service List Table - SLT );
Tabela de Classifica¸c˜ ao da Regi˜ ao (Rating Region Table - RRT );
Fragmento do Tempo de Sistema (System Time fragment);
Tabela de Alerta Avan¸cado de Emergˆ encia (Advanced Emergency Alert Table - AEAT );
Fragmento da Notifica¸c˜ ao de Mensagem na Tela (Onscreen Message Notification
fragment ).
3.3.3 Sinaliza¸c˜ao de Camada do Servi¸co (Service Layer Signaling - SLS)
