posted by bluelimn 2017.10.17 17:03

 http://www.ledsmagazine.com/articles/print/volume-13/issue-3/features/smart-lighting/bluetooth-mesh-what-s-that-noise-about.html

Bluetooth Mesh - What's that noise about? (MAGAZINE)

    

Coming Bluetooth extensions will make the wireless technology a better fit for smart lighting, explains MAREK WIERZBICKI, while mesh extensions will retain the low power, ease of use, and reliability of the proven radio technology.

 

Smart lighting might be the biggest revolution the lighting industry has seen in decades, but the multitude of available wireless communication technologies can cause a real headache for manufacturers willing to delve into this new, exciting market. Bluetooth is the latest talk of the town with its mesh networking support to be adopted later this year. We at Silvair have been deeply involved in the Bluetooth Smart Mesh Working Group's efforts aimed at standardizing a Bluetooth-based mesh architecture, and this examination of the basic concepts behind one approach to a Bluetooth Mesh implementation will give you an idea as to what Bluetooth Smart mesh networking is all about.

Interested in more articles & announcements on smart lighting?

Lighting standards we've all known for years are now being challenged by the next generation of lighting systems that promise to deliver so much more than just a well-lit space. The transition toward digital lighting is happening right in front of our eyes, and while a couple of months ago many had doubts as to whether smart lighting could be a real deal, it now seems that there is no turning back. Over the last 12 months, we've seen multiple heavyweight lighting manufacturers spinning off big chunks of their traditional businesses to put more focus on connected technologies (See LEDs Magazinecoverage of Osram). Smart lighting promises new business models with a steady stream of revenue from value-added features and services, which is exactly what lighting companies need to overcome the challenges resulting from the impressive longevity of LEDs and razor-thin margins in the LED market.

SPONSORED CONTENT BY Bluetooth®‎ ?

Bluetooth Mesh Shows Wireless Connectivity in a Whole New Light

Many of today’s wireless platforms—especially those supported by a Bluetooth® mesh network—ensure greater flexibility and extensibility at a much lower cost than a wired system can provide.

FIG. 1. There were a number of Bluetooth-based, mesh-enabled lighting products at the Consumer Electronics Show (CES) in 2016 including a lamp from Girard Sudron and a switch from NodOn.

FIG. 1. There were a number of Bluetooth-based, mesh-enabled lighting products at the Consumer Electronics Show (CES) in 2016 including a lamp from Girard Sudron and a switch from NodOn.

Moving to networks

It is therefore not surprising that virtually every week we are hearing news about lighting manufacturers entering into agreements with companies that can relatively swiftly implement smart technologies into their products, or even straightforwardly acquiring providers of wireless connectivity, cloud services, or advanced data analytics. Things have gone so far that we've already seen Goldman Sachs downgrading its rating on one of the leading lighting manufacturers, citing concerns over the company's deteriorating earnings and emphasizing its low exposure to connected technologies. The trend is clear: Lighting systems are becoming digital, and a wide variety of smart lighting products (Fig. 1) presented at CES (Consumer Electronics Show) 2016 only confirms this.

That said, there is still no consensus regarding the wireless communication protocol that could be the go-to technology for lighting applications, let alone the entire Internet of Things (IoT). Countless times has it been said that the lack of interoperability is a major obstacle to mass adoption of connected solutions, but instead of some sort of standardization, we're only seeing things getting more and more fragmented. New technologies keep emerging, each claiming to have exactly what it takes to enable seamless, robust, and secure connectivity in the Internet of Things (IoT).

In the meantime, the more mature communication standards keep evolving to address the dynamically changing customer needs, as many of them were introduced to the market when expectations and hype surrounding the IoT and connected spaces were nowhere near as big as they are today. What's more, certain product categories did not even exist back then, with smart lighting being a perfect example of a segment that has come a long way from nonexistence to being one of the hottest smart building automation segments over just a couple of years.

One of those mature standards is Bluetooth, a wireless communication protocol that seems to have been around forever and thus enjoys unmatched brand recognition. However, for certain very specific reasons, it is currently not being considered a viable option for advanced building automation solutions. The Bluetooth Special Interest Group (SIG), a 28,000-member strong body that oversees the development of Bluetooth standards, claims this is about to change once the mesh networking support is introduced into the protocol's core specification. We are only a couple of months away from this release, so let's see what's coming.

Bluetooth Classic versus Bluetooth Smart

All that noise surrounding Bluetooth might be somewhat confusing for those not too familiar with the recent developments in the wireless communication landscape. After all, the protocol was first developed before the term "Internet of Things" was even coined. But what many are still not aware of is that the Bluetooth of today is something completely different than Bluetooth of the past.

FIG. 2. Legacy Bluetooth has relied on a hub-and-spoke topology while commercial smart lighting will require a mesh network for communications.

FIG. 2. Legacy Bluetooth has relied on a hub-and-spoke topology while commercial smart lighting will require a mesh network for communications.

The original Bluetooth, known as Bluetooth Classic, was designed as a short-range, cable-replacement technology for point-topoint communications. Initially, the main goal was to synchronize data between mobile phones, but the standard quickly became the default technology for wireless data exchange between personal computing equipment (mobile phones, PCs, PDAs) and peripherals (headsets, cordless keyboards and mice, printers, and such). Devices could form a tiny personal area network (PAN) called a piconet, whereby a single central device would coordinate the activity of up to seven active peripherals.

Fast-forward to 2010, the Bluetooth Core Specification version 4.0 is released, introducing Bluetooth Low Energy (BLE), more commonly known as Bluetooth Smart. This is where the story of Bluetooth in the IoT really begins. Bluetooth Smart was designed specifically to address the needs of a new generation of smart devices, many of which are battery-powered and therefore require fast connection times and efficient power management to reduce unnecessary energy consumption.

The new specification extended Bluetooth's usefulness to a whole new range of products, ultimately making it a default technology for all kinds of wearable devices. But despite some really outstanding features of the Bluetooth Smart radio, the protocol didn't make any significant impact in the building automation segment. Smart homes were dominated by other low-power technologies, mainly ZigBee and Z-Wave, and wireless communication never really took off in commercial spaces. Due to certain important drawbacks of the available low-power communication standards, building managers preferred to stick to wired solutions, considering them way more reliable.

The reason why Bluetooth Smart was never considered a serious contender for building automation purposes is because it was designed to support relatively simple hub-and-spoke networks (Fig. 2). Applications like smart lighting require much more than that. Peer-to-peer communication and extended range are among the must-have features enabling a robust network consisting of multiple smart bulbs, and the core specification of Bluetooth Smart simply didn't provide such capability. Its hub-and-spoke model couldn't match with the mesh topology of ZigBee or Z-Wave networks, and for this reason Bluetooth could never really compete with the two in the applications they were intended for.

Is this meshable?

Even though the support for mesh networking wasn't included in the core specification of Bluetooth Smart, several companies noticed that building a mesh network based on this particular communication standard might not be such a bad idea. In 2014, Silvair (operating as Seed Labs back then) started building a mesh architecture based on Bluetooth Smart. Transforming the protocol's single-hop topology into a robust multi-hop, peer-to-peer network was quite a challenge, but the potential reward was enormous.

A mesh network based on Bluetooth Smart also turned out to offer outstanding performance and the core features of the Bluetooth radio allowed us to overcome many of the challenges that other communication protocols have a hard time dealing with. Obviously, the technology developed by Silvair was proprietary, although we did manage to maintain compliance with Bluetooth Smart's core specification.

Having received a fair amount of input from Silvair and other companies working on their proprietary mesh solutions, the Bluetooth Special Interest Group realized that such an opportunity cannot be wasted. In February 2015, it announced the formation of the Bluetooth Smart Mesh Working Group. Its goal was to standardize mesh networking support and incorporate it into the protocol's core specification. Competing companies sat down to share their experiences and find the best way to implement the mesh architecture into Bluetooth Smart. Near the end of 2015, the SIG officially confirmed that it's on track with the development of the Bluetooth Mesh, and that the standard would be adopted at some point in 2016. Moreover, some major improvements with regard to both the data rate and range of Bluetooth Smart will be included in the new standard.

The standardized mesh architecture based on Bluetooth Smart is shaping up to be a powerful framework enabling robust and scalable implementations in some of the most challenging applications. Being part of that development process and seeing many of our concepts being incorporated into the global standard is a great feeling. We are currently among the leading contributors to the Bluetooth Smart Mesh Working Group. The details about the upcoming mesh standard remain strictly confidential until some official announcements are made by the SIG itself, but we can provide you with a sneak peek into the basic concepts behind our Silvair Mesh technology, which might give you a good idea of what Bluetooth-based mesh networking is all about.

Meet a mesh

Silvair Mesh has been developed to allow users to build their smart mesh networks in which one or more mobile devices (smartphones/tablets) can control one or more mesh-enabled peripheral devices (e.g., lamps, sensors, dimmers, switches, etc.). When equipped with the mesh software stack, essentially an enhanced Bluetooth Smart stack, these devices can communicate with each other and the central controller via the Bluetooth Smart radio using the protocol's standard mechanisms called GATT (Generic Attribute Profile). This means that all mesh-enabled peripherals can create their own autonomous mesh network that does not require any central device to operate.

FIG. 3. Smart mesh capabilities are added to Bluetooth devices in the network, transport, and application layers in software and don't impact the physical and link layers that are captured in radio ICs and modules.

FIG. 3. Smart mesh capabilities are added to Bluetooth devices in the network, transport, and application layers in software and don't impact the physical and link layers that are captured in radio ICs and modules.

The decision to base Silvair Mesh on Bluetooth Smart was intentional, as it meant that the ecosystem would be compatible with all existing Bluetooth Smart devices and chipsets. However, a mesh stack also requires numerous additional features to standard Bluetooth Smart. For instance, the Silvair Mesh includes a high-performance Bluetooth controller and a new Network Security Manager, as well as the secure OverThe-Air Update functionality, which means that a device can be upgraded to the newest version of the firmware at any time.

Such a carefully crafted mesh software stack can be installed on any compatible Bluetooth chip. Silvair also developed a reference design for modules to provide the best possible solution for large installations such as those found in commercial buildings. These modules consist of standard Texas Instruments CC254x Bluetooth modules with upgraded firmware, an amplifier, and an antenna. Operating at +10-dBm Tx (transmit) power and with -98-dBm Rx (receive) sensitivity, the modules provide a 108-dB link budget that translates to a range of 1500 ft (about 500m) in the open air. Inside buildings, this value will obviously be much lower and dependent on numerous factors, yet it still remains impressive.

