USOO6970940B1
`
`(12) Unlted States Patent
`(10) Patent N0.:
`US 6,970,940 B1
`
`Vogel et al.
`(45) Date of Patent:
`Nov. 29, 2005
`
`(54) SYSTEM AND METHOD FOR
`DISTRIBUTING A SINGLE MULTICAST
`MULTI-PROGRAM AUDIO STREAM OVER A
`NETWORK
`
`(75)
`
`Inventors: Mark 0. Vogel, Hampshire, IL (US);
`Stephen L- Maynard, Lake Zurich, IL
`(US); Ali Akgun, Chicago, IL (US)
`
`.
`( T ) Notice:
`
`(73) Assignee: 3Com Corporation, Marlborough, MA
`(US)
`.
`.
`.
`.
`Subject to any disclaimer, the term 0f thls
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 948 days.
`.
`..
`,
`(21) Appl No . 09/809 822
`
`(22)
`
`Filed:
`
`Mar. 16, 2001
`
`Int. Cl.7 ............................ G06F 15/16;H04J 3/20
`(51)
`(52) us. Cl.
`.................. 709/236; 709/230, 370/395.52
`(58) Field of Search ................................ 709/230, 236;
`370/3101, 312, 395.5, 39552—3, 710/11,
`379/9002, 93.31
`
`(56)
`
`References Cited
`
`US PATENT DOCUMENTS
`4,237,486 A * 12/1980 Shimp ........................ 348/475
`4,788,675 A
`11/1988 Jones et a1,
`..
`370/69.1
`
`7/1989 Schwab ................ 381/25
`4,845,751 A
`.......
`.. 360/331
`4,920,432 A
`4/1990 Eggers et a1.
`
`49991207 A
`2/1991 ShiiaiShi et al-
`380/9
`T534712 2
`Z133% FBarenelh et a1:
`3:338:
`rugger ...................
`,
`,
`
`..... 370/260
`5,909,431 A *
`6/1999 Kuthyar et a1.
`.
`
`9/1999 Higgins ............... 370/524
`5,953,350 A *
`6,134,587 A * 10/2000 Okanoue .................... 709/222
`
`6,522,342 B1 *
`
`2/2003 Gagnon et al.
`
`............. 345/716
`
`OTHER PUBLICATIONS
`SMILE—A Multimedia Communication Framework for
`Distributed Collaboration,
`Johanson, M.,
`Framkom
`Research Corporation, pp. 1-12.*
`
`RFC 1112: Host Extensions for IP Multicasting, Deering, S.,
`
`
`
`Aug. 1989
`.*
`
`Computer \Ietworking: ATop Down Approach featuring the
`Internet, Kurose & Ross, 2000*
`Cisco 1400 Series, Overview, Cisco Systems, 1999, p.
`140*
`Multicast Deployment Made Easy, IP Multicast Planning &
`Deployment Guide, Cisco Systems, 1999, p. 1-20.*
`ViaCast IP multicastig: The answer to broadband content
`deliver, Medina, D., Broadcast Engineering, Sep. 2000.*
`* cited by examiner
`.
`.
`.
`Primary Examiner—B. Prieto
`(74) Attorney) Age/40 or Firm—McDonnell Boehnen
`Hulbeit &Beigh0if LLP
`
`(57)
`
`ABSTRACT
`.
`.
`.
`.
`.
`A system and method for distributing mult1-program audio
`over a network includes the use of a Local Area Network,
`Wide Area Network, an Intranet and the Internet. The system
`includes a network audio source, a network distribution
`System and end deViCCS The method, for distributing multi-
`program audio over a network includes creating a network
`audio frame from a plurality of blocks of data from at least
`one audio program, placing each network audio frame
`within a transport structure for transport across the network
`and assigning an address to the transport structure prior to
`-
`-
`-
`-
`delivering the transport structure to a phy51cal media.
`
`11 Claims, 5 Drawing Sheets
`
`64
`
`72
`
`62
`
`
`P
`
`REAMBLE
`
`
`66
`68
`70
`Z 60)
`
`
`
`MAC MAC
`TYPE/
`DATA
`
`
`D
`LENGTH UNIT
`SA
`
`I
`
`SF
`
`74
`
`ETHERNET FRAME
`
`IP / UDP / RTP
`HEADER PAYLOAD
`
`LAN AUDIO PROGRAM#. COUNT, ENCODING
`LAN AUDIO FRAME VERSION
`DESCRIPTOR
`
`102
`
`104
`
`106
`
`1
`
`[100
`
`AUDIO DATA
`
`108
`
`APPLE 1049
`
`APPLE 1049
`
`1
`
`

`

`S”U
`
`w
`
`amoEmEz.P052
`
`m2
`
`mosmaozm
`
`mN
`
`Mm.
`
`Sheet 1 0f 5
`
`US 6,970,940 B1
`
`ow
`
`
`
`mo_>mo02m
`
`mm0.03.4
`
`m0<n_mm_._.z_
`
`w.9E
`
`ow
`
`_\.OE
`
`NF
`
`
`
`m0_>m_omomaom
`
`2
`
`

`

`US. Patent
`
`Nov. 29, 2005
`
`Sheet 2 0f 5
`
`US 6,970,940 B1
`
`
`
`bow.vm
`
`
`
`mm
`
`8
`
`wv
`
`ow
`
`3
`
`NV
`
`20—wmm>
`
`
`
`a\a
`
`I._.02m_._E5.65\mat..22:
`
`
`
`<w<0
`
`mm
`
`mm
`
`
`
`om
`
`om
`
`N.07..
`
`
`
`m2<mmHmzmthm.
`
`<._.<n_O_n5<._.zms_0<m_u_
`
`
`
`395Eo<o._><n_
`OZEOOZm
`
`H2200#EEOOKQ
`
`OED<z<.._
`
`
`m=>_<mu_OED<z<._
`
`
`m
`
`mum
`
`mat.
`
`worm—momma
`
`3
`
`
`
`
`
`
`
`

`

`US. Patent
`
`2m.N
`
`9,E
`
`«a
`
`1.52m.—E<._.<o\mat.:2:
`
`
`<w<0
`
`
`
`
`mmaggm.oE
`
`m.
`
`3a
`
`5
`
`US 6,970,940 B1
`
`%8.\\mm
`
`
`
`
`
`
`mn_<0._><n_Mme/E:mum/GImun/m...Q<O._><n_awn/E:
`n_._.mEH.n5:n:nFm\n53\n:
`
`81x
`
`pmmm.vwNm
`
`mop
`
`we
`
`we
`
`N2
`
`
`
`<._.<n_O_D:<
`
`02_QoozmF2300#sZw—Qomm
`
`
`m_n_>._.mOhmEommn
`
`
`
`
`OED<z<._m_>_<mu_OED<z<._
`
`zo_mmm>
`
`
`
`
`
`m=>_<m_n_Hmzmmzhm
`
`4
`
`
`
`
`

`

`US. Patent
`
`m.
`
`5m
`
`w
`
`US 6,970,940 B1
`
`$5.53:Ea?M“,A”8%»wa
`Emdsoooz<wmagmao2//EOE:
`
`
`
`%92$05:oz<mmanEm
`
`Ecumzéh253.8
`
`N«2
`
`w,9.8:.<29Esamézm
`
`Er
`
`
`
`
`
` 9.00.5<55O_o:<._.:n_z_.56a
`
`
`
`
`
`
`
`Sous.._<o_m>_._n_O._.mm>_._mo
`
`5
`
`
`
`

`

`US. Patent
`
`Nov. 29, 2005
`
`Sheet 5 0f 5
`
`US 6,970,940 B1
`
`
`
`
`
`
`
`figfifillfiwadwmmfimkefikllggfiggggEggfifigg
`
`mm?
`
`fillfimwwgfigmfillg
`
`«ammafizoz<mmanEm
`
`hmOmmzék259:5
`
`Em
`
` gal-”fig.
`
`flwwfififimnmlllE"4...,“mg
`
`.I
`
`I'll!-
`ll'alllll.
`
`wmeE55.95220522:
`
`mmo<wzmmjméoooz<
`
`
`
`N87/1,!
`
`
`sows.._<o_w>1n.O._.mm>_._m_o
`
`8“//onm“a:2.$55:
`
`xo<hwn:z_
`
`mun—«m:oz<._.m_v_0<n_n:3.3m8..
`
`
`
`oz<.Ev.0<n_PESSm
`
`xo<._.mPE2_mun—(m:
`
`oz<._.m_v_o<n_n5:35m
`
`cam
`
`6
`
`
`
`
`
`
`
`
`

`

`US 6,970,940 B1
`
`1
`SYSTEM AND METHOD FOR
`DISTRIBUTING A SINGLE MULTICAST
`MULTI-PROGRAM AUDIO STREAM OVER A
`NETWORK
`
`FIELD OF THE INVENTION
`
`This present invention relates to audio distribution sys-
`tems. More specifically, it relates to a system and method for
`distributing multi-program audio over a network.
`BACKGROUND OF THE INVENTION
`
`People are increasingly utilizing Local Area Networks
`(LANs) in their residences to connect devices residing in
`disparate rooms within their residences. In addition, com-
`panies are also looking at utilizing LANs within vehicles to
`enable passengers to access information or entertainment
`while in a vehicle. The presence of LANs in a residential
`arena provides the opportunity to utilize this distribution
`network for non-traditional LAN applications. One such
`application is LAN audio. With the widespread presence of
`digital audio material, for example Moving Pictures Experts
`Group Layer-3 (MP3), LANs become an excellent transport
`network for the distribution of audio material throughout the
`home.
`
`Current residential audio distribution systems typically
`take one of two following forms, excluding placing standard
`audio wiring throughout the home. The first system uses
`wireless technology to provide a tetherless connection
`between an audio source and a headset, or a speaker system.
`This type of system does not support multiple simultaneous
`audio programs on the system, and is generally not designed
`as a network distribution system but instead is intended to
`eliminate the need for wires or wiring. In addition,
`the
`wireless interface is typically integrated with the end-user
`device. The second system uses the Transmission Control
`Protocol/Internet Protocol (TCP/IP) protocol suite to dis-
`tribute audio over a LAN. This is typically implemented
`with an audio server as a source device, and a personal
`computer with an audio card as the end device. Internet
`Protocol (IP) multicast is used along with Realtime Trans-
`port Protocol (RTP) to enable end devices to join a multicast
`service. RTP is an Internet Engineering Task Fork (IETF)
`standard for streaming realtime multimedia over IP in pack-
`ets. It supports transport of realtime data like interactive
`voice and video over packet switched networks. Within the
`RTP protocol, currently only a single audio program and
`audio encoding type is supported per multicast stream.
`Therefore to support multi-program audio, multiple multi-
`cast streams must be created with each stream supporting a
`separate audio program and potentially audio encoding type.
`The user would, at the end device, select the desired mul-
`ticast stream from the group of multicast audio programs.
`This also means that the end device must learn or acquire the
`addresses of all of the multicast streams.
`
`Therefore, it is desirable to provide a method and system
`which distributes multi-program audio over a network such
`as, for example, LAN within a single multicast stream, and
`which supports multiple audio encoding types.
`SUMMARY OF THE INVENTION
`
`The system and method of the present invention provides
`for the distribution of multi-program audio over a network.
`The network may include a Local Area Network (LAN),
`Wide Area Network, an Intranet and a public network such
`as the Internet.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`In accordance with one aspect of the present invention, a
`system for distributing multi-program audio over a network
`includes a network audio source, a network distribution
`system, and at least one end device. In a particular embodi-
`ment, the network distribution system is a wired system such
`as, but not limited to, IEEE 802.3, IEEE 802.5, IEEE 1394,
`and Home Phone Network Alliance (HPNA). In another
`particular embodiment,
`the network distribution system
`includes, a wireless system and includes, but is not limited
`to, IEEE 802.11, Bluetooth, HomeRF and IrDA. The end
`device provides a standard interface to a sound-producing
`device such as speakers or headphones.
`In accordance with another aspect of the present inven-
`tion, a method for distributing multi-program audio over a
`network includes receiving audio data blocks, encapsulating
`the audio data blocks into frames, building a network model
`layer, such as an Open Systems Interconnection (OSI) model
`layer protocol packet and stack, building a network transport
`structure and header, assigning a multi-cast address and then
`delivering the packet to the physical media. In one particular
`embodiment of the method of the present invention, the
`network transport structure is placed within an OSI layer 2
`frame such as a Medium Access Control frame. In another
`
`particular embodiment, an Internet Protocol/User Datagram
`Protocol/Realtime Transport Protocol of the OSI layers is
`used to transport the audio data across the network.
`The foregoing and other features and advantages of the
`system and method for distributing multi-program audio
`over a network will be apparent from the following more
`particular description of preferred embodiments of the sys-
`tem and method as illustrated in the accompanying drawings
`in which like reference characters refer to the same parts
`throughout the different views.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`invention are
`Preferred embodiments of the present
`described with reference
`to the
`following drawings,
`wherein:
`
`FIG. 1 is a diagram illustrating a preferred embodiment of
`the system for distributing multi-program audio over a
`network in accordance with the present invention;
`FIG. 2 is a diagram illustrating a Local Area Network
`(LAN) audio frame using a Medium Access Control Layer
`in accordance with a preferred embodiment of the present
`invention;
`FIG. 3 is a diagram illustrating a LAN audio frame using
`the Internet Protocol/User Datagram Protocol/Realtime
`Transport Protocol (IP/IUDP/RTP) in accordance with a
`preferred embodiment of the present invention;
`FIG. 4 is a flowchart diagram illustrating a method using
`the Medium Access Control layer implementation in accor-
`dance with a preferred embodiment of the present invention;
`and
`
`FIG. 5 is a flow chart diagram illustrating a method using
`the IP/UDP/RTP protocol
`implementation in accordance
`with another preferred embodiment of the present invention.
`
`DETAILED DESCRIPTION OF PREFERRED
`EMBODIMENTS
`
`The present invention is directed to a system and method
`for distributing multi-program audio over a network. The
`network preferably is a Local Area Network (LAN) but may
`include, and is not limited to, a Wide Area Network (WAN)
`or an Intranet or the Internet.
`
`7
`
`

`

`US 6,970,940 B1
`
`3
`the system of the present
`In a preferred embodiment,
`invention includes a software application or a device that
`packages the audio material and places it on the network. It
`additionally consists of a remote device which accesses the
`network, retrieves the specific audio program, and converts
`the audio material back to an analog format that can be used
`by standard audio devices such as headphones and speakers.
`The system in accordance with a preferred embodiment also
`provides the physical
`interface for these standard audio
`devices. With such a system a user can access audio from
`any location where the network is present, utilizing either a
`physical, or a wireless connection. In addition, a user can
`program a preferred selection for the material to be made
`available on the network, and can select which material is to
`be decoded at the receiving end device. Such a preferred
`embodiment of the system in accordance with the present
`invention can be used within a residence or a vehicle with
`
`the end device being transportable between the two. It may
`also be used in commercial applications where multi-pro-
`gram audio is utilized such as, for example, airplanes, and
`office complexes.
`System Overview
`FIG. 1 is a diagram illustrating a network audio system
`10, in which the network 14 is a Local Area Network (LAN)
`in accordance with a preferred embodiment of the present
`invention. The LAN audio system 10 is comprised of an
`audio source device 12 and one or more receiving end
`devices 16, 20. In one embodiment of the present invention,
`the LAN is a 100 Mega-bit (“Mbit”) per second or faster
`Ethernet, LAN. However, other types of LANs could also be
`used, for example, optical or coaxial cable networks. The
`source may be a device such as a phonograph or an audio
`device such as a “jukebox” including multi-media such as
`Compact Discs (CDs) and Digital Video Discs (DVDs) that
`is able to stream multiple audio programs. In the alternative,
`the source 12 may be an application or sequence of instruc-
`tions that resides on a server, a gateway, or a standard
`personal computer. In either case, the audio source 12 is
`connected to the network 14 or in a preferred embodiment,
`the LAN. Through the source device 12 or application, the
`user is able to configure the system to stream a number of
`audio programs on to the network 14. At the user end, there
`is a device which has a network interface, and a standard
`audio interface 18, 22 such as, for example, RCA interfaces,
`or speaker terminals, to connect to sound producing devices
`such as headphones, or speakers. In addition, the system 10
`in accordance with the present invention has the hardware
`and software necessary to select the audio program and
`convert
`it
`to a standard baseband analog format. This
`enables the user to select different audio programs as well as
`listen to them using different audio devices. In a particular
`embodiment, the end device 16, 20 may be separate from or
`alternatively integrated with the receiving device. In another
`particular embodiment,
`the end device 16, 20 may be
`mounted in a structure such as, for example, a panel in an
`armrest in a vehicle or airplane to which a receiving device
`may be connected. The network itself, although shown as
`being interfaced with physical cabling in FIG. 1, may also be
`a wireless network. The network distribution system,
`in
`particular wired embodiments may include, but is not lim-
`ited to, IEEE 802.3, IEEE 802.5, IEEE 1394 (Firewire), and
`Home Phone Network Alliance (HPNA). The network dis-
`tribution system in particular wireless embodiments may
`include, but
`is not
`limited to, IEEE 802.11, Bluetooth,
`HomeRF and IrDA.
`
`Apreferred embodiment of the present invention uses the
`IEEE 802.11 high speed wireless protocol at the physical
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`level. The IEEE 802.11 Wireless LAN specification was
`developed to provide wireless connectivity to automate
`machinery, equipment, or stations that require rapid deploy-
`ment, or stations that require rapid deployment, which may
`be portable or handheld, or which may be moving within a
`local area. The 802.11 devices operate in the 2.4 GHz
`Industrial, Scientific, and Medical (ISM) band at rates of up
`to 2 Mbps and distances up to 100 meters. Both frequency-
`hopping and direct sequence spread spectrum are supported
`by the specification. Frequency-hopping spread spectrum is
`implemented using Gaussian Frequency Shift Keying
`(GFSK) with 1 or 2 bits per symbol, and 1 MHZ channels.
`The hop size is 6 MHz, and in the United States up to 79
`channels are available in the ISM band. Direct sequence
`spread spectrum is implemented using Differential Binary
`Phase Shift Keying (DBPSK) with 1 or 2 bits per symbol
`and 25 MHz channels. Further, three to six direct sequence
`channels are available in the ISM band depending on
`whether there is channel overlap.
`The 802.11 system provides a point-to-point connection
`(two stations communicating directly), or a point-to-multi-
`point connection. In such a multipoint arrangement, a chan-
`nel is shared among multiple 802.11 devices. With a station
`in each system acting as an access point, multiple systems
`may be connected to form a distribution system. If a device
`in a system acts as a portal, a system and/or a distribution
`system may be connected to a non-802.11 system such as an
`802.3 wire line Ethernet LAN via the portal device. For
`more information on the IEEE 802.11 Wireless LAN speci-
`fication see the Institute of Electrical and Electronic Engi-
`neers (IEEE) standard for Wireless LANs incorporated
`herein by reference. IEEE standards can be found on the
`World Wide Web at the Universal Resource Locator (URL)
`www.iee.org.
`Another preferred embodiment of the system to distribute
`multi-program audio over a network uses Bluetooth tech-
`nology. Bluetooth is a short-range radio link intended to
`replace the cable(s) connecting portable and/or fixed elec-
`tronic devices. Bluetooth technology features low power,
`robustness, low complexity and low cost. It operates in the
`2.4 GHz Industrial, Scientific and Medical (ISM) band.
`Devices equipped with Bluetooth are capable of exchanging
`data at speeds up to 720 kbps at ranges up to 10 meters. It
`should be noted that higher power devices than typical
`Bluetooth enabled devices, such as, for example, a Network
`Access Point, may communicate via Bluetooth with an RF
`enabled device over a greater range, such as, for example,
`approximately 100 meters.
`A frequency hop transceiver is used to combat interfer-
`ence and fading. A shaped, binary FM modulation is applied
`to minimize transceiver complexity. A slotted channel is
`applied with a nominal slot length of 625 us. For full duplex
`transmission, a Time-Division Duplex (TDD) scheme is
`used. On the channel, information is exchanged through
`packets. Each packet
`is transmitted on a different hop
`frequency. Apacket nominally covers a single slot, but can
`be extended to cover up to five slots.
`The Bluetooth protocol uses a combination of circuit and
`packet switching. Slots can be reserved for synchronous
`packets. Bluetooth can support an asynchronous data chan-
`nel, up to three simultaneous synchronous (voice) channels,
`or a channel which simultaneously supports asynchronous
`data and synchronous voice. Each voice channel supports a
`64 kb/s synchronous (voice) channel in each direction. The
`asynchronous channel can support maximal 723.2 kb/s
`asymmetric, or 433.9 kb/s symmetric.
`
`8
`
`

`

`US 6,970,940 B1
`
`5
`The Bluetooth system consists of a radio unit, a link
`control unit, and a support unit for link management and
`host terminal interface functions. The link controller carries
`
`out the baseband protocols and other low-level link routines.
`The Bluetooth system provides a point-to-point connec-
`tion (only two Bluetooth units involved), or a point-to-
`multipoint connection. In the point-to-multipoint connec-
`tion, the channel is shared among several Bluetooth units.
`Two or more units sharing the same channel form a piconet.
`One Bluetooth unit acts as the master of the piconet, whereas
`the other units act as slaves. Up to seven slaves can be active
`in a piconet.
`System Operation
`As is known in the art, networks have their own hardware
`and software to interface with the physical media that carry
`the signals, and the network software must interface with the
`operating system software. The processing units communi-
`cate with each other using a set of rules called a protocol. A
`group of protocols, all related to the same model are called
`a protocol suite. To encourage open systems, a common
`model called Open Systems Interconnection (OSI) was
`developed by the International Standards Organization. OSI
`engendered a protocol suite which allows computers of all
`sizes and capabilities the world over to communicate using
`a common set of rules.
`
`The OSI model consists of seven layers of software
`including from lowest
`to highest, a physical, data-link,
`network,
`transport, session, presentation and application
`layer. Each of the layers makes different functionality avail-
`able to computers communicating using this model. Each
`layer in the model deals with specific computer communi-
`cation functions. A preferred embodiment of the system 10
`of the present invention uses one or more layers of the
`protocol stack defined by the OSI model. The physical layer
`is the lowest layer and specifies the rules for transmission of
`signals across the physical media (i.e.,
`the electrical,
`mechanical and functional control of data circuits). The
`physical media is analogous to interface ports. The physical
`layer transmits bits over a communication link.
`The data link layer or media abstraction, deals with
`transmission of data between devices on the same network.
`
`In addition to describing how a device accesses the physical
`media,
`this layer also provides some measure of error
`detection and control. This layer is thus concerned with
`procedures and protocols for operating the communications
`lines. Local Area Network (LAN) technologies such as,
`Ethernet, Token Ring and Fiber Distributed Data Interface
`(FDDI) operate at this layer. Data link addresses are imple-
`mented at this layer, and provide each device connected to
`the network a unique identifier by which packets may be sent
`to it. The data link layer includes the Medium Access
`Control (MAC) layer. As is known in the art, the MAC layer
`controls access to a transmission medium via the physical
`layer.
`The network layer deals with transfer of data between
`devices on different networks. The network layer adds the
`notion of network addresses which are specific identifiers for
`each intermediate network between a data source and a
`
`destination. For example, in the network layer there is an
`Internet Protocol (IP) layer. This IP layer roughly corre-
`sponds to the OSI layer 3, the network layer, but is typically
`not defined as part of the OSI model. As is known in the art,
`the IP layer is a routing protocol designed to route traffic
`within a network or between networks. More information on
`
`IP may be obtained from the Internet Engineering Task
`Force (IETF) Request
`for Comments (RFC), RFC-791
`incorporated herein by reference.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`the session
`layer,
`the transport
`The remaining layers,
`layer , the presentation layer and application layer are called
`the higher layers. These layers deal with communication
`between message source and message destination. The
`transport layer defines the rules for information exchange
`and manages end-to-end delivery of information within and
`between networks, including error recovery and flow con-
`trol. For example, a User Datagram Protocol layer (UDP)
`may be present in the transport layer. The UDP layer roughly
`corresponds to OSI layer 4,
`the transport
`layers, but
`is
`typically not defined as part of the OSI model. As is known
`in the art, UDP provides a connectionless mode of commu-
`nications with datagrams. More information on UDP may be
`obtained from RFC-768 incorporated herein by reference.
`The session layer is concerned with dialog management.
`The presentation layer provides transparent communications
`services by masking the difference of varying data formats
`between dissimilar systems. The application layer contains
`functions for particular applications services, such as, file
`transfer, remote file access and virtual terminals.
`Within the OSI model,
`the user presents data through
`application programs, such as, the User Interface Applica-
`tion Programming Interface, to the highest layer the appli-
`cation layer. This data is then passed downward through the
`hierarchy of layers with each layer adding addressing and/or
`control information. The OSI layer Application Program-
`ming Interfaces (APIs) pass data between the OSI model
`layers. When the data reaches the physical layer, and to the
`physical interfaces, it is sent to a device or network system.
`Conversely, received data at the physical interfaces is passed
`up through the layers with each layer stripping address or
`control information.
`
`The system and method for distributing multi-program
`audio over a network may use other communication proto-
`cols beside the OSI model. These include, but are not limited
`to, Transmission Control Protocol/Internet Protocol (TCP/
`IP), User Datagram Protocol/Internet Protocol (UDP/IP),
`Hyper Text Transfer Protocol (HTTP), Trivial File Transfer
`Protocol (TFTP), File Transfer Protocol (FTP), and the
`Bootstrap Protocol (BootP). The TCP/IP protocol is a net-
`working protocol
`that provides communications across
`interconnected networks, between computers with diverse
`hardware architectures and various operating systems. The
`UDP/IP is part of the TCP/IP protocol suite. UDP/IP pro-
`vides for exchange of datagrams without acknowledgements
`or guaranteed delivery. HTTP is the actual protocol used by
`the Web server and the Client browser, for moving docu-
`ments around the Internet. The TFTP is a simplified version
`of the File Transfer Protocol (FTP) that transfers files but
`does not provide password protection or user-directory
`capability. TFTP is associated with the TCP/IP family of
`protocols and depends on the connectionless datagram deliv-
`ery service, UDP. More information on TFTP is available
`from RFC-1350 incorporated herein by reference. FTP lets
`users quickly transfer text and binary files to and from a
`distant or local personal computer, list directories, delete and
`rename files on the foreign host and perform wildcard
`transfers between hosts. The distant or local personal com-
`puter may be a local area network or a phone line across the
`world or connected to the Internet. The BootP is a TCP/IP
`protocol which allows an Internet node to discover certain
`startup information such as, its IP address.
`Another suitable protocol that may be used to transport
`the audio data is the Realtime Transport Protocol (RTP),
`which itself is carried inside of UDP (User Datagram
`Protocol). RTP is described in H. Schulzrinne et al., “RTP:
`
`9
`
`

