Tag: Zigbee

Some Questions After Quad-Play

mustnotgrumbleLeave a comment

I work as an architect at a big telco that has recently become a quad-player. Part of my job is to think of what services come next. My previous interest has always been distributed computing, either networking or large data-sets. Also as part of my job I attend IT conferences on the internet of distributed devices.

My key questions & my current thoughts are:

  • What will become the distributed identity standard for device authentication?
    • OpenID Connect (OIDC) (like SAML) is not an AuthN mechanism but extends the OAuth2.0 model. The identity attribute API can be used for profile loading to define a user’s identity onto the device. This can be a lightweight equivalent of a SIM Profile & also support the eUICC flows for ownership switch (similar to a Profile Content Update Function)
    • Any AuthN & identity solution must support the limitations of loading profiles on smaller memory devices & requiring an authN flow over HTTP.
  • What will be the numbering & addressing standard for massively distributed devices?
    • This is more of an open question relating to the history of the service so that eUICC enabled devices will require an international mobile subscriber identity and LPWA & WIFI enabled devices will require a MAC addressing / IPv6 registry with the service provider.
    • The support for these addressing mechanisms and near field communication devices will have an impact of the network operator’s OSS IT architecture.
    • The GSMA proposal for eUICC uses the START-IMSI required for profile loading which supports roaming and allows for profile swap on change of ownership.
    • IPv6 offers a highly scalable address scheme. It provides 2128 unique addresses, which represents 3.4 × 1038addresses.  In other words, more than 2 Billions of Billions addresses per square millimetre of the Earth surface. It is quite sufficient to address the needs of any present and future communicating device.
    • 6LoWPAN provides a simple and efficient mechanism to shorten the IPv6 address size for constrained devices
  • Will the smart device co-ordination be through an embedded chip-set in the main home internet router?
    • Probably not but I would have said probably not 5 years ago and I still have not seen Zigbee co-ordinators or Thread border routers catch on as stand-alone devices.

I’ve not been blogging for a while, too much work is not an excuse, but will be updating more on these topics soon.

A Common Service Layer for M2M & The Challenge of AAA for Smart Devices

mustnotgrumbleLeave a comment

The Internet of Things, as distinct from the internet of people, requires communication between devices to enable home automation, telematics and health care monitoring. This intercommunication is dependent upon semantically structured and shared data for enabling functions such as identification, authentication, authorisation, bootstrapping and provisioning. Standardising both the semantically structured data and the enabling functions across M2M applications and devices would reduce the cost and extend the life of M2M devices. Standardisation for the Internet of Things is the aim of a common service layer for M2M.

There is no single internet definition for the Internet of Things, but to function as a network “Things” must have representation within the Internet. This representation includes structured data (e.g., status, capabilities, location, measurements) which needs to be semantic in order to be shared, processed and acted upon. The sharing and discoverability of information requires governance according to privacy settings and access rights. Because the Internet of Things (IoT) requires M2M application and device communication within minimal or no human involvement these privacy settings and access rights need to represent the delegated authority of the human user. Therefore M2M devices require bootstrapping of provisioned M2M service credentials (e.g. identities, M2M Root Key) which can be used for connecting and registering with different service layers and service authorities.

M2M devices can be active such as Zigbee sensors or passive such as RFID tags. M2M devices can be connected to an MNOs network using eUICCs or can be connected to an IP extending personal area network (e.g. Zigbee gateway). The ETSI principles for M2M & smart device communication are RESTful resource oriented APIs that are IP based but interwork with specific IP and non IP technologies in the M2M Area networks. The variance between device communication mechanism (IP & non-IP) and behaviour (passive vs active) makes defining an embeddable M2M common service layer a challenge.

The oneM2M group aims to develop technical specifications that address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M application servers worldwide. The common M2M Service Layer should be agnostic to underlying network technology (yet leveraging the unique features of these underlying networks), and it will use network layer services (such as security (encryption and authentication), QoS, policy, provisioning, etc.) through an adaptation layer/APIs.

The challenge for Authentication, Authorisation & Accounting in M2M will be to build trust between the human user and the delegated authority to the M2M device.  In order for an embedded common M2M service layer to operate it must support AAA (authN, authZ & accounting) for smart devices using an agreeable mechanism between multiple device manufacturers and network operators. The Telecommunications Industry Association are defining a functional standard for Authentication, Authorization and Accounting for Smart Device (AAA-SD TIA) which is encapsulated in TIA TR-50 Functional architecture for M2M Smart Device Communication System Architecture  describes AAA-SD as ” provide authentication, authorisation and accounting services to other entities in the network to establish and enforce security policies. The services may include generation of keys, generation and validation of certificates, validation of signatures, etc”. The functions proposed by the oneM2M service layer must align with TIA TR-50.