WO1997000563A1 - Method and system for receiving data packets in a unidirectional broadcasting system - Google Patents

Method and system for receiving data packets in a unidirectional broadcasting system Download PDF

Info

Publication number
WO1997000563A1
WO1997000563A1 PCT/EP1995/002348 EP9502348W WO9700563A1 WO 1997000563 A1 WO1997000563 A1 WO 1997000563A1 EP 9502348 W EP9502348 W EP 9502348W WO 9700563 A1 WO9700563 A1 WO 9700563A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
packet
data receiver
address
packets
Prior art date
Application number
PCT/EP1995/002348
Other languages
French (fr)
Inventor
Tullio Pirovano
Franco Maggioni
Original Assignee
International Business Machines Corporation
Ibm Semea S.P.A.
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 International Business Machines Corporation, Ibm Semea S.P.A. filed Critical International Business Machines Corporation
Priority to EP95924264A priority Critical patent/EP0834227B1/en
Priority to JP9502531A priority patent/JPH10511247A/en
Priority to US08/973,370 priority patent/US6167045A/en
Priority to JP50253197A priority patent/JP2995496B2/en
Priority to DE69507724T priority patent/DE69507724T2/en
Priority to PCT/EP1995/002348 priority patent/WO1997000563A1/en
Publication of WO1997000563A1 publication Critical patent/WO1997000563A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H60/00Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/09Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
    • H04H60/14Arrangements for conditional access to broadcast information or to broadcast-related services
    • H04H60/17Arrangements for conditional access to broadcast information or to broadcast-related services on recording information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/426Internal components of the client ; Characteristics thereof
    • H04N21/42684Client identification by a unique number or address, e.g. serial number, MAC address, socket ID
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643Communication protocols
    • H04N21/64322IP
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/167Systems rendering the television signal unintelligible and subsequently intelligible
    • H04N7/1675Providing digital key or authorisation information for generation or regeneration of the scrambling sequence
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H20/00Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/16Arrangements for broadcast or for distribution of identical information repeatedly
    • 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/70Aspects of broadcast communication characterised in that receivers can be addressed
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H60/00Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/09Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
    • H04H60/14Arrangements for conditional access to broadcast information or to broadcast-related services
    • H04H60/15Arrangements for conditional access to broadcast information or to broadcast-related services on receiving information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H60/00Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/35Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users
    • H04H60/38Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying broadcast time or space
    • H04H60/41Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying broadcast time or space for identifying broadcast space, i.e. broadcast channels, broadcast stations or broadcast areas
    • H04H60/44Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying broadcast time or space for identifying broadcast space, i.e. broadcast channels, broadcast stations or broadcast areas for identifying broadcast stations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/426Internal components of the client ; Characteristics thereof

