Source: http://www.google.com/patents/US7536466?dq=6978253
Timestamp: 2014-03-10 08:15:26
Document Index: 18737967

Matched Legal Cases: ['art 61', 'art 61', 'art 62', 'art 61', 'art 62', 'art 62', 'arts 104', 'art 61', 'art 61', 'art 62', 'art 61', 'art 62', 'art 62', 'arts 62', 'art 114', 'art 114', 'art 114', 'art 114']

Patent US7536466 - Sending-receiving system, sender apparatus, sending method, receiver ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA sending-receiving system, a sender apparatus, a sending method, a receiver apparatus, a receiving method, a recording medium, and a program for improving the reliability of communication. A TS packet sequence furnished with an RTP header includes audio data. The audio data alone constitutes a TS packet...http://www.google.com/patents/US7536466?utm_source=gb-gplus-sharePatent US7536466 - Sending-receiving system, sender apparatus, sending method, receiver apparatus, receiving method, recording medium, and program for improving communication reliabilityAdvanced Patent SearchPublication numberUS7536466 B2Publication typeGrantApplication numberUS 10/549,879Publication dateMay 19, 2009Filing dateMar 12, 2004Priority dateMar 18, 2003Fee statusLapsedAlso published asCN1757214A, EP1605659A1, US20060179151, WO2004084516A1Publication number10549879, 549879, US 7536466 B2, US 7536466B2, US-B2-7536466, US7536466 B2, US7536466B2InventorsKaoru Yanamoto, Tsuyoshi MasatoOriginal AssigneeSony CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (11), Non-Patent Citations (1), Referenced by (3), Classifications (10), Legal Events (4) External Links: USPTO, USPTO Assignment, EspacenetSending-receiving system, sender apparatus, sending method, receiver apparatus, receiving method, recording medium, and program for improving communication reliabilityUS 7536466 B2Abstract A sending-receiving system, a sender apparatus, a sending method, a receiver apparatus, a receiving method, a recording medium, and a program for improving the reliability of communication. A TS packet sequence furnished with an RTP header includes audio data. The audio data alone constitutes a TS packet sequence having the RTP header as well. That is, an RTP packet having the same sequence number of, for example, �1235h� is transmitted twice in a row. If the receiving side can receive at least one of the two RTP packets thus transmitted, that means the audio data has been sent intact. This arrangement makes it possible to prevent disconnections of audio being offered to the user. The invention applies to both the transmitting and the receiver apparatus for sending and receiving data therebetween.
TECHNICAL FIELD The present invention relates to a sending-receiving system, a sender apparatus, a sending method, a receiver apparatus, a receiving method, a recording medium, and a program. More particularly, the invention relates to a sending-receiving system, a sender apparatus, a sending method, a receiver apparatus, a receiving method, a recording medium, and a program for compensating data packets having gone missing during transmission or reception.
BACKGROUND ART Electronic networks have gained widespread acceptance today, and more and more services are being offered on these networks. Some networks are structured in wired fashion; others are constituted wirelessly.
DISCLOSURE OF INVENTION The present invention has been made in view of the above circumstances and provides arrangements for transmitting a given set of data a plurality of times (i.e., redundant transmission) so as to prevent irregularities such as disconnections of video or audio offered to the user.
BRIEF DESCRIPTION OF DRAWINGS FIG. 1 is a schematic view showing a typical structure of a sending-receiving system embodying the present invention;
BEST MODE FOR CARRYING OUT THE INVENTION Preferred embodiments of the present invention will now be described with reference to the accompanying drawings. FIG. 1 is a schematic view showing a typical structure of a sending-receiving system practiced as an embodiment of the invention. The sending-receiving system of FIG. 1 is made up of a sender apparatus 1 and a receiver apparatus 2. The sender apparatus 1 receives TV broadcast data via an antenna 3 and transmits the received data to the receiver apparatus 2. The receiver apparatus 2 has presentation equipment (e.g., a display unit) and an audio output device (e.g., speakers) whereby images and sounds derived from the received data are output.
FIG. 4 shows a typical data structure of the header part 61 in the TS packet 51. The header part 61 is constituted by 4 bytes and the data part 62 by 184 bytes. A �sync byte� field in the header part 61 serves to provide synchronization and its value is fixed illustratively at 47h. An �error flag� is a flag that indicates whether there exists any uncorrectable bit error in the TS packet 51.
A �start flag� indicates that this packet is a new PES packet or a new TS-PSI section. A �priority flag� indicates the priority of this packet. If the priority flag bit is set for 1, that means the priority of this packet is higher than the other TS packets 51. A �PID� field constitutes a 13-bit numeric value (identifier) indicating whether a payload part (i.e., data part 62) of the TS packet 51 has video data, audio data, TS-PSI (TS-program specific information), or something else.
A �scrambling mode� field has information denoting the scrambling mode of the data part 62. An �adaptation field flag� is a flag that provides information indicating the presence or absence of an adaptation field containing PCR (program clock reference) or like information. A �continuity counter� field has a counter value incremented by 1 for each packet having the same PID.
Reference character �V� in the RTP header 42 represents a version bit, i.e., information indicating the version number of the format in which the RTP header 42 is furnished. Reference character �P� denotes a padding bit used to adjust the size of this packet. Reference character �X� stands for an extension bit designated at function extension time.
Reference characters �CC� represent a CSRC count, i.e., information indicating the number of transmission sources involved in a real-time transmission process. Reference character �M� denotes a marker bit delimiting a frame boundary of each packet. Reference characters �PT� stand for a payload type constituting information about the type of the payload in effect. A �sequence number� field has information indicating the sequence number of the RTP packet in terms of packet sequence.
A �time stamp� field gives information about the time stamp at which the RTP header 42 was created. An �SSRC� field constitutes a synchronization source identifier indicating a synchronization source, i.e., the source of the first transmission. A �CSRC� field has contributing source identifiers that identify the destinations (clients) to which to transmit the group of packets included in a message.
FIG. 6 shows a typical data structure of the UDP header 43. An �SRC port� field in the UDP header 43 has information designating the port number of the transmission source. A �DEST port� field has information designating the port number of the destination to which to send data. The two fields provide information for designating the services to be used.
A �length� field has information indicating the combined length of the UDP header 43 and of the data subsequent to it (in bytes). A �checksum� field has information constituting a value calculated on the basis of the UDP header information and the data length. The receiving side does the same calculations as the sender side to calculate the checksum. A check is then made to determine whether or not the calculated value matches the checksum included in the received UDP header 43. A checksum mismatch indicates the possibility of the packet having been destroyed in transmit.
A �ver� field has information indicating the version of the Internet Protocol (IP) in use. An �IHL� field has information indicating an Internet header length, i.e., the length of this header. A �TOS� field gives information about the type of service, defining the priority of data and designating the type of transfers to be made.
A �TL� field gives information indicating a Total length, i.e., the combined length of the IP header 44 and of the data subsequent to it. An �ID� field has information identifying the IP packet indicated by the IP header 44. An �FL� field has information about control on the fragmentation of data in the IP layer.
An �FO� field gives information indicating where data is located upon its fragmentation in the IP layer. A �TTL� field gives information indicating the time to live, i.e., a time period that ends upon discarding of the data including this IP header 44. A �PROT� field has information indicating the protocol for use in layers above the IP layer.
An �HC� field gives information constituting a checksum allowing the receiving side to determine whether the IP header 44 has been destroyed during transmission. An �SA� field gives information indicating the IP address of the source from which data was transmitted. A �DA� field gives information indicating the IP address of the destination to which to transmit data.
A �PA� field provides preamble information used to lock PLL for clock recovery. A �DA� field has information indicating the MAC address of a transmission destination. An �SA� field gives information indicating the MAC address of a transmission source. A �type� field gives information indicating the protocol of an upper layer.
A �length� field has information indicating the number of bytes that make up the payload. One MAC header 45 carries either the �type� or the �length� information. An �FCS� field provides information for error checks. The data shown in FIG. 3 (i.e., MAC packet) is created with the addition of the MAC header 45 including the information described above.
Transmission of data supplemented with the RTP header 42 is a precondition under which the embodiment of this invention implements one of its features. That is, predetermined data (packet) is to be sent a plurality of number of times through the use of information within the RTP header 42 (more specifically, the �sequence number� shown in FIG. 5 is used).
The sequence reconstitution unit 85 references the �sequence number� field (FIG. 5) in the RTP header 42. The sequence numbers are generally serial numbers assigned in ascending order to packets (i.e., RTP headers 42), i.e., in the order in which the packets were processed by the sender apparatus 1. Alternatively, the sequence numbers may be assigned in descending order to the packets.
Illustratively, as shown in FIG. 10, sequence number �1� is stored in conjunction with TS packets 51-1-1 through 51-7-1 (the last digit of the reference numeral for each packet denotes a sequence number (hence the same numeral)). That is because the embodiment of this invention assumes that each RTP packet (i.e., MAC packet received by the receiver apparatus 2) includes seven TS packets 51-1 through 51-7. (FIG. 3). If eight TS packets were assumed to be included in one RTP packet, then sequence number �1� would be stored in association with eight TS packets 51-1-1 through 51-8-1.
Referring again to FIG. 10, sequence number �2� is stored likewise in conjunction with seven TS packets 51-1-2 through 51-7-2. Sequence number �3,� however, has no TS packets stored in connection therewith in the example of FIG. 10 although TS packets 51-1-3 through 51-7-3 would be thought of by association. Sequence number �4� is held in conjunction with TS packets 51-1-4 through 51-7-4.
As described, the TS packets 51 (as the TS packet sequence 41) that have been received and processed normally are stored in suitable areas in the storage unit 87 in conjunction with the corresponding sequence number. That is, the TS packets are stored in the order in which their sequence numbers occur in series. If for some reason any TS packets have not been received normally, nothing is stored in connection with the corresponding sequence number (e.g., the area associated with sequence number �3� has no packets stored in FIG. 10).
FIG. 11 shows a structure of an RTP packet formed by a TS packet sequence 101 supplemented with an RTP header 102. The TS packet sequence 101 in the RTP packet of FIG. 11 is made up of video data parts 104-1 through 104-7 supplemented with headers 103-1 through 103-7 respectively. The headers 103-1 through 103-7 contain the data fields such as those shown in the header part 61 of FIG. 4. Of these data fields, the �PID� field is set for �100h� in this example.
As described above with reference to FIG. 4, the value of the �PID� field in the header part 61 is determined in a manner which is dependent on the data in the data part 62 following the header part 61. If the data part 62 has video data, then the PID value is assumed to be �100h�; if the data part 62 has audio data, the PID value is assumed to be �102h.�
The PID values may be any values as long as they can be distinguished between the sender apparatus 1 and the receiver apparatus 2. These values are set by the MPEG encoder 21. Since the data parts 62 in the TS packets constituting the TS packet sequence 101 of FIG. 11 contain only video data, the �PID� fields in the headers 103-1 through 103-7 are all set for �100h.�
By contrast, a TS packet sequence 111 shown in FIG. 12 contains an audio data part 114-3. A header 113-3 attached to the audio data part 114-3 has its PID value set for �102h.�
The �sequence number� field in the RTP packet of FIG. 11 is assigned a value of �1234h.� If the RTP packet of FIG. 12 is generated immediately after the RTP packet of FIG. 11, then the �sequence number� field in an RTP header 112 of the RTP packet in FIG. 12 is assigned a value of �1235h,� a serial number continuous to the preceding value �1234h.�
The redundancy control unit 27 determines whether or not audio data is included in the supplied RTP packet by referencing the �PID� field in the header of each of the TS packets involved. A TS packet whose �PID� field is set for �100h� is deemed to have video data; a TS packet with its �PID� field set for �102h� is deemed to have audio data.
What takes place in steps S11 and S12 is explained below in more detail with reference to FIGS. 14A and 14B. FIG. 14A shows the same RTP packet as that in FIG. 12. The TS packet sequence 111 in the RTP packet of FIG. 14A includes the audio data part 114-3 (with the header 113-3 having its �PID� field set for �102h�). The sequence number of the RTP header 112 for the TS packet sequence 111 containing the audio data part 114-3 is set for �1235h.�
The RTP header 102 of the RTP packet shown in FIG. 11 has the sequence number �1234h�. This RTP header 102 is attached to the TS packet sequence 101. What is sent (i.e., processed) next is the RTP packet shown in FIG. 12. It follows that the RTP header 112 of the next RTP packet has the sequence number �1235h� and that the RTP header 112 is attached to the TS packet sequence 111.
Of the RTP headers shown in FIG. 15, the RTP headers 112 having the same sequence number �1235h� are transmitted continuously. In such a case, step S13 in the flowchart of FIG. 13 need not be carried out. That is, the RTP packet held in the storage unit 28 need only be forwarded to the UDP header supplementing unit 23 immediately after the RTP packet having the same sequence number has been output by the UDP header supplementing unit 23.
After the predetermined number of RTP packets have been transmitted, the RTP header 112 with the sequence number �1235h� is sent again. Even if the RTP header 112 (i.e., TS packet sequence 111) immediately following transmission of the RTP header 102 has gone missing for some reason, the same RTP header 112 (i.e., TS packet sequence 121) is more likely to be received normally thanks to the communication state supposedly improved over time.
In the second situation above, the sequence number itself is already placed in the storage unit 87. Referring again to FIG. 10, what is shown here is the state in which the TS packet sequence 41 to be stored in conjunction with the sequence number �3� (i.e., the TS packet sequence that should be made up of the TS packets 51-1-3 through 51-7-3) seems to have dropped out and has yet to be placed into storage. The storage area in which to place the apparently-lost packets is managed (i.e., allocated) in association with the corresponding sequence number.
Referring again to FIG. 10, the TS packets 51-1-1 through 51-7-1 associated with the sequence number �1� are first supplied to the MPEG decoder 88. Then the TS packets 51-1-2 through 51-7-2 associated with the sequence number �2� are fed to the MPEG decoder 88.
After that, the TS packets corresponding to the sequence number �3� should be supplied to the MPEG decoder 88. Since the corresponding TS packets are not found in storage when it is time for them to be fed to the MPEG decoder 88, they are skipped and the TS packets 51-1-4 through 51-7-4 associated with the next sequence number �4� are output instead.
In other words, if the TS packets associated with the sequence number �3� are not placed into the storage unit 87 before the TS packets associated with the sequence number �4� are timed to be fed to the MPEG decoder 88, there is no need subsequently to acquire the missing packets or to carry out steps in connection with the packet dropouts.
INDUSTRIAL APPLICABILITY The present invention provides arrangements for improving the reliability of communication. According to this invention, the data getting lost in transit is compensated so that disconnections or other disruptions will not occur in the video or audio being offered to the user.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5715257Oct 10, 1995Feb 3, 1998Nippon Telegraph And Telephone CorporationSystem for re-transmission in data communicationUS6898204 *Apr 4, 2001May 24, 2005Broadcom CorporationMethod of determining a collision between a plurality of transmitting stations in a frame-based communications networkEP0707394A1Oct 9, 1995Apr 17, 1996Nippon Telegraph And Telephone CorporationSystem for re-transmission in data communicationJP2001268121A Title not availableJP2002077258A Title not availableJP2002247134A Title not availableJP2002262286A Title not availableJPH1022983A Title not availableJPH08213973A Title not availableJPH11225161A Title not availableJPH11234249A Title not available* Cited by examinerNon-Patent CitationsReference1 *Schulzrinne, H. et al. "Request for Comments (RFC) 1889: RTP: A Transport Protocol for Real-Time Applications", Network Working Group, Jan. 1996, 75 pages.* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7920569 *May 5, 2008Apr 5, 2011Juniper Networks, Inc.Multi-link transport protocol translationUS8582491 *Oct 10, 2008Nov 12, 2013Lockheed Martin CorporationMethod and apparatus for routing communications using active and passive end-to-end quality-of-service reservations based on node mobility profilesUS20090274106 *Oct 10, 2008Nov 5, 2009Lockheed Martin CorporationMethod and apparatus for routing communications using active and passive end-to-end quality-of-service reservations based on node mobility profiles* Cited by examinerClassifications U.S. Classification709/230, 709/201International ClassificationG06F13/00, G06F15/16, H04L12/64, H04L29/02, H04L12/56, H04N7/26Cooperative ClassificationH04L12/64European ClassificationH04L12/64Legal EventsDateCodeEventDescriptionJul 9, 2013FPExpired due to failure to pay maintenance feeEffective date: 20130519May 19, 2013LAPSLapse for failure to pay maintenance feesDec 31, 2012REMIMaintenance fee reminder mailedSep 16, 2005ASAssignmentOwner name: SONY CORPORATION, JAPANFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:YANAMOTO, KAORU;MASATO, TSUYOSHI;REEL/FRAME:017859/0976Effective date: 20050606RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google