ITTO20010525A1 - Procedimento di trasmissione, ad esempio per la trasmissione ripartita di flussi audiovisivi o multimediali, sistema di trasmissione, trasme - Google Patents

Description

DESCRIZIONE dell'invenzione industriale dal titolo: "Procedimento di trasmissione, ad esempio per la trasmissione ripartita di flussi audiovisivi o multimediali, sistema di trasmissione, trasmettitore e ricevitore corrispondenti, relativo prodotto informatico"

TESTO DELLA DESCRIZIONE

La presente invenzione si riferisce alle tecniche di trasmissione ed è stata sviluppata con particolare attenzione alla possibile applicazione ai sistemi di comunicazione audiovisiva o multimediale .

L'invenzione affronta il problema della possibile ripartizione su più canali di flussi informativi quali ad esempio flussi audio e video da presentare in modo sincronizzato al terminale ricevente. L'invenzione mira soprattutto a soddisfare l'esigenza di trasmettere flussi informativi di questa natura su un certo numero di canali di una rete di comunicazione (quale ad esempio una rete a commutazione di pacchetto e/o una rete di comunicazione mobile) in condizioni in cui, non essendo la capacità di trasmissione del singolo canale sufficiente per soddisfare le esigenze di trasmissione, è necessario prevedere la trasmissione su più canali, in condizioni in cui il numero dei suddetti canali può anche variare nel tempo in funzione delle esigenze di trasmissione.

Sono noti nella tecnica procedimenti che consentono di associare informazione ad ogni pacchetto che trasporti dati multimediali: si può far riferimento, ad esempio, all'header RTP (IETF RFC 1889), l'header PES (ISO/IEC 13818-1) o ancora l'header SL (ISO/IEC 14496-1). In particolare, l'ultimo header citato consente un elevato grado di configurabilità e dunque permette di ottimizzare il consumo di bit nei diversi casi.

Sono parimenti note soluzioni che consentono di multiplare diversi flussi dati: di nuovo, a titolo di esempio, sì può far riferimento alla soluzione nota come MPEG-A Flexmux (ISO/IEC 14496-1), che utilizza un header contenente otto bit per individuare il flusso dati ed otto bit per indicare la lunghezza del pacchetto.

Sono infine noti, almeno per applicazioni particolari, soluzioni che consentono di ripartire una sequenza di pacchetti su più canali di trasmissione: una tecnica di questo genere è utilizzata in alcuni casi per gestire la trasmissione su due canali B ISDN.

La diretta applicazione di tali soluzioni al contesto delineato in precedenza risulta tuttavia diffìcilmente proponibile: la quantità di informazione di controllo necessaria per assicurare la corretta aggregazione dei flussi informativi in trasmissione ed una corrispondente accurata disaggregazione in ricezione (le espressioni "aggregazione" e "disaggregazione" vengono qui utilizzate nella loro accezione più generale) finirebbe infatti per avere un peso percentuale significativo rispetto all'informazione utile (payload) che viene trasmessa. Il tutto con un'utilizzazione quanto mai inefficiente delle risorse di trasmissione disponibili, di per sé già ridotte se riferite ai flussi da trasmettere.

La presente invenzione si prefigge lo scopo di fornire una soluzione perfezionata rispetto alle soluzioni precedentemente note, soprattutto per quanto riguarda lo sfruttamento della banda disponibile per la trasmissione.

Secondo la presente invenzione, tale scopo viene raggiunto grazie ad un procedimento di trasmissione avente le caratteristiche richiamate in modo specifico nelle rivendicazioni che seguono. L'invenzione si riferisce anche al relativo sistema, al trasmettitore ed al ricevitore corrispondenti, nonché al corrispondente prodotto informatico, vale a dire al prodotto direttamente caricabile nella memoria di un elaboratore e comprendente porzioni di codice software che consentono di attuare il procedimento secondo l'invenzione quando il suddetto prodotto viene fatto girare su un elaboratore.

La soluzione secondo l'invenzione consente di raggruppare e proteggere adeguatamente l'informazione riguardante la descrizione dei dati trasmessi, il meccanismo di multiplazione dei diversi flussi e quello di ripartizione su più canali di trasmissione, il tutto riducendo al minimo la quantità di bit richiesti in aggiunta al flusso utile (payload) che viene trasmesso.

