BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 255 of 440
`
`Fax Profile
`
`Bluetooth.
`
`4.2 CALL PROGRESS AUDIO FEEDBACK
`
`The GW or DT may optionally be able to provide audio feedback during call
`establishment. This clause applies only to gatewaysidata terminals that are
`able to provide audio feedback.
`
`SCO links are used to transport the digitized audio over the Bluetooth link. The
`GW shall take all initiatives for SCO link establishment. The setting of the M
`parameter (see {E}, Section 6.3.14) controls whether the GW provides audio
`feedback.
`
`lfa GW provides audio feedback for a call, the GW shall use the ‘initiate SCO
`link’ procedure (see Link Manager protocoi) to establish the audio link when the
`DCE goes off-hook.
`
`Depending on the setting of the M parameter, the GW releases the audio link
`when the DCE has detected a carrier or when the DOE goes on-hook. The
`‘remove SCO link’ procedure (see [Link Manager pro1oco|]) shall be used for
`audio link release.
`
`if SCO link establishment fails, the call establishment shall proceed without the
`audio feedback.
`
`This profile assumes that the DT is not active in any other profile that uses
`SCO links while it is operating in the Fax profile. Therefore, behavior is
`not defined for a situation where multiple SCO links are established simulta-
`neously.
`
`Dialling and Control Interoperability Requirements 1 December 1999
`
`AFFLT0294565
`
`Samsung Ex. 1216 p. 1337
`
`

