Large-scale real-time multimedia communication technology
阅读说明：本技术 大规模实时多媒体通信技术 (Large-scale real-time multimedia communication technology ) 是由 刘勇 孙雨润 赵斌 于 2018-12-05 设计创作，主要内容包括：本发明提出了一种使用软件定义网络(SDN)进行实时多媒体通信的方法、设备和系统。该方法包括由处理器接收表示SDN中直接连接的服务节点之间传输容量的路径度量,由处理器基于路径度量确定包括第一个边缘节点和第二个边缘节点之间最佳路径的级联网络拓扑,其中,最佳路径在第一个边缘节点和第二个边缘节点之间的SDN中的数据传输路径中具有最低的传输延迟,并且如确定要在第一个边缘节点和第二个边缘节点之间传输多媒体数据,则在第一个边缘节点和第二个边缘节点之间根据最佳路径来传输多媒体数据。(The invention provides a method, equipment and a system for real-time multimedia communication by using a Software Defined Network (SDN). The method includes receiving, by a processor, a path metric representing transmission capacity between directly connected service nodes in the SDN, determining, by the processor, a tandem network topology including a best path between a first edge node and a second edge node based on the path metric, wherein the best path has a lowest transmission delay in a data transmission path in the SDN between the first edge node and the second edge node, and transmitting multimedia data according to the best path between the first edge node and the second edge node if it is determined that the multimedia data is to be transmitted between the first edge node and the second edge node.)
1. A method for real-time multimedia communication using a Software Defined Network (SDN), comprising:
the processor receives path metrics representing transmission capacity between directly connected service nodes in the SDN;
the processor determines, from the path metrics, a cascaded network topology comprising an optimal path between the first edge node and the second edge node, wherein the optimal path has a lowest transmission delay in a data transmission path between the first edge node and the second edge node in the SDN; and
if it is determined that the multimedia data is to be transmitted between the first edge node and the second edge node, the multimedia data is transmitted according to the optimal path between the first edge node and the second edge node.
2. The method of claim 1, wherein the network interface hardware of the nodes of the SDN is general purpose network interface hardware.
3. The method of claim 1, wherein
The path metrics comprise a load status of at least one directly connected service node and a transmission metric between at least two directly connected service nodes,
the load state comprises at least one of an available throughput and an operational state, an
The transmission metric includes at least one of delay, packet loss rate, network traffic load, and transmission quota.
4. The method of claim 3, further comprising:
the transmission metrics are determined using at least one of multimedia data and test data, wherein the multimedia data and the test data are transmitted between directly connected serving nodes.
5. The method of claim 1, further comprising:
receiving path metrics in an iterative manner; and
the cascaded network topology is updated in an iterative manner based on the path metrics.
6. The method of claim 5, wherein the tandem network topology includes an updated best path between the first edge node and the second edge node, and the updated best path is different from the previous best path.
7. The method of claim 1, further comprising:
the processor selects a first edge node from the first plurality of candidate edge nodes as an edge node for the first terminal in the SDN based on at least one of: a previous best path associated with the first terminal, rules of a network operator associated with the SDN, a geographic location of the first terminal, geographic locations of candidate edge nodes, and path metrics associated with the candidate edge nodes; and is
A connection is established between the first terminal and the first edge node.
8. The method of claim 7, wherein transmitting the multimedia data between the first edge node and the second edge node according to the best path comprises:
if it is determined that the multimedia data is to be sent from the first edge node to the second edge node, sending path data to the first edge node containing a best path, wherein the best path is asymmetric and is to be stored by the first edge node;
attaching path data in a packet header of the multimedia data;
sending the data packet to the next service node of the optimal path; and is
The next service node determines the best path from the path data determined from the data packet.
9. The method of claim 7, further comprising:
verifying that the first terminal is connected to the first edge node, the verifying based on one or more of the following conditions: a permission to connect the first terminal to the SDN, a time limit to connect the first terminal to the SDN, a permission for the first terminal to send multimedia data, and a permission for the first terminal to receive multimedia data.
10. The method of claim 1, wherein transmitting the multimedia data between the first edge node and the second edge node according to the best path comprises:
transmitting a first packet of multimedia data according to a first path, and transmitting a second packet of multimedia data according to a second path, wherein the first packet and the second packet are duplicate packets, the first path and the second path are transmission paths between a first edge node and a second edge node, and the first path is different from the second path.
11. The method of claim 10, further comprising:
receiving at least a portion of the contents of the first packet and at least a portion of the contents of the second packet at the second edge node; and is
The complete data packet is determined by combining at least a portion of the content of the first data packet and at least a portion of the content of the second data packet.
12. A real-time multimedia communication system based on a Software Defined Network (SDN), comprising:
a first service node in the SDN;
a second service node in the SDN directly connected to the first service node; and
a control node in an SDN, comprising a processor and a memory coupled to the processor, the memory configured to store instructions that when executed by the processor are operable to:
receiving a path metric representing a transmission capacity between the first serving node and the second serving node;
determining a cascaded network topology from the path metrics, the cascaded network topology comprising an optimal path from a sender edge node to a plurality of receiver edge nodes, wherein the optimal path between the sender edge node and one of the plurality of receiver edge nodes has a lowest transmission delay in a data transmission path between the sender edge node and the receiver edge node in the SDN; and
if it is determined that the multimedia data is to be transmitted from the sender edge node to the receiver edge node, the multimedia data is transmitted from the sender edge node to the receiver edge node according to the optimal path.
13. The system of claim 12, wherein the network interface hardware of the control node, the first service node, and the second service node is generic network interface hardware.
14. The system of claim 12, wherein determining the path metrics is in an iterative manner, and the cascaded network topology is updated in an iterative manner upon receiving the path metrics.
15. The system of claim 12, wherein the cascaded network topology includes at least two transmission paths between a sender edge node and the receiver edge node.
16. The system of claim 15, wherein the at least two transmission paths include a first path from the sender edge node to the receiver edge node and a second path from the receiver edge node to the sender edge node, and the serving node in the first path is different from the serving node in the second path.
17. The system of claim 12, wherein the system comprises a plurality of communication channels in an SDN, and wherein
Each communication channel includes a set of service nodes in the SDN, an
At least one of the service nodes in the set of service nodes is associated with a different communication channel.
18. An apparatus of a Software Defined Network (SDN) for real-time multimedia communication, comprising:
a processor, and
a memory coupled to the processor, the memory configured to store instructions that when executed by the processor are operable to:
receiving path metrics associated with a first service node in the SDN and a second service node in the SDN in a periodic manner, wherein the path metrics include at least one of: a load status of at least one of the first service node and the second service node, and a transmission metric between the first service node and the second service node; and is
Upon receiving the path metrics, a cascaded network topology is updated that includes an optimal path for transmitting multimedia data from the first edge node to the second edge node.
19. The apparatus of claim 18, wherein the memory further contains instructions that when executed by the processor are operable to:
blocking a communication channel of the SDN based on a predetermined rule, wherein the communication channel comprises at least one of a first edge node and a second edge node.
20. The apparatus of claim 18, wherein the memory further contains instructions that when executed by the processor are operable to:
if it has been determined that the number of terminals in the communication channel exceeds the threshold number, a transmission mode for transmitting the multimedia data is decided for the communication channel, wherein the transmission mode comprises at least one of a multicast mode, a broadcast mode and a unicast mode.
Technical Field
The invention relates to a multimedia communication technology, in particular to the field of large-scale real-time video communication.
Background
Real-time multimedia (e.g., audio or video) communication has a wide range of applications, such as conferencing, live broadcasting, or web seminars. Multimedia streams may be generated and compressed into bitstreams using end-user terminals equipped with audio/video (a/V) devices, such as microphones and/or cameras. The bit stream may be packetized and transmitted in packets to a target user over a network, such as the internet. Upon receiving the data packets, the end-user may decompress, render, and display the multimedia bitstream (e.g., using a speaker or display) to the target user.
In the case of multi-user communications, multiple end-user ports may be used to simultaneously transmit and receive multimedia streams for interactive communications. As the size of users increases, the demands on the quality and performance of networks and systems supporting such large-scale multimedia communications become higher.
Disclosure of Invention
Methods, devices and systems for real-time video communication are set forth below.
In one aspect, a method for real-time multimedia communication using a Software Defined Network (SDN) is disclosed herein. The method includes receiving, by a processor, a path metric representing transmission capacity between directly connected service nodes in the SDN, determining, by the processor, a tandem network topology including a best path between a first edge node and a second edge node based on the path metric, wherein the best path has a lowest transmission delay in a data transmission path in the SDN between the first edge node and the second edge node, and transmitting, by the processor, multimedia data between the first edge node and the second edge node according to the best path if it is determined that the multimedia data is to be transmitted between the first edge node and the second edge node.
In another aspect, a system for real-time multimedia communication using SDN is also disclosed herein. The system includes a first service node in the SDN, a second service node in the SDN directly connected to the first service node, and a control node in the SDN. The control node includes a processor and a memory coupled to the processor. The memory is configured to store instructions that, when executed by the processor, are operable to receive a path metric indicative of a transmission capacity between a first serving node and a second serving node, determine a tandem network topology based on the path metric, the tandem network topology comprising an optimal path from a sender edge node to a plurality of receiver edge nodes, wherein the optimal path has a lowest transmission delay in a data transmission path between the first edge node and the second edge node in the SDN, and transmit multimedia data according to the optimal path between the first edge node and the second edge node if it is determined that the multimedia data is to be transmitted between the first edge node and the second edge node.
In yet another aspect, an apparatus for SDN for real-time multimedia communication is also disclosed herein. The apparatus includes a processor and a memory coupled to the processor. The memory is configured to store instructions that, when executed by the processor, are operable to receive path metrics associated with a first one of the service nodes in the SDN and a second one of the service nodes in the SDN in a periodic manner, wherein the path metrics include at least one of: a load status of at least one of the first service node and the second service node, and a transmission metric between the first service node and the second service node, and upon receiving the path metric, updating a tandem network topology comprising an optimal path for transmitting multimedia data between the first edge node and the second edge node.
Drawings
The invention will be better understood when reading the following detailed description with reference to the accompanying drawings. It is emphasized that, according to common practice, the various features of the drawing are not to scale. On the contrary, the dimensions of the various features are arbitrarily expanded or reduced for clarity.
Fig. 1 is a diagram depicting an example of a system for real-time video communication in accordance with an embodiment of the invention.
Figure 2 is a schematic diagram of a Software Defined Network (SDN) for real-time video communication, drawn in accordance with an embodiment of the present invention.
Fig. 3 is a schematic diagram of a cascaded network topology for real-time video communication, according to an embodiment of the present invention.
Fig. 4 is a flowchart depicting an example process for real-time video communication in accordance with an embodiment of the present invention.
Fig. 5 is a flowchart illustrating an example process for updating a tandem network topology according to an embodiment of the present invention.
Fig. 6 is a flowchart illustrating an example of a process for multimedia data transmission according to an embodiment of the present invention.
Fig. 7 is a flowchart illustrating an example process for authenticating a terminal in an SDN according to an embodiment of the present invention.
Fig. 8 is a diagram depicting an example of an apparatus for real-time video communication in accordance with an embodiment of the invention.
Fig. 9 is a drawing of another example of an apparatus for real-time video communication, according to an embodiment of the present invention.
Fig. 10 is a diagram of an example communication channel for real-time video communication, plotted according to an embodiment of the invention.
Detailed Description
Large-scale real-time multimedia communication in a network is quite challenging. In a large-scale real-time multimedia communication scenario, there may be a very large number of users (e.g., over 100,000) participating in the communication. Users may also be located throughout the world at various locations. In interactive multimedia communications (e.g., large-scale concerts, on-line lectures, talk show programs, etc.), the low latency requirements for multimedia transmission may be very demanding (e.g., requiring delays below 400 milliseconds).
For example, in a large scale online educational lecture held across cities, one audience may be required to participate in a quiz session with a set of performing guests, while all other audiences need to hear and participate in the discussion at any time. In live talk show programs played by paying viewers on the internet, comedians may wish to control the point in time to throw laughter out of all viewers at the same time, to respond to laughter in time, and to engage in impromptu interactions with the viewers under appropriate circumstances. Participants from different countries are also subject to different network conditions at a whole annual meeting held by a multinational company, and they all wish to be able to meet with other participants to get an immersive experience, whether speaking, watching or listening. All of these and other similar application scenarios require low-latency interactive multimedia communications.
Various challenges may be encountered in providing technical solutions for real-time interactive multimedia communication. For example, a conferencing mode may be provided for multimedia communication that may allow low-latency two-way interaction of participants, but the maximum number of simultaneous participants is very limited, only applicable in a small scale and not suitable for large scenes. As another example, in multimedia communications a broadcast mode may be provided which may allow a large number of simultaneous participants, but which typically only supports one-way communications and may have a high latency.
Systems, devices, and methods are disclosed herein for providing technical solutions for large-scale, low-latency, interactive, multi-media communication using a Software Defined Network (SDN). SDN is deployed at the application layer of a network and thus can be overlaid on top of the infrastructure of an existing public network, such as the internet. SDNs may be implemented as software modules installed in interconnected general-purpose computers, such as computer servers. SDNs may also be deployed on two types of computers (hereinafter "nodes"), a service node and a control node, respectively. The service node and the control node are interconnected with each other. The serving node is configured to receive the multimedia data transmitted from the user equipment, route (i.e., forward) the multimedia data, and transmit the multimedia data to the target user equipment. The control node is used for controlling data transmission in the SDN, such as determining an optimal transmission path for data transmission. According to an embodiment of the invention, a control node of the SDN may provide a distributed control service. That is, the control services are not centralized (e.g., implemented by a single node or a single group of nodes). Multiple control nodes may be distributed at multiple geographic locations around the world to provide control services for the SDN, and the number, location, or configuration of any control node may be modified, changed, added, or removed in any manner at any time in providing control services.
In SDN, parameters representing transmission capacity may be set periodically between service nodes. The parameters may be sent to a control node from which the optimal transmission path may be dynamically determined. When data transmission is performed, the control node may dynamically configure a cascaded network topology for transmitting multimedia data according to actual network traffic requirements. Furthermore, SDN may support multi-channel communication, so multiple events may be organized simultaneously using SDN and users may be grouped into different channels according to different events, without interfering with each other.
SDN nodes may be deployed anywhere to connect to the internet. In some implementations, SDN nodes may be deployed globally to support ring-and-ball scale real-time multimedia communications. The transmission of data packets between service nodes may be through the use of SDN connections, non-SDN connections (such as direct internet connections between service nodes), or both. The transmission of the data packets may be a bi-directional transmission between the serving nodes.
In some implementations, the SDN may be implemented only as a software module. That is, no dedicated or specific hardware is required to build the SDN, and no dedicated or specific network or network service provider is required to connect the SDN. For example, the software modules may be one or more Software Development Kits (SDKs). SDNs may be built and deployed in the application layer of any publicly accessible network, such as the internet. Therefore, the SDN only needs simple hardware for construction, and is convenient to configure, short in time consumption and low in cost. According to embodiments of the invention, SDN may support up to hundreds of thousands of users for interactive real-time multimedia communications, and the delay may be maintained as low as hundreds of milliseconds (ms). Typically the delay may be between 400-800 milliseconds.
In some implementations, SDNs may also be implemented as software and hardware modules. For example, some software modules may be implemented by specific hardware modules, such as Intellectual Property (IP) cores, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), programmable logic arrays, optical processors, programmable logic controllers, microcode, microcontrollers, servers, microprocessors, digital signal processors, or any other suitable circuit device. Software modules of an SDN may be built and deployed in the application layer of any publicly accessible network, such as the internet. A hardware module of the SDN may interface with a software module to assist in implementing the functionality of the software module. By adopting the method, the hot spot speed of the SDN application can be increased through the hardware module, so that the performance of the SDN system is improved.
Fig. 1 is an exemplary diagram of a
The
In some implementations, the
I/
The
The
In some implementations, a Software Defined Network (SDN) may be implemented at an application layer of the
It should be noted that the components or assemblies of
Fig. 2 is a schematic diagram of a Software Defined Network (SDN)200 for real-time video communication, rendered in accordance with an embodiment of the present disclosure. SDN200 is implemented at the application layer of a computer network, such as
In some implementations, SDN200 may be implemented asSoftware installed on nodes of
Furthermore, the
By implementing SDN200 as a software module on a general purpose computer on a public network, deploying SDN200 may be simple, fast, efficient, and low cost to a user (e.g., building SDNs without investing costs in dedicated hardware or proprietary network services).
As shown in fig. 2, SDN200 includes two types of nodes: a service node and a control node. The service nodes (e.g., service node 204 and 218) are used for receiving, forwarding and transmitting multimedia data from different user terminals. Control nodes, such as control node 202, are used to control network traffic. The service node and the control node may be interconnected with each other, which is not fully shown in fig. 2. For example, in an SDN with N nodes, there may be at least N × (N-1) direct connections of the above nodes. That is, any two nodes in the SDN may be directly interconnected. The connection between the nodes may be bidirectional. The connection between the nodes may also be unidirectional. The connections between nodes may also be sometimes bidirectional and sometimes unidirectional. It should be noted that the direction of network traffic between nodes of the SDN is not limited to the examples described in this disclosure.
In fig. 2, connections between nodes of the SDN200 may be represented by connecting lines between service nodes and control nodes. Solid lines with double arrows may represent bidirectional interconnections between service nodes. In some implementations, the bidirectional interconnection between serving nodes may also be used to send data to determine transmission capacity, as described in detail in relation to fig. 3-10. The dashed line with double arrows then represents the bi-directional connection between the serving node and the control node. The control node may receive data for determining the transmission capacity from the serving node and may send the best path to the serving node. In this disclosure, the term "transmission capacity" refers to the capacity or capability of an in-use (or "used") or potential (or "reserved use") network for data transmission. The transmission capacity of a node refers to the node's useful or potential capacity or ability to forward (e.g., receive and retransmit) network data. The transmission capacity between the first node and the second node means at least one of: the first node transmits network data from the first node to the second node's active or potential capacity or capability, and the second node transmits network data from the second node to the first node's active or potential capacity or capability. It should be noted that any number of any type of nodes may be deployed and interconnections between nodes may be arbitrarily configured when implementing SDN200 and are not limited to the example shown in fig. 2.
Service nodes can be subdivided into two types: an edge service node (or simply "edge node") and a routing service node (or simply "routing node"). The edge nodes are directly connected to end-user terminals (or simply "terminals"), such as
The routing node is not directly connected to any terminal. The routing nodes participate in forwarding data, such as service nodes 204, 208, and 212, 216. In some implementations, the serving node may switch between the edge node and the routing node at different times or act as both nodes. For example, serving node 206 is an edge node of
In some implementations, edge nodes of SDN200 may be connected to Autonomous Systems (ASs) operated by Internet Service Providers (ISPs). The topology of SDN200 may be divided into hierarchical groups based on the geographic locations of the service nodes, ASs, and ISPs. Data transmission for SDN200 can be divided into two types: inter-node traffic (i.e., network traffic between serving nodes) and end-node traffic (i.e., network traffic between edge nodes and terminals). Various strategies may be employed to optimize transmissions between nodes and between terminals and nodes, as described in detail in U.S. patent application serial No. 15/052,810 filed 24.2.2016, the entire contents of which are incorporated herein by reference.
In some implementations, SDN based systems may be used for real-time multimedia communications. The system may be constructed based on an SDN (e.g., SDN 200) and include a plurality of service nodes (e.g., service nodes 204 and 218) and at least one control node (e.g., control node 202). The service nodes may include edge nodes (e.g., service nodes 206, 210, and 218) and routing nodes (e.g., service nodes 204, 208, and 212) 216. Any service node in the SDN may switch between the edge node and the routing node.
A parameter indicative of transmission capacity between the serving nodes may be determined and transmitted to the control node to determine an optimal data transmission path (simply referred to as "optimal path") between the serving nodes. Hereinafter, this parameter may be referred to as a "path metric". The path metrics may be monitored iteratively (e.g., periodically or aperiodically). In some implementations, the path metric may be repeatedly determined between any two directly connected service nodes of the SDN at certain time intervals. In some implementations, the time interval may be constant (e.g., tens of milliseconds). In some implementations, the time interval may also be dynamically adjusted, such as according to the transmission load of the SDN (e.g., the time interval increases as the transmission load decreases and vice versa).
In some implementations, the path metrics may include a load state of the serving node and a transmission metric (e.g., for unidirectional or bidirectional transmission) between the serving node and another serving node. The load status may include one or more parameters indicative of the service node load. For example, the load state may include any combination of any number of parameters, such as the available throughput of the serving node and the operational state of the serving node. The transmission metrics may include statistical parameters or event-based parameters representing transmission capacity between serving nodes. For example, the transmission metrics may include any combination of any number of parameters, such as delay time, packet loss rate, network traffic load, and transmission quota.
The path metric may be determined between any two serving nodes in an active mode, a passive mode, or a combination thereof. In active mode, any two directly connected service nodes on the SDN may send and receive test packets (e.g., dummy packets containing placeholder data) to each other using, for example, a routing protocol. By performing calculations using received test packets, a transmission metric (such as delay or packet loss rate) may be determined. For example, the packet loss rate may be determined by dividing the total size of the received test packets by the total size of the test packets contained in their packet headers. In the passive mode, test packets are not used, but actual user packets are transmitted between the service nodes. For two directly connected service nodes, the transmission metric may be determined by performing a calculation on the user data packets. It should be noted that in bi-directional communication, a first transmission metric associated with a transmission from a first serving node to a second serving node may be different from a second transmission metric associated with a transmission from the second serving node to the first serving node. That is, the first transmission metric and the second transmission metric may be determined separately and independently. This transmission metric may be referred to as "asymmetry" of the bi-directional communication. Otherwise, if the first transmission metric is set to be the same as the second transmission metric (e.g., only the first transmission metric is monitored), the transmission metrics may be referred to as "symmetric". By determining the path metrics, the quality of bidirectional communication between any two directly connected service nodes in the SDN can be monitored and updated in real time.
In some implementations, an inter-service node transport metric may be determined that establishes a connection in the SDN, referred to as an "internal transport metric. In some implementations, a transmission metric (e.g., a direct internet connection) between non-SDN connected service nodes may also be determined, which is referred to as an "external transmission metric. It should be noted that any combination of any number of internal and external transmission metrics may be employed to determine the path metric. Internal and external transmission metrics may be used to decide whether to select whether to transmit multimedia data between two service nodes over a non-SDN connection or an SDN connection. In other words, non-SDN connections may be used as candidate routing options for SDN connections and vice versa.
The determined path metrics may be reported to the control node. For example, each time a serving node determines a transmission metric (e.g., an asymmetric transmission metric) between the node and another serving node, the serving node may immediately transmit the path metric to the control node. And the load status of the serving node may be repeatedly monitored and sent to the control node (e.g., along with the transmission metrics). The control node may determine the best path between the serving nodes based on the path metrics. In some implementations, if the path metric is measured and sent to the control node based on a certain period of time (e.g., a period of tens of milliseconds), the best path may also be determined based on the same period of time. The best path may be further determined based on a priori knowledge, such as a previously determined best path. In some implementations, the best path may be determined between any two service nodes of the SDN. In some implementations, multiple best paths may also be determined between any two service nodes of the SDN.
In some implementations, the best path may be symmetric (as in one-way communications). That is, the best path from the first edge node to the second edge node is the reverse path of the best path from the second edge node to the first edge node. In some implementations, the paths may also be asymmetric (as in two-way communications). That is, the best path from the first edge node to the second edge node is not the reverse path of the best path from the second edge node to the first edge node. If the determined transmission path metric is symmetric, the best path may also be symmetric. If the determined transmission path metric is asymmetric, the best path may also be asymmetric.
For example, one SDN may support bi-directional communication and include N edge nodes, where N is a positive integer. An asymmetric path metric may be determined between any two directly connected service nodes. Based on the path metrics, at least N x (N-1) best paths may be determined. In some implementations, K asymmetric best paths may be determined for any two serving nodes, where K is a positive integer. The K best paths may have different delay values. In some implementations, the K best paths may be ranked (e.g., ascending) according to delay values, and may be candidate paths for each other. For example, when the lowest delay path of the K best paths for data transmission is unavailable (e.g., has been disconnected or its delay has increased dramatically), then the path with the second lowest delay may be switched to continue data transmission.
After determining the best path, the control node may synchronize path data to the serving node, including information about the best path. In some implementations, the path data may be in the form of a routing table. In some implementations, the path data may be synchronized with all service nodes of the SDN. The synchronization of the path data may be achieved in a propagated manner.
As shown in fig. 2, control node 202 may send path data (e.g., path data stored in a routing table) to all edge nodes of SDN200, including service node 210, which is an edge node for
In some embodiments of the invention, the control node may select the service node as an edge node to connect a terminal to the SDN. The connection between the terminal and the edge node is a non-SDN connection (e.g., an internet connection). By receiving the path metrics, the control node may obtain real-time performance statistics of the SDN. An edge node may be selected from the one or more candidate edge nodes based on one or more of the following considerations: a previous best path associated with the terminal (e.g., an edge node taken by the terminal in the previous best path may be a candidate edge node for the current round), rules of a network operator associated with the SDN (e.g., the rules require all terminals to connect to a particular service node), a geographic location of the candidate terminal, a geographic location of the candidate service node, and path metrics associated with the candidate edge node. It should be noted that the consideration is not limited to the above example, but may be any factor related to the transmission capacity. The control node may assign different priorities to the considerations to determine the edge nodes.
As shown in fig. 2, when a terminal 226 is connected to the SDN200 and is ready to send multimedia data to the terminal 220, the service nodes 212 and 218 may all be candidate edge nodes, and they may have different strengths in consideration. The serving node 212 to the terminal 226 may have the lowest connection delay. The serving node 214 may have been used as an edge node for the terminal 226 in the previous best path. Service node 216 may have the smallest current transmission load among service nodes 212-218. The service node 218 may have the shortest geographic distance to the terminal 226. The serving node 218 may be selected as its edge node when the control node sets the geographical distance between the terminal 226 and the serving node to the highest priority. When the control node sets the serving node's transmission load to the highest priority, serving node 216 may be selected as its edge node. When the control node sets the previously used edge node to the highest priority, serving node 214 may be selected as its edge node. When the control node sets the connection delay to the highest priority, the serving node 212 may be selected as its edge node. It should be noted that the control node may also determine the edge node by comprehensively considering the priority of the candidate edge node. For example, each consideration factor may be assigned a weight to represent its priority. For each consideration factor, the control node may score the candidate edge nodes to indicate how strong or weak it is in the consideration factor. For each candidate edge node, a different score may be assigned to each of the plurality of consideration factors, and an overall score may be determined from the assigned plurality of scores, such as by computing a weighted sum between the plurality of scores and the weights of the respective consideration factors. The control node may select an edge node based on some rule based on the total score of the candidate edge nodes (e.g., select the candidate edge node with the highest or lowest total score).
In some implementations, after selecting an edge node for a terminal, the terminal may be authenticated prior to connecting to the SDN. For example, the configurable edge node authenticates the terminal. The verification may be based on one or more of the following conditions: a permission to connect the terminal to the SDN, a time limit to connect the terminal to the SDN, a permission for the terminal to send data, and a permission for the terminal to receive data. For example, a user may be charged a fee to use the SDN. An administrator of the SDN may assign access rights (such as a username and password) to a paying user. Access rights may include granting various permissions for a paying user to use SDN. For example, the permissions may restrict a user to be able to send data only, receive data only, use SDN for only a limited time, or use SDN freely without any restrictions. Different fees may be charged for different access rights. A request for unauthorized permission of a paying user to use the SDN may be denied. Unauthorized users (such as non-paying users or malicious attackers) may also be prevented from connecting to the SDN.
In some implementations, the control node may also authenticate the connected terminal based on the content of the user data. For example, the service node may sample the transmitted multimedia data, such as by taking a snapshot of the video stream or taking a sample of the audio stream. The sampled data may be periodically sent to a control node, which may detect (e.g., by using artificial intelligence algorithms) whether illegal, inappropriate, or rule-violating content is present in the multimedia data. If such content is detected, the control node may terminate the access rights of the offending terminal.
In some embodiments of the present invention, the control node may automatically adjust the routing mode of multimedia data transmission between the serving nodes according to the channel conditions. Users of SDN200 may send and receive multimedia data in different data communication channels, such as duplex data channels. Communication events such as concerts, meetings or live programmes may use channels for users to exchange multimedia data between each other. Users in the same channel participate in the same event. In some cases (e.g., events where a large number of users are participating), multiple channels may be available for the same event. Each channel of the SDN200 may be assigned a unique identifier, referred to as a "channel ID," by the control node. User data associated with the same channel ID may be aggregated for transmission. The serving node may also be simultaneously used for different frequency channels.
As shown in FIG. 2, a user of
As another example, in FIG. 2 the users of
In some implementations, the control node may switch the routing mode of the serving node in the same channel between unicast mode, multicast mode, and broadcast mode. The control node may synchronize information participating in the terminal in the channel with the serving node in the channel. For example, the SDN200 may use multicast mode as a default transport mode. The multicast mode may automatically switch to the unicast mode when only two terminals are included in the channel (i.e. the communication is one-to-one). The multicast mode may automatically switch to the broadcast mode when only one data transmitting terminal is included in the channel (i.e. the communication is unidirectional and one-to-many). In other words, the unicast mode and the broadcast mode can be considered as a simplified case of the multicast mode.
In some implementations, a cascaded network topology may be employed for data transmission in multicast mode when the amount of multimedia data exchanged in a channel exceeds a threshold, or when the number of users in a channel exceeds a threshold. The tandem network topology is a tree-like network topology used to represent the interconnections between service nodes. The tandem network topology may be dynamically configured according to changes in SDN transmission capacity. By using a cascaded network topology, excessive or redundant data forwarding may be reduced or avoided in an SDN.
Fig. 3 is an exemplary diagram of a cascaded network topology 300 for real-time video communication, as depicted in accordance with an embodiment of the present invention. Cascaded network topology 300 may be used for data transmission in an SDN, such as SDN200 in fig. 2. Tandem network topology 300 may be decided by a control node of the SDN, such as control node 202 in fig. 2. As shown in fig. 3, the cascaded network topology 300 is represented by the service nodes 302 and 326 and the connecting lines between them. As shown in fig. 3, the sender 302 may receive multimedia data (e.g., from a sending terminal) and send it to the receiver 310 via the router 304 and 308 and 326. The receiving party 310 and 326 can receive the multimedia data transmitted by the transmitting party 302 and forwarded by the router 304 and 308, and then transmit the multimedia data to the receiving terminal specified by the transmitting terminal. The sender, receiver and router may be service nodes of the SDN. For example, the sender 302 and the receiver 310 and 326 may be edge nodes of the
The lines between service nodes 302 and 306 may represent direct network connections (e.g., direct SDN connections) therebetween. The cascaded network topology 300 may be determined based on the best path between the sender and the receiver. If the best path is symmetric, all the above service nodes can use the same cascaded network topology for data transmission and reception, which may be referred to as "symmetry". If the best path is asymmetric, different cascaded network topologies, which may be referred to as "asymmetric," may be determined for different senders. I.e. an asymmetric cascaded network topology for unidirectional data transmission. As shown in fig. 3, when the cascaded network topology 300 is asymmetric, unidirectional data transmission is represented by a single arrowed line connecting the service nodes 302 and 326. In other words, the tandem network topology 300 is associated with the sender 302. When the service node 302-.
In some implementations, cascaded network topology 300 may include both SDN connections and non-SDN connections. For example, a direct network connection in cascaded network topology 300 may include a direct internet connection between its serving nodes. For ease of explanation without any ambiguity, in the following, direct network connections in cascaded network topology 300 are assumed to be direct SDN connections unless explicitly stated otherwise.
The cascaded network topology 300 may be determined from the path metrics determined by the control node. In some implementations, a cascaded network topology may be determined by a control node for a sender and a plurality of receivers based on path metrics measured between the sender and the receivers, and each path in the determined cascaded network topology may represent an optimal path. For example, in fig. 2, when user data is transmitted from terminal 222 to
In some implementations, the tandem network topology 300 may be dynamically configured based on changes in transmission capacity represented by path metrics. As shown in FIG. 3, in the first time period, the router 304 is selected for the best path between the sender 302 and the recipient 310, as represented by path 302 and 304 and 310. Path metrics between the sender 302 and other service nodes in the same SDN may be periodically monitored. A plurality of candidate best paths may be determined between the sender 302 and the receiver 310. For example, K best paths with different total delay times may be included in the plurality of candidate best paths from the sender 302 to the receiver 310. The K best paths may include path 302-. During the first time period, the path 302 along 304 and 310 with the lowest delay in the transmission from the sender 302 to the receiver 310.
After the first time period, assuming that the measured path metrics indicate that the total delay of the path 302 and 328 and 310 becomes the lowest among the K best paths, the control node may update the cascaded network topology 300 by changing the best path from the sender 302 to the receiver 310 to the path 302 and 328 and 310. The path 302-304-310 may be removed from the updated cascaded network topology 300. The new path 302 and 328 may be synchronized 310 at least in the router 328 and used to send user data for the second time period.
In some implementations, multimedia data may be transmitted using redundant transmissions to achieve fault tolerance. In some cases, a service node of the SDN may experience an unexpected failure (e.g., a power outage). To avoid data transfer interruptions, user data may be copied for transfer. For example, the tandem network topology 300 may be modified to group multiple service segments to form a "service cluster". User data may be transmitted between serving clusters, and the unit or "node" of the best path is a serving cluster.
For example, cascaded network topology 300 may be modified such that each circle in fig. 3 may represent a service cluster (i.e., not a single service node). In transferring user data between the serving clusters 306 and 316, the user data is actually transferred between the current serving node of the serving cluster 306 and one serving node of the serving cluster 316. For example, at the service cluster 306, user data may be replicated to multiple service nodes. The replicated user data may be independently sent to a plurality of corresponding serving nodes in the serving cluster 318. When the current serving node of serving cluster 306 fails, user data can still be sent to serving cluster 318 by other serving nodes without causing a transmission interruption.
When the replicated user data arrives at a receiving party, such as an edge node of a receiving terminal, it may be filtered (e.g. by excluding corrupted packet portions) and/or merged (e.g. by combining portions of packets) to obtain complete user data representing the original content. The complete user data may then be transmitted to the second terminal.
As shown in fig. 3, by using a tandem network topology 300, excessive or redundant data forwarding may be reduced or avoided in an SDN since user data flows between senders and receivers may be aggregated. For example, when the sender 302 sends data to the receiver 320 and 326, instead of sending multiple copies of the data, one copy of the data may be sent from the sender 302 to the router 308, and then the router 308 may generate four local copies of the data and send them to the receiver 320 and 326, respectively. Dynamically configuring the tandem network topology 300 according to changes in transmission capacity may save network bandwidth between service nodes, may also automatically repair network congestion in SDNs, and may minimize network transmission delay between edge nodes.
Fig. 4 is a flow diagram depicting an example process 400 for real-time video communication using SDN, in accordance with an embodiment of the invention. The process 400 may be implemented as software and/or hardware modules in the
Path metrics are received at operation 402 indicating transmission capacity between directly connected service nodes in the SDN. For example, the SDN may be SDN200 in fig. 2. The directly connected service nodes may include a first service node and a second service node. The first and second service nodes may be any two service nodes (e.g., any two directly connected service nodes) on SDN200, such as service node 206 and service node 208, respectively.
The path metric may be received by a processor of a control node, such as control node 202. In some implementations, the path metric may include a load state of at least one of the directly connected service nodes (e.g., the first service node and/or the second service node). The path metrics may also include transmission metrics (e.g., bidirectional transmission metrics) between at least two directly connected service nodes (e.g., a first service node and a second service node).
In some implementations, a transmission metric (e.g., a bidirectional transmission metric) may be determined using at least one of user data (e.g., multimedia data) and test data. User data and test data may be transmitted between directly connected service nodes, such as a first service node and a second service node. For example, an active mode may be employed to determine transmission metrics, i.e., using test data. The passive mode may also be employed to determine the transmission metric, i.e., using user data. The active mode and the passive mode may also be used together to determine a transmission metric. The active mode and the passive mode have been explained in the description related to the SDN200 in fig. 2.
In some implementations, the network interface hardware of the nodes of the SDN (e.g., the first service node and the second service node) may be generic network interface hardware. The universal network interface may be used to access public networks open to the public, such as the internet. For example, the network interface hardware may be the network interfaces 114 and 122 in FIG. 1. In some implementations, the network interface hardware may not support any private (e.g., closed source, proprietary, non-open, or non-public) network protocols. In some implementations, the network interface hardware of all service nodes and control nodes on the SDN may be generic network interface hardware.
At operation 404, a cascaded network topology is determined from the path metrics, and the cascaded network topology includes an optimal path between the first edge node and the second edge node. Among data transmission paths between a first edge node and a second edge node in an SDN, the best path may be the one with the lowest transmission delay (or simply "delay"). The best path may include at least one of the first serving node and the second serving node. For example, when a first edge node transmits user data to a second edge node, the cascaded network topology may be the cascaded network topology 300 of fig. 3. The first terminal and the second terminal may be directly connected to the first edge node and the second edge node, respectively. The first terminal, which may be the terminal 222 in fig. 2, is connected to the serving node 206 (i.e., the first edge node), which may be represented in fig. 3 by the sender 302. The second terminal may be a terminal 224 connected to the serving node 210 (i.e., the second edge node), which may be represented in fig. 3 by a recipient 322. The best path between the first edge node and the second edge node may be 206-208-210 in fig. 2, where the service node 208 may be represented by the router 308 in fig. 3. The optimal paths 206, 208, 210 may be represented by paths 302, 308, 322 in the cascaded network topology 300. Namely, the cascaded network topology 300 includes the optimal path 206-. In some implementations, the best path may be implemented as one or more entries in a routing table. For example, the entries may include IP addresses.
In some implementations, it may be determined whether the path metric is symmetric or asymmetric. If the path metric determined at operation 402 is asymmetric, the best path determined at operation 404 may also be asymmetric. In some implementations, multiple best paths may be determined between a sender and a receiver in a tandem network topology. In some implementations, the multiple best paths between the sender and the receiver may have different delay values.
In some implementations, the cascaded network topology may be a recursive cascaded topology. In a recursive cascade topology, each node may have at most one input (i.e., the location where user data is sent) and at least one output (i.e., the location to which user data is sent). In some implementations, if the path metric determined at operation 402 is asymmetric, the cascaded network topology may also be asymmetric. In some implementations, the tandem network topology may include only one best path (e.g., when the SDN is sending data in unicast mode).
At operation 406, if it is determined that multimedia data is to be transmitted between the first edge node and the second edge node, the multimedia data is transmitted according to the optimal path between the first edge node and the second edge node. For example, the cascaded network topology includes an optimal path 206 along 208 and 210 along which multimedia data may be transmitted from a first edge node (i.e., serving node 206) to a second edge node (i.e., serving node 210). When a first terminal (i.e., terminal 222) attempts to transmit multimedia data to a second terminal (i.e., terminal 224), the multimedia data can be transmitted over the optimal path 206 and 208 and 210. If the cascaded network topology is symmetric, the multimedia data can also be sent from the second edge node to the first edge node using the optimal path 206-. As another example, the cascaded network topology may be asymmetric and include an optimal path 210 along which multimedia data may be sent from the second edge node to the first edge node 204 along the optimal path 206.
In some implementations, a first packet of multimedia data is sent using a first path and a second packet of multimedia data is sent using a second path to achieve fault tolerance. The first packet and the second packet are duplicate packets. The first path and the second path are transmission paths from the first edge node to the second edge node, and the first path is different from the second path.
When the first and second packets arrive at the edge node of the second terminal, the first and second packets may be filtered (e.g., by excluding portions of the packets that are corrupted) and/or combined (e.g., by combining portions of the packets) to obtain a complete packet representing the original content. The complete data packet may then be transmitted to the second terminal.
In some implementations, the cascaded network topology may be dynamically updated based on changes in path metrics received by the control node. Fig. 5 is a flowchart illustrating an example process for updating a tandem network topology according to an embodiment of the present invention. Flow 500 may be implemented as software and/or hardware modules in
At
At
In some implementations, the SDN may determine the service node as an edge node for connecting a terminal (e.g., a first terminal) to the SDN. An edge node may be selected from a plurality of serving nodes that serve as candidate edge nodes. Selecting an edge node for a terminal may be based on one or more of the following conditions: the best path that the first terminal has used (e.g., the best path including a service node previously serving as an edge node of the first terminal), the network operator's rules associated with the SDN, the geographic location of the first terminal, the geographic location of the candidate edge node, and the path metrics associated with the candidate edge node.
When a terminal is determined to be an edge node, a connection (e.g., a direct connection) between the terminal and the edge node may be established. The best path and multimedia data may be sent to the serving nodes (i.e., routing nodes and edge nodes) as follows. Fig. 6 is an exemplary flow diagram depicting a
At
At
At
At
It will be determined at
In some implementations, the SDN may authenticate the terminal before the terminal connects to the SDN. The authentication may be performed, for example, by an edge node of the terminal. Fig. 7 is a flowchart illustrating an example process for authenticating a terminal in an SDN according to an embodiment of the present invention. Flow 700 may be performed prior to operation 402 in flow 400. Flow 700 may be implemented as software and/or hardware modules in
At
At
A system for SDN-based real-time multimedia communication is also disclosed. For example, the SDN may be SDN200 in fig. 2. The system may include a first service node (e.g., service node 206) in the SDN, a second service node (e.g., service node 210) in the SDN, and a control node (e.g., control node 202) in the SDN. The control node may include a processor (e.g., processor 116) and a memory (e.g., memory 118) coupled to the processor. The configurable memory is used to store instructions that when executed by the processor may be used to implement the operations in flow 400 in fig. 4.
In some implementations, the network interface hardware of the control node, the first service node, and the second service node may be general network interface hardware. The generic network interface hardware may be any network interface hardware for accessing a public network.
In some implementations, the path metric between the first serving node and the second serving node may be determined in an iterative manner (e.g., a periodic manner), and the cascaded network topology may be updated in an iterative manner upon receiving the path metric.
In some implementations, the cascaded network topology determined by the control node based on the path metrics may include at least two transmission paths between a first edge node and a second edge node to achieve fault tolerance. For example, the routing nodes of the two or more transmission paths may be different from each other. For another example, as shown in fig. 2, the tandem network topology may also be a topology between service clusters. Each serving cluster may include a plurality of serving nodes. In some implementations, the two or more transmission paths may be transmitted through the same serving cluster. For example, the first transmission path may include a first serving node and a second serving node in a first serving cluster and a second serving cluster, respectively. The second transmission path may include a third serving node and a fourth serving node in the first serving cluster and the second serving cluster, respectively. The first, second, third and fourth serving nodes are different from each other. Both the first and second transmission paths may be connected from the first edge node to the second edge node. It should be noted that the two or more transmission paths may also be transmitted through different service clusters.
In some implementations, the two or more transmission paths may include a first path from a first edge node to a second edge node and a second path from the second edge node to the first edge node. The service nodes of the first path may be different from the service nodes of the second path. In other words, the first path and the second path are asymmetric between the first edge node and the second edge node.
In some implementations, a system in an SDN may include multiple communication channels to support multi-channel communication. For example, each communication channel may include a set of service nodes in the SDN. At least one of the serving nodes in the group may be associated with a different communication channel.
Fig. 8 is a diagram depicting an example of an apparatus for real-time video communication in accordance with an embodiment of the invention. For example, the device may be a service node in an SDN, which may be SDN200 in fig. 2. The service node may be any one of service nodes 204-218.
The authentication module 802 may be used to authenticate the terminal 810 when selecting the serving
The routing module 806 may be used to send and receive user data (e.g., multimedia data) according to the best path. The best path may be obtained from path data sent by
Channel module 808 may be used to support multi-channel communications for serving
Also disclosed herein is an apparatus for a Software Defined Network (SDN) for real-time multimedia communications. For example, the device may be a control node (such as control node 202) in an SDN. The device may include a processor (e.g., processor 116) and a memory (e.g., memory 118) coupled to the processor. The configurable memory is configured to store instructions that when executed by the processor are operable to perform the following O1 and O2 operations.
At operation O1, the processor receives path metrics associated with a first service node in the SDN and a second service node in the SDN in an iterative manner. The path metrics include load states of the first and second serving nodes and transmission metrics (e.g., bidirectional transmission metrics) between the first and second serving nodes.
At operation O2, the cascaded network topology is updated upon receiving the path metrics. The tandem network topology includes an optimal path for transmitting multimedia data between a first terminal connected to a first service node and a second terminal connected to a second service node.
In some implementations, a device may allow or block communication channels of the SDN according to predetermined rules. For example, the predetermined rules may include determining whether user data in the communication channel includes illegal, or inappropriate content specified by an administrator of the SDN.
In some implementations, a transmission mode for transmitting multimedia data may be determined for a communication channel, such as determining that a number of terminals in the communication channel exceeds a threshold. For example, the transmission mode includes at least one of a multicast mode, a broadcast mode, and a unicast mode.
Fig. 9 is a drawing of another example of an apparatus for real-time video communication, according to an embodiment of the present invention. For example, the device may be a
The authentication controller 902 is operable to perform content control in a communication channel and access control of a connection terminal. For example, verification controller 902 may monitor the transmitted data content by analyzing the sample data. Sample data may be generated by the service node and sent to the
The probe controller 904 may be used to determine the best path. For example, probe controller 904 may receive path metrics from a service node (e.g., from probe module 804 of service node 800). The probe controller 904 may determine the best path based on the path metrics and/or previous best paths. Different best paths may be generated based on different path metrics received from different serving nodes. In some implementations, multiple best paths (e.g., K best paths) may be determined by the probe controller 904 for two edge nodes of the SDN. For example, the multiple best paths may be ordered according to delay time, and each may serve as an alternate path to each other.
The routing controller 906 may be used to determine and propagate the tandem network topology to the serving node. In some implementations, the routing controller 906 may determine the tandem network topology by setting the edge nodes as senders (e.g., sender 302 in fig. 3) to synthesize the best path according to the best path determined by the probe controller 904 associated with the edge nodes connected to the data sending terminal. In some implementations, routing controller 906 may send path data containing the determined tandem network topology to a routing module (e.g., routing module 806) of an associated service node (e.g., service node 800).
Channel controller 908 may be used to support multi-channel communication for SDN. For example, channel controller 908 may assign, maintain, and destroy channel IDs to communication channels of the SDN. When a channel is newly established for a multimedia communication event, the channel may be registered at the control node and the channel controller 908 may assign a channel ID to the channel. In some implementations, the channel controller 908 may cooperate with the channel module of the service node to synchronize information of the sender (e.g., the sender 302 in fig. 3) and the receiver (e.g., the receiver 310 and 326) in different channels. In some implementations, the channel controller 908 may dynamically select transmission modes (e.g., unicast, broadcast, and multicast) for data transmission in different channels.
An
Fig. 10 is an exemplary diagram of a
In some implementations, the service nodes in
The edge node set 1002 contains a plurality of edge nodes. Each edge node may be responsible for connecting terminals within a certain geographical area, such as a city. Multiple edge nodes may be provided to cover a geographic area (e.g., a metropolitan area including multiple cities).
Service cluster set 1004 includes a plurality of service clusters. Each service cluster may represent a group of service nodes that have similar hardware configurations and are located under the same physical network. For example, a service cluster may include service nodes in the same server room, within the same building, sharing the same gateway, or interconnected by the same ISP. Each serving cluster may be connected to a plurality of edge nodes. The service cluster may aggregate or replicate user data received from the edge nodes to which it is connected.
AS 1006 includes a plurality of AS nodes. AS nodes within the same AS may share the same physical network characteristics, and the quality of the transmission between AS nodes may be highly reliable. For example, the AS node may be the primary node of an international network connection. Each AS node may be connected to multiple serving clusters. And the AS node may aggregate the user data received from the edge nodes connected thereto.
In each layer in
For example,
User data sent by the first terminal may be transmitted to the second AS node (e.g., trans-country transmission) via the first AS node in the
As can be seen from the above description, by dividing the
As described above, those skilled in the art will note that all or part of the present invention described herein may be implemented using a general purpose computer or processor with a computer program that, when executed, performs any of the corresponding techniques, algorithms, and/or instructions described herein.
The computing devices described herein (and the algorithms, methods, instructions, etc. stored thereon and/or executed thereby) may be implemented by hardware, software, or any combination thereof. The hardware may include a computer, Intellectual Property (IP) core, Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), programmable logic array, optical processor, programmable logic controller, microcode, microcontroller, server, microprocessor, digital signal processor, or any other suitable circuit. In the claims, the term "processor" should be understood to encompass one or more combinations of any of the above.
Aspects described herein may be described by functional block components and various processing operations. The flows and sequences herein may be performed alone or in any combination. Functional blocks may be implemented by hardware and/or software components that perform any number of specific functions. For example, the described aspects may employ various integrated circuit components, e.g., memory elements, processing elements, logic elements, look-up tables, or the like, to carry out various functions under the control of one or more microprocessors or other control devices. Similarly, software programming or software elements, if desired, for implementing the various functions of the described content may be implemented using any programming or scripting language, such as C, C + +, Java, assembler, or the like, and any combination of data structures, objects, processes, routines or other programming elements may be used to implement the various algorithms. Various functions may be implemented by executing algorithms on one or more processors. Further, the various functions described herein may be electronically configured, signal processed and/or controlled, data processed, etc., using any number of conventional techniques. The terms "mechanism" and "element" are used broadly herein and are not limited to mechanical or physical implementations, but may include software routines or the like in conjunction with a processor.
Embodiments or portions of embodiments of the above invention can take the form of a computer program product accessible from or used by a computer or a computer-readable medium. A computer-usable or computer-readable medium may be any apparatus that may contain, store, communicate, or transport the program or data structure for use by or in connection with any processor. The medium may be an electronic, magnetic, optical, electromagnetic or semiconductor device, or the like. Other suitable mediums may also be included. The computer-usable or computer-readable medium may be referred to as non-transitory memory or medium, and may include RAM or other volatile memory or storage, which may change over time. The device memory described herein need not be physically embodied in the device, but rather can be accessed remotely from the device and need not be contiguous with other physically embodied memory in the device, unless specifically stated otherwise.
One or more of the functions described herein as being performed by examples of the invention may be implemented using machine readable instructions for operating the hardware in one or more combinations of the preceding. The computing code may be embodied in one or more modules by which one or more combined functions may be performed as a computing utility, with input and output data being communicated between each module and one or more other modules when executing the methods and systems described herein.
The terms "signal" and "data" may be used interchangeably herein. Moreover, the various portions of the computing device functionality need not be implemented in the same manner. Information, data, and signals may be represented using any of a variety of different technologies and techniques. For example, any data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by one or more combinations of voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, and so forth.
The term "example" is used herein to mean exemplary, instance, or illustration. Any feature or design described herein as "exemplary" is not necessarily indicative of any advantage or advantage over other features or designs. Rather, the term "example" is used to present concepts in a concrete fashion. Furthermore, the use of the phrases "a function" or "an function" in various places throughout the specification is not intended to imply the same embodiment or function.
The word "or" as used herein is intended to mean an inclusive "or" rather than an exclusive "or" of two or more elements referred to. That is, the word "X" includes A or B "is intended to mean any of the natural inclusive permutations, unless otherwise indicated herein or otherwise clearly contradicted by context. In other words, if X comprises a, X comprises B, or X comprises a and B, then "X comprises a or B" holds true under any of the foregoing instances. By analogy, "X includes one of A and B" means "X includes A or B". The term "and/or" as used in this disclosure is intended to mean "and" or a non-exclusive "or". That is, "X includes A, B and/or C" is intended to mean that X can include A, B and any combination of C, unless otherwise indicated or clearly indicated by context. In other words, if X includes a, X includes B, X includes C, X includes a and B, X includes B and C, X includes a and C, or X includes all of A, B and C, then each or more of the foregoing corresponds to the description of "X includes A, B and/or C". By analogy, "X includes at least one of A, B and C" means "X includes A, B and/or C".
The use of "including" or "having" and its equivalents herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. The term "if" herein can be interpreted as meaning "when," "when … …," or "assuming," etc., depending on the context.
In the context of the present invention (and in particular in the claims below), the words "a", "an" and "the" and similar referents are to be construed to cover both the singular and the plural of one or more. Further, recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, and each separate value is incorporated into the specification as if it were individually recited herein. Finally, the steps of all methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of examples or exemplary language (e.g., "such as") provided herein is intended better to illuminate the invention and is not intended to limit the scope of the invention unless otherwise claimed.
Various headings and sub-headings are used herein to list listed items. These are included to enhance readability and to simplify the process of finding and referencing material. These headings and sub-headings are not intended to, nor are they intended to, affect the interpretation of the claims or limit the scope of the claims in any way. The specific implementations shown and described herein are illustrative examples of the invention and are not intended to limit the scope of the invention in any way.
All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.
While the invention has been described in connection with certain embodiments and examples, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims, which scope is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent arrangements as is permitted under the law.