An important thing to realize is that mesh is a purely software solution. This means that Bluetooth Smart chipsets found in today's smartphones can control devices employing proprietary technologies such as Silvair Mesh, and will remain perfectly suitable for controlling and managing mesh networks once the standard is adopted by the SIG. The aforementioned software stack is applied to the networking and application layers of the standard Bluetooth Smart protocol stack as shown in Fig. 3.

How the mesh works

Now let's consider how the mesh extension works. There are two types of communication within a Silvair Mesh network: central to peripheral and peripheral to peripheral. Once the mesh network is commissioned, there is no need for further central-peripheral communication.

Central devices are usually smartphones and tablets. Such devices would typically run some type of control software. In the Silvair case, we developed an app for iOS and Android devices. The central devices are used to configure and manage the network but can also perform a software update of peripheral devices. Central devices connect to peripherals using Bluetooth Smart's standard GATT services. While this type of connection is fully compatible with Bluetooth 4.0, it employs certain proprietary techniques to allow many smartphones to be used simultaneously to control more than eight peripheral devices with eight being the limit in standard Bluetooth 4.0.

Peripheral devices are the nodes of a mesh network. A robust mesh implementation must allow peripherals to talk to each other and act as relays that pass messages through the mesh. This is a radical departure from the original architecture of Bluetooth Smart, and it allows for controlling entire groups of devices using multicast (one to many) communications - e.g., dimming a group of ceiling lights in a hallway. The Silvair Mesh implementation allows a maximum of 63 hops, which enables it to cover very extensive areas out of the box, in contrast to other technologies that require setting up more complicated or more expensive networks.

One of the most significant concepts introduced in the Silvair implementation is connectionless communication, which means that every peripheral can advertise its status in the network. As a result, lights, fans, shades, and any other mesh-enabled device are displayed automatically in the app on the central device, not only as a simple list of available devices, but with very specific parameters that can be controlled by the user - e.g., on/off, color, temperature, fan speed, or shade position. Every status change made by the user is immediately advertised to the network, and every controlling device in the mesh is updated instantly with the new status.

Network setup

As will be required in commercial applications, the Silvair Mesh software allows networks of any size to be set up, but the way in which large and small networks are commissioned, is different. Small networks of up to about 30 devices can be commissioned and managed using just the app on a smartphone or a tablet. The plug-and-play nature of Bluetooth, and the fact that the protocol is natively supported by virtually all smartphones and tablets on the market, makes the entire process extremely simple and intuitive. The app detects and displays mesh devices in its vicinity. The user creates a mesh network by selecting which devices should be added, and by giving the network a name. Once added to the network, associations and relationships can be set up between the devices as desired. The smartphone can then be switched off and these connections will remain in place (Fig. 4).

FIG. 4. Silvair Mesh supports both smaller mesh networks controlled by a single smartphone and complex networks with dedicated cloud-connected servers.

FIG. 4. Silvair Mesh supports both smaller mesh networks controlled by a single smartphone and complex networks with dedicated cloud-connected servers.

Networks of over about 30 devices, or the ones requiring more sophisticated associations, scenarios, and network monitoring services, are best set up using some type of server or management appliance. In the case of Silvair, an embedded server called Silvair Logic hosts all the logic that controls the entire network, checks the status of all peripherals, and reports any issues and unusual events via a browser-based interface.

Other mesh needs

There are a few other key elements of a Bluetooth Mesh implementation that we will mention briefly here. There needs to be a concept of permissions for control devices that ensures proper management of devices in the network. The Silvair software stack implements four levels of permissions: 1) Administrator - can operate all devices within the network, as well as configure them and manage other users' permissions; 2) Family - can operate all devices within the network, but cannot configure or manage them; 3) Guest - has limited permission to operate selected devices within the network; 4) and AdHoc - can operate public devices only on a one-to-one basis (no access to the mesh network).

Likewise, the network nodes or peripherals require the ability to provide information on their operational status and programmability. The Silvair software stack defines three Peripheral Device States: 1) Factory Default - the device leaves the factory in this state and is ready for commissioning; 2) Private - all communication is encrypted, so only users with matching keys can decrypt the state information and control the device; and 3) Public - state information, as well as selected control functions, are not encrypted and can be accessed by anyone.

The Bluetooth difference

The question one might ask at this point is why the Bluetooth Smart mesh would be any better than other mesh protocols available on the market? Simply put, it's all about the radio. Out of all low-power, low-bandwidth communication standards, none is even close to having such impressive qualities as Bluetooth Smart. This allows the protocol to address some of the most difficult issues in such challenging applications as smart lighting, where multicast, synchronous operation and responsiveness are among the must-have features.

We've tested many other technologies inside out, and we know exactly why the existing mesh protocols have failed to deliver the smart lighting experience to environments where reliability and scalability are top priorities. And we firmly believe that this year's adoption of the Bluetooth Smart mesh standard might finally open the door for smart lighting networks to become widely deployed in professional applications.


'BlueTooth > 기본기' 카테고리의 다른 글

Bluetooth Mesh - What's that noise about? (MAGAZINE)  (1) 2017.10.17
Bluetooth mesh networking From Wikipedia  (0) 2017.10.17
"블루투스의 혁신" 블루투스 메시 네트워크 표준 발표로 IoT 확산  (0) 2017.10.16
Mesh Profile  (0) 2017.10.16
Air packet에서 Bluetooth clock 확인  (0) 2017.09.08
baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
posted by bluelimn 2017.10.17 17:02

https://en.wikipedia.org/wiki/Bluetooth_mesh_networking


Bluetooth mesh networking, conceived in 2015,[1] adopted on July 13, 2017[2] is a protocol based upon Bluetooth Low Energy that allows for many-to-many communication over Bluetooth radio.

It has been defined in Mesh Profile Specification[3] and Mesh Model Specification.[4]

Overview[edit]

Communication is carried in the messages that may be up to 384 bytes long, when using Segmentation and Reassembly (SAR) mechanism, but most of the messages fit in one segment, that is 11 bytes. Each message starts with an opcode, which may be a single byte (for special messages), 2 bytes (for standard messages), or 3 bytes (for vendor-specific messages).

Every message has a source and a destination address, determining which devices process messages. Devices publish messages to destinations which can be single things / groups of things / everything.

Each message has a sequence number that protects the network against replay attacks.

Each message is encrypted and authenticated. Two keys are used to secure messages: (1) network keys – allocated to a single mesh network, (2) application keys – specific for a given application functionality, e.g. turning the light on vs reconfiguring the light.

Messages have a time to live (TTL). Each time message is received and retransmitted, TTL is decremented which limits the number of "hops", eliminating endless loops.

Bluetooth Mesh is a flood network. It's based on the nodes relaying the messages: every relay node that receives a network packet that authenticates against a known network key that is not in message cache, that has a TTL ≥ 2 can be retransmitted with TTL = TTL - 1. Message cache used to prevent relaying messages recently seen.

Bluetooth Mesh has a layered architecture, with multiple layers as below.

LayerFunctionality
Model LayerIt defines a standard way to exchange application specific messages. For example, a Light Lightness Model defines an interoperable way to control lightness. There are mandatory models, called Foundation Models, defining states and messages needed to manage a mesh network.
Access LayerIt defines mechanism to ensure that data is transmitted and received in the right context of a model and its associated application keys.
Upper Transport LayerIt defines authenticated encryption of access layer packets using an application (or device specific key). It also defines some control messages to manage Friendship or to notify the behavior of node using Heartbeat messages.
Lower Transport LayerThis layer defines a reliable (through a Block Acknowledgement) Segmented transmission upper layer packets, when a complete upper layer packet can't be carried in a single network layer packet. It also defines a mechanism to reassemble segments on the receiver.
Network LayerThis layer defines how transport packets are addressed over network to one or more nodes. It defines relay functionality for forwarding messages by a relay node to extended the range. It handles the network layer authenticated encryption using network key.
Bearer LayerIt defines how the network packets are exchanged between nodes. Mesh Profile Specification defines BLE advert bearer and BLE GATT bearer. Mesh Profile defines Proxy Protocol, through which mesh packets can be exchanged via other bearers like TCP/IP.

Theoretical limits[edit]

It's yet to be determined what are the practical limits of Bluetooth Mesh technology. There are some limits that are built into the specification, though:

Limit for a networkValueRemarks
Maximum number of nodes32 767The limit is 32768 addresses and while a node may occupy more than one address, practical limit is most likely lower
Maximum number of groups16 384

Number of virtual groups is 2128.

Maximum number of scenes65 535
Maximum number of subnets4 096
Maximum TTL127

Mesh models[edit]

As of version 1.0 of Bluetooth Mesh specification, the following standard models and model groups have been defined:

Foundation models[edit]

Foundation models have been defined in the core specification. Two of them are mandatory for all mesh nodes.

  • Configuration Server (mandatory)
  • Configuration Client
  • Health Server (mandatory)
  • Health Client

Generic models[edit]

  • Generic OnOff Server, used to represent devices that do not fit any of the model descriptions defined but support the generic properties of On/Off
  • Generic Level Server, keeping the state of an element in a 16-bit signed integer
  • Generic Default Transition Time Server, used to represent a default transition time for a variety of devices
  • Generic Power OnOff Server & Generic Power OnOff Setup Server, used to represent devices that do not fit any of the model descriptions but support the generic properties of On/Off
  • Generic Power Level Server & Generic Power Level Setup Server, including a Generic Power Actual state, a Generic Power Last state, a Generic Power Default state and a Generic Power Range state
  • Generic Battery Server, representing a set of four values representing the state of a battery
  • Generic Location Server & Generic Location Setup Server, representing location information of an element, either global (Lat/Lon) or local
  • Generic User/Admin/Manufacturer/Client Property Server, representing any value to be stored by an element
  • Generic OnOff Client & Generic Level Client
  • Generic Default Transition Time Client
  • Generic Power OnOff Client & Generic Power Level Client
  • Generic Battery Client
  • Generic Location Client
  • Generic Property Client

Sensors[edit]

  • Sensor Server & Sensor Setup Server, representing a sensor device. Sensor device may be configured to return a measured value periodically or on request; measurement period (cadence) may be configured to be fixed or to change, so that more important value range is being reported faster.
  • Sensor Client