`
`BLUETOOTH SPECEFICATION Version 1.0 8
`
`Fax Profile
`
`5 SERIAL PORT PROFILE
`
`page 258 of440
`
`Bluetooth-
`
`This profile requires compliance to the Serial Port Profit:-3. For the purposes of
`reading the Serial Port Profile. the GW shall always be considered to be Device
`B and the DT shall always be considered to be Device A.
`
`The following text together with the associated sub-clauses define the require-
`ments with regards to this profile in addition to the requirements defined in the
`Serial Port Profile.
`
`5.1 RFCOMM INTEROPERABILITY REQUIREMENTS
`
`For RFCOMM, no additions to the requirements stated in ffierial Part Prrssiéie
`apply.
`
`5.2 LZCAP INTEROPERABILITY REQUIREMENTS
`
`For the LZCAP layer, no additions to the requirements stated in Serial Port Pro-
`file apply.
`
`5.3 SDP INTEROPERABILITY REQUIREMENTS
`
`Table 532 lists all entries in the SDP database of the GW defined by this profile.
`The ‘Status’ column indicates whether the presence of this field is mandatory
`or optional.
`
`The codes assigned to the mnemonics used in the ‘Value’ column and the
`codes assigned to the attribute identifiers can be found in Bluetooth Assigned
`Numbers.
`
`Item
`
`Defln ltion:
`
`Service Class ID List
`
`Service Class #0
`
`Service Class #1
`
`Protocol Descriptor List
`
`Protocol #0
`
`Protocol #1
`
`Parameter for Protocol #1
`
`LZCAP
`
`RFCOMM
`
`N = server
`channel #
`
`Table 5.1: Service Database Entries
`
`256
`
`1 December 1999
`
`Serial Port Profile
`
`AFFLT0294566
`
`Samsung Ex. 1216 p. 1338
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`’”""’“”"°”"*
`
`Item
`
`page 257 of 440
`
`Bluetooth.
`
`Service Name
`
`Displayabie
`Text name
`
`Service-provider
`defined
`
`TruefFaise
`
`TruefFaise
`
`TruefFaise
`
`TruetFaise
`
`Audio Feedback Support
`
`Fax Class 1 Support
`
`Fax Class 2.0 Support
`
`Fax Class 2 Support
`
`BluetoothProfiie Descrip-
`torList
`
`Profiie #0
`
`Parameter for Profile #0
`
`Table 5.1: Service Database Entries
`
`*. Indicating version 1.0
`
`5.4 LINK MANAGER (LM) INTEROPERABILITY
`REQUIREMENTS
`
`in addition to the requirements for the Link Manager as stated in the
`§3’r3rt §'—‘rofiEe" on page
`this profile requires support for SCO links. in both
`the (SW and DT. The support is conditional upon the ability to provide audio
`feedback."
`
`Serial Port Profile
`
`1 December 1999
`
`AFFLT0294567
`
`Samsung Ex. 1216 p. 1339
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Fax Profile
`
`page 258 of440
`
`Bluetooth-
`
`5.5 LINK CONTROL (LC) INTEROPERABILITY
`REQUIREMENTS
`
`In the table below. all LC capabilities required by this profile are listed.
`
`Capabilities
`
`Support in
`base-band
`
`GW
`
`DT
`
`Packet types1
`
`Voice codec
`
`CVSD
`
`C1: The support for this capability is mandatory for gateways that are able to provide audio
`feed back to the DT.
`
`C2: The support for this capability is mandatory for data terminals that are able to provide
`audio feedback to the user.
`
`Table 5.2: Baseband/LC capabilities
`
`5.5.1 Class of Device usage
`
`A device which is active in the GW role of the Fax profile shall, in the Class of
`Device field:
`
`1. Set the ‘Telephony’ bit in the Service Class field (see Bluetooth Assigned
`Numbers)
`
`2. Indicate ‘Phone’ as Major Device class (see Bluetooth Assigned
`Numbers)
`
`This may be used by an inquiring device to filter the inquiry responses.
`
`1 December 1999
`
`Serial Port Profile
`
`AFFLT029456B
`
`Samsung Ex. 1216 p. 1340
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`’”""’“”"°”"*
`
`page 259 of 440
`
`Bluetooth.
`
`6 GENERIC ACCESS PROFILE INTEROPERABILITY
`
`REQUIREMENTS
`
`This profile requires compliance to the Gt-:-merit: i’-‘ac-cess Profiie.
`
`This section defines the support requirements with regards to procedures and
`capabilities defined in Generic Access Profiie.
`
`6.1 MODES
`
`The table shows the support status for Modes within this profile.
`
`Procedu re
`
`Discoverability modes
`
`Non-discoverable mode
`
`Limited discoverable mode
`
`General discoverabie mode
`
`Connectability modes
`
`Nomconneciable mode
`
`Connectable mode
`
`Pairing modes
`
`Non-pairable mode
`
`Pairable mode
`
`Table 6.1: Modes
`
`Generic Access Profile Interoperability Requirements 1 December 1999
`
`AFFLT0294569
`
`Samsung Ex. 1216 p. 1341
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 260 of440
`
`Fax Profiie
`
`6.2 secunnv ASPECTS
`
`Bluetooth-
`
`The table shows the support status for Security aspects within this profile.
`
`Support in
`DT
`
`Support in
`Gw
`
`M
`
`M
`
`Procedure
`
`Authentication
`
`Security modes
`
`Security mode 1
`
`Security mode 2
`
`Security mode 3
`
`C1: Support for at least one of the security modes 2 and 3 is mandatory
`
`Tabie 6.2: Security aspects
`
`8.3 IDLE MODE PROCEDURES
`
`The table shows the support status for Idle mode procedures within this profile.
`
`Procedure
`
`Generai inquiry
`
`Limited inquiry
`
`Name discovery
`
`Device discovery
`
`Bonding
`
`Note 1: See section 5.3.1
`
`Tabie 6.3:
`
`idle mode procedures
`
`6.3.1 Bonding
`
`Support in DT
`
`Support in GW
`
`M
`
`O
`0
`
`0
`
`M
`
`NIA
`
`NIA
`
`NIA
`
`MFA
`
`M (Note 1)
`
`It is mandatory for the DT to support initiation of bonding, and for the GW to
`accept bonding.
`
`1 December 1999
`
`Generic Access Profiie Interoperability
`
`AFFLT0294570
`
`Samsung Ex. 1216 p. 1342
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 261 of 440
`
`Fax Profile
`
`7 REFERENCES
`
`Bluetooth.
`
`[1]
`
`[2]
`
`[3]
`
`[4]
`
`[5]
`
`[6]
`
`TS 101 369 (GSM 07.10) version 6.1.0
`
`TIA~578-A Facsimile Digital Interface. Asynchronous Facsimile DCE Con~
`troi Standard, Service Class 1
`
`TIA-592 Facsimile Digital Interface. Asynchronous Facsimile DCE Control
`Standard, Service Class 2
`
`ITU T.31 Asynchronous Facsimile DCE Control —- Service Class 1
`
`ITU T.32 Asynchronous Facsimile DCE Control — Service Class 2
`
`International Telecommunication Union, "lTU-T Recommendation V.250"
`
`References
`
`1 December 1999
`
`AFFLT0294571
`
`Samsung Ex. 1216 p. 1343
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`""“”"°”’°
`
`8 LIST OF FIGURES
`
`page 262 of440
`
`Bluetooth-
`
`Figure: 15%:
`Fégurs-3 23%:
`
`Figure 2.2:
`
`Eiueicaaaiia Prczfsies ................................................................... ..2-E5
`Prctocoi mcaciei ....................................................................... ..2~’f=9
`
`;J.:':3s":'$e, e:s:am_r;§e with (;e§iL:E;«13'_I3§".=r.}.r‘=£-3 ................................ .. 250
`
`Figure 2.3:
`
`;-"-ax ;.=r‘o:"'i$e, examsie with modem .......................................... “E50
`
`1 December 1999
`
`List of Figures
`
`AFFLT0294572
`
`Samsung Ex. 1216 p. 1344
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Fax Profile
`
`9 LIST OF TABLES
`
`page 263 of 440
`
`Bluetooth.
`
`Tabée 3.1:
`
`Tabie
`
`Tahie 5.2:
`
`Tabée 6.1:
`
`“é's.-me 8.2:
`
`Ta-ibis: 6.3:
`
`A_;>;.=iEcat§=:.=n Sayer ps'oce::'urs=:s ..................................................
`Service Database Entries
`
`256
`
`Ea;~3e;*;3r:c3.fL{3 capabiiitieax .......................................................
`Macias .................................................................................... ..
`
`-=
`
`idisv,» !'E'1i'3fi6:;"J!‘:'}Cu§ii!‘*.~“3:3 ............................................................ ..
`
`-
`
`List of Tables
`
`1 December 1999
`
`AFFLT0294573
`
`Samsung Ex. 1216 p. 1345
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 264 of-440
`
`Fax Profile
`
`1 December 1999
`
`List 01 Tabtes
`
`AFFLT0294574
`
`Samsung Ex. 1216 p. 1346
`
`

`
`ACCESS PROFILE
`
`This ocum§nt is a LAN Access Profile for
`Blueoth d
`ices. Firstly, this profile defines
`L: |ueto%‘i1-enabled devices can access
`
`the rvicessof a LAN using PPP. Secondly,
`this jarofile sfihows how the same PPP mecha-
`nis@s are fed to form a network consisting
`ofjfiuo Blue" ooth-enabled devices.
`§s
`,6‘
`é’-’
`
`AFFLT0294575
`
`Samsung Ex. 1216 p. 1347
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 266 of-440
`
`LAN Access Profile
`
`1 December 1999
`
`AFFLT0294576
`
`Samsung Ex. 1216 p. 1348
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 267 of 440
`
`LAN Access Profiie
`
`CONTENTS
`
`immsziuction ..........................................
`
`................................... ......2fi$
`
`1.’!
`
`1.12
`
`1.13
`
`Scope
`
`Prufiie ifieperéderzciss ............................................................. ..f»37G
`
`Symimis and c<:rwe:3t§t;nss ..
`
`.. .
`
`.. ....27{}
`
`Frame mrenréew ..........
`
`................................................................. ...??1
`
`2.1
`
`2.2
`2.3
`2.4
`
`2.5
`
`F-*r:‘,-ta:-co! stack
`
`Gonféguratiarzs and raises
`User r'equi:‘ernents arid sceruartos ...................................... .._...2?’2
`Profile E-Lmciamaratais .............................................................. ..27’4
`
`Conforrnance: ......................................................................... ..2?<$
`
`Lfiserinterfaceasgcsects .......
`
`.............................
`
`......
`
`............. .....2?‘5
`
`6.; Genefic
`
`Add:£é0rtaiE'-kzrarreeters ............................................................ ..f»3?'e"
`
`Agzpiication iayer
`4.1
`in§t§aEi2:.a!:.i:.m of i..AN Accesss Point service: .............................. ..2.?8
`
`c3».2
`
`#3
`
`4.4
`4.5
`
`S*"'$-"‘*.°"-§"?3“
`
`(J1-J1}:-CAJ!‘h3*w*
`
`Efiémtdown of Le‘-'\§\3 Acctass Point ass.-r\;éce=3 ................................. ..2?E«}
`
`Establish LAN iionrzeciion
`
`LGSELAN
`L‘i5c0rr.r‘=e<;H_AN Cormectior:..........._........................................280
`
`inétiaéize PP? .......................................................................... .28‘?
`Shutdown PPP ....................................................................... .282
`
`E-Lstabiish E3’¥«"’§=’ Connection ..................................................... .282
`
`i3is(:c3rmect ;=>i‘—‘:"->
`Auztixenticatiorw
`
`Smvica Discuvery
`"M
`85.}? service rec-ords
`
`kink
`9.?
`
`Link
`
`Profsie Errors .......................................................................... .2893
`
`1 December 1999
`
`AFFLTD294577
`
`Samsung Ex. 1216 p. 1349
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 268 0f44-0
`
`LAN Access Profile
`
`11
`
`Management Entity Wecefiures
`13.1
`
`11.1.1 No resp0a':ses tat: inquiry
`
`11.1.2 Hm‘:-3:~3pc}n.setc :3-aging .............................................. .292
`
`11.2 Maxinwm Nurrsberafusers .................................................... ‘U292
`
`APPENWX A {kzécrmative}: ‘fimere anti caunters ......................... "293
`
`AFPENWX 8 {Nmrmaiive}: fuiicrosoft Wirsdews ........................... ..29¢3»
`
`13.‘:
`
`E3-‘(S-2-PC configuration ........................................................... ..2Si=1
`
`.i31.¥’PEE§i3iX C {infnrmative}: intemet Presmmafi {SP} ...................... ".295
`$4.?
`imrxterfaces ........................................................................... .395
`14.1.1 in=terfac.e
`
`14.1.2 in*.'er§ace
`
`14,2 Tm EPCP
`14.2.1
`EPCF’ ilanrsacfiien
`
`M~.2.2 ii” Address A¥EoCatEon
`
`14.2.3 DNS and NBNS
`
`1-4.2.4 NetB§Of:“= over E?-‘
`
`L53? ef figures ................................................................................ ..2$'?
`
`his? :3? Tabiee .................................................................................. "298
`
`References ...................................................................................... . . 2%
`
`$1‘! Nerrraetive :‘efe:'err::es
`
`17.3 inferrnative references ........................................................... ...?".S.¥Q
`
`1 December 1999
`
`AFFLTD294-578
`
`Samsung Ex. 1216 p. 1350
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 269 of 440
`
`LAN Access Profile
`
`1
`
`INTRODUCTION
`
`1.1 SCOPE
`
`This profile defines LAN Access using PPP over RFCOM M. There may be
`other means of LAN Access in the future.
`
`- PPP is a widely deployed means of allowing access to networks.
`PPP provides authentication, encryption, data compression and multi-
`protocol facilities. PPP over RFCOMM has been chosen as a means of pro-
`viding LAN Access for Bluetooth devices because of the large installed base
`of devices equipped with PPP software.
`
`It is recognized that PPP is capable of supporting various networking proto-
`cols (e.g. IP, IPX, etc.). This profile does not mandate the use of any particu-
`lar protocol. However, since IP is recognized as the most important protocol
`used in today's networks, additional IP-related information is provided in an
`appendix. The use of these other PPP protocols is not discussed.
`
`This profile does not deal with conferencing, LAN emulation, ad-hoc net-
`working or any other means of providing LAN Access. These functions are,
`or may be, dealt with in other Bluetooth profiles.
`
`This profile defines how PPP networking is supported in the following situa-
`tions.
`
`a) LAN Access for a single Bluetooth device.
`
`b) LAN Access for multiple Bluetooth devices.
`
`c) PC to PC (using PPP networking over serial cable emulation).
`
`Introduction
`
`1 December 1999
`
`AFFLT0294579
`
`Samsung Ex. 1216 p. 1351
`
`

