Patent Application
20120275501
The present patent document relates to system synchronization clocks embodied in a pluggable form factor and networks, systems and methods related thereto.
It is very often important for devices that reside on communication networks to have their system clocks synchronized. With the emergence of Carrier Ethernet and the migration of wireless backhaul from Plesiochronous Digital Hierarchy (PDH) and Synchronous Optical Networking Technologies (SONET)/Synchronous Digital Hierarchy (SDH) based networks to Ethernet based backhaul, the need for network clock synchronization has increased dramatically. However, accurate synchronization is very difficult to achieve without dedicated hardware.
While protocols exist that address the needs for a packet protocol for clock distribution, such protocols loose considerable accuracy when implemented purely in software and require hardware assistance to assure the precise accuracies desired. Furthermore, today's Carrier Ethernet networks comprise large quantities of Carrier Ethernet devices (switches, routers, network interface devices (NIDs)) that have no capability to implement clock distribution protocols either in software or hardware.
In view of the foregoing, an object according to one aspect of the present patent document is to provide a synchronization clock embodied within a pluggable transceiver. Preferably the apparatuses and methods address, or at least ameliorate one or more of the problems described above. To this end, a pluggable synchronization clock is provided. The pluggable synchronization clock comprises a pluggable transceiver and a system clock synchronization subsystem embodied within the pluggable transceiver.
In one embodiment, the system clock synchronization subsystem is adapted to implement a packet based precision time protocol. In another embodiment, the system clock synchronization subsystem is adapted to perform a first portion of the precision time protocol and further adapted to interface with a host system adapted to perform a second portion of the precision time protocol.
In yet another embodiment, the system clock synchronization subsystem further includes a timestamp unit. In various embodiments, the timestamp unit is adapted to timestamp a frame in hardware. In other embodiments, the timestamp unit is adapted to timestamp a frame in software.
In another aspect of the present patent document, a pluggable transceiver is provided. The pluggable transceiver comprises a system clock synchronization subsystem, a first interface and a second interface. The first interface is in communication with the system clock synchronization subsystem and is adapted to receive packets from an external network. The second interface is in communication with the system clock synchronization subsystem and is adapted to communicate with a host system.
In one embodiment, the system clock synchronization subsystem further comprising a time stamp unit. The time stamp unit may be adapted to time stamp packets using hardware. In other embodiments, the system clock synchronization subsystem may further include a processor unit that is adapted to time stamp packets in software.
In another embodiment, the system clock synchronization subsystem is adapted to process packets that conform with a precision time protocol. In certain of those embodiments, the precision time protocol conforms with the IEEE-1588v2 standard.
In yet another embodiment, the system clock synchronization subsystem is adapted to perform a portion of a precision time protocol and further adapted to communicate over the second interface with a host adapted to perform a second portion of the precision time protocol.
In another aspect of the present patent document, a method of synchronizing a time of a first clock with a time of a second clock is provided. The method comprises the steps of: receiving information about the time of the second clock on a first interface of a pluggable transceiver; and sending information about the time of the second clock on a second interface of the pluggable transceiver to a host device of the first clock.
In at least one embodiment, the method further comprises the step of synchronizing the time of the first clock with the time of the second clock. In various embodiments, the host device of the first clock is also the host device of the pluggable transceiver. In other embodiments, a host device of the second clock is also the host device of the pluggable transceiver.
In yet another embodiment of the method, the information about the time of the second clock is adapted to a precision time protocol standard.
In another aspect of the present patent document, a method of synchronizing a time of a device clock with a master clock is provided. The method comprises the steps of: receiving packetized information about the time of the master clock from a pluggable transceiver; calculating a transit time of the packetized information between the master clock and the device clock; and synchronizing the device clock with the master clock. In one embodiment of the method, the device clock is a component of a wireless base station.
In yet another aspect of the present patent document, a networking device with a system clock synchronization capability is provided. The networking device comprises: memory; a processor in communication with the memory; a system clock in communication with the processor; and executable instructions residing in the memory and adapted to be executed by the processor, wherein the executable instructions are designed to receive clock information from a pluggable transceiver via a host system interface and use the clock information to synchronize the system clock.
In one embodiment, the clock information is received in a packet format that is adapted to a precision time protocol standard.
In the following description of the preferred embodiments, reference is made to the accompanying drawings that form a part of this patent document, and in which specific embodiments are shown by way of illustration. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present patent document.
Consistent with its ordinary meaning, “hot pluggable transceiver” or “pluggable transceiver” (hereinafter HPT) includes any optical and/or other media transceiver that is pluggable. For example, HPT includes any transceiver that may be added or interposed into a system while the system is operational or non-operational. HPTs include transceivers adapted for any purpose including transceivers adapted and arranged to interface a network device motherboard to a fiber optic or copper networking cable (for a switch, router, media converter or other such devices). To this end, HPTs may be in any shape or customized design including any format or design which is suitable for the function for which the HPT is intended to perform. HPTs may also come in any form factor, including but not limited to formats such as SFP (Small Form-factor Pluggable), XFP (10 Gigabit Small Form Factor Pluggable), XENPAK, X2, QSFP, CFP and others. The definition of HPT is not limited by any particular form factor and HPTs may be in any form factor including form factors yet to be developed.
HPTs may be utilized for a number of applications including in any type of digital data transfer systems, various optical fiber communications systems, and communication networks. The present patent document teaches various embodiments of a system clock synchronization subsystem embodied within a HPT. In some preferred embodiments, a system clock synchronization subsystem that conforms with IEEE 1588 is embodied within a HPT. By providing a synchronization clock within a HPT, the synchronization clock may be dynamically added to any existing system design that accepts HPTs. The present patent document provides the means of adding system clock synchronization capabilities to any Ethernet system (ex. switch, router, bridge, hub, etc) equipped with an available pluggable transceiver network interface (ex. Fast Ethernet, or Gigabit Ethernet or 10G Ethernet). This allows systems to dynamically add a synchronization clock at any time.
The present patent document further teaches the operational and functional combination of synchronization clocks embodied in pluggable transceivers with their respective systems, networks, and the methods associated therewith. The various aspects of the embodiments relate also to hardware and software-enabled operational and functional systems, modules, networks, devices, apparatus and methods utilizing numerous possible combinations of hardware and software with system clock synchronization subsystems embodied in HPTs.
Pluggable synchronization clock 10, may be embodied in an HPT 18 adapted to operate at various different speeds including speeds from a few Megabits per second (Mbps) up to 10 Gigabits per second (Gbps). In other embodiments, pluggable synchronization clock 10 may operate at 40 Gbps or even 100 Gbps.
Generally speaking, the evolution of HPTs throughput is likely to evolve in parallel with the progress of networking technologies. Indeed, over the past years, new types of faster and smaller HPTs have been created. As an example of the evolution of HPTs, GBIC was one of the first HPTs to be created. Shortly after the introduction of GBIC, SFP; and 10G XENPAK became available, followed by X2, by XFP and now SFP+. In response to higher speed and capacity needs, the 40G and 100G industries created the QSFP+ and CFP interface, and are expected to create more types of such HPTs. New and/or faster HPT's will soon be available and the present patent document contemplates embodiments of pluggable synchronization clock 10 not only with existing technologies, but also embodiments of pluggable synchronization clock 10 adaptable for use with those yet to be developed faster technologies.
The system clock synchronization subsystem 12 is any subsystem adapted for use in synchronizing clocks on more than one device. For example, multiple devices on a communication network may all have an internal clock. System clock synchronization subsystem 12 may be used by itself or in combination with other system clock synchronization subsystems to allow the internal clocks to synchronize their time.
In preferred embodiments, the pluggable synchronization clock 10 may comply with one or more industry standards, such as the MSA (Multi-Source Agreement). Accordingly, pluggable synchronization clock 10 may be compatible with the equipment of numerous network component vendors. In addition, various embodiments of pluggable synchronization clock 10 may support one or multiple major communication protocols. For example, in various embodiments, pluggable synchronization clock 10 may support communication protocols such as SONET/SDH, Ethernet, Fiber Channel, or other communication protocols.
The pluggable synchronization clock 10 communicates with the host system through the host system interface 14. In embodiments where the pluggable synchronization clock 10 complies with an industry standard, the host system interface 14 between the pluggable synchronization clock 10 and the host system may also comply with a well defined electrical interface standard. Preferably in such embodiments, the electrical host system interface 14 comprises connector pins for: 1) Power supply—the system supplies power (VCC) to the transceiver; 2) Ground (TX and RX)—the system supplies reference ground to the transceiver Transmitter and Receiver circuitry; 3) I2C=Transceiver management bus. This slow management bus (I2C) allows provisioning and monitoring of the pluggable transceiver. Through this path, a hosting system can read the basic static transceiver information (transceiver type, manufacturer, serial number, maximum rate, etc.) as well as dynamic running time information (transmit power, receive power, bias current, operational alarms, etc.); 4) Data transfer—differential data TX and RX; 5) Other services like transmit enable or data rate select and/or error indication (TX Fault, LOS, etc.).
In a preferred embodiment, the host system interface includes a serial interface that uses Ethernet (ex. 100-FX or 1000-X or 10G SFI). In other embodiments, other networking protocols may be used. Using a networking protocol to communicate with the host system prevents any special handling by the host system because the data received from the pluggable synchronization clock 10 will be in conformity with the type of data the host system is designed to receive. This reduces the overhead and development of the host systems and makes the pluggable synchronization clock 10 compatible across a broad range of host system devices.
In a preferred embodiment, the pluggable synchronization clock primarily communicates with the host system via the data path (TX and RX) generally employed by the HPT hosting system to transmit and receive protocol data to/from the networking link. Communication between the host and the pluggable synchronization clock 10 via the data path is known as in-band access. In-band access may provide control to the host of both the HPT 18 and the system clock synchronization subsystem 12. For example, if the pluggable synchronization clock 10 is plugged into an Ethernet device (Ethernet switch or router or converter or plainly any computing system with a HPT Ethernet interface), communication may occur via Ethernet packets sent over the TX and RX lines.
The implementation of the in-band access between the host and the pluggable synchronization clock 10 may vary in range and complexity depending on the embodiment. There are numerous options, combinations and permutations of the range and complexity of the in-band access in embodiments that incorporate such access. Several of the preferred embodiments are, for example: 1) Simple layer 2 based proprietary access methods; and 2) Standard TCP/IP based protocols, like SNMP, HTTP, and other control protocols.
If the in-band access uses a simple layer 2 based proprietary access method, the access may be based on a proprietary simple Ethernet layer-2 packet based read/write protocol. Advantageously, no upper layer, like TCP/IP, must be employed. Security aspects in a system thus equipped may be done at the overall network access level.
If the in-band access use a control protocol such as SNMP or other control protocols, standard data security methods may be applied before transport. Any of the embodiments may further include provisioning, for example, of the TCP/IP parameters, security parameters or any other parameter.
In addition to in-band access, other channels of communication may exist as an alternative to or in addition to the data path. For example, the pluggable synchronization clock 10 may communicate with the host system via the slow management bus (I2C) intended for provisioning and monitoring of the HPT or via the special services lines for enabling activity, data rate selection or error/event monitoring. Various embodiments of the pluggable synchronization clock 10 may incorporate different communication methods or combinations thereof with the host system.
In one embodiment, the functionality of the HPT 18 and/or the system clock synchronization subsystem 12 may be initialized and configured/provisioned through the standard HPT bus (I2C) interface. In a preferred embodiment, the HPT 18 and/or the system clock synchronization subsystem 12 are initialized and configured/provisioned through standard MSA defined registers, however, in other embodiments; additional I2C based registers may be used.
Depending on the design of the pluggable synchronization clock 10, various data channels with the host system via the host system interface 14 may be used to control just about any aspect of the pluggable synchronization clock 10. However, in many preferred embodiments, the HPT I2C interface is the control interface. Through this interface, the hosting system may: 1) Enable/disable in-band provisioning access; 2) Enable/disable various modes of operation; Configure any appropriate in-band access parameters (depending on the specific in-band access implemented); Configure any protocol specific parameters, like for example real time clock setting and alignment. Furthermore, in many preferred embodiments, the special control and monitoring lines may be used for implementing specific tasks, like enabling or provisioning features or for error/event monitoring.
While the embodiment of the pluggable synchronization clock 10 shown in
In at least one embodiment of the pluggable synchronization clock 10, a system clock synchronization subsystem 12 is embodied in an HPT 18 that complies with the SFP standard.
In the embodiment shown in
In a preferred embodiment, the software or instructions for allowing the CPU 29 to control the system clock synchronization subsystem 12 may be burned into the CPU 29, such as in an ASIC. In other embodiments, CPU 29 may be in communication with memory (not shown) such that the software or instructions to control the system clock synchronization subsystem 12 resides in the memory and is/are executed by the CPU 29 during operation. In yet other embodiments, some of the software and/or instructions on how to operate the system clock synchronization subsystem 12 reside on the host system and are communicated to the CPU 29 via the host system interface 14 during operation. In other embodiments, various combinations of software and instructions residing within the CPU 29, within memory, and within the host system are used.
The embodiment of the pluggable synchronization clock 20 shown in
The embodiment of the pluggable synchronization clock 20 shown in
The embodiment shown in
In one embodiment of pluggable synchronization clock 10, the system clock synchronization subsystem 12 conforms to the Precision Time Protocol (PTP). The PTP was first standardized by the IEEE in 2002 as IEEE-1588. In 2008, an enhanced version two (2) was released (also known as PTPv2 or IEEE 1588v2). In preferred embodiments, the system clock synchronization subsystem 12 supports IEEE 1588 and more preferably IEEE 1588v2. Both versions of IEEE 1588 are incorporated by reference herein. “PTP” is used hereinafter to refer to either version of the IEEE 1588 standard. The present patent document describes a system clock synchronization subsystem 12 that complies with the PTP, however, other embodiments may implement other packet-based clock synchronization protocols, methods and mechanisms. In various embodiments, different protocols may be implemented over any data protocol.
In embodiments where a specific protocol or protocols are implemented, such as the PTP, the protocol may be implemented by the hosting system processor, by the CPU 29 residing on the HPT 18, or a combination of both. The system clock synchronization subsystem 12 provides accurate time stamping for the purpose of implementing time synchronization protocols such as the PTP but does not necessarily have to implement the protocol itself. In one embodiment, the in-band access may be used to implement the distributed system clock synchronization protocol. In this case, the system clock synchronization subsystem 12 may assists the hosting system CPU in the implementation of the system clock synchronization protocol. The control of the system clock synchronization subsystem may be performed through a proprietary in-band protocol. The in-band interface is the path for incoming and outgoing protocol message detection and/or processing, for either of the processor architectures (internal or external).
The PTP is an industry standard protocol that enables the precise transfer of frequency and time to synchronize clocks over packet based Ethernet networks. In operation, devices that reside on a communication network that wish to have their system clock synchronized with other device system clocks may include an embodiment of the pluggable synchronization clock 20 running the PTP. The PTP selects a single grandmaster clock from the available devices attempting to synchronize their clocks and then designates the remainder of the devices as slave clocks. The slave clocks are then synchronized with the system grandmaster clock. The PTP uses traffic time stamping, with sub-nanosecond granularity, to deliver the very high accuracies of synchronization needed to ensure the stability of base station frequency and handovers.
Timestamps between master and slave devices are sent within specific PTP packets by the pluggable synchronization clock 10 and in its basic form, the protocol is administration free. Of course, the precision and performance of the PTP is based on the precision of the timestamp by the TSU 21. Accordingly, it is preferably that the timestamp is performed by hardware in the TSU 21 instead of software.
The timestamps of incoming and outgoing packets need to be recorded and assessed to ensure synchronization of the various device's system clocks. Although in various embodiments, the implementation of the system clock synchronization protocol, such as the PTP, may be distributed in different amounts between the CPU residing on the system and the CPU 29 residing on the pluggable synchronization clock 10, the protocol must determine any variation in time between the slave clock and the master clock and update the device system clock accordingly. Differences in time and frequency between master and slave clocks may be evaluated based on the time stamps of the PTP packets. Clocks of each device must be measured to ensure they are within their specified limits and subsequent equipment corrections evaluated. In determining whether any equipment timing corrections are necessary, delays and drifts in sync and their effect on the transfer of timing through the network need to be considered.
When implemented correctly, the PTP is capable of providing high precision timing for large networks. The PTP employs short synchronization frames (to save network bandwidth), transparent clocks to avoid exponential error propagation in cascaded networks, as well as unicast connections to allow the synchronization of devices over long distance connections or via devices not supporting PTP (e.g. routers). The PTP provides configuration sets used by specific devices, known as “profiles”, thus simplifying the configuration of the nodes and guaranteeing the proper behavior and performance for specific systems.
Depending on whether a device is a master or a slave, the number of ports the device has, and the devices role in the network, a different type of PTP clock may be instantiated by the PTP protocol on the device. Table 2 lists the five different types of clock devices defined by the PTP.
Master and slave network devices are kept synchronized by the transmission of time stamps sent within the PTP messages. The time stamps may be provided by the TSU 21. There are two (2) types of messages in the PTP protocol: Event Messages and General Messages. Event Messages are timed messages whereby an accurate time stamp is generated both at transmission and receipt of the message. General Messages do not require time stamps but may contain time stamps for their associated event message. The various PTP messages defined by the IEEE 1588v2 standard are described in Table 3.
In order to correctly sync the master and slave clocks of different devices, the propagation delay between devices must be accurately measured. The PTP provides two mechanisms to measure the propagation delay between PTP ports: 1) The Delay Request mechanism; and 2) The Peer Delay Mechanism. The Delay Request Response Mechanism uses the messages: Sync; Delay_Req; Delay_Resp; and, if required, Follow_up. The Peer Delay Mechanism uses the messages: Pdelay_Req; Pdelay_Resp; and, if required, Pdelay_Resp_Follow_Up. The Peer Delay Mechanism is restricted to topologies where each peer-to-peer port communicates PTP messages with, at most, one other such port.
Ports on Ordinary or Boundary clocks can use either mechanism; ports on end-to-end transparent clocks are independent of these mechanisms, and ports on peer-to-peer transparent clocks use only the peer delay mechanism. It should also be noted that the two mechanisms do not inter-work on the same communication path.
Once the protocol is initiated, there are two phases in the normal execution of the protocol: Phase 1 establishes the Master-Slave hierarchy; and Phase 2 synchronizes the clocks using either of the two above described mechanisms.
Master-Slave hierarchy is established between any pair of ports running PTP. In each port of any device that includes an Ordinary or Boundary clock, there is a PTP state machine. These state machines use the ‘Best Master Clock Algorithm’ (BMCA) to establish the Master clock for the path between two ports. The statistics of the remote end of a path are provided to each state machine by the Announce message. Since the local clocks statistics are already known by the state machine, a comparison can be made as to which is the best Master.
A method for synchronizing ordinary and boundary clocks using the Delay Request-Response Mechanism will now be described. After the Master-Slave hierarchy has been established, the clock synchronization phase can start. The clock synchronization phase consists of the exchange of PTP timing messages on the communication path between two devices that include PTP clocks. For example, two devices that include a pluggable synchronization clock 20. There are two parts to this synchronization method: 1) Measuring the propagation delay between Master and Slave; and 2) Performing the clock offset correction.
Measuring the propagation delay between Master and Slave is performed using the Delay Request-Response Mechanism.
Once the Slave knows the timing of t1, t2, t3, and t4, it can calculate the mean propagation delay (TMPD) of the messages path. This is calculated using the following equation:
The Sync and optional Follow_Up messages give the master to slave message propagation time (t-ms). The Delay_Req and Delay_Resp messages give the slave to master message propagation time (t-sm). Any asymmetry between t-ms and t-sm introduces an error into the clock offset correction.
Once the propagation delay is known, the Master can send the sync message and the optional Follow_Up messages containing its master timestamp. Because the propagation delay between the Master and the Slave is known by the Slave, the clock correction can occur in the Slave device and the Slave can sync its clock with the Master device.
t2−t1−TMPD
The above is a simple model that does not show any end-to-end transparent clocks. Transparent clocks were added in version two of the IEEE 1588 standard released in 2008. End-to-end transparent clocks do not serve as Master or Slave clocks but they do insert/update a correction field into event messages that allows adjustment of timestamps at the Slave device to remove residence times through any transparent clock devices/bridges. The above model would not include any peer-to-peer transparent clocks as these cannot coexist on the same communications path as the Delay Request-Response Mechanism.
As an alternative to the Delay Request Response Mechanism, devices may sync their boundary clocks using the Peer Delay Mechanism. Similar to the Delay Request Response Mechanism, the Peer Delay Mechanism is initiated after the Master clock has been selected. There are two parts to synchronizing boundary clocks using the Peer Delay Mechanism. First, the link propagation delay is measured and then the clock offset correction can be performed.
Once Port 1 knows the timing of t1, t2, t3, and t4, it can calculate the mean link delay (TMLD). This is calculated using the following equation:
The device uses the TMLD when calculating the correction field for each Sync or Follow_Up message that passes through the bridge. The outgoing correction field will be the sum of the residence time, the mean link delay and any correction field from upstream ports. The Pdelay_Req, Pdelay_resp and optional Pdelay_Resp_Follow_Up messages allow the round trip link delay to be calculated (t-ms+t-sm). Any asymmetry between t-ms and t-sm introduces an error into the clock offset correction.
Once the TMLD has been calculated the Slave devices may perform the clock offset correction. Referring back to
t2−t1−correctionField
A benefit of peer-to-peer path correction is that the path delay of each individual Sync or Follow_Up message is calculated as it travels along the communication path. It is therefore not affected by a change to the path. When using the Peer Delay Mechanism the clock synchronization does not require the return path to be calculated as it does in the basic exchange, i.e. the Delay_Req, Delay_Resp messages shown in
The PTP may be transported over many different protocol types and the pluggable synchronization clock 10 may be adapted to support such protocols. Preferably, the pluggable synchronization clock 10 is adapted to run the PTP over UDP using IPv4. However, in other embodiments, other combinations of protocols may be used. For example, the pluggable synchronization clock 10 may be adapted to run the PTP over UDP using IPv6, IEEE 802.3/Ethernet, DeviceNET, ControlNET, IEC 61158 Type 10 (Fieldbus) or any other type of data transport protocol.
In PTP over UDP using IPv4 or IPv6 over Ethernet, the first byte of the PTP message immediately follows the final byte of the UDP header. The UDP port identifies the UDP datagram as a PTP message. In PTP over IEEE 802.3/Ethernet the first byte of the PTP message occupies the first byte of the client data field of the Ethernet frame. The Ethernet type field is set to 0x88F7 and identifies the client data field as a PTP message.
Although numerous embodiments of the present invention include a system clock synchronization subsystem 12 embodied in a HPT, other embodiments encompass the operational and functional combination of HPTs including a system clock synchronization subsystem 12 with networking equipment designed to interface with HPTs. For example, one embodiment of the present invention includes an Ethernet router with an HPT interface including a HPT with a system clock synchronization subsystem 12 embodied therein. Another embodiment includes a data communication network with a first communication device including a HPT 18 with a system clock synchronization subsystem 12 and a second communication device including a HPT 18 with a system clock synchronization subsystem 12. Other embodiments consist of the software-enabled operational of an HPT 18 including a system clock synchronization subsystem 12.
In addition to providing an easy way to sync the system clock of the host device, other embodiments may also provide external signals that may be used to sync other clocks. For example, in one embodiment the system clock synchronization subsystem 12 generates a sync signal and outputs it to other devices. The sync signal may be output via the host system interface 14, external port 16, or an additional interface designed specifically for such signal. In one embodiment, variable external clock frequencies or an external PPS signal are generated for accuracy measurements.
The various embodiments of the pluggable synchronization clock described above may be used to provide the existing installed base Carrier Ethernet devices with an HPT interface (switches, routers, NIDs) with the capability of adding support for system clock synchronization protocols such as IEEE 1588v2 at the resolution required by wireless-backhaul installations (for ex. sub-100 nanosecond resolution, 1 pps, 10 MHz, etc.). In addition, embodiments of the pluggable synchronization clocks described herein may be used to generally synchronize different systems with independent clocks. Such synchronization may be used in Carrier Ethernet (and others) network testing, like Y.1731, MEF 10, MEF 17, and others.
In another example of how embodiments of the pluggable synchronization clocks described herein may be implemented, two edge Carrier Ethernet Switches do not have native support for hardware-based clock synchronization. With the addition of an embodiment of the pluggable synchronization clock, the edge Carrier Ethernet Switches are capable of synchronizing their clocks. As a result, the two systems can accurately run all the Y.1731/MEF 17 IA SLA assurance tests, including the challenging unidirectional latency (delay measurement DM) and jitter (delay variation DV) testing.
Although the embodiments have been described with reference to the drawings and specific examples, it will readily be appreciated by those skilled in the art that many modifications and adaptations of the processes and apparatuses described herein are possible without departure from the spirit and scope of the embodiments as claimed herein. Thus, it is to be clearly understood that this description is made only by way of example and not as a limitation on the scope of the embodiments as claimed below.
This application claims the benefit of U.S. Provisional Application No. 61/479,670, filed Apr. 27, 2011, which is hereby incorporated by reference
| Number | Date | Country | |
|---|---|---|---|
| 61479670 | Apr 2011 | US |