Definitions

  • the invention relates to a method and system for the transmittal of data over a unidirectional broadcasting system.
  • a unidirectional broadcasting system consists of a number of information providers which are connected and send information to a broadcaster that has the function of transmitting the information received from the information provider to a plurality of data receivers through a broadcasting channel, wherein data receivers have no possibility of sending any information back to the information providers or to the broadcaster.
  • a broadcast system can reach a high number of data receivers in a large territory, theoretically without any limit. Examples of unidirectional broadcasting systems are television and radio broadcasting systems.
  • connection packets activate a "virtual" data channel, over which data can be conveyed from a calling terminal (information provider) to a called terminal (data receiver).
  • the connection can be terminated by a disconnection packet or by using timeout mechanisms.
  • Connection packets cause a calling terminal to be actually connected to a called terminal over the virtual data channel only if the destination address of the connection packet matches the specific calling terminal address, stored in the called terminal. This virtual data channel is identified only by the calling terminal address.
  • Data packets are identified only by the destination address so that data flow can be routed over the corresponding virtual data channel.
  • the information-providers act as sources of information consisting of a plurality of variable length messages and issue control packets, enabling/disabling packets and data packets.
  • Each data receiver has a unique address as a permanent attribute.
  • the enabling/disabling packets selectively enable or disable a specific data receiver or a specific group of data receivers.
  • the grouping of the data receivers is managed and updated remotely by each information provider through control packets.
  • connection oriented protocols used over broadcasting channels are critical because of the intrinsic high dependency of data reception on the connection packet. The loss of this packet causes the loss of all subsequent data packets.
  • a method for receiving unidirectionally transmitted data over a broadcasting channel said data consisting of a plurality of variable length messages, split into data packet, sent by at least one information provider to at least one data receiver, each data packet including at least two identifiers, a first identifier identifying the sending information provider and a second identifier identifying the message sent by said information provider owning the packets, the first and second identifiers forming a packet address, identifying univocally each message transmitted over the broadcasting channel, at least one data packet further including a third identifier identifying a data receiver, the method comprising the steps of: maintaining in the data receiver a list of information providers from which said data receiver is authorized to receive information on a selective basis; retrieving from each data packet received the packet address and said third identifier, if any; validating said packet address as relating to data directed to said data receiver, when said third identifier identifies said data receiver; making available to any user of the data receiver all the data
  • the invention allows to receive, on an optimistic base, data packets pertaining to a specific virtual broadcasting channel that has not been actually enabled because of a loss of the connection packet. For data packets received over this "orphan" connection the destination address is not known a priori. Even if it is not possible to establish whether these data are directed to a specific called terminal, data is received "sub judice" by any receiving terminal, having a possibility of access to the specific virtual broadcasting channel. Then, during subsequent transmissions of the same information message a receiving terminal can determine whether some "orphan" data packets where directed to it and consider them as properly received.
  • each receiving terminal has to collect and later evaluate such data , causing a reduced performance of the system.
  • a method which further comprises the step of discarding all the data packets stored in the data receiver identified by a same packet address, after receipt of a data packet including the same packet address and the third identifier not identifying said data receiver. Moreover, the method further comprises the step of discarding the data packets received including said same packet address. Finally, the method further comprises the step of selecting a time period and discarding all the data packets stored in the data receiver identified by a same packet address not validated within said time period.
  • a method is provided wherein the step of storing in the data receiver the received data packet identified by a non validated packet address, includes the step of encrypting the data packet information contents.
  • a system for receiving unidirectionally transmitted data over a broadcasting channel said data consisting of a plurality of variable length messages, split into data packet, sent by at least one information provider to at least one data receiver, each data packet including at least two identifiers, a first identifier identifying the sending information provider and a second identifier identifying the message sent by said information provider owning the packets, the first and second identifiers forming a packet address, identifying univocally each message transmitted over the broadcasting channel, at least one data packet further including a third identifier identifying a data receiver, the system comprising means for maintaining in the data receiver a list of information providers from which said data receiver is authorized to receive information on a selective basis;means for retrieving from each data packet received the packet address and said third identifier, if any; means for validating said packet address as relating to data directed to said data receiver, when said third identifier identifies said data receiver; means for making available to any user
  • Figure 1 depicts a schematic view of a broadcast system wherein the present invention can be implemented.
  • Figure 2 depicts a general packet structure according with the present invention.
  • Figure 3 depicts a block diagram of the apparatus implementing the transmission protocol of the invention
  • Figure 4 depicts a structure of the data file wherein the packets received are stored.
  • a plurality of information providers 1 a to 1 N are connected to a broadcaster 2 having the function of transmitting the data received from the information provider to a plurality of data receivers 4 a to 4 M through a broadcasting channel 3.
  • an information provider may also be referenced as "calling terminal” and a data receiver as "called terminal”.
  • the broadcaster 2 is a specific unit having the function of collecting and transmitting the date received from the information providers. However, the broadcaster may also transmit data originated by itself, acting in this case as an information provider.
  • Data is structured as digitally encoded packets having either data transfer or various control purposes, as it will be described in further detail.
  • IPT Information_provider_id> ⁇ ip_timeout>, where:
  • ⁇ information_provider_id> is a unique identifier of the source of data (information provider); ⁇ ip_timeout> identifies the timeout after which the information received by the information provider is removed from the data receiver storage memory.
  • This identifier preferably is assigned by the manufacturer and is the address of the data receiver.
  • Selective transmission is achieved by establishing a connection between an information provider, and a specific data receiver being identified by a unique identifier.
  • Each information provider may concurrently transmit, in time division, different messages or data arranged in packets to a data receiver, or to different data receivers or groups of data receivers.
  • Once a connection is established it is possible to transmit data from the information provider to the connected data receiver(s).
  • a connection is terminated either as the result of a specific command issued by the calling terminal or automatically after a given connection timeout.
  • the method herein described makes use of a "packet oriented" transmission protocol, where the generic packet has, preferably, a fixed length and a structure as depicted in Figure 2.
  • the data file is divided into a sequence of blocks and each block is divided into packet units of data to be sent to the data receiver. Then the data receiver rebuilt the complete data file re-assembling the packet units of data into blocks and then the blocks into the original file.
  • the ⁇ packet> format is
  • ⁇ packet>:: ⁇ packet_address> ⁇ packet_type> ⁇ data>.
  • ⁇ packet_address> identifies univocally each data file transmitted over the broadcasting system by a specific information provider
  • ⁇ information_provider_id> identifies the information provider or the source of information; ⁇ conversation_id> identifies the data file sent by the specified information provider, such a data file will be de-assembled in data packets during the transmission from the information provider to the data receiver(s). For every value of ⁇ information_provider_id>, the ⁇ conversation_id> is increased at each transmission of different data field and is cyclic, i.e. after having reached a maximum value it restart from the initial value. The maximum value is to be defined in order to prevent interference between different data file.
  • ⁇ packet_type> is an identifier, specifying the type of the packet as indicated in the following; ⁇ data> contains the data information or one or more control identifiers.
  • the ⁇ packet> structure further comprises:
  • ⁇ continuity_index> which is a progressive cyclic index of the packet which allows to identify whether a packet is being re-transmitted. This allows the decoder of any called terminal to recognize a newly received packet as a formerly received copy of the same packet; - ⁇ checksum> which is an error checking code that allows to detect the presence of errors in the packet.
  • This code can be implemented as a cyclic redundancy code (CRC) applied to the ⁇ data> field.
  • CRC cyclic redundancy code
  • the other fields of the packet ( ⁇ packet_address>, ⁇ continuity_index>, ⁇ packet_type>) can be protected with error detection and correction policies (i.e. Hamming code 8/4).
  • CR connection request packet It establishes a connection between a calling terminal and the called terminal(s). Establishing a connection means that the called terminal marks as available to the user all the packets carrying a ⁇ packet_address> equal to the one contained in CR packet.
  • connection_duration> identifies the timeout after which the data received associated to the ⁇ packet_address> are swapped out from the main memory to the storage memory to improve the system capability.
  • DR disconnection request packet It activates the swap-out process for the data received identified by the ⁇ packet_address>; at the same time it marks as available to the user all the packets carrying such ⁇ packet_address> if not already done.
  • this packet identifies the start of a block of data packets. In fact, to reduce the protocol overhead, it can be useful to send a sequence of data packets to form a block.
  • the structure of the block is such that the first data packet only conveys the block length, whereas the following packets convey data only.
  • the ⁇ data> field of this packet is so structured:
  • ⁇ data>:: ⁇ block_number> ⁇ blockJen> ⁇ data_unit>, wherein: ⁇ block_number> is the number of the block of the data file; ⁇ block_len> is the size in byte of the block; ⁇ data_unit> represents the starting packet unit of data of the block;
  • DF non-starting data packet This packet conveys only data.
  • a number of DF packets (up to the length specified in the DT packet) follows a DT packet.
  • This packet transfers the information necessary to reassemble the data block to form a higher level entity (i.e. a data file).
  • the ⁇ data> field of this packet is so structured:
  • ⁇ total_blocks_jn_file> is the total number of blocks into which the file was disassembled.
  • file_len> is the size in bytes of the file;
  • ⁇ fiie_val_code> is a code that allows to verify the completeness and correctness of the data file received
  • ⁇ file_name> is the name of the data file or a data file identifier.
  • This packet is used to distribute a central clock for adapter synchronization purposes.
  • the data receiver is in an IDLE state 300.
  • test 310 is performed to determine the type of the packet. If a CR or a DR ⁇ packet_type> value is received the ⁇ packet_address> field of the packet is retrieved to be compared with a list of packet addresses which are maintained by the data receiver: the Packet Address Stored Table (PAST). Each entry of PAST is formed by a field ( ⁇ packet_address_stored) and a pointer to a file ( ⁇ received_file>). Each ⁇ packet_address_stored> assumes one of three different values:
  • TRUE when a CR or DR packet including such ⁇ packet_address> has been received comprising a ⁇ receiver_address_id> which matches the data receiver ⁇ uniquejdentifier>; FALSE when a CR or DR packet including such ⁇ packet_address> has been received, comprising a ⁇ receiver_address_id> which does not match the data receiver ⁇ unique_identifier> UNKNOWN when no CR or DR packet including such ⁇ packet_address> has been received and the packet comes from a FRIEND information provider, i.e. the ⁇ information_provider_id> part of the ⁇ packet_address> is included in the Information Provider Table (IPT) of the data receiver.
  • IPT Information Provider Table
  • each ⁇ packet_address_stored> is associated, by the pointer, to a file ⁇ received_file> which will be used by the data receiver to store each data packet identified by such ⁇ packet_address>. If no corresponding ⁇ packet_address_stored> exists and the info ⁇ nation provider is a FRIEND one, a new entry is added to the list with UNKNOWN value and associated to a new empty ⁇ received_file>, as further described. In step 320 a test is performed to check if the ⁇ receiver_address_id> carried by the packet in the ⁇ data> field matches the data receiver identifier ⁇ unique_identifier>.
  • step 330 the control passes to step 330, wherein the value of the ⁇ packet_address_stored> corresponding to the ⁇ packet_address> is checked. Then, if the value is TRUE, the data receiver discards the packet in step 332; consequently the process returns to the idle state 300. If a FALSE or UNKNOWN value is retrieved, the control is passed to step 334, wherein the value of the ⁇ packet_address_stored> corresponding to the received ⁇ packet_address> is changed to TRUE, thus validating the ⁇ packet_address> as actually addresses to the specific receiver. In step 336 the pointed ⁇ received_file>, if any, becomes available to the user; therefore, the process returns to the idle state 300.
  • step 340 the ⁇ packet__address_stored> corresponding to the received ⁇ packet_address> is flagged as FALSE and in step 342 the associated ⁇ received_file>, if any, is discarded.
  • step 350 the process passes to step 350, wherein the ⁇ packet_address> included in the received packet is retrieved and compared with PAST in the data receiver. If the value of the corresponding ⁇ packet_address_stored> is TRUE, in step 352 the packet is stored in the pointed ⁇ received_file> and made available to the user in step 358; then the process retums to idle state 300. If the value is FALSE, in step 356, the packet is discarded without any other activity and the process return in the idle state 300.
  • step 354 the packet is stored in the pointed ⁇ received_file> but the packet, as the rest of the file, is not made available to the user, remaining "sub-judice” until it will be determined whether the file was directed or not to such data receiver. Finally the process return to the idle state 300.
  • step 360 it is tested if the information provider is a FRIEND one; if so, in step 362 a new entry is added with an UNKNOWN value and having the associated pointer pointing to a new empty ⁇ received._file>, then the control passes to step 354. If the result of the test 360 is no, then the control passes to step 356.
  • Each data block is made up of a DT packet 410 with a sequence of DF packets 420 so that the total block length (in bytes) reaches the one conveyed by DT packet, and the data blocks are written into a data file ( ⁇ received_file>) 400, corresponding to the one identified by the ⁇ packet_address> conveyed by the packets.
  • a validation bit 440 is added to each data packet (DT, DF) 410, 420 received, showing if the packet has been properly received, testing the ⁇ checksum> value conveyed by each packet.
  • the ⁇ received_file> maintains the visibility attribute of the data blocks, i.e. if the data blocks have the corresponding ⁇ packet_address_stored> value equal to UNKNOWN, the ⁇ received_file> will be hidden to the user.
  • many well known alternatives can be adopted ranging from simply vary the file attributes to more complex techniques like data encryption.
  • Each ⁇ received_file> is stored into a temporary directory.
  • the completed ⁇ received_file> is renamed with the value carried by the DV packet and moved to the user directory, thus making it available to the user (including the corrupted data).
  • Retransmissions, if any, of the same data have the same value of ⁇ packet_address> so it is possible to setup suitable merging policies among different data blocks.
  • the data packets DT and DF corresponding to the ones which have been lost or corrupted during a previous transmission are managed. Then if the retransmitted packet data corresponds to a lost data packet this is added to the ⁇ received_file>, while if such a data packet corresponds to a corrupted data packet this replaces the corrupted one into the ⁇ received_file>.
  • Any ⁇ received_file> with ⁇ packet_address_stored> equal to UNKNOWN remains hidden until a retransmission of the same data file occurs: in this case if a CR or DR packet is received and the conveyed ⁇ packet_address> is validated, as previously disclosed, then the corresponding ⁇ packet_address_stored> is set to TRUE and the visibility attribute of the ⁇ received_file> is modified accordingly.
  • the ⁇ received_file> corresponding to the ⁇ packet_address> conveyed by the packet is swapped into the main memory, to improve the capability of the process while the data block are being collected, and it will be swapped out to the disk storage, when one of the following conditions occurs: a DR packet with the same ⁇ packet_address> is received; the timeout, carried in the ⁇ connection_duration> field of the CR packet, is lapsed; - a new CR packet has to be received and the main memory has no more space available for storing the new ⁇ received_file>.
  • n ⁇ received_files> can be stored at the same time in the main memory with a FIFO algorithm managing the in/out procedure for each ⁇ received_file>.
  • a garbage collection routine has to be setup to delete each UNKNOWN

