Enhanced 3GPP system for Machine Type ...

Download PDF
172 downloads 59053 Views 201KB Size Report
Comment
Index Terms – MTC, M2M, IoT, 3GPP, Standards, Monitoring, .... application server via SCEF. .... Step 1: The Service Capability Server (SCS)/Application. Server ...
(c) 2015 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other users, including reprinting/ republishing this material for advertising or promotional purposes, creating new collective works for resale or redistribution to servers or lists, or reuse of any copyrighted components of this work in other works.

Enhanced 3GPP system for Machine Type Communications and Internet of Things Andreas Kunz1, Athul Prasad2, Konstantinos Samdanis1, Syed Husain3, JaeSeung Song4 NEC Laboratories Europe, Heidelberg, Germany1 Nokia Networks, Espoo, Finland2 NTT DoCoMo, Tokyo, Japan3 Sejong University, Seoul, Korea4 Email: [email protected], [email protected], [email protected], [email protected], [email protected] Abstract — The Third Generation Partnership Project (3GPP) has been working on developing specifications on Machine Type Communications (MTC), also known as Machine to Machine Communications (M2M), which is all part of Internet of Things (IoT), a technology that enables machines and devices to be inter-connected via the internet. This paper presents recent M2M/IoT feature enhancements in 3GPP. These features include architectural enhancements for inclusion of a service exposure framework, group based IoT management, efficient monitoring mechanisms for IoT devices, optimization of IoT device power consumption, and high latency communications. These M2M/IoT related functionalities and enhancements are a continuing effort within 3GPP to make the mobile network fulfil the ever changing M2M/IoT requirements, and in so doing allow operators/service providers to offer unique services. Index Terms – MTC, M2M, IoT, 3GPP, Standards, Monitoring, Group management.

I. INTRODUCTION Interest in Internet of Things, a network of machines and devices interconnected via the Internet, is growing rapidly as a main driver of significant revenue growth for mobile network operators [1]. Machine Type Communications or Machine-to-Machine Communications is an important enabling technology to accelerate the IoT. The number of communicating things for IoT is forecast to increase to 26 billion devices by 2023 [2]. Considering an enormous business growth, many international standards development organizations (SDOs) are paying attention to develop technical specifications on MTC/IoT including the 3rd Generation Partnership Project, oneM2M and ITU-T [3][4][5]. The existing mobile cellular network was not originally designed to efficiently manage MTC/IoT communication. 3GPP has been working on collecting new requirements for various MTC/IoT use cases followed by analyzing architectural enhancements required for 3GPP systems to satisfy these new MTC/IoT requirements. As the number of MTC/IoT devices using cellular networks is expected to grow rapidly, with numbers far exceeding that of typical

mobile devices, it could cause various new challenges to 3GPP systems. For example, a large amount of MTC/IoT devices in the same region (e.g., city, town, sports stadium) can try to transmit traffic at the same time. This can cause serious impact on the mobile networks, especially on the resource management of the core networks and the performance of communications [16]. While the 3GPP system provides standards for the mobile network and wireless connectivity layers, focusing on energy and cost efficiency, there exist other SDOs working on different layers. One of them is the oneM2M standards focusing on the application layer, control layer, and device management layer. In order to support end-to-end IoT service optimization, these different layers have to expose their services and allow the exchange of information. For example, applications of a MTC/IoT device running on top of the oneM2M service layer can share the mobility status information to the service capability functions of the 3GPP systems, so that a network operator can optimize its network resources and support the device to save its radio resources and battery power consumption. In this article we will review the standards activities in some of the most relevant work items to MTC and IoT. Key issues, requirements and potential solutions expected to have an important impact to future 3GPP networks are highlighted. In particular, the following features are introduced in this paper: • Architecture Enhancements for Service Capability Exposure (AESE): Provides architecture enhancements for a service capability exposure framework when 3GPP service capabilities are exposed via other standardized APIs (Application Programming Interface) such as oneM2M open API(s) (Section II) • Group-based feature (GROUPE): Analyses architectural enhancements for group based message delivery to a large group of IoT devices resulting in controlling network congestion (Section III) • Monitoring Enhancements (MONTE): Evaluates architectural enhancements required for 3GPP systems to provide various monitoring service capabilities such

