U.S. patent application number 14/493171 was filed with the patent office on 2015-02-19 for methods and apparatus for transmitting data streams via a heterogeneous network.
The applicant listed for this patent is Apple Inc.. Invention is credited to Ashley Ian Butterworth, Matthew Xavier Mora, Niel David Warren, Andrew Yanowitz.
Application Number | 20150052257 14/493171 |
Document ID | / |
Family ID | 47749158 |
Filed Date | 2015-02-19 |
United States Patent
Application |
20150052257 |
Kind Code |
A1 |
Mora; Matthew Xavier ; et
al. |
February 19, 2015 |
METHODS AND APPARATUS FOR TRANSMITTING DATA STREAMS VIA A
HETEROGENEOUS NETWORK
Abstract
Methods and apparatus that enable a community of devices having
differing underlying protocols to stream media data such as video
or audio data. In one exemplary embodiment, this invention enables
IEEE 1394-compliant ("FireWire" enabled) devices to communicate
across an Ethernet infrastructure, such as one enabled by the
Ethernet AVB Standard(s). This enhances connectivity, and also
supports obviating one or more physical ports within the device(s).
In another embodiment, or more wireless transports are
utilized.
Inventors: |
Mora; Matthew Xavier;
(Fremont, CA) ; Butterworth; Ashley Ian;
(Normanhurst, AU) ; Yanowitz; Andrew; (Ben Lomond,
CA) ; Warren; Niel David; (Soquel, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Apple Inc. |
Cupertino |
CA |
US |
|
|
Family ID: |
47749158 |
Appl. No.: |
14/493171 |
Filed: |
September 22, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13784689 |
Mar 4, 2013 |
8843670 |
|
|
14493171 |
|
|
|
|
12572995 |
Oct 2, 2009 |
8392631 |
|
|
13784689 |
|
|
|
|
61195141 |
Oct 2, 2008 |
|
|
|
Current U.S.
Class: |
709/227 |
Current CPC
Class: |
H04L 12/40117 20130101;
H04L 67/141 20130101; H04L 12/4011 20130101; H04L 69/08 20130101;
G06F 2213/0012 20130101; H04L 12/40097 20130101; G06F 15/16
20130101; H04L 69/18 20130101; G06F 13/00 20130101; G06F 13/102
20130101 |
Class at
Publication: |
709/227 |
International
Class: |
H04L 29/08 20060101
H04L029/08; H04L 29/06 20060101 H04L029/06 |
Claims
1-2. (canceled)
3. An apparatus configured to interoperate with a heterogeneous
fabric, comprising: an interface to the heterogeneous fabric, the
heterogeneous fabric configured to support multiple different
device protocols; a user interface; a processor; and a
non-transitory computer readable apparatus having a storage medium
with at least one computer program stored thereon, the at least one
computer program configured to, when executed on the processor,
cause the apparatus to: responsive to a connection to the
heterogeneous fabric, register the apparatus with a network daemon;
identify one or more other devices connected to the heterogeneous
fabric via the network daemon; and responsive to a user request via
the user interface, initiate a data connection to at least a target
device of the one or more other devices within a user session.
4. The apparatus of claim 3, wherein the user session is initiated
and terminated based at least in part on user input received by the
user interface.
5. The apparatus of claim 3, wherein the interface to the
heterogeneous fabric is configured to format packets of a first
protocol into packets of a second protocol, the second protocol
being native to the heterogeneous fabric.
6. The apparatus of claim 3, wherein the first protocol is native
to the target device.
Description
PRIORITY
[0001] This application is a divisional of and claims priority to
co-owned and co-pending U.S. patent application Ser. No. 13/784,689
of the same title filed Mar. 4, 2013, issuing as U.S. Pat. No.
8,843,670 on Sep. 23, 2014, which is a divisional of U.S. patent
application Ser. No. 12/572,995 of the same title filed Oct. 2,
2009, now U.S. Pat. No. 8,392,631, which claims priority to U.S.
Provisional Patent Application Ser. No. 61/195,141 filed Oct. 2,
2008 of the same title, each of which are incorporated by reference
herein in their entirety.
COPYRIGHT
[0002] A portion of the disclosure of this patent document contains
material that is subject to copyright protection. The copyright
owner has no objection to the facsimile reproduction by anyone of
the patent document or the patent disclosure, as it appears in the
Patent and Trademark Office patent files or records, but otherwise
reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
[0003] 1. Field of Invention
[0004] The present invention relates generally to the field of data
networks and device data sharing. More particularly, in one
exemplary aspect, the present invention is directed to methods and
apparatus enabling a heterogeneous community of devices (e.g.,
those which operate according to a FireWire or Ethernet AVB
protocol) to interoperate seamlessly and transfer data and media
(e.g., audio and video) there between.
[0005] 2. Description of Related Technology
[0006] Modern electronic equipment has greatly enhanced the quality
of life for many. However, as the use of such equipment has
increased, so has the need to connect equipment of differing types
purchased from different manufacturers. For example, while a
computer and a digital camera may each be useful when used alone,
the ability to connect the digital camera to the computer and
exchange information (e.g., photos, video) between the two makes
the combination even more useful. Therefore, a need was apparent
for a serial bus standard that would allow for the connection and
communication between such devices.
[0007] The IEEE 13944995 standard (and its associated trade names
"FireWire.TM." (Apple Inc.), "i.LINK" (Sony), and "Lynx" (Texas
Instruments), etc.) was developed to satisfy this need. This
standard revolutionized the consumer electronics industry by
providing a serial bus management system that featured high speeds
and the ability to "hot" connect equipment to the bus; that is, the
ability to connect equipment without first turning off the existing
connected equipment. Since its adoption, the IEEE 1394-1995
standard has seen acceptance in the marketplace with many major
electronics and computer manufacturers providing IEEE 1394-1995
connections on equipment that they sell. Several variants of IEEE
1394 have also been developed and widely deployed which improve and
enhance various system characteristics (including e.g., higher
speeds and longer connection paths).
[0008] In addition to IEEE 1394 based standards, a new standard
being proposed at the time of the filing of the present application
is herein referred to as the "Ethernet AVB standard". Ethernet AVB
is a new standard being developed for transmitting audio and video
data across an 802.1 Ethernet link. Existing Ethernet standards
guarantee packet delivery; Ethernet AVB is expected to provide
additional capabilities enabling isochronous data transfer.
Specifically, Ethernet AVB provides guarantees on maximum latency
and minimum bandwidth that enable "streaming" applications, which
were previously limited due to requirements for low latency
isochronous transfer of audio and video.
Unsatisfied Need for Interoperability
[0009] Due to the widespread existing deployments of existing IEEE
1394 devices, and the virtually universal Ethernet infrastructure,
a solution for providing interoperability for the two standards
seamlessly (with respect to various types of media) would greatly
enhance the overall utility of both. Such a solution does not
currently exist.
[0010] Another issue relates to the increasing "disappearance" of
physical ports on hardware devices such as computers, video
cameras, etc. over time. These physical ports (including FireWire
ports) are becoming less prolific on new generation devices
because, inter alia, aggressive form factor reductions no longer
allow distinct connectors for all supported I/O technologies. Thus,
physical space for the port and the extra cost of the port make it
a strong candidate for removal. For example, in the MacBook Air
product manufactured by the Assignee hereof, connectors include
only a USB port, power port and a video port. Neither a physical
FireWire port nor Ethernet port are present on the device. As the
number of (FireWire and other) ports disappear, so do the
connectivity opportunities for devices using that port
specification. Hence, in order to maintain FireWire support and
distribution over such devices, other "ways off of" and "ways onto"
the device are needed.
[0011] Accordingly, improved methods and apparatus are needed for
providing data stream delivery between two differing protocols,
such as for example Ethernet AVB, and IEEE 1394. Such an improved
solution should operate seamlessly and without adversely impacting
user experience on existing apparatus. Moreover, such
"multi-lingual" data stream delivery would be operable without
requiring undue hardware or other modification to implementations
already deployed. To these ends, such data delivery schemes should
minimally support "master-slave" operation, where a dynamically
bridging multi-lingual device performs all translation for its
localized network, without requiring its non-enabled slave devices
to do so.
[0012] Multiple clients would also advantageously work
cooperatively to simultaneously source and sink isochronous
datastreams, each independently capable of additionally splitting
or merging multiple isochronous data streams.
[0013] Lastly, such improved apparatus and methods would enable the
use of IEEE 1394-compliant devices across any geography or
topology, such as by piggybacking on existing Ethernet
infrastructure.
SUMMARY OF THE INVENTION
[0014] The present invention satisfies the foregoing needs by
providing, inter alia, improved apparatus and methods for bridging
data (including audio and video or other multimedia data) across
networks or devices using different protocols.
[0015] In one aspect of the invention, a method for sending a
message from a source device to a target device is disclosed. In
one embodiment, the message is sent via a fabric or other
intermediary architecture, and said source device operates with a
first protocol, and said fabric operates with a second protocol,
said first and second protocols being different. The method
comprises: associating said source device with a software entity;
associating said target device with said software entity;
responsive to said associations of said source device and said
target device, negotiating one or more parameters related to data
stream requirements; receiving at least one message compliant with
said first protocol from said source device; formatting said at
least one messages to be compliant with said second protocol, and
said negotiated one or more parameters; and transmitting said
formatted at least one messages via said fabric.
[0016] In one variant, said source device and fabric are
characterized by isochronous transfer parameters.
[0017] In another variant, the first protocol comprises a
1394-compliant protocol, and the second comprises an Ethernet AVB
compliant protocol.
[0018] In a second aspect of the invention, a source device adapted
for isochronous data transfer is disclosed.
[0019] In a third aspect of the invention, a transfer medium
adapted to facilitate media/data transfer between different
protocol environments is disclosed. In one embodiment, the medium
comprises a fabric capable of connecting 1394.1 bridge portals and
that is capable of transferring any serial bus subaction from one
portal to its co-portal, and that supports bidirectional,
non-blocking transfer of asynchronous request subactions,
asynchronous response subactions, and isochronous subactions.
[0020] In a fourth aspect, a computer readable medium comprising at
least one computer program adapted transfer media/data between
different protocol environments is disclosed.
[0021] In a fifth aspect of the invention, a client device adapted
to run the aforementioned program is disclosed. In one variant, the
client device comprises a desktop or portable computer. In another
variant, the client device comprises a personal media device or
PDA. In yet another embodiment, the device comprises a network
router, such as a home LAN or switch or router.
[0022] In a sixth aspect of the invention, a portal architecture is
disclosed. In one embodiment, the portals comprise 1394.1-compliant
portals disposed on each side of an Ethernet AVB network, and which
employ AVC command interpreters. This approach allows existing
FireWire software to "see" FireWire devices that are not physically
connected to the local FireWire bus (or if there is no local
FireWire bus at all).
[0023] In a seventh aspect of the invention, one or more wireless
protocols are utilized as the bearer(s) for the transported media
content.
[0024] In an eighth aspect of the invention, business models and
associated methods of doing business are disclosed.
[0025] In a ninth aspect, a method of managing connectivity over a
heterogeneous fabric is disclosed. In one exemplary embodiment, the
method includes: receiving an indication of one or more
capabilities associated with a first device, the first device
having a first protocol associated therewith and the first device
being coupled to the heterogeneous fabric, responsive to the
indication, storing at least one device capability associated with
the first device, and responsive to a received request for a
connection to a target device, providing the at least one stored
device capability to the target device.
[0026] In a variant, the target device has a second protocol
associated therewith.
[0027] In a tenth aspect, an apparatus configured to manage
connectivity of a heterogeneous fabric is disclosed. In one
embodiment, the apparatus includes an interface, a processor, and a
computer readable storage medium.
[0028] In a variant, the computer storage medium includes
instructions configured to, when executed by the processor:
responsive to a device having a first protocol associated therewith
being coupled to the heterogeneous fabric, the fabric having a
second protocol different from the first protocol, identify one or
more device capabilities, store the one or more device
capabilities, and responsive to the device requesting connection to
a target device, provide the stored one or more device capabilities
to the target device. The device and the target device in one
implementation initiate a data connection via the heterogeneous
fabric without further intervention by the apparatus.
[0029] In an eleventh aspect, an apparatus for interoperation with
a heterogeneous fabric is disclosed. In an exemplary embodiment,
the apparatus includes: an interface to the heterogeneous fabric,
the heterogeneous fabric comprising multiple different device
protocols, a user interface, a processor, and a computer readable
apparatus having a storage medium.
[0030] In a variant, the storage medium includes a computer program
configured to, when executed by the processor, cause the apparatus
to: responsive to a connection to the heterogeneous fabric,
register with a network daemon, identify one or more other devices
connected to the heterogeneous fabric via the network daemon, and
responsive to a user request via the user interface, initiate a
data connection to at least a target device of the one or more
other devices within a user session.
[0031] Other features and advantages of the present invention will
immediately be recognized by persons of ordinary skill in the art
with reference to the attached drawings and detailed description of
exemplary embodiments as given below.
BRIEF DESCRIPTION OF THE DRAWINGS
[0032] FIG. 1 is a logical flow diagram illustrating one embodiment
of the generalized method of transferring data across a
heterogeneous protocol environment according to the invention.
[0033] FIG. 2 is block diagram illustrating one embodiment of an
apparatus adapted to transfer data across a heterogeneous protocol
environment.
[0034] FIG. 3 is a graphical illustration of protocol stack
interactions between two exemplary devices as part of the data
transfer of FIG. 1.
[0035] FIG. 3A is a graphical illustration of one embodiment of a
data packet structure according to the invention.
[0036] FIG. 3B is a high layer representation of one exemplary
embodiment of a software system comprising a user and kernel space,
according to the present invention.
[0037] FIG. 3C is a graphical representation of one embodiment of
kernel space additions useful for implementing the heterogeneous
protocol data transfer functionality of the present invention.
[0038] FIG. 3D is another graphical representation of various
components of the protocol stack of FIG. 3C, and their
interrelationships.
[0039] FIG. 3E is a graphical representation of one embodiment of
user space additions useful for implementing the heterogeneous
protocol data transfer functionality of the present invention.
[0040] FIG. 3F is a block diagram of one exemplary embodiment of a
software architecture employing a proxy for interfacing between a
first device and various software processes on the same or
different device, using the kernel space and user space components
of FIGS. 3C and 3E, respectively.
[0041] FIG. 4 is a block diagram illustrating one exemplary
heterogeneous community of devices according to the invention.
[0042] FIGS. 5A-5D are block diagrams illustrating various
different user scenarios consistent with the present invention.
DETAILED DESCRIPTION OF THE INVENTION
[0043] Reference is now made to the drawings, wherein like numerals
refer to like parts throughout.
[0044] As used herein, the terms "client device", "end user device"
and "user equipment" or "UE" include, but are not limited to
cellular telephones, smartphones (such as for example an
iPhone.TM.), personal computers (PCs), such as for example an
iMac.TM., Mac Pro.TM., Mac Mini.TM. or MacBook.TM., and
minicomputers, whether desktop, laptop, or otherwise, as well as
mobile devices such as handheld computers, PDAs, video cameras,
set-top boxes, personal media devices (PMDs), such as for example
an iPod.TM., or any combinations of the foregoing.
[0045] As used herein, the term "computer program" or "software" is
meant to include any sequence or human or machine cognizable steps
which perform a function. Such program may be rendered in virtually
any programming language or environment including, for example,
C/C++, Fortran, COBOL, PASCAL, assembly language, markup languages
(e.g., HTML, SGML, XML, VoXML), and the like, as well as
object-oriented environments such as the Common Object Request
Broker Architecture (CORBA), Java.TM. (including J2ME, Java Beans,
etc.), Binary Runtime Environment (BREW), and the like.
[0046] As used herein, the terms "Ethernet AVB" and "Ethernet AVB
Standards" refer, without limitation, to any one or more of the
following as applicable: (i) IEEE Std. P1722; (ii) IEEE Std.
P802.1AS; (iii) IEEE Std. P802.1Qat; (iv) IEEE Std. P802.1Qav; (v)
IEEE Std. P802.1AB; (vi) IEEE Std P802.1BA; (vii) IEEE Std. P1722;
and (viii) IEEE Std. 1394TA 2006021, each of the foregoing being
incorporated herein by reference in its entirety.
[0047] As used herein, the terms "IEEE 1394" and FireWire" refer
without limitation to any one or more of the following as
applicable: (i) IEEE Std. 1394-1995; (ii) IEEE Std. 1394a-2000
amendment; (iii) IEEE Std. 1394b-2002 amendment; and (iv) IEEE Std.
1394c-2006 amendment, each of the foregoing being incorporated
herein by reference in its entirety.
[0048] As used herein, the term "integrated circuit (IC)" refers to
any type of device having any level of integration (including
without limitation ULSI, VLSI, and LSI) and irrespective of process
or base materials (including, without limitation Si, SiGe, CMOS and
GaAs). ICs may include, for example, memory devices (e.g., DRAM,
SRAM, DDRAM, EEPROM/Flash, and ROM), digital processors, SoC
devices, FPGAs, ASICs, ADCs, DACs, transceivers, memory
controllers, and other devices, as well as any combinations
thereof.
[0049] As used herein, the term "memory" includes any type of
integrated circuit or other storage device adapted for storing
digital data including, without limitation, ROM. PROM, EEPROM,
DRAM, SDRAM, DDR/2 SDRAM, EDO/FPMS, RLDRAM, SRAM, "flash" memory
(e.g., NAND/NOR), and PSRAM.
[0050] As used herein, the terms "microprocessor" and "digital
processor" are meant generally to include all types of digital
processing devices including, without limitation, digital signal
processors (DSPs), reduced instruction set computers (RISC),
general-purpose (CISC) processors, microprocessors, gate arrays
(e.g., FPGAs), PLDs, reconfigurable compute fabrics (RCFs), array
processors, secure microprocessors, and application-specific
integrated circuits (ASICs). Such digital processors may be
contained on a single unitary IC die, or distributed across
multiple components.
[0051] As used herein, the terms "network" and "bearer network"
refer generally to any type of data, telecommunications or other
network including, without limitation, data networks (including
MANs, PANs, WANs, LANs, WLANs, micronets, piconets, internets, and
intranets), hybrid fiber coax (HFC) networks, satellite networks,
cellular networks, and telco networks. Such networks or portions
thereof may utilize any one or more different topologies (e.g.,
ring, bus, star, loop, etc.), transmission media (e.g., wired/RF
cable, RF wireless, millimeter wave, optical, etc.) and/or
communications or networking protocols (e.g., SONET, DOCSIS, IEEE
Std. 802.3, 802.11, ATM, X.25, Frame Relay, 3GPP, 3GPP2, WiMAX,
WAP, SIP, UDP, FTP, RTP/RTCP, H.323, etc.).
[0052] As used herein, the terms "network interface" or "interface"
typically refer to any signal, data, or software interface with a
component, network or process including, without limitation, those
of the FireWire (e.g., FW400, FW800, etc.), USB (e.g., USB2),
Ethernet (e.g., 10/100, 10/100/1000 (Gigabit Ethernet), 10-Gig-E,
etc.), MoCA, Serial ATA (e.g., SATA, e-SATA, SATAII),
Ultra-ATA/DMA, Coaxsys (e.g., TVnet.TM.), radio frequency tuner
(e.g., in-band or OOB, cable modem, etc.), Wi-Fi (802.11a,b,g,n),
WiMAX (802.16), PAN (802.15), IrDA or other wireless families.
[0053] As used herein, the term "wireless" means any wireless
signal, data, communication, or other interface including without
limitation Wi-Fi (IEEE Std. 802.11), Bluetooth, 3G (3GPP, 3GPP2,
UMTS), HSDPAIHSUPA, TDMA, CDMA (e.g., IS-95A, WCDMA, etc.), FHSS,
DSSS, GSM, PAN (IEEE Std. 802.15), WiMAX (IEEE Std. 802.16), MWBA
(IEEE Std. 802.20), narrowband/FDMA, OFDM, LTE, PCS/DCS, analog
cellular, CDPD, satellite systems, millimeter wave or microwave
systems, acoustic, and infrared (i.e., IrDA).
[0054] As used herein, the terms "WLAN" and "wireless LAN" refer
generally to any system wherein a wireless or air interface is
employed between two devices, and which provides at least local
area networking capability. Wi-Fi systems are one exemplary
instance of WLANs.
Overview
[0055] In one aspect, the present invention discloses, inter alia,
methods and apparatus that enable a community of heterogeneous
isochronous devices having differing underlying protocols to stream
data such as video or audio data. In one exemplary embodiment, this
invention enables IEEE 1394-compliant ("FireWire" enabled) devices
to communicate across an Ethernet infrastructure, such as one
enabled by the recent Ethernet AVB Standard(s).
[0056] In one variant, the invention enables an IEEE 1394 device to
stream data to an Ethernet AVB-compliant device (or vice
versa).
[0057] In another variant, an IEEE 1394 device may stream data to
another IEEE 1394 device via an Ethernet AVB-compliant fabric.
[0058] In a second alternate embodiment, this invention enables
IEEE 1394-compliant ("FireWire" enabled) devices to communicate
across a wireless network infrastructure, such as one enabled by
IEEE 802.11 (Wireless Local Area Networks).
[0059] In another aspect, methods and apparatus are disclosed which
enable flexible connection management for an isochronous system
having multiple sources and targets (e.g. an audio network). In one
embodiment, such flexible connection management is provided for
without regard to the direction or distribution of datastreams.
[0060] In yet another aspect of the invention, an
implementation-dependent data "fabric" is disclosed. In one
embodiment, the fabric is adapted for compliance with IEEE 1394.1
bridging requirements, and comprises apparatus adapted to
interconnect the 1394.1 bridge portals that is capable of
transferring any serial bus subaction from one portal to its
co-portal, and that supports bidirectional, non-blocking transfer
of asynchronous request subactions, asynchronous response
subactions, and isochronous subactions.
[0061] In one variant, the fabric is limited in geographical extent
(e.g., the bridge portals and fabric are each located within a
common device enclosure or even on a common substrate or module
within the device).
[0062] In another variant, the fabric is physically extensive
(e.g., the bridge's portals are located in more disparate
locations, such as in separate rooms of a house, or even in
separate buildings).
[0063] In a second alternate embodiment, the fabric is adapted for
wireless operation. In one such embodiment, the fabric is adapted
for compliance with IEEE 802.11 (Wireless Local Area Networks).
[0064] Advantageously, the methods and apparatus of the exemplary
embodiment of the present invention are agnostic (work with) any of
the variants of the FireWire 1394 standard.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
[0065] Exemplary embodiments of the present invention are now
described in detail. While these embodiments are primarily
discussed in the context of an isochronous network of devices
having differing protocols, and more specifically to a
heterogeneous network of IEEE 1394-compliant and Ethernet AVB
devices, it will be recognized by those of ordinary skill that the
present invention is not so limited, and in fact may be used in
other types of applications, and with different protocols.
[0066] The following brief discussion of standards and their
associated descendents is useful for understanding one or more
aspects of the present invention.
Ethernet AVB
[0067] So-called "Ethernet AVB Standards" include: (i) IEEE Std.
P1722--Streaming Transport; (ii) IEEE Std. P802.1AS; (iii) IEEE
Std. P802.1Qat; (iv) IEEE Std. P802.1Qav; (v) IEEE Std. P802.1AB;
(vi) IEEE Std P802.1BA; (vii) IEEE Std P802.1BA; and (viii) IEEE
Std. 1394TA 2006021, each of the foregoing which are incorporated
herein by reference in their entirety.
IEEE 1394-1995
[0068] As of 2007, IEEE 1394 was a composite of four documents: the
original IEEE Std. 1394-1995, the IEEE Std. 1394a-2000 amendment,
the IEEE Std. 1394b-2002 amendment, and the IEEE Std. 1394c-2006
amendment. On Jun. 12, 2008, all these amendments as well as errata
and some technical updates were incorporated into a superseding
standard IEEE Std. 1394-2008.
IEEE 1394-1995 ("FireWire 400")
[0069] FireWire 400 can transfer data between various
interconnected devices at data rates of 100, 200, or 400 Mbps
half-duplex data rates (the actual transfer rates are 98.304,
196.608, and 393.216 Mbps. These different transfer modes are
commonly referred to as S100, S200, and S400. Under this standard,
cable length is also limited, although several cables can be
daisy-chained using repeaters, hubs, etc. often present in FireWire
equipment (although there is a maximum "total" chained length
limitation also).
IEEE 1394a-2000
[0070] An amendment to the original standard (IEEE 1394a) was
released in 2000 which both clarified and enhanced the original
specification. Support for asynchronous streaming was added, as was
faster bus reconfiguration, packet concatenation, and a
power-conserving "suspend" mode of operation. 1394a also
standardized use of the 4-pin (non-power) connector.
IEEE 1394b-2002 ("FireWire 800")
[0071] FireWire 800 or S800 was introduced commercially by Apple
Inc. in 2003. This newer (1394b) specification allows a transfer
rate of 786.432 Mbps full-duplex via a new encoding scheme often
referred to as "beta" mode. It is backwards compatible to the
slower rates of FW400 described above. However, while the IEEE
1394a and IEEE 1394b standards are compatible, FireWire 800's
connector is different from FireWire 400's connector, making the
cables incompatible. A "bilingual" cable is available which allows
the connection of legacy devices to the new port.
[0072] The 1394b specification supports data rates up to 3200
Mbit/s (S1600 and 53200) over beta-mode or optical connections up
to 100 meters in length. Standard CAT-5e unshielded twisted pair
supports 100 meters at S100. The original 1394/1394a standards used
data/strobe (D/S) encoding (called legacy mode) on the signal
wires, while 1394b added a new data encoding scheme called
8B10B.
IEEE 1394c-2006 ("FireWire S800T")
[0073] IEEE 1394c-2006 was published on Jun. 8, 2007, and provides
several changes including: (i) a new port specification which
provides 800 Mbit/s over the same RJ45 connectors with CAT-5e cable
which is specified in IEEE 802.3 clause 40 (gigabit Ethernet over
copper twisted pair); (ii) automatic negotiation that allows the
same port to connect to either IEEE Std 1394 (FireWire) or IEEE
802.3 (Ethernet) devices.
IEEE Std. 1394.1
[0074] FireWire bridging (IEEE 1394.1) was designed to support
longer distances and more devices on a network. Currently, 63
devices is the maximum number of devices allowed on a single
FireWire bus. The 1394.1 bridging allows the connection of multiple
busses for expanding the number of devices. Also, by expanding the
number of busses, the maximum distance between devices can be
expanded as well. IEEE 1394.1 defines a "bridge" as consisting " .
. . of two bridge portals (each with its associated PHY and link),
queues (FIFOs) for asynchronous and isochronous subactions (which
collectively form an implementation-dependent fabric between the
two portals), cycle timers, route maps, and configuration ROM."
However, it is appreciated that the foregoing definition is
implementation specific, and the present invention is in no way so
limited. More broadly, as used throughout, the term "bridging",
"bridge", etc. refers to the physical and logical apparatus
necessary to connect a first network technology to a second network
technology. Such methods and apparatus may be physical (e.g.,
hardware/firmware implementations), logical (e.g., software
implementations), or any combination thereof.
[0075] In addition to the foregoing standards and protocols, others
have been adopted (or are under development) which relate to A/V
transmission:
IEEE Std. 802.1Qat
[0076] IEEE Std. 802.1Qat ("Standard for Local and Metropolitan
Area Networks--Virtual Bridged Local Area Networks--Amendment: 9:
Stream Reservation Protocol (SRP)"), which is incorporated herein
by reference in its entirety, provides for reservation of bandwidth
on the network (including between end stations through a number of
bridges). A "listener" requests bandwidth to a "talker" and bridges
ask each other along the chain if there is sufficient bandwidth to
support adding the stream.
IEEE Std. 802.1Qav
[0077] IEEE P802.1 Qav ("IEEE Standard for Local and Metropolitan
Area Networks--Virtual Bridged Local Area Networks--Amendment:
Forwarding and Queuing Enhancements for Time-Sensitive Streams"),
which is incorporated herein by reference in its entirety,
specifies how to queue packets to not burst traffic across the
network. Bridges are used to automatically shape traffic.
IEEE Std. 802.1AB
[0078] IEEE Std. 802.1AB ("Station and Media Access Control
Connectivity Discovery--Apr. 5, 2005"), which is incorporated
herein by reference in its entirety, discloses Link Layer
capability discovery; i.e., discovery of what capabilities the ends
of the link have. This protocol may be used to tell end stations
what priority to send class-A and class-B traffic, and may be used
by some bridges to enable AVB functionality.
IEEE Std P802.1BA
[0079] IEEE Std P802.1BA ("Audio Video Bridging (AVB)
Systems--Draft PAR--Feb. 1, 2008), which is incorporated herein by
reference in its entirety, discloses profiles that select features,
options, configurations, defaults, protocols and procedures of
bridges, stations and LANs that are necessary to build networks
that are capable of transporting time sensitive audio and/or video
data streams.
IEEE Std. 1394TA 2006021
[0080] IEEE Std. 1394TA 2006021 ("Networking IEEE 1394 Clusters via
UWB over Coaxial Cable--Part 3: FCP and CMP over IPv4"), which is
incorporated herein by reference in its entirety, describes
discovering and controlling device configurations, and connection
management. It is based on the 1394 TA Specifications, and uses (i)
UDP/IP for communications, and (ii) Bonjour.TM. protocol for
discovery and removal notifications.
IEEE Std. 802.1AS and "AppleAS"
[0081] IEEE Standard 802.1AS ("IEEE Standard for Local and
Metropolitan Area Networks--Timing and Synchronization for
Time-Sensitive Applications in Bridged Local Area Networks"), which
is incorporated herein by reference in its entirety, provides
mechanisms for synchronizing frequency of clocks, and for measuring
the propagation delay across a link. It also provides a
NIC-to-bridge interface in bridged network, and NIC-to-NIC in a
two-machine network. It is based on IEEE 1588, and requires
ingress/egress time stamping in the MAC (i.e., Sync,
PDelay_Request, and PDelay_Response frames time-stamped on egress
and ingress).
[0082] The AppleAS protocol is an implementation of the IEEE
802.1AS protocol developed in interest of the Assignee. The
functionality of AppleAS is described in greater detail herein.
Briefly, AppleAS comprises an abstraction layer that isolates the
vendor code from differences in Ethernet AVB hardware, and can
still function without dedicated hardware (though at a reduced
precision of time synchronization). It resolves or reconciles the
IEEE 801.1 AS clock with the resident system's CPU clock, such that
the software can relate system time to network time, and vice
versa. In one implementation, the protocol is implemented in NIC
hardware, and is IEEE 802.1AS-compliant. In another implementation,
only the hardware time stamping is applied in the hardware, and
IEEE-802.1 AS protocol is implemented in software.
Extension of FireWire "Bridging"--
[0083] The FireWire.TM. protocol allows for high-speed data
transfer between two or more devices. The protocol can maximally
support sixty-three (63) devices on a single FireWire bus. FireWire
bridging according to IEEE 1394.1 allows the connection of multiple
busses for expanding the number of devices. The bridging component
is described within the IEEE 1394.1 specification as being
comprised of: (i) a serial bus bridge; (ii) two bridge portals
(each with its associated PHY and link), (iii) queues (FIFOs) for
asynchronous and isochronous subactions (which collectively form an
implementation-dependent fabric between the two portals), (iv)
cycle timers, (v) route maps, and (vi) configuration ROM.
[0084] In one embodiment, the present invention provides such an
"implementation-dependent fabric" using an Ethernet AVB cloud. As
used herein, an AVB "cloud" refers to a collection of AVB devices
that support all the AVB protocols. Any legacy Ethernet device
added to an AVB switch would terminate the cloud at that port.
Accordingly, AVB devices may exist which are not a part of the
"cloud" structure (e.g. legacy AVB devices, etc.).
[0085] The exemplary fabric is adapted for compliance with IEEE
1394.1 bridging requirements, and comprises apparatus adapted to
interconnect the 1394.1 bridge portals that is capable of
transferring any serial bus subaction from one portal to its
co-portal. The fabric also supports bidirectional, non-blocking
transfer of asynchronous request subactions, asynchronous response
subactions, and isochronous subactions.
[0086] Previous software implementations of FireWire-based audio
have typically had similar topologies to Universal Serial Bus (USB)
"Host-to-device" models, due to the relatively inconvenient nature
of physically wiring complex networks, despite FireWire device
capabilities. By augmenting the FireWire capabilities with Ethernet
AVB, and the corresponding ubiquitous Ethernet infrastructure, such
limitations are advantageously removed. Thus, while prior art
implementations may implement a single centralized supervisory
computer; the peer-to-peer nature of the FireWire/Ethernet AVB bus
is not so limited. Hence, in another aspect of the present
invention, the functionality between connection management and
datastream management is logically separated.
[0087] Such additional flexibility enables multiple additional use
case scenarios. In one embodiment, a FireWire network with multiple
connection managers (e.g., computers) and one or more devices
(e.g., speakers, microphones, iPods, etc.) may have any number of
conveniently selectable interconnections and topologies.
[0088] In another embodiment, a connection manager (e.g. computer)
may be separate from a data source/sink (e.g., Home Theater
Receiver, etc.).
[0089] In yet another embodiment, the merging and splitting of data
sources can be separated from connection management. Similarly, the
connection management can be performed in isolation from the data
being routed between the devices (e.g., data is not routed within
the connection manager).
Methods--
[0090] Referring now to FIG. 1, a first embodiment of the
generalized process 100 for integrating an isochronous network of
devices having differing networking protocols according to the
present invention is described.
[0091] At step 102, a first isochronous network having at least one
first device capable of operating with at least a first and a
second protocol interfaces is initialized, and connects to an
interconnection fabric which utilizes its second protocol
interface. The initialization procedures may comprise for example
registration with a local or remote software entity, such as a
network daemon described hereinafter.
[0092] In one embodiment, the first protocol interface is an IEEE
1394.1-compliant interface, and the second protocol interface is an
Ethernet AVB interface. The interconnection fabric comprises an
Ethernet AVB-compliant network cloud.
[0093] At step 104, an external device operating with at least a
second protocol interface is initialized, and connects to the
interconnection fabric utilizing its second protocol interface. In
one embodiment, the external or second device additionally
comprises a first protocol interface (not physically connected to
the first device); the second device is physically connected to a
target isochronous device via its first protocol interface (wherein
the term "target" is applied for clarity rather than to indicate
direction of data transfer). The target device can also be part of
the second device.
[0094] At step 106, the first device determines the existence of
the second device. In one embodiment, such identification is
accomplished via a software entity, such as a software daemon. The
identification is performed local to either the first and or the
second device. In an alternate embodiment, such identification is
performed at a third party connection management entity.
[0095] At step 108, the first device negotiates one or more
isochronous parameters to connect with the second device. In one
embodiment, such isochronous parameters may comprise for example:
(i) audio sample formats, (ii) sample rates, and (iii) channel
numbers, etc.
[0096] A source isochronous device in logical connection with the
first device via the first device's first protocol interface
receives (or transmits) an isochronous data stream to the target
isochronous device (wherein the term "source" is applied for
clarity rather than as an indication of data transfer).
[0097] At step 110, the first and second devices provide a logical
bridge between the first and second differing isochronous
protocols. In one embodiment, the management of the first and
second devices and corresponding source and target nodes is
performed within a graphical user interface (GUI) or other such
mechanism well known to those of ordinary skill in the computer
arts.
[0098] At step 112, isochronous data is transferred via the logical
bridge. In one variant, the isochronous data stream transferred
comprises at least one stream of audio and/or video. Multiple
source and target devices may exist, each receiving and or
transmitting at least one stream of audio, and or video.
Apparatus--
[0099] Referring now to FIG. 2, an exemplary apparatus 200 useful
in implementing the methods of the present invention is
illustrated. While a specific device configuration and layout is
shown and discussed, it is recognized that other implementations
can be readily implemented by one of ordinary skill given the
present disclosure. For example, various components may be divided
and/or placed within other devices, integrated into one physical
form factor, etc.
[0100] The illustrated embodiment of the apparatus 200 comprises a
device such as a portable (laptop or handheld) computer, or
audio/video capture, or synthesis system capable of receiving or
transmitting an isochronous datastream across two or more differing
protocols. In one exemplary implementation, the multi-lingual
functionality is performed within a dedicated processing device
coupled to physical connectors for each protocol (e.g., a IEEE 1394
connector and an 802.3 Ethernet connector accessible on the back of
the device), distributed throughout the equipment enclosure, as
described in greater detail subsequently herein.
[0101] As shown in FIG. 2, the apparatus 200 comprises a processing
subsystem 202, operational memories 204, a first physical connector
206 corresponding to a first protocol, and a second physical
connector 208 corresponding to a second protocol, and a power
subsystem 210. In one exemplary embodiment, the first physical
connection corresponds to a FireWire (IEEE 1394) multi-pin
interface (whether 4-pin, 6-pin, or otherwise), and the second
physical connection corresponds to an Ethernet AVB interface (e.g.,
RJ-45 connector). It will be appreciated that any number of
different or similar physical connections (for example, multiple
homogeneous and heterogeneous ports) may be used consistent with
the invention as well.
[0102] The processing subsystem 202 comprises a central processing
unit (CPU) or digital processor, such as a microprocessor, digital
signal processor, field-programmable gate array, or plurality of
processing components mounted on one or more substrates. The
processing subsystem is tightly coupled to operational memory 204
which may include for example SRAM, FLASH and SDRAM components. The
processing subsystem may also comprise additional co-processors,
such as a dedicated graphics accelerator, network processor (NP),
or audio processor. A direct memory access (DMA) subsystem (not
shown) of the type well known in the art may also be utilized with
the processor and memory in order to facilitate memory accesses. In
one embodiment, a time scheduled Ethernet DMA hardware is used for
scheduling Ethernet packets at the proper rate (e.g. 8000 packets
per second). Normally, Ethernet DMA hardware is used when streaming
data or a group of descriptors. Ethernet DMA transmits as soon as
the data arrives in the hardware queues. For Ethernet AVB, Ethernet
data is queued in a priority queue with "time to send" values, such
that the Ethernet DMA hardware is able to schedule packets out at
the proper rate and proper time.
[0103] The illustrated power management subsystem (PMS) 210
comprises a controller for power delivery and battery management
(if so equipped), and/or a plurality of discrete electrical
components (not shown). Additionally, a chemical battery cell such
as a Lithium Ion (Li-ion), or Nickel Cadmium (Ni--Cd) battery
provides power to the device apparatus when disconnected from a
parent power source such as a 115 VAC wall outlet/transformer.
[0104] The illustrated mass storage subsystem 212 comprises an
integrated circuit memory for storing a computer readable program,
and/or a plurality of discrete electrical components (e.g. motor,
controller, and hard disks, etc.). Typical embodiments of such
storage subsystems are hard disk drives common to the art. Other
alternate embodiments may use non-volatile solid-state memory, such
as NAND/NOR FLASH, ROM, etc.
[0105] In certain embodiments, the device may further comprise one
or more of target or source components. Such components consume or
produce isochronous data streams. Typical embodiments may include:
speakers 252, microphones 254, cameras 256, DVD and CD disk players
258, or monitors 260. Such target/source components may be
integrated within the device 200, or stand-alone in nature (e.g.,
connected to the apparatus 200 via interposed cabling, wireless
links, etc.).
[0106] In another embodiment of the invention, the apparatus
comprises a network switch or router adapted to perform data
transport between two devices (e.g., one operating according to a
FireWire protocol, and one operating according to an Ethernet
protocol). For example, in one variant, the apparatus comprises a
"super hub" that includes both FireWire and Ethernet AVB ports on
the hub, and which performs the translation to and from each
protocol.
[0107] In still another embodiment, the apparatus comprises a
removable/portable "dongle" (e.g., adapter or converter). In one
variant, the dongle has a FireWire port on one end, and an Ethernet
AVB port on the other. The dongle is plugged into the FireWire port
or Ethernet port on one device (or is otherwise connected to the
port indirectly, such as via a male/female, male/male, or
female/female interconnection cable), and similarly connected at
its other end to the other device. The dongle contains sufficient
processing capability and software to perform the protocol
"translation" described elsewhere herein. It will also be
appreciated that the dangle may be configured for "one-to-many"
operation (e.g., one port of a first protocol, and multiple ports
for the other protocol).
Exemplary Implementation
[0108] The following software descriptions further illustrate one
exemplary embodiment useful in implementing a heterogeneous network
of audio devices for providing audio and/or video stream transfers,
according to the present invention. While this specific embodiment
has functionality divided into kernel and user space operations,
these distinctions should not be construed as limiting as these
components may be implemented both in kernel space, and/or in user
space.
[0109] Moreover, while the following description relates primarily
focused on audio data transfer, the invention is in no way limited
to audio data, and in fact may support video and other multimedia
data types. Video formats supported may include for example (and
without limitation) IEC 61883-x based protocols such as IEC
61883-1, 61883-3, 61883-4, 61883-6, and 61883-7). See Appendix I
hereto for a listing of some relevant "video" standards that may be
utilized in conjunction with the methods and apparatus of the
present invention to facilitate, format and control video delivery
over different bearer protocols.
[0110] Various components are used in the illustrated embodiment to
provide the required functionality. Aspects of the functionality of
these components are described below. The aforementioned components
are also provided via a computer program listing appendix entitled
"AppleAS SOURCE CODE" disclosed in Appendix II, herein incorporated
in its entirety.
Ethernet 802.1 AS Driver
[0111] AppleAS kext (Kernel Extension) is one embodiment of the
802.1 AS Ethernet driver. It implements the IEEE 802.1 AS protocol
and provides an API for mapping 802.1 AS grandmaster time to Host
CPU time in nanoseconds.
[0112] Referring now to FIG. 3, a software system 300 is shown,
useful in describing one exemplary software or protocol stack
resident within a plurality of exemplary devices. As shown, each
entity of the software stack 302 within each device communicates
with the corresponding entities of other devices. A connection
manager 304 (AppleAudioNetworkingDaemon) is also shown. The
entities comprise: AppleAudioNetworking 310,
ApplelsochChannelMapper Kext (Kernel Extension) 320, and
AppleFireWireAVBBridge Kext 330. Two supplemental software
components are also utilized: AVCDescriptors Framework (not shown),
IOFireWireMultiIsoehListener 340.
[0113] The daemon (AppleAudioNetworkingDaemon) 304 is responsible
for performing device capability discovery, connection management
and handling device communications. The daemon sits above the
various kernel extensions needed for performing channel mapping,
bridging and audio streaming, and the frameworks which provide
device discovery, connection management calls and descriptor
parsing.
[0114] The AppleAudioNetworking entity 310 provides
application-level management via a graphical user interface for
configuring devices and the network of devices. The application
entity receives connection management information from the daemon
304. The application entity 310 is responsible for configuring
kernel extensions, talking with devices and performing local device
discovery. AppleAudioNetworking handles discovery and configuration
aspects of the AppleFWAudio 312 driver within user space, rather
than within the kernel. Drivers may be stored in operating system
(OS) kernels to offload device management from higher-level
software. AppleAudioNetworking handles audio device management
functionality explicitly, as audio devices may not necessarily be
local to the AppleAudioNetworking software.
[0115] AppleAudioNetworking further provides, in the illustrated
embodiment, support for AVB (Audio Video Bridging) devices using
AVC (Advanced Video Coding)-over-IP (Internet Protocol), as
previously referenced herein.
[0116] AppleAudioNetworking is supplemented with three (3)
components: (i) AppleFWAudio kext 312, (ii) FWAUserLib framework
314, and (iii) AVCVideoServices library 316. AppleFWAudio kext
enables audio streaming. Devices are created and configured through
the FWAUserLib framework with the connection management being
handled with the daemon (described hereinafter). The
AVCVideoServices library performs discovery of FireWire and
AVC-over-IP devices, reading of device configurations, performing
device communication and connection management of AVC-over-IP
devices.
[0117] The IOFireWireMultilsochListener 340 is a software function
which allows multiple clients on one node to "listen in" to the
same isochronous channel. The IOFireWireMultilsochListener does not
restrict the number of input isochronous contexts available. While
the IOFireWireMultilsochListener may perform basic formatting
operations (e.g., modifying headers, address translation, etc.) to
service various clients, it does not alter the datastream itself.
The IOFireWireMultilsochListener splits each isochronous channel to
the AppleFWAudio, AppleFireWireAVBBridge (AFAB) Kext. AppleFWAudio,
and AFAB are critical to connection management.
[0118] The AppleFireWireAVBBridge (AFAB) 330 kext performs the
bridging of the local FireWire bus to an AVB network/cloud. The
AFAB uses the IEC 61883/IIDC packet format of the AVBTP draft
specification previously referenced herein to encapsulate the
FireWire isochronous packet. The AFAB is a two-way bridge, capable
of both transmitting and receiving AVB packets. The AFAB may
support any number of input and output streams, each of which may
have differing channel counts. A user client enables local and or
remote configuration of the AFAR.
[0119] The AVCDescriptors framework (not shown) is a
Foundation-based Objective-C framework that performs parsing of AVC
device descriptors into an object-based hierarchy that can be
easily used for getting and setting properties of the descriptors.
AVCDescriptors will accept either the binary descriptor from the
device or the appropriate dictionary from AVCVideoServices. The
AVCDescriptors may produce a binary or dictionary version of the
descriptors suitable for AVCVideoServices or programming into a
device. The AVCDescriptors presents information necessary for
management within a localized database, such that each FireWire
node can track other FireWire, and Ethernet AVB members. In one
embodiment, the AVCDescriptors is a software program for
translating IEEE 1394 based AVC device descriptors into the
industry standard XML format for storage or modification.
AVCDescriptors additionally supports conversion from the XML format
to IEEE 1394 binary descriptor format. The XML outputs of the
AVCDescriptors are used by the controller to discover the
capabilities and parameters of the device, including such qualities
as device name, names of plugs/streams, internal routing, etc. The
binary outputs of AVCDescriptors are used natively within connected
IEEE 1394 compliant busses.
[0120] FIG. 3A illustrates one exemplary packet structure useful
with the present invention. The illustrated packet structure
comprises three components: a first header 352, a second header
comprising one or more isochronous parameters 354, and a payload
356. The packet, when being bridged from one protocol to another,
utilizes the first header 352 so as to comply with the "bridged to"
protocol. Information is parsed from the parameters field 354, to
determine any differences (e.g. sample rates) and or requirements
to modify the payload. The payload 356 is packaged for use at the
destination.
[0121] While the packets share the same structure regardless of the
source or destination of the packet, it is appreciated that in
certain embodiments one or more elements of the packet structure
may require modification to accommodate differing endpoints. For
example, packets from a first IEEE 1394 compliant bus transmitted
into an AVB cloud will have large portions of the payload 356
filled with data when connecting to a second IEEE 1394 compliant
bus via the AVB cloud. Alternately, the same payload may be
considerably smaller, when being transmitted to an AVB device
within the AVB cloud. Furthermore, packets from an AVB device in an
AVB cloud to an IEEE 1394 compliant may have smaller payloads, and
may require padding with null data by an intelligent component,
such as the AVB/FireWire bridge component.
[0122] In the illustrated embodiment, the first header 352
comprises an Ethernet (IEEE Std. 802) header of the type well known
in the art, while the second header comprises an IEEE P1722 header.
The payload illustrated is a FireWire packet payload of the type
well known in the art. It will be appreciated, however, that other
packet headers and structures (as well as different protocols) may
be used consistent with the invention.
[0123] FIG. 3B is a high layer representation 360 of the software
system components; as shown, the system is separated between
user-land (applications and APIs) 362 and the kernel (drivers) 364.
AppleFireWireAVB Proxy 366 is the controlling software component
that sets up the Ethernet to FireWire mapping and instantiates the
components needed for the bridging of protocols.
[0124] FIG. 3C is a graphical representation of one embodiment of
an exemplary protocol stack (kernel space) 370 implementing the
heterogeneous protocol data transfer functionality of the present
invention. The exemplary protocol stack includes the additional
components: AppleAS 371, AppleMAAP 372, Apple1722Ethernet 373,
Apple 1722Dispatcher 374 and AppleFireWireAVBBridge.
IONetworkFamily 375 and Ethernet Drivers 376 are pre-existing
Ethernet protocol stack components; similarly the FireWire Stack
374 uses existing FireWire stack in the current system.
[0125] In the exemplary embodiment, the current FireWire stack,
Ethernet stack, user-land API and associated software components
are combined in accordance with one or more aspects of the present
invention. Specifically, the present invention enables user-land
software operation, regardless of physical link characteristics.
The isochronous stream data may be received from either the
Ethernet or IEEE 1394 link. Moreover, the existing applications and
APIs running on the system cannot directly access the physical
links; thus higher level software remains unaware of link specific
operation. The separation of user space from kernel space
seamlessly provides isochronous data to the upper layer software
without requiring configuration for either Ethernet AVB of FireWire
protocols. Consequently, existing FireWire applications, like
"iMovie", can run without requiring modification.
[0126] FIG. 3D is another graphical representation 380 of various
components of the example protocol stack of FIG. 3C, and their
interrelationships. As shown in FIG. 3D, components added in the
kernel space include: (i) AppleAVBInterface; (ii) AppleAS (802.1AS
time synchronization) 371; (iii) AppleVirtualAS (802.1AS time
synchronization for unsupported hardware) 381; (iv) AppleMAAP
(dynamic allocation of multicast MAC addresses) 372; (v)
Apple1722Dispatcher (routes AVB frames between multiple clients)
374; (vi) Apple1722Client (abstract client class) 382; (vii)
Apple1722Ethernet (client subclass for Ethernet interface); and
(viii) AppleFireWireAVBBridge.
[0127] FIG. 3E is a graphical representation 390 of one embodiment
of an exemplary protocol stack (user space) implementing the
heterogeneous protocol data transfer functionality of the present
invention. The exemplary user space additions are two (2) peer
entities: AppleAudioNetworking 391 and AppleAVBFireWireProxy 392.
The AppleAudioNetworking software module is resident to the
Ethernet AVB device, whereas the AppleAVBFireWireProxy software
module communicates with the Firewire device. It should be noted
that both modules may or may not be co-located within the same
device, depending on implementation, etc.
[0128] FIG. 3F is a block diagram of one embodiment of a software
architecture 395 employing a proxy for interfacing between a first
device and various software processes on the same or different
device. As shown in FIG. 3F, the kernel space and user space
components of FIGS. 3C and 3E, respectively are used to bridge
between a FireWire network, and an Ethernet AVB network, via the
proxy software entity.
[0129] Referring now to FIG. 4, one exemplary heterogeneous
community 400 of the aforementioned devices useful in illustrating
the methods and apparatus of the invention is described. As shown
in FIG. 4, device 200A is physically interconnected to another
device 200B via a common bus 406 (e.g. IEEE 1394), and logically
interconnected via the aforementioned software functions. Each
group of devices negotiates their internal addressing within a
localized network. Bridging portals are devices which "bridge" from
the localized network to an external device 200C (e.g., another
device of similar or differing nature). Bridging portals provide
connection 404 to a fabric 402, wherein the fabric must be capable
of transferring any serial bus subaction from the bridging portal
to its destination device (e.g. co-bridging portal, external
device, etc.). The localized network may utilize a protocol (e.g.,
IEEE 1394.1), which is different than the interconnecting fabric
(e.g. Ethernet AVB).
[0130] As previously described herein, the "fabric" of the present
embodiment may be conceptualized as a set of FIFOs that support
bidirectional, non-blocking transfer of asynchronous request
subactions, asynchronous response subactions, and isochronous
subactions. The fabric could be modest in geographical extent, as
when the bridge portal and external device are located within a
single enclosure. Conversely, the fabric could be physically
extensive, as could be the case if a bridge's portal was located in
separate room from the external device.
[0131] In one exemplary embodiment, the devices 200 are FireWire
devices compliant with IEEE 1394, and the fabric 402 is an Ethernet
AVB-compliant "cloud". As shown, an IEEE 1394.1 compatible portal
200A is on at least one side of the Ethernet AVB network, and
employs AVC command interpreters in the portals to allow existing
FireWire software to "see". FireWire and Ethernet AVB devices (i.e.
200C, 200D) that are not physically connected to the local FireWire
bus via the Ethernet AVB connection 404.
[0132] In yet another exemplary embodiment, a pair of bridging
portals (200A and 200C) may bridge two separate busses (406) having
a first protocol, via a fabric (402) having a second different
protocol with suitable isochronous properties. Such bridging
portals are responsible for converting the information on one bus
for transfer to the co-bridging portal on the other bus. The
connection fabric between portals could be an internal bus, system
bus, or any other interconnection readily understood by those
skilled in the electronic arts. If the connection fabric between
portals is private, the portals may send packets via the connection
fabric without any additional processing (e.g. encryption). Certain
interconnection fabrics are desirable for varying purposes; for
instance, an Ethernet AVB network between bridging portals can
enable significant geographic distance between a first and second
network. If the fabric is an Ethernet AVB network, then the portals
could be put anywhere on the Ethernet AVB cloud and still function
correctly.
Example Use Scenarios
[0133] In a first example, the Assignee manufactures and releases a
new computer that has no FireWire ports but does include the new
Ethernet AVB hardware. With a small dongle that implements the
FireWire to AVB protocol conversion described in this patent, the
user can connect the FireWire audio device to the dongle and then
connect the dongle to the new computer via the Ethernet jack. The
FireWireAVB proxy software on the computer will then connect to the
FireWire audio device as if it is now an AVB audio device. The
AppleEthernetAudio driver will enumerate and discover the device,
presenting it to the Audio sub-system. Audio applications adapted
to operate with FireWire type devices will operate seamlessly with
the new computer. The bridging "dongle" will transparently enable
the software to see the FireWire Audio device as if it was directly
connected to a FireWire port.
[0134] In another aspect of this invention, a first computer can
physically incorporate the "dongle" that is mentioned above to
enable play through operation by a second computer on a computer
network. The first computer with both FireWire and AVB compliant
Ethernet hardware can act as a bridge between FireWire and Ethernet
AVB. The software on the first computer would provide an "AVC
FireWire device sharing mode" to the system software so that any
computer (e.g. second computer) on the network could see the
FireWire device attached to the first computer. A second computer
on the network may then connect to the first computer over the
Ethernet AVB network and use the services provided by the FireWire
device. In this mode, an unmodified AVC FireWire application like
iMovie running on the second computer, could operatively utilize
the FireWire device resident to the first computer; iMovie could
operate as if it was directly connected to the FireWire device.
[0135] The following example user scenarios (FIG. 5A-D) illustrate
some possible application environments enabled by the methods and
apparatus of the present invention. These scenarios are only
exemplary, and the invention is in no way limited thereto.
[0136] With respect to FIG. 5A, a regular user (Jack) is a
Macintosh.TM. ("Mac") computer user and has been for many years. He
owns a FireWire audio device (FAD) 502. He has been using the Mac
OS X Leopard.TM. operating system for a long time, and has just
upgraded to the latest Mac OS X, FatCat.TM.. Jack plugs in his FAD,
starts Logic Pro, which is his digital audio workstation software
(DAW) and sets it to use his FAD. He then proceeds to do what he
has previously done with his DAW.
[0137] Mac OS X FatCat includes a new FireWire audio architecture
supporting networking, and has added support for the new AVB
specification; however Jack is not interested in any of these
features and has never launched the AppleAudioNetworking
application. None-the-less, he expects his FAD to behave exactly
the same as it always has in previous versions of Mac OS X.
[0138] Referring now to FIG. 5B, a studio user (Bob) is a sound
engineer at a recording studio. He uses Mac OS X as his platform of
choice, and has many FADs around his studio. Bob has recently
switched to the new Mac OS X FatCat because he has heard about the
new FireWire audio networking feature.
[0139] Bob launches the AppleAudioNetworking application, and
connects his all his FADs (which comprise two 2-channel FADs and 3
18-channel FADs) to his MacPro. He also connects several other
Macintoshes to the FireWire bus to act as channel mappers. He
configures his local Macintosh to have a 30 channel input, and
output CoreAudio device consisting of three 10-channel input
streams and one 42-channel output stream. He connects the 3 input
streams to 3 of his 18 channel FADs. He creates a channel mapper on
one of the remote machines that takes a 42-channel input stream,
and outputs three 10-channel streams. He connects the input stream
of the mapper to the output stream of his MacPro, and the 3 output
streams to his 18-channel FADs. Bob also creates a channel mapper
on another of his remote machines that takes a 42-channel input
stream and outputs 6 2-channel streams. He connects the input
stream of the mapper to the output stream of his MacPro, and the
output streams to each of the 2-channel FADs. He adjusts the
mapping so that the 2-channel FADs streams are connected to the
last 12 channels rather than the first 12 channels. Bob then saves
the configuration so that he can use it again.
[0140] Bob opens up the Logic (DAW) and configures it to use his
new 30-channel input and 42-channel output device. He sets up
appropriate mixes on the last 12 channels for the 2-channel FADs to
be used as stage monitors, and sets up appropriate mixes on the
first 30 channels. Bob then starts his recording session. When Bob
has finished his recording session, and copied his audio, he turns
off all of his equipment.
[0141] The next day Bob comes back to continue recording with the
same setup. He turns on all of his equipment, starts his DAW and
commences the day's activities.
[0142] Referring to FIG. 5C, a live performance user (John) works
at a concert hall. They have recently upgraded their system to use
new high-speed Ethernet-based AVB and FireWire devices and Mac OS X
FatCat as the control and configuration platform. The control room
is equipped with several MacPro devices running various software
applications needed to control their concert hall, and to run the
AppleAudioNetworking software to configure their sound system.
[0143] The concert hall is fitted with AVB-equipped speakers rigs
all being wired back to a central AVB cloud synchronized to a
class-A specification. The MacPro devices in the control room, as
well as several under the stage, are also connected to the live
sound AVB cloud as well as a secondary communications cloud. A
central AVB based mixing board 510 is provided in the control room,
which can have configurations saved and loaded by a computer over
the AVB cloud.
[0144] A new concert is being planned and setup in the hall. John's
task is to set up the sound system. He sits down at the main
configuration computer, opens AppleAudioNetworking, and loads a
copy of the clean default sound network configuration. He adjusts
the configuration for the particulars of the concert. One of the
special features of this concert is a FireWire-based sound effects
box which is triggered by the audio. This box is connected to one
of the MacPro devices under the stage. The technicians on stage
have already set this up, and so a new display icon has appeared in
AppleAudioNetworking to represent this device. John needs to
connect this to the mixing board.
[0145] While John was configuring the sound system routing, someone
else was setting the mixing board configuration to add an extra
stream for the sound effects box. They pass this file to John, who
uploads it to the mixing board via a vendor plug-in in
AppleAudioNetworking. John now has an extra output stream on the
mixing board to connect to the special effects box. John connects
the new output on the mixing board to the input of the special
effects box, and AppleAudioNetworking establishes a connection
between the two via a bridge on the MacPro to which the special
effects box is connected. John then saves this configuration for
the concert.
[0146] On the day of the concert, John loads up the saved
configuration and then runs through the usual pre-concert
checks.
[0147] Referring to FIG. 5D, an experimenter (Eve) is an
experienced Mac OS X user. She has just upgraded to Mac OS X
FatCat. She has noticed a new feature of the operating system
(audio networking). She has been exploring her system, and has
discovered the AppleAudioNetworking application. She launches the
application and is presented with the current configuration of her
system. She has no FireWire or AVB devices, so all she sees is an
icon for her local Mac. She opens the README link to find out more
information about what she can do with the system/software.
[0148] She reads that she can set up multiple Macs on the same
network to talk to each other, and send audio directly between the
machines. Since she has two Macs running Mac OS X FatCat, she
decides to set up an audio network to play with. She enables
multi-Mac support on each of her machines, since it is a private
network which nobody else can connect to, she decides to not enable
password authentication.
[0149] On both Macs she creates a 2-channel AVB device. On one of
her machines she connects the input of each machine to the output
of the other machine. On one machine she opens up "System
Preferences" and sets the AVB device as the output device. She then
opens iTunes.TM. and starts playing her music. On the other
machine, she enables pass-through from the AVB device to the
built-in speakers, and her music begins playing from her
speakers.
Wireless Variants
[0150] In another aspect of the invention, the aforementioned
protocols used on the various communicating devices may comprise
wireless protocols such as for example WLAN, PAN, or WAN/MAN
protocols.
[0151] Wired operation may statically reserve resources to enable
operation. For instance, Ethernet AVB requires each node between
the source and targets to reserve resources for datastream
transmission, thus providing a bandwidth, and latency guarantee.
Transmission and reception of data is relatively reliable for wired
devices; however, wireless devices may fade in and out of service,
causing considerable complication. A wireless linkage in
combination with a wired link may fade out unexpectedly, leaving
unused reserved resources on the wired network. Methods and
apparatus for bridging wireless/wired devices must also provide for
"clean up" operations.
[0152] Under one embodiment, wireless operation of one or more
components of the aforementioned heterogeneous networks is
envisaged. In addition to providing a bridging access from a first
wired protocol to a second wireless protocol, concurrent
monitoring, diagnosis and re-routing of wireless/wired links are
desired to minimize unnecessary resource utilization during a "fade
out". In one variant, each of the bridging devices, the target or
the source may transmit a link condition signal relating current
status of the isochronous stream. A bridging element within a
heterogeneous network may monitor the reliability of one or more
wireless links, and transmit feedback to the source device, thus
enabling the source device (and any associated wire line "hops") to
throttle their reserved resources accordingly.
[0153] In another embodiment of the wireless/wired invention, a
bridging element within a heterogeneous network may register a
relative estimation of wireless robustness for use with the
connection management software. In one variant, the connection
management software may maintain an entry for each wireless device,
related to relative wireless data rate. Such an entry may be e.g.,
a relative measurement of bit error rate (BER), signal to noise
(SNR), or any of the other plethora of useful link-related
measurements commonly known to those skilled in the
telecommunications arts. In another variant, such an entry may
additionally include a total number of subscribers actively
connected to a datastream, to accommodate the requirements of
broadcast and or multicast operation. For example, one or more
subscribers may drop off without adversely affecting the experience
of other broadcast subscribers.
[0154] In yet another embodiment of the wireless/partially wireless
invention, a bridging element within a heterogeneous network having
a wireless source and destination may continuously poll each
wireless link for to modify its operation. In one variant, the
bridging element may regularly insert, re-process or sniff packets
being received and transmitted to dynamically size the reserved
resources to only what the weakest link may serve. Alternatively,
the bridging element may perform such monitoring to dynamically
size the reserved resources to only what the strongest receiving
link may serve (as applicable within a broadcast or multicast
situation).
[0155] In yet another embodiment of the wireless/partially wireless
invention, a bridging element within a heterogeneous network may
receive link updates from one or more target device attached to a
bus on the second protocol. For example, a bridging element
connecting two differing wire line protocols may receive
notification from one such protocol that a wireless linkage
downstream has failed (e.g., a device on a wireless hub, which is
connected to the bridging portal via wire line). Alternatively, a
bridging element connecting a wireless protocol to a wired protocol
may receive notification that a wireless link downstream of the
wired protocol has failed (e.g. an Ethernet AVB cloud connecting a
wireless device on a bridging node to a wireless LAN, etc.
[0156] A channel mapping element may also be utilized consistent
with the invention. Under one embodiment, the mapping element
adaptively resizes channels based at least in part on the wireless
channel reception. For example, one or more channels of channel
mapping functionality may be preprocessed based at least in part on
the expected wireless link quality.
[0157] Other implementations and variations of the foregoing
features will be appreciated by those of ordinary skill given the
present disclosure.
Business Methods and Models
[0158] In another aspect of the invention, various business models
and methods of doing business relating the aforementioned
heterogeneous networks are envisaged.
[0159] In one aspect, the ability to obviate one or more ports on a
device is inherently less expensive. For example, a device
manufacturer or service provider can support similar features to
their preexisting products or services with a smaller bill of
materials (BOM) for the correspondingly reduction in components
(e.g. port connections, driver hardware, etc.). Furthermore,
replacement of high cost port solutions (e.g. FireWire) with lower
cost port solutions (e.g. Ethernet AVB) would also advantageously
work to reduce manufacturing cost.
[0160] In another aspect, an adapter device capable of bridging
between a first network, to a pre-existing device having a second
network connection type could be manufactured and sold, so as to
maintain backward compatibility. Consistent support of backward
compatibility is generally considered in customer's determination
of price; and customers will ostensibly be willing to pay more for
consumer electronics devices which are supported through time,
rather than made obsolete. Furthermore, the manufacture and sale of
adapter devices (commonly referred to in the arts as a "dongle") is
also profitable, in some cases providing opportunities for third
party licensing fees.
[0161] In one embodiment, a device capable of both connection
operation and streaming operation may require a software patch sold
after purchase, to enable one, or both features. In a related
embodiment, connection management is a relatively sporadic software
function, whereas streaming data has specific requirements on the
data path. These differences may be leveraged in manufacturing such
specialized devices.
[0162] It will also be appreciated that the methods and apparatus
described herein, by allowing for isochronous data networking
spanning varying protocols and networks, and limited software
modifications to extant infrastructure and devices, also provide an
intrinsic cost benefit over prior art isochronous data networking
technologies. Specifically, by obviating the expense of
infrastructure through reuse of existing networking technology,
some of the cost and complexity associated with such isochronous
networking can be avoided, and customer systems made simpler and
"thinner" in terms of capability.
[0163] Moreover, greater levels of connectivity between devices can
be achieved, even when the pervasiveness of certain types of
physical ports (e.g., 1394) has decreased with time.
[0164] It will be recognized that while certain aspects of the
invention are described in terms of a specific sequence of steps of
a method, these descriptions are only illustrative of the broader
methods of the invention, and may be modified as required by the
particular application. Certain steps may be rendered unnecessary
or optional under certain circumstances. Additionally, certain
steps or functionality may be added to the disclosed embodiments,
or the order of performance of two or more steps permuted. All such
variations are considered to be encompassed within the invention
disclosed and claimed herein.
[0165] While the above detailed description has shown, described,
and pointed out novel features of the invention as applied to
various embodiments, it will be understood that various omissions,
substitutions, and changes in the form and details of the device or
process illustrated may be made by those skilled in the art without
departing from the invention. The foregoing description is of the
best mode presently contemplated of carrying out the invention.
This description is in no way meant to be limiting, but rather
should be taken as illustrative of the general principles of the
invention. The scope of the invention should be determined with
reference to the claims.
Appendix I
Other Standards and Technologies
IEC 61883-1
[0166] IEC 61883-1 ("Consumer audio/video equipment--Digital
interface--Part 1: General"--February 1998), incorporated by
reference herein in its entirety, is a standard that describes,
inter alia: (i) isochronous Plug Control Registers; (ii) Connection
Management Protocol (CMP); (iii) Function Control Protocol (FCP);
and (iv) Common Isochronous Packet (CIP) headers. It is useful for
the transport of isochronous data when using AV/C, DVC, MPEG, or
AMP.
AV/C General Specification
[0167] AV/C General Specification (Accepted by 1394 TA (version
4.2), and including 1998010--"Enhancements to the AV/C General
Specification 3.0", 1998001--"AV/C Digital Interface Command Set
General Specification", and 1996002--"AV/C Digital Interface
Command Set") each incorporated by reference herein in its
entirety, defines inter alia general commands used to control
consumer audio/video electronics. It utilizes 1394 Unit
architectures, and is useful for implementation of audio/video
devices, and for software driver development.
MPEG4 Over 1394
[0168] MPEG4 over 1394 is not yet standardized; a study group is
investigating the need/demand for a specification to transport
MPEG4 (including H.264) over 1394, and identifying which parts of
MPEG4 are applicable. The group is also discussing strategies for a
specification (i.e., encapsulating in MPEG2-TS over 61883-4, or
transport MPEG-4 in `native` form over 1394). This standard (when
finalized) would be applicable for all devices sending MPEG4
streams over 1394.
IEC 61883-6
[0169] IEC 61883-6 ("Consumer audio/video equipment--Digital
interface--Part 6: Audio and music data transmission
protocol"--February 1998), incorporated by reference herein in its
entirety, is a standard that describes Audio/Music Transport
Protocol across 1394. It is useful for devices transporting
formatted Audio or Music streams over 1394.
IEC 61883-2
[0170] IEC 61833-2 ("Consumer audio/video equipment--Digital
interface--Part 2: SD-DVCR data transmission"--February 1998),
incorporated by reference herein in its entirety, is a standard
that describes SD-DVCR Transport Protocol across 1394. It is useful
for devices transporting SD-DVCR over 1394.
IEC 61833-3
[0171] IEC 61883-3 ("Consumer audio/video equipment--Digital
interface--Part 3: HD-DVCR data transmission"--February 1998),
incorporated by reference herein in its entirety, is a standard
that describes an HD-DVCR Transport Protocol across 1394.
IEC 61883-5
[0172] IEC 61883-5 ("Consumer audio/video equipment--Digital
interface--Part 5: SDL-DVCR data transmission (TA4)"--February
1998), incorporated by reference herein in its entirety, is a
standard that describes SDL-DVCR Transport Protocol across
1394.
IEC 61883-4
[0173] IEC 61883-4 ("Consumer audio/video equipment--Digital
interface--Part 4: MPEG2-TS data transmission"--February 1998),
incorporated by reference herein in its entirety, is a standard
that describes MPEG Transport Streams (TS) (including DVB TS)
across 1394.
IEC 61883-7
[0174] IEC 61883-7 ("Consumer audio/video equipment--Digital
interface--Part 7: Transmission of ITU-R BO.1294 System
B"--February 1998), incorporated by reference herein in its
entirety, is a standard that describes MPEG Transport Streams (TS)
for DSS (not quite the same as standard MPEG-2) across 1394.
TA 1998005
[0175] TA 1998005 ("AV/C Tuner Broadcast System
Specification--Digital Video Broadcast (DVB)--1998), incorporated
by reference herein in its entirety, is a standard that describes
AV/C control enhancements for Digital Video Broadcast (DVB) video
tuners. It is useful for devices doing DVB video tuning controlled
across 1394.
* * * * *