This paper is a postprint of a paper submitted to and accepted for publication in IET Wireless Sensor Systems and is subject to Institution of Engineering and Technology Copyright. The copy of record is available at IET Digital Library
Special Issue on Use of Cellular Technologies in Sensor Networking
Optimizations in Machine Type Communications for Sensor Data Networking Syed Husain1, Athul Prasad2, Andreas Kunz3, JaeSeung Song4*, Takeshi Koshimizu1 1
NTT DOCOMO, Tokyo, 100-6150, Japan Nokia Networks, Espoo, 02610, Finland 3 NEC Laboratories Europe, Heidelberg, 69115, Germany 4 Sejong University, Seoul, 143-747, Korea Email: *
[email protected] 2
Abstract: Currently, many sensor data networks are managed using Machine-to-Machine (M2M) or Machine Type Communications (MTC) technologies. One of the key factors for the success of sensor data networks is in developments of international M2M/MTC standards. As 3GPP and oneM2M are actively working on standardizing M2M/MTC specifications for 3GPP core networks and M2M common service layer, this paper reviews the ongoing activities in 3GPP and oneM2M standardization bodies, in the area of machine type or machine-to-machine communications, focusing on enhancing device, service platform, and mobile network technologies that can be useful in achieving cost efficiencies in sensor data networks. 1. Introduction The sensor data networks are managed using machine-to-machine (M2M) or Machine Type Communications (MTC) technologies. One of the key requirements of future sensor data networks is the need for low-cost devices (also called user equipment (UE) in 3GPP) that can be managed efficiently both at the application layer and the network control layer [1,2]. Therefore, many researchers in academia are investigating different mechanisms that can manage M2M/MTC (e.g., sensor) devices efficiently [3,4]. For example, Jin et al., develop a scheduling algorithm that can analyse remaining energy and recommend the best batteries to work with [5], and Das et al., design correlation-aware cross-layer to manage a complex sensor networks with various available information that span multiple layers [6]. Together with such efforts in academia, there is considerable amount of effort ongoing in 3GPP and oneM2M standards organizations to further enhance the device, network, and service platform technologies beyond what has been accomplished up to Rel-12 [7,8] that would be conducive for adoption in sensor networking. In this paper we present the ongoing work in 3GPP and oneM2M on a number of projects in the area of M2M/MTC. Section 2 presents the ongoing work in 3GPP and oneM2M on MTC/M2M enhancements. Section 3 provides interesting use cases on interworking that show how the mobile network can be optimized through sharing configuration values with the services platform. Section 4 has been included to show how the 3GPP network resources can be optimally used when information about the ongoing
1
behavior of UEs from 3rd party platforms is made available. Finally, Section 5 provides the summary and conclusions. 2. MTC/M2M Enhancements 3GPP and oneM2M are actively working on standardization for MTC/M2M technologies. In particular, 3GPP is focusing on supporting M2M features to 3G/LTE devices, and oneM2M is standardizing common service layer platform for M2M. In this section, we introduce their latest standards activities.
2.1. In 3GPP Release 13
Currently, 3GPP is working on several enhancements related to MTC in Rel-13 from both a radio communications perspective [9,10,11,12,13,14] and system architecture perspective [15,16,17]. In the recent past, 3GPP radio access network (RAN) working group proposed several new enhancements for MTC low-cost devices (useful in deployment of sensor networks) such as power preference indicator, RAN overload control, new UE categories (called Cat-0), enhanced power saving modes, and UE assistance information for parameter tuning [10]. These enhancements were already studied in previous releases but further improved in Rel-13 and provide the much needed features in coverage and power savings for low-cost devices. Low-Cost Devices (or UEs) [9,14]: Since LTE UE (or device) has been mainly designed for broadband services, a significant re-design is needed in order to support low-cost devices required for future MTC applications. The work already started in Rel-12, where the so called “Cat-0 UE” supports one receive antenna with reduced peak data rates of 1 Mbps and optionally operating in half-duplex mode. But for massive deployment of low-cost MTC devices in sensor networks, with low data rate and high latency requirements, a new category of MTC devices are planned to be defined in Rel-13. The capabilities currently envisioned for such devices include reduced device bandwidth of 1.4 MHz in both uplink and downlink, and reduced maximum transmit power constraints. The enhancements currently proposed for Rel-13 can enable an overall reduction in bill of materials cost of the wireless modem in the MTC device by about 68 % to 76 %, with a proportional reduction in the complexity of the device as well. Coverage Enhancement [9,14]: With reduced device complexity there is a natural degradation of coverage of the device. Hence, coverage enhancements are also essential for wide adoption of such lowcost devices since such devices would be deployed in indoor locations with poor coverage, such as basements, parking garages, etc. Having one receive antenna could cause up to 4 dB degradation in the
2
Application
Application
Application
API 1
API 2
...
API 3
API n OMA/ GSMA/ other SDOs
Service Capability Exposure Function (SCEF)
TRUST DOMAIN
3GPP Sh
HSS
Rx
PCRF
T4/ Tsms
SMS-SC/ GMSC/ IWMSC
Tx
Tsp
3GPP interface
ISC
...
MME/ SGSN
MTCIWF
S-CSCF
Network Entity
Fig. 1. 3GPP SCEF Architecture Framework [19]
performance of downlink channels, due to the lack of receiver combining and diversity gains, while the maximum transmit power reduction would lead to the reduction of uplink coverage of the device. Reduced system bandwidth could also lead to performance degradation due to lack of diversity gains. Some coverage enhancement mechanisms are also proposed for enhancing the coverage of low-cost LTE UE, such as relaxing the system performance requirements, multi-frame channel estimations, repetition/frame bundling, overhead reduction, increasing reference signal density, etc. Coverage enhancements would be scalable and configurable, while minimizing the amount of transmission and reception times per device. A mechanism for identifying the coverage range is also required for configuring the device with appropriate coverage enhancements. Device Power Saving [9,14]: In pre-Rel-13, power preference indicator (PPI) and power saving mode have been introduced in LTE-Advanced systems to reduce power consumption. The PPI enables the MTC device to inform the network that a low-power consumption mode is preferred. Mechanisms such as reduced measurements configurations and longer sleep times could be configured for the MTC device to reduce power consumption, and operate in the low-power consumption mode. The power saving mode enables the UE to remain registered to the network, but unreachable for downlink traffic. From the network perspective, the UE is considered to be in sleep mode and enter active mode only when there is uplink data to be transmitted or after expiration of a power saving mode timer. Such a mode is ideal for
3
MTC devices with infrequent uplink data traffic, such as remote sensing devices, smart grids, etc. In Rel13, MTC devices are also expected to send assistance information to the network about its traffic type or pattern, and the network will be able to configure radio resource related parameters based on this information. System Architecture Enhancements: Currently, several architecture enhancements for service capability exposure are currently being studied in 3GPP [16], which are essential for external 3rd party M2M application servers (AS) to access the 3GPP network, for provisioning various services. One of the key issues addressed is to define the service capability exposure function (SCEF) architecture framework (see Fig. 1), which identifies and defines the 3GPP service capabilities, and facilitates these service capabilities to be discovered by and exposed to trusted 3rd parties. The service capabilities include communication services (e.g., voice calling, short message service (SMS), multimedia messaging service (MMS) etc.), subscription services (e.g., subscription identity, feature sets, preferences, etc.), context information services (e.g., location, presence, profile, device capabilities, data connection type, etc.) and control information services (e.g., quality of service (QoS), policy, security, etc.). Some of the main functionalities of the SCEF include: x
Authentication and authorization
x
Policy enforcement
x
Discovery of exposed service capabilities
x
Assurance related to usage of Application Programming Interfaces (API)
x
Accounting
x
Access to external entities
x
Abstracting 3GPP network topologies from external entities 3GPP is also studying architectural enhancements required for providing monitoring service
capabilities according to service requirements. It was concluded that the monitoring capabilities could be accessed using different 3GPP interfaces or nodes (e.g., Home Subscriber Server (HSS) via enhanced Sh interface) or Mobility Management Entity (MME)/ Serving GPRS Support Node (SGSN) using a newly defined interface. Reporting of the same message using different interfaces could also be supported, for satisfying various usage scenarios (for e.g., with different frequencies of location reporting or varying location accuracy requirements, etc.). There are also various other studies ongoing on MTC enhancements in the 3GPP system architecture working group:
4
Infrastructure Domain
Field Domain
AE1
AE1
Mca
Mca
AE3
Mca
CSE1
To other service provider
CSE2
Mcc Mcn
Mcc’ Mcn
NSE1
NSE2
CSE2 creates resource for registered AE3
Fig. 2. oneM2M service layer high-level architecture
x
System impacts of extended Discontinuous Reception (DRX) cycle for the optimization of power consumption [18] - this study mainly targets the core network and non-access stratum (NAS). impacts in UE due to the extension of DRX cycle for both idle and connected mode, and aims to develop solutions in the core network to support this operation. Currently, various solutions for idle and connected mode DRX have been proposed and open issues are being evaluated.
x
System architectural enhancements for group based features [19] - this study investigates solutions for message delivery to a group of devices, which involves various key issues such as group message delivery, group based policy control, group-specific NAS level congestion control, and group-based addressing and identifiers. System architectural enhancements to support high latency devices unreachable for long periods of
time [17] - this study investigates packet discard for UEs in sleep mode, frequent retransmissions, increased load on the core network, waste of radio resources, etc. The two main scenarios considered in the study include downlink packet transmission to UEs in power saving mode, and coordination of maximum latency between applications and the network. 2.2. In oneM2M Release 1 and beyond
The oneM2M is a global standardization body for the development of a set of M2M and Internet of Things (IoT) specifications [1]. oneM2M was initiated by seven leading Information and Communications Technology standards development organizations (SDO): ARIB and TTC from Japan, ATIS and TIA from USA, CCSA from China, ETSI from Europe, and TTA from Korea. Currently more than 200 member companies are actively contributing to oneM2M.
5
Main objectives of oneM2M are (1) to minimize IoT/M2M service layer standards market fragmentation, (2) define a common service layer platform that supports network agnostic services and interworks with different existing M2M vertical systems [20], and (3) defines interfaces and APIs that can be built on devices, gateways and infrastructure nodes. The oneM2M common service layer platform is intended to be implemented on various hardware and software modules to allow a global scale end-to-end communication chain. oneM2M has published a suite of ten technical specifications as its first release (Release 1) [21,22,23,24,25,26,27,28,29,30], which includes requirements, architecture, API specification, security solutions, and protocol bindings for Hypertext Transfer Protocol (HTTP), Constrained Application Protocol (CoAP) and Message Queue Telemetry Transport (MQTT). In addition, oneM2M Release 1 contains device management specifications allowing the use of Open Mobile Alliance (OMA) and Broadband Forum specifications. As shown Fig. 2, the oneM2M functional architecture is comprised of three types of entities; (1) an Application Entity (AE) that consists of M2M application logic, (2) a Common Services Entity (CSE) that consists of a set of Common Service Functions (CSFs), and (3) a Network Services Entity (NSE) that provides inter-working with underlying networks. Interworking Support: A unique feature of the oneM2M horizontal service layer platform is interworking: x
Interworking via Mca reference point with vertical applications that can register themselves to oneM2M service layer.
x
Interworking via CSFs with various M2M service platforms such as AllJoyn [18] and LWM2M [31].
x
Interworking of various existing service functions and protocols such as BBF TR-069 [27,32], OMA DM [26], CoAP [28], HTTP [29], and MQTT [30].
x
Interworking via Mcn reference points with various underlying networks.
x
Communications over the Mcn reference point include message services, Network APIs defined by other SDOs, and various interworking service functions for MTC devices defined by 3GPP and 3GPP2. For example, through this interworking the CSE in a MTC device can send a connection requests with QoS requirements towards the 3GPP core networks.
6
Fig. 3. Network optimization through the exchange of configuration parameters
Communications Support: A Common Services Entity (CSE) consists of a set of Common Service Functions (CSF) which is an informative group of similar sub-functions such as security (SEC), Location (LOC), Communication Management and Delivery Handling (CMDH). In particular, CMDH is responsible for data delivery handling feature between oneM2M entities (e.g., the CSE and the AE, NSE or other CSE). This allows the M2M Service Provider to provide policies and communication/delivery request parameters for the usage of the underlying network. For example, a service provider can configure a gateway (i.e., MN) to collect all sensor data during the day and only forward the accumulated data set at 2 am in order to have saving on bandwidth and latency. Therefore, when these parameters are satisfied, the CMDH can buffer requests in order to forward the messages at a later time when the network traffic is lower. 3. Interworking Use Cases Generally many M2M services exchange small data packets (e.g., containing sensor data and commands) with their sensors and actuators. In particular, frequent transmission of M2M/IoT data from mobile devices to M2M/IoT services could cause network overload because the devices have to change their internal state between idle and connected state frequently. In addition, if mobile devices are operating with an always-on communication mode in which the device is kept in connected state and sends small data packets to its M2M/IoT services, these devices consume significant amounts of radio resources and battery power.
7
Fig. 4. Network optimization with mobility management parameters
In order to reduce the network load related to the frequent state transition and radio resources consumption, the mobile network (e.g., 3G and LTE) need to adjust its configuration parameters, such as the reception time interval, a timer keeping the connection, based on the type of M2M/IoT applications (e.g., frequent or infrequent data transmissions) running on the mobile devices. However, in general, such configuration values of M2M/IoT devices are configured on Service Layer, and not easily shared with the mobile network. In this section, we illustrate two use cases that show how the mobile network can be optimized through sharing configuration values. Flood warning system: Let us consider a M2M based flood warning system consisting of an application, a service platform, devices, and the mobile network. M2M devices collect its sensing data (i.e., water level of a river), and send the data to the M2M application through the mobile network. The M2M application analyzes the measured data to detect if the water level has become hazardous. If the water level exceeds a certain threshold, the M2M application sends a request to devices to increase communication interval and shares the increased interval to M2M service platform. The interval value is then further shared by M2M service platform with the mobile network to optimize the usage of the network resources. As shown in Fig. 3, according to the received interval value, the mobile network adjusts its configuration parameters, for example:
8
x
Connection keep timer (e.g., from “short” to “long”): This reduces the control load related to the frequent state transition.
x
Radio reception interval (e.g., from “normal” to “frequent”): The device switches to the abnormal c ommunication mode. Therefore, the mobile core network can allocate more radio resources to the M2M devices only
when the water level exceeds a certain threshold. Mobility management system: In general, M2M devices can be categorized into two mobility categories, namely, stationary device and mobile device. Many M2M devices have a permanent fixed location (e.g., sensors on a house). However, there exist devices that fall into both mobility categories because they change the status of their mobility characteristics. For example, a device in a car can be a stationary device when the car is parked, and at the same time it can be a mobile device when the car is in a driving mode. For the mobile network, it is important to know the status of mobility characteristics of a IoT/M2M device in order to use network resources efficiently. However, such characteristics are available on the device, and only be provided on the service layer. This use case illustrates how the service layer detects a change of mobility characteristics and shares the change with the mobile network by interworking between the M2M service platform and the mobile network. Let us consider a fleet management car scenario (see Fig. 4). There is an M2M device (i.e., in a car) that collects mobility related information from its embedded sensors. When the car is parked, and its engine is turned off, the device sends mobility related information such as engine on/off, navigation system on/off, and GPS data to the application server that serves a fleet management company. The application server then sends the current mobility characteristics (e.g., high mobility because the car has been moving) and the collected information (in this case, the engine off) to the M2M service platform. The service platform performs an analysis with the given information and detects the changes on the mobility characteristics (i.e., from high mobility to no mobility status). The service platform sends the detected changes to the mobile network. The mobile network adjusts its configuration parameters for optimization as follows: x
Traffic (paging) area (e.g., from “wide” to “short): Handover doesn’t need to be performed.
x
Location registration interval (e.g., from “short” to “long”).
Therefore, the mobile core network can reduce the usage of its network resources.
9
Fig. 5. SCEF interworking example
4. 3GPP Resource Optimization For interworking with external networks, 3GPP has specified a framework for the Architecture Enhancements for Service Capability Exposure (AESE) in TS 23.682 [15] within Release 13. This framework enables the exposure of 3GPP capabilities like communications, context, subscription and control to external service providers for value added services via an API, e.g., like from OMA or GSMA. The framework allows to identify and to define service capabilities as well as their exposure and the discovery of the exposed capabilities. For this reason, 3GPP defined the Service Capability Exposure Function (SCEF) to provide the above functionality (see Fig. 5). The SCEF interfaces to the application provider on one side and provides access to network capabilities and services of the underlying 3GPP network on the other side. One key issue resolved was the support of 3rd party interaction on information for predictable communication patterns for a UE or group of UEs. The service provider knows the behavior of the application of a specific UE or group of UEs depending on the different use case as described above, e.g., sensors that measure the water level of a river sending measurement every hour, but others e.g., in a train may send measurements or reports with much shorter frequency. The communication pattern comprises two different parts: a data traffic communication pattern characterizing the user plane traffic and a mobility communication pattern characterizing the movements of a UE. Parameter examples of the data traffic communication pattern include: x
indication whether the communication is periodic, e.g., every 24 hours, represented by a flag
x
average duration of communication, i.e., how long does the communication go on
x
average interval time between periodic communications, i.e., fixed time until the next scheduled
10
UE
eNB
MME
HSS
SCEF
AS/SCS
1. NOTIFY (Communication ti Pattern) P tt )
on-going signalling connection
2. Profile query Release
3. Profile answer
4. NOTIFY Response
5. Derive network parameter 6. CP parameters per UE UE is ECM-idle
7. CP parameters per UE 8. CN assistance data produced by MME
9. Service Request, S1 Connection & Radio Bearer Establishment CN assistance data provided to eNB by MME 10. The eNB may use assistance data to reduce signalling affecting the MME
Fig. 6. Core Network assisted eNodeB parameters tuning with Provisioning of network parameters
x
communication average amount of data per communication, e.g., expected data may be only a few KB depending on the service, like measurement data transmission.
Parameter examples of the mobility communication pattern include: x
indication whether the UE is stationary, i.e., a flag whether it is fixed installed at a specific place
x
location, if UE is stationary
x
mobility area where the UE moves around, i.e., if not stationary, the UE may move only in a certain region, e.g., bus service of a city where the busses never leave the city boundaries average speed, i.e., applies only to the non-stationary UEs.
x
This way of interworking and provisioning of the communication pattern enables many optimizations inside the 3GPP network. One example is also explained in the TR 23.708 [16], which uses the communication pattern to provide start values for the feature of core network assisted eNodeB parameters tuning. This feature enables the MME to estimate the average time of the UE states (CONNECTED/IDLE) as well as the mobility behavior of the UE. This information is then used to “tune” the eNodeB configuration. The Release 12 feature of core network assisted eNodeB parameters tuning is deriving the values from the actual UE behavior, but with this feature the service provider could give the
11
relevant communications pattern to the SCEF in order to pre-set the values to tune the eNodeB from the start. The call flow for this procedure is shown in the following Fig. 6: 1. The service provider notifies the SCEF about the CP for the UE or group of UEs. 2. The SCEF authenticates & authorizes the request and queries the HSS for additional information 3. The HSS provides the UE profile to the SCEF. 4. The SCEF acknowledges the notification back to the service provider. 5. The SCEF derives the relevant network parameters based on operator policy or configuration from the received request of the service provider and creates a CP for further processing. 6. The SCEF provides the CP to the HSS where they are stored in order to handle IDLE mode mobility scenarios with MME change until further updates from the service provider. 7. The HSS provides the CP to the serving MME. 8. The MME derives the CN assisted eNB parameters from the CP and takes also the local network conditions and local configuration into account and stores them until the Service Request procedure from the UE. The MME has now information about the average time the UE remains in ECM-CONNECTED and ECM-IDLE based on the received data traffic communication pattern, i.e., periodic communication indicator, communication duration timer, periodic time and average data volume per communication and from the current bearer characteristics (RAT type, QoS, etc.) of the UE. Furthermore the MME can derive the expected HO interval based on the information present in the received mobility communication pattern (stationary indication, mobility area, average mobility speed). The MME can use both parameters to minimize the ECM-CONNECTED state reduced for high mobile UEs. The CN assisted parameters derived from the CP are updated based on the statistics collected in the MME when the UE gets into ECM_CONNECTED mode. 9. The UE sends a Service Request message and moves into ECM-CONNECTED state. 10. The eNodeB may take the information from the MME into account in order to optimize signaling messages. 5. Future Work – Evolution towards Fifth Generation (5G) 3GPP and oneM2M standards are evolving towards satisfying all the requirements that would enable the massive deployment of IoT devices using cellular networks. Various evaluations done in [14,33] indicate that enhancements are required in standards to support the massive deployment of IoT devices, such as support for massive increase in device density, support for extremely low-cost and low power consumption devices, improved cell coverage along with these enhancements, etc. The current consensus
12
Fig. 7. Evolution of MTC towards 5G [25, 30].
in the standardization community is that the support for such massive deployment of MTC could be done as part of the evolution of LTE standards, as shown in Fig. 7 , which is based on the requirements presented in [14,34]. There are some key requirements for the support of ultra-reliable machine-type communications [34,35,36], which includes extremely low end-to-end latency of 5 ms including jitter, retransmits, etc., and high reliability with packet loss rates of 10-9 or 99.999 %. Such requirements would necessitate a re-design of the currently defined cellular networks, especially the access network. These enhancements are expected to be standardized as part of the 5G cellular network standards. The applications for such requirements include industrial automation which requires low delay, jitter, retransmits, etc., medical applications, automated driving, public safety services, etc. Currently, research is ongoing to develop various technology enablers for supporting these challenging requirements [36,37].
6. Summary and Conclusions In this paper we present and describe the ongoing efforts in 3GPP and oneM2M on MTC/M2M enhancements that can achieve the cost efficiencies required in sensor data networks applications. These enhancements will enable future sensor networks to take advantage of cost efficiencies through the use of low-cost devices that exhibit high latency and can interact with mobile operator networks in an efficient manner. 7. References [1] J. Swetina, Guang Lu, P. Jacobs, F. Ennesser, and JaeSeung Song, "Toward a standardized common
13
M2M service layer platform: Introduction to oneM2M," Wireless Communications, IEEE, vol. 21, no. 3, pp. 20-26, June 2014. [2] J., Kunz, A., Schmidt, M., Piotr, S. Song, "Connecting and Managing M2M Devices in the Future Internet," Springer Journal of Mobile Networks and Applications, vol. 19, no. 1, pp. 1-17, February 2014. [3] D. Kumar, "Performance analysis of energy efficient clustering protocols for maximising lifetime of wireless sensor networks," Wireless Sensor Systems, IET, vol. 4, no. 1, pp. 9-16, March 2014. [4] J. Azevedo, F. Santos, M. Rodrigues, and L. Aguiar, "Sleeping ZigBee networks at the application layer," Wireless Sensor Systems, IET, vol. 4, no. 1, pp. 35-41, March 2014. [5] R. Jin, Z. Che, Z Wang, M. Zhu, and L. Wang, "Battery optimal scheduling based on energy balance in wireless sensor networks," Wireless Sensor Systems, IET, vol. 5, no. 6, pp. 277-282, December 2015. [6] S.N. Das and S. Misra, "Correlation-aware cross-layer design for network management of wireless sensor networks," Wireless Sensor Systems, IET, vol. 5, no. 6, pp. 263-270, December 2015. [7] A. Kunz, Laeyoung Kim, Hyunsook Kim, and S.S. Husain, "Machine type communications in 3GPP: From release 10 to release 12," in Globecom Workshops (GC Wkshps), 2012 IEEE, December 2012, pp. 1747-1752. [8] D. Astely, E. Dahlman, G. Fodor, S. Parkvall, and J. Sachs, "LTE release 12 and beyond," Communications Magazine, IEEE, vol. 51, no. 7, pp. 154-160, July 2013. [9] TR 36.888, "Study on Provision of Low-Cost Machine-Type Communications (MTC) User Equipments (UEs) based on LTE," 3GPP, v12.0.0 http://www.3gpp.org/DynaReport/36888.htm, Jun., 2014. [10] RP-141660, New WI proposal: Further LTE Physical Layer Enhancements for MTC, Sep., 2014. [11] TR 23.887, "Study on Machine-Type Communications (MTC) and Other Mobile Data Applications Communications Enhancements," 3GPP, v12.0.0 Dec., 2013. [12] TR 37.868, "RAN Improvements for Machine-type Communications," 3GPP, v11.0.0 Mar., 2013. [13] TR 37.869, "Study on Enhancements to Machine-Type Communications (MTC) and other Mobile Data Applications," 3GPP, v12.0.0 Mar., 2013. [14] R. Ratasuk, A. Prasad, Zexian Li, A. Ghosh, and M. Uusitalo, "Recent advancements in M2M communications in 4G networks and evolution towards 5G," in Intelligence in Next Generation Networks (ICIN), 2015 18th International Conference on, Feb., 2015, pp. 52-57. [15] TS 23.682, "Architecture enhancements to facilitate communications with packet data networks and applications," 3GPP, v13.1.0 http://www.3gpp.org/DynaReport/23682.htm , Mar., 2015. [16] TR 23.708, "Architecture Enhancements for Service Exposure," 3GPP, V1.1.0 http://www.3gpp.org/DynaReport/23708.htm, Feb., 2015. [17] TR 23.709, "Study on Optimizations to Support High Latency Communications," 3GPP, v1.1.1 http://www.3gpp.org/DynaReport/23709.htm, Feb., 2015. [18] TR-0014, "oneM2M AllJoyn Interworking," oneM2M, v0.1.0 http://www.onem2m.org/, Jan., 2015. [19] TR 23.769, "Group based Enhancements," 3GPP, v1.1.0 http://www.3gpp.org/DynaReport/23769.htm , Feb., 2015. [20] S. Husain, A. Kunz, J Song, and T. Koshimizu, "Interworking architecture between oneM2M service layer and underlying networks," in Globecom Workshops (GC Wkshps), 2014, pp. 636-642. [21] TR-0001, "oneM2M Use Case collection," oneM2M, v0.0.5 http://www.onem2m.org/ , Nov., 2013.
14
[22] TS-0001, "oneM2M Functional Architecture," oneM2M, v1.6.1 http://www.onemem.org/, Jan., 2015. [23] TS-0002, "oneM2M Requirements," oneM2M, v1.0.1 http://www.onem2m.org, Jan., 2015. [24] TS-0003, "oneM2M Security Solutions," oneM2M, v1.0.1 http://www.onem2m.org, Jan., 2015. [25] TS-0004, "oneM2M Service Layer Core Protocol Specification," oneM2M, v1.0.1 http://www.onem2m.org, Jan., 2015. [26] TS-0005, "oneM2M Management Enablement (OMA)," oneM2M, v1.0.1 http://www.onem2m.org, Jan., 2015. [27] TS-0006, "oneM2M Management Enablement (BBF)," oneM2M, v1.0.1 http://www.onem2m.org, Jan., 2015. [28] TS-0008, "oneM2M CoAP Protocol Binding," oneM2M, v.1.0.1 http://www.onem2m.org, Jan., 2015. [29] TS-0009, "oneM2M HTTP Protocol Binding," oneM2M, v1.0.1 http://www.onem2m.org, Jan., 2015. [30] TS-0010, "oneM2M MQTT Protocol Binding," oneM2M, v1.0.1 http://www.onem2m.org, Jan., 2015. [31] TS-0014, "LWM2M Interworking," oneM2M, v0.1.0 http://www.onem2m.org/, Feb., 2015. [32] TR-069 Amendment 5, "CPE WAN Management Protocol," Broadband Forum, http://www.broadband-forum.org/technical/download/TR-069_Amendment-5.pdf , 2013. [33] H. Shariatmadari et al., "Machine-type communications: current status and future perspectives toward 5G systems," Communications Magazine, IEEE, vol. 53, no. 9, pp. 10-17, September 2015. [34] P., Braun, V., Mayer, P., et al. Popovski, "Deliverable D1.1 Scenarios, requirements and KPIs for 5G mobile and wireless system," METIS, ICT-317669-METIS/D1.1 Apr., 2013. [35] TR 102 889-2, "Part 2: Technical characteristics for SRD equipment for wireless industrial applications using technologies different from Ultra-Wide Band (UWB)," ETSI, Aug., 2011. [36] G.C. Madueño, C. Stefanovic, and P. Popovski, "Reliable Reporting for Massive M2M Communications With Periodic Resource Pooling," Wireless Communications Letters, IEEE, vol. 3, no. 4, pp. 429-432, August 2014. [37] O.N.C. Yilmaz et al., "Analysis of ultra-reliable and low-latency 5G communication for a factory automation use case," in Communication Workshop (ICCW), 2015 IEEE International Conference on, 2015, pp. 1190-1195. [38] TR 23.789, "Monitoring Enhancements," 3GPP, v1.1.0 http://www.3gpp.org/DynaReport/23789.htm, Feb. 2015.
15
