Sdl_evolution: [Accepted] SDL 0053 - Connectivity via iAP-BT and Transport Switch

[theresalech]

Hello SDL community,

The review of the revised proposal "SDL 0053 - Connectivity via iAP-BT and Transport Switch" begins now and runs through May 23, 2017. The original review of "Connectivity via iAP-BT and Transport Switch" occurred April 18 through April 25, 2017. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0053-Connectivity-via-iAP-BT-and-Transport-Switch.md

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

https://github.com/smartdevicelink/sdl_evolution/issues/158

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

• Is the problem being addressed significant enough to warrant a change to SDL?
• Does this proposal fit well with the feel and direction of SDL?
• If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
  Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you,
Theresa Lech

Program Manager - Livio
[email protected]

[madhuy]

HMI can then proceed with closing the iAP session over the Bluetooth transport. Apps which are connected over BT would get disconnected when the iAP session over BT is closed and would need to register over USB.

I don't think you can close iAP session from HU(HMI).

[madhuy]

And also I dont think “reconnection” timer will work in below case

1. USB + BT Connected
2. Disconnect USB.
   in above case SDL proxy gets AccessoryDisconnect and AccessoryConnect from iOS which makes SDl proxy recycle and causes app to unregister and register.

[robinmk]

1) HU can close the iAP session just as it is responsible to setup the iAP session.
2) Yes that is correct, the "reconnection" timer is meant to work when switching from BT to USB.
When BT is connected and then USB, both transports are available and hence the re-connection strategy is applicable.

[madhuy]

@robinmk
Thanks for your answers.

Regarding # 1 - HU can close the iAP session just as it is responsible to setup the iAP session.

HU(accessory) can not open/Close Session. open/Close is done only by iOS Device.

Please Check "Mfi Accessory Firmware Specification" _section 1.7.6 Communication iAP commands_

Spec says as below

0x3F OpenDataSessionForProtocol Dev to Acc
0x40 CloseDataSession Dev to Acc {transID:2, sessionID:2}

Dev means iOS device
Acc means HU.

[robinmk]

