Bluetooth Application Layer development on Nexus Channel

Our first topic!
Here is a discussion that was already happening in emails about developing a Bluetooth Application Layer leveraging the existing Nexus Channel work by Angaza.

I’ll highlight a few distilled points from a recent email thread with Vaibhav that may be useful.

Nexus Channel Core is the application layer standard (a direct subset of OCF) that defines how devices expose resources to one another, and how that data is communicated between devices at the presentation layer (via CBOR, also specified by OCF). Application developers on any device (from Cortex-M0 based MCUs to full fledged laptops or smartphones) are able to implement standard ‘resource models’ for common functionality. An introduction of these ‘models’ can be found here: Nexus Channel Models, and the spec for writing a new resource model is here for developing a new resource model. That spec has certain conventions in place (entire resource representation in CBOR < 120 bytes) intended to ease use over the OpenPaygo Link wired connectivity between devices (and ensure that the largest number of devices implementing Nexus Channel Core could also read/interact with the same resource). Assuming the underlying link layer was OK transporting more data, you could of course increase the amount of data exposed by a single resource to a GET request.

Nexus Channel Core makes no assumption of cloud connectivity (does not expect or require a device to ‘talk to a central server’), and requires only a way to communicate data between devices in the field to function.

There is also an application security layer Angaza offers on top of “Nexus Channel Core”, when that security layer is used, the resulting solution is referred to as “Nexus Channel”. Basically, it defines a few new security-oriented resources (to manage cloud-driven, ‘secured links’ at the application layer between devices). It also allows sending custom commands from a server to a ‘controller capable’ device (typically via a token/keycode) which allows it to interact with other ‘accessory capable’ devices nearby to establish a secure link. Once the secure link is established, the devices can interact with one another ‘securely’ (messages are authenticated, replay attacks are prevented, etc). This is accomplished by introducing a security-layer between the incoming messages (GET/POST) and the eventual ‘resource’ they are heading to, and checking if the resource
is secured, and if so, ensuring the link is established with the requesting device, and the message is valid (authenticates using the link security key/info). This, combined with a PAYG Credit resource that only allows ‘POST’ requests from ‘linked/secured’ controller devices, enables certain PAYG use cases.

Just like Nexus Channel ‘security’ adds some context at the application layer (the notion of ‘controller’ and ‘accessory’ capable devices, and ‘secured links’ between them, as well as ‘securing’ GET or POST requests to certain resource types), other application level functionality can be layered on top of Nexus Channel Core. Nexus Channel Core focuses entirely on enabling devices to share application-level information in a common language (CoAP GET/POST to standard resource models definitions implemented by other devices, which return a CoAP response). The presentation layer is specified (CBOR) as well as partially a network layer (devices implementing Nexus Channel Core devices may have Nexus IDs, which can be represented as a permanent, universally valid IPV6 address - allowing devices to send commands to specific other Nexus IDs). There is a valid registered block of addresses in ARIN which can be used for applications that need to provide globally-unique and valid addresses to Nexus Channel Core devices (such as a server wanting to send a command to a ‘specific’ device running Nexus Channel Core - if it knows the Nexus ID of the target device). This also allows for use cases where a gateway might share the ‘connected’ Nexus Channel IPV6 addresses with an authorized server, to indicate what specific devices are conncted. Those IPV6 addresses could also be exposed by the gateway to allow a server to ‘communicate via HTTPS to an IPV6 address’ to the gateway, which then translates the messages down into Nexus Channel Core to send to the devices.

Its important to note that Nexus Channel Core is separate from the link and transport layers that connect devices (whether wirelessly or wired), and relies on some standard connectivity at that layer between the devices - in order to transmit application-layer messages between them. OpenPaygo Link is our current recommended wired link and transport layer, and we’d be interested in exploring how OpenPaygo Airlink could serve an equally important role as the standard link/transport layer for Bluetooth devices implementing Nexus Channel Core application layer resource interoperability.

Hey Josh
thanks for joining the community and posting the recap, really appreciated!

Would this be the fc00::/7 space? Or has Angaza specifically requested an addressing space for its iot devices on the global internet?

Further, is there value in maintaining a device registry specific to this interoperability initiative?

Would this be the fc00::/7 space?

While fc00::/7 is intended for private/local use the Nexus CIDR block is actually a public, globally addressable /48 block. You can check out the registration details for the “Nexus” IPV6 block via a whois:

 whois 2620:89:6000:0:0:0:0:0

You should see something like:

NetRange: 2620:89:6000:: - 2620:89:6000:FFFF:FFFF:FFFF:FFFF:FFFF
CIDR: 2620:89:6000::/48
NetName: NEXUS
NetHandle: NET6-2620-89-6000-1