Figure 1: Service Capability Exposure Architecture as indication of roaming status and continuous reporting on the location of an IoT device (Section IV), • Extended Discontinuous Reception (eDRX): Studies extending the discontinuous reception cycle to reduce UE power consumption and efficient resource utilization (Section V) • High Latency Communications (HLCom): Supports applications that communicate with unreachable 3GPP IoT devices for extended periods (Section VI) The set of features introduced in this article is not an exhaustive list, but a representative selection of the important work items on M2M/IoT related topics in 3GPP release 13. Each section presents an overview of given work item, main issues and options of architectural enhancements, and future directions. Finally, the article is concluded with a brief discussion and summary for future M2M/IoT related standardization work in 3GPP (Section VII). II. ARCHITECTURE ENHANCEMENTS FOR SERVICE CAPABILITY EXPOSURE The Architecture Enhancements for Service Capability Exposure work describes how 3GPP system provided service capabilities can be exposed via one or more standardized APIs, e.g., the Open Mobile Alliance (OMA)API(s) or the GSM Association (GSMA). Six key issues were concluded for normative specification in 3GPP TS 23.682 [6]: • Key Issue 1 - Service Capability Exposure Framework • Key Issue 2 - Setting up an AS session with required QoS • Key Issue 3 - Change the chargeable party at the session set-up or during the session • Key Issue 4 - Support of 3rd party interaction on information for predictable communication patterns • Key Issue 6 - Informing the 3rd party about potential network issues • Key Issue 7 - 3GPP resource management for background data transfer

Figure 2: Provisioning of CP Parameters The documented key issues 5 on informing the 3rd party about a UE's connection properties could not be concluded within the Rel-13 time frame (not listed here). Figure 1 shows the service capability exposure framework architecture as agreed in key issue 1. This architecture introduces the Service Capability Exposure Function (SCEF) in order to securely expose the services and capabilities via the 3GPP network interfaces. While the SCEF is always in the trust domain of the operator or trusted business partner, the applications may be outside the trust domain. The SCEF has various functionalities; the main ones may be Authentication and Authorization, Policy enforcement and the ability for the external entities to discover the exposed service capabilities. In the following key issue 4 is introduced as an example on how SCS/AS influence parameters in the 3GPP core network and Radio Access Network (RAN). The SCS/AS knows the behavior of the UE and can make a prediction of the communication and mobility pattern, e.g., whether communication is periodic, the duration, interval between the periodic communications and whether the UE is stationary or mobile. The SCS/AS can provide such information in form of a Communication Pattern (CP) to the SCEF together with a corresponding validity time, i.e., when this CP is active. The related call flow is shown in the following Figure 2. When the SCEF receives the Update Request in step 2, it selects the relevant CP Parameters and takes care that not two active CP sets are overlapping with their validity times. The SCEF then sends the CP Parameter set to the HSS including the validity time. It is possible that more than one CP Parameter set is sent in the same message. The HSS then updates the UE’s subscriber profile with the CP Parameter set and validity time and acknowledges the request. The HSS provides the CP Parameter set and validity time to the MME where they are stored. The MME may use the CP Parameters in order to derive start values for the Core Network assisted eNodeB Parameters tuning feature as described in 3GPP TS 23.401 [7].

