Patent Application
20060187925
The invention relates to the field of performing data communication over serial busses using Internet Protocols IP. More specifically it is related to the field of performing real time streaming over serial busses using Internet Protocols.
For video streaming over Internet a number of high compression video encoding techniques exist. Such techniques include MPEG2 or MPEG4 video/audio coding. Other techniques are H.263, H.264, DIVX or Windows Media 9, etc. Those techniques allow the compression of a standard video quality stream with 640*480 pixels á 8 bits in 3 colour components at 25 Hz=184 Mbit/s by the factor of 100 or more, so that video streaming over analogue telephone line with DSL modem (Digital Subscriber Line) becomes possible.
At the other end of the video chain, namely at the end of video production most compression techniques are unacceptable even if exclusively redundancy reduction is used. Therefore, much higher data rates must be supported for data communication via bus protocols.
There is one bus standard existing for the field of professional video production called HDSDI (SMPTE 292 M) dealing with approximately 1.5 Gbit/s. Also, in future more and more high definition video material will be produced and here much higher data rates are required, e.g. for 2 k cinematography film 1920*1080 pixels á 10 bits in 3 colour components at 24 frames per second+audio and meta data leads to 1.6 Gbit/s. Beyond that, the 4 k film is on the way with 3840*2160 resolution. Here the industries have to deal with 6 Gbit/s.
In studios it is therefore highly desirable to build networks of video servers and sinks based on bus technology that provides data transport capacities above 2 Gbit/s. The Ethernet bus technology is specified for these high data rates. There are Ethernet variants existing providing 1 Gbit/s data rate, such as 1000BASE-SX, 1000BASE-LX, 1000BASE-CX and 1000BASE-T. Furthermore there are Ethernet variants specified, that provide 10 Gbit/s data rate based on optical fibre. These are named 10GBASE-LX4, 10GBASE-SR, -LR -ER, 10GBASE-SW, -LW and -EW.
It is more and more likely that video streaming over Ethernet physical layer will be used for professional video production. And it is very much wanted to use the already installed upper layers like TCP (Transmission Control Protocol)/UDP (User Datagram Protocol)/RTP (Real Time Transport Protocol) and IP (Internet Protocol) for this video streaming as stacks/drivers with these protocol layers are shipped with a lot of different Operating Systems (OS). The advantage is that many software tools ‘off the shelf’ are supporting the TCP/UDP and IP protocols to retrieve/show or store/record these video streams.
Most of the known applications for video streaming over IP are software based. To achieve kind of real-time streaming the performance of the processor executing the applications has to be very high. The processors interrupt reaction time for processing IP-packets becomes more demanding with increasing Ethernet physics speed level (1000BASET, 10 Gbit Ethernet (10 GbE)). For processing IP-packets on 10 GbE, today's processors cannot provide the needed performance. Taking the next upper protocol layer into account, especially TCP, the processor does not have enough performance.
To solve the above-mentioned problem it is the general idea of the invention for a method for performing data transport over a serial bus using Internet protocols to split up the TCP/UDP/RTP and IP protocol levels for embedded software/hardware architectures and do the real-time streaming not over TCP but over UDP/RTP. The time critical RTP/UDP/IP protocols are in this proposal completely supported by hardware and the not time critical TCP/(UDP)/IP level is implemented by software on an embedded microprocessor. Likewise the invention relates to the idea to split up the protocol levels in case the real-time streaming is done with procedure calls of a file system instead of RTP.
For an apparatus for use in the method according to the invention it is advantageous if said apparatus comprises hardware means for processing the real-time critical data packets, software means for processing the real time uncritical data packets as well as a filter means in conjunction with a demultiplexer for passing the real-time critical data packets to the HW means and the real-time uncritical data packets to the software means.
Further advantageous embodiments are apparent from the respective dependent claims.
If Internet technology is used it is particularly advantageous that the filter algorithm makes the following three decisions:
Decision criteria for the filtering means result from the analysis of TCP/UDP/IP packet header. The decision may be made dependent on:
This way a demultiplexer can be used that passes the data packet to the right processing stage depending on filter decision.
In general the filter decisions: 1.) and 2.) are used to block processing of not foreseen incoming data packets or to acknowledge them real-time uncritical by software in a simple way e.g. acknowledge ‘busy’. This is done according the unique IP source address and IP destination address in the data packet headers.
An embodiment of the invention is to use the network layer for streaming. Here the RTP (Real-time transport protocol) and RTSP (Real-time streaming protocol) are used together with UDP/IP. Here the stream is controlled with RTSP in a real-time uncritical way and the data packets are streamed with RTP in a real-time critical way. Respectively the UDP/IP layers and the RTP layer have to be hardware accelerated, RTSP can be supported by software processing. For this purpose in addition the filter decisions: 3.) 4.) and 5.) are used to determine the data packets that are to be processed in hardware for real-time behavior by their unique entry in the ‘Protocol’-field, source port number of TCP/UDP packets, destination port number of TCP/UDP packets. All other data packets are real-time uncritical and can be processed by software.
In the embodiment of the invention where a file system is used to control data access in the network, the file system has a number of procedures implemented for executing different tasks. In this case it is advantageous that a network station contains a procedure filter for separating real-time-critical procedure calls from real-time-uncritical procedure calls for passing the procedure calls either to the hardware means respectively software means.
For this purpose additionally the filter decision 6.) is to be used to determine the real-time critical data packets according to their procedures ‘READ’ and ‘WRITE’ and process them by hardware. All other data packets according procedures e.g. ‘create_file’ can be processed in a real-time uncritical way by software.
In comparison to currently known solutions that are relying on software, this embodiment guarantees the needed data throughput rate for accessing e.g. storage devices by distinguishing real-time-critical procedures from real-time-uncritical procedures.
Time-critical data streams to or from a storage device e.g. over a network are with this invention able to act with throughput speeds of 2 Gbit/s or above accelerated by a hardware implemented data path.
The invention is in particular useful if the existing Network File System NFS is implemented.
Exemplary embodiments of the invention will be explained in more detail with reference to the drawings, which show in
a the packet format of an Ethernet data packet including IP-, UDP- and RTP-header;
b the packet format of an Ethernet data packet including IP-, UDP- and RPC-header;
In
a shows the format of an Ethernet packet transporting a part of a video stream. The pure payload data including video data is depicted on top of the drawing. The second highest level shows the payload data of the highest level plus an RTP header. The third level shows payload data, RTP header plus an UDP header in front of the RTP header. The second level shows the extension of the packet in the third level with an IP header in front of the UDP header. At the bottom of
b shows the corresponding format of an Ethernet packet for the embodiment that the RTP layer is exchanged with the RPC calls for the NFS.
Unit 25 is for the receiving path an IP-header-, and upper layer header filter and a data packet demultiplexer and in case of the transmitting path a data packet multiplexer. Here, it is filtered for the real-time critical data packets with predetermined specific source/destination IP address ID=xy on the specific ports and for file system networking with a specific remote procedure call. All needed information for filtering can be found in the packet headers. This unit therefore needs to evaluate the different headers in the packet. The IP ID is present in the IP header as shown in
Unit 25 filters the time uncritical packets for a TCP or UDP port with the according source/destination IP IDs (in
Next, the processing path in the other direction, i.e. in the direction of transmitting data from the device shown in
Next, the processing path with the same direction but for real-time uncritical packets is described. If a connected device (e.g. a Windows/Linux PC) requests data packets via e.g. FTP resp. TCP from the subject device, the FTP/TCP packet request is received by the embedded processor 31 as described above. The embedded processor interprets the FTP command and requests the application 30 for the wanted data. The data is provided from the application 30 to the application packet demultiplexer. This unit writes the data into the RAM 32. The embedded processor 31 builds a TCP/IP packet from the data and requests the header filter and data packet multiplexer unit 25 to send the data packets to the TX-DMA unit 33. Next processing units are the FIFO memory 23, the Ethernet MAC layer hardware unit 22, the Ethernet physical layer 21 and finally the Ethernet cable 20.
The receiving and transmitting path will be explained separately. For the receiving path the fast arriving data packets are collected in FIFO memory 40 of the FIFO memory unit 23 for time decoupling purposes. There is a configuration block 42 in the different hardware modules and so it is in the FIFO memory block. RX data packets are processed in the header parser block 43 of the filter block 25 according the filter algorithm mentioned above. The real-time critical packets are provided directly to the TX engine 63 in the hardware block 62 for the real time protocol stack. The real-time uncritical packets are written into a FIFO 44 that decouples system timing from DRAM timing. The packets out of the FIFO 44 are provided through the four channel DRAM controller 48 to the DRAM 32. Here, these data packets can be processed with the microcontroller 31, which may be based on the processor core PPC405. This processor is connected with the four channel DRAM controller 48 via its interface ports 55. The TX engine 63 is providing the real-time critical data packets to the hardware processing modules MAC client 65, IP 26 and UDP 27 for the real time protocol stack 62. Within these modules the packet evaluation is done in accordance to the respective standard. The application interface 66 provides the real-time critical data packets to the application module 29, where the RTP or RPC processing is done in a specific real-time hardware module 28. All real-time uncritical topics that are issued by received Ethernet data packets are handled between the microcontroller 31 who is in charge of processing the real-time uncritical Ethernet packets in the DRAM 24 and the microprocessor core 67 of the application processing through the application interface 61.
For transmitting purposes, the microprocessor core 67 of the application 29 is issuing a send request to the microcontroller 31 who configures all necessary modules for transmitting purpose. Thereafter the application 29 provides real-time critical data packets through the RTP/RPC module 28 and through the application interface 61 to the UDP 27, IP 26 and MAC-Client 65 hardware modules for formatting the data packets according the respective standard in real-time, respectively ‘on-the-fly’. The RX-engine 64 is providing these data packets via a FIFO 45 to the scheduled data path multiplexer 46. Here, the real-time critical data packets are mixed with the real-time uncritical data packets that were provided by the microcontroller 31 in the DRAM 32, where these packets are fetched by the DRAM controller 48 and are provided to the FIFO 47. Afterwards all data packets are written into the TX-FIFO 41 for time decoupling purpose and send out to the optical respectively copper medium 20 via the Ethernet MAC 22 and the Ethernet physical layer module 21.
With respect to the RPC topic mentioned earlier, an additional embodiment of the invention is described with reference to
Data processing architectures like the one shown in
With the new applications in the AV real time domain demanding a sustained data throughput rate of 2 Gbit/s, it is not possible anymore to support this high data throughput (with an intelligent file system (FS) control) by software.
For managing data access to files in a network a file system exists called NFS (Network File System). NFS is a UNIX-based pseudo file system for use in a network on top of RPC-, UDP-, and IP-layer stack, where NFS is a set of the remote procedure calls RPC. In this embodiment of the invention it is kernel to introduce a mechanism that splits the procedures of the NFS layer into software-supported tasks and hardware implemented tasks.
The software part manages the NFS control procedures with ‘non-real-time’ behaviour like GETATTR, CREATE or REMOVE [see Table 1] except the NFS procedures READ and WRITE.
In comparison to currently known solutions that are relying solely on software, the proposed invention guarantees a needed (high) data throughput rate for accessing e.g. storage devices by distinguishing real-time-critical NFS procedures from real-time-uncritical procedures.
Time-critical data streams to or from a NFS storage device e.g. over a network are with this invention able to act with throughput speeds of 2 Gbit/s or above accelerated by a hardware implemented data path.
Various modifications of the described embodiments are possible and fall under the scope of the below listed claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 05090033.1 | Feb 2005 | EP | regional |
