Problem Statement 2 - Problem Statements - Network Architecture and Problem Statement

Chapter 3: Network Architecture and Problem Statement

3.3 Problem Statements

3.3.2 Problem Statement 2

- power saving of M2M devices forming capillary network - efficient bulk transfer of data via broadcast, multicast - bandwidth aggregation

- possible gateway can assist in self-organization of M2M devices

3.3 Problem Statements

As shown in figure 7, there are two different networks involved in the communication between M2M devices and M2M server. These two networks i.e. WiFi or ZigBee capillary network and LTE network have their own power saving mechanisms and are originally designed to operate independently. For example, in case of WLAN, IEEE standard 802.11 specifies WLAN stations behavior in power save mode of operation. Similarly for LTE devices, 3GPP specifies DRX/DTX based mechanisms for power saving. Below problem statements are derived based on this fundamental observation.

3.3.1 Problem statement 1

To Synchronize WLAN and ZigBee M2M devices power saving cycles with that of M2M gateway LTE interface power save cycles while considering extended DRX cycle duration, periodic and non-periodic Tracking Area Updates (TAU). This requires design of an energy efficient network solution that enables longer doze mode and optimal mode-switch-over by WiFi or ZigBee M2M devices.

3.3.2 Problem Statement 2

To enable extended DRX cycle duration of M2M Gateway’s LTE interface. This maximizes

power saving without incurring network re-entry. From the problem statement 1 above, the overall impact of maximizing idle mode duration of LTE interface is that M2M devices are able to go into sleep mode for longer duration, and reducing the periodic waking-up to check any data packet destined to itself. For this, as explained in later sections, inter-TAU duration is also used since TAU duration is often in several minutes to hours.

Chapter 4 Power Saving Solution for M2M Devices

4.1 Proposed Power Saving Design for M2M Devices

Figure 8 shows proposed energy efficient network design that helps to significantly improve capillary network M2M device power saving. This lets M2M devices to enable longer doze mode and optimal mode-switch-over by synchronizing M2M devices operation modes with M2M gateway’s LTE interface power save cycle considering extended DRX cycles, periodic as well as non-periodic Tracking Area Update. Below subsections provide algorithm details for the scenario where these M2M devices support WiFi and ZigBee interfaces. In this figure, M2M gateway’s LTE interface may go to Idle mode, use DRX in connected mode, remain in active mode or may go to disconnected state. Idle mode duration may be based on extended DRX mechanism and/or inter-TAU interval, as explained in more detail in the below solutions subsections. This implies that LTE idle mode duration can range from a few milliseconds to minutes or even in hours. On the other hand WiFi Access Point (AP), for example, broadcasts periodic beacon messages usually configured to be in milliseconds. Accordingly, WiFi Stations needs to wake-up and listen to these beacon messages. However, in scenarios where LTE interface is in extended Idle mode or if there is agreement, based on message exchanges, between M2M gateway and M2M server to send

any downlink data only during fixed duration immediately after TAU message, the WiFi STAs need not frequently wake-up to determine if AP has any buffered data to it or not. In other words, in these scenarios, STAs need to only wake-up when LTE interface is in active mode and ready to receive or send data to/from LTE network/M2M Server and capillary network.

Figure 8 Power Saving Design for M2M devices

4.2 Power Saving Scheme for WiFi Capable M2M devices

Solution for WiFi capable M2M devices is a specific case which follows the general design explained in section 4.1. Figure 9 shows the synchronization mechanism for Power saving by WiFi capable M2M devices/Station (STA). It also addresses the complex scenario where at any point of time some STA may be in sleep mode while others may be in awake or active mode. LTE-M2M gateway calculates Listen Interval and Target Beacon Transmission Time (TBTT), as shown in figure 8, and includes them in the broadcast message named W-Bcn.

Listen Interval or LI indicates to how often a STA in power save mode wakes-up to listen to beacon management frame. Beacon Interval or BI represents the number of Time Units (TUs) between Target Beacon Transmission Time (TBTT). LI is expressed in the units of Beacon

backward compatible. This “vendor specific” option is already available in the IEEE Standard 802.11 defined beacon packet format.

STA 2 in figure 9 is originally supposed to wake-up after every 3rd LI, however after receiving W-Bcn with new timer value, it changes its LI and thus can be in doze/sleep mode for longer duration. In case of STA 1, it is already in sleep mode when W-Bcn is sent by the gateway thus it wakes up at the usual time i.e. after LI = 5. Next time M2M gateway may send unicast packet to STA 1.

TB TT : Target B eacon Transm ission Tim e B I: B eacon Interval

LI: Listen Interval PSM : Pow er Save M ode

P-TA U : Periodic Tracking A rea U pdate (TA U ) W -B cn: B eacon w ith a vender-specific IE

n+2 n+8

