EP0872054A1 - Transfert audio dans un systeme de radiodiffusion numerique - Google Patents

Transfert audio dans un systeme de radiodiffusion numerique

Info

Publication number
EP0872054A1
EP0872054A1 EP96934880A EP96934880A EP0872054A1 EP 0872054 A1 EP0872054 A1 EP 0872054A1 EP 96934880 A EP96934880 A EP 96934880A EP 96934880 A EP96934880 A EP 96934880A EP 0872054 A1 EP0872054 A1 EP 0872054A1
Authority
EP
European Patent Office
Prior art keywords
audio
data
data group
file
procedure
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP96934880A
Other languages
German (de)
English (en)
Inventor
Ari c/o Nokia Mobile Phones Ltd. SALOMÄKI
Mika Kasslin
Jukka Pehkonen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Oyj
Original Assignee
Nokia Oyj
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Oyj filed Critical Nokia Oyj
Publication of EP0872054A1 publication Critical patent/EP0872054A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H20/00Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/44Arrangements characterised by circuits or components specially adapted for broadcast
    • H04H20/46Arrangements characterised by circuits or components specially adapted for broadcast specially adapted for broadcast systems covered by groups H04H20/53-H04H20/95
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H20/00Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/40Arrangements for broadcast specially adapted for accumulation-type receivers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H2201/00Aspects of broadcast communication
    • H04H2201/10Aspects of broadcast communication characterised by the type of broadcast system
    • H04H2201/20Aspects of broadcast communication characterised by the type of broadcast system digital audio broadcasting [DAB]