`

`US 6,970,940 B1
`
`7
`A Transport Protocol for Real-Time Applications,” IETF
`RFC 1889, January 1996, which is incorporated herein by
`reference.
`
`The operating environment for the system 10 of the
`present invention includes a processing system with at least
`one Processing Unit such as a Central Processing Unit
`(CPU) and a memory system. In accordance with the prac-
`tices of persons skilled in the art of computer programming,
`the present invention is described below with reference to
`acts and symbolic representations of operations that are
`performed by the processing system, unless indicated oth-
`erwise. Such acts and operations are sometimes referred to
`as being “computer-executed”, or “CPU executed.”
`It will be appreciated that
`the acts and symbolically
`represented operations include the manipulation of electrical
`signals by the CPU. An electrical system with data bits
`causes a resulting transformation or reduction of the elec-
`trical signal representation, and the maintenance of data bits
`at memory locations in the memory system to thereby
`reconfigure or otherwise after the CPU’s operation, as well
`as other processing of signals. The memory locations where
`data bits are maintained are physical locations that have
`particular electrical, magnetic, optical, or organic properties
`corresponding to the data bits.
`The data bits may also be maintained on a computer
`readable medium including magnetic disks, optical disks,
`organic disks, and any other volatile or non-volatile mass
`storage system readable by the CPU. The computer readable
`medium includes cooperating or interconnected computer
`readable media, which exist exclusively on the processing
`system or is distributed among multiple interconnected
`processing systems that may be local or remote to the
`processing system.
`There are at least two preferred embodiments for the
`network audio protocol. A first preferred embodiment is
`based on a MAC layer implementation that eliminates the
`need for the higher layer IP/UDP/RTP protocols. This pre-
`ferred embodiment reduces the overhead of each audio
`
`packet and enables a lower cost end device since processing
`and memory requirements of a MAC layer implementation
`are much lower than higher layer implementations.
`The second preferred embodiment is based on an IP/UDP/
`RTP implementation with a modification to RTP to enable
`multi-program audio and multiple encoding types within a
`single multicast stream. This increases the complexity of the
`end device but enables the introduction of additional IP
`
`based capabilities such as a Real Time Control Protocol
`(RTCP) which is a part of RTP, eXtensible Markup Lan-
`guage (XML), HyperText Markup Language (HTML), and
`Service Location Protocol (SLP). In general, the capabilities
`of the two preferred embodiments rely on the introduction of
`a LAN audio frame which enables the multi-program audio
`and multiple encoding type capabilities within a single
`multicast stream.
`
`The network, and in a preferred embodiment, the LAN
`audio source sequentially takes a block of data from a user
`defined number of audio programs, and encapsulates each
`block of audio data in a network, or in one embodiment, in
`a LAN audio frame. A preferred method of the present
`invention includes the source device then placing each LAN
`audio frame in a separate transport structure, assigning a
`common multicast address, and then streaming the data onto
`the network or preferably the LAN. Each transport structure
`frame contains audio information from a single program,
`each of which could be of a different audio encoding type,
`such as, for example, but not limited to, Moving Pictures
`Experts Group Layer-3 (MP3) and Wave File (WAV) which
`
`8
`is a Microsoft Windows proprietary format for encoding
`sound. Consecutive transport frames may contain audio data
`from different programs, however, all frames are addressed
`by a single multicast address as described herein below. To
`enable this flexibility, each LAN audio frame includes a
`LAN audio header that is pre-pended to the audio data
`contained within the LAN audio frame. For one of the
`
`preferred embodiment which uses RTP, this is considered an
`extension to the RTP protocol. The LAN audio header
`provides the end devices with the information they need to
`extract a specific program from the single multicast stream.
`The header includes some combination of the following
`items, which are dependent on the preferred embodiments:
`version number of the network, or more particularly, in one
`embodiment, the LAN audio protocol, size of the payload,
`number of programs in the multicast stream, program num-
`ber, encoding type (MP3, WAV, etc.) within the payload,
`packet sequence (per program), fragmentation (standard or
`proprietary), and program descriptor.
`To enable multi-program audio within a single multicast
`stream, addressing of the network audio data is based on a
`single specific multicast address that conforms to the par-
`ticular network or preferably, but not
`limited to, LAN
`implementation. For example, with an Institute of Electrical
`and Electronics Engineers (IEEE) LAN, such as IEEE
`802.3, or IEEE 802.11,
`the address originates from the
`locally administered multicast pool as defined by the IEEE.
`Other LAN implementations, such as Home Phone Network
`Alliance (HPNA), and Bluetooth may utilize a specific
`address fitting within their particular addressing scheme.
`End devices specifically look for this address and ignore all
`other data without
`this address. By using a single, and
`locally known and administered multicast address for all
`LAN audio frames, the end device does not need to learn and
`store multiple addresses as is required with the current RTP
`specification. In addition, by using a single locally admin-
`istered address, there is no conflict with other global mul-
`ticast services.
`
`The final format of a LAN audio frame for two preferred
`embodiments, based on an Ethernet implementation, are
`shown in FIGS. 2 and 3. FIG. 2 is a diagram illustrating a
`LAN audio frame 40 using a MAC layer in accordance with
`a preferred embodiment of the present invention while FIG.
`3 is a diagram illustrating a LAN audio frame 100 using an
`IP/UDP/RTP protocol in accordance with another preferred
`embodiment of the present invention.
`In FIGS. 2 and 3 the ethernet frames 24, 60 of audio data
`are reformatted to a network audio frame such as the LAN
`audio frame 40, 100. The ethernet audio frame 24, 60
`includes the following