Abstract

Information providers act as sources of information consisting of a plurality of variable length messages and issue control packets, enabling/disabling packets and data packets. Each data receiver has a unique address as a permanent attribute. The enabling/disabling packets selectively enable or disable a specific data receiver or a specific group of data receivers. Therefore to avoid that the loss of the enabling/disabling packet leads to the loss of the corresponding whole set of packets, each data receiver stores packets for later use in the re-establishment of the entire set of transmission packets. However, only data packets provided by any FRIEND information provider (i.e. information provider from which the data receiver is authorized to receive information on a selective basis) are managed by the data receiver. Then when, during a re-transmission, an enabling/disabling packet related to the information stored into the data receiver is received, such information is immediately made available to the user of the data receiver, without waiting for its complete re-transmission.

Description

Method and system for receiving data packets in a unidirectional broadcasting system
The invention relates to a method and system for the transmittal of data over a unidirectional broadcasting system.
A unidirectional broadcasting system consists of a number of information providers which are connected and send information to a broadcaster that has the function of transmitting the information received from the information provider to a plurality of data receivers through a broadcasting channel, wherein data receivers have no possibility of sending any information back to the information providers or to the broadcaster. A broadcast system can reach a high number of data receivers in a large territory, theoretically without any limit. Examples of unidirectional broadcasting systems are television and radio broadcasting systems.
The availability of well-working broadcasting systems such as the television systems, able to allow the transmission of data to many end-users distributed in a large territory over a broadcast channel without considerable added costs, increases the research in such a field.
A method of providing unidirectional transmittal of data from a plurality of information providers to one or more data receivers over a broadcasting system is disclosed in the published European Patent Application EP-491069-A1. This application describes a connection-oriented transmission protocol wherein connection packets activate a "virtual" data channel, over which data can be conveyed from a calling terminal (information provider) to a called terminal (data receiver). The connection can be terminated by a disconnection packet or by using timeout mechanisms. Connection packets cause a calling terminal to be actually connected to a called terminal over the virtual data channel only if the destination address of the connection packet matches the specific calling terminal address, stored in the called terminal. This virtual data channel is identified only by the calling terminal address. Data packets are identified only by the destination address so that data flow can be routed over the corresponding virtual data channel. The information-providers act as sources of information consisting of a plurality of variable length messages and issue control packets, enabling/disabling packets and data packets. Each data receiver has a unique address as a permanent attribute. The enabling/disabling packets selectively enable or disable a specific data receiver or a specific group of data receivers. The grouping of the data receivers is managed and updated remotely by each information provider through control packets.
However, when the transmission system is unidirectional, like in a broadcasting channel, information is transmitted on an optimistic basis. In fact, through the broadcasting channel, the called terminal cannot inform back the calling terminal about errors occurring either over the channel or in the called terminal itself (e.g. terminal failure or temporary problems, unrecovered long duration noise, etc). Beside that, connection oriented protocols used over broadcasting channels are critical because of the intrinsic high dependency of data reception on the connection packet. The loss of this packet causes the loss of all subsequent data packets.
Consequently, it can be useful to retransmit the same information over the broadcasting channels, at different times. For example, the whole set of packets could be retransmitted again more times at time intervals in the optimistic expectation that the cause of the loss of the connection packet has ceased or has been removed and that this favourable condition lasts for a time period sufficient for the data receiver to successfully and consecutively receive the entire set of packets. Unfortunately, experience has shown that transmission disturbances or interruptions may last for long times and in some cases the above approach is unsuccessful. In fact the possibility of loosing the connection packet upon long duration transmission disturbances or interruptions leads to the loss of the corresponding whole set of packets thus frustrating the expected benefits of the retransmission.
Therefore there is a need for a method and system allowing a data receiver to receive individual data packets or groups of data packets for later use in the re-establishment of the entire set of transmission packets.
In accordance with the present invention, there is provided a method for receiving unidirectionally transmitted data over a broadcasting channel, said data consisting of a plurality of variable length messages, split into data packet, sent by at least one information provider to at least one data receiver, each data packet including at least two identifiers, a first identifier identifying the sending information provider and a second identifier identifying the message sent by said information provider owning the packets, the first and second identifiers forming a packet address, identifying univocally each message transmitted over the broadcasting channel, at least one data packet further including a third identifier identifying a data receiver, the method comprising the steps of: maintaining in the data receiver a list of information providers from which said data receiver is authorized to receive information on a selective basis; retrieving from each data packet received the packet address and said third identifier, if any; validating said packet address as relating to data directed to said data receiver, when said third identifier identifies said data receiver; making available to any user of the data receiver all the data packets identified by the validated packet address; the method being characterized by further comprising the steps of: storing in said data receiver each data packet having the first identifier, contained in the packet address, included in said list of information providers, provided that the data receiver has not received yet any data packet including said third identifier validating said packet address; making available to any user of the data receiver all the stored packets identified by said packet address, after the receipt of said third identifier validating said packet address.
The invention allows to receive, on an optimistic base, data packets pertaining to a specific virtual broadcasting channel that has not been actually enabled because of a loss of the connection packet. For data packets received over this "orphan" connection the destination address is not known a priori. Even if it is not possible to establish whether these data are directed to a specific called terminal, data is received "sub judice" by any receiving terminal, having a possibility of access to the specific virtual broadcasting channel. Then, during subsequent transmissions of the same information message a receiving terminal can determine whether some "orphan" data packets where directed to it and consider them as properly received.
However, some difficulties still remain if a lot of "orphan" data packets are received "sub judice" by one or more receiving terminal and stored. In this case, each receiving terminal has to collect and later evaluate such data , causing a reduced performance of the system.
In one arrangement of the invention is provided a method which further comprises the step of discarding all the data packets stored in the data receiver identified by a same packet address, after receipt of a data packet including the same packet address and the third identifier not identifying said data receiver. Moreover, the method further comprises the step of discarding the data packets received including said same packet address. Finally, the method further comprises the step of selecting a time period and discarding all the data packets stored in the data receiver identified by a same packet address not validated within said time period.
This method overcomes the above difficulties. However, the process of storing in a data receiver some information which can be not directed to it, may cause some security problem. In fact, a user may try to misappropriate such stored information. Therefore, in a preferred embodiment of the present invention, a method is provided wherein the step of storing in the data receiver the received data packet identified by a non validated packet address, includes the step of encrypting the data packet information contents.
Viewing another aspect of the present invention, there is also provided a system for receiving unidirectionally transmitted data over a broadcasting channel, said data consisting of a plurality of variable length messages, split into data packet, sent by at least one information provider to at least one data receiver, each data packet including at least two identifiers, a first identifier identifying the sending information provider and a second identifier identifying the message sent by said information provider owning the packets, the first and second identifiers forming a packet address, identifying univocally each message transmitted over the broadcasting channel, at least one data packet further including a third identifier identifying a data receiver, the system comprising means for maintaining in the data receiver a list of information providers from which said data receiver is authorized to receive information on a selective basis;means for retrieving from each data packet received the packet address and said third identifier, if any; means for validating said packet address as relating to data directed to said data receiver, when said third identifier identifies said data receiver; means for making available to any user of the data receiver all the data packets identified by the validated packet address; the system being characterized by further comprising: means for storing in said data receiver each data packet having the first identifier, contained in the packet address, included in said list of information providers, provided that the data receiver has not received yet any data packet including said third identifier validating said packet address; means for making available to any user of the data receiver all the stored packets identified by said packet address, after the receipt of said third identifier validating said packet address.
An embodiment of the present invention will now be described, in connection with the cited European Patent Application EP-491069-A1 , herein included by reference, and with the accompanying drawings; wherein:
Figure 1 depicts a schematic view of a broadcast system wherein the present invention can be implemented.
Figure 2 depicts a general packet structure according with the present invention. Figure 3 depicts a block diagram of the apparatus implementing the transmission protocol of the invention Figure 4 depicts a structure of the data file wherein the packets received are stored. Referring to Figure 1, a plurality of information providers 1a to 1N are connected to a broadcaster 2 having the function of transmitting the data received from the information provider to a plurality of data receivers 4a to 4M through a broadcasting channel 3. in the following an information provider may also be referenced as "calling terminal" and a data receiver as "called terminal".
The broadcaster 2 is a specific unit having the function of collecting and transmitting the date received from the information providers. However, the broadcaster may also transmit data originated by itself, acting in this case as an information provider.
An improved selective distribution mechanism ensuring N x M unidirectional connection over a broadcasting channel between N information providers and M data receivers is provided. Data is structured as digitally encoded packets having either data transfer or various control purposes, as it will be described in further detail.
A state-of-the-art data receiver in a unidirectional broadcasting system is provided with the following characteristics:
a) it comprises a non-volatile memory used to store a list of the information providers from which the data receiver is authorized to receive information: the Information Provider Table
(IPT). The list is comprised of the following data: <information_provider_id><ip_timeout>, where:
<information_provider_id> is a unique identifier of the source of data (information provider); <ip_timeout> identifies the timeout after which the information received by the information provider is removed from the data receiver storage memory.
b) it is identified by a unique identifier <unique_identifier>, representing a permanent attribute. This identifier preferably is assigned by the manufacturer and is the address of the data receiver.
Selective transmission is achieved by establishing a connection between an information provider, and a specific data receiver being identified by a unique identifier. Each information provider may concurrently transmit, in time division, different messages or data arranged in packets to a data receiver, or to different data receivers or groups of data receivers. Once a connection is established, it is possible to transmit data from the information provider to the connected data receiver(s). A connection is terminated either as the result of a specific command issued by the calling terminal or automatically after a given connection timeout.
The method herein described makes use of a "packet oriented" transmission protocol, where the generic packet has, preferably, a fixed length and a structure as depicted in Figure 2. In such a protocol, the data file is divided into a sequence of blocks and each block is divided into packet units of data to be sent to the data receiver. Then the data receiver rebuilt the complete data file re-assembling the packet units of data into blocks and then the blocks into the original file. In the following the symbol "::=" means "is composed by". The <packet> format is
<packet>::=<packet_address><packet_type><data>. The <packet_address> format is <packet_address>::=<informationj3rovider_id><conversation_id>, wherein:
<packet_address> identifies univocally each data file transmitted over the broadcasting system by a specific information provider;
<information_provider_id> identifies the information provider or the source of information; <conversation_id> identifies the data file sent by the specified information provider, such a data file will be de-assembled in data packets during the transmission from the information provider to the data receiver(s). For every value of <information_provider_id>, the <conversation_id> is increased at each transmission of different data field and is cyclic, i.e. after having reached a maximum value it restart from the initial value. The maximum value is to be defined in order to prevent interference between different data file. <packet_type> is an identifier, specifying the type of the packet as indicated in the following; <data> contains the data information or one or more control identifiers.
Preferably, the <packet> structure further comprises:
<continuity_index> which is a progressive cyclic index of the packet which allows to identify whether a packet is being re-transmitted. This allows the decoder of any called terminal to recognize a newly received packet as a formerly received copy of the same packet; - <checksum> which is an error checking code that allows to detect the presence of errors in the packet. This code can be implemented as a cyclic redundancy code (CRC) applied to the <data> field. The other fields of the packet (<packet_address>, <continuity_index>, <packet_type>) can be protected with error detection and correction policies (i.e. Hamming code 8/4). - <packet_code> which identifies the beginning of the <packet> for synchronization purposes. A preferred list of values assumed by <packet_type> with the related <data> field structure einafter described. This list contains all the information which the present invention needs rove the state-of-the-art unidirectional broadcasting system.
CR connection request packet. It establishes a connection between a calling terminal and the called terminal(s). Establishing a connection means that the called terminal marks as available to the user all the packets carrying a <packet_address> equal to the one contained in CR packet. The <data> field is so structured: <data>::=<receiver_address_id><connection_duration><data_info> Where <receiver_address_id> identifies the address of the called terminal and
<connection_duration> identifies the timeout after which the data received associated to the <packet_address> are swapped out from the main memory to the storage memory to improve the system capability.
DR disconnection request packet. It activates the swap-out process for the data received identified by the <packet_address>; at the same time it marks as available to the user all the packets carrying such <packet_address> if not already done. The <data> field is so structured: <data>::=<receiver_address>
DT starting data packet. Since the data file is disassembled into blocks, this packet identifies the start of a block of data packets. In fact, to reduce the protocol overhead, it can be useful to send a sequence of data packets to form a block. The structure of the block is such that the first data packet only conveys the block length, whereas the following packets convey data only. The <data> field of this packet is so structured:
<data>::=<block_number><blockJen><data_unit>, wherein: <block_number> is the number of the block of the data file; <block_len> is the size in byte of the block; <data_unit> represents the starting packet unit of data of the block;
DF non-starting data packet. This packet conveys only data. A number of DF packets (up to the length specified in the DT packet) follows a DT packet. The <data> field of the packet is so structured: <data>::=<data_unit> <data_unit> represents a packet unit of data of the block <block number> identified in the previously received DT packet.
DV vital information packet. This packet transfers the information necessary to reassemble the data block to form a higher level entity (i.e. a data file). The <data> field of this packet is so structured:
<data>:=<total_blocks_in_file><fileJen><file_vaLcode><file_name> where:
<total_blocks_jn_file> is the total number of blocks into which the file was disassembled. <file_len> is the size in bytes of the file;
<fiie_val_code> is a code that allows to verify the completeness and correctness of the data file received;
<file_name> is the name of the data file or a data file identifier.
TS time stamp packet. This packet is used to distribute a central clock for adapter synchronization purposes.
In addition to the above other state-of-the-art packet types are used, for instance to manage groups of data receivers.
Hereinafter only the part referring to the new improvement with respect to the prior art methods will be described, with reference to the previously defined packet structure and types and to Figure 3.
At start time, the data receiver is in an IDLE state 300. When a packet is received, test 310 is performed to determine the type of the packet. If a CR or a DR <packet_type> value is received the <packet_address> field of the packet is retrieved to be compared with a list of packet addresses which are maintained by the data receiver: the Packet Address Stored Table (PAST). Each entry of PAST is formed by a field (<packet_address_stored) and a pointer to a file (<received_file>). Each <packet_address_stored> assumes one of three different values:
TRUE when a CR or DR packet including such <packet_address> has been received, comprising a <receiver_address_id> which matches the data receiver <uniquejdentifier>; FALSE when a CR or DR packet including such <packet_address> has been received, comprising a <receiver_address_id> which does not match the data receiver <unique_identifier> UNKNOWN when no CR or DR packet including such <packet_address> has been received and the packet comes from a FRIEND information provider, i.e. the <information_provider_id> part of the <packet_address> is included in the Information Provider Table (IPT) of the data receiver.
Then, each <packet_address_stored> is associated, by the pointer, to a file <received_file> which will be used by the data receiver to store each data packet identified by such <packet_address>. If no corresponding <packet_address_stored> exists and the infoπnation provider is a FRIEND one, a new entry is added to the list with UNKNOWN value and associated to a new empty <received_file>, as further described. In step 320 a test is performed to check if the <receiver_address_id> carried by the packet in the <data> field matches the data receiver identifier <unique_identifier>. If so the control passes to step 330, wherein the value of the <packet_address_stored> corresponding to the <packet_address> is checked. Then, if the value is TRUE, the data receiver discards the packet in step 332; consequently the process returns to the idle state 300. If a FALSE or UNKNOWN value is retrieved, the control is passed to step 334, wherein the value of the <packet_address_stored> corresponding to the received <packet_address> is changed to TRUE, thus validating the <packet_address> as actually addresses to the specific receiver. In step 336 the pointed <received_file>, if any, becomes available to the user; therefore, the process returns to the idle state 300.
Coming back to step 320, if the match is unsuccessful, in step 340 the <packet__address_stored> corresponding to the received <packet_address> is flagged as FALSE and in step 342 the associated <received_file>, if any, is discarded.
If the type of the packet value is other than 'CR' or OR', then from test 310 the process passes to step 350, wherein the <packet_address> included in the received packet is retrieved and compared with PAST in the data receiver. If the value of the corresponding <packet_address_stored> is TRUE, in step 352 the packet is stored in the pointed <received_file> and made available to the user in step 358; then the process retums to idle state 300. If the value is FALSE, in step 356, the packet is discarded without any other activity and the process return in the idle state 300. If the value is UNKNOWN, in step 354 the packet is stored in the pointed <received_file> but the packet, as the rest of the file, is not made available to the user, remaining "sub-judice" until it will be determined whether the file was directed or not to such data receiver. Finally the process return to the idle state 300. Then, if in step 350 no <packet_address__stored> corresponding to the <packet_address> has been found in PAST, in step 360 it is tested if the information provider is a FRIEND one; if so, in step 362 a new entry is added with an UNKNOWN value and having the associated pointer pointing to a new empty <received._file>, then the control passes to step 354. If the result of the test 360 is no, then the control passes to step 356.
Referring now to Figure 4, the process to rebuild a data file will be disclosed. When data packets (DT, DF, DV) are received, they are assembled into data blocks 430. Each data block is made up of a DT packet 410 with a sequence of DF packets 420 so that the total block length (in bytes) reaches the one conveyed by DT packet, and the data blocks are written into a data file (<received_file>) 400, corresponding to the one identified by the <packet_address> conveyed by the packets. Preferably, a validation bit 440 is added to each data packet (DT, DF) 410, 420 received, showing if the packet has been properly received, testing the <checksum> value conveyed by each packet. The <received_file> maintains the visibility attribute of the data blocks, i.e. if the data blocks have the corresponding <packet_address_stored> value equal to UNKNOWN, the <received_file> will be hidden to the user. To reach this goal, many well known alternatives can be adopted ranging from simply vary the file attributes to more complex techniques like data encryption.
Each <received_file> is stored into a temporary directory. When all the data blocks have been received and the total length (<file_len>) of the <received_file> is reached or a timeout is lapsed, the completed <received_file> is renamed with the value carried by the DV packet and moved to the user directory, thus making it available to the user (including the corrupted data). Retransmissions, if any, of the same data have the same value of <packet_address> so it is possible to setup suitable merging policies among different data blocks. For instance, in a preferred embodiment, during a retransmission of a data file only the data packets DT and DF corresponding to the ones which have been lost or corrupted during a previous transmission (i.e. data packet stored having the validation bit equal to false) are managed. Then if the retransmitted packet data corresponds to a lost data packet this is added to the <received_file>, while if such a data packet corresponds to a corrupted data packet this replaces the corrupted one into the <received_file>. Any <received_file> with <packet_address_stored> equal to UNKNOWN remains hidden until a retransmission of the same data file occurs: in this case if a CR or DR packet is received and the conveyed <packet_address> is validated, as previously disclosed, then the corresponding <packet_address_stored> is set to TRUE and the visibility attribute of the <received_file> is modified accordingly.
Preferably, when a CR packet is received the <received_file> corresponding to the <packet_address> conveyed by the packet is swapped into the main memory, to improve the capability of the process while the data block are being collected, and it will be swapped out to the disk storage, when one of the following conditions occurs: a DR packet with the same <packet_address> is received; the timeout, carried in the <connection_duration> field of the CR packet, is lapsed; - a new CR packet has to be received and the main memory has no more space available for storing the new <received_file>. In the preferred embodiment n <received_files> can be stored at the same time in the main memory with a FIFO algorithm managing the in/out procedure for each <received_file>.
Preferably, a garbage collection routine has to be setup to delete each UNKNOWN
<received_file> which is older than the defined parameter <ip_timeout> contained in the IPT. In this way each different information provider is provided with a different timeout, depending on the type of the data sent over the broadcasting channel

