Subject: [core] Running CoAP over a local BLE network

From: "Golnaz KARBASCHI" <[email-masked]>
Date: Mon, 6 May 2013 15:33:07 +0200

Hello to All , 
 
I have a question about running a COAP application instead of GATT based
profiles over a local network with BLE (Bluetooth Low Energy) peripherals.
The idea of using CoAP is its http friendly characteristics (RESTfull
structure) and its lightness for a constrained based network, like BLE. BUT
we do not want to have necessarily the end-to-end IP connections all the way
on our local network.  
 
Supposing to have a BLE local network like the figure below, with a host
node for accessing to the exterior connections (such as internet connection)
O--- BLE-----O (HOST) ---------  > internet
O--- BLE-----|
O--- BLE-----|
 
My question is that if we don't care running IPV6 all the way to BLE
peripherals (and so don't need to implement a 6lowpan layer), is there still
any interest to use CoAP?
 
And if we decided to run CoAP instead of existing structures and profiles of
BLE, can CoAP in a network without running IPV6 be implemented on BLE as is?
How should it be implemented ?  Is it correct to say that CoAP will behave
just as a new profile for the BLE network? 
Meaning that L2CAP takes care of adaptation between CoAP and lower layers
(MTU adaptation, etc.) and CoAP plays its role to have a http friendly
interface for the network ?    
 
Thank you in advance if any one that is familiar with BLE or not (!) can
give me more information about this question.
 
Golnaz KARBASCHI

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 7 May 2013 13:30:30 -0400

Hi Golnaz,

I am not familiar with BLE, but with regards to your specific question
of:

"...can CoAP in a network without running IPV6 be implemented on BLE as
is?"

My response is:

*         No, you cannot implement CoAP on a network that is not running
IPv6 (or IPv4)

*         CoAP was meant to run on an UDP/IP protocol stack.  There are
many critical parts of the CoAP protocol that would break if the
underlying layers was not UDP/IP.  For example:

o   Using the IPv6 address as a literal in the host part of the URI (
http://tools.ietf.org/html/draft-ietf-core-coap-16#section-5.10.1 )

o   Triggering IP multicast (
http://tools.ietf.org/html/draft-ietf-core-coap-16#section-8 )

o   Listening on the UDP port number
(http://tools.ietf.org/html/draft-ietf-core-coap-16#section-12.7 )

o   Etc.

So, to repeat, I do not believe that you can run CoAP on a network that
does not have IPv6 (or IPv4) underneath.

Hope that helps.

Best Regards,

Akbar

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Golnaz KARBASCHI
Sent: Monday, May 06, 2013 9:33 AM
To: [email-masked]
Subject: [core] Running CoAP over a local BLE network

Hello to All , 

I have a question about running a COAP application instead of GATT based
profiles over a local network with BLE (Bluetooth Low Energy)
peripherals.

The idea of using CoAP is its http friendly characteristics (RESTfull
structure) and its lightness for a constrained based network, like BLE.
BUT we do not want to have necessarily the end-to-end IP connections all
the way on our local network.  

Supposing to have a BLE local network like the figure below, with a host
node for accessing to the exterior connections (such as internet
connection)

O--- BLE-----|

O--- BLE-----|

My question is that if we don't care running IPV6 all the way to BLE
peripherals (and so don't need to implement a 6lowpan layer), is there
still any interest to use CoAP?

And if we decided to run CoAP instead of existing structures and
profiles of BLE, can CoAP in a network without running IPV6 be
implemented on BLE as is? How should it be implemented ?  Is it correct
to say that CoAP will behave just as a new profile for the BLE network? 

Meaning that L2CAP takes care of adaptation between CoAP and lower
layers (MTU adaptation, etc.) and CoAP plays its role to have a http
friendly

Golnaz KARBASCHI

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 May 2013 00:22:03 +0400

While this (can't run CoAP directly on BLE L2CAP) is true today, we do have proposals for various alternative transport bindings (including SMS), so if this is a sensible thing to do, we could look into it.  On the BLE level, the obvious choking point is channel allocation.  I'd like to understand the usecase some more, and build more of an opinion when I'm back in Germany next week... 

Sent from my iPad

On 07.05.2013, at 21:30, "Rahman, Akbar" <[email-masked]> wrote:

> Hi Golnaz,
>  
> I am not familiar with BLE, but with regards to your specific question of:
>  
> “…can CoAP in a network without running IPV6 be implemented on BLE as is?”
>  
>  
> My response is:
> ·         No, you cannot implement CoAP on a network that is not running IPv6 (or IPv4)
> ·         CoAP was meant to run on an UDP/IP protocol stack.  There are many critical parts of the CoAP protocol that would break if the underlying layers was not UDP/IP.  For example:
> o   Using the IPv6 address as a literal in the host part of the URI ( http://tools.ietf.org/html/draft-ietf-core-coap-16#section-5.10.1 )
> o   Triggering IP multicast ( http://tools.ietf.org/html/draft-ietf-core-coap-16#section-8 )
> o   Listening on the UDP port number (http://tools.ietf.org/html/draft-ietf-core-coap-16#section-12.7 )
> o   Etc.
>  
>  
> So, to repeat, I do not believe that you can run CoAP on a network that does not have IPv6 (or IPv4) underneath.
>  
>  
> Hope that helps.
>  
>  
> Best Regards,
>  
>  
> Akbar
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Golnaz KARBASCHI
> I have a question about running a COAP application instead of GATT based profiles over a local network with BLE (Bluetooth Low Energy) peripherals.
> The idea of using CoAP is its http friendly characteristics (RESTfull structure) and its lightness for a constrained based network, like BLE. BUT we do not want to have necessarily the end-to-end IP connections all the way on our local network. 
>  
> Supposing to have a BLE local network like the figure below, with a host node for accessing to the exterior connections (such as internet connection)
> My question is that if we don't care running IPV6 all the way to BLE peripherals (and so don't need to implement a 6lowpan layer), is there still any interest to use CoAP?
>  
>  
> And if we decided to run CoAP instead of existing structures and profiles of BLE, can CoAP in a network without running IPV6 be implemented on BLE as is? How should it be implemented ?  Is it correct to say that CoAP will behave just as a new profile for the BLE network?
> Meaning that L2CAP takes care of adaptation between CoAP and lower layers (MTU adaptation, etc.) and CoAP plays its role to have a http friendly
> Thank you in advance if any one that is familiar with BLE or not (!) can give me more information about this question.
>  
> Golnaz KARBASCHI
>  
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 8 May 2013 10:49:32 +0200

Hi Golnaz,

I would also like to know more about the use case.

On the side of advantages of your proposal, I understand that you would
avoid the (compressed) IPv6 and UDP headers in the transmitted packets.
This would save the addition of at least 6/7 bytes to each CoAP layer
packet, which would be significant savings. The header overhead including
BLE headers would decrease by at least 30% if your CoAP packets (plus
IPv6/UDP headers) fit in a single BLE Data Channel PDU (i.e. have a
maximum size of 23 bytes). If those packets slightly exceed 23 bytes, the
savings would be much greater. Another advantage is that you would avoid
as well the implementation of 6LoWPAN/IPv6/UDP.

However, the peripherals you mention would miss the opportunity of being
Internet citizens. And the hosts in your figure would have to perform some
form of protocol translation or adaptation.

As Carsten said, another issue would be which L2CAP channel identifier(s)
should be used to indicate that the protocol on top of L2CAP is CoAP. Use
of L2CAP channel IDs is regulated by the Bluetooth SIG.

The IPv6 over BLE draft almost passed IESG, but there is a pending
DISCUSS, which will be (hopefully) solved once it is clear which L2CAP
channel identifier(s) can be used for IPv6. Fortunately, the Bluetooth SIG
found it worth to launch a working group in order to provide the necessary
functionality to allow IPv6 over BLE, and this includes a decision on the
channel identifier(s) for IPv6. However, this process has required (and
will still require) some time to reach completion.

Hope this helps!

Carles

> While this (can't run CoAP directly on BLE L2CAP) is true today, we do
> have proposals for various alternative transport bindings (including SMS),
> so if this is a sensible thing to do, we could look into it.  On the BLE
> level, the obvious choking point is channel allocation.  I'd like to
> understand the usecase some more, and build more of an opinion when I'm
> back in Germany next week...
>
> Sent from my iPad
>
>> ·         CoAP was meant to run on an UDP/IP protocol stack.  There are

---

From: "Golnaz KARBASCHI" <[email-masked]>
Date: Tue, 14 May 2013 13:52:25 +0200

Hi Carsten and Akbar,

Thank you for your answers. 

Yes, I agree that there are some parts of CoAP that are defined specifically to work with IP, but there may be some use-cases (like mine) that cannot run the IP all the way to the end points. I think this is a good motivation for starting drafts like : coap with alternative transports (thanks to Bill !):

 <http://datatracker.ietf.org/doc/draft-silverajan-core-coap-alternative-transports/> http://datatracker.ietf.org/doc/draft-silverajan-core-coap-alternative-transports/).

Well, the question was raised in order to know if there is still any interest to implement CoAP over these kinds of networks that do not care about end-to-end IP connections , but need to be compatible with other CoAP networks or at least have http connections to exterior. 

As Carels mentioned too, ignoring IP over our internal network leads to significant saving in overhead but may require installing an adaption/proxy at Host level.

Another motivation of removing IP over our LowPAN is that the ongoing draft (IPV6 over BLE) is still not complete !  

Our use case is a wireless BAN (Body Area Network) autonomous en battery and with BLE peripherals from a main gateway to some sensors and other embedded constrained devices. The gateway communicates wirelessly with a Host  (as shown again in the fig below) which potentially is connected to internet.  

O--- BLE-----|

O--- BLE-----|

Effectively, the pb. of CoAP directly over BLE and instead of GATT is related to Bluetooth compliance issues, such as defining a new channel identifier, etc.  But as suggested, it can be applied to BLE as a new service over the existing GATT profile, Though,  at this point I am not certain that it is a straightforward task to do !. 

Regards,

Golnaz Karbaschi 

De : Carsten Bormann [mailto:[email-masked]] 
Envoyé : mardi 7 mai 2013 22:22
À : Rahman, Akbar
Cc : Golnaz KARBASCHI; [email-masked]
Objet : Re: [core] Running CoAP over a local BLE network

Sent from my iPad

Hi Golnaz,

 

My response is:

o   Etc.

 

Hope that helps.

Best Regards,

Akbar

Hello to All , 

O--- BLE-----|

O--- BLE-----|

 

Golnaz KARBASCHI

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 14 May 2013 19:20:43 +0200

Hi Golnaz,

> Another motivation of removing IP over our LowPAN is that the ongoing
> draft (IPV6 over BLE) is still not complete !

The last pending IESG DISCUSS on the draft is which L2CAP Channel ID(s)
may be used for 6LoWPAN. Besides this, I think there will be no further
changes to the draft.

> Effectively, the pb. of CoAP directly over BLE and instead of GATT is
> related to Bluetooth compliance issues, such as defining a new channel
> identifier, etc.  But as suggested, it can be applied to BLE as a new
> service over the existing GATT profile, Though,  at this point I am not
> certain that it is a straightforward task to do !.

I have not analyzed in detail this approach, but one first comment I have
is that there would be some (possibly large) degree of functionality
duplication between GATT/ATT and CoAP on top of it. Isn't GATT/ATT alone
good enough for the peripherals in your use case?

Regards,

Carles

---

From: "Golnaz KARBASCHI" <[email-masked]>
Date: Wed, 15 May 2013 13:23:40 +0200

Hi Carels, 

> The last pending IESG DISCUSS on the draft is which L2CAP Channel ID(s)
may be used for 6LoWPAN. Besides this, I think >there will be no further
changes to the draft.

 [Golnaz] Yes, it is in the pending state waiting for BT SIG to decide about
Channel ID. But for this reason, there is no commercial stable stack that
supports IPV6+BLE. So may be good for prototyping .   

> service over the existing GATT profile, Though,  at this point I am 
> not certain that it is a straightforward task to do !.

>I have not analyzed in detail this approach, but one first comment I have
is that there would be some (possibly large) >degree of functionality
duplication between GATT/ATT and CoAP on top of it. Isn't GATT/ATT alone
good enough for the >peripherals in your use case?
[Golnaz] >  Actually GATT/ATT is good enough for data exchange in our use
case. The only reason for looking at CoAP is benefiting from its
interoperability with other CoAP networks and also its compatibility with
http connections. 

Regards,
Golnaz

---

From: Teemu Savolainen <[email-masked]>
Date: Wed, 15 May 2013 14:52:08 +0300

While I do have interest to think about CoAP over BLE..

.. I do not think this to be sound reason, as highly likely IPv6 over BLE
is standard faster than any other standardized approach for transmitting
CoAP over BLE.. All other approaches would start from scratch in BT SIG and
by the time process has been gone through, IPv6 would be out of the
pipeline already.

Best regards,

Teemu

---

From: <[email-masked]>
Date: Wed, 15 May 2013 13:02:15 +0000

Hi,

I can see two main approaches for CoAP over BLE that each have unique advantages:

1.)    CoAP over GATT over BLE: This is a kludge of layers above layers, but its unique advantage is that you could implement it with today's off-the-shelf BLE HW and SW stacks that often only offer GATT-based third party APIs. CoAP over GATT could be transparently mapped to CoAP/UDP/IP or as beind developed in CoRE WG to HTTP/TCP/IP.

2.)    CoAP over 6LoWPAN over BLE: This is the end-to-end IP solution, and something both IETF and BT SIG are alrady standardizing, so it has the advantages associated with IP and 6LoWPAN-based efficiency (low overhead), and if the BLE vendors care about CoAP and/or IP this is the standard they should primarily follow.

CoAP over BLE might IMHO fall into the middle: You still would not be able to implement it as a third party "app" on top of existing BLE GATT stacks e.g. in a smartphone or a tablet with BLE support, and you would not get it standardized faster than 6LoWPAN over BLE. So it would not have neither speed nor generality advantages.

Having said that, these are just my assumptions and if they can be realistically challenged, it might be worthwhile to look into this further.

Markus

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Teemu Savolainen
Sent: 15 May, 2013 14:52
To: Golnaz KARBASCHI
Cc: [email-masked]
Subject: Re: [core] Running CoAP over a local BLE network

> Another motivation of removing IP over our LowPAN is that the ongoing draft (IPV6 over BLE) is still not complete !

.. I do not think this to be sound reason, as highly likely IPv6 over BLE is standard faster than any other standardized approach for transmitting CoAP over BLE.. All other approaches would start from scratch in BT SIG and by the time process has been gone through, IPv6 would be out of the pipeline already.

Best regards,

Teemu

---

From: Bill Silverajan <[email-masked]>
Date: Wed, 15 May 2013 17:10:23 +0300

Hi Golnaz,

>   <http://datatracker.ietf.org/doc/draft-silverajan-core-coap-alternative-transports/> http://datatracker.ietf.org/doc/draft-silverajan-core-coap-alternative-transports/).

Thanks firstly for the endorsement of our draft :-) Indeed, one of the 
main intentions of the work was to have a slightly out-of-the-box 
re-think about what it means to do REST-based resource retrieval using 
CoAP, and decoupling it from the underlying transport.

> Well, the question was raised in order to know if there is still any interest to implement CoAP over these kinds of networks that do not care about end-to-end IP connections , but need to be compat…

There has been interest about doing that with CoAP, and another draft 
(https://datatracker.ietf.org/doc/draft-becker-core-coap-sms-gprs/) 
providing substantial evidence that CoAP's benefits can be employed over 
networks not worrying about end-to-end IP, and instead focusing on 
end-to-end CoAP (if it can be called that).

> Effectively, the pb. of CoAP directly over BLE and instead of GATT is related to Bluetooth compliance issues, such as defining a new channel identifier, etc.  But as suggested, it can be applied to…

The advantage of deploying CoAP over BLE (assuming L2CAP) is that L2CAP 
semantics and behaviour can mimic that of UDP. It's trivial to implement 
this in lab-based proof of concept prototypes. Unfortunately as 
discussed earlier, it's not something that can be realistically deployed 
in products, for all the reasons mentioned.

As I see it, the choices are:

CoAP over 6LowPAN adaptation layer over BLE, or CoAP over GATT over BLE. 
In both cases, an adaptation layer will be necessary for standards 
compliance and will introduce overhead and possibly an overlap of 
functionality, either with the underlying BLE stack or with how 
resources and attributes are represented. So it's either end-to-end IP 
or end-to-end REST, depending on which you prefer.

If the CoAP + GATT solution is chosen, at least these issues should be 
considered:

* Can you integrate the CoAP resource identification into the 
service/characteristic model of GATT? In this case, it's worth to 
consider whether your abstraction is really CoAP over GATT, or a 
CoAP-GATT proxy.

* Can you extend CoAP group communication/service discovery to leverage, 
again, the GATT/ATT profiles and what are its implications towards 
active discovery using SDP over BR/EDR

* Can you unambiguously identify the resource being served with CoAP to 
point to the correct 16-bit handle, uuid, ble address and so on so that 
any other CoAP end point might retrieve the resource regardless of what 
transport is being used?

I don't have any empirical evidence to support one approach over the 
other, in terms of performance, signalling, efficiency, etc 
unfortunately. However, at least until the 6LowPAN over BLE work is 
finalised and standardised, perhaps there's a larger number of devkits 
/sdks supporting service prototyping over GATT?

Regards,
Bill

-- 
| Bilhanan Silverajan                       Tel: +358 (0)40 849 0757 |
| Tampere University of Technology, Finland                          |

---

From: "Golnaz KARBASCHI" <[email-masked]>
Date: Thu, 16 May 2013 11:07:07 +0200

Hello, 

I totally agree that in the standard of IPV6 over BLE is the best/fastest
approach for having an end-to-end standard and http friendly connections all
over the network. 

So I think, in our use case, before finalizing 6lowpan over BLE and having
commercial sdks on the rfc, as Carels mentioned too, it seems that the best
choice is using the existing GATT/ATT over our BLE peripherals, as it gives
us bidirectional signaling (client server structure) and the big advantage
of already standardized protocol. Well, of course we miss the opportunity of
having direct internet connections all the way on our LowPan.

Best regards,

Golnaz 

De : Teemu Savolainen [mailto:[email-masked]] 
Envoyé : mercredi 15 mai 2013 13:52
À : Golnaz KARBASCHI
Cc : [email-masked]; Rahman, Akbar; Carsten Bormann
Objet : Re: [core] Running CoAP over a local BLE network

.. I do not think this to be sound reason, as highly likely IPv6 over BLE is
standard faster than any other standardized approach for transmitting CoAP
over BLE.. All other approaches would start from scratch in BT SIG and by
the time process has been gone through, IPv6 would be out of the pipeline
already.

Best regards,

Teemu

---

From: "Golnaz KARBASCHI" <[email-masked]>
Date: Thu, 16 May 2013 11:23:36 +0200

Hi Bill, 

The advantage of deploying CoAP over BLE (assuming L2CAP) is that L2CAP
semantics and behaviour can mimic that of UDP. It's trivial to implement
this in lab-based proof of concept prototypes. Unfortunately as discussed
earlier, it's not something that can be realistically deployed in products,
for all the reasons mentioned.

[Golnaz] right ! I agree !

CoAP over 6LowPAN adaptation layer over BLE, or CoAP over GATT over BLE. 
In both cases, an adaptation layer will be necessary for standards
compliance and will introduce overhead and possibly an overlap of
functionality, either with the underlying BLE stack or with how resources
and attributes are represented. So it's either end-to-end IP or end-to-end
REST, depending on which you prefer.

[Golnaz] I think, if we can, end-to-end IP is the better solution, specially
if having end-to-end REST is not free to get and needs manipulation for
integrating CoAP into GATT services. Then, in some scenarios, like ours,
some nodes cannot take advantage of having direct IP connections. I think in
this case, for choosing one of these approaches the best way is comparing
the applied overhead and duplications and efficiency by each of them. After
all, both still remain prototyping solutions before deploying in real
products.   

regards,
Golnaz