Definitions

  • the present invention relates to audio transport in a digital broadcasting system in which services can be transported as a continuous stream or in data packets.
  • the Digital Audio Broadcasting (DAB) system which has been developed to allow an efficient utilization of frequency bands, uses a completely digital transmission path.
  • the system is designed to replace the analogue broadcasting system commonly used at present, which is based on the use of frequency modulation.
  • DAB defines a digital radio channel based on multiple carriers, which is applicable for the transmission of both audio and data services.
  • a completely digital transmission channel may be either a continuous data stream channel or a packet channel. Packet transmission is more flexible and allows easier transmission of data units of finite length.
  • ETSI European Telecommunication Standards Institute
  • Fig. 1 the highest level of abstraction in the DAB system is called ensemble, Fig. 1. It contains all services existing in a given fre ⁇ quency band. A change from one ensemble to another is effected by tuning to a different frequency band, just as one changes channels in current FM radio reception.
  • the ensemble is divided into services, exemplified in Fig. 1 by Alpha Radio 1, Beta Radio and Alpha Radio 2.
  • there may be data services although they are not shown in the figure.
  • Each service is further di ⁇ vided into service components .
  • a service component can be transported either via an audio channel or via a data channel.
  • FM radio contains only one service and one service component (audio) in each channel.
  • the trans ⁇ mission frame whose duration is 24 ms or 96 ms depend ⁇ ing on the DAB mode, consists of three chronologically consecutive parts.
  • the first part is a synchronizing channel, which contains no service information.
  • the next part is a fast information channel FIC, which has a mode-specific fixed length.
  • the last part is a main service channel MSC, which contains all the subchannels.
  • the position, size and number of subchannels within the MSC may vary, but the size of the MSC is constant.
  • the MSC contains a maximum of 63 different audio and/or data subchannels.
  • the subchannels are numbered on the basis of a so-called sub-Channel Id from 0 to 62.
  • the MSC may contain an auxiliary information channel AIC, which has a fixed channel number 63.
  • the AIC may contain the same type of information as the FIC.
  • the MSC information is transmitted using time interleaving such that in DAB mode I the MSC part of the frame is divided into four parts and these are placed in successive transmission frames. These parts are known as CIF (Common Interleaved Frame) , so the MSC part of the frame in mode I contains four CIFs. In other modes no inter ⁇ leaving is used, so the MSC is the same as the CIF.
  • CIF Common Interleaved Frame
  • the service supplier may also provide data services and e.g. multimedia services.
  • the DAB operator produces a DAB transmission signal, which consists of successive transmission frames such as those presented in the lower part of Fig. 1.
  • the information channel FIC and the channel MSC containing the audio and data services are separated from each other from the transmission frame.
  • the subchannels are separated and channel decoded and then passed on for further processing.
  • the user From the in ⁇ formation in the received FIC channel, the user will know which services are included in the ensemble re ⁇ ceived and is thus able to select a desired service or services.
  • subchannel service components ac ⁇ cording to the application programme, it is possible to compose e.g. a desired multimedia service.
  • the data is transmitted in packets as illustrated by Fig. 2, consisting of a header field, a data field and a checksum.
  • the meanings of the fields are in accor ⁇ dance with the DAB standard.
  • the packet header contains packet length data (Pkt Len) , a continuity index (Cont Ind) , first/last packet data (First/Last) , an address (Pkt Address) identifying the service component, a com ⁇ mand (Command) and the actual data field length (Data Len) .
  • the data field contains the actual data to be transmitted plus fill bits if required. At the end is the packet checksum (Pkt CRC) .
  • a so-called data group is formed.
  • Fig. 2B The packets are formed at the transmitting end from the data group by simply cutting it into sections and placing each section into the data field of a data packet.
  • Gen ⁇ erally a data group consists of the data fields of a number of consecutive packets transmitted. In the sim ⁇ plest case, one packet is sufficient to form a data group.
  • the data group is formed as illustrated by Fig. 3.
  • the meanings of the abbreviations of the data group header and session header fields are as indicated in the table below:
  • EXT FL extension flag LAST FL last CRC FL CRC flag SEG NUM segment number SES FL session flags RFA reserved for future applications DG TYPE data group type LEN IND length of next address field CONT IND continuity index ADDR FIELD end user's address REP IND repetition index EXT FIELD extension field
  • a continuous audio stream is transmitted in frames having a structure as illustrated by Fig. 4.
  • 16-bit PCM coded audio samples coming at a frequency of 48 kHz are divided into sub-bands and the samples of the sub-bands are encoded into the audio frame by making use of the masking effect of the human ear so that the incoming bit rate 768 kbit/s is reduced e.g. in the case of a mono channel to a rate of about 100 kbit/s.
  • the four-byte header of the frame contains information intended for the decoders in the receiver, such as synchronization data, bit rate data, and sam ⁇ pling frequency data.
  • a bit allocation field coming af ⁇ ter the checksum indicates how the bits are allocated to each one of the audio field sub-bands containing 36 coded samples and which bits have been removed from the samples in making use of the masking effect.
  • a Scale Factor Selection Information field indicates how the group of audio samples has been scaled (normalized) in the decoder. After this there is a field that contains the audio bits proper. The information in it corresponds to 24 ms of audio. The field contains 36 encoded sub ⁇ band audio samples divided into twelve triplets, each of which contains 3 sub-band samples. Thus, four triplets corresponds to 12 ms of audio. Next there are fill bits if the number of audio bits amounts to less than the audio field length.
  • PAD Programme Associated Data
  • the audio part of multimedia is proposed to be transmitted in audio frames, yet there may be certain reasons to transmit audio in packet mode as well.
  • Packet mode transmission could in principle be applied e.g. to send audio files, which would first be stored in the memory of the receiver and then played back via the speakers at the appropriate time during the multimedia presentation.
  • This type of audio transport has the ad ⁇ vantage that the file can be transmitted at any bit rate, so the transport rate need not be the same as the fixed bit rate which is used in the transmission of audio frames or an audio stream and which has been as- signed a number of allowed bit rate values in the DAB specification.
  • a disadvantage with this type of transmission is that the audio file has to be stored in memory if the transport rate is lower than the audio stream bit rate, or it needs to be buffered if the transport rate is higher than the audio stream bit rate.
  • playback cannot be started immediately upon recep ⁇ tion of the file, whereas in the case of buffering, playback can be started immediately.
  • the disad- vantage is not a real one, because in most of the possi ⁇ ble practical applications there is no need to transmit an audio file at the audio stream bit rate.
  • the real problem is that the audio stream in audio frames cannot be transmitted in packet mode because there is no mecha ⁇ nism for indicating the audio frame boundaries.
  • Real time packet transmission here means that the bit rate is the same in the transmission of both the audio stream and the audio packets, and that it would be possible in some way to extract from the pack ⁇ ets the same information that is contained in the audio frames.
  • This principle could be applied e.g. to locate bit errors in audio frames by comparing the received audio frame with the checksum CRC of the received pack ⁇ ets that carry the same audio information and with the checksum CRC of the data group formed from the packets. In this way, the audio samples in the audio frames would end up being covered by CRC checking.
  • packets for this purpose would involve extra auxiliary signalling of audio, which might be acceptable as a temporary solu ⁇ tion. If audio transmission is to be protected on a lasting basis and as efficiently as packet transmission is, it would of course be preferable to improve the er ⁇ ror protection of the audio bits in audio frames di ⁇ rectly.
  • the definition describes the in ⁇ terruption of an active broadcast-type service by an an ⁇ nouncement, but the transmission profile for the an ⁇ nouncement can only be defined by specifying the serv- ices to be interrupted. There is no way to address the announcement to a given user group only.
  • the object of the present invention is to achieve audio transport in packet mode so as to allow both addressed audio transport and indication of audio frames in a packet stream.
  • audio is transmitted over a packet channel as a file.
  • An audio frame is placed in the data field of a data group.
  • one segment in the file transfer pro ⁇ tocol corresponds to one audio frame.
  • a data group is assembled in the normal manner, so the data field of the data group will contain a file segment, which in this case is an audio f ame.
  • a file transfer protocol needs to be used. Since the transfer can be performed at any speed, the frames have to be stored or buffered in the receiver prior to presentation.
  • the audio frames are transmitted over a packet channel in the form of a continuous stream.
  • An audio frame is placed in the data field of a data group.
  • the transmission speed is exactly the same as the audio channel bit rate.
  • individual data groups are transmitted at exactly the correct pace, so the transmission consists of an endless train of data groups. Therefore, no file trans- fer protocol is needed. No buffering needs to be used, but the receiver presents the audio frames directly as it receives data groups from the packet channel.
  • the invention is illustrated by the attached draw- ings, in which
  • Fig. 1 presents a known DAB hierarchy
  • Fig. 2a presents the structure of DAB packets
  • Fig. 2b shows how a data group is formed from packets
  • Fig. 3 presents the structure of a data group
  • Fig. 4 presents a DAB audio frame
  • Fig. 5 illustrates the use of an IDG.
  • the audio frames are transmitted as an audio file, in other words, the audio, which has a beginning, a duration and an end, constitutes one file.
  • the file is divided into seg- ments and each segment is placed in the data field of a data group.
  • the protocol will be briefly described be ⁇ low. According to the invention, a segment is exactly equivalent to an audio frame.
  • the file transfer protocol can be implemented ac ⁇ cording to the general basic principle proposed by the Eureka-147 project, in which each segment forms one data group. Successive segments of the file are numbered se- quentially so that the first segment number in the ses ⁇ sion header is 0. The last segment of the file is indi ⁇ cated by a flag in the LAST field of the session header of the data group formed from it .
  • the receiver receives the data packets and forms data groups out of them. If its checksum indicates that bit errors occurred during the transfer, the receiver picks up the data packets of the relevant data group from the retransmission of the file.
  • the Eureka-147 project includes a proposi ⁇ tion that an additional special Information Data Group (IDG) be created.
  • IDG Information Data Group
  • Fig. 5 illustrates the idea of the IDG in file transfer.
  • One IDG is associated with only one file. It is placed at least at the beginning of the packet stream relating to the file, i.e. at the beginning of the file transfer, but IDGs can also be placed in the middle of the packet stream, in other words, the IDG may appear at any point during the file transfer or the IDG can be transmitted some time before the actual file transfer, so it can be used to announce a file transfer before it is started.
  • files X, Y and Z are transferred and the IDGs referring to them are identified by corre ⁇ sponding letters .
  • the file descriptor can be used to give the receiver the required detailed information about the file to be transferred.
  • the file descriptor includes a field containing so- called transfer parameters (T-parameters) .
  • T-parameters transfer parameters
  • a T-parameter called File Type declares the type of the file, so the application software of the receiver is able to decide which algorithm to use for file analysis and interpreta- tion of its contents.
  • DAB audio a new file type pa ⁇ rameter called "DAB audio" be added to let the receiver know that the incoming file announced by the IDG is an audio file.
  • the informa ⁇ tion about the services is transmitted over the fast in ⁇ formation channel (FIC) . It is used to announce the lo ⁇ cation and nature of the service components.
  • FOC fast in ⁇ formation channel
  • a service description for each service is placed in a separate field, which contains a parameter field called service component description.
  • One of the parameters is service component type and this parameter is set to File Trans ⁇ fer.
  • the receiver From the FIC channel information the receiver thus learns that a file is being transferred and from the IDG information that the file is an audio file. The receiver is therefore able to receive the file, decode the audio and present it. Depending on the file transfer speed, the receiver must either store the audio file or use buffering for it .
  • the audio frames are transmitted in packet mode, yet as a continu ⁇ ous audio stream.
  • the transfer speed is exactly the same as it would be if audio frames were used.
  • each audio frame is first assigned to a data group, then packets are formed from the data group and transmitted.
  • the audio frame also contains the PAD.
  • the transmission is not a file transfer procedure as in the first embodiment, so no file transfer protocol is needed. Therefore, no information data groups IDG are needed, either.
  • An audio data group may never cross the CIF boundary, so the entire data group must be trans- ferred in a single common interleaved frame CIF.
  • the data group must be transferred in a single transmission frame. If repetition is used at the data group level, then the data group and all the repe ⁇ titions of it must be transmitted in a single CIF, i.e. each repetition is transmitted in a single CIF.
  • a session header is not necessarily needed, but it is advisable to use it because it contains an address field ADDR FIELD, which is intended for the end user's address. By means of this address, an audio transmission can be addressed to a de ⁇ sired user group.
  • ADDR FIELD address field
  • the SEG NUM field is used as a counter that is incre ⁇ mented by one on every data group. This helps the re ⁇ DCver keep in synchronism, because if a data group fails to be transmitted or is defective, the playback is delayed by the duration of an audio frame.
  • the flag in the LAST FL field is always zero because the transmis ⁇ sion is a continuous audio stream, albeit in packet mode.
  • the data group can be interleaved with other packet mode service components in the same subchannel, but the data group must still fit into a single CIF. If a data group is interleaved with other service compo ⁇ nents carrying audio data groups in the same subchannel, then all the data groups must be transmitted in a single CIF.
  • the appli ⁇ cant proposes that the service component type parameter "DAB Audio Stream" be sent in the service component de ⁇ scription field in the fast information channel FIC.

