Ports of Call

How MBIM will help the development of the M2M industry

Posted by Greg Scaffidi
Greg Scaffidi
 
User is currently offline
on Friday, 09 March 2012
in MBIM

For those of you wondering just what the M2M industry is and why it matters, here's a little background information. M2M stands for Machine to Machine, and refers to communication technologies that allow intelligent systems and intelligent devices to share information. Applications of M2M technology run the gamut from smart appliances, remote telemetry, and utility metering to intelligent manufacturing systems, robotics, and automated roadways. In fact, there's almost no limit to where M2M technology can be applied. As a growth industry, M2M is forecasted to be worth around $750 billion with billions of devices by 2015. With the advent of MBIM 1.0, wireless network controller nodes will be developed that can each control and service literally thousands of intelligent devices.

How is this possible? One of the basic features that MBIM provides is the ability to transport up to 256 simultaneous "raw" IP (both IPV4 and IPV6) and Device Service streams (DSS) over a single USB interface. We'll discuss the concept and use of DSS in more detail in a future posting. For the purpose of this article it suffices to say that DSS enables the use of proprietary protocols and data streams over a standard transport medium (i.e. MBIM). Given that a single USB device can support up to 15 endpoints and a MBIM interface requires 3 endpoints, a single USB device could support up to 5 MBIM interfaces which translates to 1280 simultaneous dedicated connections. Since each USB host controller can manage up to 128 devices and the number of USB host controllers in each system is limited only by the number of available slots, it will be possible to theoretically control a staggering N * 163840 connections from a single system (where N is the number of USB host controllers installed in a system). This enables M2M applications to easily manage a large number of connections. When we include the fact that many types of M2M devices are commonly managed without the need for dedicated data streams through the use of SMS (which is natively supported by the MBIM 1.0 specification), the advantages of MBIM as a key M2M backbone technology become readily evident.

For those of you wondering just what the M2M industry is and why it matters, here's a little background information. M2M stands for Machine to Machine, and refers to communication technologies that allow intelligent systems and intelligent devices to share information. Applications of M2M technology run the gamut from smart appliances, remote telemetry, and utility metering to intelligent manufacturing systems, robotics, and automated roadways. In fact, there's almost no limit to where M2M technology can be applied. As a growth industry, M2M is forecasted to be worth around $750 billion with billions of devices by 2015. With the advent of MBIM 1.0, wireless network controller nodes will be developed that can each control and service literally thousands of intelligent devices.

How is this possible? One of the basic features that MBIM provides is the ability to transport up to 256 simultaneous "raw" IP (both IPV4 and IPV6) and Device Service streams (DSS) over a single USB interface. We'll discuss the concept and use of DSS in more detail in a future posting. For the purpose of this article it suffices to say that DSS enables the use of proprietary protocols and data streams over a standard transport medium (i.e. MBIM).

Given that a single USB device can support up to 15 endpoints and a MBIM interface requires 3 endpoints, a single USB device could support up to 5 MBIM interfaces which translates to 1280 simultaneous dedicated connections. Since each USB host controller can manage up to 128 devices and the number of USB host controllers in each system is limited only by the number of available slots, it will be possible to theoretically control a staggering N * 163840 connections from a single system (where N is the number of USB host controllers installed in a system). This enables M2M applications to easily manage a large number of connections. When we include the fact that many types of M2M devices are commonly managed without the need for dedicated data streams through the use of SMS (which is natively supported by the MBIM 1.0 specification), the advantages of MBIM as a key M2M backbone technology become readily evident.

Below is a simple block diagram illustrating a possible MBIM Wireless M2M controller implementation.

M2M Controller.png

Here is another block diagram illustrating a possible standalone embedded MBIM Wireless M2M controller implementation. This type of controller can be deployed where autonomous control is desired. Of course, these standalone controllers could also be integrated into a larger network of M2M nodes...

M2M Standalone.png

Depending on the requirements of the M2M application, each communication channel with a M2M device can be assigned a separate session ID associated with a corresponding "raw" IP data stream. Alternatively, for non-IP based communication channels, a DSS session ID can be assigned and associated with a proprietary protocol and data stream. M2M software applications and services can establish a connection with M2M devices represented by a specific Access Point Name (APN) through the use of the MBIM services defined by the following Command Identifiers (CIDs):

  • MBIM_CID_CONNECT
  • MBIM_CID_DSS_CONNECT

These features allow MBIM to support multiple dedicated data streams where high frequency command and control telemetry and/or high bandwidth data transfers are necessary.

For simpler, low bandwidth applications, SMS messages are commonly used to communicate with M2M devices. Support for SMS is native to the MBIM 1.0 specification allowing an easy migration path for any existing SMS-based M2M applications and a robust framework for the development of new ones. The MBIM 1.0 specification defines the following SMS related CIDs:

  • MBIM_CID_SMS_CONFIGURATION
  • MBIM_CID_SMS_READ
  • MBIM_CID_SMS_SEND
  • MBIM_CID_SMS_DELETE
  • MBIM_CID_SMS_MESSAGE_STORE_STATUS

For more information on the MBIM 1.0 specification please see Mobile Broadband Interface Model (MBIM) V1.0

For more information on the M2M industry here are some links that you may find helpful:

http://m2m.com/index.jspa

http://www.tiaonline.org/standards/committees/committee.cfm?comm=tr-50

http://www.tiaonline.org/standards/mstf/index.cfm

http://www.connectedworldmag.com/

If you've read this far, I hope to have at least piqued your interest in this potential application of MBIM technology. Until next time...

Tags: MBIM
Hits: 3932 1 Comment

MBIM Device Services and why are they important

Posted by Greg Scaffidi
Greg Scaffidi
 
User is currently offline
on Tuesday, 10 January 2012
in MBIM

The MBIM 1.0 specification defines support for something called "Device Services".  The label of "Device Services" is a catch-all applied to any traffic that it is not IP-based.  Essentially, MBIM accommodates the transfer of virtually any type of protocol and payload over a standard transport mechanism.  If you think about it, this is a very powerful concept.  Up until now, USB devices that contained multiple functions had to expose each of those functions through a separate USB interface.  For example, a typical broadband device might have a call control/device management interface, a network interface, a GPS interface, and a diagnostic interface.  This could consume as many as eight to ten USB endpoints and require three to four different host drivers (not including the composite driver) to be involved in managing the device.  With the advent of MBIM Device Services the endpoint count can be reduced to three and the required host drivers can be reduced to one MBIM class driver that handles call control, device management, and network data transfer, with the GPS and diagnostic functions handled by services and/or applications communicating directly with their respective device services.  The reduced endpoint count translates into reduced cost for the device manufacturer.  The reduction in required drivers translates into less complicated installation, reduced risk of driver related issues, and a better user experience.  This combination can only affect time to market considerations in a positive way.

One of the reasons this is possible to achieve is because MBIM supports the concept of simultaneous connections to multiple DSS sessions.  Each MBIM device function can support up to 256 different Device Services.  In addition, if the MBIM device function advertises support for it, multiple instances of the same Device Service can be opened by the host.

The MBIM 1.0 specification defines the following Device Services related CIDs:

MBIM_CID_DEVICE_SERVICES

Used to retrieve a list of all the device services supported by the MBIM device function and their associated properties as defined by the MBIM_DEVICE_SERVICES_INFO and MBIM_DEVICE_SERVICE_ELEMENT structures.  The MBIM_DEVICE_SERVICES_INFO structure specifies the number of MBIM_DEVICE_SERVICE_ELEMENT structures (one per device service), the maximum number of activated DSS sessions (up to 256) supported by the device function, an offset/length pair list identifying each of the MBIM_DEVICE_SERVICE_ELEMENT structures, and the array of MBIM_DEVICE_SERVICE_ELEMENT structures itself.  Each MBIM_DEVICE_SERVICE_ELEMENT structure specifies a UUID which uniquely identifies the device service stream, whether the service transports a data payload, the maximum number of instances of this service supported by the device function, the number of DSS specific CIDs for this service, and a list of the DSS specific CIDs.

 

 

MBIM_CID_DEVICE_SERVICE_SUBSCRIBE_LIST

Used to inform the device function of the specific CIDs for which the host wishes to receive unsolicited even notifications via MBIM_INDICATE_STATUS_MESSAGE as defined by the MBIM_DEVICE_SERVICE_SUBSCRIBE_LIST and MBIM_EVENT_ENTRY structures.  The MBIM_DEVICE_SERVICE_SUBSCRIBE_LIST structure specifies the number of MBIM_EVENT_ENTRY structure elements contained, an offset/length pair list identifying each of the MBIM_EVENT_ENTRY structure elements, and the array of MBIM_EVENT_ENTRY structure elements itself.  Each MBIM_EVENT_ENTRY structure specifies the DSS UUID uniquely identifying the device service associated with the desired list of CIDs, the number of desired CIDs, and the array of desired CIDs.

 

MBIM_CID_DSS_CONNECT

Used to activate and deactivate a DSS session as defined by the MBIM_SET_DSS_CONNECT structure.  The MBIM_SET_DSS_CONNECT structure specifies the DSS UUID uniquely identifying the desired device service, the DSS session ID that uniquely identifies the session for the device service stream, and whether to activate or deactivate the session.

Because the MBIM 1.0 specifications allows for the flexibility of defining custom CIDs for DSS implementations, it is possible to convert virtually any protocol into a DSS equivalent.  Whether there's a need to transport existing non-IP based protocols and/or completely custom protocols, there's practically no limit to what can be accomplished using this feature of MBIM.

Below is a simple block diagram illustrating a possible MBIM Device Services implementation.

MBIM Dev SV.jpg

For more information on the MBIM 1.0 specification and Device Service Streams please see Mobile Broadband Interface Model (MBIM) V1.0

Perhaps in a future blog we'll discuss a specific DSS implementation.  Until next time...

Tags: MBIM
Hits: 5809 0 Comments
Legal and Copyright Information