File transfer over BLE. OTS or something else?

[mrono]

Hello.

I need to transfer files from a phone to a BLE peripheral device. I have a small FatFS filesystem on an external flash chip on the device, and I'm now trying to decide how to transfer files to and from it. I'm using the nRF5 SDK.

I already have a custom BLE service on the device, which has characteristics for sending commands and associated parameters. This works well, but the assumption so far has been that all data for a command fits into a single characteristic write or read. I could extend this system to handle "appending" data to a file. And also to create, write, read, name, list and checksum files. But this seems like reinventing the wheel to me, so I'm looking at OTS to see if I could use it instead. I have been looking at the OTS server and client examples.

Before I start adding OTS to my application, I have a few questions:

• I haven't worked with L2CAP channels before. How do they coexist with regular GATT services? Can I simply treat it as "just another service"? Or is there a penalty in terms of power consumption or bandwidth usage on having an L2CAP channel open?
• How good is support for OTS in phones? I mean iOS and Android. If I choose to use OTS will I make life easier or harder for our app developers compared to a custom solution?
• How do I handle large files too big to hold in ram temporarily? I'm assuming this isn't a problem, but do I need a "flow control"-like mechanism to ensure that buffers won't overflow while waiting for the flash write to finish?
• Perhaps a detail at this point, but OTS objects have a type which is a UUID. Is there a generic "file" object type? Or perhaps a binary/text object type?

Lastly, an example combining OTS and a file system would be great. But I did see that someone asked for that just a few weeks ago.

[ovrebekk]

Hi 

I haven't worked with L2CAP channels before. How do they coexist with regular GATT services? Can I simply treat it as "just another service"? Or is there a penalty in terms of power consumption or bandwidth usage on having an L2CAP channel open?

It is up to the L2CAP module to interface to any L2CAP COC channels you might be using, in addition to the normal GATT data. 

In principle you can just treat it as any other service, yes. Total bandwidth will have to be shared between the L2CAP COC channels and any regular GATT services you have running, just as you need to share bandwidth between GATT services normally. 

In terms of power consumption and total bandwidth running L2CAP COC channels should be slightly more efficient than GATT, since you have a bit less overhead (every GATT packet requires a 3 byte ATT header, which you don't need for L2CAP COC data), but the difference is negligible. 

How good is support for OTS in phones? I mean iOS and Android. If I choose to use OTS will I make life easier or harder for our app developers compared to a custom solution?

Android added support for this in version 8, and you also have support on iOS. 

We don't have any examples showing how to set this up on the phone side unfortunately, so you would have to implement this on your own. 

How do I handle large files too big to hold in ram temporarily? I'm assuming this isn't a problem, but do I need a "flow control"-like mechanism to ensure that buffers won't overflow while waiting for the flash write to finish?

The easiest way to handle this is simply to stop calling the sd_ble_l2cap_ch_rx(..) function when you run out of memory in the application, and then the SoftDevice will automatically hold off on receiving any more updates. L2CAP COC channels use their own credit based flow control scheme, to ensure that no more data is sent if the buffers are full on the peer side.  

Perhaps a detail at this point, but OTS objects have a type which is a UUID. Is there a generic "file" object type? Or perhaps a binary/text object type?

The specification doesn't say anything about this, other than that "Relevant object types that are to be used for a given application may be specified by a higher-level specification."

If you do something proprietary you are free to generate random 128-bit UUID's that you can use, and associate them with whatever you want. 

Lastly, an example combining OTS and a file system would be great. But I did see that someone asked for that just a few weeks ago.

Do you have a link to the case?

Best regards
Torbjørn

[mrono]

Thank you

ovrebekk said:

In principle you can just treat it as any other service, yes. Total bandwidth will have to be shared between the L2CAP COC channels and any regular GATT services you have running

Bandwidth will be shared, that is clear. What I was unsure about was if an L2CAP COC channel has its own equivalent of "empty PDUs" sent all the time to keep the connection open. I'll need to read some more about it.

ovrebekk said:

Android added support for this in version 8, and you also have support on iOS. 

We don't have any examples showing how to set this up on the phone side unfortunately, so you would have to implement this on your own.

I was hoping that something like FTP over BLE existed. It seems that OTS could be a base for that, but searching for "OTS file transfer" and similar yields very little results. The search for a file UUID was also in hope that someone had already standardized this type of operation.

This is the core of my dilemma. I'm not an app developer so it is difficult for me to estimate if implementing OTS helps here. It is a standard service, so it ought to be easier to implement that a fully custom one. But it seems there is still a lot that we'd need to do ourselves. Even on the peripheral side, the infocenter docs say that the Nordic OTS implementation isn't qualified. I'm guessing it is incomplete. This device will eventually be certified, so I'd need to add any missing bits to comply with the standard. If I choose to do a fully custom service for file transfer, I'm free to implement as much or as little as I need. But then I do need to implement it all myself.

ovrebekk said:

L2CAP COC channels use their own credit based flow control scheme, to ensure that no more data is sent if the buffers are full on the peer side.

Thank you, that is clear now.

ovrebekk said:

Do you have a link to the case?

This case is what I meant.

[ovrebekk]

Hi

mrono said:

Bandwidth will be shared, that is clear. What I was unsure about was if an L2CAP COC channel has its own equivalent of "empty PDUs" sent all the time to keep the connection open. I'll need to read some more about it.

The link layer already does this, there is no need to have a separate mechanism for each higher level protocol. In other words the L2CAP COC channels will just rely on the standard link layer empty packet mechanism. 

mrono said:

This device will eventually be certified, so I'd need to add any missing bits to comply with the standard. If I choose to do a fully custom service for file transfer, I'm free to implement as much or as little as I need. But then I do need to implement it all myself.

I discussed this some more with the app developer, and while he confirmed that proper OTS support on the mobile side is something they want to add they have a lot of other things to do first, and even if they decide to provide it it could take a year or more before we are able to have something ready. 

He also pointed out the fact that the OTS specification is quite complex, and requires much more work to add than a proprietary GATT service. 

In other words, for the time being I would have to recommend doing something based on a proprietary GATT service. 

Best regards
Torbjørn

[mrono]

ovrebekk said:

the OTS specification is quite complex, and requires much more work to add than a proprietary GATT service

ovrebekk said:

for the time being I would have to recommend doing something based on a proprietary GATT service

Thank you. This was exactly the kind of advice I was hoping for.

[ovrebekk]

You welcome. The best of luck with your project