Claims

1. A method for receiving unidirectionally transmitted data over a broadcasting channel, said data consisting of a plurality of variable length messages, split into data packet, sent by at least one information provider to at least one data receiver, each data packet including at least two identifiers, a first identifier identifying the sending information provider and a second identifier identifying the message sent by said information provider owning the packets, the first and second identifiers forming a packet address, identifying univocally each message transmitted over the broadcasting channel, at least one data packet further including a third identifier identifying a data receiver, the method comprising the steps of maintaining in the data receiver a list of information providers from which said data receiver is authorized to receive information on a selective basis; retrieving from each data packet received the packet address and said third identifier, if any; validating said packet address as relating to data directed to said data receiver, when said third identifier identifies said data receiver; making available to any user of the data receiver all the data packets identified by the validated packet address; the method being characterized by further comprising the steps of: storing in said data receiver each data packet having the first identifier, contained in the packet address, included in said list of information providers, provided that the data receiver has not received yet any data packet including said third identifier validating said packet address; making available to any user of the data receiver ail the stored packets identified by said packet address, after receipt of said third identifier validating said packet address.
2. A method as claimed in claim 1 further comprising the step of discarding all the data packets stored in the data receiver identified by a same packet address, after receipt of a data packet including said same packet address and said third identifier not identifying said data receiver.
3. A method as claimed claim 2 further comprising the step of discarding the data packets received including said same packet address.
4. A method as claimed in any preceding claim further comprising the step of selecting a time period and discarding all the data packets stored in the data receiver identified by a same packet address not validated within said time period.
5. A method as claimed in any preceeding claim wherein the step of storing in the data receiver the received data packet identified by a non validated packet address, includes the step of encrypting the data packet information contents.
6. A system for receiving unidirectionally transmitted data over a broadcasting channel, said data consisting of a plurality of variable length messages, split into data packet, sent by at least one information provider to at least one data receiver, each data packet including at least two identifiers, a first identifier identifying the sending information provider and a second identifier identifying the message sent by said information provider owning the packets, the first and second identifiers forming a packet address, identifying univocally each message transmitted over the broadcasting channel, at least one data packet further including a third identifier identifying a data receiver, the system comprising means for maintaining in the data receiver a list of information providers from which said data receiver is authorized to receive information on a selective basis; means for retrieving from each data packet received the packet address and said third identifier, if any; means for validating said packet address as relating to data directed to said data receiver, when said third identifier identifies said data receiver; means for making available to any user of the data receiver all the data packets identified by the validated packet address; the system being characterized by: means for storing in said data receiver each data packet having the first identifier, contained in the packet address, included in said list of information providers, provided that the data receiver has not received yet any data packet including said third identifier validating said packet address; means for making available to any user of the data receiver all the stored packets identified by said packet address, after the receipt of said third identifier validating said packet address.
7. The system as claimed in claim 6 further comprising means for discarding all the data packets stored in the data receiver identified by a same packet address, after receipt of a data packet including said same packet address and said third identifier not identifying said data receiver.
8. The system as claimed in claim 7 further comprising means for discarding the data packets received including said same packet address.
9. The system as claimed in any of claims 6 to 8 further comprising means for selecting a time period and means for discarding all the data packets stored in the data receiver identified by a same packet address not validated within said time period.
10. The system as claimed in any of claims 6 to 9 wherein said means of storing in the data receiver the received data packet identified by a non validated packet address, include means for encrypting the data packet information contents.
PCT/EP1995/002348 1995-06-19 1995-06-19 Method and system for receiving data packets in a unidirectional broadcasting system WO1997000563A1 (en)

