(19) United States AppEeAudioNefworking AppleAVBFireWireProxy

(19) United States AppEeAudioNefworking AppleAVBFireWireProxy
US 20130250971A1
(19) United States
(12) Patent Application Publication (10) Pub. No.: US 2013/0250971 A1
Mora et al.
(43) Pub. Date:
Sep. 26, 2013
Provisional application No. 61/195,141, ?led on Oct.
2, 2008.
Publication Classi?cation
(71) Applicant: APPLE INC., Cupertino, CA (U S)
Inventors: Matthew Xavier Mora, Fremont, CA
(US); Ashley Ian ButterWorth,
Normanhurst (AU); Andrew Yanowitz,
Ben Lomond, CA (U S); Niel David
Int. Cl.
H04L 29/06
(52) US. Cl.
CPC .................................... .. H04L 69/08 (2013.01)
USPC ........................................................ .. 370/467
Warren, Soquel, CA (U S)
(73) Asslgnee: Apple Inc" cupemno’ CA (Us)
Appl' NO" 13/784’689
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”
Man 4’ 2013
enabled) devices to communicate across an Ethernet infra
structure, such as one enabled by the Ethernet AVB Standard
Related U's' Apphcatlon Data
Methods and apparatus that enable a community of devices
Division of application No. 12/572,995, ?led on Oct.
2, 2009, noW Pat. No. 8,392,631.
(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.
Use: Space Additions
AVE Commands
AVC Descriptors
FireWire Stack
AVC Commands
AVC Descriptors
FireWire Stuck
Patent Application Publication
Sep. 26, 2013 Sheet 1 0f 12
INHiALiZE szzown mm
mans“ 8RIDGE
TRANSFER xsocuaowous DATA / m
\ 10o
US 2013/0250971 A1
Patent Application Publication
Sep. 26, 2013 Sheet 2 0f 12
_________ -.a
____________________________________________ -l
US 2013/0250971 A1
Patent Application Publication
Sep. 26, 2013 Sheet 3 0f 12
US 2013/0250971 A1
Patent Application Publication
Sep. 26, 2013 Sheet 7 0f 12
US 2013/0250971 A1
Patent Application Publication
Sep. 26, 2013 Sheet 8 0f 12
US 2013/0250971 A1
AVB FireWire Proxying
FireWire Device
FireWire AVB Bridge
Patent Application Publication
Sep. 26, 2013 Sheet 9 0f 12
FIG. 4
US 2013/0250971 A1
Patent Application Publication
Sep. 26, 2013 Sheet 10 0f 12
US 2013/0250971 A1
0 5m
---- -
466/ ______ "E': U;
Q1; ?’ \
g5; \ /
Patent Application Publication
Sep. 26, 2013 Sheet 11 0f 12
US 2013/0250971 A1
[1 am?
F ._"_
406 J
Patent Application Publication
Sep. 26, 2013 Sheet 12 0f 12
US 2013/0250971 A1
Sep. 26, 2013
US 2013/0250971A1
application is herein referred to as the “Ethemet AVB stan
dard”. Ethernet AVB is a neW standard being developed for
transmitting audio and video data across an 802.1 Ethernet
Ethernet AVB is expected to provide additional capabilities
enabling isochronous data transfer. Speci?cally, Ethernet
AVB provides guarantees on maximum latency and minimum
bandWidth that enable “streaming” applications, Which Were
previously limited due to requirements for loW latency isoch
link. Existing Ethernet standards guarantee packet delivery;
[0001] This application is a divisional of and claims priority
to co-oWned, co-pending US. patent application Ser. No.
12/572,995 entitled “METHODS AND APPARATUS FOR
NEOUS NETWORK”, ?led Oct. 2, 2009 (issuing as US. Pat.
No. 8,392,631 on Mar. 5, 2013), Which claims priority to US.
Provisional Patent Application Ser. No. 61/195,141 ?led Oct.
2, 2008 of the same title, each of Which are incorporated by
reference herein in its their entirety.
[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 reproduc
tion by anyone of the patent document or the patent disclo
sure, as it appears in the Patent and Trademark Of?ce patent
?les or records, but otherWise reserves all copyright rights
ronous transfer of audio and video.
Unsatis?ed Need for Interoperability
[0009] Due to the Widespread existing deployments of
existing IEEE 1394 devices, and the virtually universal Eth
ernet 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.
Another issue relates to the increasing “disappear
ance” of physical ports on hardWare devices such as comput
ers, video cameras, etc. over time. These physical ports (in
cluding FireWire ports) are becoming less proli?c on neW
generation devices because, inter alia, aggressive form factor
reductions no longer alloW distinct connectors for all sup
1. Field of Invention
The present invention relates generally to the ?eld 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 equip
ment of differing types purchased from different manufactur
ers. 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
ported 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 manufac
tured 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 num
ber of (FireWire and other) ports disappear, so do the connec
tivity opportunities for devices using that port speci?cation.
Hence, in order to maintain FireWire support and distribution
over such devices, other “Ways off of” and “Ways onto” the
device are needed.
Accordingly, improved methods and apparatus are
needed for providing data stream delivery betWeen tWo dif
fering protocols, such as for example Ethernet AVB, and
IEEE 1394. Such an improved solution should operate seam
lessly 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 modi?cation to implementations already
bus standard that Would alloW for the connection and com
munication betWeen such devices.
deployed. To these ends, such data delivery schemes should
minimally support “master-slave” operation, Where a
[0007] The IEEE 1394-1995 standard (and its associated
trade names “FireWireTM” (Apple Inc.), “i.LINK” (Sony),
and “Lynx” (Texas Instruments), etc.) Was developed to sat
lation for its localiZed netWork, Without requiring its non
dynamically bridging multi-lingual device performs all trans
enabled slave devices to do so.
isfy 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 ?rst 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
cooperatively to simultaneously source and sink isochronous
Multiple clients Would also advantageously Work
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 exist
ing Ethernet infrastructure.
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 char
acteristics (including e.g., higher speeds and longer connec
tion paths).
by providing, inter cilia, improved apparatus and methods for
bridging data (including audio and video or other multimedia
data) across netWorks or devices using different protocols.
In addition to IEEE 1394 based standards, a neW
standard being proposed at the time of the ?ling of the present
The present invention satis?es the foregoing needs
Sep. 26, 2013
US 2013/0250971A1
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 ?rst protocol, and said fabric operates With a second
protocol, said ?rst and second protocols being different. The
method comprises: associating said source device With a soft
Ware 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 ?rst 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 mes
sages via said fabric.
[0016] In one variant, said source device and fabric are
characterized by isochronous transfer parameters.
[0017] In another variant, the ?rst protocol comprises a
1394-compliant protocol, and the second comprises an Eth
ernet AVB compliant protocol.
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 con?gured 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 con?gured to, When executed by the processor:
responsive to a device having a ?rst protocol associated there
With being coupled to the heterogeneous fabric, the fabric
having a second protocol different from the ?rst 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.
adapted for isochronous data transfer is disclosed.
[0029] In an eleventh aspect, an apparatus for interopera
tion With a heterogeneous fabric is disclosed. In an exemplary
embodiment, the apparatus includes: an interface to the het
[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
tiple 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 com
bridge portals and that is capable of transferring any serial bus
puter program con?gured to, When executed by the processor,
In a second aspect of the invention, a source device
erogeneous fabric, the heterogeneous fabric comprising mul
subaction from one portal to its co-portal, and that supports
cause the apparatus to: responsive to a connection to the
bidirectional, non-blocking transfer of asynchronous request
subactions, asynchronous response subactions, and isochro
heterogeneous fabric, register With a network daemon, iden
nous 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 dis
[0021] In a ?fth 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.
tify 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 inven
tion 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
[0032] FIG. 1 is a logical ?oW diagram illustrating one
embodiment of the generalized method of transferring data
[0022] In a sixth aspect of the invention, a portal architec
ture is disclosed. In one embodiment, the portals comprise
1394.1-compliant portals disposed on each side of an Ether
net AVB network, and Which employ AVC command inter
across a heterogeneous protocol environment according to
the invention.
[0033] FIG. 2 is block diagram illustrating one embodi
preters. This approach alloWs existing FireWire softWare to
ment of an apparatus adapted to transfer data across a hetero
“see” FireWire devices that are not physically connected to
the local FireWire bus (or if there is no local FireWire bus at
geneous 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 embodi
ment of a data packet structure according to the invention.
[0036] FIG. 3B is a high layer representation of one exem
plary embodiment of a softWare system comprising a user and
In a seventh aspect of the invention, one or more
Wireless protocols are utilized as the bearer(s) for the trans
ported 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 connectiv
ity over a heterogeneous fabric is disclosed. In one exemplary
embodiment, the method includes: receiving an indication of
kernel space, according to the present invention.
[0037] FIG. 3C is a graphical representation of one embodi
ment of kernel space additions useful for implementing the
one or more capabilities associated With a ?rst device, the ?rst
heterogeneous protocol data transfer functionality of the
device having a ?rst protocol associated thereWith and the
present invention.
[0038] FIG. 3D is another graphical representation of vari
ous components of the protocol stack of FIG. 3C, and their
?rst device being coupled to the heterogeneous fabric,
responsive to the indication, storing at least one device capa
bility associated With the ?rst device, and responsive to a
Sep. 26, 2013
US 2013/0250971A1
[0039] FIG. 3E is a graphical representation of one embodi
ment of user space additions useful for implementing the
[0049] As used herein, the term “memory” includes any
type of integrated circuit or other storage device adapted for
heterogeneous protocol data transfer functionality of the
present invention.
FIG. 3F is a block diagram of one exemplary
storing digital data including, Without limitation, ROM.
EDO/FPMS, RLDRAM, SRAM, “?ash” memory (e.g.,
embodiment of a softWare architecture employing a proxy for
interfacing betWeen a ?rst device and various softWare pro
cesses on the same or different device, using the kernel space
[0050] As used herein, the terms “microprocessor” and
“digital processor” are meant generally to include all types of
and user space components of FIGS. 3C and 3E, respectively.
[0041] FIG. 4 is a block diagram illustrating one exemplary
tal signal processors (DSPs), reduced instruction set comput
heterogeneous community of devices according to the inven
FIGS. 5A-5D are block diagrams illustrating vari
digital processing devices including, Without limitation, digi
ers (RISC), general-purpose (CISC) processors, micropro
cessors, gate arrays (e.g., FPGAs), PLDs, reeon?gurable
compute fabrics (RCFs), array processors, secure micropro
ous different user scenarios consistent With the present inven
cessors, and application-speci?c 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 “netWor ” and “bearer
[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 iPhoneTM), personal computers (PCs), such as for
example an iMacTM, Mac PrOTM, Mac MiniTM or Mac
BookTM, and minicomputers, Whether desktop, laptop, or oth
erWise, as Well as mobile devices such as handheld comput
ers, PDAs, video cameras, set-top boxes, personal media
devices (PMDs), such as for example an iPodTM, or any com
binations of the foregoing.
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 lan
guage or environment including, for example, C/C++, For
tran, COBOL, PASCAL, assembly language, markup lan
guages (e. g., HTML, SGML, XML, VoXML), and the like, as
Well as object-oriented environments such as the Common
Object Request Broker Architecture (CORBA), JavaTM (in
cluding J2ME, Java Beans, etc.), Binary Runtime Environ
ment (BREW), and the like.
[0046] As used herein, the terms “Ethemet AVB” and “Eth
ernet 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.
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 irre
spective of process orbase materials (including, Without limi
tation 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 control
lers, and other devices, as Well as any combinations thereof.
netWork” refer generally to any type of data, telecommunica
tions or other netWork including, Without limitation, data
netWorks (including MANs, PANs, WANs, LANs, WLANs,
micronets, piconets, intemets, and intranets), hybrid ?ber
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 communica
tions 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., TVnetTM), 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 Wire
less signal, data, communication, or other interface including
Without limitation Wi-Fi (IEEE Std. 802.11), Bluetooth, 3G
(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.,
As used herein, the terms “WLAN” and “Wireless
LA ” refer generally to any system Wherein a Wireless or air
interface is employed betWeen tWo devices, and Which pro
vides at least local area netWorking capability. Wi-Fi systems
are one exemplary instance of WLANs.
[0055] In one aspect, the present invention discloses, inter
alia, methods and apparatus that enable a community of het
erogeneous 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 AVE Standard(s).
Sep. 26, 2013
US 2013/0250971A1
[0056] In one variant, the invention enables an IEEE 1394
device to stream data to an Ethernet AVB-compliant device
IEEE Std P802.1BA; and (viii) IEEE Std. 1394TA 2006021,
each of the foregoing which are incorporated herein by ref
(or vice versa).
erence in their entirety.
[0057] In another variant, an IEEE 1394 device may stream
data to another IEEE 1394 device via an Ethernet AVB
IEEE 1394-1995
compliant fabric.
documents: the original IEEE Std. 1394-1995, the IEEE Std.
1394a-2000 amendment, the IEEE Std. 1394b-2002 amend
ment, and the IEEE Std. 1394c-2006 amendment. On Jun. 12,
In a second alternate embodiment, this invention
enables IEEE 1394-compliant (“FireWire” enabled) devices
to communicate across a wireless network infrastructure,
As of 2007, IEEE 1394 was a composite of four
such as one enabled by IEEE 802.11 (Wireless Local Area
2008, all these amendments as well as errata and some tech
nical updates were incorporated into a superseding standard
[0059] In another aspect, methods and apparatus are dis
closed which enable ?exible connection management for an
IEEE Std. 1394-2008.
isochronous system having multiple sources and targets (eg
IEEE 1394-1995 (“FireWire 400”)
an audio network). In one embodiment, such ?exible connec
tion management is provided for without regard to the direc
tion or distribution of datastreams.
In yet another aspect of the invention, an implemen
tation-dependent data “fabric” is disclosed. In one embodi
ment, 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 trans
ferring any serial bus subaction from one portal to its co
[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).
portal, and that supports bidirectional, non-blocking transfer
of asynchronous request subactions, asynchronous response
IEEE 1394a-2000
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
1394a) was released in 2000 which both clari?ed and
nous streaming was added, as was faster bus recon?guration,
within a common device enclosure or even on a common
packet concatenation, and a power-conserving “suspend”
substrate or module within the device).
mode of operation. 1394a also standardized use of the 4-pin
[0062] In another variant, the fabric is physically extensive
(e. g., the bridge’s portals are located in more disparate loca
IEEE 1394b-2002 (“FireWire 800”)
tions, such as in separate rooms of a house, or even in separate
An amendment to the original standard (IEEE
enhanced the original speci?cation. Support for asynchro
(non-power) connector.
FireWire 800 or S800 was introduced commercially
by Apple Inc. in 2003. This newer (1394b) speci?cation
[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.1 1 (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.
allows a transfer rate of 786.432 Mbps full-duplex via a new
encoding scheme often referred to as “beta” mode. It is back
wards 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 differ
ent from FireWire 400’s connector, making the cables incom
Exemplary embodiments of the present invention
are now described in detail. While these embodiments are
primarily discussed in the context of an isochronous network
patible. A “bilingual” cable is available which allows the
connection of legacy devices to the new port.
[0072] The 1394b speci?cation supports data rates up to
3200 Mbit/s (S1600 and S3200) 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) encod
ing (called legacy mode) on the signal wires, while 1394b
of devices having differing protocols, and more speci?cally to
a heterogeneous network of IEEE 1394-compliant and Eth
emet AVB devices, it will be recognized by those of ordinary
IEEE 1394c-2006 (“FireWire S800T”)
skill that the present invention is not so limited, and in fact
may be used in other types of applications, and with different
and provides several changes including: (i) a new port speci
added a new data encoding scheme called 8B10B,
IEEE 1394c-2006 was published on Jun. 8, 2007,
?cation which provides 800 Mbit/s over the same R145 con
nectors with CAT-5e cable which is speci?ed in IEEE 802.3
The following brief discussion of standards and
clause 40 (gigabit Ethernet over copper twisted pair); (ii)
their associated descendents is useful for understanding one
automatic negotiation that allows the same port to connect to
either IEEE Std 1394 (FireWire) or IEEE 802.3 (Ethernet)
or more aspects of the present invention.
Ethernet AVB
[0067] So-called “Ethemet AVB Standards” include: (1)
IEEE Std. P1722iStreaming 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.1 BA; (vii)
IEEE Std. 1394.1
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
Sep. 26, 2013
US 2013/0250971A1
allowed on a single FireWire bus. The 1394.1 bridging allows
IEEE Std. 1394TA 2006021
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 de?nes 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 fab
ric between the two portals), cycle timers, route maps, and
con?guration ROM.” However, it is appreciated that the fore
going de?nition is implementation speci?c, 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 ?rst
network technology to a second network technology. Such
IEEE Std. 1394TA 2006021(“Networking IEEE
1394 Clusters via UWB over Coaxial Cable Part 3: PCP and
CMP over IPv4”), which is incorporated herein by reference
in its entirety, describes discovering and controlling device
con?gurations, and connection management. It is based on
the 1394 TA Speci?cations, and uses (i) UDP/IP for commu
nications, and (ii) BonjourTM protocol for discovery and
removal noti?cations.
IEEE Std. 802.1AS and “AppleAS”
IEEE Standard 802.1AS (“IEEE Standard for Local
and Metropolitan Area NetworksiTiming and Synchroniza
methods and apparatus may be physical (e.g., hardware/?rm
tion for Time-Sensitive Applications in Bridged Local Area
Networks”), which is incorporated herein by reference in its
ware implementations), logical (e.g., software implementa
entirety, provides mechanisms for synchronizing frequency
tions), or any combination thereof.
of clocks, and for measuring the propagation delay across a
link. It also provides a NIC-to-bridge interface in bridged
[0075] In addition to the foregoing standards and protocols,
others have been adopted (or are under development) which
relate to AN transmission:
IEEE Std. 802.1Qat
[0076] IEEE Std. 802.1 Qat (“Standard for Local and Met
ropolitan Area NetworksiVirtual Bridged Local Area Net
worksiAmendment: 9: Stream Reservation Protocol (SRP)
”), which is incorporated herein by reference in its entirety,
provides for reservation of bandwidth on the network (includ
ing 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 suf?cient bandwidth to
support adding the stream.
IEEE Std. 802.1Qav
[0077] IEEE P802.1Qav (“IEEE Standard for Local and
Metropolitan Area Networksi-Virtual Bridged Local Area
NetworksiAmendment: Forwarding and Queuing Enhance
ments for Time-Sensitive Streams”), which is incorporated
herein by reference in its entirety, speci?es how to queue
packets to not burst traf?c across the network. Bridges are
used to automatically shape tra?ic.
IEEE Std. 802.1AB
IEEE Std. 802.1 AB (“Station and Media Access
Control Connectivity DiscoveryiApr. 5, 2005”), which is
incorporated herein by reference in its entirety, discloses Link
Layer capability discovery; i.e., discovery of what capabili
ties the ends of the link have. This protocol may be used to tell
end stations what priority to send class-A and class-B traf?c,
and may be used by some bridges to enable AVB functional
network, and NIC-to-NIC in a two-machine network. It is
based on IEEE 1588, and requires ingress/egress time stamp
ing 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. Brie?y, 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 imple
mentation, 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.1AS protocol is implemented in software.
Extension of FireWire “Bridging”
The FireWireTM protocol allows for high-speed data
transfer between two or more devices. The protocol can maxi
mally 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 speci?cation 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 imple
mentation-dependent fabric between the two portals), (iv)
cycle timers, (v) route maps, and (vi) con?guration ROM.
In one embodiment, the present invention provides
such an “implementation-dependent fabric” using an Ether
net AVB cloud. As used herein, an AVB “cloud” refers to a
IEEE Std P802.1BA
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
[007 9] IEEE Std P802.1BA (“AudioVideo Bridging (AVB)
SystemsiDraft PARiFeb. 1, 2008), which is incorporated
herein by reference in its entirety, discloses pro?les that select
features, options, con?gurations, defaults, protocols and pro
cedures of bridges, stations and LANs that are necessary to
build networks that are capable of transporting time sensitive
audio and/or video data streams.
may exist which are not a part of the “cloud” structure (eg
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 bidirec
Sep. 26, 2013
US 2013/0250971A1
tional, non-blocking transfer of asynchronous request subac
tions, asynchronous response subactions, and isochronous
?rst and or the second device. In an alternate embodiment,
such identi?cation is performed at a third party connection
management entity.
[0086] Previous software implementations of FireWire
based audio have typically had similar topologies to Univer
sal Serial Bus (USB) “Host-to-device” models, due to the
[0095] At step 108, the ?rst device negotiates one or more
isochronous parameters to connect with the second device. In
one embodiment, such isochronous parameters may com
relatively inconvenient nature of physically wiring complex
networks, despite FireWire device capabilities. By augment
prise for example: (i) audio sample formats, (ii) sample rates,
ing the FireWire capabilities with Ethernet AVB, and the
corresponding ubiquitous Ethernet infrastructure, such limi
tations are advantageously removed. Thus, while prior art
implementations may implement a single centraliZed super
visory computer; the peer-to-peer nature of the FireWire/
[0096] A source isochronous device in logical connection
with the ?rst device via the ?rst device’s ?rst protocol inter
face 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 trans
Ethernet AVB bus is not so limited. Hence, in another aspect
of the present invention, the functionality between connec
tion management and datastream management is logically
logical bridge between the ?rst and second differing isochro
Such additional ?exibility enables multiple addi
tional use case scenarios. In one embodiment, a FireWire
network with multiple connection managers (e.g., comput
ers) 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 split
ting of data sources can be separated from connection man
agement. Similarly, the connection management can be per
formed in isolation from the data being routed between the
devices (e.g., data is not routed within the connection man
a ger) .
[0090] Referring now to FIG. 1, a ?rst embodiment of the
generaliZed process 100 for integrating an isochronous net
work of devices having differing networking protocols
according to the present invention is described.
[0091] At step 102, a ?rst isochronous network having at
least one ?rst device capable of operating with at least a ?rst
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.
and (iii) channel numbers, etc.
At step 110, the ?rst and second devices provide a
nous protocols. In one embodiment, the management of the
?rst 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.
[0099] Referring now to FIG. 2, an exemplary apparatus
200 useful in implementing the methods of the present inven
tion is illustrated. While a speci?c device con?guration and
layout is shown and discussed, it is recogniZed that other
implementations can be readily implemented by one of ordi
nary 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 datas
tream across two or more differing protocols. In one exem
plary implementation, the multi-lingual functionality is per
formed 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
In one embodiment, the ?rst protocol interface is an
back of the device), distributed throughout the equipment
IEEE 1394.1-compliant interface, and the second protocol
enclosure, as described in greater detail subsequently herein.
[0101] As shown in FIG. 2, the apparatus 200 comprises a
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 inter
processing subsystem 202, operational memories 204, a ?rst
physical connector 206 corresponding to a ?rst protocol, and
a second physical connector 208 corresponding to a second
face. In one embodiment, the external or second device addi
protocol, and a power subsystem 210. In one exemplary
embodiment, the ?rst physical connection corresponds to a
tionally comprises a ?rst protocol interface (not physically
FireWire (IEEE 1394) multi-pin interface (whether 4-pin,
connected to the ?rst device); the second device is physically
connected to a target isochronous device via its ?rst protocol
responds to an Ethernet AVB interface (e.g., RJ-45 connec
interface (wherein the term “target” is applied for clarity
tor). It will be appreciated that any number of different or
6-pin, or otherwise), and the second physical connection cor
rather than to indicate direction of data transfer). The target
similar physical connections (for example, multiple homoge
device can also be part of the second device.
neous and heterogeneous ports) may be used consistent with
the invention as well.
At step 106, the ?rst device determines the existence
of the second device. In one embodiment, such identi?cation
is accomplished via a software entity, such as a software
daemon. The identi?cation is performed local to either the
The processing subsystem 202 comprises a central
processing unit (CPU) or digital processor, such as a micro
processor, digital signal processor, ?eld-programmable gate
Sep. 26, 2013
US 2013/0250971A1
array, or plurality of processing components mounted on one
may be con?gured for “one-to-many” operation (e.g., 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 pro
port of a ?rst protocol, and multiple ports for the other pro
cessing subsystem may also comprise additional co-proces
Exemplary Implementationi
sors, such as a dedicated graphics accelerator, netWork pro
cessor (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 schedul
ing Ethernet packets at the proper rate (eg 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 sen ” 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 (NiiCd) battery provides poWer to the device
apparatus When disconnected from a parent poWer source
The folloWing softWare descriptions further illus
trate one exemplary embodiment useful in implementing a
heterogeneous netWork of audio devices for providing audio
and/or video stream transfers, according to the present inven
tion. While this speci?c embodiment has functionality
divided into kernel and user space operations, these distinc
tions should not be construed as limiting as these components
may be implemented both in kernel space, and/or in user
[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 con
junction With the methods and apparatus of the present inven
tion to facilitate, format and control video delivery over dif
ferent bearer protocols.
Various components are used in the illustrated
such as a 115 VAC Wall outlet/transformer.
embodiment to provide the required functionality. Aspects of
the functionality of these components are described beloW.
The illustrated mass storage subsystem 212 com
prises an integrated circuit memory for storing a computer
The aforementioned components are also provided via a com
readable program, and/or a plurality of discrete electrical
puter program listing appendix entitled “AppleAS SOURCE
components (eg motor, controller, and hard disks, etc.).
CODE” disclosed in Appendix II, herein incorporated in its
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/
Ethernet 802.1 AS Driver
[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, micro
phones 254, cameras 256, DVD and CD disk players 258, or
monitors 260. Such target/source components may be inte
grated Within the device 200, or stand-alone in nature (e.g.,
connected to the apparatus 200 via interposed cabling, Wire
less links, etc.).
In another embodiment of the invention, the appa
ratus 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 accord
ing to an Ethernet protocol). For example, in one variant, the
apparatus comprises a “super hu ” 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 com
prises a removable/portable “dongle” (e.g., adapter or con
ver‘ter). 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 su?icient processing capability
and softWare to perform the protocol “translation” described
elseWhere herein. It Will also be appreciated that the dongle
AppleAS kext (Kernel Extension) is one embodi
ment of the 802.1AS Ethernet driver. It implements the IEEE
802.1AS protocol and provides anAPI for mapping 802.1 AS
grandmaster time to Host CPU time in nanoseconds. Refer
ring 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,
AppleI sochChannelMapper Kext (Kernel Extension) 320,
and AppleFireWireAVBBridge Kext 330. TWo supplemental
softWare components are also utiliZed: AVCDescriptors
Framework (not shoWn), IOFireWireMultiIsochListener 340.
[0112] The daemon (AppleAudioNetWorkingDaemon)
304 is responsible for performing device capability discov
ery, connection management and handling device communi
cations. The daemon sits above the various kernel extensions
needed for performing channel mapping, bridging and audio
streaming, and the frameWorks Which provide device discov
ery, connection management calls and descriptor parsing.
[0113] The AppleAudioNetWorking entity 310 provides
application-level management via a graphical user interface
for con?guring devices and the netWork of devices. The appli
cation entity receives connection management information
from the daemon 304. The application entity 310 is respon
sible for con?guring kernel extensions, talking With devices
and performing local device discovery. AppleAudioNetWork
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF