To run TCP/IP (v4 or v6), 802.11 WiFi has definate advantage. It is designed to run TCP/IP from the beginning.
802.15.4 Zigbee lagged behind, because of their 128-byte frame length is not efficient to run TCP/IP. They came up with 6LowPAN (compressed / shortened IPv6 header) as temporally solution, later they announced improved 802.15.4g standard to catch up, which can handle up to 2048-byte frame.
TCP/IP on Bluetooth has been "adopted chiild". Early LAN profile was disaster and soon abandoned. PAN profile (aka BNEP) was not great success neither (How many people scratched your heads by weird accronyms like PANU, NAP or GN?). Official "IPv support" on BT4.1 is good foundation, but it is still just a foundation. As long as I've read Core Spec 4.1 document, no detail of IP-over-BT specification (such as how to implement IPv6 Neighbor Discovery on BT) defined there. Only two "IPv6" strings found in 2684 pages of doccument.
I'm not deeply involved with Bluetooth stuff. Perhaps well-defined IPv6 over Bluetooth LE specification exists somewhere I just don't know...
I think Bluetooth 4.1 is a much needed improvement that lays a firmer foundation for devices with IPv6 communication. Bluetooth Smart with the coming addition of IP connectivity may make it fundamental wireless link in the Internet of Things.
In my understanding the brand name "Bluetooth Smart (Smart Ready)" is effort to solve initial confusion between "Bluetooth LE" and "Bluetooth 4.0" as well as compatibility issue. Often misunderstood that "Bluetooth 4.0" = "Bluetooth LE", but Bluetooth mode (BDR, EDR, +HS, LE) are independent from Bluetooth versions. Simple version designation - "Bluetooth 4.0" does not necessary mean it has low power mode (LE), but it COULD have high-speed mode (+HS). In order to clarify Bluetooth product specification, you must write version and mode separately - like "Bluetooth 4.0 BDR/EDR/LE". It is rather handful, not many Bluetooth product catalogs are written in that way.
Worse, "Bluetooth 4.0" product MAY or MAY not have intercompatibility because it could be "Dual mode" or "Single mode". Dual-mode device have BDR (possibily EDR too) and LE mode, but single-mode device have either BDR or LE mode only. Certainly dual-mode devices are compatible, but single-mode BT4.0LE device is not compatible with single-mode BT4.0BDR/EDR device. It is confusing, at least for me.
So, Bluetooth SIG decided to give more easy-to-understand designation. "Bluetooth Smart" is single-mode Bluetooth LE device, "Bluetooth Smart Ready" is dual-mode Bluetooth device. "Smart" device works with "Smart" or "Smart Ready" products, but not with legacy Bluetooth product.
I agree, I have always referred to it as BTLE, but Smart it is "In 2011, the Bluetooth SIG announced the Bluetooth SMART logo scheme, intended to clarify compatibility between LE devices." source http://en.wikipedia.org/wiki/Bluetooth_low_energy#Bluetooth_Smart_branding
I don't know how I missed ever hearing it referred to as "Bluetooth Smart," but from a marketing point of view, I think "Bluetooth Low Energy" or LE works better. For consumers considering fitness gadgets or other wearables, "low energy" is a more attractive sounding feature (long batter life) than "smart." In fact, many consumers probably associate "smart" with short battery life -- as in their smartphones. Yes, they are smart, and because they're so smart, the battery doesn't even last all day.
BLE has become a de-facto standard for many mobile devices, smart watches and wearbles monitoring the health also. This trend will continue and push BLE into many more consumer electronics in the future and may become prominent technology of IOT. inter mobile communication.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.