`
`BLUETOOTH SPECEFICATION Version 1.0 8
`
`page 270 of440
`
`LAN Access Profile
`
`1.2 PROFILE DEPENDENCIES
`
`In =~’3iggLss'e 1.1, the Bluetooth profile structure and the dependencies of the
`profiles are depicted. A profile does have dependencies — direct and indirect —
`on the profi|e(s) within which it is contained. as illustrated in the figure.
`In particular, this LAN Access profile is dependent on the Serial Port and
`Generic Access profiles.
`
`Service Discovery
`;== Profile
`
`.'F_(§$gl3_lN-‘baaed.Profi|e
`_ Cord|essTeIephony
`"= Profile
`
`::
`
`' "at" Port Profile
`
`j Dial-up Networking
`1 Profile
`
`_
`'
`Fax PI'DfllE
`
`'
`
`'
`
`'
`
`'
`
`"
`
`; Headset Profile
`
`I
`_
`:_ LAN Access Profile
`
`Z;
`.j
`
`.;
`
`_
`';
`
`File Transfer
`Profile
`
`._; Object Push Profile
`
`Hf Synchronization
`Profile
`
`Z
`:
`
`Z:
`
`If
`
`Figure 1.1: Bluetooth Profiles
`
`1.3 SYMBOLS AND CONVENTIONS
`
`This profile uses the symbols and conventions specified in Section 1.2 of the
`| Generic Access Profile {E3}.
`
`1 December 1999
`
`introduction
`
`AFFLT02945B0
`
`Samsung Ex. 1216 p. 1352
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 271 of 440
`
`LAN Access Profile
`
`2 PROFILE OVERVIEW
`
`2.1 PROTOCOL STACK
`
`The figure below shows the protocols and entities used in this profile.
`
`Data Terminal
`
`LAN Access Point
`
`Figure 2.1: Protocol Stack
`
`PPP is the IETF Point-to-Point Protocol [$3. PPP-Networking is the means of
`taking IP packets toffrom the PPP layer and placing them onto the LAN. This
`mechanism is not defined by this profile but is a well-understood feature of
`Remote Access Server products.
`
`The Baseband it}, LMP {2} and LZCAP [33 are the OSI layer 1 and 2 Bluetooth
`protocols. RFCOMM {4} is the Bluetooth adaptation of GSM TS 07.10 {S}. SDP
`is the Bluetooth Service Discovery Protocol
`
`ME is the Management Entity which coordinates procedures during initializa-
`tion, configuration and connection management.
`
`2.2 CONFIGURATIONS AND ROLES
`
`The following roles are defined for this profile.
`
`LAN Access Point (LAP) — This is the Bluetooth device that provides access to
`a LAN (e.g. Ethernet, Token Ring, Fiber Channel, Cable Modem, Firewire,
`USB, Home Networking). The LAP provides the services of a PPP Server. The
`PPP connection is carried over RFCOMM. RFCOMM is used to transport the
`PPP packets and it can also be used for flow control of the PPP data stream.
`
`Profile overview
`
`1 December 1999
`
`AFFLT02945B1
`
`Samsung Ex. 1216 p. 1353
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 272 of440
`
`LAN Access Profile
`
`Data Terminal (DT) — This is the device that uses the services of the LAP. Typi-
`cal devices acting as data terminals are laptops, notebooks, desktop PCs and
`PDAs. The DT is a PPP client. It forms a PPP connection with a LAP in order to
`
`gain access to a LAN.
`
`This profile assumes that the LAP and the DT each have a single Bluetooth
`radio.‘
`
`2.3 USER REQUIREMENTS AND SCENARIOS
`
`The following scenarios are covered by this profile.
`
`1. A single DT uses a LAP as a wireless means for connecting to a Local Area
`Network (LAN). Once connected, the DT will operate as if it were connected
`to the LAN via dial-up networking. The DT can access all of the services pro-
`vided by the LAN.
`
`LAN Access Point
`
`Figure 2.2: LAN Access by a single D3".
`
`‘Data Terminal
`
`1. Products with multiple radios can still conform to this profile. The LAP and DT roles can be
`adopted independently by each radio.
`
`272
`
`1 December 1999
`
`Profile overview
`
`AFFLT02945B2
`
`Samsung Ex. 1216 p. 1354
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 273 of 440
`
`LAN Access Profile
`
`2. Multiple DTs use a LAP as a wireless means for connecting to a Local Area
`Network (LAN). Once connected, the DTs will operate as if they were con-
`nected to the LAN via dial-up networking. The DTs can access all of the ser-
`vices provided by the LAN. The DTs can also communicate with each other
`via the LAP.2
`
`LAN Access Point
`
`Data Terminal B
`
`ta Terminal A
`
`Figure 2.3: LAN Access by multiple DTs_
`
`3. PC to PC connection. This is where two Bluetocth devices can form a single
`connection with each other. This scenario is similar to a direct cable connec-
`
`tion commonly used to connect two PCs. In this scenario, one of the devices
`will take the role of a LAP. the other will be a DT. See Appsrndix 13.1 for
`more details of how this can be configured.
`
`Figure 2.4: PC to PC connection.
`
`Some LAP products may have an internal LAN or use the PSTN to access the
`Internet or corporate networks. The dial-up mechanisms to achieve the Internet
`connection are specific to the LAP. The DTs are totally unaware of these activi-
`ties — except maybe in the event of longer connection times and traffic delays.
`
`2. The DTs will be able to communicate with each other only ifthe required services (e.g. DNS)
`are available on the LAN.
`
`Profile overview
`
`1 December 1999
`
`AFFLT02945B3
`
`Samsung Ex. 1216 p. 1355
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`LAN Access Profile
`
`2.4 PROFILE FUNDAMENTALS
`
`page 274 of 440
`
`Bluetooth-
`
`Here is a brief summary of the interactions between a DT and a LAP. Subse-
`quent sections in this profile provide more detail for each of the following steps.
`
`1. The first step is to find a LAP that is within radio range and is providing a
`PPPIRFCOMIWLZCAP service. For example, the DT user could use some
`application to find and select a suitable LAP.
`
`. If there is no existing baseband physical link, then the DT requests a base-
`band physical link with the selected LAP. At some point after the physical
`link establishment, the devices perform mutual authentication. Each device
`insists that encryption is used on the link — see Eisctian 3.1.
`
`. The DT establishes a PPPIRFCOM MILZCAP connection.
`
`. Optionally, the LAP may use some appropriate PPP authentication mecha-
`nism (e.g. CHAP {$3.11}. For example. the LAP may challenge the DT‘s user
`to authenticate himself or herself; the DT must then supply a username and
`password. If these mechanisms are used and the DT fails to authenticate
`itself, then the PPP link will be dropped.
`
`. Using the appropriate PPP mechanisms, a suitable IP address is negotiated
`between the LAP and the DT.
`
`6. IP traffic can now flow across the PPP connection.
`
`7. At any time the DT or the LAP may terminate the PPP connection.
`
`2.5 CONFORMANCE
`
`If conformance to this profile is claimed, all capabilities indicated mandatory for
`this profile shall be supported in the specified manner (process-mandatory).
`This also applies to all optional and conditional capabilities for which support is
`indicated. All mandatory capabilities, and optional and conditional capabilities
`for which support is indicated, are subject to verification as part of the
`Bluetooth certification program.
`
`1 December 1999
`
`Profile overview
`
`AFFLT02945B4
`
`Samsung Ex. 1216 p. 1356
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 275 of 440
`
`LAN Access Profile
`
`3 USER INTERFACE ASPECTS
`
`This profile is built upon the Generic Access Profile.
`
`- When reading C3{’:E”‘.F3E"§i3 Access E5’rc‘iiie, DevA (the connection initiator) is
`equivalent to DT. and DevB is equivalent to the LAP.
`
`All the mandatory requirements defined in Genee'Er: Access Profile are man-
`datory for this profile.
`
`Unless otherwise stated below, all the optional requirements defined in
`Generic: Access Profile are optional for this profile.
`
`3.1 SECURITY
`
`It is recognized that security in a wireless environment is of paramount impor-
`tance.
`
`Both the LAP and the DT must enforce that encryption is operating on the
`baseband physical link while any PPP traffic is being sent or received. The LAP
`and the DT will refuse any request to disable encryption. Therefore, Bluetooth
`pairing must occur as a means of authenticating the users. A PIN or link key
`must be supplied, even if the default PIN is used. The default PIN for LAN
`access is a zero length PIN. Failure to complete the pairing process will pre-
`vent access to the LAN Access service.
`
`A more sophisticated product may require further authentication, encryption
`andior authorization.
`
`User interface aspects
`
`1 December 1999
`
`AFFLT02945B5
`
`Samsung Ex. 1216 p. 1357
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 276 of440
`
`LAN Access Profile
`
`3.2 GENERIC MODES
`
`| The following modes are defined in Section ii of Generic Access Profile {13}.
`This profile requires the following support.
`
`— Support Us
`Discoverability modes
`
`supvonvr
`
`Non-discoverable mode
`
`Limited discoverable mode
`
`General discoverable mode
`
`Connectabllity modes
`
`Non-connectable mode
`
`Connectable mode
`
`Pairing modes
`
`Non-pairable mode
`
`Pairable mode
`
`Table 3.1: Generic Mode requirements table
`
`Notes
`
`1. A typical use for the Non—discoverab!e mode is where the LAP is intended
`for personal use only. The DT would remember the identity of the LAP and
`never need to use the Bluetooth inquiry mechanism.
`
`2. A typical use for the General discoverable mode is where the LAP is
`intended for general use. The DT would not be expected to remember the
`identity of all the LAPs that it uses. The DT is expected to use the Bluetooth
`inquiry mechanism to discover the LAPs in range.
`
`1 December 1999
`
`User interface aspects
`
`AFFLT02945B6
`
`Samsung Ex. 1216 p. 1358
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 277 of 440
`
`LAN Access Profile
`
`3.3 ADDITIONAL PARAMETERS
`
`Bluetooth.
`
`The following parameter is mandatory for the LAP. Optionally it may be config-
`urable by the LAP administrator.
`
`Maximum number of users. Different products have different capabilities and
`resource limitations that will limit the number of simultaneous users that they
`can support. The administrator of the LAP may choose to further limit the num-
`ber of simultaneous users.3
`
`- Single-user mode is when the maximum number of users is configured to
`allow only a single user. In this mode. either the DT or the LAP may be the
`master of the piconet. Single-user mode means that a single DT has exclu-
`sive access to a LAP.4
`
`Multi-user mode is when the maximum number of users is configured to
`allow more than one user. In this mode. the LAP must always become the
`master of the piconet. If the DT refuses to allow the LAP to become master,
`then the DT cannot gain access to the LAN.
`
`3. The fewer simultaneous users there are using a Bluetooth radio, the more bandwidth will be
`available to each. A LAP can be restricted to a single user.
`4. There are situations where a DT may wish to connect to a LAP and still remain the master of
`an existing piconet. For example, a PC is the master of a piconet with connections to a
`Biuetooth mouse and a Bluetooth video projector. The PC then requires a connection to the
`LAP, but must remain master of the existing piconet. If, for some reason, the PC can only be
`a member of one piconet. then the LAP must be a ptconet slave. This situation is only possi-
`ble if the LAP's ‘maximum number of users‘ parameter has been configured to 1; Le. single-
`user mode.
`
`User interface aspects
`
`1 December 1999
`
`AFFLT02945B7
`
`Samsung Ex. 1216 p. 1359
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`LAN Access Profile
`
`4 APPLICATION LAYER
`
`page 278 of440
`
`Bluetooth-
`
`4.1
`
`Initialization of LAN Access service
`
`M
`
`X
`
`Shutdown of LAN Access service
`
`Establish LAN Connection
`
`Lost LAN Connection
`
`Disconnect LAN Connection
`
`Table 4.1: Application-layer requirements table
`
`C1: Currently the LAP is not required to initiate a LAN connection establish-
`ment. In the future, a LAP may initiate a connection (e.g. as part of some form
`of LAP-initiated hand-off).
`
`4.1
`
`INITIALIZATION OF LAN ACCESS POINT SERVICE
`
`This procedure initiates the configuration of the device as a LAP. This operation
`involves setting the following parameters:
`
`- All the configurable parameters defined in {‘3€-BCEE-3!":
`mum number of users, discoverabiiity mode, etc.)
`
`(For example, maxi-
`
`The required Bluetooth PlNs andlor link keys.
`
`Any appropriate PPP configuration options (eg. authentication. compres-
`sion) can be configured. In order to ensure interoperability, a LAP shall not
`require connecting DTS to perform any PPP authentication, until the LAP
`administrator has configured PPP authentication.
`
`When initialization is complete. the device will be able to accept PPP connec-
`tions.
`
`For products whose main role is that of a LAP, this initialization procedure is
`typically run automatically when the device is powered up.
`
`For other products (eg. PCs. Notebooks, etc.), this initialization procedure
`allows the user to configure the product as an access point, so that a DT can
`connect to it.
`
`1 December 1999
`
`Application layer
`
`AFFLT02945BB
`
`Samsung Ex. 1216 p. 1360
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 279 of 440
`
`LAN Access Profile
`
`4.2 SHUTDOWN OF LAN ACCESS POINT SERVICE
`
`This procedure stops the device from acting as a LAP.
`
`- The PPP Server is shutdown — as defined in 53st.-tion
`
`- Optionally, a product may take steps to prevent unauthorized Biuetooth
`access at a later time by deleting some of the stored link keys.
`
`4.3 ESTABLISH LAN CONNECTION
`
`Normally the DT will initiate the establishment of a connection to the LAN.
`
`1. The first step is to select a LAP and a suitable PPPIRFCOMM service that it
`provides. This selection may be done in one of the following ways:
`
`The DT user is presented with a list of LAPs that are within radio range. and
`the services that they provide. The user can then select a LAP.’service from
`the list provided.
`
`The DT user is presented with a list of services that are being provided by
`the LAPs that are within radio range. Where the same service is provided by
`multiple LAPs (i.e. identical Serviceclass-lDs), the application may choose
`to show the service only once. The user can then select a service from the
`list provided. The DT will automatically select a suitable LAP that provides
`the selected service.
`
`The DT user enters the name of the service that is required, e.g. ‘network’,
`or ‘Meeting #1‘ (see Fiiectiori
`for more information on service names).
`The DT will automatically select a suitable LAP that provides the required
`service.
`
`Some application on the DT automatically searches for and selects a suit-
`able LAP!5ervice.
`
`Whatever means is used, the result of the selection process must be a LAP
`that is within radio range and a PPPIRFCOMM service that it provides.
`
`in all cases, the Bluetooth Service Discovery mechanisms are used to retrieve
`service information. This service information provides all the information
`required to create the RFCOMM connection in step 4.
`
`2. Optionally, the DT user (or application) is allowed to enter a Bluetooth
`Authentication PIN or link key suppiied by the application. If no PIN is
`entered, then a zero-iength PIN is used.
`
`3. Optionally, the DT user (or application) is allowed to enter a username and
`password for PPP authentication. if some PPP authentication mechanism is
`used and the user does not initially supply the username and password,
`then heishe may be prompted for them later in the connection establish-
`ment.
`
`Application layer
`
`1 December 1999
`
`AFFLT02945B9
`
`Samsung Ex. 1216 p. 1361
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 280 of440
`
`LAN Access Profile
`
`Bluetooth-
`
`4. When the user (or application} activates the connection, then a PPP applica-
`tion is started, to attempt to establish a connection to the selected access
`pointlservice using the procedures in 12.1.
`
`More complex situations (e.g. hand-off of a DT between LAPs) may require the
`LAP to initiate the establishment of a connection. These situations are possi-
`ble. but are outside the scope of this document.
`
`4.4 LOST LAN CONNECTION
`
`If the LAN connection is lost for any reason, then the DT user (or application)
`must be notified of connection failure.
`
`Optionally, the application may allow re-establishment of the connection to the
`same (or similar) LAPz'service. The application could remember the previous
`LAP. service, PIN, link key, username and password and use them to allow
`speedy or automatic re-establishment of the LAN connection. The procedures
`described in E3e::;tion 5.1 will be used.
`
`4.5 DISCONNECT LAN CONNECTION
`
`Either the LAP or the DT may terminate the LAN Connection at any time —
`using the procedures in 8ectit';-n 5.4-.
`
`1 December 1999
`
`Application layer
`
`AFFLT0294590
`
`Samsung Ex. 1216 p. 1362
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`LAN Access Profiie
`
`5 PPP
`
`page 281 of 440
`
`Bluetooth.
`
`PPPIRFCOMM operation in this profile is simiiar to PPP operation in normal
`dial-up networking, except that this profile omits the use of AT commands; PPP
`starts as soon as the RFCOMM link is established. By contrast, in dial-up net-
`working, AT commands are used to establish the link, then PPP starts commu-
`nicating.
`
`The LAP exports a PPP Server interface {Si}. This specification does not require
`any particular means of achieving the ‘appearance’ of a PPP Server. One
`implementation of a LAP could contain a PPP Server. Alternatively, the LAP
`could be some kind of PPP proxy, where PPP packets are transferred toifrom a
`PPP server somewhere else on the network.
`
`The following text, together with the associated sub-clauses, defines the man-
`datory requirements with regard to this profile.
`
`Support in LAP
`
`Support in DT
`
`Procedure
`initialize PPP
`
`Shutdown PPP
`
`Establish PPP Connection
`
`Disconnect PPP Connection
`
`PPP Authentication Protocols
`
`Table 5.1: PPP capabiiities
`
`5.1
`
`INITIALIZE PPP
`
`On the LAP, the existence of a PPP Server shall be registered in the Service
`Discovery Database. The service attributes are defined in '?.i.
`
`A device in the DT role does not register PPP in the Service Discovery Data-
`base. However, it is possible for a device to be both a LAP and a DT; therefore
`the device could register PPP in the Service Discovery Database as defined
`above.
`
`PPP is a packet-oriented protocol, whereas RFCOMM expects seriai data
`streams. Therefore, the PPP layer must use the serialization mechanisms
`described in
`
`1 December 1999
`
`AFFLT0294591
`
`Samsung Ex. 1216 p. 1363
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 282 of440
`
`LAN Access Profile
`
`5.2 SHUTDOWN PPP
`
`Bluetooth-
`
`All existing PPP connections are disconnected.
`
`The PPP layer disables or removes the PPP service entry from the Service
`Discovery Database.
`
`5.3 ESTABLISH PPP CONNECTION
`
`If there is no existing RFCOMM session between the LAP and the DT, then the
`device initiating the PPP connection shall first initialize RFCOMM (see Section
`5:3). The device obtains the RFCOMM Server channel to use from the service
`information it discovered earlier.
`
`Using the Link Control Protocol (LCP) {E5}, the LAP and DT negotiate a PPP
`link.
`
`Part of the LCP is the negotiation of the Maximum Transmission Unit (MTU) to
`be used on the PPP link — see {8} for details. This profile places no require-
`ments on the negotiated MTU.5
`
`Depending upon its capabilities and configuration (see 3.2), a LAP may have
`multiple PPP sessions in operation simultaneously.
`
`5.4 DISCONNECT PPP CONNECTION
`
`The following reasons will cause PPP to terminate the connection:
`
`1. User intervention.
`
`2. Failure of the