Priority Applications (6)

Application Number Priority Date Filing Date Title
EP95924264A EP0834227B1 (en) 1995-06-19 1995-06-19 Method and system for receiving data packets in a unidirectional broadcasting system
JP9502531A JPH10511247A (en) 1995-06-19 1995-06-19 Method and system for receiving data packets in a unidirectional broadcast system
US08/973,370 US6167045A (en) 1995-06-19 1995-06-19 Method and system for receiving data packets in a unidirectional broadcasting system
JP50253197A JP2995496B2 (en) 1995-06-19 1995-06-19 Method and system for receiving data packets in a unidirectional broadcast system
DE69507724T DE69507724T2 (en) 1995-06-19 1995-06-19 METHOD AND METHOD FOR RECEIVING DATA PACKAGES IN A ONE-WAY TRANSMISSION DEVICE
PCT/EP1995/002348 WO1997000563A1 (en) 1995-06-19 1995-06-19 Method and system for receiving data packets in a unidirectional broadcasting system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP1995/002348 WO1997000563A1 (en) 1995-06-19 1995-06-19 Method and system for receiving data packets in a unidirectional broadcasting system

Publications (1)

Publication Number Publication Date
WO1997000563A1 true WO1997000563A1 (en) 1997-01-03

Family

ID=8166042

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP1995/002348 WO1997000563A1 (en) 1995-06-19 1995-06-19 Method and system for receiving data packets in a unidirectional broadcasting system