If devices choose to implement Nexus Channel Core, they can have globally unique Nexus IDs which are also able to be made into globally unique, completely legal IPV6 addresses, allowing global addressing of devices without any NAT (of course, assuming the devices are internet connected, which many devices are not at this stage).

Nexus IDs are composed of 6-bytes (48 bits) split into two parts (described more below), and can be converted into a valid IPV6 address using EUI-64 expansion (same as MAC address expansion, described in RFC 2373).

The ‘who sent it’ is answered by each device having a “Nexus ID”, generally a permanent ID which is burned in at time of production (doesn’t matter how, but it does need to be globally unique). The Nexus ID is 48-bits, split into the following format:

  • Upper 2 bytes: uint16_t value representing " authority id"
  • Lower 4 bytes: uint32_t value representing 'device_id"

The general concept is that an ‘authority ID’ maps back to some party which is guaranteeing there are ‘no collisions’ within that ID space, so there won’t be any two devices with the same authority ID and device ID globally (generally speaking, although see authority ID 0xFE80 below for a special exception which is not intended for universally unique use).

The ‘authority IDs’ that are defined so far are:

  • 0xFFFF = reserved for development/testing (anyone can use or make IDs in this space in a pre-production/testing context)

  • 0x0000-0x00FF = reserved for core ‘GOGLA related’ use cases currently, including a ‘globally unique’ PAYG ID scheme. Authority IDs in this range are authorized to translate their Nexus ID into a globally valid IPV6 address within the Nexus CIDR block.

  • 0xFE80 = reserved for dynamically assigned Nexus IDs (e.g. nexus IDs that aren’t globally unique, e.g. if your link layer has a scheme where it dynamically assigns identities to devices that have no factory assigned ID or outside world mapping to those device IDs, you can use this authority ID). Selected to be semantically

  • 0xFFxx = Currently reserved as a special ‘broadcast designator’, that is only used as a destination address when a Nexus Channel Core device is broadcasting. May be ignored (in most cases, it will just translate to whatever ‘broadcast’ address/scheme is used by the link layer). The bottom byte is variable ‘xx’ so that in the future, its possible to add some scope context to the multicast if required (right now, the reference implementation uses 0xFF02, assuming something similar to a ‘link local’ broadcast, so we chose to stay semantically similar to the IPV6 spec, even though a bare Nexus ID isn’t an IPV6 address…). But again, we’d expect most link layer implementations to just see ‘authority ID begins with 0xFF, ok, this is a broadcast’ and ignore the rest. (the API also includes a ‘broadcast flag’ so the dest address can just be completely ignored in that case, as well).

Further, is there value in maintaining a device registry specific to this interoperability initiative?

I suspect so! For the specific universal PAYG ID use case, we’re working with GOGLA to make the existing work around universal PAYG IDs more widely available. Its certainly possible there is value in another, non-PAYG related device registry also leveraging the Nexus ID scheme.

However, do you mean a device registry related to permanent Nexus IDs (/IPV6 addresses), or device as a model that collects a certain ‘set’ of ‘resource types’ (e.g. a ‘fridge’ is a device that implements the ‘temperature’ and ‘capacity’ resources, or something like that)?

This diagram from the documentation submitted to ARIN for the Nexus IPV6 block may be helpful as well - it explains how even though the devices on a local network might not speak ‘IPV6’, a gateway can still be “IPV6 aware” and translate the “Nexus ID” of devices on the local network (on a constrained link/transport layer) to “IPV6” for addressing by the outside world, by placing those 48-bit Nexus IDs into valid IPV6 addresses in the Nexus CIDR block.

(Of course, since the ARIN block wasn’t granted at this point, the diagram shows a nonsense “2001:db8:1234” space, the actual Nexus granted block is 2620:89:6000).

Thanks for this great set of information. What types of use cases are foreseen/in use for PAYG/IoT devices that require them to be on the global internet?

Hi Vaibhav,

Essentially, the representation of the Nexus ID in IPV6 its just a convenience to allow the devices to have an IPV6 if there are other use cases (perhaps unrelated to PAYG at all) on the device that a developer might want to have a unique address to identify a device by. Because there is already space purchased and allocated for the purpose, its possible to choose to just use the Nexus ID directly as an IPV6 address (rather than needing to purchase or otherwise obtain a separate block for the same end result).

In the drawing above, it should also show how the Nexus ID can be used as a link-local unique IPV6 as well (allowing use of the ID as a direct way to address devices for systems that are already connected in a way that supports IPV6 addressing, e.g. something like RFC 7668 IPV6 over BLE)

I don’t foresee any immediate uses of a globally unique IPV6 address for PAYG use cases (as most of what we’re seeing so far are devices either directly connected to a specific backend, or via a gateway to the same effect, and ‘accessing’ the device is typically through some interface on that backend/server).