Time and scenes[edit]

  • Time Server & Time Setup Server, allowing for time synchronization in mesh network
  • Scene Server & Scene Setup Server, allowing for up to 65535 scenes to be configured and recalled when needed.
  • Scheduler Server & Scheduler Setup Server
  • Time Client, Scene Client & Scheduler Client

Lighting[edit]

  • Light Lightness Server & Light Lightness Setup Server, representing a dimmable light source
  • Light CTL Server, Light CTL Temperature Server & Light CTL Setup Server, representing a CCT or "tunable white" light source
  • Light HSL Server, Light HSL Hue Server, Light HSL Saturation Server & Light HSL Setup Server, representing a light source based on Hue, Saturation, Lightness color representation
  • Light xyL Server & Light xyL Setup Server, representing a light source based on modified CIE xyY color space.
  • Light LC (Lightness Control) Server & Light LC Setup Server, representing a light control device, able to control Light Lightness model using an occupancy sensor and ambient light sensor. It may be used for light control scenarios like Auto-On, Auto-Off and/or Daylight Harvesting.
  • Light Lightness Client, Light CTL Client, Light HSL Client, Light xyL Client & Light LC Client

Provisioning[edit]

Provisioning is a process of installing the device into a network. It is a mandatory step to build a Bluetooth Mesh network.

In the provisioning process, a provisioner securely distributes a network key and a unique address space for a device. Provisioning protocol uses P256 Elliptic Curve Diffie-HellmanKey Exchange to create a temporary key to encrypt network key and other information. This provides security from a passive eavesdropper. It also provides various authentication mechanisms to protect network information, from an active eavesdropper who uses Man-In-The-Middle attack, during provisioning process.

A key unique to a device known as "Device Key" is derived from elliptic curve shared secret on provisioner and device during the provisioning process. This device key is used by the provisioner to encrypt messages for that specific device.

Terminology used in Bluetooth mesh networking specification[edit]

  • Destination: The address to which a message is sent.
  • Element: An addressable entity within a device.
  • Model: Standardized operation of typical user scenarios.
  • Node: A provisioned device.
  • Provisioner: A node that can add a device to a mesh network.
  • Relay: A node able to retransmit messages.
  • Source: The address from which a message is sent.


'BlueTooth > 기본기' 카테고리의 다른 글

Bluetooth Mesh - What's that noise about? (MAGAZINE)  (1) 2017.10.17
Bluetooth mesh networking From Wikipedia  (0) 2017.10.17
"블루투스의 혁신" 블루투스 메시 네트워크 표준 발표로 IoT 확산  (0) 2017.10.16
Mesh Profile  (0) 2017.10.16
Air packet에서 Bluetooth clock 확인  (0) 2017.09.08
baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
posted by bluelimn 2017.10.16 17:54

원문보기: 
http://www.itworld.co.kr/news/105679#csidxa5d4a62d448be1a929a02c4376d2927 

by ItWord : Peter Sayer | IDG News Service



블루투스에 새로운 메시(mesh) 네트워킹 기능이 곧 구현된다. 무엇보다 좋은 점은 새로운 하드웨어가 없어도 활용이 가능하다는 것이다.

메시 네트워킹을 사용하면 산업 현장에서 센서를 연결하거나 스마트 홈 또는 건물 자동화 네트워크를 생성하는 과정이 더 간편해진다. 기기는 멀리 떨어진 게이트웨이까지 메시지를 전달할 필요없이 가까운 이웃에게 메시지를 전달하도록 요청하면 된다.


Credit: Stephen Lawson

이는 기기에서 사물인터넷에 참여할 수 있는 새로운 방법을 제공한다. 블루투스 표준을 관할하는 기구인 블루투스 SIG의 기술 프로그램 관리자 마틴 울리는 "예를 들어 건물에서 조명 제어 용도로 메시 네트워크를 구축할 경우 다른 기기에서 자산 추적, 길찾기 등 다른 분야를 위한 무선 인프라로 이 네트워크를 사용할 수 있다"고 말했다.

블루투스는 메시 네트워킹을 저전력 블루투스(Bluetooth Low Energy, BLE)에 구축된 네트워킹 토폴로지로 취급하므로 이를 지원하는 기기가 있다면 소프트웨어 업데이트를 통해 메시에 참여할 수 있을 가능성이 높다. 스마트폰과 태블릿도 마찬가지다. BLE를 지원한다면 앱만 있으면 바로 메싱을 시작할 수 있다.

지난 7월 18일, 블루투스 메시 네트워킹 표준 버전 1.0이 발표되어 호환 기기가 앞다퉈 등장하겠지만 이미 경주는 진행 중이다.

울리는 "일반적인 블루투스 SIG 워킹 그룹에 참여하는 기업 수가 10~20개 정도인데 반해 블루투스 메시 네트워킹 개발 워킹 그룹에는 120여 개의 기업이 참여한만큼 업계는 이미 이 사양의 요구사항을 잘 파악하고 있다"고 말했다.

요구사항 테스트도 이미 마쳤다. 울리는 "테스트를 해야 사양을 완성할 수 있다. 이미 15개의 테스팅 이벤트를 통해 전체 사양을 다뤘다"고 밝혔다. 울리는 블루투스 메시 스택이 있는 하드웨어 모듈이 몇 개월 내에 시장에 등장할 것이라고 말했다. 업체에서 부가적인 소프트웨어를 명분으로 더 높은 가격을 요구할 수 있지만 울리는 자신이 아는 한 새로운 기능을 이용하기 위해 필요한 부가적인 특허 라이선스는 없다고 전했다.

블루투스 메시 네트워크에서는 노드가 생성되는 방법이 각기 다르다. 조명 기구의 컨트롤러와 같이 전력이 충분히 공급되는 장치도 있고, 전등 스위치나 온도 센서와 같이 배터리 하나로 수년 동안 작동해야 하는 장치도 있기 때문이다. 사양은 이런 기기에서 에너지를 절약할 수 있는 두 가지 방법을 제공한다.

하나는 메시지 전송을 위한 "게시 및 가입(publish and subscribe)" 모델이다. 예를 들어 부엌 전등 스위치라면 켜고 꺼야 할 기기의 주소 목록을 유지하기 위해 전기를 소비할 필요가 없다. 대신 "부엌 조명" 목록에서 참고하도록 표시된 "켜기" 메시지만 게시하면 된다. 이 메시지는 메시를 따라 전달되고, 각 기기들은 그 목록에 가입되어 있는지 여부에 따라 메시지에 응해 작동할지 여부를 스스로 판단한다.

다른 방법은 에너지 공급이 제한된 기기에서 "친구"를 호출하는 것이다. 예를 들어 온도 센서에서 주기적으로 판독값을 전송할 필요없이 온도가 정해진 범위를 벗어날 때만 보고하면 된다고 가정해 보자. 이렇게 하면 드물게 발생하는 예외만 전송하면 되므로 전송에 사용되는 에너지를 절약할 수 있다.

그러나 설정 온도 범위 업데이트를 받기 위해 지속적으로 수신 대기를 하게 되면 배터리가 금방 소진될 수 있다. 전원이 충분히 공급되는 기기를 친구로 해서 기기를 설계하면 이 센서는 하루에 한 번(또는 원하는 간격으로) 라디오 수신기를 켜면 되고, 이때 친구가 센서 오프라인 동안 전송된 모든 메시지를 전달해준다. 휴가 중에 우편함을 확인하러 매일 집으로 다시 올 필요 없이 이웃이 우편물을 대신 받아두는 것이라고 생각하면 된다.

가입할 메시 네트워크를 선택하거나 친구로 설정할 기기를 선택하는 과정은 두 블루투스 기기를 페어링해 포인트 투 포인트 연결을 구성하는 것보다는 조금 더 복잡하다.

프로비저닝(provisioning)이라고 하는 이 프로세스에는 블루투스 지원 스마트폰, 태블릿 또는 컴퓨터에서 실행되는 앱이 필요하다. 전구, 산업용 센서 또는 보안 카메라와 같은 새 메시 기기는 프로비전되지 않은 상태로 제공되므로 네트워크에 노드로 가입하려면 앱에서 암호화 키를 다운로드해야 한다.

동일한 앱을 사용해 키를 폐기할 수도 있으므로 망가진 전구를 안전하게 버릴 수 있다. 이렇게 하면 누군가 쓰레기 더미를 뒤져 버려진 전구에서 키를 복구해 네트워크에 침입할 위험이 없다.

이 사양의 개발자들은 재전송 공격(replay attacks)으로부터 블루투스 메시 네트워크를 보호하기 위해 각 메시지에 고유한 시퀀스 번호가 있는지 확인하도록 했다.

또한 이 사양은 네트워크 인프라와 여기서 실행되는 애플리케이션에 대해 서로 다른 암호화 계층을 제공한다. 예를 들어 호텔의 스마트 조명 네트워크가 호텔 객실 도어 잠금을 여는 메시지를 전달할 수 있지만 애초에 이 메시지를 생성하는 데 필요한 암호화 키는 호텔의 스마트폰 앱에만 보관할 수 있다.

ABI 리서치(ABI Research)의 선임 분석가 앤드류 지그나니는 메시 네트워킹의 도입은 블루투스가 기존의 작동 범위와 네트워크 규모 제한을 극복하는 데 도움이 될 것으로 전망했다.

지그나니는 "메시 네트워킹은 블루투스 혁신의 새로운 단계이며, 블루투스가 개인 영역 네트워크 및 페어링(pairing) 기술에서 우리 주변의 사물에 연결하는 기능을 갖춘 더 넓은 범위의 강력한 저전력 IoT 연결 솔루션으로 전환하는 데 핵심적인 역할을 할 것"이라고 예상했다. editor@itworld.co.kr


'BlueTooth > 기본기' 카테고리의 다른 글

Bluetooth Mesh - What's that noise about? (MAGAZINE)  (1) 2017.10.17
Bluetooth mesh networking From Wikipedia  (0) 2017.10.17
"블루투스의 혁신" 블루투스 메시 네트워크 표준 발표로 IoT 확산  (0) 2017.10.16
Mesh Profile  (0) 2017.10.16
Air packet에서 Bluetooth clock 확인  (0) 2017.09.08
baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
posted by bluelimn 2017.10.16 15:43

Mesh Profile


▪ Revision: v1.0

▪ Revision Date: 2017-Jul-13