Thank you for the feedback. I guess the term "close" is causing some confusion. Sorry about that.
In this case, the accessory has to shut down the iAP2 connection. (This is the term used in the 'Accessory Interface Specification'.

[madhuy]

@robinmk

I did check in 'Accessory Interface Specification'
_# 2.16 Disconnecting and reconnecting section says_
Accessories must not initiate a connection disconnect or reconnect except in the case of user direct action (such as physical unplug/replug, moving a wireless device out of range,turning on/off an accessory , etc.) unless otherwise specified (such as USB Role Switch and Carplay)

Please let me know if i missing any thing here.
Since It is significant change in SDLcore, I would suggest have Sequence diagram each use cases( it is personal suggestion) it is upto SDLC to define the process.

[robinmk]

There is a section about having multiple iAP connections.
This change is to be done by the HMI (outside core). The changes to core are as outlined in the impact section

[Toyota-Sbetts]

@robinmk

the accessory has to shut down the iAP2 connection

Even if this is feasible, other features may rely on the iAP2 connection and closing it may disrupt other features of the head unit. This proposal seems to impose large requirements on the system adopting SDL Core to behave in a specific way that might conflict with OEM specifications.

We would also like to see some sort of sequence diagram for the proposal if possible to ensure our understanding of the text is correct.

[madhuy]

@robinmk

There is a section about having multiple iAP connections.

are you talking about this from 2.15 section?
Alternatively, an accessory may shutdown the iAP2 Connection
if yes, Then it shutdowns all the sessions not only SDL specific Session.

This change is to be done by the HMI

If I understand the floe correctly the current flow is as below.

1. Transport adapter send devicelist to SDLcore.
2. SDLcore send Device list to HMI by using UpdateDevicelist().
3. HMI send onDeviceChosen() to SDlcore with device ID.
4. SDL core establishes communication for the perticular Device ID.

You think HMI need to communicate directly with Native iAP services to start connection/shutdown prior to all above steps. in this case OEM's need to provide porting layer to HMI Since OEM implements iAP stack.

[robinmk]

@madhuy ,
Yes the the iAP2 connection is shutdown and not a specific session.
Since OEM implements the transport drivers it is the HMI layer (outside SDL) which has to shut down the iAP2 connection.
@Toyota-Sbetts ,
Apple specifications require that the accessory must not continue using multiple iAP2 connections.
The HMI layer is responsible for setting up and shutting down the iAP2 connection and is not imposed by the SDL layer.
The major change from SDL would be regarding holding off on sending unregistration info till "reconnection" timer times out.
I don't have a detailed seq diagram ready, will try to put together something

[Toyota-Sbetts]

@robinmk

The HMI layer is responsible for setting up and shutting down the iAP2 connection and is not imposed by the SDL layer

The HMI layer (which talks to SDL Core via websockets) and the Transport layer (which connects to the transport adapter) may be two separate components on the HU. Our understanding of the proposal is now the HMI layer must also manage and be aware of the transport layer status and I think @madhuy clarifies that above as our understanding of the flow matches his. This will impose specific requirements to the OEM which may conflict with specification or design.

[madhuy]

@robinmk

Yes the the iAP2 connection is shutdown and not a specific session.

I don't think OEM's allow HMI to do that.

Since OEM implements the transport drivers it is the HMI layer (outside SDL) which has to shut down the iAP2 connection.

It means either HMI needs some porting layer to use transport driver or HMI needs to use SDlcore to communicate with Tranport driver. if HMI communicate through SDlcore need to add new API's

[robinmk]

[robinmk]

Adding a seq dig

[AGaliuzov]

@robinmk @madhuy @Toyota-Sbetts
Please try to review this proposal considering the above information

There is a difference between HMI which uses HMI_API and HMI in the terms low-level system layer.

Every OEM has some set of drivers and own logic how to handle devices connectivity. Let’s call it “System” it responsible in particular for the following activities:
The order of connectivity
The special stack (BlueZ, iAP, AOA)
The own api / libraries to use above stacks.
From the other hand, OEM has some graphical representation which we usually call HMI and it works in terms of HMI_API.

Now, in terms of iAP reconnection. The “System” provides some low-level API for SDL to work on transport layer: iAP, API, Bluetooth API, USB(AOA). The same system has to provide to SDL the ability how to handle connected device Whereas HMI layer is supposed to update the information about the current system state in appropriate for user way.

Let’s try to avoid this mixing between HMI logic and “System” logic. All the low-level signals are received by SDL directly from system and whereas the high-level logic remains untouched

[Toyota-Sbetts]

@robinmk @AGaliuzov
Thanks for the quick turn around on the sequence diagram!
I think it's cleared up a lot of questions around the proposal from our end.

Overall, we support a lot of the ideas in this proposal: transport switching support, automatic reconnection logic, etc.
We are still reviewing this proposal in detail to understand its impact to our current implementation but have a few questions/clarifications:

1. Legacy Transports
   We want to ensure legacy transport adapters are still supported after this change as changing the system logic beefore major model revisions can sometime be very difficult.

2. iAP Specific Behaviors
   From the sequence diagram, it seems the transport manager specifically calls out the iAP adapters for "substitute iAP2Bt adapter for iAP2Usb adapter" but we're concerns about the TM having this TA specific behavior.
   Is the plan to have some generic way for TAs to thell the TM of exclusivities or when multiple transports are allowed?
   We feel this proposal would be best to enhance existing TA functionality and not be necessarily iAP specific and just ensure the iAP use case is encompassed.

3. System should control the transport switching
   In the current sequence diagram, the TA notifies the system via SDL_MSG_iPOD_DEVICE_TRANSPORT_SWITCH (caused by some trigger from the TM?).
   We feel the system should always be control of the transport state and be responsible for controlling the transport switch otherwise we may run into conflicts or timing issues with other iAP features.

[madhuy]

@robinmk @AGaliuzov

Thank you for Sequence diagram and explanation. Please update Proposal with "System" instead of HMI.

And also I see one assumption, TA expects to same UUID for BT, BT+USB and USBOnly from System.

Handling iOS AccessoryDisconnect/Connect Notification in HS App

When System shutdown iAP connection, SDL proxy gets AccessoryDisconnect/Connect from iOS which makes SDL proxy recycles and send RegisterAppinterface. in this case does SDL core ignore to send onHMIStatus(NONE) ?

Handling Multiple app case and protocol strings
if Multiple apps running and have each have its protocol strings, There is no guarantee that app connects same protocol string after reconnection(explained below). does this have any impact on System implementation or TA implementation.
Ex:
Initially,
_App1 <-> com.smartdevicelink.proto1
App2 <-> com.smartdevicelink.proto2_
after reconnection there is possibility of changing protocol string
_App1 <-> com.smartdevicelink.proto2
App2 <-> com.smartdevicelink.proto1_

Finally, Do we really need to have separate TA's (BT,USB)? can we handle with one TA with different transportType?

[AGaliuzov]

@Toyota-Sbetts

Legacy Transports
We want to ensure legacy transport adapters are still supported after this change as changing the system logic before major model revisions can sometimes be very difficult.

The transport adapter is system(OEM) specific thing. Basically, the already existing adapters are remaining untouched. The existing proposal is related to iAP2 only.

From the sequence diagram, it seems the transport manager specifically calls out the iAP adapters for "substitute iAP2Bt adapter for iAP2Usb adapter" but we're concerns about the TM having this TA-specific behavior.

Yes, this proposal is related to iAP adapter only. But the switch logic is performed on the TM side and the TM is the same for any OEM. From the other hand, it is quite hard to implement something similar for Android because there is no way to have something similar to UUID. SDL uses USB serial and BT mac for android. So it does not know if there is same device or no.

System should control the transport switching

It is quite feasible. However, I would suggest having some additional parameter in ini file for the automatic switching. So the certain integrator could be able to decide whether they want to control switching mechanism or allow SDL to do this automatically.
The overall sequence could be as following:

1. SDL has BT connected device.
2. SDL has received the same device via USB
3. SDL check the ini file for the configuration: if the auto switch is allowed it performs the switch flow. Otherwise, SDL will wait for the certain signal from the system and the USB connection remains inactive.

[AGaliuzov]

@madhuy

And also I see one assumption, TA expects to same UUID for BT, BT+USB and USBOnly from System.

This is right, just consider that it works only for iAP transport.

There is no guarantee that app connects same protocol string after reconnection(explained below). does this have any impact on System implementation or TA implementation.

The protocol strings will not affect the reconnection flow. SDL decides whether app has been reconnected or no using the information from RegisterAppInterfaceRequest: appName, policy_app_id, deviceID.

Finally, Do we really need to have separate TA's (BT,USB)? can we handle with one TA with different transportType?

This is the pure implementation question. Basically, we don't need to have the separate adapters and having adapter type is enough to handle the switch flow

When System shutdown iAP connection, SDL proxy gets AccessoryDisconnect/Connect from iOS which makes SDL proxy recycles and send RegisterAppinterface. in this case does SDL core ignore to send onHMIStatus(NONE) ?

Please consider this as the regular unexpected disconnect

[theresalech]

The Steering Committee has deferred this proposal, requesting that the implementation be revised to be more generic, as opposed to the specific iAP adaption currently described. The Ford and Xevo teams will work together to revise, and the Steering Committee will review again once the revisions are in place.

[AGaliuzov]

@Toyota-Sbetts @madhuy @robinmk please find updated diagram

[theresalech]

The review of the revised proposal "Connectivity via iAP-BT and Transport Switch" begins now and runs through May 23, 2017.

[theresalech]

With the inclusion of the diagram posted on 2017-05-15, this proposal has been accepted by the Steering Committee. The Ford and Xevo teams have also discussed additional enhancements for this feature and will be entering separate proposals for such.

[theresalech]

Issue entered: [SDL 0053] Connectivity via iAP-BT and Transport Switch