Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
  • H04N21/23614—Multiplexing of additional data and video streams
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
  • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
  • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
  • H04N21/4348—Demultiplexing of additional data and video streams
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
  • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
  • H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
  • H04N21/4432—Powering on the client, e.g. bootstrap loading using setup parameters being stored locally or received from the server
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
  • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
  • H04N21/458—Scheduling content for creating a personalised stream, e.g. by combining a locally stored advertisement with an incoming stream; Updating operations, e.g. for OS modules ; time-related management operations
  • H04N21/4586—Content update operation triggered locally, e.g. by comparing the version of software modules in a DVB carousel to the version stored locally
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F8/00—Arrangements for software engineering
  • G06F8/60—Software deployment

Definitions

• the present invention relates to the update of the resident software contained in devices.
• the context is more particularly the update by distribution in a stream of the device management software.
• each update stream carried all the segments constituting the functional software and was addressed to a particular type of platform.
• operators have often used new manufacturers to diversify their set-top box providers. The latter have themselves sought to reduce the cost of equipment by providing new decoders based on new hardware versions.
• the hardware pool has become heterogeneous and the bandwidth requirement allocated to download streams has become more important.
• the technical problem therefore consists in reducing the bandwidth requirements allocated to the download stream, both for the operator and the manufacturer. This problem can be stated as follows:
• the invention makes it possible to mix in the same stream different versions of software for different decoders.
• the principle is to define a single data format that allows you to update a decoder from a stream carrying the binary segments of several resident software versions, these binary segments being composed of segments common to several software versions and segments specific to each of the software versions.
• the procedure implemented by the loader to retrieve the code segments dedicated to a hardware version of a decoder is more complex.
• this procedure can be improved to ensure that the loader only tries to recover the code segments that need to be updated.
• a method of constructing a distribution medium containing a plurality of resident software versions for a plurality of devices that includes an identification step within the different resident software versions comprising the plurality of common portions to at least two resident software versions, as well as a step of splitting the different resident software versions composing the plurality into segments, as well as the assembly of these segments within a distribution medium, the component segments a part common to at least two versions found once in the distribution media.
• the invention furthermore comprises a step of marking each segment by means of identifying the devices targeted by the resident software version (s) of which the segment is a part.
• the plurality of devices is a plurality of digital television reception apparatuses.
• the distribution medium is an MPEG transport stream.
• the invention also relates to a method for acquiring all or part of a resident software version by an apparatus having means for accessing a distribution medium distributed by a network of distribution, said medium comprising a plurality of segments comprising a plurality of resident software versions, the method comprises a step of identification within the distribution support of at least one segment intended for said apparatus, as well as a step of downloading said segment identified within the apparatus from said distribution medium and storage in memory of said segment.
• the identification step within the distribution medium comprises a step of comparing a set of identifiers identifying within each segment the devices targeted by the resident software version to which the segment belongs and a set of identifiers reside on the device and encoding its type and use.
• the set of identifiers contains at least one platform identifier identifying the precise type of hardware version of the device, a product identifier identifying the operator operating the device and a usage identifier identifying the intended use of the device.
• the apparatus is a digital television receiver and the distribution medium is an MPEG transport stream.
• the invention also relates to a carrier for distributing a plurality of resident software versions to a plurality of devices, said software versions being segmented where said distribution medium gathers the segments of the plurality of versions of resident software, the segments common to at least two versions of software being present only once on the medium.
• each segment has a set of identifiers identifying within each segment the devices targeted by the resident software version to which the segment belongs.
• the set of identifiers contains at least one platform identifier identifying the precise type of hardware version of the device, a product identifier identifying the operator operating the device and a usage identifier identifying the intended use of the device.
• the medium has the form of an MPEG transport stream.
• the invention also relates to an apparatus having means for accessing a distribution medium containing a plurality of software versions resident to a plurality of devices, these versions being divided into a plurality of segments within the support of distribution, said apparatus having means for downloading segments present within the description medium and means for storing these segments and having means for determining the segments forming part of a resident software version being intended for it among the plurality of segments present within the distribution support.
• the apparatus has a set of identifiers coding its type and its use and means for comparing this set of identifiers with a set of identifiers present within each segment present in the within the distribution medium and identifying the devices targeted by the resident software version to which the segment belongs.
• the means for accessing a distribution medium are means for accessing an MPEG transport stream.
• Figure 1 shows the known architecture of a download software broadcast system on a set of decoders.
• Figure 2 shows an example of software architecture of a decoder.
• Figure 3 shows the different levels of splitting of the resident software in an exemplary embodiment of the invention.
• Figure 4 shows the stubborn segment in the exemplary embodiment of the invention.
• Figure 5 shows the format of the MPEG section in the exemplary embodiment of the invention.
• FIG. 6 shows the steps of the method used by the decoder to find the segments that it must download in the exemplary embodiment of the invention.
• FIG. 7 shows the architecture of a decoder according to the exemplary embodiment of the invention.
• This example is in the field of digital television decoders, but the invention can be applied to any device having a resident software that can be updated through a general broadcast means. Examples include DVD players updated by a single DVD containing software versions for different platforms or otherwise.
• FIG. 7 illustrates the architecture of a decoder referenced 7.1 according to an exemplary embodiment of the invention.
• This decoder consists of a reception module referenced 7.7 ("Tuner" in English) for receiving streams containing audio and video services.
• This module can be a satellite, cable or terrestrial module, or even an IP network connection interface.
• the streams coming from this reception module will then be processed by the MPEG demultiplexer / decoder referenced 7.6.
• This module will be in charge of the verification of the rights and the decryption of the flow if necessary.
• the desired service will be isolated in the stream, indeed the same stream can contain a multiplexing of several audio and video services. Once the desired service is isolated, the different elementary streams are extracted.
• These streams generally consist of at least a compressed video stream and audio stream, generally today, according to the MPEG-2 standard, but the invention works regardless of the format of the services, such as MPEG-4 or other .
• These flows are uncompressed then converted to analog to provide video output and audio output. All these operations are controlled by a resident software distributed in a distributed manner between the read-only memory referenced 7.4 and the rewritable permanent memory referenced 7.3.
• the RAM referenced 7.2 will serve, in turn, working memory for the execution of the resident software.
• FIG. 2 schematically illustrates the various blocks involved in the composition of the resident software present on the embodiment of the invention.
• This resident software runs on the hardware, referenced 2.8, which we have described above. It consists of two parts, a first, referenced 2.5, consists of a loader referenced 2.6 and a minimum set of drivers, referenced 2.7, allowing this charger to operate.
• this charger and its drivers are stored in non-rewritable permanent memory so as to guarantee their integrity over time. Indeed, this charger has the function of allowing the update of the software of the decoder and must be able to operate in any event whatever the state of the resident software stored in the rewritable memory, its corruption should not be possible .
• the other part of the resident software consists of a complete set of drivers, referenced 2.4, for managing the hardware. Above these drivers is an operating system, referenced 2.3, offering a set of generic features based on the drivers.
• the application includes high level software that will provide the user with the functionality of its decoder. It consists of a human-machine interface and implements features such as service switching, interactivity engine management, interactive applications and more. It is common that this part also includes a charger, referenced 2.9, for updating this set of software referenced 2.1. This charger, can itself be updated. Indeed, when downloading a new version of the system software, it may contain a new version of this loader which will be stored in place of the loader referenced 2.9.
• the loader referenced 2.6 stored in permanent memory will always be able to allow a new update of the software to solve the problem and to find a version of the software part referenced 2.1 of the software and therefore of the loader being part referenced 2.9.
• the need to perform a software download in a decoder can have several causes.
• the first cause is the corruption of the installed software. Indeed, the software part referenced 2.1 is stored in rewritable memory, it is always possible that it is corrupted. In this case, the corruption is detected at the next start of the device which will check by a system of CRC ("Cyclic Redundancy Check") the integrity of the modules making up the software. If a corruption is detected in a module other than the charger, it will be used to download a new version of the software. Here it is possible either to update a new full version of the system software or simply modules detected as corrupted. When the charger itself is detected as corrupted the update is entrusted to the permanent charger referenced 2.6.
• CRC Cyclic Redundancy Check
• Another download cause is the availability of a new version of the resident software.
• This new version can correct errors in the current version and / or add new features to this resident software.
• the detection by the decoder, during its startup phase a new version will cause, possibly under certain conditions, the download of this new version by the charger referenced 2.9 and its installation in the decoder.
• This stream will be transmitted by a broadcast station referenced 1.5 to a referenced satellite 1.6 which will broadcast it to the decoders referenced 1.7 to 1.10.
• the infrastructure described here is that of satellite broadcasting, but the scheme is the same for another type of broadcast that can be cable, terrestrial or even an internal network within a manufacturing plant.
• the flow calculated by the mixer referenced 1.4 will be issued by a server responsible for manufacturing the signal to the decoder.
• the download stream built will contain a version of the software for a given type of decoder but in the context of the invention it will be possible to mix modules belonging to several software versions in this stream.
• a number of identifiers are used to mark resident software versions and determine the decoders involved. We will mainly find the following identifiers which will play a determining role in the download process:
• the platform identifier composed in fact of the aggregation of two identifiers, PT indicating the type of platform which corresponds to the model of decoder and PV allowing to indicate the version number in the type of plate -form.
• This identifier therefore makes it possible to precisely identify a hardware decoder model.
• the product identifier, PR which will generally identify the operator using the decoder. Indeed, the same hardware decoder will not use the same software depending on the operator who will deploy it.
• the identifier of use, US which will allow for the same platform and the same product to differentiate the use that will be made of the platform. It is thus possible to differentiate, for example, a platform intended for a subscriber of a platform intended for testing or the like.
• a set of these identifiers is stored in the decoder to know the exact model of the platform, the operator and the purpose for which the decoder is intended.
• the download streams also contain a set of these identifiers to know the decoders for which the content software is created. In the context of the invention each segment will have its own set of parameters.
• a decoder In known manner when a decoder must be updated with a new software version for the reasons described above, it will use internal parameters to identify the stream containing the software version that is intended for it. It then connects to this stream and verifies that the platform, product, and usage identifiers contained in the stream match those it has. In this case he will download the software contained in the stream and memorize it.
• the update mechanism is based on the transmission of bit segments referenced 3.3. These segments correspond to a division of the memory images, referenced 3.1, of the different versions of resident software that we want to mix in the stream. These segments can correspond directly to the different modules composing the resident software versions or be the result of another cutting mode. These code segments are preceded by a header segment referenced 3.2 which describes the set of broadcast code segments. All segments are transported through MPEG sections referenced 3.4. Indeed MPEG transport streams are composed of a succession of sections of 188 bytes.
• the "header" segment illustrated in FIG. 4 is itself composed of a
• Header then a loop describing each of the code segments included in the stream and a signature field that authenticates this segment of headstrong and its content.
• the heading of the "header” segment includes the following fields:
• SegmentVersionld identifies the version of the segment. It is used to know if a segment is already present in the decoder and does not need to be downloaded.
• SegmentType, Segmentld correspond respectively to the type of segment (operating system, drivers, interface, 7) and its identifier in the type.
• HashMemoryType Hash type calculated on the segment stored in memory. Required to verify the authentication of the stream.
• SegStorageAdress storage address of the segment in memory
• CompressionType Type of compression on the segment transported in the stream. Lets you know if the segment is compressed or not and which compression algorithm was used.
• the transport format is based on the transport format in MPEG sections shown in Figure 5. It contains the information "YES”, “SegmentNb”, “FlowVersionld” described above. This information will be used to retrieve the data transmitted in the stream.
• Each module is indeed marked by configuration, or other, with a set of parameters PT, PV, PR and US indicating its destination.
• the analysis of these parameters makes it possible to identify the modules common to several versions. Then, when cutting these modules into segments, each segment will be marked with the parameter set PT, PV, PR and US corresponding to it, the common segments are not duplicated during the construction of the distribution medium, here the MPEG stream.
• a second step referenced E2 is to verify the authentication of this header segment with its signature.
• a third step referenced E3 consists of building the list of segments corresponding to the decoder performing the download by successively extracting (see table below):
• a fourth step, referenced E4 consists, in the case of an update due to the availability of a new version of software, to retrieve in this list only segments whose "SegVersionld” is different from “ SegVersionld "stored in memory and corresponding to the previous update.
• the recovered version is the same as that which one already has and one will recover the segments identified as corrupted.
• a fifth step is to check the integrity of each segment recovered through the CRC of each segment.
• a sixth step is to store the downloaded segments in memory.