▪ Group Prepared By: Mesh Working Group


1.3.2 Acronyms and abbreviations

Abbreviation or Acronym

Meaning

ACK

Acknowledgment

AD

Advertising Data

AES

Advanced Encryption Standard

AID

Application Key Identifier

AKF

Application Key Flag

ASCII

American Standard Code for Information Interchange

ATT

Attribute Protocol

ATT_MTU

Attribute Protocol Maximum Transmission Unit

BR/EDR

Basic Rate / Enhanced Data Rate

CCM

Counter with CBC-MAC

CID

Company Identifier

CMAC

Cipher-based Message Authentication Code

CTL

Network control message indication

DST

Destination

ECB

Electronic CodeBook

ECDH

Elliptic Curve Diffie-Hellman

FCS

Frame Check Sequence

FIPS

Federal Information Processing Standards

FSN

Friend Sequence Number

GAP

Generic Access Profile

GATT

Generic Attribute Profile

ID

Identifier

IEEE

Institute of Electrical and Electronics Engineers

IKM

Input Key Material

IVI

Initialization Vector Index

JSON

JavaScript Object Notation

LED

Light Emitting Diode

LSO

Least Significant Octet

MAC

Message Authentication Code

MD

More Data

MIC

Message Integrity Check

MSO

Most Significant Octet

MTU

Maximum Transmission Unit

NID

Network Identifier

OBO

On Behalf Of (another element)

OKM

Output Key Material

OOB

Out of Band

PDU

Protocol Data Unit

PID

Product Identifier

RFU

Reserved for Future Use

RPL

Replay Protection List

RSSI

Received Signal Strength Indicator

SAR

Segmentation And Reassembly

SEG

Segmentation indication bit

SEQ

Sequence Number

SIG

Special Interest Group

SRC

Source

SZMIC

Size of Message Integrity Check

TTL

Time To Live

URI

Uniform Resource Indicator

UUID

Universally Unique Identifier

VID

Version Identifier

WG

Working Group

 

1.3.3 Terminology

Term

Definition

Address

The identity of one or more elements in one or more nodes.

Configuration Client

A node that implements the Configuration Client model.

Destination

The address to which a message is sent.

Device

An entity that is capable of being provisioned onto a mesh network.

Element

An addressable entity within a device. A device is required to have at least one element.

Message

A sequence of octets that is sent from a source to a destination.

Neighbors

Nodes in direct radio range (single hop).

Network

A group of nodes sharing a common address space.

Node

A provisioned device.

Provision

The process of authenticating and providing basic information (including unicast addresses and a network key) to a device. A device must be provisioned to become a node. Once provisioned, a node can transmit or receive messages in a mesh network.

Provisioner

A node that is capable of adding a device to a mesh network.

Relay

A node that receives and then retransmits messages.

Source

The address from which a message is sent.

State

A value representing a condition of an element that is exposed by an element of a node.

Subnet

A group of nodes that can communicate with each other.


 

'BlueTooth > 기본기' 카테고리의 다른 글

Bluetooth Mesh - What's that noise about? (MAGAZINE)  (1) 2017.10.17
Bluetooth mesh networking From Wikipedia  (0) 2017.10.17
"블루투스의 혁신" 블루투스 메시 네트워크 표준 발표로 IoT 확산  (0) 2017.10.16
Mesh Profile  (0) 2017.10.16
Air packet에서 Bluetooth clock 확인  (0) 2017.09.08
baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
posted by bluelimn 2017.09.08 15:24

 

 

Clock delta : 0x0c (12)

Time delta : 003750

Calc : 12  * 625 / 2

 

Clock 625/2 이유는 625μs 확인하기 위해서는 최소한 2배의 속도로 체크해야 하기 때문이다.

 

 

1.1 BLUETOOTH CLOCK
Every Bluetooth device shall have a native clock that shall be derived from a
free running reference clock. Offsets may be added to the reference clock to
synchronize the native clock with other non-Bluetooth systems. For
synchronization with other Bluetooth devices, offsets are used that, when
added to the native clock, provide temporary Bluetooth clocks that are mutually
synchronized. It should be noted that the Bluetooth clock has no relation to the
time of day; it may therefore be initialized to any value. The clock has a cycle of
about a day. If the clock is implemented with a counter, a 28-bit counter is
required that shall wrap around at 228-1. The least significant bit (LSB) shall
tick in units of 312.5 μs (i.e. half a time slot), giving a clock rate of 3.2 kHz.
The clock determines critical periods and triggers the events in the device.
Four periods are important in the Bluetooth system: 312.5 μs, 625 μs, 1.25 ms,
and 1.28 s; these periods correspond to the timer bits CLK0, CLK1, CLK2, and
CLK12, respectively, see Figure 1.4 on page 68.

 

Bluetooth Air에서 기본으로 사용하는 시간 단위는 625 μs.

 

 

2.2.5.1 Piconet physical channel timing
In the figures, only single-slot packets are shown as an example.
The master TX/RX timing is shown in Figure 2.3 on page 76. In Figure 2.3 and
Figure 2.4 the channel hopping frequencies are indicated by f(k) where k is the
time slot number. After transmission, a return packet is expected N × 625 μs
after the start of the TX packet where N is an odd, integer larger than 0. N
depends on the type of the transmitted packet.
To allow for some time slipping, an uncertainty window is defined around the
exact receive timing. During normal operation, the window length shall be 20
μs, which allows the RX packet to arrive up to 10 μs too early or 10 μs too late.

It is recommended that slaves implement variable sized windows or time
tracking to accommodate a master's absence of more than 250ms.
During the beginning of the RX cycle, the access correlator shall search for the
correct channel access code over the uncertainty window. If an event trigger
does not occur the receiver may go to sleep until the next RX event. If in the
course of the search, it becomes apparent that the correlation output will never
exceed the final threshold, the receiver may go to sleep earlier. If a trigger
event occurs, the receiver shall remain open to receive the rest of the packet
unless the packet is for another device, a non-recoverable header error is
detected, or a non-recoverable payload error is detected.

 

Bluetooth에서는 clock에 대한 시간 오차를 기준에서 앞/뒤 10μs 까지는 허용한다.

즉, 기준에서 10μs를 벗어나면 안 된다.

 

'BlueTooth > 기본기' 카테고리의 다른 글

Bluetooth Mesh - What's that noise about? (MAGAZINE)  (1) 2017.10.17
Bluetooth mesh networking From Wikipedia  (0) 2017.10.17
"블루투스의 혁신" 블루투스 메시 네트워크 표준 발표로 IoT 확산  (0) 2017.10.16
Mesh Profile  (0) 2017.10.16
Air packet에서 Bluetooth clock 확인  (0) 2017.09.08
baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
posted by bluelimn 2017.09.08 15:08

 

 

Baseband에 ACK와 NACK로 SEQN(Sequence Number)이 결정됨.

기본적으로 SEQN은 data packet에 대해서만 0,1로 변경 된다.

이 때, 동일한 LT_ADDR에 대해서 SEQN을 확인 한다.

위의 이미지에서 LMP의 LT_ADDR이 3이므로 동일한 3에 대해서 check함.

 

Receiver는 data packet에 대해 정상 수신하면 ARQN에 1을 주고 잘못된 data를 받으면 0을 준다.

Receiver는 data packet 또는 NULL/POLL에 ARQN을 줄 수 있다.

 

Sender는 ARQN으로 1을 받으면 다음 data packet에 자신의 SEQN을 변경한다.

만약 Receiver가 응답이 없거나 ARQN으로 0을 보내면 retransmit packet을 보낸다.

'BlueTooth > 기본기' 카테고리의 다른 글

Bluetooth Mesh - What's that noise about? (MAGAZINE)  (1) 2017.10.17
Bluetooth mesh networking From Wikipedia  (0) 2017.10.17
"블루투스의 혁신" 블루투스 메시 네트워크 표준 발표로 IoT 확산  (0) 2017.10.16
Mesh Profile  (0) 2017.10.16
Air packet에서 Bluetooth clock 확인  (0) 2017.09.08
baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
posted by bluelimn 2016.01.28 15:35

2.4.1 LMP Response Timeout

(pairing sequence) : fixed on spec


The time between receiving a baseband packet carrying an LMP PDU and

sending a baseband packet carrying a valid response PDU, according to the

procedure rules in Section 4 on page 249, shall be less than the LMP

Response Timeout. The value of this timeout is 30 seconds.



2.4 PAGE TIMEOUT (0x04)

(acl connection)

The Page Timeout error code indicates that a page timed out because of the

Page Timeout configuration parameter. This error code may occur only with the

Remote_Name_Request and Create_Connection commands.


Range: 0x0001 to 0xFFFF

Default: 0x2000 (8192)

Mandatory Range: 0x0016 to 0xFFFF

Time = N * 0.625 msec

Time Range: 0.625 msec to 40.9 sec

Time Default: 5.12 sec


6.7 CONNECTION ACCEPT TIMEOUT

The Connection_Accept_Timeout configuration parameter allows the BR/EDR

Controller to automatically deny a connection request after a specified time

period has occurred and the new connection is not accepted. The parameter

defines the time duration from when the BR/EDR Controller sends a

Connection Request event until the BR/EDR Controller will automatically reject

an incoming connection.


Range: 0x0001 to 0xB540

Default: 0x1F40 (8000)

Mandatory Range: 0x00A0 to 0xB540

Time = N * 0.625 msec

Time Range: 0.625 msec to 29 sec

Time Default:

BR/EDR 5 sec

AMP type dependent


6.8 PAGE SCAN INTERVAL

The Page_Scan_Interval configuration parameter defines the amount of time

between consecutive page scans. This time interval is defined from when the

Controller started its last page scan until it begins the next page scan.


Range: 0x0012 to 0x1000; only even values are valid

Default: 0x0800

Mandatory Range: 0x0012 to 0x1000

Time = N * 0.625 msec

Time Range: 11.25 msec to 2560 msec

Time Default: 1.28 sec



6.9 PAGE SCAN WINDOW

The Page_Scan_Window configuration parameter defines the amount of time

for the duration of the page scan. The Page_Scan_Window can only be less

than or equal to the Page_Scan_Interval.


Range: 0x0011 to 0x1000

Default: 0x0012

Mandatory Range: 0x0011 to Page Scan Interval

Time = N * 0.625 msec

Time Range: 10.625 msec to Page Scan Interval

