Presentation on theme: "WPAN: INTRODUCTION A WPAN (Wireless PAN) is a short-distance wireless network specifically designed to support portable and mobile computing devices such."— Presentation transcript:
2 WPAN: INTRODUCTIONA WPAN (Wireless PAN) is a short-distance wireless network specifically designed to support portable and mobile computing devices such as PCs, PDAs, wireless printers and storage devices, cell phones, pagers, set-top boxes, and a variety of consumer electronics equipment.Bluetooth is an example of a wireless PAN that allows devices within close proximity to join together in ad hoc wireless networks in order to exchange information.Many cell phones have two radio interfaces-one for the cellular network and one for PAN connections.
3 WPAN WPANs such as Bluetooth provide the bandwidth and convenience to make data exchange practicalfor mobile devices such as palm computers.Bluetooth overcomes many of the complicationsof other mobile data systems such as cellularpacket data systems...The reach of a PAN is typically a few meters.
4 WPANA Bluetooth PAN is also called a piconet, and is composed of up to 8 active devices in a master-slave relationship (up to 255 devices can be connected in 'parked' mode).The first Bluetooth device in the piconet is the master, and all other devices are slaves that communicate with the master.A piconet typically has a range of 10 meters, although ranges of up to 100 meters can be reached under ideal circumstances.
5 WPANA wireless PAN consists of a dynamic group of less than 255 devices that communicate within about a 33-foot range.Unlike with wireless LANs, only devices within this limited area typically participate in the network, and no online connection with external devices is defined.One device is selected to assume the role of the controller during wireless PAN initialization, and this controller device mediates communication within the WPAN.
6 WPANThe controller broadcasts a beacon that lets all devices synchronize with each other and allocates time slots for the devices.Each device attempts to join the wireless PAN by requesting a time slot from the controller.The controller authenticates the devices and assigns time slots for each device to transmit data.The data may be sent to the entire wireless PAN using the wireless PAN destination address, or it may be directed to a particular device.
7 WPANThe working group is defining different versions for devices that have different requirements.focuses on high-bandwidth (about 55M bit/sec), low-power MAC and physical layers, while deals with low-bandwidth (about 250K bit/sec), extra-low power MAC and physical layers.
8 WPAN: HistoryWPAN: smaller area of coverage, ad hoc only topology, plug and play architecture, support of voice and data devices, and low-power consumption.BodyLAN (DARPA, mid-1990s): inexpensive WPAN with modest bandwidth that could connect personal devices within a range of about 5 feet.project initiated a WPAN group in 1997.In March 1998, the HomeRF group was formedIn May 1998, a Bluetooth special group was formedIn March 1999, was approved as a separate group to handle WPAN
9 IEEE WPANDevelopment of standards for short distance wireless networks used for networking of portable ad mobile computing devices.The original functional requirement was published in January 22, 1998, and specified devices with:Power management: low current consumptionRange: metersSpeed: kbpsSmall size: .5 cubic inches without antennaLow cost relative to target deviceShould allow overlap of multiple networks in the same areaNetworking support for a minimum of 16 devices
10 IEEE WPANThe initial activities in the WPAN group included HomeRF and Bluetooth group.HomeRF currently has its own website [HomeRFweb]IEEE WPAN has four task groups:Task group 1: based on Bluetooth. Defines PHY and MAC for wireless connectivity with fixed, portable, and moving devices within or entering a personal operating space.Task group 2: focused on coexistence of WPAN and WLANs.Task group 3: PHY and MAC layers for high-rate WPANs (higher than 20 Mbps)Task group 4: ultra-low complexity, ultra-low power consuming, ultra-low cost PHY and MAC layer for data rates of up to 200 kbps.
11 BluetoothIdeaUniversal radio interface for ad-hoc wireless connectivityInterconnecting computer and peripherals, handheld devices, PDAs, cell phones – replacement of IrDAEmbedded in other devices, goal: 5€/device (2002: 50€/USB Bluetooth)Short range (10 m), low power consumption, license-free 2.45 GHz ISMVoice and data transmission, approx. 1 Mbit/s gross data rate
14 BluetoothHistory1994: Ericsson (Mattison/Haartsen), “MC-link” projectRenaming of the project: Bluetooth according to Harald “Blåtand” Gormsen [son of Gorm], King of Denmark in the 10th century1998: foundation of Bluetooth SIG,1999: erection of a rune stone at Ericsson/Lund2001: first consumer products for mass market, spec. version 1.1 releasedSpecial Interest GroupOriginal founding members: Ericsson, Intel, IBM, Nokia, ToshibaAdded promoters: 3Com, Agere (was: Lucent), Microsoft, Motorola> 2500 membersCommon specification and certification of products
15 …and the real stone Located in Jelling, Denmark, erected by King Harald “Blåtand”in memory of his parents.The stone has three sides – one sideshowing a picture of Christ.Inscription:"Harald king executes these sepulchral monuments after Gorm, his father and Thyra, his mother. The Harald who won the whole of Denmark and Norway and turned the Danes to Christianity."This could be the “original” colors of the stone. Inscription:“auk tani karthi kristna” (and made the Danes Christians)Btw: Blåtand means “of dark complexion”(not having a blue tooth…)
16 Characteristics2.4 GHz ISM band, 79 RF channels, 1 MHz carrier spacingChannel 0: 2402 MHz … channel 78: 2480 MHzG-FSK modulation, mW transmit powerFHSS and TDDFrequency hopping with 1600 hops/sHopping sequence in a pseudo random fashion, determined by a masterTime division duplex for send/receive separationVoice link – SCO (Synchronous Connection Oriented)FEC (forward error correction), no retransmission, 64 kbit/s duplex, point-to-point, circuit switchedData link – ACL (Asynchronous ConnectionLess)Asynchronous, fast acknowledge, point-to-multipoint, up to kbit/s symmetric or 723.2/57.6 kbit/s asymmetric, packet switchedTopologyOverlapping piconets (stars) forming a scatternet
17 Bluetooth Protocol Stack RadioBasebandLink ManagerControlHostControllerInterfaceLogical Link Control and Adaptation Protocol (L2CAP)AudioTCS BINSDPOBEXvCal/vCardIPNW apps.TCP/UDPBNEPRFCOMM (serial line interface)AT modemcommandstelephony apps.audio apps.mgmnt. apps.AT: attention sequenceOBEX: object exchangeTCS BIN: telephony control protocol specification – binaryBNEP: Bluetooth network encapsulation protocolSDP: service discovery protocolRFCOMM: radio frequency comm.PPP
18 Frequency Selection During Data Transmission (TDMA/TDD) fk625 µsfk+1fk+2fk+3fk+4fk+5fk+6Mtsymmetricasymmetricasymmetric
19 Overall Frame Format of Bluetooth Packets The 48 bit address unique to every Bluetooth device is used as the seed to derive the sequence for hopping frequencies of the devices.Four types of access codes:Type 1: identifies a “M” terminal and its piconet addressType 2: identifies a “S” identity used to page a specific “S”.Type 3: Fixed access code reserved for the inquiry process (will be explained)Type 4: dedicated access code reserved to identify specific set of devices such as fax machines, printers, or cell phones.Header: 18 bits repeated 3 times with a 1/3 FEC codeaccess codepacket headerpayload72540-2745bitsS addresstypeflowARQNSEQNHEC3418preamblesync.(trailer)64(4)bits
20 Overall Frame Format of Bluetooth Packets S-address allows addressing the 7 possible “S” terminals in a piconetThe 4-bit packet type allows for 16 choices of different grade voice systems:6 of this payload types are asynchronous connectionless (ACL), primarily used for packet data communication3 of the payload types are synchronous connection oriented (SCO), primarily used for voice communications1 a integrated voice (SCO) and data (ACL) packet4 are control packets common for both SCO and ACL linksaccess codepacket headerpayload72540-2745bitsS addresstypeflowARQNSEQNHEC3418preamblesync.(trailer)64(4)bits
21 Control Packets Four types: ID: occupies half of a slot, and it carries the access code with no data or even a packet type codeNULL: used for ACK signaling, and there is no ACK for itPOLL: similar to the NULL, but is has an ACKNULL and POLL: have the access code and the header, and so they have packet type codes and status report bits“M” terminals use the POLL packet to find the “S” terminals in their coverage area.FHS (Frequency Hop Synchronization): carries all the information necessary to synchronize two devices in terms of access code and hopping timing. This packet is used in the inquiry and paging process explained later.
23 Connection Management In the beginning of the formation of a piconet, all devices are in SB mode, then one of the devices starts with an inquiry and becomes the “M” terminal.During the inquiry process, “M” registers all the SB terminals that then become “S” terminals. After the inquiry process, identification and timing of all “S” terminals is sent to “M” using FHS packets.The “M” terminal starts a connection with a PAGE message including its timing and ID to the “S” terminal.When the connection is established, the communication takes place, and at the end, the terminal can be sent back to SB, Hold, park or Sniff states.Standby: do nothingInquiry: search for other devicesPage: connect to a specific deviceConnected: participate in a piconet
24 Connection Management Hold, Park and Sniff are power-saving modes.The Hold mode is used when connecting several piconets or managing a low-power device.In the Hold mode, data transfer restarts as soon as the unit is out of this mode.In the Sniff mode, a slave listens to the piconet at reduced and programmable intervals according to the applications needs.In the Park mode a device gives up its MAC address but remains synchronized with the piconet.A Parked device does not participate in the traffic but occasionally listens to the traffic of “M” to resynchronize and check on broadcast messages.Park: release AMA, get PMASniff: listen periodically, not each slotHold: stop ACL, SCO still possible, possibly participate in another piconet
25 Interference Between Bluetooth and 802.11 The WLAN industry specified three levels of overlapping:Interference: multiple wireless networks are said to interfere with one another if colocation causes significant performance degradationCoexistence: multiple wireless networks are said to coexist if they can be colocated without significant impact on performance. It provides for the ability of one system to perform a task in a shared frequency band with other systems that may or may not be using the same rules for operationInteroperation: provides for an environment with multiple wireless systems to perform a given task using a single set of rules
26 Piconet P=Parked M=Master SB=Standby S=Slave Collection of devices connected in an ad hoc fashionOne unit acts as master and the others as slaves for the lifetime of the piconetMaster determines hopping pattern, slaves have to synchronizeEach piconet has a unique hopping patternParticipation in a piconet = synchronization to hopping sequenceEach piconet has one master and up to 7 simultaneous slaves (> 200 could be parked)PSSMPSBSPSBM=MasterS=SlaveP=ParkedSB=Standby
27 Forming a Piconet All devices in a piconet hop togetherMaster gives slaves its clock and device IDHopping pattern: determined by device ID (48 bit, unique worldwide)Phase in hopping pattern determined by clockAddressingActive Member Address (AMA, 3 bit)Parked Member Address (PMA, 8 bit)SBMSP
28 ScatternetLinking of multiple co-located piconets through the sharing of common master or slave devicesDevices can be slave in one piconet and master of anotherCommunication between piconetsDevices jumping back and forth between the piconetsMSPSBPiconets(each with acapacity of< 1 Mbit/s)M=MasterS=SlaveP=ParkedSB=Standby
29 WPAN: IEEE 802.15-1 – Bluetooth Data rateSynchronous, connection-oriented: 64 kbit/sAsynchronous, connectionless433.9 kbit/s symmetric723.2 / 57.6 kbit/s asymmetricTransmission rangePOS (Personal Operating Space) up to 10 mwith special transceivers up to 100 mFrequencyFree 2.4 GHz ISM-bandSecurityChallenge/response (SAFER+), hopping sequenceCost50€ adapter, drop to 5€ if integratedAvailabilityIntegrated into some products, several vendorsConnection set-up timeDepends on power-modeMax. 2.56s, avg. 0.64sQuality of ServiceGuarantees, ARQ/FECManageabilityPublic/private keys needed, key management not specified, simple system integrationSpecial Advantages/DisadvantagesAdvantage: already integrated into several products, available worldwide, free ISM-band, several vendors, simple system, simple ad-hoc networking, peer to peer, scatternetsDisadvantage: interference on ISM-band, limited range, max. 8 devices/network&master, high set-up latency
30 WPAN: IEEE 802.15 – future developments 1 : CoexistenceCoexistence of Wireless Personal Area Networks (802.15) and Wireless Local Area Networks (802.11), quantify the mutual interference: High-RateStandard for high-rate (20Mbit/s or greater) WPANs, while still low-power/low-costData Rates: 11, 22, 33, 44, 55 Mbit/sQuality of Service isochronous protocolAd hoc peer-to-peer networkingSecurityLow power consumptionLow costDesigned to meet the demanding requirements of portable consumer imaging and multimedia applications
31 WPAN: IEEE 802.15 – future developments 2 : Low-Rate, Very Low-PowerLow data rate solution with multi-month to multi-year battery life and very low complexityPotential applications are sensors, interactive toys, smart badges, remote controls, and home automationData rates of kbit/s, latency down to 15 msMaster-Slave or Peer-to-Peer operationSupport for critical latency devices, such as joysticksCSMA/CA channel access (data centric), slotted (beacon) or unslottedAutomatic network establishment by the PAN coordinatorDynamic device addressing, flexible addressing formatFully handshaked protocol for transfer reliabilityPower management to ensure low power consumption16 channels in the 2.4 GHz ISM band, 10 channels in the 915 MHz US ISM band and one channel in the European 868 MHz band
32 Why not use Wireless LANs? BluetoothWhy not use Wireless LANs?- power- costA cable replacement technology1 Mb/s symbol rateRange 10+ metersSingle chip radio + basebandat low power & low price point ($5)
33 IEEE 802.11: Classical WLANs Replacement for Ethernet Supported data rates11, 5.5, 2, 1 Mbps; and recently up to 2.4 GHzup to 54 Mbps in 5.7 GHz band ( a)RangeIndoor metersOutdoor: 50 – 100 metersTransmit power up to 100 mWCost:Chipsets $ 35 – 50AP $200 - $1000PCMCIA cards $100 - $150
34 blurring the distinction Emerging LandscapeIEEEBluetooth802.11b for PDAsBluetooth for LAN accessNew developments areblurring the distinctionCordlessheadsetLAN APWhich option is technically superior ?What market forces are at play ?What can be said about the future ?
35 Bluetooth Working Group History February 1998: The Bluetooth SIG is formedpromoter company group: Ericsson, IBM, Intel, Nokia, ToshibaMay 1998: Public announcement of the Bluetooth SIGJuly 1999: 1.0A spec (>1,500 pages) is publishedDecember 1999: ver. 1.0B is releasedDecember 1999: The promoter group increases to 93Com, Lucent, Microsoft, MotorolaMarch 2001: ver. 1.1 is releasedAug 2001: There are 2,491+ adopter companies
41 Bluetooth Specifications ApplicationsHCIIPSDPRFCOMMDataAudioL2CAPSingle chip with RS-232,USB, or PC card interfaceLink ManagerBasebandRFA hardware/software/protocol descriptionAn application framework
42 Interoperability & Profiles ApplicationsRepresents default solution for a usage modelVertical slice through the protocol stackBasis for interoperability and logo requirementsEach Bluetooth device supports one or more profilesProtocolsProfiles
43 Bluetooth Profiles (in version 1.2 release) Generic AccessService DiscoveryCordless TelephoneIntercomSerial PortHeadsetDial-up NetworkingFaxLAN AccessGeneric Object ExchangeObject PushFile TransferSynchronization
47 EM Spectrum ISM band 902 – 928 Mhz2.4 – Ghz5.725 – GhzISM bandAM radioS/W radioFM radioTVTVcellularLFHFVHFUHFSHFEHFMF30kHz300kHz3MHz30MHz300MHz30GHz300GHz10km1km100m10m1m10cm1cm100mm3GHzX raysGamma raysinfraredvisibleUV1 kHz1 MHz1 GHz1 THz1 PHz1 EHzPropagation characteristics are different in each frequency band
49 Bluetooth Radio Link frequency hopping spread spectrum 1Mhz. . .1237983.5 Mhzfrequency hopping spread spectrum2.402 GHz + k MHz, k=0, …, 781,600 hops per secondGFSK modulation1 Mb/s symbol ratetransmit power0 dbm (up to 20dbm with power control)
51 Baseband Applications Control Applications Data Control Data Baseband IPSDPRFCOMMRFBasebandAudioLink ManagerL2CAPDataControlSDPRFCOMMIPApplicationsDataAudioL2CAPLink ManagerBasebandRF
52 Bluetooth Physical Link Point to point linkmaster - slave relationshipradios can function as masters or slavesmssmPiconetMaster can connect to 7 slavesEach piconet has max capacity =1 Mbpshopping pattern is determined by the master
53 Connection Setup Inquiry - scan protocol to learn about the clock offset and device address of other nodes in proximity
54 Inquiry on Time Axis f1 f2 Slave1 Inquiry hopping sequence Master
55 Piconet Formation Page - scan protocol MasterActive SlaveParked SlaveStandbyPage - scan protocolto establish links with nodes in proximity
56 Addressing Bluetooth device address (BD_ADDR) 48 bit IEEE MAC addressActive Member address (AM_ADDR)3 bits active slave addressall zero broadcast addressParked Member address (PM_ADDR)8 bit parked slave address
57 Piconet Channel m s1 s2 FH/TDD f1 f2 f3 f4 f5 f6 625 sec 1600 hops/sec
58 Multi Slot Packets m s1 s2 Data rate depends on type of packet FH/TDD 625 µsecData rate depends on type of packet
59 Physical Link Types Asynchronous Connection-less (ACL) Link Synchronous Connection Oriented (SCO) Linkslot reservation at fixed intervalsAsynchronous Connection-less (ACL) LinkPolling access methodSCOSCOACLACLmIf there is no data to be sent on the ACL link and no polling is required, no transmission shall take place.If a slave fails to decode the slave address in the packet header, it is not allowed to transmit in the next slot.However, on an SCO link, the slave can go ahead and transmit in its allocated slot even if the decoding fails in the preceding slot.SCO slave shall not transmit in its allocated slot if a different slave was addressed in the previous master-to-slave slot.A collision can happen when a slave incorrectly decodes a packet addressed to another slave and respondss1s2
60 Packet Types Data/voice Control packets packets Voice data ID* Null PollFHSDM1HV1HV2HV3DVDM1DM3DM5DH1DH3DH5Add channel mapping discussion here:Link Control Channel (packet header)Link Management channelL2CAPSCO
61 Packet Format 72 bits 54 bits 0 - 2744 bits Access code Header Payload VoiceheaderDataCRCNo CRCNo retriesARQFEC (optional)FEC (optional)Mention that over SCO link you cannot carry any other real-time traffic. There is no protocol-id field in the SCO header/payload. Is this really true?625 µsmasterslave
63 Packet Header m s Purpose Max 7 active slaves Addressing (3) 54 bitssmAccesscodeHeaderPayloadPurposeMax 7 active slavesAddressing (3)Packet type (4)Flow control (1)1-bit ARQ (1)Sequencing (1)HEC (8)16 packet types (some unused)Broadcast packets are not ACKedHow useful is header protection when payload is unprotectedFor filtering retransmitted packetsVerify header integritytotal18 bitsEncode with 1/3 FEC to get 54 bits
68 Scatternet, Scenario 2 How to schedule presence in two piconets? Forwarding delay ?Missed traffic?
69 Baseband: Summary TDD, frequency hopping physical layer L2CAPLMPPhysicalData linkDevice 2Device 1TDD, frequency hopping physical layerDevice inquiry and pagingTwo types of links: SCO and ACL linksMultiple packet types (multiple data rates with and without FEC)
70 Link Manager Protocol Applications Control Data Setup and management RFBasebandAudioLink ManagerL2CAPDataControlSDPRFCOMMIPApplicationsSetup and managementof Baseband connectionsPiconet ManagementLink ConfigurationSecurityLMP
71 Piconet Management m s Attach and detach slaves Master-slave switch Establishing SCO linksHandling of low power modes ( Sniff, Hold, Park)PagingsmreqMasterSlaveresponse
72 Low Power Mode (hold)Hold offsetSlaveHold durationMaster
73 Low Power Mode (Sniff) Traffic reduced to periodic sniff slots Sniff offsetSniff durationSlaveSniff periodMasterTraffic reduced to periodic sniff slots
74 Low Power Mode (Park)SlaveBeacon instantMasterBeacon intervalPower saving + keep more than 7 slaves in a piconetGive up active member address, yet maintain synchronizationCommunication via broadcast LMP messages
75 Connection Establishment & Security GoalsAuthenticated accessOnly accept connections from trusted devicesPrivacy of communicationprevent eavesdroppingPagingLMP_host_conn_reqLMP AcceptedConstraintsProcessing and memory limitations$10 headsets, joysticksCannot rely on PKISimple user experienceSecurity procedureMasterSlaveLMP_setup_completeLMP_setup_complete
76 AuthenticationAuthentication is based on link key (128 bit shared secret between two devices)How can link keys be distributed securely ?challengeresponseVerifierClaimantacceptedLink keyLink key
77 Pairing (Key Distribution) Pairing is a process of establishing a trusted secret channel between two devices (construction of initialization key Kinit)Kinit is then used to distribute unit keys or combination keysPIN +ClaimantaddressPIN +ClaimantaddressVerifierClaimantRandom numberchallengeRandomnumberresponseRandomnumberacceptedKinitKinit
78 Link Manager Protocol Summary BasebandL2CAPLMPPhysicalData linkDevice 2Device 1Piconet managementLink configurationLow power modesQoSPacket type selectionSecurity: authentication and encryption
79 Logical Link Control and L2CAPApplicationsLogical Link Control andAdaptation ProtocolIPSDPRFCOMMDataL2CAP providesProtocol multiplexingSegmentation and Re-assemblyQuality of service negotiationAudioL2CAPLink ManagerBasebandRF
80 Logical Link Control and L2CAPApplicationsLogical Link Control andAdaptation ProtocolIPSDPRFCOMMDataL2CAP providesProtocol multiplexingSegmentation and Re-assemblyQuality of service negotiationAudioL2CAPLink ManagerBasebandRF
81 Why baseband isn’t sufficient? IPRFCOMMMultiplexingdemultiplexingMTUBaseband provides hard coded choices for ARQ and FEC. How good those choices are in providing good quality of service. Would it be better to provide more flexibility to the higher layers?reliable*, flow controlledBasebandin-sequence, asynchronous linkBaseband packet size is very small (17min, 339 max)No protocol-id field in the baseband header
82 Need a Multiprotocol Encapsulation Layer RFCOMMIPRFCOMMunreliable,no integrityreliable*, in-order,flow controlled, ACL linkBaseband provides hard coded choices for ARQ and FEC. How good those choices are in providing good quality of service. Would it be better to provide more flexibility to the higher layers?If we were to define another adaptation layer on top of SCO link, what would it look like?What problem you’ll run into if you try to use L2CAP segmentation/reassembly over multihop links? Ans: L2CAP fragments have no-id. It is impossible to distinguish one fragment from the other.What is the use of the flow-control bit in the ACL payload header? How is it different from the Flow bit in the baseband header?How about ARQ at L2CAP layer and no reliability at Baseband?What aboutReliability?Connection oriented or connectionless?integrity checks?Desired featuresProtocol multiplexingSegmentation and re-assemblyQuality of service
83 Segmentation and Reassembly LengthPayloadBasebandpacketsCRCCRCCRCMin MTU = 48 equals two DH1 packets – 6 (l2cap header) = 48.Default MTU = 672 equals two DH5 packets – 6 = 672.Analyze how well links be utilized for different combinations of higher layer MTU, negotiated L2CAP MTU, and choice of packet types.start ofL2CAPcontinuationof L2CAPcontinuationof L2CAPcannot cope with re-ordering or lossmixing of multiple L2CAP fragments not allowedIf the start of L2CAP packet is not acked, the rest should be discardedmin MTU = 48672 default
84 Multiplexing and Demultiplexing RFCOMMIPRFCOMMCircuit or connection-less ?Why is L2CAP connection oriented ?Baseband is polling basedBandwidth efficiency- carry state in each packet Vs. maintain it at end-pointsNeed ability for logical link configurationMTUreliability (Flush timeout option)QoS (token bucket parameter negotiation)Evaluate design choices of L2CAP.Simplicity was one of the goals, but was it achieved?Parameter negotiation adds complexity and extra round trips. Since memory and processing are becoming cheap, it is not clear if the flexibility offered by parameter negotiation buys anything at all.MTU, reliability, and QoS should be link properties, not per L2CAP connection properties. I wonder how often different protocols will use different params for L2CAP connection.
86 L2CAP Connection: an Example InitiatorTargetL2CAP_ConnectReqEstablishmentL2CAP_ConnectRspL2CAP_ConfigReqConfigurationL2CAP_ConfigRspMTU, QoSreliabilityL2CAP_ConfigReqL2CAP_ConfigRspData transferL2CAP_DisconnectReqTerminationL2CAP_DisconnectRsp
87 L2CAP Packet Format (Connectionless) LengthDCIDPayload22+0 – 64KPSMNot fully developed yet.
88 L2CAP: Summary Design constraints: Assumptions about the lower layer SimplicityLow overheadLimited computation and memoryPower efficientAssumptions about the lower layerReliable, in-order delivery of fragmentsIntegrity checks on each fragmentAsynchronous, best effort point-to-point linkNo duplicationFull duplexFood for thought:L2CAP header has no protection at all. Length field is the only protection. Which other protocol has similar header?Comment:- Protocol designed fora specific link- L2CAP over othermedia will not work!Service provided to the higher layerProtocol multiplexing and demultiplexingLarger MTU than basebandPoint to point communication
89 Bluetooth Service Discovery Protocol ApplicationsIPSDPRFCOMMDataAudioL2CAPLink ManagerBasebandRF
90 Example usage of SDP Establish L2CAP connection to remote device Query for servicessearch for specific class of service, orbrowse for servicesRetrieve attributes that detail how to connect to the serviceEstablish a separate (non-SDP) connection to use the service
91 Serial Port Emulation using RFCOMM ApplicationsIPSDPRFCOMMDataSerial Port emulation on top of a packet oriented linkSimilar to HDLCFor supporting legacy appsAudioL2CAPLink ManagerBasebandRF
92 Serial Line Emulation over Packet based MAC RFCOMMRFCOMML2CAPL2CAPDesign considerationsframing: assemble bit stream into bytes and, subsequently, into packetstransport: in-sequence, reliable delivery of serial streamcontrol signals: RTS, CTS, DTR
93 IP over Bluetooth V 1.0 Applications GOALS Data SDPRFCOMMGOALSDataInternet access using cell phonesConnect PDA devices & laptop computers to the Internet via LAN access pointsAudioL2CAPLink ManagerBasebandRF
94 LAN Access Point Profile IPAccess PointPPPSecurityAuthenticationAccess controlEfficiencyheader and data compressionAuto-configurationLower barrier for deploymentWhy use PPP?RFCOMML2CAPBaseband
95 Inefficiency of Layering PalmtopLAN access pointIPIPpacket orientedPPPPPPrfc 1662byte orientedrfc 1662RFCOMMRFCOMMpacket orientedL2CAPL2CAPEmulation of RS-232 over the Bluetooth radio link could be eliminated
96 Terminate PPP at LAN Access Point PalmtopAccess PointIPIPPPPPPPethernetRFCOMMRFCOMMBluetoothBluetoothPPP server function at each access pointmanagement of user name/password is an issueroaming is not seamless
97 L2TP TunnelingPalmtopAccess PointPPP serverIPIPPPPPPPethernetIPUDPethernetIPUDPRFCOMMRFCOMMBluetoothBluetoothTunneling PPP traffic from access points to the PPP server1) centralized management of user name/password2) reduction of processing and state maintenance at each access point3) seamless roaming
98 Seamless Roaming with PPP REQ1ServerCLR5RPL4REQ3RPL2AP1AP2MAC level handoffMAC level registrationPPPPPPpalmtop
99 IP over Bluetooth v 1.1: BNEP Access PointIPBluetooth Network EncapsulationProtocol (BNEP) provides emulation ofEthernet over L2CAPBNEPBNEP definesa frame format which includes IEEE 48 bit MAC addressesA method for encapsulating BNEP frames using L2CAPOption to compress header fields to conserve spaceControl messages to activate filtering of messages at Access PointL2CAPBaseband
102 Bluetooth Value Chain Wireless Carriers Stack providers Software ConspicuouslymissingStackprovidersSoftwarevendorsIntegratorsSiliconRadio
103 Value to Carriers: Synchronization and Push More bits over the airUtilization of unused capacity during non-busy periodsHigher barrier for switching service providers
104 Value to Carriers: Cell phone as an IP Gateway Will Pilot and cell phone eventually merge?More bits over the airEnhanced user experiencePalmpilot has a better UI than a cell phoneGrowth into other vertical markets
105 Value to Carriers: Call Handoff Cordless baseThreatoropportunity?More attractive calling plansAlleviate system load during peak periodsServe more users with fewer resources
106 Biggest Challenges facing Bluetooth InteroperabilityAlways a challenge for any new technologyHyped up expectationsOut of the box ease of useCost target $5Critical massRF in siliconConflicting interests – business and engineering
107 References IEEE , “Wireless LAN MAC and Physical Layer Specification,” June 1997. Hirt, W.; Hassner, M.; Heise, N. “IrDA–VFIr (16 Mb/s): modulation code and system design.” IEEE Personal Communications, vol.8, (no.1), IEEE, Feb Lansford, J.; Bahl, P. “The design and implementation of HomeRF: a radio frequency wireless networking standard for the connected home.” Proceedings of the IEEE, IEEE, Oct Specification of Bluetooth System, ver. 1.0, July 1999
108 References (cnt) Haartsen, J.C. “The Bluetooth radio system.”, IEEE Personal Communications, IEEE, Feb Haartsen, J.C. ‘Bluetooth towards ubiquitous wireless connectivity.’, Revue HF, Soc. Belge Ing. Telecommun. & Electron, p.8–16. Rathi, S. “Bluetooth protocol architecture.” Dedicated Systems Magazine, Dedicated Systems Experts, Oct.–Dec Haartsen, J.C.; Mattisson, S. “Bluetooth–a new low–power radio interface providing short–range connectivity.” Proceedings of the IEEE, IEEE, Oct Gilb, J.P.K “Bluetooth radio architectures.” 2000 IEEE Radio Frequency Integrated Circuits (RFIC) Symposium Digest of Papers, Boston, MA, USA, 11–13 June 2000.
109 References (cnt) N. Benvenuto, G. Cherubini, “Algoritmi e circuiti per le telecomunicazioni”, Ed. Libreria Progetto. The Bluetooth Special Interest Group, Documentation available at IEEE Working Group for WPANs™; Barker, P.; Boucouvalas, A.C.; Vitsas, V. “Performance modelling of the IrDA infrared wireless communications protocol.” International Journal of Communication Systems, vol.13, Wiley, Nov.–Dec Tokarz, K.; Zielinski, B. “Performance evaluation of IrDA wireless transmission.” 7th Conference on Computer Networks, Zakopane, Poland, 14–16 June 2000. ETSI RES, “Digital European Cordless Telecommunications (DECT), Common interface Part 1: Overview,” ETS –1, 1996.