Figure 9 WiFi power save cycle synchronization

Figure 10 shows the algorithm implemented at the gateway in order to support power saving by WiFi capable M2M devices. The algorithm allows gateway to calculate Listen Interval and TBTT under different scenarios. The calculated values are then sent to M2M devices over gateway’s WiFi interface.

Figure 10 Algorithm for updating WiFi Parameters

4.3 Power Saving Scheme for ZigBee Capable M2M devices

Solution for ZigBee capable M2M devices is another specific case which follows the general design explained in section 4.1. The solution for ZigBee is divided into two parts: one for non-beacon mode of operation and second for beacon mode. Both approaches are based on proposed design concept, as shown in figure 8. For the beacon mode, main idea is to enable appropriate “Listen Interval” and inactive duration calculation for forbidden interval as shown in figure 11. If the ZigBee device is in active state, we adjust super-frame duration to match allowed duration or data-exchange duration of the M2M gateway LTE interface. On the other hand if the ZigBee device is in the power saving state then we set the super-frame duration to shorter interval and Beacon Interval set to longer interval. These can be done at the network layer. We use NLME-NETWORK-FORMATION.request and MLME-START.request as shown in figure 12.

Figure 11 Beacon Interval and superframe reconfiguration in Zigbee

Figure 12 Super-frame reconfiguration

For the non-beacon mode, main ideas are to reduce periodic polling and aligning the communication window. Figure 13 shows procedures of state change of M2M devices from active state to power saving state. From implementation perspective, it starts with 3GPP module, which informs the controller unit about the inter-TAU interval or the active duration

S D = a B a se S u p e rfra m e D u ra tio n * 2S O _ A ctiv e

S u p e rfra m e C o n fig u ra tio n in A c tiv e sta te

A c tiv e P e rio d

B I = a B a se S u p e rfra m e D u ra tio n * 2B O _ A ctiv e

A c tiv e

P e rio d In a c tiv e P e rio d

S u p e rfra m e C o n fig u ra tio n in P S sta te

S D = a B a se S u p e rfra m e D u ra tio n * 2^{S O _ P S}

B I = a B a se S u p e rfra m e D u ra tio n * 2^{B O _ P S}

during which data may be exchanged and thus it indicates allowed time or granted time interval. Controller unit in-turn triggers ZigBee module of the M2M gateway, which in turn sends appropriate notification to M2M devices in the Capillary network. Thus M2M devices learn that during this inter-TAU time, there is no data expected to arrive from network/server via the gateway device.

Figure 13 Procedure for active to power save state change

4.4 Power Saving Schemes on LTE Interface

4.4.1 Extended DRX: Idle mode and connected mode

Extended DRX solution is proposed to work between M2M Gateway’s LTE interface and LTE network. It also considers scenarios where more than one devices with LTE interface are deployed for M2M applications. These devices could be part of a group subscription and Set curRate to the Rate of Power Save State

applications with predictable communication cycles such as many of the existing Machine to Machine (M2M) communication. It provides system and method for enhanced DRX operation. It also provides mechanism for dynamically allocating communication-window within the allowed “Grant time-interval” to each M2M device possibly with a group deployment. The solution can be summarized as:

- Hand-shake protocol between M2M gateway and LTE core network to configure and update various DRX parameters, time-duration – requiring changes in LTE NAS protocol. Changes required by this method are kept flexible and simple to allow interoperable and standardization possibilities.

- A set of message exchanges between M2M gateway and other UEs, running M2M applications, to dynamically configure new allocated individual communication window – requiring changes in local-communication protocols i.e. WiFi or ZigBee.

The solution is designed with due consideration of the two main properties of the deployments – one, a significantly large number of M2M devices and second, ever increasing need for devices to conserve battery power. It also exploits the availability of UE with possibly group based subscription for such deployments. As shown in figure 14, the solution is divided into four steps, as explained below:

1) The network dynamically adjusts devices allowed-time Interval start time, considering inputs from HSS on the group subscription details, M2M server and total allowed duration. Allowed-time interval is when the device is allowed to send or receive data traffic, based on traffic condition, subscription-option, etc.

2) M2M Gateway interacts with LTE core network, MME, SGW in order to learn the start time as well as overall duration of newly adjusted allowed-time interval.

3) M2M Gateway calculates individual M2M device communication time-slot. It also calculates number of DRX long and short cycles as well as duration of each of the DRX long and DRX short cycles. The long DRX cycle can be as small as 10 ms and up to several minutes. Short DRX cycle can be as small as 2ms and as large as 640ms.

These values are calculated such that the duration and number of long DRX cycle and short DRX cycles respectively are maximum possible, considering the calculated allowed time-duration.

4) Configured DRX parameters along with individual device communication time-slots are sent to each device. This can be done using non-3GPP interface protocol such as extending IEEE 802.11 or 802.15.4 MAC protocols.