Abstract

Dans un système de radiodiffusion numérique, le son est émis sous la forme d'un flux continu dans des trames audio. Selon l'invention, on parvient à cela en émettant exactement une trame audio dans le champ des données de chaque groupe de données. Le son peut être transféré sous forme de fichier. Un nombre déterminé de trames audio successives constitue alors un fichier audio, lequel est transféré conformément au protocole de transfert de fichiers du système. Dans ce cas, la vitesse de transfert peut varier. Le son peut être transféré par paquets, sous la forme d'un flux continu, et les trames audio sont transférées à la même vitesse par la formation de groupes de données successifs à partir de trames audio arrivant sous la forme d'un flux, et par la sélection de la vitesse de transfert des paquets de données, de telle sorte que la vitesse de transfert d'une trame audio attribuée au groupe de données soit la même que pour une trame audio émise sous la forme d'un flux continu.
EP96934880A 1995-11-07 1996-11-05 Transfert audio dans un systeme de radiodiffusion numerique Withdrawn EP0872054A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FI955357A FI99064C (fi) 1995-11-07 1995-11-07 Audiosiirto digitaalisessa yleisradiojärjestelmässä
FI955357 1995-11-07
PCT/FI1996/000595 WO1997017776A1 (fr) 1995-11-07 1996-11-05 Transfert audio dans un systeme de radiodiffusion numerique