III. GROUP-BASED FEATURE The Group-based feature for Rel-13 addresses several key issues for management of groups of devices requiring similar treatment. This greatly helps congestion control in 3GPP system when it is not necessary to treat each device individually. The following aspects of group-based feature are handled in Rel-13: • Group-specific NAS Level Congestion Control • Group based addressing and identifiers to map between external group ID and internal group ID • Message delivery to a group of devices





 )( (

 )

( 



(

-' "   

.' #" &" /'  " 0'"   ! 1'"$" "! 2' # !!  3'#" &" 4'"$"     #!" 5'"$"     !! -,' # !!  --'!!" " #!"( !! -.' #!!$ % -/'" !!" #!!

How the 3GPP system determines that devices are causing congestion is by tracking NAS signaling per group to determine which members of a particular group are causing extensive NAS signaling. This requires group-based addressing which requires mapping between external group IDs to internal group IDs. Then message delivery can proceed to these groups of devices. Group message delivery allows efficient distribution of the same content to the members of a group that are located in a particular geographical area, as requested by the 3rd party application server via SCEF. The group message delivery procedure is shown in Figure 3 [6]. First, if there is no assigned TMGI for an External Group ID, the SCS/AS sends the Allocate TMGI Request (External Group ID, SCS Identifier) message to the SCEF. The SCS/AS may determine the IP address(es)/port(s) of the SCEF by performing a DNS query using the External Group Identifier or using a locally configured SCEF identifier/address. The SCEF checks that the SCS/AS is authorized to request TMGI allocation. In step 2, the SCEF determines whether the SCS/AS is authorized to request TMGI allocation. (Please note here that the authorization of TMGI allocation for the group and acquisition of the BM-SC routing information are not specified in this release of the specification.) The SCEF then initiates the TMGI allocation to the BM-SC (see TMGI Allocation Procedure specified in TS 23.468 [8]). The SCEF sends the received TMGI and expiration time information to the SCS/AS. In this step, the SCEF may cache the serving BM-SC Identity information and mapping between External Group ID and TMGI (Step 4). Application level interactions may be applied for the devices of specific group to retrieve the related MBMS service information, e.g., TMGI. Application level interactions between the UE and the SCS/AS are out of scope of this specification (Step 5). The SCS/AS sends the Group Message Request (External Group Identifier, SCS Identifier, delivery content, location/area information, RAT(s) information, TMGI) message to the SCEF. The location/area information indicated by the SCS/AS may be the geographic area information (Step 6). The SCEF checks that the SCS/AS is authorized to send a group message request. If this check fails the SCEF sends a Group Message Confirm message with a cause value, indicating the reason for the failure condition and the flow stops at this step 7.

Figure 3: Group message delivery procedure Here authorization of group message delivery using MBMS towards a specific group is not specified in this release of the specification. In Step 8, the SCEF sends an Activate MBMS Bearer Request (MBMS service Area, TMGI, delivery content) message to the BM-SC. (Please note that the SCEF maps between location/area information provided by the SCS/AS and the MBMS service area for the distribution of the group message based on configuration in the operator domain. The SCEF needs to be aware that the selected MBMS service area(s) may result in broadcast of the message over an area larger than the area that may be indicated by SCS/AS) The BM-SC sends an Activate MBMS Bearer Response to the SCEF (Step 9). Then the SCEF sends a Group Message Confirm message to the SCS/AS to confirm that the Request has been accepted for delivery to the group (Step 10) followed by the session start procedure via BM-SC (see MBMS Session Start Procedure specified in TS 23.246 [9]). In Steps 12 and 13, if the SCS/AS did not provide the SCEF with the delivery content in Step 6 the SCS/AS transfers the group message content to the SCEF in this step. SCEF delivers the contents to BM-SC and BM-SC transfers the corresponding content to UEs. To avoid that potential responses to the broadcast message by high numbers of devices are sent at almost the same time, the SCS/AS makes sure the UE is provided with a response time window if it expects the UEs to respond to the group message. In response to the received content, the UE may initiate immediate or later communication with the SCS/AS. Note that the UE application ensures distribution of any responses over the response time window. IV. MONITORING ENHANCEMENTS The Monitoring enhancements (MONTE) feature provides architectural enhancements for the 3GPP system that allow for activating monitoring of specific events in the system which are then reported to 3rd party application provider to take specific actions as described in TS 23.682 [6]. Studied monitoring events are: • “SIM-swapping” scenario, e.g., association of UE and UICC (Universal Integrated Circuit Card)

• • • • •

UE location and location changes Loss of connectivity Communication failure Roaming status and serving network changes Reporting the number of UEs present in a certain area

It was concluded to use a solution with monitoring via MME (Mobility Management Entity)/SGSN (Serving GPRS Support Node) and HSS (Home Subscriber Server) or the Policy and Charging Rules Function (PCRF). The solution introduces two new interfaces from the SCEF to connect to the serving MME (T6a) and to the serving SGSN (T6b). The new functionality is to configure monitoring events by the SCEF at the serving MME/SGSN and to do monitoring event reporting by the serving MME/SGSN to the SCEF. Another new reference point (S6t) between SCEF and HSS to provide subscription and UE related information to the SCEF, configure monitoring events and report events as well as mapping E.164 MSISDN (Mobile Subscriber Integrated Services Digital Network Number) or external identifier to IMSI (International Mobile Subscriber Identity) and retrieve serving node information for the UE (i.e., serving MME/SGSN). These new reference points are not exclusive to the MONTE feature but can be used also with other features, e.g., AESE. The SCEF could also interface to the PCRF to retrieve the location information and to report communication failure of a UE, but this requires dynamic Policy and Charging Control (PCC) in the network. The Figure 4 shows the general flow for requesting the PCRF on monitoring events. Step 1: The Service Capability Server (SCS)/Application Server (AS) sends a Monitoring Request to the SCEF, including information about the event type, e.g., Location Reporting or Communication Failure. Step 2: The SCEF performs an authorization checks whether the SCS/AS is allowed to send monitoring requests. Step 3: Based on operator policies the requested monitoring event is configured to be performed via PCRF. The SCEF triggers the PCRF initiated-IP-CAN session modification procedure as defined in TS 23.203 [10]. Step 4: The SCEF sends a Monitoring Response message to the SCS/AS. V. EXTENDED DISCONTINUOUS RECEPTION (EDRX) The energy efficiency of mobile terminals engaging in machine type communications is an essential enabler for the massive deployment of such devices. In the massive MTC deployment scenario for sensors, etc., the battery life of the device could determine the device lifetime as well, and it is essential to optimize the device operation to save power. Currently, a work item called extended DRX for power consumption optimization is ongoing in 3GPP [11], with the main motivation of optimizing power consumption and



 



 !

$   %      &    "  &

 %& %#& '  

Figure 4: Monitoring via PCRF signaling load in scenarios with mobile terminated data. Mechanisms for power saving, such as the new power saving mode (PSM) that was defined in Release-12 [12], is insufficient when there is mobile terminated data awaiting delivery. Thus, extending the idle and connected state DRX for deployment scenarios which has priority towards mobile terminated data, without introducing additional signaling load is essential. The main objective of the work item is to continue the work done in [13] on extended idle and connected mode DRX, by investigating the open issues further. For idle mode eDRX, the open issues initially identified were mainly related to the non-access stratum (NAS) protocol extensions required for enabling better coordination between the UE and MME. A new paging strategy would also be required at the core network that works with both extended and normal DRX cycle. For connected mode eDRX, whether the MME, Sand P-GWs need to be aware of the use of eDRX by the UE required further study. There have been issues related to the RAN identified as well, which includes the challenges in maintaining reliability, idle mode UE measurements and cell reselections, handling mobile terminated data for extended connected mode DRX, etc. The detailed key issues, solutions proposed and related evaluations done as part of this work is presented in [14]. The solutions proposed are mainly targeting issues identified in extending the idle and connected mode DRX. The idle and connected mode eDRX solutions which were part of the conclusions in [14] are discussed further here. For supporting NAS protocol extensions to enable extended idle mode DRX cycle, it is proposed that the legacy DRX parameters are incorporated with the eDRX information to ensure backward compatibility. Thus, the UE is able to determine the eDRX value to be used and supported by the network once the NAS procedure is complete. Various advantages of the solution, including limited impacts on RAN is also documented in [14], as part of the evaluation done. For avoiding the retransmission of mobile terminated SMS to UEs in long DRX, possible longer than the retransmission timer value, it is proposed that MME could indicate to the SMS infrastructure that the UE is unreachable. Such an enhancement would avoid the need to adapt the retransmission timers in the SMS infrastructure [14], and minimizes the amount of unnecessary retransmissions.

For networks that support both Rel-12 PSM and idle mode eDRX, a proper interaction between the features should be defined. If a UE requests the MME to activate both the features, it is proposed that the MME can decide whether either or both of the features need to be activated. Based on the evaluations done in [14], such a solution was considered to be practically feasible, with minimal impacts on the MME and UE. Another important issue related to idle mode eDRX is the impacts on mobile terminated location services, due to the UE being unreachable for long periods of time. For this purpose, a new ‘UE transiently not reachable’ indication could be defined, with enhancements in MME and gateway mobile location center (GMLC), to indicate that the UE is in idle mode eDRX state, and that the location reporting would be delayed. Such a solution would be essential for the cases where the GMLC retransmission timer values are less than the one of the eDRX cycle [14]. For the core network paging strategy for normal and eDRX cycles, it was proposed to either leave it to MME implementation, or based on negotiations between UE and the core network. In order to handle the S-/P-GW retransmissions for control plane procedures, it is proposed to either adjust the GTP-C retransmission timers according to eDRX cycle values or to define new cause codes to indicate that the UE is in eDRX while in idle mode [14]. It was also concluded that the eDRX for idle mode, with cycle lengths beyond 10.24s would only be adopted for further specifications. No conclusions have yet been made on the solutions related to the connected mode eDRX issues [15]. V. HIGH LATENCY COMMUNICATIONS The work on high latency communications (HLCom) contains a set of functions, which are used for devices that are not immediate reachable, because of power saving reasons following operators’ configurations. The term “high latency” is used to describe the long initial wait time before a device wakes-up, establishes communications and responds to incoming downlink packets. Currently, high latency communications are handled by: • Introducing extended buffering to hold downlink data, while the device is in power saving mode • Explicit notification towards the SCS/AS indicating the time a device become reachable again Extended buffering is introduced at the Serving-GW (S-GW) and it is controlled by the MME/SGSN, which explicitly inform the S-GW to buffer downlink packets related to a specific device until it wakes-up and becomes fully operational. Otherwise, if buffering is not used, the S-GW simply discards the downlink packets when the device is not reachable and the MME/SGSN issues a notification towards the SCS/AS once the device becomes available. Such notification can be placed on one-time reachability request or on a repeated basis, once a device becomes available following a Downlink Data Notification (DDN) failure. The SCS/AS, upon receiving such reachability notification, can now re-send the priori discarded data to the device.



Figure 5: Device availability notification process following a DDN failure The maximum latency can be configured by the SCS/AS and provided to the network either via interacting with the application for setting-up periodic RAU/TAU in relation with the power saving mode or during the device reachability monitoring event. This increases the efficiency of 3GPP network allowing power saving functions. The detailed steps for the case of the device availability following a DDN failure are illustrated in Figure 5. In particular, steps 1 to 6 contain the event configuration in where the SCS/AS registers to the 3GPP network the request to notify the device availability after DDN failure. The remaining steps 7 to 17 show how such notification is used when SCS/AS cannot deliver downlink data because of lack of response, i.e., device unreachability. In particular in step 1, the SCS/AS registers a trigger to be notified following a DDN failure via the SCEF, which forwards such a monitoring request to the HSS in step 2. The HSS in step 3 lets the MME know about such a request, which in turn allocates internally an event flag and responds back in step 4 to the HSS. The HSS then provides a monitoring response to the SCEF, which in turn forwards it to the SCS/AS. When downlink data is sent by the SCS/AS to the S/P-GW in step 7, the S-GW issues a DDN to the MME, i.e., step 8, requesting device paging. The MME in turn initiates paging in step 9, but if it receives no response because the device is in power saving mode, then it responses back to the S-GW a DDN failure, in step 10. At the same time it sets a flag to notify device availability after DDN failure in step 11. Once the device wakes-up and performs a TAU, step 12, the MME realizes that the device is now available in step 13, and issues a monitoring indication towards the SCEF in step 14 to let the SCS/AS know about the device reachability, step

15. The SCS/AS then re-sends the queued data step 16 towards the device in step 16. VII. DISCUSSION AND CONCLUSIONS In this article we introduced the recent 3GPP standards

activities in the areas of the MTC/IoT. Major features and issues that have been developed or are currently under development, were presented. In particular, work items focusing on: (1) general architecture enhancements for MTC/IoT, (2) group management mechanisms, (3) MTC/IoT device monitoring, discontinuous data reception mechanisms to reduce UE power consumption and (4) high latency communications, were reviewed. Looking at these recent standards work items in 3GPP, we could identify several important standards trends: 1) given the fact that the number of MTC/IoT devices will be increase significantly, network systems have to be enhanced to cope with huge amount of data traffic from MTC/IoT devices, 2) various standards technologies (e.g., monitoring mechanisms, group management, data aggregation and delivery) for MTC/IoT have to be investigated to optimize 3GPP networks, and 3) as many technologies are used in MTC/IoT services, SDOs developing MTC/IoT related standards need to collaborate with each other, e.g., exposing their service capabilities and sharing useful management information. ACKNOWLEDGEMENTS This work was supported by Institute for Information & communications Technology Promotion (IITP) grant funded by the Korea government (MSIP) (No.B0184-15-1003, oneM2M The Development of oneM2M Conformance Testing Tool and QoS Technology) REFERENCES [1] J.Song, A. Kunz, M. Schmidt, and P. Szczytowski. “Connecting and managing m2m devices in the future internet,” Mobile Networks and Applications, pages 1–14, 2013. [2] “3GPP Overview of 3GPP Release 11,” v0.1.0, 2013 [3] T. Taleb and A. Kunz, “Machine type communications in 3gpp networks: potential, challenges, and solutions,” Commun. Mag., IEEE, vol. 50, no. 3, pp. 178–184, 2012. [4] J. Swetina, G. Lu, P. Jacobs, F. Ennesser, and J. Song, “Toward a standardized common m2m service layer platform: Introduction to onem2m,” IEEE Wireless Communications, vol. 21, no. 3, pp. 20-26, 2014. [5] S. Husain, A. Prasad, A. Kunz, A. Papageorgiou, and J. Song, “Recent Trends in Standards Related to The Internet of Things and Machine-to-Machine Communications,” Journal of Information and Communication Convergence Engineering, vol. 12, no. 4, pp. 228–236, 2014. [6] 3GPP TS 23.682 “Architecture enhancements to facilitate communications with packet data networks and applications,” v13.2.0, Jun. 2015 [7] 3GPP TS 23.401 “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access,” v13.3.0, June, 2015