Time Default: 11.25 msec


2.8 CONNECTION TIMEOUT (0x08)

(check link loss)

The Connection Timeout error code indicates that the link supervision timeout

has expired for a given connection.



6.21 LINK SUPERVISION TIMEOUT

The Link_Supervision_Timeout parameter is used by the Controller to monitor

link loss.

Range: 0x0001 to 0xFFFF

Default: 0x7D00

Mandatory Range: 0x0190 to 0xFFFF

Time = N * 0.625 msec

Time Range: 0.625 msec to 40.9 sec

Time Default:

BR/EDR 20 sec

AMP 10 sec


usually set to 0x1F40 (8000) : 5 sec



6.28 LOGICAL LINK ACCEPT TIMEOUT

The Logical_Link_Accept_Timeout configuration parameter allows the AMP

Controller to automatically deny a logical link request after a specified time period

has elapsed and the new logical link has not completed.

Range: 0x0001 to 0xB540

Default: 0x1F40

Mandatory Range: 0x00A0 to 0xB540

Time = N * 0.625 msec

Time Range: 0.625 msec to 29 sec

Time Default: AMP Type dependent : 5 sec



6.36 SYNCHRONIZATION TRAIN INTERVAL (for LE)

The Sync_Train_Interval configuration parameter defines the time between

Synchronization Train transmit events on a single transmit RF channel.

Default: 0x0080

Mandatory Range: 0x0020 to 0x1000

Time = N * 0.625 msec

Time Range: 20 msec to 40.9 sec

Time Default: 80 msec


6.37 SYNCHRONIZATION TRAIN TIMEOUT (for LE)

The synchronization_trainTO configuration parameter is used by the controller

to terminate the Synchronization Train after it has been started via the

HC_Start_Synchronization_Train command.

Default: 0x0002EE00

Mandatory Range: 0x00000002 to 0x07FFFFFE

Time = N * 0.625 msec

Time Range: 1.25 msec to 23.3 hours

Time Default: 120 msec


6.2 INQUIRY SCAN INTERVAL

The Inquiry_Scan_Interval configuration parameter defines the amount of time

between consecutive inquiry scans. This is defined as the time interval from

when the BR/EDR Controller started its last inquiry scan until it begins the next

inquiry scan.

Range: 0x0012 to 0x1000; only even values are valid

Default: 0x1000

Mandatory Range: 0x0012 to 0x1000

Time = N * 0.625 msec

Time Range: 11.25 to 2560 msec

Time Default: 2.56 sec

usually try 2 times = 5.12 sec







'BlueTooth > 기본기' 카테고리의 다른 글

Bluetooth mesh networking From Wikipedia  (0) 2017.10.17
"블루투스의 혁신" 블루투스 메시 네트워크 표준 발표로 IoT 확산  (0) 2017.10.16
Mesh Profile  (0) 2017.10.16
Air packet에서 Bluetooth clock 확인  (0) 2017.09.08
baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
kitkat install 다시 시작  (9) 2014.07.19
posted by bluelimn 2016.01.07 16:51

RFCOMM


frame types

  - SABM (Set Asynchronous Balanced Mode command)

    : connect with remote server channel

  - UA (Unnumbered Acknowledgement response)

    : response for SABM/DISC

  - DM (Disconnected Mode response)

    : when RFCOMM is disconnected

  - DISC (Disconnect command)

    : disconnect with remote device

  - UIH (Unnumbered information with header check command and response)

    : send and receive data with remote device.


SCN(Server Channel Number)

Server applications registering with an RFCOMM service interface are assigned a 

Server Channel number in the range 1…30. [0 and 31 should not be used since 

the corresponding DLCIs are reserved in TS 07.10] It is this value that should be 

registered in the Service Discovery Database.

  - MAP, PBAP, HFP can obtain SCN from  SDP.

  - SCN 0 means  control channel.


Supported Control Channel Commands

 - DLC parameter negotiation (PN)


DLCI (Data Link Connection Identifier) 

  - DLCI 0 : control 

  - DLCI even : initializing connection

  - DLCI odd : non-initializing connection


DISC (Disconnect command) 

The DISC command shall be used to terminate an operational or initialization mode previously set by a command. It

shall be used to inform one station that the other station is suspending operation and that the station should assume a

logically disconnected mode. Prior to actioning the command, the receiving station shall confirm the acceptance of the

DISC command by the transmission of a UA response.


UA (Unnumbered Acknowledgement) response

The UA response shall be used by the station to acknowledge the receipt and acceptance of SABM and DISC commands.


C/R (Command/Response)

The C/R (command/response) bit identifies the frame as either a command or a response.


P/F (Poll/Final)

The poll (P) bit set to 1 shall be used by a station to solicit (poll) a response or sequence of responses from the other station.

The final (F) bit set to 1 shall be used by a station to indicate the response frame transmitted as the result of a soliciting (poll) command.


'BlueTooth > 기본기' 카테고리의 다른 글

"블루투스의 혁신" 블루투스 메시 네트워크 표준 발표로 IoT 확산  (0) 2017.10.16
Mesh Profile  (0) 2017.10.16
Air packet에서 Bluetooth clock 확인  (0) 2017.09.08
baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
kitkat install 다시 시작  (9) 2014.07.19
BLE 4.1  (0) 2014.06.25
posted by bluelimn 2015.12.15 16:17

GPP Generic PIM Profile

 Abbreviation or Acronym

 Meaning 

 BNF

 Backus-Naur Form 

 DTD

 XML Document Type Definition 

 FRD

 Feature Requirements Document 

 GAP

 Generic Access Profile 

 GPP

 Generic PIM Profile 

 GOEP

 Generic Object Exchange Profile 

 MAP

 Message Access Profile MRD Market Requirements Document 

 MSC

 Message Sequence Chart 

 PAS

 PIM Access Service 

 PIM

 Personal Information Management 

 PIMCE

 PIM Client Equipment 

 PIMSE

 PIM Server Equipment 

 PNS

 PIM Notification Service 

 PSM

 Protocol Service Multiplexer 

 WG

 Working Group 

 XML

 eXtensible Markup Language 

 XSD

 XML Schema Definition


In particular, GPP is based on GOEP v2.0 with OBEX over L2CAP.





• PIM Server Equipment (PIMSE) - is the device that provides the PIM object repository (i.e., has the ability to provide a client unit with PIM objects that are stored in this device and with notifications of changes in its repository). Furthermore, it provides features to upload and modify PIM entries in its repository. For example, a PIM device may be a mobile phone or a smartphone.

• PIM Client Equipment (PIMCE) - is the device that accesses the PIM objects repository engine of the PIMSE for downloading, browsing and displaying existing PIM objects, modifying such objects and also to upload objects to the PIMSE. For example, a PIMCE device may be a car head unit.


User Scenarios

The following are the main scenarios that are covered by this profile:

• The PIMCE browses in the PIM objects repository of the PIMSE: In this scenario, the PIMCE can navigate through the PIMSE’s folder structure, can get listings of PIM objects and can get PIM objects that are locally stored in thePIMSE device. A typical configuration would be that of a Bluetooth car-kit or a PC browsing the content of a mobile phone's PIMSE repository.

• The PIMCE uploads PIM objects onto the PIMSE repository: In this scenario, PIM objects are created on the PIMCE device and uploaded to the PIMSE device for storage (e.g., a new calendar entry or an email for sending).

• The PIMCE deletes PIM objects from the PIMSE repository: In this scenario, the PIMCE device deletes selected objects on the PIMSE (e.g., removal of a calendar entry or a spam mail).

• The PIMSE notifies the PIMCE: In this scenario, the PIMSE notifies the PIMCE about a change in the PIM r (e.g., removal of a calendar entry, a status change of a calendar entry, reception of a new message or modification of a phonebook entry).


Overview

GPP considers the following object types that may be transferred:

Literal objects: the actual PIM data objects stored in the repository of the PIMSE (e.g., a message, a phonebook entry, or a calendar entry).

Listing objects: listings of literal objects with a number of listing entries, each with a limited but relevant amount of information about the related literal objects. The listings may be virtual and do not necessarily have to be identical with the contents of the physical PIMSE file system.

Folder listing objects: listings with entries, describing the sub-folders of a folder. The folders structure may be virtual and does not necessarily have to be identical with the structure of the physical PIMSE file system. Event report objects: events are sent by the PIMSE to the PIMCE to report changes in the PIMSE's object repository.


Character-Set

If not defined otherwise by the specific PIM application profile the character set used for the attributes of the PIM application objects shall be UTF-8.



 Feature

 Support by the PIMCE

 Support by the PIMSE

 Connect PIM Access Service

 M*

 M**

 Disconnect PIM Access Service

 M*

 M**

 Connect PIM Notification Service

 O**

 M*

 Disconnect PIM Notification Service

 C1**

 M*


* ability to request or initiate, ** ability to respond or react 

C1: Feature is mandatory if feature 'Connect PIM Notification Service' is supported by device



Initialization Sequence for a GPP Session That Uses Only the PIM Access Service



Initialization Sequence for a GPP Session That Uses Both the PIM Access Service and the PIM Notification Service





Terminating a PIM Access or PIM Notification Service Connection



The termination of a PIM Access or a PIM Notification Service connection is done in accordance with. The PNS connection of a given GPP-based application shall be closed if :

- all registered PAS connections have been de-registered

or

- if all the application’s PAS connections have been closed


Generic PIM Profile Functions

5.2 SendEvent Function

5.3 SetNotificationRegistration Function

5.4 GetObjectListing Function

5.5 GetObject function

5.6 PushObject Function

5.7 GetInstanceInformation Function

5.8 SyncInstance Function


5.2 SendEvent Function

5.2.1 Connection ID

The connection ID header shall be used to indicate the connection ID, received during the connection establishment, in order to signal the recipient of the request which OBEX connection this request belongs to.

5.2.3.1 InstanceID

This header shall be used by the PIMSE to indicate the corresponding PIMSE-Instance (see Section 3.3.3). As only one PNS service connection per application can be established from the PIMSE device to the MCE, this parameter is required by the PIMCE to determine the PIMSE Instance that should receive this event. The PIMCE can retrieve the corresponding InstanceID from the PIMSE’s SDP record (see Section 7.1.1 ‘InstanceID’ parameter).


5.3 SetNotificationRegistration Function

5.3.3.1 NotificationStatus

The PIMCE shall indicate the request for being notified about changes in the object repository for the corresponding application profile. The header shall have either of the values:

• "Off", meaning no notification required or

• "On", meaning the notification service (PNS) session of the corresponding application shall be established


5.4 GetObjectListing Function


5.5 GetObject function

5.5.2 Name

The Name header shall be used to indicate the handle of the literal object to be retrieved. The handle shall be represented by a null-terminated Unicode text string with up to 32 hexadecimal digits (the handle is 128 bits but leading zeros may be omitted).


5.5.3 Type

The type header shall be used by the related application profile to indicate the type of object to be transmitted. Accordingly, the value has to be defined by the application profile.


5.6 PushObject Function


5.7 GetInstanceInformation Function


5.7.4 Body/EndOfBody

The Body includes a string with the requested user-readable information of the application instance. It shall be represented by a null-terminated UTF-8 text string of at most 200 characters (including the null termination character).


5.8 SyncInstance Function


Application Parameter Headers

The tag IDs used in the Application Parameters header are listed below.



'BlueTooth > 기본기' 카테고리의 다른 글

Mesh Profile  (0) 2017.10.16
Air packet에서 Bluetooth clock 확인  (0) 2017.09.08
baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
kitkat install 다시 시작  (9) 2014.07.19
BLE 4.1  (0) 2014.06.25
Security Mode  (1) 2014.06.24
posted by bluelimn 2015.11.26 12:58


Paging

Page scan (slave)

An unconnected Bluetooth device must periodically enter the page scan state; in this state, the device activates its receiver and listens for a master device that might be trying to page it. A device operates in one of three page SR (Scan Repetition) modes:

R0: the device listens continuously for a master paging it.
R1: the device listens at least every 1.28 seconds (2048 slots).
R2: the device listens at least every 2.56 seconds (4096 slots).

During the page scan state, the unconnected device listens on one of 32 channels, for at least 10ms (16 slots). A different channel is selected every 1.28 seconds (2048 slots). The channels and the hopping sequence are calculated from the device's BD_ADDR (Bluetooth Device Address).

Page (master)

When commanded to enter the page state, the master device starts to transmit, using 16 of the 32 channels being used by the paged device. During every even numbered slot it transmits two ID packets on two different channels, and during the following slot it listens on two different channels for the slave's response (also an ID packet). In the next two slots it uses the next two channels, so the hopping sequence (of 16 channels) repeats every 10ms (16 slots).

The master repeats the 16 slot sequence for at least long enough for the paged device to enter the page scan state:

R0: at least once.
R1: at least 128 times (i.e. for at least 1.28 seconds).
R2: at least 256 times (i.e. for at least 2.56 seconds).

If the master doesn't receive a response, it will then try the other 16 channels.

Page sequence

  • Slot n+0: The master transmits one ID packet in the first half slot, then a second ID packet (on a different frequency) in the second half slot.
  • Slot n+1: The slave responds with an ID packet, in either the first half or second half of the slot.
  • Slot n+2: The master transmits an FHS packet.
  • Slot n+3: The slave responds with an ID packet, in the first half of the slot.
  • Slot n+4: The master switches to the normal hopping scheme. The first packet it transmits is a POLL packet.

Inquiry

Inquiry scan (slave)

An unconnected Bluetooth device that wants to be "discovered" by a master device will periodically enter the inquiry scan state; in this state, the device activates its receiver and listens for inquiries. It must enter this state at least every 2.56 seconds (4096 slots).

During the inquiry scan state, the unconnected device listens on one of 32 channels, for at least 10ms (16 slots). A different channel is selected every 1.28 seconds (2048 slots). The channels and the hopping sequence are calculated from the general inquiry address.

Inquiry (master)

When commanded to enter the inquiry state, the master device starts to transmit, using 16 of the 32 channels used for inquiries. During every even numbered slot it transmits twoID packets on two different channels, and during the following slot it listens on those two channels for a slave's response (an FHS packet). In the next two slots it uses the next two channels, so the hopping sequence (of 16 channels) repeats every 10ms (16 slots). The 16 slot sequence must be repeated at least 256 times (i.e. for at least 2.56 seconds) before switching to the other set of 16 channels.


'BlueTooth > 기본기' 카테고리의 다른 글

Air packet에서 Bluetooth clock 확인  (0) 2017.09.08
baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
kitkat install 다시 시작  (9) 2014.07.19
BLE 4.1  (0) 2014.06.25
Security Mode  (1) 2014.06.24
Vega series에서 HID가 connecting state에 머물러 있음  (0) 2014.03.27
posted by bluelimn 2014.10.23 17:09

A2DP를 사용하다 보면 Signaling channel과 Media channel이 구분되어 연결되는 것을 많이 보는데 그러면서도 air log를 확인하지 않으면 정확히 어떤 차이가 있는 지 쉽게 감이 오지 않는다.


Air log를 BomProbe Protocol Analysis System으로 보면 A2DP와 관련하여

AVDTP/AVDTP Signaling/AVDTP Media/A2DP

이러한 탭이 보이는데...


A2DP와 관련된 내용들은 결국 AVDTP 탭에서 다 확인이 가능하다

이 중에서 Media 관련은 AVDTP Media, Signaling 관련은 AVDTP Signaling으로 분류한 정도로 생각하면 된다.


정리하자면 AVDTP Media tab에는 음원을 전달하는 packet들이 들어있고, 이것이 그대로 A2DP tab으로 전달된다.

그럼 AVDTP signaling은 A2DP가 아니냐?

아니다. A2DP는 profile이고 AVDTP는 protocol 이므로 profile 하위에 깔고 있다.

여기서 AVDTP signaling이 무엇인지가 중요해지는데 결국 음원이 아닌 다른 control packet들이라고 생각하면 된다.


Signaling tab을 보면 사실 간단한 명령들이 보인다.



Discover : decoer를 알려달라는 명령

Get capabilities : 해당 decoer의 capability를 확인(codec type,sampling frequency, channel mode 등 지원 가능한 사양 확인)

set configuration : 어떤 코덱을 어떤 설정으로 사용할 것인지

open : channel open

start : media data를 주겠다.

suspend : 중단

기타 등등...


'BlueTooth > 기본기' 카테고리의 다른 글

baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
kitkat install 다시 시작  (9) 2014.07.19
BLE 4.1  (0) 2014.06.25
Security Mode  (1) 2014.06.24
Vega series에서 HID가 connecting state에 머물러 있음  (0) 2014.03.27
Bluetooth Packet Type  (0) 2013.11.06
posted by bluelimn 2014.07.19 17:34

install ubuntu 12.04 


source code download

참고 : https://source.android.com/source/downloading.html

$ mkdir ~/bin
$ PATH=~/
bin:$PATH
$ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$ chmod a
+x ~/bin/repo
 $ repo init -u http://git.android-x86.org/manifest -b kitkat-x86
 $ repo sync

install required packages(Ubuntu 12.04

$sudo apt-get install git gnupg flex bison gperf build-essential \
  zip curl libc6
-dev libncurses5-dev:i386 x11proto-core-dev \
  libx11
-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 \
  libgl1
-mesa-dev g++-multilib mingw32 tofrodos \
  python
-markdown libxml2-utils xsltproc zlib1g-dev:i386
$ sudo ln
-s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so

한번에 다 설치하면 종속성 때문에 설치가 안될 수 있으니 차근차근 나눠서 설치


Initialize


$ source build/envsetup.sh

$ lunch 

5. android_x86-eng

선택


Build

$ make -j4



아래의 에러를 만나서 진행이 안되는 중..ㅠㅠ


UNEXPECTED TOP-LEVEL EXCEPTION:

com.android.dex.util.ExceptionWithContext

at com.android.dex.util.ExceptionWithContext.withContext(ExceptionWithContext.java:45)

at com.android.dx.dex.cf.CfTranslator.processMethods(CfTranslator.java:377)

at com.android.dx.dex.cf.CfTranslator.translate0(CfTranslator.java:139)

at com.android.dx.dex.cf.CfTranslator.translate(CfTranslator.java:94)

at com.android.dx.command.dexer.Main.processClass(Main.java:682)

at com.android.dx.command.dexer.Main.processFileBytes(Main.java:634)

at com.android.dx.command.dexer.Main.access$600(Main.java:78)

at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:572)

at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)

at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)

at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)

at com.android.dx.command.dexer.Main.processOne(Main.java:596)

at com.android.dx.command.dexer.Main.processAllFiles(Main.java:498)

at com.android.dx.command.dexer.Main.runMonoDex(Main.java:264)

at com.android.dx.command.dexer.Main.run(Main.java:230)

at com.android.dx.command.dexer.Main.main(Main.java:199)

at com.android.dx.command.Main.main(Main.java:103)

Caused by: java.lang.NullPointerException

at com.android.dx.cf.code.ConcreteMethod.<init>(ConcreteMethod.java:87)

at com.android.dx.cf.code.ConcreteMethod.<init>(ConcreteMethod.java:75)

at com.android.dx.dex.cf.CfTranslator.processMethods(CfTranslator.java:277)

... 15 more

...while processing <init> (Lcom/android/internal/telephony/gsm/GSMPhone;)V

...while processing com/android/internal/telephony/gsm/GSMPhone$1.class


1 error; aborting

make: *** [out/target/common/obj/JAVA_LIBRARIES/telephony-common_intermediates/classes-with-local.dex] Error 1



'BlueTooth > 기본기' 카테고리의 다른 글

bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
kitkat install 다시 시작  (9) 2014.07.19
BLE 4.1  (0) 2014.06.25
Security Mode  (1) 2014.06.24
Vega series에서 HID가 connecting state에 머물러 있음  (0) 2014.03.27
Bluetooth Packet Type  (0) 2013.11.06
quoted-printable decoder  (0) 2013.06.03
posted by bluelimn 2014.06.25 09:41

BLE 4.0에서 smart ready(dual mode) 끼리는 연결 안되는 문제가 있었는데

4.1로 넘어가면서 smart ready간 연결도 지원한다고 함.

시간이 나면 4.1도 정리해볼 필요가 있을 것으로 보임.



출처 : 위키디피아

http://ko.wikipedia.org/wiki/%EB%B8%94%EB%A3%A8%ED%88%AC%EC%8A%A4#.EB.B8.94.EB.A3.A8.ED.88.AC.EC.8A.A4_4.1



블루투스 4.0