Country Status (5)

Country Link
US (1) US6167045A (en)
EP (1) EP0834227B1 (en)
JP (2) JP2995496B2 (en)
DE (1) DE69507724T2 (en)
WO (1) WO1997000563A1 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1113600A3 (en) * 1999-10-28 2003-01-02 Matsushita Electric Industrial Co., Ltd. Device for broadcasting a programme with one or more receiving terminal identifiers which are transmitted with the programme for identifying a receiving terminal and receiving device for receiving this programme
US6598070B1 (en) 1998-11-24 2003-07-22 Nec Corporation Data sending/receiving system, data receiving device, and data receiving method based on generating a temporary file-name and temporary file-size according to a position information before storing on the receiving side
WO2018090611A1 (en) * 2016-11-21 2018-05-24 深圳市中兴微电子技术有限公司 Packet processing method and device, and computer storage medium

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6704788B1 (en) * 1999-07-06 2004-03-09 General Instrument Corporation Method and apparatus for transmitting and reassembling packetized data in large scale networks
JO2195B1 (en) * 1999-09-10 2003-12-23 ناجرا كارد اس ايه Messages transmission process and system for data bases
US6510144B1 (en) * 1999-12-07 2003-01-21 Cisco Technology, Inc. Network layer support to enhance the transport layer performance in mobile and wireless environments
US7171493B2 (en) * 2001-12-19 2007-01-30 The Charles Stark Draper Laboratory Camouflage of network traffic to resist attack
JP4125160B2 (en) * 2003-03-06 2008-07-30 キヤノン株式会社 Transmitter and receiver
CN104094249B (en) * 2012-04-25 2018-09-28 企业服务发展公司有限责任合伙企业 It is transmitted using the file of XML
US10263916B2 (en) 2012-12-03 2019-04-16 Hewlett Packard Enterprise Development Lp System and method for message handling in a network device
WO2020212611A1 (en) * 2019-04-18 2020-10-22 Medicus Ai Gmbh Method and system for transmitting combined parts of distributed data

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0256526A2 (en) * 1986-08-14 1988-02-24 Nec Corporation Packet-switched communications network for efficiently switching non-burst signals
US4949394A (en) * 1988-02-29 1990-08-14 Kabushiki Kaisha Kenwood Addressable PCM music broadcast receiver
US4991207A (en) * 1988-03-26 1991-02-05 Kabushiki Kaisha Kenwood One-way address transmission system of PCM music
WO1992017014A1 (en) * 1991-03-22 1992-10-01 Gpt Limited Connectionless switching for an atm switch
EP0528730A1 (en) * 1991-08-19 1993-02-24 France Telecom Method for emitting and receiving personalized programs

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4926375A (en) * 1987-05-05 1990-05-15 Ge Fanuc Automation North America, Inc. Multiple nodes broadcast communication method with receiver identification by bit position in transferred massage
US5128934A (en) * 1990-06-29 1992-07-07 Motorola, Inc. Multiple transmitter message transmission system and method therefor
EP0491069A1 (en) * 1990-12-18 1992-06-24 International Business Machines Corporation Selective data distribution method using unidirectional broadcast or multicast transmission
US5724357A (en) * 1992-01-28 1998-03-03 Fleetwood Group, Inc. Remote response system and data transfer protocol
CA2146132C (en) * 1992-10-01 1998-12-29 Leon Jasinski Selective call receiver capable of requesting information from a communication system and method therefor
US5398021A (en) * 1993-07-19 1995-03-14 Motorola, Inc. Reliable information service message delivery system
US5715243A (en) * 1995-03-27 1998-02-03 Hewlett-Packard Company Information service provider for transmitting multiple rate wireless information

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0256526A2 (en) * 1986-08-14 1988-02-24 Nec Corporation Packet-switched communications network for efficiently switching non-burst signals
US4949394A (en) * 1988-02-29 1990-08-14 Kabushiki Kaisha Kenwood Addressable PCM music broadcast receiver
US4991207A (en) * 1988-03-26 1991-02-05 Kabushiki Kaisha Kenwood One-way address transmission system of PCM music
WO1992017014A1 (en) * 1991-03-22 1992-10-01 Gpt Limited Connectionless switching for an atm switch
EP0528730A1 (en) * 1991-08-19 1993-02-24 France Telecom Method for emitting and receiving personalized programs

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6598070B1 (en) 1998-11-24 2003-07-22 Nec Corporation Data sending/receiving system, data receiving device, and data receiving method based on generating a temporary file-name and temporary file-size according to a position information before storing on the receiving side
EP1113600A3 (en) * 1999-10-28 2003-01-02 Matsushita Electric Industrial Co., Ltd. Device for broadcasting a programme with one or more receiving terminal identifiers which are transmitted with the programme for identifying a receiving terminal and receiving device for receiving this programme
WO2018090611A1 (en) * 2016-11-21 2018-05-24 深圳市中兴微电子技术有限公司 Packet processing method and device, and computer storage medium