L'invenzione è suscettibile di essere utilizzata con particolare vantaggio per trasmettere in tempo reale segnali audio e/o video (eventualmente accompagnati da segnali dati) su linee telefoniche quali, ad esempio, linee di una rete di telecomunicazione mobile, quale una rete cellulare.

Il riferimento a questo contesto di applicazione non deve essere tuttavia interpretato in senso limitativo del campo di possibile applicazione dell'invenzione, che è affatto generale.

L'invenzione verrà ora descritta, a puro titolo di esempio non limitativo, con riferimento ai disegni annessi, in cui:

la Figura 1 illustra, sotto forma di uno schema a blocchi funzionale, il funzionamento di un sistema secondo l'invenzione, considerato dal lato trasmissione, e

la Figura 2 illustra, sotto forma di uno schema a blocchi funzionale, il funzionamento di un sistema secondo l'invenzione, considerato dal lato ricezione.

Nello schema della figura 1 il riferimento S indica in generale una sorgente di flussi informativi video V, audio A e/o dati D che si presuppongono essere assemblati in unità di accesso (access unit) di dimensione variabile, ciascuno associata ad una certa metainformazione corrispondente .

La metainformazione include in particolare un cosiddetto "time stamp" indicante l'istante di tempo a cui l'unità di accesso si riferisce (ad esempio l'istante di cattura di un frame video), misurato relativamente ad un sistema di riferimento temporale che si suppone essere noto tanto alla sorgente S quanto ad un utilizzatore o destinatario U (figura 2) dei flussi in questione.

Ad esempio, nella parte in alto a sinistra della figura 1 le varie unità di accesso che compongono il segnale video V sono state indicate come Vtl, Vt2, Vtn. Analogamente, le unità di accesso del flusso audio A sono indicate con Atl, At2, ..., Atn, mentre le unità omologhe del flusso dati D sono indicate con Dtl, Dt2,..., Dtn. Le lettere V, A e D identificano la natura del singolo flusso informativo (video, audio, dati), mentre tn (n= 1,.. n) indica il tempo di cattura della corrispondente unità di accesso.

Le figure dei disegni fanno riferimento alla presenza di tre flussi informativi V, A e D. E' comunque evidente che la presente invenzione può essere applicata con vantaggio anche in contesti in cui, ad esempio:

- siano presenti solo alcuni dei flussi V, A, D considerati in precedenza, e/o

- siano presenti più flussi dello stesso tipo, cioè, ad esempio, più flussi video, più flussi audio, etc..

Il tutto in qualunque numero e/o combinazione possibile.

Le varie unità di accesso Vtn, Atn, Dtn vengono forniti a rispettivi moduli pacchettizzatori P che organizzano (secondo criteri per sé noti) il flusso delle unità di accesso in pacchetti di dimensioni opportune in vista della trasmissione.

Ogni pacchetto contiene almeno un segmento di unità di accesso, vale a dire un segmento di unità di accesso, un'intera unità di accesso, ovvero ancora un certo numero di unità di accesso intere.

Ogni pacchetto risulta composto da un carico utile (payload) nonché da un rispettivo header.

Tutto questo in vista dell'aggregazione dei vari flussi formativi V, A, D in un flusso aggregato complessivo derivante dall'azione di aggregazione svolta da un modulo M con funzione di multiplexer (mux). Il flusso aggregato viene quindi distribuito su un certo numero di canali Cj (con j=l, ..., n: il canale può dunque essere - almeno in certe condizioni - anche uno solo) di una rete di trasmissione N quale, ad esempio, una rete di comunicazione mobile di tipo cellulare.

L'operazione di ripartizione sui canali in questione viene attuata tramite un modulo di suddivisione o splitter S che opera in funzione delle specifiche esigenze di trasmissione (ad esempio, in funzione del numero di canali al momento utilizzati per la trasmissione).

I criteri di funzionamento del modulo multiplexer M e del modulo splitter S sono da ritenersi ampiamente noti nella tecnica e tali da non richiedere una descrizione particolareggiata in questa sede, anche perché quali criteri non sono di per sé rilevanti ai fini della comprensione e dell'attuazione della presente invenzione.

Così come meglio illustrato nella parte in alto a destra della figura 1, il singolo header associato alle varie unità di accesso dei flussi V, A e D raggruppa due tipologie di campi.

Un primo insieme di campi dell'header H (insieme indicato con HS) convoglia informazioni specificatamente configurate per il singolo flusso e che rappresentano la metainformazione associata ai dati trasmessi.

Un secondo insieme di campi dell'header H (insieme indicato con HG) comprende invece campi di validità generale, che non dipendono dal singolo flusso, compreso almeno un bit di parità (checksum).

Si noterà che, per semplicità di illustrazione, i suddetti insiemi di campi HS e HG sono stati rappresentati nelle figure come contigui fra loro. In realtà i campi dei due insiemi in questione sono di solito "mescolati" fra loro, tale soluzione essendo anzi preferita, ad esempio per esigenze di parsing in sede di ricezione.

I tecnici esperti del settore apprezzeranno che la tecnica di rappresentazione della metainformazione associata alla singola unità di accesso è mutuata dalla specifica dell'header SL (ISO/IEC 14496-1), in quanto questa permette di ridurre al minimo il consumo di bit in ogni header ed al contempo è configurabile e dunque consente una notevole flessibilità.

Nella specifica ISO/IEC 14496-1 esiste un preciso meccanismo per configurare l'header SL : questo meccanismo consiste nella trasmissione preventiva di una struttura denominata SLConfigDescriptor che stabilisce, ad esempio, quanti bit vadano utilizzati per rappresentare un time stamp, ed in quale scala.

Nella soluzione secondo l'invenzione una struttura quale SLConfigDescriptor può essere trasmessa preventivamente, ma anche essere preimpostata sui terminali. In ogni caso a tale SLConfigDescriptor si aggiungono ulteriori parametri di configurazione per gestire il caso di molteplici unità di accesso in un singolo pacchetto.

La tecnica utilizzata in questo caso è analoga a quella definita per la pacchettizzazione di flussi MPEG-4 su RTP (riferimento attuale: IETF draftgentric-avt-mpeg4-multiSL-04 .txt).

Nel complesso, l'insieme dei campi utilizzati per convogliare nell'header H la metainformazione delle unità di accesso compone la parte di header qui denominata HS. Ogni singolo flusso necessita in generale di una propria configurazione relativa all'header HS mentre i parametri di configurazione possono essere diversi per ciascun flusso.

Così come già detto, in aggiunta ai campi dell'insieme HS, nell'header sono presenti ulteriori informazioni, complessivamente indicate con HG, destinate a permettere la suddivisione del flusso trasportato sulle diverse linee ed il corretto riassemblaggio al ricevitore.

In particolare, nell'esempio di attuazione qui illustrato, l'insieme di ulteriori informazioni HG comprende i seguenti campi:

- PN: numero del pacchetto nell'ordine di invio sul sistema di trasmissione,

CH: identificativo del canale; ogni canale trasporta un particolare flusso (video, audio o dati),

- L: lunghezza del pacchetto dati,

- CK: checksum di protezione per tutti i dati dell'header (dunque sia della parte HS, sia della parte HG), ad eccezione di CK stesso.

In modo preferito, il campo CH con 1'identificativo del canale viene collocato in una posizione di testa dell'header H, così da precedere l'insieme HS, per evidenti esigenze di parsing in ricezione .

La dimensione (numero di bit) utilizzata per i vari campi dell'header HG è determinata in modo da ottenere il miglior compromesso fra la riduzione dell'overhead introdotto dalla generazione dell'header e le prestazioni richieste al sistema.

La configurazione della parte di header HG non può essere stabilita a run-time (come invece è ipotizzabile per la parte HS), ma rappresenta invece un vincolo per il sistema trasmettitore-ricevitore.

L'assegnazione di diversi canali CH disponibili ai vari flussi video, audio e dati può essere preimpostata o essere stabilita a run-time; in quest'ultimo caso è però necessario riservare un canale per l'assegnazione.

Nella definizione dei dati che compongono i due insiemi di campi dell'header H è necessario tenere conto di alcuni fattori intrinseci legati alle caratteristiche generali del sistema di trasmissione .

Ad esempio, la lunghezza del campo time stamp in HS determina il tempo di wrap around del time stamp.

Analogamente, il valore massimo del campo PN in HG determina la massima differenza nel tempo di percorrenza ammesso fra le linee disponibili.

La lunghezza del campo CH determina il numero massimo di flussi che possono essere contemporaneamente supportati e, in modo analogo, il valore massimo di L corrisponde alla lunghezza massima del pacchetto.

Infine, la lunghezza del campo CK determina la capacità di rilevazione/correzione degli errori per gli header.

I pacchetti sono generati con lunghezza variabile, in particolare con una dimensione massima che permette di bilanciare con una certa precisione la distribuzione dei dati sulla molteplicità di canali disponibili. I pacchetti così generati vengono distribuiti dal modulo splitter S sui vari canali Cl, ..., Cj rispettando un criterio di distribuzione omogenea del carico fra le diverse linee.

Ogni pacchetto generato viene inviato su una determinata linea. Pacchetti troppo lunghi potrebbero generare un disequilibrio nel carico delle linee; pertanto le unità di accesso che eccedono in lunghezza la dimensione massima di pacchetto vengono frammentate su più pacchetti.

Il campo CH viene utilizzato in fase di ricezione per la ricostruzione dei vari flussi di unità di accesso V, A e D.

Il campo di numero di pacchetto PN è destinato a consentire di ricostruire, in fase di ricezione, la corretta sequenza dei pacchetti, ovviando così alla possibile differenza di tempo di percorrenza della rete trasmissiva N che può esistere fra i diversi canali .

Il time stamp e i diversi altri campi dell'insieme HS sono destinati a permettere di ricostruire, in fase di ricezione, gli esatti contorni delle unità di accesso e le metainformazioni a loro associate, permettendo la loro corretta gestione (ad esempio, la riproduzione sincronizzata di audio e video).

Passando ad esaminare la struttura del ricevitore illustrata in figura 2, si osserverà che i dati pacchettizzati in arrivo dalla rete N sui vari canali Cj, ... C(j+1) vengono sottoposti ad una serie di operazioni di analisi, riorganizzazione e bufferizzazione destinate a ricostruire la sequenza di unità di accesso originariamente trasmessa, mantenendo le metainformazioni che le caratterizzano .

I dati ricevuti su ogni singolo canale non espongono, in ricezione, i confini dei singoli pacchetti trasmessi, ma costituiscono un flusso continuo di byte.

Il primo passo che viene eseguito nel ricevitore consiste pertanto nell ' analizzare il flusso di byte in ingresso ed identificare i confini dei diversi pacchetti .

Ciò avviene tramite moduli PS che ricercano i pacchetti analizzando il flusso di byte in arrivo su ciascun canale alla ricerca di una sequenza di almeno due header sintatticamente corretti.

In particolare, i moduli PS provano a decodificare un header (HI) a partire da un certo byte nel flusso ed a verificare che il checksum CK sia corretto. In caso affermativo, i moduli PS passano ad analizzare 1'header (H2) successivo che dovrebbe trovarsi ad una distanza L (appena ricavata dal corrispondente campo della parte HG di HI). Se anche H2 risulta avere un checksum CK corretto, i moduli PS procedono a verificare gli header successivi H3, H4, ecc.

Il numero di header sottoposti a verifica è impostabile selettivamente.

Qualora la verifica fallisca, i moduli PS ripetono lo stesso tipo di calcolo a partire dal byte immediatamente successivo a quello considerato in precedenza, e così via fino a che la trama dei pacchetti non è stata individuata.

I moduli PS svolgono una funzione di parsing diretta all'interpretazione ed al riconoscimento dei vari campi degli header H.

I pacchetti così individuati dai moduli PS vengono inviati ad un modulo PR che riordina i pacchetti provenienti dai diversi canali avvalendosi dell'informazione convogliata dei campi PN.

Ciò avviene realizzando una comparazione tra i pacchetti in testa nelle varie code attive. Si ricostruisce così la corretta sequenza dei pacchetti in modo indipendente dal tempo di percorrenza che i vari pacchetti possono avere subito in sede di delivery .

Il terzo passo di elaborazione attuato in seno al ricevitore prevede che un modulo demultiplatore DM ripartisca (sulla base del contenuto dei campi CH) il flusso informativo ricevuto in una pluralità di flussi inoltrati ad una schiera di moduli depacchettizzatori DP, ciascuno preposto alla depacchettizzazione di un rispettivo flusso informativo .

Ciascuno dei de-pacchettizzatori DP estrae da ciascun pacchetto riordinato del rispettivo flusso informativo (V, A o D) il payload vero e proprio nonché la metainformazione ad esso associata (convogliata tramite la parte di header HS). Ciascun modulo PS genera pertanto alla sua uscita la sequenza delle unità di accesso video (Vtn), audio (Atn) o dati (Dtn) che gli compete. Tutto questo in vista del successivo trattamento dei dati rispettivi, attuato secondo criteri noti.

Naturalmente, fermo restando il principio dell'invenzione, i particolari di realizzazione e le forme di attuazione potranno essere ampiamente variati rispetto a quanto descritto ed illustrato, senza per questo uscire dall'ambito della presente invenzione .

Claims (22)

1. RIVENDICAZIONI 1. Procedimento per trasmettere su un insieme di canali di comunicazione (Cj) almeno un flusso informativo (V, A, D) assemblato in unità di accesso (Vtn, Atn, Dtn) con associata rispettiva metainformazione, caratterizzato dal fatto che per la trasmissione su detto insieme di canali (Cj) detto almeno un flusso informativo (V, A, D) è organizzato in pacchetti, ciascun pacchetto comprendendo almeno un segmento di una di dette unità di accesso (Vtn, Atn, Dtn) di detto almeno un flusso informativo (V, A, D) ed un header (H); detto header (H) comprendendo: un primo insieme di campi (HS), che rappresenta la metainformazione associata a detto almeno un segmento di detta unità di accesso (Vtn, Atn, Dtn) di detto almeno un flusso informativo (V, A, D), e - un secondo insieme di campi (HG) comprendente campi di validità generale, indipendenti da detto almeno un flusso informativo (V, A, D).
2. 2. Procedimento secondo la rivendicazione 1, caratterizzato dal fatto che dette unità di accesso (Vtn, Atn, Dtn) hanno dimensione variabile.
3. 3. Procedimento secondo la rivendicazione 1 o la rivendicazione 2, caratterizzato dal fatto che detto almeno un flusso informativo viene scelto nel gruppo costituito da un flusso informativo video (V), un flusso informativo audio (A), e un flusso informativo dati (D).
4. 4. Procedimento secondo una qualsiasi delle precedenti rivendicazioni, caratterizzato dal fatto che dette unità di accesso (Vtn, Atn, Dtn) sono relative a flussi informativi diversi fra loro.
5. 5. Procedimento secondo una qualsiasi delle precedenti rivendicazioni, caratterizzato dal fatto che detto secondo insieme (HG) di campi di detto header (H) comprende almeno un campo scelto nel gruppo costituito dai seguenti campi: - numero del pacchetto nell'ordine di invio in trasmissione (PN), identificativo del canale di trasmissione (CH), - lunghezza del pacchetto dati (L), - controllo (checksum - CK).
6. 6. Procedimento caratterizzato dal fatto che detta secondo insieme (HG) di campi di detto header (H) comprende tutti i campi secondo la rivendicazione 5.
7. 7. Procedimento secondo la rivendicazione 5 o la rivendicazione 6, caratterizzato dal fatto che detto campo identificativo del canale di trasmissione (CH) è situato, nell'ambito di detto header (H), in posizione precedente a detto primo insieme di campi (HS).
8. 8. Procedimento secondo una qualsiasi delle rivendicazioni 5 a 7, caratterizzato dal fatto che detto campo di controllo (CK) è relativo a dati compresi tanto in detto primo insieme (HS) quanto in detto secondo insieme (HG) di campi di detto header (H).
9. 9. Procedimento secondo una qualsiasi delle rivendicazioni 5 a 7, caratterizzato dal fatto che detto campo di controllo (CK) è relativo a dati compresi tanto in detto primo insieme (HS) quanto in detto secondo insieme (HG) di campi di detto header (H) escluso il campo di controllo (CK) stesso.
10. 10. Procedimento secondo una qualsiasi delle rivendicazioni 5 a 9, caratterizzato dal fatto che detto campo di controllo è un campo di controllo di parità o checksum (CK).
11. 11. Procedimento secondo una qualsiasi delle rivendicazioni 1 a 10, caratterizzato dal fatto che detto primo insieme (HS) di campi di detto header (H) comprende un campo di time stamp (TS).
12. 12. Sistema di trasmissione configurato per operare con il procedimento secondo una qualsiasi delle rivendicazioni 1 a 11.
13. 13. Trasmettitore per sistema di trasmissione operante con il procedimento secondo una qualsiasi delle rivendicazioni 1 a 11, caratterizzato dal fatto che comprende: - un multiplatore (M) per generare detto flusso informativo organizzato in pacchetti a partire da dette unità di accesso (Vtn, Atn, Dtn), e - un modulo splitter (S) per distribuire detto flusso informativo organizzato in pacchetti sui canali di detto insieme (Cj).
14. 14. Trasmettitore secondo la rivendicazione 13, caratterizzato dal fatto che detto modulo splitter (S) è configurato per distribuire detto flusso informativo organizzato in pacchetti in modo sostanzialmente omogeneo su detti canali di detto insieme (Cj).
15. 15. Ricevitore per sistema di trasmissione operante con il procedimento secondo una qualsiasi delle rivendicazioni 1 a 11, caratterizzato dal fatto che comprende almeno un modulo di ricerca dei pacchetti (PS) a partire da detto flusso informativo; detto modulo di ricerca essendo configurato in modo da: identificare un byte dato in detto flusso informativo organizzato in pacchetti, e decodificare detto header (H) a partire da detto byte dato.
16. 16. Ricevitore secondo la rivendicazione 15, per la ricezione di flussi organizzati in pacchetti comprendenti, nel secondo insieme (HG) di campi di detto header (H) un campo di controllo (CK), caratterizzato dal fatto che detto modulo di ricerca (PS) è configurato per verificare la corretta decodifica di detto header (H) in funzione di detto campo di controllo.
17. 17. Ricevitore secondo la rivendicazione 15 o la rivendicazione 16, caratterizzato dal fatto che detto modulo di ricerca (PS) è configurato in modo tale per cui, nell'impossibilità di decodificare in modo corretto detto header (H) a partire da detto byte dato, lo stesso modulo di ricerca (PS) ripete il tentativo di decodifica di detto header (H) a partire da un byte successivo nel flusso.
18. 18. Ricevitore secondo una qualsiasi delle rivendicazioni 15 a 17, per la ricezione di flussi organizzati in pacchetti in cui detto secondo insieme (HG) di campi di detto header (H) comprende un campo identificativo (L) della lunghezza del pacchetto, caratterizzato dal fatto che detto modulo di ricerca (PS) è configurato in modo tale per cui, a fronte della corretta decodifica di detto header (H) in detto flusso organizzato in pacchetti, il modulo di ricerca (PS) procede ad analizzare un header successivo situato, in detto flusso organizzato in pacchetti, ad una distanza desunta da detto campo di lunghezza del pacchetto (L).
19. 19. Ricevitore secondo una qualsiasi delle rivendicazioni 15 a 18, caratterizzato dal fatto che comprende, a valle di detto almeno un modulo di ricerca (PS), un modulo di riordino dei pacchetti (PR), detto modulo di riordino (PR) essendo configurato per ordinare i pacchetti in detto flusso in funzione dell'ordine di invio in trasmissione.
20. 20. Ricevitore secondo la rivendicazione 19, configurato per operare su flussi organizzati in pacchetti in cui detto secondo insieme (HG) di campi di detto header (H) comprende un campo indicativo del numero del pacchetto nell'ordine di trasmissione (PN), caratterizzato dal fatto che detto modulo di riordino è configurato per operare in funzione dell'informazione desunta da detto campo di numero del pacchetto (PN).
21. 21. Ricevitore secondo una qualsiasi delle rivendicazioni 15 a 20, caratterizzato dal fatto che comprende inoltre un modulo demultiplexer (DM) per disaggregare, a partire da detto flusso organizzato in pacchetti, rispettivi flussi informativi distinti (V, A, D).
22. 22. Prodotto informatico caricabile nella memoria di un elaboratore, comprendente porzioni di codice software per realizzare il procedimento secondo una qualsiasi delle rivendicazioni 1 a 11 quando detto prodotto viene fatto girare su un elaboratore . Il tutto sostanzialmente come descritto ed illustrato e per gli scopi specificati.