블루투스 SIG는 클래식 블루투스와 블루투스 하이 스피드와 블루투스 로우 에너지를 포함한 기능을 가진 블루투스 4.0을 발표하였다. 블루투스 하이 스피드는 와이파이 기반으로, 클래식 블루투스는 기존의 블루투스 프로토콜로 구성되어 있다. 2010년 6월 30일에 채택되었다. 블루투스 저전력(Bluetooth Low Energy, 약어: BLE)은 블루투스 v4.0에 포함된 간단한 연결을 빠르게 만들기 위한 완전히 새로운 프로토콜 스택이다. 2011년 말, 호스트를 위한 "Bluetooth Smart Ready" 와 센서를 위한 "Bluetooth Smart" 가 블루투스 저전력(BLE)의 새 로고로써 선보였다.


싱글 모드 구현에선 저전력 프로토콜 스택이 단독적으로 구현된다.

듀얼 모드 구현에선 저전력 기능이 기존의 블루투스 컨트롤러에 통합된다.

Bluetooth SMART는 블루투스 저전력 전용 장치로써 일반적으로 배터리로 동작하는 센서에서 사용된다. 동작에 SMART Ready 또는 다른 SMART 장치를 필요로 한다. 또한 최대 도달 거리가 50M 이다.

Bluetooth SMART Ready 는 듀얼 모드 장치를 나타내며 일반적으로 노트북 또는 스마트폰에서 사용된다. 기존의 블루투스와 블루투스 저전력 장치를 둘다 사용한다.



블루투스 4.1

블루투스 SIG는 2013년 12월 블루투스 4.1의 새로운 기능을 발표했다. 블루투스 4.1의 주요 특징은 다음과 같다.


공존성(coexistence) 향상- 블루투스와 LTE 무선이 서로 통신 상태를 조정해 가까운 대역폭으로 인한 간섭 현상을 줄여준다.

더 나은 연결(better connections)- 블루투스 연결 장치끼리의 거리가 증가해 잠시 연결이 끊어지게 되면, 4.1 블루투스 장치는 거리 내로 되돌아올 시 자동으로 재연결된다.

데이터 전송 개선(improved data transfer)- 블루투스를 사용하는 악세서리 장치(헬스 기구) 등과의 통신 전송 상태를 보다 효율적으로 개선하였다.

개발자에게 더 많은 유연성 제공(more flexibility to developers)- 앞으로 있을 웨어러블 기기 붐에 대비한 업데이트로, 블루투스 연결을 통해 웨어러블 기기가 스마트폰의 주변장치이자 동시에 다른 장치와의 허브 역할도 할 수 있게 해준다. 또한 장래를 위해 사물 인터넷(The Internet of Things)을 위한 새로운 IPV6 사용 표준도 들어가 있다.

'BlueTooth > 기본기' 카테고리의 다른 글

RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
kitkat install 다시 시작  (9) 2014.07.19
BLE 4.1  (0) 2014.06.25
Security Mode  (1) 2014.06.24
Vega series에서 HID가 connecting state에 머물러 있음  (0) 2014.03.27
Bluetooth Packet Type  (0) 2013.11.06
quoted-printable decoder  (0) 2013.06.03
synergy MessageSendLater  (0) 2011.04.19
posted by bluelimn 2014.06.24 16:14

Security Mode 4

 the Bluetooth specification specifies four levels of security for Bluetooth 

services for use during Secure Simple Pairing (SSP): 

 

Service Level 3 

requires man-in-the-middle (MITM) protection and encryption; user interaction is acceptable. 


Service Level 2 

requires encryption only; MITM protection is not necessary. 


Service Level 1 

does not require MITM protection and encryption; user interaction is minimal. 


Service Level 0 

does not require MITM protection, encryption, or user interaction. 





5.2.1.1 Security mode 1 (non-secure)


When a remote Bluetooth device is in security mode 1 it will never initiate any

security procedure (i.e., it will never send LMP_au_rand, LMP_in_rand or

LMP_encryption_mode_req).



5.2.1.2 Security mode 2 (service level enforced security)


When a remote Bluetooth device is in security mode 2 it will not initiate any

security procedure before a channel establishment request

(L2CAP_ConnectReq) has been received or a channel establishment procedure

has been initiated by itself. (The behavior of a device in security mode 2 is

further described in [11].) Whether a security procedure is initiated or not

depends on the security requirements of the requested channel or service.

A Bluetooth device in security mode 2 should classify the security requirements

of its services using at least the following attributes:

• Authorization required

• Authentication required

• Encryption required

Note: Security mode 1 can be considered (at least from a remote device point

of view) as a special case of security mode 2 where no service has registered

any security requirements.



5.2.1.3 Security modes 3 (link level enforced security)


When a remote Bluetooth device is in security mode 3 it will initiate security

procedures before it sends LMP_setup_complete. (The behavior of a device in

security mode 3 is as described in [3].)

A Bluetooth device in security mode 3 may reject the host connection request

(respond with LMP_not_accepted to the LMP_host_connection_req) based on

settings in the host (e.g. only communication with pre-paired devices allowed).



5.2.2 Security mode 4 (service level enforced security)


A Bluetooth device in security mode 4 shall classify the security requirements

of its services using at least the following attributes (in order of decreasing

security):

• Authenticated link key required

• Unauthenticated link key required

• No security required

An authenticated link key is a link key where either the numeric comparison,

out-of-band or passkey entry simple pairing association models were used. An

authenticated link key has protection against man-in-the-middle (MITM)

attacks. To ensure that an authenticated link key is created during the Simple

Pairing procedure, the Authentication_Requirements parameter should be set

to one of the MITM Protection Required options. An unauthenticated link key is

a link key where the just works Secure Simple Pairing association model was

used. An unauthenticated link key does not have protection against MITM

attacks.

When both devices support Secure Simple Pairing, GAP shall default to requiring

an unauthenticated link key and enabling encryption. A profile or protocol

may define services that require more security (e.g. an authenticated link key).

or no security. To allow an unauthenticated link key to be created during the

Simple Pairing procedure, the Authentication_Requirements parameter may be

set to one of the MITM Protection Not Required options.

When the device is in Bondable Mode, it shall enable Secure Simple Pairing

mode prior to entering Connectable Mode or establishing a link.

Device rejected?

LMP_not_accepted LMP_accepted

yes no

Authentication /

Pairing

Encrypt

26 July 2007 Security Aspects

BLUETOOTH SPECIFICATION Version 2.1 + EDR [vol 3] page 198 of 268

Generic Access Profile

A Bluetooth device in security mode 4 shall respond to authentication requests

during link establishment when the remote device is in security mode 3 for

backwards compatibility reasons.

A Bluetooth device in security mode 4 enforces its security requirements before

it attempts to access services offered by a remote device and before it grants

access to services it offers to remote devices. Service access may occur via

L2CAP channels or via channels established by protocols above L2CAP such

as RFCOMM.

'BlueTooth > 기본기' 카테고리의 다른 글

GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
kitkat install 다시 시작  (9) 2014.07.19
BLE 4.1  (0) 2014.06.25
Security Mode  (1) 2014.06.24
Vega series에서 HID가 connecting state에 머물러 있음  (0) 2014.03.27
Bluetooth Packet Type  (0) 2013.11.06
quoted-printable decoder  (0) 2013.06.03
synergy MessageSendLater  (0) 2011.04.19
bluelab stereo 2009.R2 Inquiry시 iPhone이 검색되면 panic  (0) 2011.03.30
posted by bluelimn 2014.03.27 10:32

증상 : Vega series에서 HID를 연결하면 Phone state가 connecting에서 머물러 있음


원인 : device가 master role을 가져가려고 하면 host(phone)가 정상적으로 처리하지 못함


해결 : device를 slave role로 설정

'BlueTooth > 기본기' 카테고리의 다른 글

Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
kitkat install 다시 시작  (9) 2014.07.19
BLE 4.1  (0) 2014.06.25
Security Mode  (1) 2014.06.24
Vega series에서 HID가 connecting state에 머물러 있음  (0) 2014.03.27
Bluetooth Packet Type  (0) 2013.11.06
quoted-printable decoder  (0) 2013.06.03
synergy MessageSendLater  (0) 2011.04.19
bluelab stereo 2009.R2 Inquiry시 iPhone이 검색되면 panic  (0) 2011.03.30
Apple 개발문서  (4) 2010.03.15
posted by bluelimn 2013.11.06 17:17

SCO (Synchronized connection oriented) Packet


1. HV1 Packet


HV는 High-quality Voice의 약어로 이것은 10바이트의 데이터를 송신하는 패킷이다.


데이터는 1/3 FEC로 에러 보정을 하고 있다.


PAYLOAD의 길이는 240 bit로 PAYLOAD 내의 Header는 없다.


이 패킷을 사용하여 64Kbps의 음성데이터를 송신하는 경우 1.25ms 주기로 송신이 가능하다.


2. HV2 Packet


20바이트의 데이터를 송신하는 패킷이다.


데이터는 2/3 FEC로 에러 보정을 하고 있다.


PAYLOAD의 길이는 240 bit로 PAYLOAD 내의 Header는 없다.


이 패킷을 사용하여 64Kbps의 음성데이터를 송신하는 경우 2.5ms 주기의 송신이 가능하다.


3. HV3 Packet


30바이트의 데이터를 송신하는 패킷이다.


데이터는 FEC로 에러보정이 되지 않는다.


PAYLOAD의 길이는 240bit로 PAYLOAD 내의 Header는 없다.


이 패킷을 사용하여 64Kbps의 음성데이터을 송신하는 경우 3.75ms 주기의 송신이 가능히다.


4. DV Packet


DV는 Data Voice의 약자로 이것은 음성정보와 비음성정보를 동시에 전송하는 패킷이다.

HV1 packet을 대신할 때만 사용된다. 


PAYLOAD의 부분은 80bit 음성 field, 150bit의 데이터 필드가 구성되어 있다.


음성field는 FEC에 의한 에러 보정이 되어 있지 않다.


 


ACL (Asynchronous Connectionless Link) Packet


1. DM1 Packet


DM은 Data-Medium rate의 약어로, 18바이트의 데이터와 16bit의 CRC를 전송한다.


데이터는 2/3 FEC로 에러 보정되고 있다.


DM1은 1slot/packet 송신을 한다.


2. DH1 Packet


DH는 Data-High rate의 약어로, 28바이트의 데이터와 16bit의 CRC를 전송한다.