Landscapes

• Engineering & Computer Science (AREA)
• Multimedia (AREA)
• Signal Processing (AREA)
• General Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Databases & Information Systems (AREA)
• Stored Programmes (AREA)
• Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
• Information Transfer Between Computers (AREA)

Priority Applications (5)

Applications Claiming Priority (2)

Publications (1)

Family

ID=34950480

Family Applications (1)

Country Status (7)

Families Citing this family (3)

Citations (5)

Family Cites Families (10)

• 2004
  • 2004-08-04 FR FR0451779A patent/FR2874146A1/fr active Pending
• 2005
  • 2005-08-02 CN CN2005800264634A patent/CN1993985B/zh not_active Expired - Fee Related
  • 2005-08-02 BR BRPI0513989-9A patent/BRPI0513989B1/pt not_active IP Right Cessation
  • 2005-08-02 EP EP05777844.1A patent/EP1774774B1/fr not_active Expired - Lifetime
  • 2005-08-02 WO PCT/EP2005/053768 patent/WO2006013204A1/fr not_active Ceased
  • 2005-08-02 JP JP2007524341A patent/JP5995394B2/ja not_active Expired - Fee Related
  • 2005-08-02 US US11/659,044 patent/US20090125965A1/en not_active Abandoned
• 2015
  • 2015-09-30 JP JP2015193607A patent/JP2016035757A/ja active Pending

Patent Citations (5)

Also Published As

Similar Documents

Legal Events