Figure 14 Extended DRX

4.4.2 Inter-TAU Duration

The main point here is that downlink data transfer is only possible during an allowed time period immediately after the LTE-M2M gateway performed a TAU/RAU procedure. During that allowed time period the M2M server can communicate with the LTE-M2M gateway.

After the allowed time period the LTE-M2M gateway may switch off the receiver and communication is not possible. After the LTE-M2M gateway performs a TAU/RAU procedure, it may stay in power-up mode and inform the M2M Server that it is available for communication so that the M2M Server can forward all buffered traffic to the device. The M2M gateway may be configured not to inform the M2M Server after every TAU/RAU procedure and thus reduce the frequency of allowed time periods. How often an allowed time period occurs is thus configurable. For example, the M2M gateway may be configured to stay in power-up mode after a TAU/RAU and inform the M2M Server about its availability only between 1am – 5am every day. The M2M Server buffers downlink traffic for the M2M gateway until it informs the server that it is ready for M2M communications.

4.5 M2M Gateway Implementation-Design

Figure 15 shows different components of the LTE-M2M gateway. The shaded part shows enhancements of the modules required in order to improve power saving in M2M devices. As shown in the figure, M2M gateway includes non-3GPP interface such as IEEE 802.11 or WLAN, IEEE 802.15.4 or ZigBee and NFC. The figure shows non-3GPP network interface controller (NIC) module for communicating with the M2M devices, a 3GPP NIC module for communicating with the LTE network, and a core module coupled to the non-3GPP module and the 3GPP module. The non-3GPP module and M2M controller unit and 3GPP interface implements the proposed algorithm. The core module includes an M2M controller unit, which further includes a database and a controller. The controller stores information regarding the M2M devices in the database and retrieves information regarding the M2M devices from the database. The core module also includes a memory manager to manage memory usage by the database, and a communication scheduler to schedule communications

between the M2M gateway and the M2M devices and communications between the M2M gateway and the 3GPP network.

The 3GPP LTE module includes, apart from a standard LTE protocol stack, an M2M enable unit which implements hand-shake protocol to enable extended DRX cycle as discussed in the previous section. Also, for example, the M2M enable unit may send, periodically or non-periodically, updated information regarding the M2M devices to the LTE network using Tracking Area Update messages. This is used to update MME database of the LTE network with the initial or updated information regarding the M2M devices which can then be used to monitor and control these devices via M2M gateway.

Figure 15 M2M Gateway System Design

Chapter 5 Modeling

5.1 Simulation Environment

We used OPNET Modeler simulator [12]. Figure 16 and figure 20 shows network topologies we implemented in OPNET simulation environment for analyzing our power saving solutions. In this topology, an M2M server is connected to the LTE network. An LTE UE with an additional Ethernet interface is connected to a WiFi AP and represents M2M gateway, when considered along with other required functionalities. The M2M device equipped with WiFi interface communicates with the M2M server through the WiFi AP.

During each simulation run, the M2M user sends or requests data to or from the M2M server which in turn communicates with M2M devices. The M2M gateway, which implements proposed functionalities, buffers and queues any requests in case the M2M device is in sleep state. After wake-up, M2M device initiates PS-Poll mechanism, in case WiFi AP indicates any buffered data for it using TIM bit in the beacon message. After retrieving all the buffered packets, it may decide to go back to sleep mode again.

Figure 16 Network Topology and Simulation set-up

5.2 Simulation Results and Analysis 5.2.1 Extended DRX in Connected mode

For the extended DRX power saving evaluation, simulation parameters and their values are listed in below table 1 and table 2. We used different traffic models for evaluation. In figure 17, small data packets of fixed size (100 bytes) arriving at constant intervals of 30 seconds (blue graph) and 30 minutes (purple graph) are considered. While in figure 18, exponential-interval traffic with mean arrival time of 30 seconds (blue graph), 5 minutes (yellow graph) and 30 minutes (purple graph) are considered. For simplicity, we disabled the short DRX cycle, and only adopt the long DRX cycle. For the configured values, as shown in Table 1 and Table 2, in Normal state UE’s transmitter and receiver are ON, in Active state UE’s receiver is ON and it can receive paging messages on PDCCH, and in sleep state UE’s transmitter and receiver are Off.

Table 1: Attributes for Extended DRX simulation Operating Power in Normal State (mW) 100 mW

Operating Power in Active State (mW) 40 mW Operating Power in Sleep State (mW) 10 mW

Table 2: Attributes for connected mode Simulation On Duration Timer (Subframes) 50

Short DRX Cycle Timer (Subframes) 160

Use Short DRX Cycle Disabled

Inactivity Timer (Subframes) 100 Retransmission Timer (Subframes) 4 Long DRX Cycle Multiplication Factor 1