데이터는 FEC 에러보정은 하지 않느다.


DH1은 1slot/packet 송신을 한다.


3. DM3 Packet


DM3 패킷은 DM1 패킷의 PAYLOAD를 확장한 것으로 3slot/packet 송신을 한다.


2~123바이트의 데이터와 16비트의 CRC를 전송한다.


데이터는 2/3 FEC에 의한 에러보정을 하고 있다.


3slot을 송신하는 중간에는 주파수 변환을 실시하지 않는다.


4. DH3 Packet


DH3 패킷은 FEC를 하지 않는것 이외에는 DM3와 동일하다.


FEC를 하지 않으므로 2~185바이트의 데이터 전송이 가능하다.


5. DM5 Packet


DM5 패킷은 DM1 패킷의 PAYLOAD를 확장한 것으로 5slot/packet 송신을 한다.


2~226바이트의 데이터와 16비트의 CRC를 전송한다.


데이터는 2/3 FEC로 에로보정을 한다.


5slot을 송신하는 중간에는 주파수 변환을 하지 않는다.


6. DH5 Packet


DH5 Packet은 FEC를 하지 않는 것 이외에는 DM5 패킷과 동일하다.


FEC를 하지 않기 때문에 2~341바이트의 데이터 전송이 가능하다.


7. AUX1 Packet


AUX1 패킷은 CRC 에러 체크가 없는 것 이외에는 DH1 패킷과 동일하다.


CRC가 없으므로 1~30바이트의 데이터 전송이 가능하다. AUX1은 ACL-U, ACL-C logical links를 사용하지 않는다.


2-DH1 : DH1과 비슷, π/4-DQPSK 사용. 2~56bytes

2-DH3 : DH3과 비슷. π/4-DQPSK 사용. 2~369bytes. 3 time slots

2-DH5 : DH5와 비슷. π/4-DQPSK 사용. 2~681bytes. 5 time slots

3-DH1 : DH1과 비슷. 8DPSK 사용. 2~85bytes

3-DH3 : DH3과 비슷. 8DPSK 사용. 2~554 bytes. 3 time slots

3-DH5 : DH5와 비슷. 8DPSK 사용. 2~1023 bytes. 5 time slots


eSCO packets


* eSCO links were added in version 1.2 of the Bluetooth specification.

Following a request from either the master or slave device, the master may establish an eSCO link to that device.

* eSCO packets are always transmitted in predetermined time slots: the regular interval between eSCO packets is specified when the link is established.

* eSCO packets can be 1 or 3 slots in length.

* eSCO packets to/from a specific slave are acknowledged, and may be retransmitted if not acknowledged.


The packet type is determined by the TYPE code in the header:


NULL No payload. Used for acknowledgements or flow control.

POLL No payload. Used by the master to poll slaves. Requires acknowledgement.

8. EV3 Extended Voice (no error correction), 1 slot: maximum 30 data bytes plus a 16-bit CRC. 1~30bytes

9. EV4 Extended Voice (2/3 rate FEC), 3 slots: maximum 120 data bytes plus a 16-bit CRC. 1~120bytes

10. EV5 Extended Voice (no error correction), 3 slots: maximum 180 data bytes plus a 16-bit CRC. 1~180bytes


11. 2-EV3 : EV3과 비슷하며 π/4-DQPSK 사용. 1~60bytes

12. 2-EV5 : EV5와 비슷하며  π/4-DQPSK 사용. 1~360bytes.

13. 3-EV3 : EV3과 비슷하며 8DPSK 사용. 1~90bytes.

14. 3-EV5 : EV5와 비슷하며 8DPSK 사용. 1~540bytes


'BlueTooth > 기본기' 카테고리의 다른 글

AVDTP signaling/Media  (0) 2014.10.23
kitkat install 다시 시작  (9) 2014.07.19
BLE 4.1  (0) 2014.06.25
Security Mode  (1) 2014.06.24
Vega series에서 HID가 connecting state에 머물러 있음  (0) 2014.03.27
Bluetooth Packet Type  (0) 2013.11.06
quoted-printable decoder  (0) 2013.06.03
synergy MessageSendLater  (0) 2011.04.19
bluelab stereo 2009.R2 Inquiry시 iPhone이 검색되면 panic  (0) 2011.03.30
Apple 개발문서  (4) 2010.03.15
Peer-to-Peer Connectivity  (0) 2010.03.04
posted by bluelimn 2013.06.03 17:16

quoted-printable.h




quoted-printable.c


'BlueTooth > 기본기' 카테고리의 다른 글

kitkat install 다시 시작  (9) 2014.07.19
BLE 4.1  (0) 2014.06.25
Security Mode  (1) 2014.06.24
Vega series에서 HID가 connecting state에 머물러 있음  (0) 2014.03.27
Bluetooth Packet Type  (0) 2013.11.06
quoted-printable decoder  (0) 2013.06.03
synergy MessageSendLater  (0) 2011.04.19
bluelab stereo 2009.R2 Inquiry시 iPhone이 검색되면 panic  (0) 2011.03.30
Apple 개발문서  (4) 2010.03.15
Peer-to-Peer Connectivity  (0) 2010.03.04
iphone간 bluetooth 연결 sample  (1) 2010.03.04
posted by bluelimn 2011.04.19 10:25
extern CsrTid CsrTimedEventIn(CSR_TIME delay,
                          void (*fn)(CsrUint16 mi, void *mv),
                          CsrUint16 fniarg,
                          void *fnvarg);

extern CsrBool CsrCancelTimedEvent(CsrTid eventid,
                                 CsrUint16 *pmi,
                                 void **pmv);


void bg_usleep(CsrUint32 useconds)
void bg_wait(void)
void bg_wake_up(void)

참고 : CsrPutMessage

'BlueTooth > 기본기' 카테고리의 다른 글

BLE 4.1  (0) 2014.06.25
Security Mode  (1) 2014.06.24
Vega series에서 HID가 connecting state에 머물러 있음  (0) 2014.03.27
Bluetooth Packet Type  (0) 2013.11.06
quoted-printable decoder  (0) 2013.06.03
synergy MessageSendLater  (0) 2011.04.19
bluelab stereo 2009.R2 Inquiry시 iPhone이 검색되면 panic  (0) 2011.03.30
Apple 개발문서  (4) 2010.03.15
Peer-to-Peer Connectivity  (0) 2010.03.04
iphone간 bluetooth 연결 sample  (1) 2010.03.04
아이폰 블루투스 프로그래밍  (3) 2010.03.03
posted by bluelimn 2011.03.30 15:37

bluelab stereo 2009.R2 Inquiry시 iPhone이 검색되면 panic되는 문제

확인 결과
Dm_inquiry_handler.c 에서 inquiryParseEir()함수 사용 시 null pointer참조 문제가 있었다.

static uint8* inquiryParseEir(uint8* size_eir_data, uint8 *inquiry_data[HCI_EIR_DATA_PACKET_PTRS])
{
 uint8 i, j;
 uint8* eir_data = NULL;
 uint8* eir_data_part = NULL;
 uint8* p;
 
 /* Work out the number of EIR data parts */
 for(i=0 ; inquiry_data[i] != NULL ; i++)
 {}
 
 if(i>0)
 {
  /* Allocate memory for the EIR data */
  *size_eir_data = ((i-1) * HCI_EIR_DATA_BYTES_PER_PTR);
  eir_data = PanicUnlessMalloc(*size_eir_data);
 
  /* Point to first data part */
  p = eir_data;
  /* Copy all data except for last data part */
  for(j=0;j<(i-1);j++)
  {
   /* Get data part j and copy to p */
   eir_data_part = VmGetPointerFromHandle(inquiry_data[j]);
   memmove(p,eir_data_part,HCI_EIR_DATA_BYTES_PER_PTR);
   free(eir_data_part);
   /* Point to next data part */
   p += HCI_EIR_DATA_BYTES_PER_PTR;
  }

 
  /* Get the last data part */
  eir_data_part = VmGetPointerFromHandle(inquiry_data[i-1]);
  /* Work out how much actual data there is in it */
  for(j=(HCI_EIR_DATA_BYTES_PER_PTR-1); (eir_data_part[j] == 0) && (j > 0); j--)
  {}
  j++;
  /* Realloc eir data to fit in the last bit */
  eir_data = realloc(eir_data, *size_eir_data + j + 1);
 
  /* Point p to the new section (data may have moved during realloc) */
  p = eir_data + *size_eir_data;   
  *size_eir_data += (j+1);
  /* Copy in the data */
  memmove(p,eir_data_part,j);
  free(eir_data_part);
  /* Terminate data */
  p+=j;
  *p = 0;
 }
 else
 {
  *size_eir_data = 0;
  eir_data = NULL;
 }
 return eir_data;
}

'BlueTooth > 기본기' 카테고리의 다른 글

Security Mode  (1) 2014.06.24
Vega series에서 HID가 connecting state에 머물러 있음  (0) 2014.03.27
Bluetooth Packet Type  (0) 2013.11.06
quoted-printable decoder  (0) 2013.06.03
synergy MessageSendLater  (0) 2011.04.19
bluelab stereo 2009.R2 Inquiry시 iPhone이 검색되면 panic  (0) 2011.03.30
Apple 개발문서  (4) 2010.03.15
Peer-to-Peer Connectivity  (0) 2010.03.04
iphone간 bluetooth 연결 sample  (1) 2010.03.04
아이폰 블루투스 프로그래밍  (3) 2010.03.03
bluetooth keypad  (0) 2010.02.10
posted by bluelimn 2010.03.15 10:59
-Apple Human Interface Guidelines
-Apple Software Design Guidelines
-AppleScript for MacOSX
-Application Architecture
-Basic Drawing
-Certificate, Key, and Trust Services Reference
-Color and Color Management Systems
-Core Foundation Reference
-The Drawing Environment
-HeaderDoc Unfettered
-I/O Kit Fundamentals
-Keychain Services Reference
-Launch Time Performance
-MacOSX Technology Overview
-Screen Saver Reference for Objective-C
-Sheets
-Software Distribution
-Text System Architecture
-What Is Cocoa?
-Working With Bluetooth Devices
-Working With USB Device Interfaces
-Writing an I/O Kit Device Driver

Technical Q&As
-QA1292:Avoiding the -42 error with DiscRecording
-QA1351:Directories Appear as Volume Aliases

원문 : http://kmug.co.kr/board/zboard.php?id=applenews&no=717