`
`page 496 of1082
`
`Jnteroperabflfty Requirements for Biue-tooth as a WAP Bearer
`
`uetooth-
`
`29 November 1999
`
`AFFLT0293724
`
`Samsung Ex. 1019 p. 496
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 497 of 1082
`
`Inreroperabiffljx Requirements for Biuetooth as a WAP Bearer
`
`uetouth.
`
`CONTENTS
`
`immsziuction ..................................................................................... "$99
`
`1.’! Documantficope
`
`The Use sf WA?’ in the Eiuatouth Environment .......................... "599
`
`2.1
`
`2.2
`
`‘JaIue—.a:*£dedServices..............................................................5OG
`
`Usage: Cases
`
`2.2.2 Fhrbidden
`2.2.3 WAP Smart Kiosk ...................................................... .59!
`
`Wk? Services Gvrewiew ................................................................ ".552
`
`3.‘?
`
`‘1s’*JAP §':".r':iiiia-‘BS ..........................................................................
`3.3.1
`“.:"J'.«5.F* Ciieni ................................................................ ..5{}2
`
`3.3.2 WAF3 §’rc»xyfGateway ................................................. .1393
`13-.’§.3
`\.;‘.*‘.£‘sP Server ...............................................................
`
`WA?“ é”->ram>r;9Es ....................................................................... . .503
`
`3.2.‘: Wireless: Datagrarn F‘a'o?ocr;i (W'CJP} .......................... ..504
`
`3.2.2 Wéreaiess Transaction Protocoi {WT§=‘)
`
`.
`
`......5£}-«3
`
`3.2.3 Wireiess ?ra:“=:=..;302"3; §..aye.=r Se.-*.".=.;rit3,«' {‘v‘~.r‘TL8}
`
`3.2.4 Wireiess Session £'~=mé.acoi‘
`
`Coratrasténg WAP amt; interwar: F>ro:;:3cr.>!s ...............................
`3.3.1
`Ui":>P.=’WE3F’ ................................................................. ..
`
`9*’ .9-3 M
`
`$1-7f:}.r-_....\§-'§'_,.\§
`
`F»'~5$*’1’~*’1'~*3‘
`
`<$3<.)‘=.-ii-"
`
`WTP.F‘f*C1P .................................................................. ..
`
`WT2..$.=‘SSL ................................................................. ..
`
`WSF’:‘1~iTTP ................................................................ ..
`
`i;‘.’fz;‘i{.I'£—~E'E'¥v‘;E_ ............................................................... ..
`
`WMLSc:'i;:t.*‘Ja\-'35“-:<;rig3i. ............................................... ..
`
`.
`
`.
`
`.
`
`'
`
`-
`
`-
`
`‘
`
`'
`
`29 November 1999
`
`AFFLT0293725
`
`Samsung Ex. 1019 p. 497
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Interoperabiffty Requirements for Biue-tooth as a WAP Bearer
`
`page 498 of 1082
`
`Bluetonth.
`
`é
`
`WA? in the Biuetaeth Féconet ...................................................... "585
`
`an
`
`‘WA? Server Commzmicatioma ......................... ..
`
`4.1.1
`
`inétéation by the Céiant
`
`4-.1.‘i.1 Discovea"yo:'ServEces ........... ..
`"i'ern1inaiion bythe Ciient
`
`4.1.2
`
`.................... "598
`.506
`
`..................... . 50?’
`E30"?
`
`4.1.3
`
`initéaticm by the Server Device
`
`E30"?
`
`4.1.3.1 Discoveryof
`.................... .. 558
`inxgmameratatiozu of WA? fez‘ Biuemoth .............. ..
`................... ..5{3E3
`4.2. ‘E
`‘uifffi?’ ?-fianagemesut Entity ..................... ..
`
`4.2.1.1 Asynchronous Neiifications
`4.2.1.2 Aitemate
`
`. 5G8
`538
`
`4.2.2 Addressing .......................................... ..
`
`....................
`
`451.3
`
`Network Su;Jp0rt'1:rWAP ................................ ..
`4.3.1
`
`.................... ..5{3Q
`509
`
`iniemperabiiity Fiequirememzs. ...................................................... .. 511
`5.1
`Siege 1 — Basia: !n?erc:;3erai*.-iiitg.-' ....................... .. .................... “$311
`Stage 2
`1’-\ci~.ranc:eci interogaerabéiiiy ...................................... .. 511
`
`5.2
`
`$awice fliscuvery .......................................................................... ..5?2
`512
`£13.?
`SUP Service Recmds
`$3.2
`
`SEEP Frotuczai Data Units
`
`SM
`
`6.3
`
`Servicze discovery ;3rc.=r:=:-adure
`
`534
`
`Refarentxes ...................................................................................... .. 5'3 5
`
`29 November 1999
`
`AFFLTD293726
`
`Samsung Ex. 1019 p. 498
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 499 of 1082
`
`interoperabifiry Requirements for Biuetooth as a WAP Bearer
`
`uetooth.
`
`1
`
`INTRODUCTION
`
`1.1 DOCUMENT SCOPE
`
`This document is intended for Bluetooth implementers who wish to take advan-
`tage of the dynamic, ad-hoc characteristics of the Bluetooth environment in
`providing access to value-added sewices using the WAP environment and pro-
`toools.
`
`Bluetooth provides the physical medium and link control for communications
`between WAP client and server. This document describes how PPP may be
`used to achieve this communication.
`
`The information contained in this document is not sufficient to allow the imple-
`mentation of a generat-purpose WAP ciient or server device. Instead, this doc-
`ument provides the following information:
`
`- An overview of the use of WAP in the Bluetooth environment will explain
`how the concept of value-added services fits within the Bluetooth vision.
`Examples are given of how the WAP value-added services model can be
`used to fulfil specific Bluetooth usage models.
`
`The WAP Services Overview attempts to place the WAP environment in a
`familiar context. Each component of WAP is introduced, and is contrasted
`with equivalent Internet protocols (where applicable).
`
`A discussion of WAP in the Bluetooth Piconet describes how the particular
`structure of Bluetooth communications relates to WAP behaviors.
`
`Finally. the Interoperability Requirements describe the specific Bluetooth
`features that must be implemented in order to ensure interoperability
`between any two WAP enabled Bluetooth devices.
`
`29 November 1999
`
`AFFLT0293727
`
`Samsung Ex. 1019 p. 499
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`interoperabiiity Requirements for Biueioofh as a WAP Bearer
`
`page 500 of 1082
`
`Bluetooth-
`
`2 THE USE OF WAP IN THE BLUETOOTH ENVIRONMENT
`
`2.1 VALUE-ADDED SERVICES
`
`The presence of communications capabilities in a device is unlikely to be an
`end in itself. The end users are generally not as interested in the technology as
`in what the technology allows them to do.
`
`Traditional telecommunications relies on voice communications as the single
`application of the technology, and this approach has been successful in the
`marketplace. As data communications services have become more widely
`available, there is increasing pressure to provide services that take advantage
`of those data capabilities.
`
`The Wireless Application Protocol Forum was formed to create a standards-
`based framework, in which value-added data services can be deployed, ensur-
`ing some degree of interoperability.
`
`2.2 USAGE CASES
`
`The unique quality of Bluetooth, for the purposes of delivering value-added ser-
`vices, is the limited range of the communications link. Devices that incorporate
`Bluetooth are ideally suited for the receipt of location-dependent services. The
`following are examples of how the WAP ciient 1’ server mode! can be applied to
`Bluetooth usage cases.
`
`2.2.1 Briefcase Trick
`
`Figure 2.1: The ‘Briefcase Trick‘ Hidden Computing Scenario
`
`The Briefcase Trick usage case allows the user’s laptop and mobile phone to
`communicate, without user intervention, in order to update the user's e-maii.
`The user can review the received messages from the handset, all without
`removing the laptop from its storage in a briefcase.
`
`29 November 1999 The Use of WAP In the Bluetoolh Environment
`
`AFFLT0293'/28
`
`Samsung Ex. 1019 p. 500
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`interoperabiiity Requirements for Biuetooth as a WAP Bearer
`
`page 501 of 1082
`
`Bluetooth.
`
`2.2.2 Forbidden Message
`
`Figure 2.2: The ‘Forbidden Message’ Hidden Computing Scenario
`
`The Forbidden Message usage case is similar to the briefcase trick. The user
`can compose messages in an environment where no dial-up connection is pos-
`sible. At a later time the laptop wakes up, and checks the mobile phone to see
`if it is possible to send the pending messages. If the communications link is
`present, then the mail is transmitted.
`
`2.2.3 WAP Smart Kiosk
`
`The WAP Smart Kiosk usage case allows a user to connect a mobile PC or
`handheld device to communicate with a kiosk in a public location. The kiosk
`can provide information to the device that is specific to the user's location. For
`exampie, information on flights and gates in an airport, store locations in a
`shopping centre. or train schedules or destination information on a railway plat-
`form.
`
`The Use of WAP In the Bluetoolh Environment
`
`29 November 1999
`
`AFFLT0293729
`
`Samsung Ex. 1019 p. 501
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`interoperability Requirements for Blue-tooth as a WAP Bearer
`
`page 502 of 1082
`
`Bluetooth-
`
`3 WAP SERVICES OVERVIEW
`
`The Wireless Application Protocol is designed to provide Internet and Internet-
`like access to devices that are constrained in one or more ways. Limited com-
`munications bandwidth. memory, processing power, display capabilities and
`input devices are all factors driving the development of WAP. Although some
`devices may only exhibit some of the above constraints, WAP can still provide
`substantial benefit for those devices as well.
`
`The WAP environment typically consists of three types of device: the WAP Cli-
`ent device. the WAP Proxylgateway and WAP Server. In some cases the WAP
`Proxyfgateway may also include the server functionality.
`
`WAP Client
`
`Base Station WAP Server.-‘Proxy
`
`Figure 3. 1: Typical WAP Environment
`
`3.1 WAP ENTITIES
`
`3.1.1 WAP Client
`
`The WAP Client device is usually found in the hands of the end user. This
`device can be as powerful as a portable computer, or as compact as a mobile
`phone. The essential feature of the client is the presence of some type of dis-
`play and some type of input device.
`
`The WAP Client is typically connected to a WAP Proxyigateway through a wire-
`less network. (Figure
`on page 503) This network may be based on any
`available technology. The WAP protocols allow the network to exhibit low reli-
`ability and high latency without interruption in service.
`
`29 November 1999
`
`WAP Services Overview
`
`AFFLT0293730
`
`Samsung Ex. 1019 p. 502
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 503 of 1082
`
`interoperability Requirements for Bluetooth as a WAP Bearer
`
`uetooth.
`
`3.1.2 WAP Proxyi‘Gateway
`
`The WAP Proxyigateway acts as an interface between the wireless network,
`and the larger Internet. The primary functions of the proxy are to provide DNS
`name resolution services to WAP ciient devices and transiation of Internet pro-
`tocols and content formats to their WAP equivalents.
`
`3.1.3 WAP Server
`
`The WAP Server performs a function that is similar to a server in the Internet
`world. In fact. the WAF’ server is often an HTTP server. The server exists as a
`
`storage location for information that the user can access. This ‘content’ may
`include text, graphics, and even scripts that allow the client device to perform
`processing on behalf of the server.
`
`The WAP Server logic may exist on the same physical device as the Proxy.’
`gateway, or it may reside anywhere in the network that is reachable from the
`Proxyigateway.
`
`The server may fill the role of an HTTP server, a WSP server, or both.
`
`3.2 WAP PROTOCOLS
`
`The WAP environment consists of a layered protocol stack that is used to iso-
`late the user agents from the details of the communications network. Figisre «3.1
`on page fitit‘; illustrates the general architecture of the WAP protocol stack.
`Bluetooth will provide an additional data bearer service, appearing at the bot-
`tom of this diagram.
`
`.
`
`.
`
`._..E .....:..__ _E _.:_.
`
`.
`
`.
`
`other Services and
`Mnlications
`
`Beams:
`|os!.I
`
`as-136
`
`IW°Pi
`
`Té-#6:?-:=%¥%“= -';'?‘.1'=
`\ .\. ..\..
`..,\.
`..
`com Pl-IS
`
`cow PDC—P |
`
`Figure 3.2: WAP Protocol Stack
`
`WAP Services Overview
`
`29 November 1999
`
`E:
`iDI'-.‘N | max ||stc... E?
`
`AFFLT0293731
`
`Samsung Ex. 1019 p. 503
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`interoperabiiity Requirements for Biuetoofh as a WAP Bearer
`
`page 504 of 1082
`
`Bluetooth-
`
`3.2.1 Wireless Datagram Protocol (WDP)
`
`The WDP layer provides a service interface that behaves as a socket-based
`UDP implementation. For a bearer service based on IP, then this layer is UDP.
`For bearer which do not provide a UDP service interface, then an implementa-
`tion of WDP must be provided to act as an adaptation layer to allow socket-
`based UDP datagrams over the native bearer.
`
`3.2.2 Wireless Transaction Protocol (WTP)
`
`The WTP layer provides a reliable datagram service on top of the WDP (U DP)
`layer below.
`
`3.2.3 Wireless Transport Layer Security (WTLS)
`
`The WTLS layer is an optional component of the protocol stack that provides a
`secure data pipe between a client WSP session and its peer server WSP ses-
`sion. In the current version of the WAP specification, this session will terminate
`at the WAP server. There is currently a proposal before the WAP Forum for a
`proxy protocol, which will allow the intermediate WAP proxy to pass WTLS traf-
`fic across the proxyigateway without decrypting the data stream.
`
`3.2.4 Wireless Session Protocol (WSP)
`
`The WSP layer establishes a relationship between the client application. and
`the WAP server. This session is relatively long-lived and able to survive service
`interruptions. The WSP uses the services of the WTP for reliable transport to
`the destination proxyigateway.
`
`3.3 CONTRASTING WAP AND INTERNET PROTOCOLS
`
`The intent and implementation of the WAP protocol stack has many parallels
`with those of the Internet Engineering Task Force (IETF). The primary objective
`of the WAP Forum has been to make Internet content available to devices that
`
`are constrained in ways that make Internet protocols unsuitable for deploy-
`ment.
`
`This section compares the roles of the WAP protocol stack‘s layers with those
`of the IETF.
`
`3.3.1 UDPIWDP
`
`At the most basic layer, WAP and lntemet protocols are the same. The WAP
`stack uses the model of a socket-based datagram (UDP) service as its trans-
`port interface.
`
`Some Internet protocols also use the UDP service, but most actually use a
`connection-oriented stream protocol (TCP).
`
`29 November 1999
`
`WAP Services Overview
`
`AFFLT0293732
`
`Samsung Ex. 1019 p. 504
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 505 of 1082
`
`interoperabiifly Requirements for Biuetooth as a WAP Bearer
`
`uetooth.
`
`3.3.2 WTPITCP
`
`The wireless transport protocol (WTP) provides services that, in some
`respects, fill the same requirements as TCP. The Internet Transmission Control
`Protocol (TCP) provides a reliable, connection-oriented, character-stream
`protocol that is based on IP services. In contrast, WTP provides both reliable
`and unreliable, one-way and reliable two-way message transports. The trans-
`port is optimized for WAP’s ‘short request, long response’ dialogue characteris-
`tic. WTP also provides message concatenation to reduce the number of
`messages transferred.
`
`3.3.3 WTLSISSL
`
`The Wireless Transport Layer Security (WTLS) is derived from the Secure
`Sockets Layer (SSL) specification. As such, it performs the same authentica-
`tion and encryption services as SSL.
`
`3.3.4 WSPIHTTP
`
`Session services in WAP are provided by the Wireless Session Protocol
`(WSP). This protocol incorporates the semantics and functionality of HTTP 1.1,
`while adding support for long-lived sessions, data push, suspend and resume.
`Additionally, the protocol uses compact encoding methods to adapt to narrow-
`band communications channels.
`
`3.3.5 WMUHTML
`
`The markup language used by WAP is a compact implementation that is simi-
`lar to HTML, but optimized for use in hand-held devices. WML is an XML-
`defined markup language.
`
`3.3.6 WMLScripti'JavaScript
`
`WAP also incorporates a scripting language that is similar to JavaScript, but
`adapted to the types of constrained devices that WAP is targeted for.
`
`WAP Services Overview
`
`29 November 1999
`
`AFFLT0293733
`
`Samsung Ex. 1019 p. 505
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`interoperabiiity Requirements for Biuefoorh as a WAP Bearer
`
`page 506 of 1082
`
`Bluetooth.
`
`4 WAP IN THE BLUETOOTH PICONET
`
`In many ways, Bluetooth can be used like other wireless networks with regard
`to WAP. Bluetooth can be used to provide a bearer for transporting data
`between the WAP Client and its adjacent WAP Server.
`
`Additionally, B|uetooth’s ad hoc nature provides capabilities that are exploited
`uniquely by the WAP protocols.
`
`4.1 WAP SERVER COMMUNICATIONS
`
`The traditional form of WAP communications involves a client device that com-
`
`municates with a Serverl’Proxy device using the WAP protocols. In this case
`the Bluetooth medium is expected to provide a bearer service as specified by
`the WAP architecture.
`
`4.1.1 Initiation by the Client Device
`
`When a WAP client is actively ‘listening’ for available Bluetooth devices, it can
`discover the presence of a WAP server using B|uetooth's Service Discovery
`Protocol.
`
`WAP Proxy
`I Gateway
`
`Figure 4. 1: WAP Server / Proxy in Piconet
`
`In Pigure dist, stage 1 the WAP Client device is moving into range of the WAP
`Proxyigateway's piconet. When the client detects the presence of the WAP
`proxyigateway, it can automatically, or at the client's request, connect to the
`server.
`
`29 November 1999
`
`WAP in the Bluetooth Pioonet
`
`AFFLT0293734
`
`Samsung Ex. 1019 p. 506
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 507 of 1082
`
`interoperability Requirements for Bluetooth as a WAP Bearer
`
`uetooth.
`
`4. 1.1. 1 Disco very of Services
`
`The client must be able to determine the specific nature of the WAP proxy!
`gateway that it has detected. It is expected that the Bluetooth Service Discov-
`ery Protocol will be used to learn the following information about the server:
`
`- Server Name — this is a user readable descriptive name for the server.
`
`- Server Home Page Document Name — this is the home page URL for the
`server. This is optional.
`
`Server!Proxy Capability — indicates if the device is a WAP content server, a
`Proxy or both. If the device is a Proxy, it must be able to resolve URLs that
`are not local to the Server!Proxy device.
`
`In Figgtira 4:32, stage 2, the device is communicating with the WAP proxyigate—
`way. All WAP data services normally available are possible.
`
`4.1.2 Termination by the Client Device
`
`In i5=ig_;1.ir-:-3 4.1, stage 3. the device is exiting the piconet. When the device
`detects that communication has been lost with the WAP proxylgateway, it may
`optionally decide to resume communications using the information obtained at
`discovery.
`
`For example, a client device that supports alternate bearers may query the
`alternate address information of the server when that capability is indicated.
`The information should be cached for later access because the client device
`
`may leave the piconet at any time, and that information will no longer be avail-
`able.
`
`In the WAP Smart Kiosk example above, if the user wishes to continue
`receiving information while out of Bluetooth range, the Kiosk would provide an
`Internet address to the client device. When Btuetooth communications are not
`
`possible. the device could use cellular packet data to resume the client-server
`SBSSIOFI.
`
`This capability is impiementation-dependent, and is provided here for illustra-
`tive purposes only.
`
`4.1.3 Initiation by the Server Device
`
`An alternative method of initiating communications between a client and server
`is for the server to periodically check for available client devices. When the
`server device discovers a client that indicates that it has WAP Client capability,
`the server may optionally connect and push data to the client.
`
`The client device has the option of ignoring pushed data at the end user’s dis-
`cretion.
`
`WAP in the Bluetooth Piconet
`
`29 November 1999
`
`AFFLT0293735
`
`Samsung Ex. 1019 p. 507
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`interoperabiiity Requirements for Biue-tooth as a WAP Bearer
`
`page 508 of 1082
`
`Bluetooth-
`
`4 . 1'. 3.1 Discovery of Services
`
`Through the Bluetooth Service Discovery Protocol, the server can determine
`the following information about the client:
`
`' Client Name — this is a friendly format name that describes the client device
`
`- Client capabilities — this information allows the server to determine basic
`information regarding the client's Bluetooth-specific capabilities
`
`4.2 IMPLEMENTATION OF WAP FOR BLUETOOTH
`
`In order to effectively implement support for WAP over Bluetooth, certain capa-
`bilities must be considered.
`
`4.2.1 WDP Management Entity
`
`Associated with an instance of the WDP layer in the WAP Protocol Stack is an
`entity that is responsible for managing the services provided by that layer. The
`WDP Management Entity (WDP-ME) acts as an out-of-band mechanism for
`controlling the protocol stack.
`
`4.2.1.1 Asynchronous Notifications
`
`The WDP-ME will need to be able to generate asynchronous notifications to
`the application layer when certain events occur. Example notifications are:
`
`- New Client Node Detected
`
`- New Server Node Detected
`
`' Client Node Signal Lost
`
`- Server Node Signal Lost
`
`- Server Push Detected (detected as unsolicited content)
`
`Platform support for these events is implementation-specific. All of the listed
`events may be derived through the Bluetooth Host Controller Interface
`(page 51?), with the exception of Server Push.
`
`4.2.1.2 Aiternate Bearers
`
`An implementation of WAP on a particular device may choose to support multi~
`ple bearers. Methods of performing bearer selection are beyond the scope of
`this document. The procedure to be followed is implementation-dependent.
`See F‘.-tactics 4.'§..’:‘: above.
`
`29 November 1999
`
`WAP in the Bluetooth Pioonet
`
`AFFLT0293736
`
`Samsung Ex. 1019 p. 508
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 509 of 1082
`
`lnteroperabifity Requirements for Bluetooth as a WAP Bearer
`
`uetooth.
`
`4.2.2 Addressing
`
`Two basic types of addressing are being used in the WAP environment: User
`Addressing and Proxyfgateway Addressing. User addressing describes the
`location of objects within the network, and is independent of the underlying
`bearer. Proxyi'Gateway Addressing describes the location of the WAP proxy!
`gateway that the device is communicating with. Proxyi'Gateway addressing is
`dependent on the bearer type.
`
`The end user deals mainly with Uniform Resource Locators (URL). These
`addresses are text strings that describe the document that is being accessed.
`Typically, the Proxyigateway in conjunction with Internet Domain Name.
`
`Servers resolve these strings into network addresses.
`
`The address of the WAP Proxyigateway is usually a static value that is config-
`ured by the user or network operator. When the user enters a URL, the request
`is forwarded to the configured WAP proxyigateway. If the URL is within the
`domain of a co-located server. then it indicates that the document is actually
`WAP content. If the URL is outside of the WAP proxyi'gateway’s domain, then
`the WAP Proxyigateway typically uses DNS name resolution to determine the
`H3 address of the server on which the document resides.
`
`The client device would first identify a proxyigateway that is reachable through
`Bluetooth, then it would use the service discovery protocol to present the user
`with a server name or description. When the user selects a server, then the
`WAP client downloads the home page of the server (as determined by the dis»-
`covery process; see section 4.1.1.? on page 559'?) Once the user has navigated
`to the home page of the desired server, then all subsequent URLs are relative
`to this home page. This scenario presumes that the WAP Proxyigateway and
`WAP Content server are all co-located in the Bluetooth device, although this
`structure is not required for interoperability.
`
`A WAP Proxyigatewayiserver will typically provide a default URL containing
`the home page content for the server. A proxy-only device typically provides no
`URL or associated content.
`
`4.3 NETWORK SUPPORT FOR WAP
`
`The following specifies a protocol stack, which may be used below the WAP
`components. Support for other protocol stack configurations is optional, and
`must be indicated through the Bluetooth Service Discovery Protocol.
`
`4.3.1 PPPIRFCOMM
`
`Devices that support Bluetooth as a bearer for WAP services using PPP pro-
`vide the following protocol stack support:
`
`WAP in the Bluetooth Piconet
`
`29 November 1999
`
`AFFLT0293737
`
`Samsung Ex. 1019 p. 509
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`interoperability Requirements for Bluetooth as a WAP Bearer
`
`page 510 of1082
`
`Bluetooth-
`
`RFCOMM
`
`RFCOMM
`
`Figure 4.2.’ Protocol Support for WAP
`
`For the purposes of interoperability, this document assumes that a WAP client
`conforms to the role of Data Terminal as defined in LAN Access Profile using
`PPP £8}. Additionally, the WAP server or proxy device is assumed to conform to
`the role of the LAN Access Point defined in {$3}.
`
`The Baseband (page 323), LMP (page 185) and LZCAP (page 245) are the OSI
`layer 1 and 2 Bluetooth protocols. RFCOMM
`35:35) is the Bluetooth adap-
`tation of GSM TS 07.10 {#1. SDP (page 323) is the Bluetooth Service Discovery
`Protocol.
`
`PPP is the IETF Point-to-Point Protocol E33. WAP is the Wireless Application
`Protocol stack and application environment
`
`29 November 1999
`
`WAP in the Bluetooth Pioonel
`
`AFFLT0293'/38
`
`Samsung Ex. 1019 p. 510
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 511 of 1082
`
`interoperabiifly Requirements for Biuetooth as a WAP Bearer
`
`uetooth.
`
`5 INTEROPERABILITY REQUIREMENTS
`
`5.1 STAGE 1 — BASIC INTEROPERABILITY
`
`Stage 1 interoperability for WAP over Bluetooth (all mandatory):
`
`- Provide WAP Class A device compliance £7’:
`
`- Provide, through service discovery mechanisms, the network address for
`devices that support WAP proxyigateway functionality.
`
`5.2 STAGE 2 — ADVANCED INTEROPERABILITY
`
`Stage 2 interoperability for WAP over Bluetooth (mandatory):
`
`- All Stage 1 interoperability requirements are supported
`
`- Provide Server Name and information about Server.’Proxy capabilities
`through service discovery.
`
`Provide Client Name and information about Client Capabilities through ser-
`vice discovery.
`
`Asynchronous Notifications for Server.
`
`Asynchronous Notifications for Client.
`
`Interoperability Requirements
`
`29 November 1999
`
`AFFLT0293739
`
`Samsung Ex. 1019 p. 511
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`interoperabiiity Requirements for Biuefoofh as a WAP Bearer
`
`page 512 of1082
`
`Bluetooth.
`
`6 SERVICE DISCOVERY
`
`6.1 SDP SERVICE RECORDS
`
`Service records are provided as a mechanism through which WAP client
`devices and proxyigateways become aware of each other dynamically. This
`usage differs from other WAP bearers in that the relationship between the two
`devices will be transitory. That is, a Bluetooth device will not have a bearer-
`specific address configured or provisioned to a specific proxyigateway.
`
`Clients and proxyfgateways become aware of each other as they come in prox-
`imity of one another. The Bluetooth Service Discovery Protocol allows the
`devices to query the capabilities of each other as listed in the Interoperability
`Requirements section of this document.
`
`‘facts 5.‘: shows the service record for the WAP Proxyfgateway device.
`
`Definition
`
`Ser\riceC|asslDList
`
`ServiceC|assU
`
`WAP ProxyiGateway
`
`Bluetooth Profi le
`Descriptorust
`
`ProfileDescriptorO
`
`Profile
`
`Version
`
`Protocol
`Descriptorust
`
`Supported Profile
`
`Profile Version
`
`LANAccess
`Usingppp W
`
`(varies)
`
`Descriptorfl
`
`UDP
`
`UDP
`
`Parametero
`
`WSP Conneclionless
`Session Port No.
`
`9200 (default)
`
`Paramete-r1
`
`WTP Session Port No.
`
`9201 (defauiij
`
`Parameterz
`
`Parameter3
`
`WSP Secure Connec-
`lionless Port No.
`
`WTP Secure Session
`Port No
`
`Parameters‘-I
`
`WAP vCard Port No.
`
`Parameter5
`
`Parameter6
`
`Parameter?
`
`WAP vCai Port No.
`
`WAP vCard Secure
`Port No_
`
`WAP vCal Secure
`Port No.
`
`9202 (defaufl)
`
`9203 (defauit)
`
`9204 (defauir)
`
`9205 (default!)
`
`9206 (defauitj
`
`9207 (default!)
`
`Table 6.1: Service Record format for WAP Proxy/Ga tevvay devices
`
`29 November 1999
`
`Service Discovery
`
`AFFLT0293740
`
`Samsung Ex. 1019 p. 512
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 513 of 1082
`
`interoperabiiiiy Requirements for Biuetooth as a WAP Bearer
`i"“""“’“““‘"“""""“"“"“‘
`Item
`
`Defl n itlon
`
`Value
`
`uetooth.
`
`ServiceName
`
`Dispiayable
`Text name
`
`(varies, e.g.
`‘Airport infor-
`mation‘)
`
`NetworkAddress
`
`IP Network Address
`of Server
`
`(Varies)
`
`WAPGateway‘
`
`0x01 = Origin
`Server;
`
`Indicates if device is
`
`.
`
`0x02 = Proxy;
`
`origin server or proxy
`
`M03 2 Origin
`Server and
`Proxy
`
`HomePageURL
`
`URL of home page
`document
`
`Tebie 6.1: Service Record fame: for WAP Proxy/Gateway devices
`
`*. Stage 2 interoperabiity requirements.
`
`T. If this parameter is omitted, then a default is assumed for origin servers as:
`http:i.-‘networks-oidress/1ndex.wm|
`
`ServiceC|ass|DList
`
`Serviceclassfl
`B|uetoothProfi|e
`
`DescriptorList
`
`Profi|eDescriptor0
`
`K UUID WAP_CL|ENT
`
`Profile
`
`Version
`
`ServiceName
`
`Supported Profile
`
`Profile Version
`
`Displayable
`.
`Text name of client
`
`LANAcce-ss
`Usingppp W
`
`(varies)
`
`String
`
`(varies)
`
`Tabie 6.2: Service Record format for WAP Ciienr devices
`
`Service Discovery
`
`29 November 1999
`
`AFFLT0293741
`
`Samsung Ex. 1019 p. 513
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 514 of1082
`
`interoperabiiity Requirements for Blue-tooth as a WAP Bearer
`
`Bluetooth-
`
`6.2 sop PROTOCOL DATA uuns
`
`'i"ai3ia
`
`shows the specified SDP PDUs (Protocol Data Units). which are
`
`required for WAP Interoperability.
`
`Ability to Send
`
`Ability to Retrieve
`
`WAP
`Client
`M
`
`WAP
`Proxy
`M
`
`WAP
`Client
`M
`
`WAP
`Proxy
`M
`
`SDP PD”
`
`SdpErrorResponse
`
`Sd pSe rvice Searchmlri buteRequest
`
`Sd pSe Nice SearchAtlributeRespor1se
`
`Table 6.3.’ SDP PDUIS
`
`6.3 SERVICE DISCOVERY PROCEDURE
`
`In the simplest form, the signaling can be like this:
`\
`§
`co.\xxw.\-«x“xxxxmxxxxxx-aw.\-ax-o.\-ax-o.\-aw.\-ax-9%.-o.w.xxx\-o.\-«xxxxxxwxxxwtxxxxxxx-ax-o.\-aw.\-ax-aux-ax-o.w.\-o.\-«x-o.\-o.w\xxxxmxxwfixxxxxxxxx-exxx-A».\-mmxvxmxmxmxwxmx-«xv-.\x\\m\x\\x\\
`3
`E
`.
`§5
`WAP Client or Proxy iv‘
`3 WAP Client or Proxy
`\\r.\\r.\\rL\\9.\\o.\\9.\\9.\\9.\\r\\\9.\\9.\rvs\\>.\\.\\n.\\r.\\n.\
`\r.\\ra\\r.\\r\\\o.\\o.\T.\Vx\V.\Vx\\o.\\r.\rv\\\.x\\.>.\ru\\r:.\\V\\ru\\ru\\r.\\ra\\r\\\r\\\9.\\9.xv.\\r.\\§\\\V.\V.vvs\\.x\\.x\ru\\r.\\ru\\ru\\r\\\r.\\r.\\ru\\r\\\o.\\n.\\r.\\r.\\o.\
`§“
`§ Sd pServiceSearchAttrIbuteReq uest
`§
`§3§
`S
`Q
`gi
`Q Z:::=::=::=:::2::=:::==)
`\
`mxmmwwxvmxmxmmxwwsvmv.:s\>.:w\\\w\wq~évmvmwmwmwwvmwwvia-n:o>.:s\¢:s~:\\\\\:\\~.\a~\r\v:\wN\:\~ru\\n:\\r.:\\n:\\wn:\\§\wm:smwwamxmxmxwmvavmmwxvmmvmxmmvm
`§ SdpServiceSearchAttributeResponse
`t _____________________ __
`Q < ————————————————————— -—-v
`. YB\A\\DL\\N\\A\\D.\\E\\\n\\A\\b.\\9.\\9.\$\EW.\V\\\b.\\9.\K$$\KVA“\\v.\\N\\A\\B.\\EV.\\n\\A\\b.\\9.\\9.\\b.\N(\V\\\b.\$\V\\hb.\\9.VA\A\\‘4.\\N\\‘D.\B.\\EV.\\E\}§A\$\\9.\\9.\\‘r.\N(\\9.\\b.\“\V\\\b.\$\Em\N\\V\\N\\‘D.\D.\\E\\\A\\A\
`
`I
`
`MIA’/N/MIN//h$IYIAV4!/»V/MlfivgAI/JV:
`
`§§§3t y
`
`m W
`
`AP service discovery procedures are symmetrical. Each device must be able
`to handle all of the PDUS without regard for the current device role. A minimal
`implementation must return the service name string.
`
`29 November 1999
`
`Servioe Discovery
`
`AFFLT0293742
`
`Samsung Ex. 1019 p. 514
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 515 of 1082
`
`interoperability Requirements for Biuetooth as a WAP Bearer
`
`uetooth.
`
`7 REFERENCES
`
`[1]
`
`[2]
`
`[3]
`
`TS 101 369 (GSM 07.10) version 6.2.0
`
`Simpson, W., Editor, "The Point—to-Point Protocol (PPP)", STD 50, RFC
`1661, Daydreamer, July 1994.
`
`Simpson, W., Editor, "PPP in HDLC Framing", STD 51, RFC 1662, Day-
`dreamer, July 1994.
`
`[4]
`
`See Appendix VIII, “Bl=..=eto<:>th Assigraso‘ Nurnr.-ere“ on
`
`18-99
`
`[5] Wireless Application Protocol Forum, ‘Wireless Application Protocol",
`version 1.0, 1998
`
`[6] Bluetooth Special interest Group, "Bluetooth LAN Access Profile using
`PPP"
`
`[?] Wireless Application Protocol Forum, "WAP Conformance", Draft version
`27 May 1998
`
`29 November 1999
`
`AFFLT0293743
`
`Samsung Ex. 1019 p. 515
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 516 of1082
`
`Jnteroperabflfty Requirements for Biue-tooth as a WAP Bearer
`
`uetooth-
`
`29 November 1999
`
`References
`
`AFFLT0293744
`
`Samsung Ex. 1019 p. 516
`
`
`
`CONTROLLER INTERFACE
`SPECIFICATION
`
`=
`
`:
`
`- This %pocum §nt describes the functional speci-
`ficat' n for tie Host Controller Interface (HCI).
`The s CI proglides a command interface to the
`bas§band cgmtroller and link manager, and
`acgess to Ijardware status and control regis-
`tefs. This filterface provides a uniform method
`ff accesfing the Bluetooth baseband capabili-
`fifties.
`is
`
`AFFLT0293745
`
`Samsung Ex. 1019 p. 517
`
`
`
`BLUETOOTH SPECEFICATION Version 1.0 8
`
`page 518 of 3382
`
`Host Conrrofler Interface Functfonaf Specification
`
`uetooth-
`
`29 November 1999
`
`AFFLT0293746
`
`Samsung Ex. 1019 p. 518
`
`
`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Host Conrrofler Interface Functional Specification
`
`CONTENTS
`
`page 519 0f1G82
`
`Bluetouth.
`
`imrcsziuctimz ................................................................................ ......524
`1.‘:
`
`Lower Layers at ‘me Eiuatcoéiu Sefiwara Stack ...................... ..
`
`524
`
`1.2
`
`Biuetooth Hardware Biock Déagram .....