[8] 3GPP TS 23.468 “Group communication system enablers for LTE (GCSE_LTE),” v13.1.0, Jun. 2015 [9] 3GPP TS 23.246 “Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description,” v13.1.0, Jun. 2015 [10] 3GPP TS 23.203 “Policy and charging control architecture,” v13.4.0, Jun. 2015 [11] 3GPP SP-140881, “New Feasibility study on Extended DRX cycle for Power Consumption Optimization ,” Dec. 2014. [12] R. Ratasuk, et al. "Recent Advancements in M2M Communications in 4G Networks and Evolution Towards 5G," IEEE ICIN, Paris, Feb. 2015. [13] 3GPP TR 23.887, ‘Study on Machine-Type Communications (MTC) and Other Mobile Data Applications Communications Enhancements,’ v12.0.0, Dec. 2013. [14] 3GPP TR 23.770, “Study on System Impacts of Extended DRX Cycle for Power Consumption Optimization,” v1.0.0, June 2015. [15] 3GPP S2-151985, “Cover Sheet for TR 23.770 for Approval at TSG SA,” May 2015. [16] K. Samdanis, A. Kunz, M.I. Hossain, T. Taleb, "Virtual Bearer Management for Efficient MTC Radio and Backhaul Sharing in LTE Networks", IEEE PIMRC, London, Sep. 2013.