This document is still in draft mode. Some section content may change.
- 1 About NTB (New Tizen Bluetooth Framework)
- 2 NTB Architecture
- 3 The current state of development
- 4 Multi-user NTB
- 5 NTB CAPI
- 6 Links
About NTB (New Tizen Bluetooth Framework)
Welcome to the New Tizen Bluetooth Framework Architecture wiki.
Bluetooth Framework is the core middleware of TIZEN Bluetooth. TIZEN is increasingly used on different devices(such as TV, camera and so on).
For improving BT performance and matching TIZEN new features, simple design, save memory consumption, good performance and easily ported to other Tizen verticals are asked to TIZEN Bluetooth Framework.
The old Bluetooth Framework has been unable to meet the above requirements. Therefore, NTB(New Tizen Bluetooth Framework) is developed to fix the above related issues.
The New Tizen Bluetooth Framework Architecture wiki is used for showing the NTB Architecture and the related documents.
Note that Bluetooth features are only supported on reference target devices, not on the SDK Emulator.
The Role Of Bluetooth Framework
The Role of Bluetooth Framework in Tizen
1.Provides Simple, Uniform, Stable CAPI interface for Apps/UI
2.Integrates BlueZ into Tizen elegantly and Handles Tizen specific Bluetooth operations
- Easy to maintain, extend
- High performance, low memory consumption
3.Easily to port to different verticals/branch/Platform
Old Bluetooth Framework
1.Over complicated, performance issue, maintaining issue
2.Bluetooth-Service daemon should not wrap entire BlueZ and proxy all the BlueZ operations and events.
- That makes Bluetooth-Service daemon over complicated
- And difficult to maintain and migrate to latest version of BlueZ
- Impact performance a lot
- Apps should access BlueZ directly in most situations
3.Non-UI operations should be merged into Bluetooth-Service
- To reduce memory consumption
- and improve performance
- Easy to maintain
4.Difficult to migrate to new version of BlueZ
5.Difficult to port to other Tizen verticals or branches
- Verticals/branches may have different apps/UI, vconf, configure …
6.No unified interface for apps/UI
- Some apps call CAPI; while others access Bluetooth-service daemon
- Apps/UI are not easy to write and maintain
7.Bluetooth-Service uses Dbus-glib, which has been replaced by GDbus lib
- Please see Tizen Telephony core code
- Also see
New Tizen Bluetooth Framework
The following picture is New Tizen Bluetooth Framework Architecture
New Design Philosophy
1.Unified CAPI for Apps/UI
2.All Tizen specific non-UI functions are merged in Bluetooth-service daemon
3.Apps/UI access BlueZ directly
- with help functions CAPI/BlueZ-lib
4.Bluetooth-Service only proxy paring and OPP operations for BlueZ
5.BlueZ-lib facilitates BlueZ services access
- Hide the DBus operation detail
- Easily to migrate to new version of BlueZ
- Easy to port to other vertical/platform
7.Bluetooth-Service is modulated
- Easy to add new feature
- Module load/unload runtime
8.A2DP(Pulse Audio) uses upstream solution
- Pulse Audio accesses BlueZ directly and independent from the Bluetooth Framework
- Using ConnMan based tethering over bluetooth
- ConnMan accesses BlueZ dreictly and independnt from Bluetooth Framwork
The comparison between two bluetooth framework
New Tizen Bluetooth Framework Upgrading BlueZ is more easily than Old Bluetooth Framework.
This design will make the big version upgrade very easy, all the upgrade work will focus on very limited files
The small change of BlueZ API, we also can get benefit especially to people not familiar with the code.
Compared with the original design Current design is simple and the code is more easy to be understood and easy to maintain
New Tizen Bluetooth Framework memory consumption is less than Old Bluetooth Framework.
New Design Saves >50% Memory, it is our goal to touch it in the next step.
At current, the memory consumption value is tested again.
The reason of memory consumption.
a. New Tizen Bluetooth Framework invoke the interfaces of Bluez directly.
It saves the unnecessary memory consumption.
b. New Tizen Bluetooth Framework will use the load/unload way to run the external modules(such as HFP, MAP and so on).
When not using the external modules, the related memory will be saved.
c. Only one BT daemon runs on the system.
Too many daemons will use more memory.
The current state of development
We have finished 0.2 release
- This release includes:
- Software framework
- Enhanced CAPI
- Refined Bluetooth service Daemon
- Bluez lib
- Basic Bluetooth Profiles
- Adapter functionality
- Device functionality
- Data share(OPP client/server)
- MAP agent
It is Basing on latest upstream BlueZ(5.x)
Some IOT and mobile related features are being developed.
The related bug has been created on Jira in PTF-184
The current NTB new status:
1. Working with Dominique's team to merge NTB to TIZEN Common.
We plan to merge NTB to TIZEN Common before 2014.12.
We are in the process of merging.
2. “Error and Exception Handling fix” feature is being developed and will be finished in two weeks.
3. “Runtime plugin and module load/unload” feature is being developed and will be finished in two weeks.
The TCT BT NTB result
What is Web TCT
TCT is short for the Tizen Compliance Tests, which validates platform compatibility for Tizen.
Why is Web TCT test done
Bluetooth TCT test cases are for checking the related features of Bluetooth-Frwk are ok or not.
The necessary BT features on Tizen are tested and checked by Bluetooth TCT test.
TCT Work Flow
TCT Test Results
- Current PASS ratio：(314+1)/(322 -1 )= 98.13%
- Bluez5.x doesn’t support BluetoothAdapter_setName_longname, so give it up
- To get test results, please download the file and modify the result file type to ".tgz" (File:Result.tgz.doc)
To ease bluetooth multi-user integration into Tizen, let's split this task into different phases ordered by priority.
phase 1 : user isolation
Ensure that userB can NOT benefit from the pairing link between deviceL and deviceR initiated by userA
userA owns the deviceR1 connection. userB can NOT connect to deviceR1
userB can pair and connect to deviceR2
phase 2 : shared-pairing with exclusive connection
phase 3 : shared-pairing with parallel connections
phase 4 : local adapter control
phase 5 : sharing devices
Please check the detail info from https://wiki.tizen.org/wiki/Multi-user_Bluetooth.
Our plan is two steps
a. To finish phase1 before NTB is integrated to Tizen.org
After then, NTB will be integrated to Tizen.org.
b. We will continue to check and investigate the related features(phase2, 3 and so on) on Tizen.org.
At current, phase1 has been finished in NTB and it will be supported more
After integration to Tizen.org, we will start the next steps.
NTB only support the CAPI layer's multi-user controlling.
It is enough to control the all official BT applications.
The related official applications in Tizen3 (web application and native application) will only use the CAPIs to control BT.
The following points are the Multi-user NTB design
a. NTB daemon will record the paired remote devices info (which user of Tizen paired with the remote BT devices).
According to the record, we can get the privileges of the different user with the different BT devices.
The record items will be recorded in the file of .bt_privileges.
The item includes the paired remote address and the user ID paired with remote BT device.
Get the above two values from .bt_privileges and according to the BT phase1 requirements of Multi-user,
NTB daemon can know if someone user have privileges to use the paired BT devices or not.
b. NTB daemon add two the interfaces to implement the features of multi-user BT.
"GetUserPrivileges" and "RemoveUserPrivileges"
1. GetUserPrivileges provides if the related user have privileges to control/pair with the remote devices or not.
BT APP --->inovke GetUserPrivileges interface --> NTB daemon
BT APP <-- return the related privileges <-- NTB daemon
2. RemoveUserPrivileges provide to remove the record of remote device privileges.
BT APP unpaired finish --> inovke RemoveUserPrivileges interface --> NTB daemon(NTB daemon remove the unpaired device record info).
The flow of multi-user BT are the following two pictures
Multi-user NTB test cases
All test cases are running on Tizen Common.
UserA is User "Alice".
UserB is User "Bob".
Remote BT Device is DeviceA.
Local BT Device is DeviceL.
1. UserA paired with DeviceA(DeviceA didn't be paired with DeviceL), UseA can pair with DeviceA.
2. After paired with DeviceA, UserA can audio connect with DeviceA.
3. After paired with DeviceA, UserA can hid connect with DeviceA.
4. After paired with DeviceA, UserA can socket connect with DeviceA.
5. After paired with DeviceA, UserA can send files to DeviceA.
6. After paired with DeviceA, UserB can't audio connect with DeviceA.
7. After paired with DeviceA, UserB can't hid connect with DeviceA.
8. After paired with DeviceA, UserB can't socket connect with DeviceA.
9. After paired with DeviceA, UserB can't send files to DeviceA.
10.UseB can't unpaire with DeviceA.
10.UseA can unpaire with DeviceA.
11.After UserA unpaired with DeviceA, UserB can pair with DeviceA.
13.After UserB paired with DeviceA, UserB can audio connect with DeviceA and UserA can't audio connect with DeviceA.
14. After UserB paired with DeviceA, UserB can hid connect with DeviceA and UserA can't hid connect with DeviceA.
15. After UserB paired with DeviceA, UserB can socket connect with DeviceA and UserA can't socket connect with DeviceA.
16. After UserB paired with DeviceA, UserB can send files to DeviceA and UserA can't send files to DeviceA.
1. Remote device pair the multi-user support device, which user should response the pair request?
Case: Remote device send the pair request to local device which has "Bob" and "Alice" users run at the same time, and who will popup the pincode dialog.
2. OPP, sending file request from remote device, and then which user should response the file accept/reject request?
Case: Remote device send the file to local device which has "Bob" and "Alice" users run at the same time, and who will popup the "Accept/Reject file" dialog.
3. Socket(RFComm) multi-user is checking. At current, Socket(RFComm) is low priority in IVI.
a. NTB keep the existed BT CAPIs and NTB didn't modify the existed BT CAPIs' name, param and return. Therefore, the CAPIs of NTB matches the CAPIs of Bluetooth-Frwk.
b. The current BT application based on the CAPIs of Bluetooth-Frwk doesn't need to be modified. The current BT application can work well based on NTB.
c.The current Bluetooth Frwk doesn't provide the BT agent CAPIs. The BT agent is implemented by the Bluetooth Frwk internal ways.
NTB only provide the interfaces of BT CAPIs and not provide the other interfaces to control BT. Therefore, to support BT agent, NTB added the related BT CAPIs to implement it.
The following points are the added BT agent CAPIs.
* @ingroup CAPI_NETWORK_BLUETOOTH_AGENT_MODULE * @brief Register bluez agent. * * @remarks This function must be called before all Bluetooth Agent API. * You must free all resources of the Bluetooth agent by calling * bt_agent_unregister() if Bluetooth agent is no longer needed. * * @return 0 on success, otherwise negative error value. * @retval #BT_ERROR_NONE Successful * @retval #BT_ERROR_NOT_INITIALIZED Not initialized * @retval #BT_ERROR_INVALID_PARAMETER Invalid parameter * @retval #BT_ERROR_ALREADY_DONE Already register * * @see bt_agent_unregister()
int bt_agent_register(bt_agent *agent);
* @ingroup CAPI_NETWORK_BLUETOOTH_AGENT_MODULE * @brief Releases all resources of the Bluetooth Agent. * * @remarks This function must be called if Bluetooth Agent is no longer needed. * * @return 0 on success, otherwise negative error value. * @retval #BT_ERROR_NONE Successful * @retval #BT_ERROR_NOT_INITIALIZED Not initialized * * @see bt_agent_register()
* @ingroup CAPI_NETWORK_BLUETOOTH_AGENT_MODULE * @brief Agent accept confirm info. * * @param[in] user_data The user data from agent callback * indicate which confirm will be accepted. * * @see bt_agent_register() * @see bt_agent_unregister() * @see bt_agent_confirm_reject()
void bt_agent_confirm_accept(bt_req_t *requestion);
* @ingroup CAPI_NETWORK_BLUETOOTH_AGENT_MODULE * @brief Agent reject confirm info. * * @param[in] user_data The user data from agent callback * indicate which confirm will be rejected. * * @see bt_agent_register() * @see bt_agent_unregister() * @see bt_agent_confirm_accept()
void bt_agent_confirm_reject(bt_req_t *requestion);
* @ingroup CAPI_NETWORK_BLUETOOTH_AGENT_MODULE * @brief Agent puts the pin code to authorize. * * @param[in] pin_code The pin code used to authorize. * @param[in] user_data The user data from agent callback * indicate which pin code authorized will be reply. * * @see bt_agent_register() * @see bt_agent_unregister() * @see bt_agent_pincode_cancel()
void bt_agent_pincode_reply(const char *pin_code, bt_req_t *requestion);
* @ingroup CAPI_NETWORK_BLUETOOTH_AGENT_MODULE * @brief Agent cancel the authorized with pin code. * * @param[in] user_data The user data from agent callback * indicate which pin code authorized will be reply. * * @see bt_agent_register() * @see bt_agent_unregister() * @see bt_agent_pincode_reply()
void bt_agent_pincode_cancel(bt_req_t *requestion);
d. At current, OOB (NFC handover BT) is implemented by using the internal Bluetooth APIs.
NTB only support the BT CAPIs.
Therefore, the OOB related CAPIs need to be added too.
Two OOB BT capis will be added.
1. Bluetooth read local OOB data.
2. Bluetooth add the remote OOB data.