Also Published As

Publication number Publication date
EP0834227B1 (en) 1999-02-03
DE69507724D1 (en) 1999-03-18
US6167045A (en) 2000-12-26
JP2995496B2 (en) 1999-12-27
EP0834227A1 (en) 1998-04-08
JPH10511247A (en) 1998-10-27
DE69507724T2 (en) 1999-09-30

Similar Documents

Publication Publication Date Title
US4908828A (en) Method for error free message reception
US5838668A (en) Satellite broadcast communications system
EP1555774B1 (en) Data receiving apparatus and data receiving method
US7937638B2 (en) Error correction apparatus and method
KR100968086B1 (en) Method and apparatus for enhanced file distribution in multicast or broadcast
US5175765A (en) Robust data broadcast over a distributed network with malicious failures
US20150295706A1 (en) System and method for transmitting digital multimedia data with analog broadcast data
US7944921B2 (en) Method and system for distributing mobile broadcast service and mobile terminal
US6449654B1 (en) System and methods for retransmitting corrupted data
EP0834227B1 (en) Method and system for receiving data packets in a unidirectional broadcasting system
EP0959635A1 (en) Connectionless downloading of software to wireless terminals
KR100848273B1 (en) Device and method for processing file in digital broadcasting receiver
KR20000075358A (en) Variable-length data transmitting and receiving apparatus in accordance with radio link protocol for a mobile telecommunication system and method thereof
NZ521031A (en) Vending machines sending data comprising only differences between new and reference data to central processor
WO2003043259A1 (en) Method and device for retransmission of transmitted units
RU2155451C2 (en) Method for information distribution in mass terminal network and device which implements said method
CN115334174A (en) Multichannel matching method and communication method based on Subset-037 protocol
JPH05252087A (en) Communication system
CN110808858A (en) Method and device for transmitting 5G access network data based on micro-service unit
US6781987B1 (en) Method for packet transmission with error detection codes
JPH09512411A (en) Packetized message transmission system, transmitter and receiver used in such system, and packetized message transmitting / receiving method
US8407552B2 (en) Method based on error corrector codes, applicable to a variable rate multimedia datastream
EP0711064B1 (en) Switching of a terminal, such as a facsimile terminal, to one of two channels
JP2003234739A (en) Digital data transmitting/receiving system and digital data transmitting/receiving method
CN115065942A (en) Method and device for receiving and transmitting auxiliary broadcast network of mobile communication network

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1995924264

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 08973370

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 1995924264

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: CA

WWG Wipo information: grant in national office

Ref document number: 1995924264

Country of ref document: EP