Wake-up Policy for Uplink Data Wake Up Immediately

Pkt Inter-arrival tim e 30 m in

Figure 17 UE power consumptions with different DRX cycles and traffic condition

Figure 18 UE power consumptions with different DRX cycles and traffic condition

From the simulation results shown in figure 17 and figure 18 we observe that by increasing DRX cycle duration from 0.08 seconds to 40 seconds, power consumption is reduced by about 60% reduction. It is noted that 3GPP specification TS 36.331 [16], recommends longDRX minimum value of 0.01 seconds and maximum of 2.56 seconds. Also, it

recommends shortDRX minimum value of 0.002 seconds and maximum of 0.64 seconds.

However, this specification is for usual UE devices and is not optimized for M2M devices.

These values are recommended considering various factors such as signalling overhead, delay, applications, user requirements and lack of reliable ways to predict traffic patterns.

Considering the power saving advantages in M2M devices by increasing DRX cycles, 3GPP as part of Release-12, is currently discussing different approaches and may specify one or more solutions sometimes by early 2014.

5.2.2 Extended DRX in Idle mode

Figure 19 shows power consumption with respect to different DRX cycle and traffic conditions. The curve with the blue line considers small data packets of fixed size (100 bytes) arriving at constant intervals of 30 seconds. While in case of pink curve packets inter-arrival time is 300 seconds. Table 1 and Table 3 show various configured values for the purposes of Idle mode simulation results.

Table 3 Attributes for Idle Mode Simulation On Duration Timers (Subframes) 50

Short DRX Cycle Timer (Subframes) 64

Use Short DRX Cycle Disabled

Inactivity Timer (Subframes) 100 Retransmission Timers (Subframes) 4 Long DRX Cycle Multiplication Factor 1

Wake-up Policy for Uplink Data Wake Up Immediately

0 5 10 15 20 25 30

0 20000 40000 60000 80000 100000

DRX Cycle Timer (Subframes)

Total Power Consumption (mWh)

Figure 19 UE power consumptions with different DRX cycles and traffic condition

5.2.3 Capillary network M2M Device Power saving

As shown in figure 20, we create a simulation environment using the OPNET simulator in which an M2M server was connected to the LTE network and an UE with an additional Ethernet interface was connected to a WiFi AP. The M2M device which is equipped with WiFi interface communicates with the M2M server through the WiFi AP. Note that the UE and the WiFi AP are collectively treated as an M2M gateway. During a simulation run, the M2M user requests data from the M2M server which then conducts small data transmission with the M2M device. The M2M gateway enabling the proposed method queues requests until the M2M device wakes up at the beginning of next power save cycle. While waking up, the M2M device deals with all the requests queued in the M2M gateway and goes back to idle mode afterwards. The simulation time was set to 3 days in each simulation run. Among the simulation runs, some mandatory parameters were varied. The simulation environment settings & parameters are listed in Table 4, where values of SDT request rates mean that the SDT request inter-arrival times are exponentially distributed (i.e., a Poison process) with mean

value 30 seconds.

Figure 20 Network Topology for Simulate Purposes

Figure 21 shows the cumulative power consumption over time with different small data transmission request rates. The M2M device operating in a traditional power saving scheme was set listen interval to 10, 110, and 300, respectively, and denoted as “WiFi PS.” We observe that the M2M device with a large listen interval wakes up less frequently, saving more power than those with smaller intervals. On the other hand, the M2M device with the proposed method, which is denoted as “M2M PS”, does not wake up during Idle intervals, consuming less power than WiFi PS.

d = 3 Hrs d = 9 Hrs

Figure 21 Total Allowed Time Required vs. number of M2M Devices

Table 4: Parameters for WiFi Simulation Scenario

Parameter (Notation) Value(s)

WiFi AP Beacon Interval (dBI) 0.5 seconds

Periodical TAU Interval (power save cycle) (d) 10800, 32400 seconds WiFi STA (M2M device) Listen Interval (LI) 10, 110, 300 BIs Small Data Transmission (SDT) Request Rate (r)

exponential(30) seconds Tx Power Consumption at MTC Device (eTx) 330 mA

Rx Power Consumption at MTC Device (eRx) 280 mA Active Mode Power Consumption at MTC Device (eA) 178 mA Idle Mode Power Consumption at MTC Device (eI) 9 mA

Simulation Time 3 days

Chapter 6: Conclusion and Future Work

Motivated by the tremendous opportunities along with several technical challenges imposed by Machine to Machine Communication, we selected this as our topic of research. After investigating several M2M related technical issues and observing that power saving is a very significant constraint in these, often small and wireless M2M devices, we decided to take this

在文檔中一個用於長期演進技術以降低WiFi/ZigBee機器設備電耗的機對機通訊閘道 (頁 23-0)