WACA Introduction XO 102604.docWACA Introduction XO 102601.doc
`
`Rev. XO
`
`Public Relations and Marketing role, which must be kept in mind so the
`wireless adaptor should be in a fairly robust and mature stage such as a "pilot
`series" with final form, fit and function.
`
`1.2.3 Production
`
`The production launch is scheduled for the summer of 2005. The wireless
`audio adaptor may be bundled with entertainment phones special "iRadio"
`edition or sold as an accessory through various distribution channels.
`
`1.3
`
`Scope
`
`This document first describes the concept of the wireless audio car adapter,
`summarizes the various technical assumptions then proposes a road map for
`various market segmentations.
`It then highlights milestones deliverables and
`preliminary schedule.
`In appendix, are
`listed
`the specific relationship
`responsibilities and various term sheet details such as ownership, licensing,
`warranties, and technical assistance.
`
`Key products we seek to develop through this collaboration
`
`1- Initially for demonstration Q4 2004: a universal CD adaptor for a majority
`of OEM and aftermarket head-units forwarding on a serial bus at 9.6kbps
`- 19.2kbps (RS232 or TTL) all the" head-unit key events along with
`pushing CD text information back to the head-unit. This should be based
`on similar products developed for iROD interface, different brand CD
`changer or XM / Sirius "direct connect" interface technology.
`
`2- For trials Q2 2005: an integrated core reference design that could be
`licensed to an ODM of Motorola's choice based on an Analog Devices
`BlackFin technology, a similar combo DSP/ARM media processor or
`integrated into Zeevo BlueTooth "system on chip". This reference design
`will integrate audio decoder(s), Motorola's iRadio BlueTooth stack and
`control middleware with the partner universal CD changer adapter
`technology.
`
`3- To be Negotiated:
`a. small series of 100-200 wireless adaptors based on reference
`design to be demonstrated in Q2 2005 for limited trial.
`b. Production agreement
`
`Motorola Confidential Proprietary
`
`Page 6
`
`2/11/200510/27/200'1 |
`
`Page 334 of 667
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XO 102604.doc
`
`Rev: XO
`
`14 Glossary
`
`Mobile Client An iRadio enabled mobile device has its own storage and is
`occasionally connected to a home PC/gateway for updating
`stored content and sending back usage data. For the Demo
`and Trial, the only Mobile Client will be Motorola Entertainment
`phones. For later product phases Mobile Clients could also
`include: car decks and high-end wireless adapters, PDA,
`personal music player...
`
`"WACA"
`Wireless
`Audio Car
`Adapter
`
`A device that forms the gateway between the phone and the car
`radio head-unit, acting as a universal adaptor for a majority of
`aftermarket and OEM car decks.
`It will receive car radio/CD changer messages, translate them to
`appropriate Mobile Client commands and send the translated
`commands over Bluetooth to the Mobile Client.
`It will receive Mobile Client commands over Bluetooth, translate
`them to appropriate car radio/CD changer messages to the car
`radio.
`It will receive compressed audio over Bluetooth from the Mobile
`Client, decode it and output it via a lineout audio output.
`In higher-end inceptions, it could broadcast audio and data over
`T'-.'TV FM or store its own content directy and acts as a stand-alone
`renderer. Road-map allows the Bluetooth wireless link to evolve
`towards WiFi type of wireless protocol
`
`A2DP
`
`PAN
`
`SPP
`
`A BlueTooth Advanced Audio Data profile which allows quality
`stereo audio to be streamed over BlueTooth rather than the
`limited speakerphone/or headphone profile.
`It uses as a
`standard a Sul>band perceptual codec (SBC). Alternatively,
`well-known codec decoders could be attached as plugins such
`as MPS, WMA or AAC+ to avoid codec cascading degradation.
`
`Another BlueTooth serial profile dubbed "Personal Area
`Network" for proximity ad-hoc networking over IP network.
`
`The basic serial profile connection for FTP exchanges over
`BlueTooth for point-to-point files exchange
`
`Motorola Confidential Proprietary
`
`Page 7
`
`2/11/200510/27/2001 |
`
`Page 335 of 667
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XO 102601.doc
`
`Rev: XO
`
`1.5 Assumptions
`
`• The wireless adaptor wiD be able to interface a majority of major
`aftermarket brands such as Pioneer, Alpine, Clarion, Kenwood, Sony,
`JVC and Panasonic
`• The wireless adaptor will be able to interface a majority of major OEM
`brands such as GM, Ford, DaimlepChrysler, Toyota, Honda and most
`European makers like BMW and VW.
`• The wireless adaptor will control directly the MUTE line and the proprietary
`bus.
`• All depressed keys on the head-unit are expected to be reported. At a
`minimum, all presets memory keys, previous track /next track, fast forward
`and Rewind, source information should be relayed to the WACA
`• The wireless adaptor will be able to display text on the car radio deck and
`will manage the timing of the displays and associated warning sounds
`• The alternative use of "proprietary" custom car radio buses is legal
`through either legal reverse engineering and public domain information or
`individual agreement with the car radio makers.
`
`• Others TBD...
`
`Motorola Confidential Proprietary
`
`Page 8
`
`2/11/200510/27/2001 |
`
`Page 336 of 667
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XO 102604.doc
`
`Rev: XO
`
`2 Wireless Audio Car Adaptor options
`
`The "WACA" concept can branch into a various farrily of products, which may not
`all end up in production, but may address different segments of the market. It
`starts with BlueTooth as the major wireless proximity transport then expands to
`the WiFi family and even branch into a tethered solution to hostthe transmitting
`phone in a recharging USB cradle. Here is a brief description of the major
`topologies:
`
`2.1 Basic WACA Architecture
`
`The WACA is a 2 way wireless gateway interface that translates audio
`files and commands streamed from a Motorola phone over BUeTooth into
`an analog or PCM audio feed to the car radio. It also receives car deck
`user interface commands (key push and release events) and status
`information so that the system operates in a closed loop where both the
`phone and the car deck can select which music the user wants. Finally,
`the WACA also send text information to the car deck through the limited
`CD text capabilities which are either containing audio program associated
`data or dialog with the user.
`
`TIC
`
`• BlueTooth transport
`• Streamed audio file
`• Text commands
`• car decks inputs and
`status
`
`•PPRat.
`
`BlueTopth^Slack^
`
`hiDAe]
`
`iGodec!
`
`mil
`
`iRadioCar Stack
`icjunctiomeo
`
`CaftdecKBBi
`Bustgont'olfelKa
`
`ipRSMj
`Flash
`
`Sm?
`
`fc
`
`Figure 1: generic WACA Architecture
`
`• Power, ground
`• R+,R-.L+,L-
`• Mute
`• Custom bus:
`/ •car decks inputs and status
`•CD text display
`• SP/DIF
`
`fcftlKS
`illppj
`
`n MSu
`
`--
`
`gp.
`
`-3 PI
`V£...
`
`Motorola Confidential Proprietary
`
`Page 9
`
`Page 337 of 667
`
`

`
`WACA Introduction XO 102604.doc W AC A Introduction X0 102604.doc
`
`Rev: XO
`
`2.2 WACA#1: BlueTooth baseline Ihin client
`
`The baseline will use BlueTooth as a wireless transport and the "WACA" will
`behave essentially as a "slave" device to the phone. The following diagram
`represents this:
`
`Command/Control
`
`Steaming Audio
`
`©f
`'
`iOsMk
`MSf I
`
`r**-
`
`W !
`
`.v/'&J
`
`mm*
`
`"tk
`
`reiduMl
`IMalaSI
`
`1
`
`r _ .
`
`MMiabas^B
`
`• Analog or PCM
`Audio
`• Text display
`• Car deck events
`and status
`
`Bl
`
`lOSjli^rinelLJ
`
`Figure 2: Baseline thin client WACA Architecture
`
`The CD changer interface "adaptors" on the market are using some ATMEL /
`Cirrus 8/16bits microcontrollers which are not powerful enough to handle the
`BlueTooth stack and the associated audio decodng. Two controller solutions are
`envisioned and will dictate the road map based on price targets and flexibility of
`reconfiguration;
`• Use an integrated "System-on-Chip" like Zeevo family of products which
`integrates BlueTooth stack, basic SBC decoder andARM+DSP chips on
`the same die, allowing cost-effective application solutions like iRadio to be
`built on.
`• Use a two chip solution: integrated BlueTooth baseband processor from
`Broadcom or CSR and multimedia embedded controller like the Analog
`Devices BlackFin, PowerPC or Intel Xscale
`
`Natural evolution: With improvements in price and power consumption, WiFi /
`802.1 Ixx wireless transport may gradually replace BlueTooth in the phones and
`other portable media devices as ubiquitous wireless PAN transport. Insuch a
`case, a next version of the WACA thin client would replace the BlueTooth stack
`with a WiFi stack. WiFi/802.11xx interface may also allow direct transfer and
`
`Motorola Confidential Proprietary
`
`Page 10
`
`Page 338 of 667
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XQ 102601.doc
`
`Rev: XO
`
`synchronization from the home gateway without the phone being needed if RF
`propagation allows it.
`
`2.3 WACA #2: "No Install-totally wireless" thin client
`
`For consumer mass adoption, it is likely that however simple the professional
`installation could be, this is still a major hurdle to clear with the consumer. A
`totally wireless solution would include a wireless FM broadcast to convert the
`audio stream and tune to one FM station at a time on the car deck. The sound
`quality will be sacrificed for the ease of installation. SDARS user's high
`percentage request has proven that the FM broadcast solution was a great
`enabler for mass adoption and easy listening in the car or at home.
`
`In the case of iRadio, the two-way interaction could be improved by adding two
`key features:
`• Use RDS to display text for audio program associated data and also
`interactive messages.
`• Use of basic short vocabulary command based speech recognition to
`select channel playlists
`
`Command
`/ Control
`
`Streaming Audio
`
`D
`
`Micro IN
`
`Bl M-TUPU ,
`
`NSS
`'WV'
`
`•M
`
`* i
`
`<3
`
`.^Esp'^EchSi.lJ
`
`t "JHHTl
`
`1
`
`f-Broadca
`
`11|
`
`'*
`
`: i BmaBcasu
`
`iHsemmands
`
`FM
`
`Car radio
`deck
`
`Figure 3: "Totally wireless" thin client WACA Architecture
`
`2.4 WACA #3: Wired Audio Car Adaptor
`
`In this architecture, the WACA is a "Master" reading content from mass
`storage devices connected through USB. The key advantage from this
`
`Motorola Confidential Proprietary
`
`Page 11
`
`2/11/200510/27/2001 |
`
`Page 339 of 667
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XO 10260'l.doc
`
`Rev: XO
`
`topology is to offer a simple mass storage interface mode between phone
`and other MPS media players appearing as media mass storage for the
`USB host, which is reading the audio tracks in sequence. This topology
`does not require any iRadio middleware or cellular phones iRadio enabled
`to work (you could plug any media player with USB and they should
`appear as mass storage to the WACA which wouti work as the master.
`However, adding iRadio USB manager and radio command module will
`bring a fuller user experience with all the advanced services for user
`convenience synonym of iRadio service. The USB link will be equivalent
`to the multiple Bluetooth connections and could multiplex audio stream
`and command & control data...
`
`Command
`/ Control
`
`•;
`Mass storage
`Audio files
`
`;
`
`EH
`HMMg
`......
`
`I SB
`Manager.
`
`Wmm
`mm&m
`
`MtfijJjtd
`Dt'Codk'
`
`^
`X
`
`' Audio files
`
`. v-Ato
`
`I
`
`giaipgmR|||
`BfqJraialil
`
`—i
`
`•'
`
`» " .
`(....
`
`A.
`
`.Char.e'el:
`
`>
`
`Figure 4: Wired USB thin client WACA Architecture
`
`2.5 WACA #4: "Hands-Free" kit audio adaptor - Hybrid BlueTooth + USB cradle
`
`-
`
`This hybrid topology caters to the people who may need the flexibility to
`recharge their phone into the car or use the USB link with other MPS
`players while having possible Hands-free phone conversation through the
`car radio stereo. It is also perfect for the cases where the iser want to
`experience iRadio audio streaming without moving the phone out of his
`pocket.
`
`Motorola Confidential Proprietary
`
`Page 12
`
`2/11/200510/27/2001 |
`
`Page 340 of 667
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XO 102604.doc
`
`Rev: XO
`
`Hands-Free
`Microphone
`
`D-
`
`Command
`/ Control
`
`Streaming Audio
`-4
`Voice input
`
`»•
`
`•Re-charge
`•Mass storage
`server
`
`{ *"*- Stream
`f-ntodiT
`
`/'
`
`• .
`
` M i
`
`l a d d i d4 1 .
`
`
`
`UMI
`
`g1«init.tr
`
`/
`
`—•r-:-".?
`•anv
`11 Sidt-r
`
`-y*
`-f- n SB"-^.
`. M mjcer
`
`|RM|O||||
`ftWanaglg
`
`©ifeMi
`
`Mt!
`
`mmzti
`
`!ir
`
`'f.
`
`Figure 5: "Hybrid" hands-Free expandable thin client WACA Architecture
`
`2.6 WACA #5: "Thick Client" roacknap evolutions
`
`. The WACA could evolve in a more powerful "Thick client" adaptor which would
`be the 'missing Link" for mass adoption of nomadic digital players into the car
`while waiting for BlueTooth, WiFi and hard-drives / memory cards to become
`ubiquitous on the car decks themselves (jonger aftermarket and OEM lifecycle).
`It is considered "Thick" once it hosts its own memory and manages "iRadio"
`business rules for the content without a need for the phone. By providing more
`than one USB port and managing these ports, the WACA could beome a
`successful "low cost alternative" media gateway for all the legacy car decks, that
`will not yet provide digital memory and wireless interfaces.
`
`The entire iRadio middleware available in the phone can be ported into the
`WACA so that, in the advent of a WIFI direct link with the Home Gateway, the
`WACA will function as both a server and renderer roles under an UpnP AA/
`paradigm. The phone may not be needed in this picture unless it provides some
`value added services like "hot content".
`In such a ca$, the Home gateway or
`WiFI/WiMAx hot spots on the go can transfer directly the media content updates
`into the car and receive usage tracking from the WACA.
`
`Motorola Confidential Proprietary
`
`Page 13
`
`2/11/200510/27/2001 |
`
`Page 341 of 667
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XO 10260'i.doc
`
`Rev: XO
`
`Command/Control
`
`Streaming Audio
`
`•BTkey ^...
`•WiFi Key
`•Storage key
`
`ii''
`*;«BTpvlana|;er
`
`(Efe'cotiei]
`
`Car radio
`deck Bus
`
`RMJ
`M
`IsMB
`• m
`
`••••
`
`jjSl
`
`[liB!
`
`*J ""'.Lbli
`
`BpueiMieB
`
`iv'-
`
`w%
`
`hS^e'ii
`aaiimwnii
`
`[wSfKreTOKi
`
`rf"
`
`-
`
`Z^\
`
`pi^r :@i
`
`*'$t **'
`Zeevo SoC or 2 ch ps-bolutionVe!g^feR|'Broaqc:b|in..^*B|!^kf»T^^^P
`
`Figure 6: "High-End" expandable thin client WACA Architecture
`
`This approach would require a more powerful controller structure than the
`BlueTooth Zeevo system on chip may be able to provide. The BlackFin chip
`series from Analog Devices has shown tremendous computing power for very
`cost effective price. The WACA partner wll of course be influential in the
`decision of the core controller.
`
`Motorola Confidential Proprietary
`
`Page 14
`
`2/11/200510/27/2001 |
`
`Page 342 of 667
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XO 10260'1 .doc
`
`Rev: XO
`
`3 Timeline
`
`3.1
`
`iRadio timeline
`
`• iRadio is targeted for alpha release on December 31, 2004 for CES demo
`
`• iRadio Beta release on February 15, 2005: a beta release in this context is
`defined as Version 0.9:
`o Locked feature-set
`o All features implemented
`o Functionally complete
`o Operational
`• Public trials of iRadio "beta" starting on April 4, 2005 for up to 200 users
`
`• Commercial product release will commence in Q3 2005.
`The Commercial product release of iRadio 1.x will assume that the product has
`undergone and passed rigorous QA testing for functionality, stability and data
`integrity.
`
`3.2 WACA timeline
`
`. •. Car deck to RS232 + Line in adaptor- one manufacturer model: no later than
`11/22/04
`Car deck to RS232 + Line in adaptor - multi-manufacturers programmable
`model: no later than 12/1/04
`• Single board BlueTooth + car adaptor prototype (alpha): 12/15/2004
`• Single board BlueTooth + car adaptor (beta): 2/15/2005
`• Single module BlueTooth + car adaptor (pilot)- qty 200: 4/15/2005
`• Single module BlueTooth + car adaptor (production)- qty >1000/ week:
`7/1/2005
`
`Motorola Confidential Proprietary
`
`Page 15
`
`2/11/200510/27/2004 |
`
`Page 343 of 667
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XO 102604.doc
`
`Rev: XO
`
`4 Rotes & responsibilities
`
`4.1 Motorola:
`
`Motorola will provide:
`• Program contact
`• System definition leadership
`•
`iRadio middleware interface algorithm
`• Phone interface protocol
`• Integration into target phones
`
`4.2 WACA partner
`
`WACA partner will provide the integrality or a sub-function of the following list:
`
`Provides car radio adaptor interface (hardware and software)
`Provides wireless and USB interfaces (hardware & software)
`Provides hardware core reference design
`Integrates iRadio middleware with wireless and car radio adaptor
`Provide WACA kit including housing module and adaptation cable sets
`Product validation for automotive environment
`OMD high volume /Jow cost agreed manufacturing
`
`Motorola Confidential Proprietary
`
`Page 16
`
`2/11/200510/27/2001 |
`
`Page 344 of 667
`
`

`
`1
`
`2
`
`3
`
`Introduction
`1.1
`Overview
`1.2
`Phases
`1.2.1
`Demo
`1.2.2
`Trial
`1.2.3
`Product
`1.3
`Scope
`1.4
`Glossary
`System Definition
`2.1
`Structure
`2.2
`Elements
`2.2.1
`Content Provider Interface
`2.2.2
`Home Configuration PC
`2.2.3 Mobile Clients
`2.2.4
`Thin car client
`2.2.5
`Public WiFi Hot spot
`2.2.6
`Cellular data system
`2.2.7
`Internet
`2.2.8
`In-home network
`2.2.9
`Home remote control
`2.2.10 Home renderer
`2.2.11 Updating system
`2.3
`Actors
`2.3.1
`User
`2.3.2
`Friend
`System Functions
`3.1
`Content Provider Interaction
`3.1.1
`Temporary Content Provider Standiri...
`3.2
`Updating
`3.2.1
`Discovery/Authorization....
`3.2.2
`Opportunistic Updating
`3.2.3 Mobile to mobile updates...
`3.2.4
`Content license approaches
`3.2.5
`Data updated
`3.2.6
`Problem situations
`3.2.7
`Cellular data opportunities....
`3.2.8
`Hot-spot opportunities
`3.3 Mobile Communications Medium
`3.3.1
`BlueTooth/WiFi
`Thin car client (streaming from a mobile client)
`3.4
`3.4.1
`A2DP Basic
`3.4.2
`A2Dp Advanced
`3.4.3
`User Interface
`3.4.4
`Short-term approaches..
`3.5
`DRM/codecs
`3.6
`Device to Device Transitions
`
`3
`3
`3
`3
`3
`3
`3
`3
`4
`4
`4
`4
`5
`5
`5
`5
`5
`6
`6
`6
`6
`6
`6
`6
`6
`7
`7
`7
`7
`7
`8
`8
`8
`8
`Error! Bookmark not defined.
`9
`9
`9
`9
`9
`9
`Error! Bookmark not defined.
`10
`10
`10
`10
`
`Page 345 of 667
`
`

`
`Configuration
`3.7
`3.7.1
`Personal MP3 support
`3.7.2
`iRadio Purchased content support.
`3.7.3
`Content not supported
`3.7.4
`At computer user interface
`3.7.5
`Remote configuration
`3.7.6
`Transitions
`3.7.7
`Channels
`3.8
`In-home content consuption
`3.8.1 Mobile unit as an in-home remote control
`3.8.2
`UPnP
`3.8.3
`Pause/Resume
`3.9 Mobile (Personal) operations
`3.9.1
`Content consumption
`3.9.2
`Storage
`3.10 At computer content consumption
`3.10.1 At home
`3.10.2 Remote
`3.11 Home Gateway
`3.12 Usage tracking
`3.13 Alarm clock
`
`10
`10
`10
`10
`11
`11
`Error! Bookmark not defined.
`11
`11
`Error! Bookmark not defined.
`12
`12
`12
`12
`12
`12
`12
`12
`12
`12
`Error! Bookmark not defined.
`
`Page 346 of 667
`
`

`
`1 Introduction
`1.1 Overview
`The core iRadio functionality is well described in the iRadio Market Requirements Document.
`
`1.2 Phases
`
`1.2.1 Demo
`This is the CES 2005 demo. It will take place in a suite during the CES show (Jan 6- 9). It
`will demonstrate how iRadio technology will work throughout a typical user's day, from
`waking up in the morning, driving to work, going to the gym and returning home. The software
`implementing this demo will use Bluetooth for mobile client updates UPnP will be used for
`streaming content in the home.
`1.2.2 Trial
`A trial with several hundred users is planned over the course of the second quarter of 2005.
`The Trial will demonstrate seamless operation between the home and car domains. Ideally the
`Trial system will be a natural evolution of the Demo system. This evolution would include the
`implementation of missing features as well as testing and enhancements
`1.2.3 Product
`The product will incorporate improvements suggested by the trial as well as improvements
`uncovered by testing in representative user environments. In order to be on the market with a
`partner in 2005, the initial product (referred to as phase 1) will probably have the same features
`as the demo system. More advanced features will be deferred to following phases.
`
`1.3 Scope
`This document focuses on the operation of the iRadio system for the Demo and Trial.
`Functionality beyond the Demo and Trial may be identified and even described, but it is not the
`focus of this document.
`
`_
`
`1.4 Glossary
`Mobile Client
`Any iRadio enabled mobile device which is occasionally connected to either
`the home network or the Internet for updating stored content and providing
`usage data. Mobile Client can include: cell phone, car device, personal music
`player ...
`An ordered set of content. By default a playlist would cause the content to be
`played in sequential order. There might also be a way to randomize the playlist
`(or playing of it) so that the original order is not apparent. On mobile client, a
`playlist may only be partially resident on a device.
`
`Playlist
`
`Page 347 of 667
`
`

`
`Light-weight
`updating
`Bulk Content
`
`The exchange of relatively small amounts of data which does not include bulk
`content
`Actual audio or video content which involves large amounts of data.
`
`2 System Definition
`2.1 Structure
`SYSTEM DIAGRAM GOES HERE
`
`2.2 Elements
`2.2.1 Content Provider Interface
`The content provider is not part of the iRadio system. This interface encompasses all
`communication with the content provider. At its simplest, the content provider will provide
`playlists (genre channels, user custom channels, and the bulk content associated with those
`Playlists). The iRadio Server provides user consumption and rating information. Additionally,
`the content provider interface handles the user's purchase of individual pieces of content.
`There is nothing in the system which limits the number content providers which could be
`supported.
`2.2.2 iRadio system
`The iRadio Server and the Home Gateway work together to implement the core of the iRadio
`system. The exact division of responsibilities between the two elements will be decided later
`and is often unimportant when trying to understand how the system works as a whole.
`
`2.2.2.1 iRadio Server
`This is the central content aggregation point for the iRadio system. It communicates with
`the content providers and passes the information on to the rest of the system. Although the
`Home Gateway is typically in the communications path with mobile devices, the iRadio
`Server can communicate directly with mobile devices via public WiFi access points or via
`the cellular system.
`
`2.2.2.2 Home Gateway
`The Home Gateway software runs on the user's home PC or on a dedicated in-home media
`server (MS 1000). iRadio content is cached on the Home Gateway before it is played in the
`home via UPnP A/V or preemptively transferred to Mobile iRadio Clients which can
`connect to the Home Gateway via the home network. The Home Gateway functionality has
`no need for a user interface and no user interface is planned.
`
`Page 348 of 667
`
`

`
`2.2.3 Home Configuration PC
`Although the user may use the same PC for the Home Gateway as they use for configuring the
`iRadio, these are two different roles and are called out separately. The most extreme case for
`the Configuration PC being separate from the Home Gateway is when the Home gateway is a
`MS 1000.
`2.2.4 Mobile Clients
`Mobile Clients are any iRadio enabled mobile devices which occasionally connect to either the
`home network or the Internet for updating stored content and providing usage data. For the
`Demo and Trial phases, cell phones are the only Mobile Client In later phases it could be a car
`device can or personal music player.
`
`2.2.4.1 Phone client
`The phone is running either native or Java iRadio software which controls all iRadio
`functions. This software must run continuously, not just when the user is listening to
`content on the phone. Running in the background, the software takes care of updating the
`phone and the rest of the iRadio system so that content is always up-to-date. There are no
`specific plans to use cellular data communications for any updating, but that remains a
`possibility.
`
`2.2.4.2 Car client (thick)
`An iRadio in-car unit with content storage and WiFi support interacts with the iRadio
`system the same as any other mobile client. The in-car unit could be integrated into a radio,
`Telematics Control Unit or installed as an after-market unit via the CD changer interface.
`
`2.2.5 Thin Car Client
`The Thin Car Client has no memory of its own. If allows content to be streamed to it from
`personal device carried by someone in the car via Bluetooth or WiFi. Additionally the in-car
`audio control actuations are sent to the source of the stream so that the driver can easily control
`the content.
`2.2.6 Public WiFi Hot spot
`Not part of the Demo or Trial system, a public WiFi hot-spot allows mobile devices to updated
`content directly from the iRadio Server. In early phases this updating will not include a user's
`personal audio files which were not purchased through the iRadio system. WiFi access points
`which require the user to enter encryption information will not be supported. Configuration of
`acceptable WiFi access points will be possible to limit connections.
`
`2.2.7 Cellular data system
`Not part of the Demo or Trial system, a mobile client capable of cellular data connections could
`use these connections for partial updates at minimal cost. Full updates would be cost
`prohibitive.
`
`Page 349 of 667
`
`

`
`2.2.8 Internet
`The Internet is used to connect the iRadio Server to the Home Gateway and in the future,
`directly to mobile clients via a public WiFi access point or via cellular data connection.
`
`2.2.9 In-home network
`The two responsibilities of the home network are to support the streaming of content for in-
`home consumption and to facilitate updating of mobile clients. These two responsibilities could
`be addressed by different in-home networks as long as they are both supported by the Home
`Gateway.
`
`2.2.9.1 UPnP
`UPnP A/V facilitates the streaming of content within a small network. This is the chosen
`approach for the consumption of content in the home for the Demo and Trial.
`
`2.2.9.2 Mobile connection
`In the short term, Mobile Clients will be updated over WiFi or Bluetooth, any reasonably
`high speed network would also work. For the Demo and Trial, Bluetooth will be the
`
`Home remote control
`2.2.10
`For the Demo and Trial it is assumed that the personal mobile device will also act as the user's
`remote control in the home for iRadio content consumption. This will use a Bluetooth link
`back to the Home Gateway which will participate in the UPnP network on the remote's behalf.
`
`Home renderer
`2.2.11
`. This is the end point where streamed content in the home is converted to analog for presentation
`to the user. For UPnP there are several commercially available audio rendering devices.
`
`Updating system
`2.2.12
`The updating system is the differentiating technology of the iRadio system which allows
`multiple devices/domains to keep in sysnc regarding what the user has listened to, is listening
`to, and is expected to listen to in the future.
`
`2.3 Actors
`2.3.1 User
`This is the person who uses the iRadio system in the various domains and for various purposes.
`
`2.3.2 Phone Friend
`For scenarios and which involve receiving a phone call, this would be the person who phones
`the user.
`.
`
`Page 350 of 667
`
`

`
`3 System Functions
`
`3.1 Content Provider Interaction
`The iRadio relies on content providers for providing all the content which the user didn't already
`own. Content Providers would initially provide genre playlists, celebrity playlists, and content
`purchase. The iRadio system would provide content consumption information through this
`interface also. This interface would be widened as needed to cover billing and community services
`as needed.
`The connection between the iRadio Server and the Content Provider would be over a dedicated
`private connection or a VPN for privacy and security. Considering the large amounts of
`information which may be crossing between the iRadio server and the Content Provider, they need
`a high capacity connection.
`
`3.1.1 Temporary Content Provider Standin
`For Demo, there will not really be a Content Provider. The content will either be faked on the
`iRadio server or a simple Content Provider stub could be created. The stub would use HTTP
`for all communications. Most of the genre playlists, celebrity playlists, and purchase
`interactions could be done via XML (or even SOAP). Bulk content transfers don't benefit from
`XML or SOAP, so those would be transferred one at a time using plain HTTP GET requests.
`
`3.2 Updating
`Updating occurs between all the major elements of the iRadio system (iRadio Server, Home
`Gateway and Mobile Clients) and is the main enabler of the iRadio features.
`
`3.2.1 Discovery/Authorization
`Each element of the iRadio system has a list of users which it supports. A Mobile Client will
`likely have only one person in the user list. The iRadio server could have millions of users.
`The initial handshake between to iRadio elements is used to determine whether the two
`elements have any users in common. If they have users in common, then the interchange
`proceeds to determine what information needs to be updated.
`Discovery occurs amongst Mobile clients and the Home Gateway. Communications with the
`iRadio server is established via a known URL rather than discovery.
`The following stages occur:
`• Discovery: Receive initial inquiry or response associated with actual discovery of an
`iRadio enabled device
`• Authentication: Exchange supported user's information to see if there are users in
`common.
`• Add to registry: The discovered and authenticated device is placed in a registry of
`devices available for updating.
`• Updating: Immediately after addition to the registry updating occurs. Updating also
`occurs as needed so long as the device remains in the registry.
`• Remove from registry: When it is determined that a device in the registry can no
`longer be reached, then it is removed from the registry.
`For devices designed to connect to the iRadio Server, in parallel with the discovery of devices
`in the immediate proximity, there is also an effort to form a connection to the iRadio Server.
`
`Page 351 of 667
`
`

`
`3.2.2 Data updated
`The following relatively small types of data are sent from the mobile client during updating:
`• Content Status Changes: Playing, Stopped, Paused, Resumed, Skipped. Where
`appropriate, this includes play-point information.
`• Rating: This the user's rating of the content and contains a content identifier, and both
`the change in rating and the new rating value.
`• Purchase Request: This contains a content identifier.
`• Key Press: For diagnostic purposes and user interaction studies, each key press is
`captured.
`Each piece of data above is time stamped (UTC timezone and local offset). The Content Status
`Changes and Ratings are of general interest to all elements using the updating system. The
`Purchase Request and Key Press information is only of interest to the iRadio Server although it
`may be forwarded through other elements.
`Updating also involves sending the following data to the mobile client:
`• Playlists/Daily Set descriptions: These are user specific content descriptions which do
`not include the actual bulk content.
`• Bulk Content The large pieces of data which is the audio or video data.
`• User configuration/Preferences: TBD
`
`3.2.3 Opportunistic Updating
`Because proximity network connections are transient, updating occurs whenever there is the
`opportunity to do so. This accommodates situations where the user rapidly changes from one
`domain to another and the seamless experience must be maintained.
`
`3.2.4 Mobile to mobile updates
`Jhe current Demo and Trial plans call for each user to have only one Mobile Client so mobile
`to mobile updating can never occur. During the Demo and Trial, the Mobile Client will update
`with the Home Gateway (or possibly the iRadio Server) directly.
`In situations where a user does have multiple mobile clients, most updating will occur at home
`directly with the Home Gateway, but there are cases where an automotive mobile client might
`never connect to the home network if the user lives in an apartment building. In these cases
`updating between mobiles is used to bridge this gap. A personal mobile client would
`periodically update information with the Home Gateway and the automotive mobile client.
`