Workshop on Transceiver Design for ITS
Efficient Data Transmission Scheme for MTC Communications in LTE System Shiann-Tsong Sheu, Chun-Hsiang Chiu, Shaojung Lu, Hsien-Hao Lai Department of Communication Engineering, National Central University, Taiwan e-mail: [email protected], [email protected], [email protected], [email protected] 72,000 taxis of them have been equipped with the fleet management devices. The most frequent location report happens with the interval of 5 seconds, and periodicity of 1015 seconds is a typical configuration. One typical RACH overload scenario that has been observed in a current network appears in the taxi area of airport. For example, such kind of overload is observed often in Beijing Capital International Airport, since it is normal that there are hundreds of taxis queued for passengers. For the airport scenario, assuming that there are 800 taxis aggregating in one cell and 90% of them need to send their location information. Assuming that reporting interval is 10 seconds and reporting time across taxis is uniformly distributed, the RACH intensity (number of RACH attempts/s) generated by taxis is about 800*90%/10=72. As for the case of meeting at the taxi company, there are also hundreds of taxis aggregating in one cell, e.g. 400. All of them are equipped with fleet management devices once the company has subscribed to the service. Then the RACH intensity is about 400/10=40 attempts/s. Additionally, MTC devices need to process handover while they are in idle mode and are moving on the road. Assuming that the base station radius in Beijing urban area is about 300m and the average velocity of vehicles is 40km/h, handover happens for every 27s. As illustrated in the above example, an eNodeB needs to serve 800 MTC devices at any time. The incurred loading from an eNodeB to handle MTC devices is somehow ignorable because the number of MTC devices served by a cell is relatively small, as compared to the aforementioned smart metering scenarios. However, according to the specified handover frequency (1/27 handover per second) of a taxi, an eNodeB needs to handle 29.62 (=800/27) handover procedures every second. Considering a non-active MTC device in idle mode for further data transmission, although it has no data to transmit, it still needs to perform location update procedure when it moves from the coverage area of serving eNodeB to the coverage area of target eNodeB. As a consequence, this kind of network still has to handle 29.62 handover procedures every second. Besides, due to the responsibility of serving eNodeB to pass the corresponding key(s) of the handover MTC device to the target eNodeB, additional signaling overhead in core network may further increase the system complexity. Considering the complexity of handover procedures, MTC devices shall enter detached state if they do not have data to transmit. MTC devices must do authentication procedure every time when it is willing to transmit data.
Abstract—Machine type communication (MTC) is becoming an important part of the cellular network, such as long-termevolution (LTE) network. Diverse MTC applications are going to be realized in LTE network due to the advantages of better coverage and lower deployment cost. However, a large number of MTC devices desiring to transmit short data will cause overloaded in the radio access network (RAN). As a solution, this paper proposes an efficient data transmission scheme for MTC devices to transmit data in order to minimize the impact from MTC communications on standard LTE network. Keywords-component; LTE; MTC; M2M; machine type communication; radio network overload
I.
INTRODUCTION
In the mobile communication system, machine type communication (MTC) plays an important role in recent years. There are a number of important differences between MTC and human-to-human (H2H) communication. MTC involves several entities which do not necessarily need human’s operation. Three use cases are listed in 3GPP TR 37.868 [1] to show the use cases of MTC services. The first use case of MTC services is metering. Metering refers to electric, gas, water or heating, etc. The second use case is road security. Road security involves emergency call, ticketing, fleet management and congestion avoidance. The third use case is consumer electronic and devices. Due to these use cases, MTC contains five aspects different from H2H communication: a) different market scenarios. b) data communications without voice. c) lower costs and effort for users. d) a very large number of end devices. e) little traffic for every device. Due to these aspects, protocols in mobile communications need to be modified to get the best performance. In the 3rd Generation Partnership Project (3GPP) Radio Access Network Working Group 2 (RAN2) meetings, several examples of random access channel (RACH) overload in case of specific MTC applications were discussed and agreed for inclusion in the technical report (TR). One of these scenarios described in the TR is a fleet management application. Fleet management is becoming a popular MTC application in China. In many metropolises of China, taxis are equipped with the devices which can report their latest location information periodically or on demand. Currently, the fleet management application has been deployed in many cities of China. These applications are using General packet radio service (GPRS)/ Enhanced Data rates for GSM Evolution (EDGE) to report their information. In Beijing, there are around 80,000 taxis now, and more than
978-1-61284-671-2/11/$26.00 ©2011 IEEE
727
In the previous research paper [2], MTC devices shall enter detached state if they do not have data to transmit. To enter detached state also solves handover problems. In the previous research paper [3], the cellular communication architecture was modified to fit the MTC needs. It was an un-peer2peer communication architecture, which made the MTC devices less protocol stacks than normal. A facilitator need to be built for reconstructing the missed protocols and act as a virtual interface between the MTC server and the MTC devices. The architecture can reduce the overhead of the MTC data transmission. However, to modify the system architecture is not an easy issue in the mobile communication system. The security issue is not considered in this solution. In some cases in the proposed paper, MTC device does not need to do the mutual authentication procedure for data transmission. It would be a dangerous impact to the cellular network. Another previous research [4] proposed enhancements of the MAC protocol. It showed that the MAC protocol may further reduced. The MTC devices may send data with the preambles or just send data after uplink (UL) grant. However, the research did not consider the security issue and was also a dangerous modification to the cellular network. There is an obvious issue where congestion in the signalling network is caused by a high number of MTC devices trying almost simultaneously to setup their connections after completing the contention procedure. In other words, every MTC device is requested to start authentication phase and data radio bearer establishment phase before transmitting MTC data to MTC server and after the RACH procedure is done. For the MTC devices with small data transmissions feature, the signalling overhead of preliminary procedures prior to small data transmission from MTC device to MTC server should be reduced or avoided. This paper proposes an efficient MTC data transmission procedure to minimize the overhead and latency incurred from MTC communications. The paper proposed a scheme that the MTC devices can send data to MTC server in the authentication procedure. This scheme can reduce the overhead of MTC and also considers the security issue. II.
FAST MTC DATA TRANSMITION PROCEDURE
A. Standard Procedure During the network attachment phase, an MTC device contends the channel resource following the received RACH information. Once an MTC device gets the response from evolved universal terrestrial radio access network (EUTRAN), it starts the authentication phase. The MTC device and mobile management entity (MME) will exchange some specific parameters in order to accomplish the authentication process. If the authentication of MTC device has passed, MTC device is able to access the network via establishing data radio bearer(s). The complicated time sequence of an
728
Figure 1. MTC data transmission procedures: (a) Standard sequence. (b) Efficient data transmission scheme MTC device from the initial state to get the permission of sending data to MTC server is depicted in Fig. 1 (a). It is evident that the signalling overhead incurred from MTC device with small data transmission feature will impact the system performance. Furthermore, the battery powered MTC device (such as sensors or meters) would keep power off all the time unless it desires to send data to the MTC server. To maximize the system performance and the lifetime of MTC device, it is desired to design an efficient data transmission procedure to minimize the communication period by simplifying the time sequence of transmissions. For a large number of time-controlled MTC devices with small packet size and low duty cycle features, it is inefficient for the serving network to setup and maintain the connectivity. Therefore, this paper proposes the solution to deliver MTC data without establishing the data radio bearer (DRB) between MTC device and E-UTRAN.
MTC device
E-UTRAN
S-GW P-GW
MME
HSS
MTC Server
System Information Acquisition
RRC Connection Establishment
Random Access Procedure
Attach Request Initial UE Message Authentication Data Request (IMSI || SN identity || Network Type)
Authentication Request (RAND || AUTN) Authentication response (RES || )
Authentication Data Response (RAND || XRES || CK || IK || AUTN)
Authentication Request (RAND || AUTN || KSIASME) Cache MTCDATA
Authentication response (RES) DownLink NAS transport + Security Mode Command
Timeout
Indicate success of authentication and transmission
MTC Data Forwarding
Figure 2. Time sequence of efficient data transmission According to MTC service requirements defined in TS 102 689 document [5], the MTC system shall support authentication of MTC devices, provide mechanisms to assure integrity of transmitted information and support confidentiality for MTC services. Based on such requirement, the MTC device shall perform mutual authentication with serving network before data transmission and reception. If the MTC device skips mutual authentication procedures before data transmission and reception, there are some security issues impacting to the system. B. Efficient data transmission scheme In the mutual authentication procedures, authentication information is exchanged by the user equipment (UE) and MME. Since authentication information is exchanged between the UE and MME during the mutual authentication, the MTC device may embed data into the authentication information and send it to serving network. Once the authentication of MTC device has passed, the eNodeB already has the MTC data on hand and then it can quickly
729
forward data to the MTC server via core network. This procedure is shown in Fig 1 (b). Fig. 2 depicts the time sequence of efficient data transmission scheme. While an MTC devices trends to transmit data to the MTC server. It receives RACH information from the air interface. Then an MTC device contends the channel resource following the received RACH information. After contending success, the MTC device sends an attach request which involves International Mobile Subscriber Identity (IMSI) to E-UTRAN. E-UTRAN sends an UE initial message to MME. Then MME sends authentication data request to home subscriber server (HSS) to request the authentication of the MTC device. HSS returns an authentication data response which contains a random number (RAND), expected user response (XRES), cipher key (CK), integrity key (IK) and authentication token (AUTN) to MME. MME sends authentication request contains key set identifier (KSI), RAND and AUTH to EUTRAN. E-UTRAN sends another authentication request with RAND and AUTN to the MTC device. Then the MTC device sends an authentication response to E-UTRAN.
TABLE I.
LATENCY FROM RRC CONNECTION ESTABLISHMENT TO MTC DATA TRANSMISSION Type
Normal Procedure Effcient MTC Data Transmission Procedure TABLE II.
Figure 3. Encryption for MTCDATA In order to accomplish the MTC data transmission in authentication phase, the proposed efficient MTC data transmission procedure allows an MTC device to embed the MTC data (MTCDATA) into the authentication response message, which is sent from an MTC device to the MME. The MTCDATA could be encrypted by using an encryption algorithm with encryption key (such as KNASenc, KRRCenc and KUPenc) and also appended the message authentication code derived by applying an integrity protection algorithm with integrity key (such as KNASint and KRRCint)[6][7]. Because the authentication response message sent from MTC device to the MME is forwarded by the serving eNodeB, the serving eNodeB is able to extract the MTCDATA from the authentication response message and temporarily store it for further decryption and forwarding. Fig. 3 depicts the MTCDATA is embedded in authentication response message. After then, the remaining of authentication response message is sent to MME by eNodeB, as the standard does. If the MTC device passes the authentication, the MME sends a security mode command to the eNodeB. Once the eNodeB receives the command, it can decrypt and verify the MTCDATA by applying the same algorithms and keys. If the MTCDATA is correct, the eNodeB will forward it to MTC server automatically. In order to comply with legacy protocol, the eNodeB will send message authentication reject to the MTC device only when the authentication is failed[8]. In other words, the MTC device is aware of the success of authentication and data transmission when the timer T3416 expires. It is worthwhile to note that the timer T3416 is activated when the MTC device sends the authentication response message to MME. The default timeout value is 30s. Considering the power consumption issue, the timeout value for the MTC devices should be set as small as possible. III.
Steps 62
Latency (Best) 125 ms
Latency (Worst) 365 ms
18
45 ms
136 ms
SIMULATION PARAMETERS
Parameter Number of MTC devices MTC devices arrival distribution Interval of MTC data transmission Cell bandwidth PRACH Configuration Index Total number of preambles Maximum number of preamble transmission Number of UL grants per RAR Number of CCEs allocated for PDCCH Number of CCEs per PDCCH Preamble detection probability (in case of no collision)
ra-ResponseWindowSize mac-ContentionResolutionTimer Backoff Indicator HARQ retransmission probability for Msg3 and Msg4 (non-adaptive HARQ) Maximum number of HARQ TX for Msg3 and Msg4 (non-adaptive HARQ)
Setting 5000, 10000, 30000 Beta distribution 10 seconds 5 MHz 6 54 10 3 16 4
1−
1 ei
where i indicates the i-th preamble transmission 5 subframes 48 subframes 20ms 10% 5
B. Simulation Parameters Table 1 shows the latency time from RRC connection establishment to MTC data transmission. While an MTC device need to upload MTC data to the server, it has to perform 62 steps and spends up to 365 ms to finish the transmission in normal procedure. However, it just has to perform 18 steps and spends up to 136 ms to finish the transmission in Efficient MTC data transmission procedure. The simulation uses the parameters in Table 2. The simulation parameters were discussed in 3GPP meetings and noted in the TR. C. Simulation Results Fig. 4 shows the simulation result. The MTC devices which use the efficient MTC data transmission scheme have much less latency than the MTC devices which use the procedure defined in specification. While the MTC devices use the standard procedure to transmit MTC data, it spends 150 ms to 450 ms finishing the
SIMULATION
A. Simulation Assumptions 3GPP meetings define the number of MTC devices can be set to 5000, 10000 and 30000. Every MTC device must upload data every 10 seconds. We simulate two different procedures to transmit MTCDATA to the MTC server and compare the results.
730
packet size and low duty cycle. In addition, the establishment and maintenance of DRB for such MTC devices should be avoided if possible. This paper has proposed an efficiencyimprovement procedure to improve LTE network in machine type communication. This scheme leads to an efficient cellular network for MTC communication in LTE system. V.
ACKNOWLEDGEMENT
This work was supported in part by grants from the M2M System Simulation and Performance Analysis Project of Institute for Information Industry (III) and sponsored by MOEA, Taiwan, ROC. REFERENCES [1] [2]
whole procedure. However, it spends 75 ms to 150 ms finishing data exchange by efficient fast data transmission scheme. Comparing in best case and worst case, it spends Figure 4. Simulation results
[3]
[4]
double to triple time finishing data transmission procedure respectively. It means that the cellular network which implements efficient data transmission scheme has more radio resources to serve more devices than it uses standard procedure. IV.
[5] [6]
CONCLUSION
[7]
In this paper, the time sequence analysis shows that the legacy attach procedure is quite inefficient for the timecontrolled MTC devices, which have the features of small
[8]
731
3GPP TR 37.868, Study on RAN Improvements for Machine-type Communications Sheu, S-T., Lee, Y-T., and Lu S. “Load Analysis for MTC Devices in Idle Mode or Detached State.”, in Proc of ICS 2010, 16-18 Dec. 2010, pp. 424-428 Chen, Y., and Yang, Y. "Cellular based machine to machine communication with un-peer2peer protocol stack.", In Vehicular Technology Conference Fall (VTC 2009-Fall), 2009 IEEE 70th, 20-23 Sept. 2009 , pp. 1-5 Chen, Y., and Wang, W. " Machine-to-Machine Communication in LTE-A.", In Vehicular Technology Conference Fall (VTC 2010-Fall), 2010 IEEE 72nd, 6-9 Sept. 2010 , pp. 1-4 ETSI TS 102 689, “Machine-to-Machine communications (M2M); M2M service requirements” 3GPP TS 33.401, “3GPP System Architecture Evolution (SAE); Security architecture” 3GPP TS 24.301, “Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)” 3GPP TS 33.102, “3G Security; Security architecture”
Efficient Data Transmission Scheme for MTC Communications in LTE System Shiann-Tsong Sheu, Chun-Hsiang Chiu, Shaojung Lu, Hsien-Hao Lai Department of Communication Engineering, National Central University, Taiwan e-mail: [email protected], [email protected], [email protected], [email protected] 72,000 taxis of them have been equipped with the fleet management devices. The most frequent location report happens with the interval of 5 seconds, and periodicity of 1015 seconds is a typical configuration. One typical RACH overload scenario that has been observed in a current network appears in the taxi area of airport. For example, such kind of overload is observed often in Beijing Capital International Airport, since it is normal that there are hundreds of taxis queued for passengers. For the airport scenario, assuming that there are 800 taxis aggregating in one cell and 90% of them need to send their location information. Assuming that reporting interval is 10 seconds and reporting time across taxis is uniformly distributed, the RACH intensity (number of RACH attempts/s) generated by taxis is about 800*90%/10=72. As for the case of meeting at the taxi company, there are also hundreds of taxis aggregating in one cell, e.g. 400. All of them are equipped with fleet management devices once the company has subscribed to the service. Then the RACH intensity is about 400/10=40 attempts/s. Additionally, MTC devices need to process handover while they are in idle mode and are moving on the road. Assuming that the base station radius in Beijing urban area is about 300m and the average velocity of vehicles is 40km/h, handover happens for every 27s. As illustrated in the above example, an eNodeB needs to serve 800 MTC devices at any time. The incurred loading from an eNodeB to handle MTC devices is somehow ignorable because the number of MTC devices served by a cell is relatively small, as compared to the aforementioned smart metering scenarios. However, according to the specified handover frequency (1/27 handover per second) of a taxi, an eNodeB needs to handle 29.62 (=800/27) handover procedures every second. Considering a non-active MTC device in idle mode for further data transmission, although it has no data to transmit, it still needs to perform location update procedure when it moves from the coverage area of serving eNodeB to the coverage area of target eNodeB. As a consequence, this kind of network still has to handle 29.62 handover procedures every second. Besides, due to the responsibility of serving eNodeB to pass the corresponding key(s) of the handover MTC device to the target eNodeB, additional signaling overhead in core network may further increase the system complexity. Considering the complexity of handover procedures, MTC devices shall enter detached state if they do not have data to transmit. MTC devices must do authentication procedure every time when it is willing to transmit data.
Abstract—Machine type communication (MTC) is becoming an important part of the cellular network, such as long-termevolution (LTE) network. Diverse MTC applications are going to be realized in LTE network due to the advantages of better coverage and lower deployment cost. However, a large number of MTC devices desiring to transmit short data will cause overloaded in the radio access network (RAN). As a solution, this paper proposes an efficient data transmission scheme for MTC devices to transmit data in order to minimize the impact from MTC communications on standard LTE network. Keywords-component; LTE; MTC; M2M; machine type communication; radio network overload
I.
INTRODUCTION
In the mobile communication system, machine type communication (MTC) plays an important role in recent years. There are a number of important differences between MTC and human-to-human (H2H) communication. MTC involves several entities which do not necessarily need human’s operation. Three use cases are listed in 3GPP TR 37.868 [1] to show the use cases of MTC services. The first use case of MTC services is metering. Metering refers to electric, gas, water or heating, etc. The second use case is road security. Road security involves emergency call, ticketing, fleet management and congestion avoidance. The third use case is consumer electronic and devices. Due to these use cases, MTC contains five aspects different from H2H communication: a) different market scenarios. b) data communications without voice. c) lower costs and effort for users. d) a very large number of end devices. e) little traffic for every device. Due to these aspects, protocols in mobile communications need to be modified to get the best performance. In the 3rd Generation Partnership Project (3GPP) Radio Access Network Working Group 2 (RAN2) meetings, several examples of random access channel (RACH) overload in case of specific MTC applications were discussed and agreed for inclusion in the technical report (TR). One of these scenarios described in the TR is a fleet management application. Fleet management is becoming a popular MTC application in China. In many metropolises of China, taxis are equipped with the devices which can report their latest location information periodically or on demand. Currently, the fleet management application has been deployed in many cities of China. These applications are using General packet radio service (GPRS)/ Enhanced Data rates for GSM Evolution (EDGE) to report their information. In Beijing, there are around 80,000 taxis now, and more than
978-1-61284-671-2/11/$26.00 ©2011 IEEE
727
In the previous research paper [2], MTC devices shall enter detached state if they do not have data to transmit. To enter detached state also solves handover problems. In the previous research paper [3], the cellular communication architecture was modified to fit the MTC needs. It was an un-peer2peer communication architecture, which made the MTC devices less protocol stacks than normal. A facilitator need to be built for reconstructing the missed protocols and act as a virtual interface between the MTC server and the MTC devices. The architecture can reduce the overhead of the MTC data transmission. However, to modify the system architecture is not an easy issue in the mobile communication system. The security issue is not considered in this solution. In some cases in the proposed paper, MTC device does not need to do the mutual authentication procedure for data transmission. It would be a dangerous impact to the cellular network. Another previous research [4] proposed enhancements of the MAC protocol. It showed that the MAC protocol may further reduced. The MTC devices may send data with the preambles or just send data after uplink (UL) grant. However, the research did not consider the security issue and was also a dangerous modification to the cellular network. There is an obvious issue where congestion in the signalling network is caused by a high number of MTC devices trying almost simultaneously to setup their connections after completing the contention procedure. In other words, every MTC device is requested to start authentication phase and data radio bearer establishment phase before transmitting MTC data to MTC server and after the RACH procedure is done. For the MTC devices with small data transmissions feature, the signalling overhead of preliminary procedures prior to small data transmission from MTC device to MTC server should be reduced or avoided. This paper proposes an efficient MTC data transmission procedure to minimize the overhead and latency incurred from MTC communications. The paper proposed a scheme that the MTC devices can send data to MTC server in the authentication procedure. This scheme can reduce the overhead of MTC and also considers the security issue. II.
FAST MTC DATA TRANSMITION PROCEDURE
A. Standard Procedure During the network attachment phase, an MTC device contends the channel resource following the received RACH information. Once an MTC device gets the response from evolved universal terrestrial radio access network (EUTRAN), it starts the authentication phase. The MTC device and mobile management entity (MME) will exchange some specific parameters in order to accomplish the authentication process. If the authentication of MTC device has passed, MTC device is able to access the network via establishing data radio bearer(s). The complicated time sequence of an
728
Figure 1. MTC data transmission procedures: (a) Standard sequence. (b) Efficient data transmission scheme MTC device from the initial state to get the permission of sending data to MTC server is depicted in Fig. 1 (a). It is evident that the signalling overhead incurred from MTC device with small data transmission feature will impact the system performance. Furthermore, the battery powered MTC device (such as sensors or meters) would keep power off all the time unless it desires to send data to the MTC server. To maximize the system performance and the lifetime of MTC device, it is desired to design an efficient data transmission procedure to minimize the communication period by simplifying the time sequence of transmissions. For a large number of time-controlled MTC devices with small packet size and low duty cycle features, it is inefficient for the serving network to setup and maintain the connectivity. Therefore, this paper proposes the solution to deliver MTC data without establishing the data radio bearer (DRB) between MTC device and E-UTRAN.
MTC device
E-UTRAN
S-GW P-GW
MME
HSS
MTC Server
System Information Acquisition
RRC Connection Establishment
Random Access Procedure
Attach Request Initial UE Message Authentication Data Request (IMSI || SN identity || Network Type)
Authentication Request (RAND || AUTN) Authentication response (RES || )
Authentication Data Response (RAND || XRES || CK || IK || AUTN)
Authentication Request (RAND || AUTN || KSIASME) Cache MTCDATA
Authentication response (RES) DownLink NAS transport + Security Mode Command
Timeout
Indicate success of authentication and transmission
MTC Data Forwarding
Figure 2. Time sequence of efficient data transmission According to MTC service requirements defined in TS 102 689 document [5], the MTC system shall support authentication of MTC devices, provide mechanisms to assure integrity of transmitted information and support confidentiality for MTC services. Based on such requirement, the MTC device shall perform mutual authentication with serving network before data transmission and reception. If the MTC device skips mutual authentication procedures before data transmission and reception, there are some security issues impacting to the system. B. Efficient data transmission scheme In the mutual authentication procedures, authentication information is exchanged by the user equipment (UE) and MME. Since authentication information is exchanged between the UE and MME during the mutual authentication, the MTC device may embed data into the authentication information and send it to serving network. Once the authentication of MTC device has passed, the eNodeB already has the MTC data on hand and then it can quickly
729
forward data to the MTC server via core network. This procedure is shown in Fig 1 (b). Fig. 2 depicts the time sequence of efficient data transmission scheme. While an MTC devices trends to transmit data to the MTC server. It receives RACH information from the air interface. Then an MTC device contends the channel resource following the received RACH information. After contending success, the MTC device sends an attach request which involves International Mobile Subscriber Identity (IMSI) to E-UTRAN. E-UTRAN sends an UE initial message to MME. Then MME sends authentication data request to home subscriber server (HSS) to request the authentication of the MTC device. HSS returns an authentication data response which contains a random number (RAND), expected user response (XRES), cipher key (CK), integrity key (IK) and authentication token (AUTN) to MME. MME sends authentication request contains key set identifier (KSI), RAND and AUTH to EUTRAN. E-UTRAN sends another authentication request with RAND and AUTN to the MTC device. Then the MTC device sends an authentication response to E-UTRAN.
TABLE I.
LATENCY FROM RRC CONNECTION ESTABLISHMENT TO MTC DATA TRANSMISSION Type
Normal Procedure Effcient MTC Data Transmission Procedure TABLE II.
Figure 3. Encryption for MTCDATA In order to accomplish the MTC data transmission in authentication phase, the proposed efficient MTC data transmission procedure allows an MTC device to embed the MTC data (MTCDATA) into the authentication response message, which is sent from an MTC device to the MME. The MTCDATA could be encrypted by using an encryption algorithm with encryption key (such as KNASenc, KRRCenc and KUPenc) and also appended the message authentication code derived by applying an integrity protection algorithm with integrity key (such as KNASint and KRRCint)[6][7]. Because the authentication response message sent from MTC device to the MME is forwarded by the serving eNodeB, the serving eNodeB is able to extract the MTCDATA from the authentication response message and temporarily store it for further decryption and forwarding. Fig. 3 depicts the MTCDATA is embedded in authentication response message. After then, the remaining of authentication response message is sent to MME by eNodeB, as the standard does. If the MTC device passes the authentication, the MME sends a security mode command to the eNodeB. Once the eNodeB receives the command, it can decrypt and verify the MTCDATA by applying the same algorithms and keys. If the MTCDATA is correct, the eNodeB will forward it to MTC server automatically. In order to comply with legacy protocol, the eNodeB will send message authentication reject to the MTC device only when the authentication is failed[8]. In other words, the MTC device is aware of the success of authentication and data transmission when the timer T3416 expires. It is worthwhile to note that the timer T3416 is activated when the MTC device sends the authentication response message to MME. The default timeout value is 30s. Considering the power consumption issue, the timeout value for the MTC devices should be set as small as possible. III.
Steps 62
Latency (Best) 125 ms
Latency (Worst) 365 ms
18
45 ms
136 ms
SIMULATION PARAMETERS
Parameter Number of MTC devices MTC devices arrival distribution Interval of MTC data transmission Cell bandwidth PRACH Configuration Index Total number of preambles Maximum number of preamble transmission Number of UL grants per RAR Number of CCEs allocated for PDCCH Number of CCEs per PDCCH Preamble detection probability (in case of no collision)
ra-ResponseWindowSize mac-ContentionResolutionTimer Backoff Indicator HARQ retransmission probability for Msg3 and Msg4 (non-adaptive HARQ) Maximum number of HARQ TX for Msg3 and Msg4 (non-adaptive HARQ)
Setting 5000, 10000, 30000 Beta distribution 10 seconds 5 MHz 6 54 10 3 16 4
1−
1 ei
where i indicates the i-th preamble transmission 5 subframes 48 subframes 20ms 10% 5
B. Simulation Parameters Table 1 shows the latency time from RRC connection establishment to MTC data transmission. While an MTC device need to upload MTC data to the server, it has to perform 62 steps and spends up to 365 ms to finish the transmission in normal procedure. However, it just has to perform 18 steps and spends up to 136 ms to finish the transmission in Efficient MTC data transmission procedure. The simulation uses the parameters in Table 2. The simulation parameters were discussed in 3GPP meetings and noted in the TR. C. Simulation Results Fig. 4 shows the simulation result. The MTC devices which use the efficient MTC data transmission scheme have much less latency than the MTC devices which use the procedure defined in specification. While the MTC devices use the standard procedure to transmit MTC data, it spends 150 ms to 450 ms finishing the
SIMULATION
A. Simulation Assumptions 3GPP meetings define the number of MTC devices can be set to 5000, 10000 and 30000. Every MTC device must upload data every 10 seconds. We simulate two different procedures to transmit MTCDATA to the MTC server and compare the results.
730
packet size and low duty cycle. In addition, the establishment and maintenance of DRB for such MTC devices should be avoided if possible. This paper has proposed an efficiencyimprovement procedure to improve LTE network in machine type communication. This scheme leads to an efficient cellular network for MTC communication in LTE system. V.
ACKNOWLEDGEMENT
This work was supported in part by grants from the M2M System Simulation and Performance Analysis Project of Institute for Information Industry (III) and sponsored by MOEA, Taiwan, ROC. REFERENCES [1] [2]
whole procedure. However, it spends 75 ms to 150 ms finishing data exchange by efficient fast data transmission scheme. Comparing in best case and worst case, it spends Figure 4. Simulation results
[3]
[4]
double to triple time finishing data transmission procedure respectively. It means that the cellular network which implements efficient data transmission scheme has more radio resources to serve more devices than it uses standard procedure. IV.
[5] [6]
CONCLUSION
[7]
In this paper, the time sequence analysis shows that the legacy attach procedure is quite inefficient for the timecontrolled MTC devices, which have the features of small
[8]
731
3GPP TR 37.868, Study on RAN Improvements for Machine-type Communications Sheu, S-T., Lee, Y-T., and Lu S. “Load Analysis for MTC Devices in Idle Mode or Detached State.”, in Proc of ICS 2010, 16-18 Dec. 2010, pp. 424-428 Chen, Y., and Yang, Y. "Cellular based machine to machine communication with un-peer2peer protocol stack.", In Vehicular Technology Conference Fall (VTC 2009-Fall), 2009 IEEE 70th, 20-23 Sept. 2009 , pp. 1-5 Chen, Y., and Wang, W. " Machine-to-Machine Communication in LTE-A.", In Vehicular Technology Conference Fall (VTC 2010-Fall), 2010 IEEE 72nd, 6-9 Sept. 2010 , pp. 1-4 ETSI TS 102 689, “Machine-to-Machine communications (M2M); M2M service requirements” 3GPP TS 33.401, “3GPP System Architecture Evolution (SAE); Security architecture” 3GPP TS 24.301, “Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)” 3GPP TS 33.102, “3G Security; Security architecture”
