Patent Application
20070286074
The invention will be described for a home LAN based on the UPnP architecture, and in particular to a home LAN that distributes an AV traffic stream between a serving device and a rendering device, but the invention is fully applicable to other types of network architectures distributing other types of traffic streams. UPnP AV technology is defined in “UPnP Device Architecture, Version 1.0,” and is built upon Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol HTTP, and Extensible Markup Language (XML). UPnP AV technology defines two AV devices, a media server and a media renderer. The user must be able to browse the AV media items stored on the media server or available for transmission from the media server, select a specific item, and cause it to be played on the media renderer. To provide a uniform mechanism for media rendering devices to browse the AV media items available from the media server and to obtain detailed information about individual items, UPnP AV technology defines a Content Directory Service (CDS) in the media server. The CDS provides a method for the media server to publish a listing of the media items that it can serve, along with related metadata, such as a UPnP Traffic Descriptor, for each media item. For ease of explanation the invention will be described using QoS concepts and syntax as described in “UPnP QoS Architecture, Version 1.0.”
In this example, it is desired that the AV traffic stream from the PC (media server) to the digital TV (media renderer) be of high quality, which is determined by bandwidth and latency. Once the AV stream is established, the quality of the stream should not be degraded during normal operation, regardless of what else is happening on the network. As shown in
As shown in
In UPnP the QoS parameters are contained in the UPnP Traffic Specification (TSPEC). TSPEC includes parameters such as Traffic ID, and traffic characteristics like peak rate, mean rate, delay requirement and loss requirement. TSPEC is represented in the form of an XML structure in the CDS. In the UPnP AV scenario, the TSPEC XML is extracted from the CDS and inserted into the Traffic Descriptor associated with the AV media content item.
In the conventional method proposed in the UPnP standards, after the traffic stream has been established, the QM initiates QoS configuration of all devices along the path of the traffic stream, including the intermediate device. The QM receives the TrafficDescriptor, which is the representation of a traffic stream structure and which includes the QoS parameters in TSPEC, and applies the appropriate QoS policy for the TrafficDescriptor. The QoS policy may come from an optional QoS Policy Service, which can be controlled by the network user, or from a default policy. The QoS policy includes the relative importance of a particular traffic stream, such as a TrafficImportanceNumber and a UserImportanceNumber. The QM conveys these parameters to the devices and then the QoS Device Service in each device configures the device for handling the new traffic. The TrafficImportanceNumber in turn is used in deriving the technology-specific access priority. The internal mechanism used by the QoS Device Service for applying the TrafficImportanceNumber is typically by tagging the packets to be transmitted. For example, in a HomePlug™ network four priority levels are defined by the standard, so the TrafficImportanceNumber would be converted to one of these priority levels.
The conventional UPnP QoS configuration method requires signaling to each network device along the path of the traffic stream, including the intermediate device. This requires the QM to discover the path of the traffic stream and then send the QoS parameters to each of the devices along the path. This method is considered relatively complex.
In this invention, the QoS setup for an intermediate device and the network segment to which it is attached occurs after QoS signaling configures QoS in just the two end devices, i.e., the source and the sink. While this end-to-end QoS method is relatively easier to implement than the above-described conventional UPnP method, it does not configure an intermediate device with the QoS parameters. One proposed solution to configuring the intermediate device in this end-to-end method is “auto-connect”, wherein the intermediate device measures the AV data to determine the QoS parameters. However, in many cases, the accuracy and speed of the measurement may render the auto-connect approach unreliable.
In this invention, after QoS has been set up in the source and sink devices using the end-to-end method, the intermediate device determines that it needs to set up QoS for an AV stream, for example, by detecting the AV stream from the packet pattern or the IP/port/protocol information. The intermediate device queries the QPH with the AV stream information (IP addresses, port numbers, protocol, etc) of this AV connection to get the QoS parameters for this stream. After receiving the response from the QPH, the intermediate device or node, which is typically a router, bridge or hub connected to its own network segment, knows the QoS parameters for the AV media item and uses the QoS parameters to configure QoS in its network segment. In particular, the intermediate device uses the QoS parameters to determine how much bandwidth should be allocated for this AV media item.
It is possible that the input to QPH includes only part of the traffic stream identifier (SourceIP; DestinationIP; SourcePort; DestinationPort; Protocol). In such a case, the output from QPH may have more than one matched TrafficDescriptors returned to the intermediate device. If so, the intermediate device need decide which one to apply for the QOS configuration based on more information gathered. In a case like this a second embodiment of this invention may be utilized, as described below.
In the above embodiments, it is assumed that the QPH (the QM in a UPnP-based network) is located in the sink device. However, in a more general case where the QPH is not necessarily located in sink device, or where multiple QPHs exist, a multicast query from the intermediate device to the stream owner may be required. Alternatively, in such a general case, the QoS query can be sent to either the source device or the sink device since both devices will have the QoS parameters and thus function as a QPH. As described previously, any device can be a QPH if it contains the QoS parameters and can respond to a query. In such a case, the action of a QoS device (QD), such as QD:GetQoSState, can be used to return the QoS parameters along with other information in the TrafficDescriptors that are currently active. Then the QoS Device Service in the intermediate device will match the traffic information it knows to find the corresponding TrafficDescriptor. This TrafficDescriptor contains the QoS parameters the intermediate device uses to configure its network segment with QoS.
While the invention has been described with respect to a LAN with two segments having an intermediate device between the two segments, the invention is also applicable to a network wherein one of the segments is a wide area network (WAN), such as the Internet. This is illustrated in the example network 10′ of
While the present invention has been particularly shown and described with reference to the preferred embodiments, it will be understood by those skilled in the art that various changes in form and detail may be made without departing from the spirit and scope of the invention. Accordingly, the disclosed invention is to be considered merely as illustrative and limited in scope only as specified in the appended claims.