Publications (1)

Publication Number Publication Date
EP0872054A1 true EP0872054A1 (fr) 1998-10-21

Family

ID=8544343

Family Applications (1)

Application Number Title Priority Date Filing Date
EP96934880A Withdrawn EP0872054A1 (fr) 1995-11-07 1996-11-05 Transfert audio dans un systeme de radiodiffusion numerique

Country Status (4)

Country Link
EP (1) EP0872054A1 (fr)
AU (1) AU7301296A (fr)
FI (1) FI99064C (fr)
WO (1) WO1997017776A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9714624D0 (en) * 1997-07-12 1997-09-17 Trevor Burke Technology Limite Visual programme distribution system
JP2000244425A (ja) * 1999-02-24 2000-09-08 Sony Computer Entertainment Inc 放送システムおよび受信再生端末
FI19991865A (fi) 1999-09-01 2001-03-01 Nokia Corp Menetelmä ja järjestelmä räätälöityjen audio-ominaisuuksien toimittamiseksi solukkojärjestelmien päätelaitteisiin
US6618367B1 (en) * 1999-12-16 2003-09-09 Agere Systems Inc. Transmission frame structure for a satellite digital audio radio system
EP1119122A3 (fr) 2000-01-20 2005-01-19 Matsushita Electric Industrial Co., Ltd. Méthode de radiodiffusion numérique, émetteur de radiodiffusion pour l'émission de signaux de radiodiffusion numérique ainsi que récepteur pour la réception de ces signaux de radiodiffusion numérique
US6766376B2 (en) 2000-09-12 2004-07-20 Sn Acquisition, L.L.C Streaming media buffering system

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2643978B2 (ja) * 1988-04-23 1997-08-25 株式会社ケンウッド パケットデータ生成装置
FR2718905B1 (fr) * 1994-04-19 1996-06-28 France Telecom Signal numérique organisé en containers de données autonomes, notamment pour la transmission de données vers des récepteurs à fonctionnement intermittent, procédé de diffusion et procédé de réception correspondants.
DE4422015C1 (de) * 1994-06-16 1995-08-03 Bosch Gmbh Robert Verfahren zur Übertragung digitaler Daten und digitaler Zusatzdaten und Verfahren zur Wiedergabe digitaler Daten und digitaler Zusatzdaten

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9717776A1 *

