e, for example, IPv6-only capable wearable heart rate monitors, temperature sensors, cameras, and SO forth. This can place requirements for supported radios and tethering software. Future of IPv6 in 3GPP Networks Even though connectivity to smart objects may be provided by handset type of UEs, there will also be UEs that are more of the gateway-like entities (e.g., fixed to a building, to a vehicle, or such like). In any case, the smart objects may be using many kinds of (low-power) radios, like WLAN, IEEE 802.15.4, Bluetooth Low Energy, or Near Field Communications (NFC), in addition to wired connectivity methods, that may bring additional hardware requirements for the UEs. The IEEE 802.15.4, though, is not intended for mobile use and hence such radio would be supported effectively only by the UEs of fixed type. To provide Internet connectivity IP-wise, a UE has to provide some sort of IPv6 tethering services, as described in Section 4.7.5, and in some cases also IPv4 tethering using the common means such as IPv4 NAT. Providing connectivity for IPv6-only smart objects, however, brings a possibly significant problem: what if the mobile UE does not have IPv6 connectivity due to home, or visited, network not supporting IPv6? The set of solutions for those cases includes at least host-based IPv6 to IPv4 protocol translation, host-based double protocol translation, and IPv6-over-IPv4 tunneling. Active research is ongoing to tackle this issue and there are currently no definite solutions. The UEs interested in accessing services provided by IoT may need to be able to talk new protocols, such as CoAP. This can bring additional requirements for the IP suite UEs implement, and for the applications as well. For example, a web browser may need to be enhanced with CoAP in order to to be able to access smart objects. 6.5.5 Implications to 3GPP Networks The millions, if not billions, of new smart objects with 3GPP modems will definitely have implications for 3GPP networks. Even more, if the smart objects themselves do not hap