Also Published As

Publication number Publication date
FI99064B (fi) 1997-06-13
FI955357A0 (fi) 1995-11-07
WO1997017776A1 (fr) 1997-05-15
AU7301296A (en) 1997-05-29
FI99064C (fi) 1997-09-25

Similar Documents

Publication Publication Date Title
EP2139132B1 (fr) Méthode de transmission à des terminaux mobiles d'un guide électronique de services multimédia
US9350471B1 (en) Systems and methods for transmitting and receiving large objects via digital radio broadcast
US8144612B2 (en) Systems and methods for transmitting media content via digital radio broadcast transmission for synchronized rendering by a receiver
US20210235135A1 (en) Apparatuses and methods for transmitting or receiving a broadcast content via one or more networks
US8451868B2 (en) Systems and methods for transmitting media content via digital radio broadcast transmission for synchronized rendering by a receiver
US6415135B1 (en) Transmission protocol for file transfer in a DAB system
US20120189069A1 (en) Systems and Methods for a Multiport Synchronous-Asynchronous Client for Scheduling and Delivering Content for Digital Radio Broadcast Transmission
KR20160147841A (ko) 방송 전송 장치, 방송 전송 장치의 동작 방법. 방송 수신 장치 및 방송 수신 장치의 동작 방법
US20090207861A1 (en) Method and Apparatus For Formatting Data Signals in a Digital Audio Broadcasting System
US6347071B1 (en) Time division multiplexed transmission of OFDM symbols
US20160337707A1 (en) Broadcast transmission device and operating method thereof, and broadcast reception device and operating method thereof
US20180139499A1 (en) Method for streaming through a data service over a radio link subsystem
US8893214B2 (en) Image processing apparatus, signal processing method, and program
WO2008106838A1 (fr) Procédé de transmission de multicanaux pour un guide de service électronique dans une diffusion multimédia mobile
EP0872054A1 (fr) Transfert audio dans un systeme de radiodiffusion numerique
WO2011044349A1 (fr) Systèmes et procédés permettant de transmettre un contenu multimédia par le biais d'une transmission radio numérique pour un rendu synchronisé par un récepteur
WO1997017775A1 (fr) Reception multimedia dans un systeme de radiodiffusion numerique
US9842048B2 (en) Systems, methods, and computer readable media for digital radio broadcast receiver memory and power reduction
HUT63018A (en) Method for transferring control signal varying in time
JP4868686B2 (ja) デジタル放送信号多重送出装置
KR20080063185A (ko) 임의의 eti-신호를 dab 모드 3을 갖는eti-신호로 변환하기 위한 방법 및 장치
WO2002041547A1 (fr) Dispositif et procede pour la diffusion sans fil sur un nombre d'ondes porteuses

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19980608

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB NL

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA MOBILE PHONES LTD.

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA CORPORATION

RIN1 Information on inventor provided before grant (corrected)

Inventor name: PEHKONEN, JUKKA

Inventor name: KASSLIN, MIKA

Inventor name: SALOMAEKI, ARI,C/O NOKIA MOBILE PHONES LTD.

17Q First examination report despatched

Effective date: 20080129

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20120531