WO2012173349A2 - Method and apparatus for transmitting data in power saving mode in wireless communication system - Google Patents

Abstract

A method and an apparatus for transmitting data in a wireless communication system are provided. A machine-to-machine (M2M) apparatus in a deregistration with context retention (DCR) mode generates an uplink (UL) data having a size which is smaller than 140 bytes, transmits a ranging request message (AAI-RNG-REQ) including the UL data to a base station, and receives from the base station a ranging response message (AAI-RNG-RSP) as a response to the ranging request message. The ranging request message comprises a ranging purpose indication field for indicating a location update for transmitting the UL data in the DCR mode. Also, the ranging response message comprises a location update response field for indicating a location update success in transmitting the UL data as a response to the ranging purpose indication field.

Description

Method and apparatus for data transmission in power saving mode in wireless communication system

The present invention relates to wireless communication, and more particularly, to a data transmission method and apparatus in a power saving mode in a wireless communication system.

The Institute of Electrical and Electronics Engineers (IEEE) 802.16e standard is the sixth standard for international mobile telecommunications (IMT-2000) in the ITU-radiocommunication sector (ITU-R) under the International Telecommunication Union (ITU) in 2007. It was adopted under the name OFDMA TDD '. ITU-R is preparing the IMT-advanced system as the next generation 4G mobile communication standard after IMT-2000. The IEEE 802.16 working group (WG) decided to pursue the IEEE 802.16m project with the goal of drafting an amendment standard of the existing IEEE 802.16e as a standard for the IMT-advanced system at the end of 2006. As can be seen from the above objectives, the IEEE 802.16m standard implies two aspects: past continuity of modification of the IEEE 802.16e standard and future continuity of the specification for next generation IMT-advanced systems. Therefore, the IEEE 802.16m standard is required to satisfy all the advanced requirements for the IMT-advanced system while maintaining compatibility with the mobile WiMAX system based on the IEEE 802.16e standard.

The IEEE 802.16p specification, which is based on the IEEE 802.16e standard and the IEEE 802.16m standard and optimized for machine-to-machine communication (M2M), is being developed. M2M communication may be defined as an information exchange performed between a subscriber station and a server or between subscriber stations in a core network without any interaction with a person. . A device that performs M2M communication may be referred to as an M2M device. The IEEE 802.16p specification is the minimum change in orthogonal frequency division multiple access (OFDMA) physical layer (PHY) within the enhancement of medium access control (MAC) and licensed bands of the IEEE 802.16 specification. Is under discussion. As the IEEE 802.16p specification is discussed, wide area wireless coverage is required within the licensed band, and the scope of application of automated M2M communications for the purpose of observation and control is wide. Can lose.

Many M2M applications have significantly different requirements for network access, typically human-initiated or human-controlled network access. Require. M2M applications include vehicular telematics for vehicles, healthcare monitoring of bio-sensors, remote maintenance and control, smart metering, and consumer devices Automated services, etc. M2M application requirements include very lower power consumption, large numbers of devices, short bursts, etc. transmission, device tampering detection and reporting, improved device authentication, and the like.

According to the characteristics of the M2M device, the operation of the M2M device may be optimized. For example, a power saving mode for entering each M2M device may be determined according to mobility, communication type, and scheduling type of the M2M device. Even in the power saving mode, there may be data to be transmitted by the base station or the M2M device. Whenever there is data to be sent, it may be inefficient to exit the power saving mode and perform network reentry.

Therefore, there is a need for a method for efficiently transmitting data in a power saving mode.

An object of the present invention is to provide a data transmission method and apparatus in a power saving mode in a wireless communication system. The present invention provides a method of transmitting uplink data while maintaining a DCR mode when an M2M device in a delegation with context retention (DCR) mode transmits uplink data.

In one aspect, there is provided a data transmission method by a machine-to-machine (M2M) device in a deregistration with context retention (DCR) mode in a wireless communication system. The data transmission method generates uplink (UL) data having a size smaller than 140 bytes, and transmits a ranging request message (AAI-RNG-REQ) including the UL data to a base station. Receiving a ranging response message (AAI-RNG-RSP) in response to the ranging request message from a base station, wherein the ranging request message includes a location update for transmission of the UL data in the DCR mode. and a ranging purpose indication field indicating a update, wherein the ranging response message indicates a successful location update for transmission of the UL data in response to the ranging purpose indication field. It includes a location update response field.

The ranging request message may further include a context retention identifier (CRID) which is an M2M device identifier currently assigned to the M2M device in the DCR mode.

The ranging response message may further include a traffic indication field indicating whether there is downlink (DL) data to be transmitted from the base station to the M2M device in the DCR mode.

The data transmission method may further include terminating the DCR mode by performing network reentry to the base station and receiving the DL data from the base station.

The value of the traffic indication field is 1, and the traffic indication field may indicate that there is DL data to be transmitted by the base station to the M2M device.

The ranging response message may further include a DL traffic start time field indicating a least significant bit (LSB) 8 bits of a frame number at which the base station starts to transmit the DL data. Can be.

The data transmission method may further include receiving the DL data from the base station without terminating the DCR mode.

The last DL data of the DL data transmitted by the base station may include a multicast traffic end extended header (MTEEH) or a traffic end extended header (TEEH).

The DCR mode may be determined based on an M2M power saving class negotiated with the base station at the time of network entry.

The data transmission method may further include receiving a CRID of the M2M device from the base station upon entering the network.

In another aspect, a machine-to-machine (M2M) device is provided that is in a derivative with context retention (DCR) mode in a wireless communication system. The M2M device includes a radio frequency (RF) unit for transmitting or receiving a radio signal, and a processor connected to the RF unit, wherein the processor is uplink (UL) data having a size smaller than 140 bytes. Generate a message, and transmit a ranging request message (AAI-RNG-REQ) including the UL data to a base station, and a ranging response message (AAI-RNG-RSP) in response to the ranging request message from the base station. The ranging request message includes a ranging purpose indication field indicating a location update for transmitting the UL data in the DCR mode, and the ranging response message includes: a ranging purpose indication field; The message is a location update response indicating a success of a location update for transmission of the UL data in response to the ranging purpose indication field. se) contains fields.

In the DCR mode, UL data can be efficiently transmitted to the base station without performing network re-entry.

1 illustrates a wireless communication system.

2 illustrates a basic M2M service system structure of IEEE 802.16 supporting machine-to-machine (M2M) communication.

3 illustrates an advanced M2M service system structure of IEEE 802.16 supporting M2M communication.

4 shows an example of a frame structure of IEEE 802.16m.

5 shows an example of the operation of the M2M device entering the DCR mode.

6 shows an embodiment of the proposed multicast traffic reception method.

7 shows another embodiment of the proposed multicast traffic reception method.

8 shows another embodiment of the proposed multicast traffic reception method.

9 shows another embodiment of the proposed multicast traffic reception method.

10 shows another embodiment of the proposed multicast traffic reception method.

11 shows another embodiment of the proposed multicast traffic reception method.

12 shows an example of the operation of the M2M device entering the idle mode.

13 shows an embodiment of the proposed data transmission method.

14 shows another embodiment of the proposed data transmission method.

15 shows another embodiment of the proposed data transmission method.

16 is a block diagram of a wireless communication system in which an embodiment of the present invention is implemented.

The following techniques include code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), single carrier frequency division multiple access (SC-FDMA), and the like. It can be used in various wireless communication systems. CDMA may be implemented by a radio technology such as universal terrestrial radio access (UTRA) or CDMA2000. TDMA may be implemented with wireless technologies such as global system for mobile communications (GSM) / general packet radio service (GPRS) / enhanced data rates for GSM evolution (EDGE). OFDMA may be implemented in a wireless technology such as IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, evolved UTRA (E-UTRA). IEEE 802.16m is an evolution of IEEE 802.16e and provides backward compatibility with systems based on IEEE 802.16e. UTRA is part of a universal mobile telecommunications system (UMTS). 3rd generation partnership project (3GPP) long term evolution (LTE) is part of evolved UMTS (E-UMTS) using evolved-UMTS terrestrial radio access (E-UTRA), which employs OFDMA in downlink and SC in uplink -FDMA is adopted. LTE-A (advanced) is the evolution of 3GPP LTE.

For clarity, the following description focuses on IEEE 802.16m, but the technical spirit of the present invention is not limited thereto.

1 illustrates a wireless communication system.

The wireless communication system 10 includes at least one base station (BS) 11. Each base station 11 provides a communication service for a particular geographic area (generally called a cell) 15a, 15b, 15c. The cell can in turn be divided into a number of regions (called sectors). A user equipment (UE) 12 may be fixed or mobile, and may include a mobile station (MS), a mobile terminal (MS), a user terminal (UT), a subscriber station (SS), a wireless device, and a PDA (PDA). It may be called other terms such as personal digital assistant, wireless modem, handheld device, etc. Base station 11 generally refers to a fixed station that communicates with terminal 12, It may be called other terms such as an evolved-NodeB (eNB), a base transceiver system (BTS), an access point, and the like.

The UE belongs to one cell, and the cell to which the UE belongs is called a serving cell. A base station that provides a communication service for a serving cell is called a serving BS. Since the wireless communication system is a cellular system, there are other cells adjacent to the serving cell. Another cell adjacent to the serving cell is called a neighbor cell. A base station that provides communication service for a neighbor cell is called a neighbor BS. The serving cell and the neighbor cell are relatively determined based on the terminal.

This technique can be used for downlink or uplink. In general, downlink means communication from the base station 11 to the terminal 12, and uplink means communication from the terminal 12 to the base station 11. In downlink, the transmitter may be part of the base station 11 and the receiver may be part of the terminal 12. In uplink, the transmitter may be part of the terminal 12 and the receiver may be part of the base station 11.

2 illustrates a basic M2M service system structure of IEEE 802.16 supporting machine-to-machine (M2M) communication.

The basic M2M service system architecture 20 may include a mobile network operator (MNO) 21, an M2M service consumer 24, at least one IEEE 802.16 M2M device (hereinafter, 802.16 M2M device, 28), at least One non-IEEE 802.16 M2M device 29 is included. The MNO 21 includes an access service network (ASN) and a connectivity service network (CSN). The 802.16 M2M device 28 is an IEEE 802.16 terminal with M2M functionality. The M2M server 23 is an entity that communicates with one or more 802.16 M2M devices 28. The M2M server 23 has an interface to which the M2M service consumer 24 can connect. The M2M service consumer 24 is a user of the M2M service. The M2M server 23 may be inside or outside a connectivity service network (CSN) and may provide specific M2M services to one or more 802.16 M2M devices 28. The ASN may include an IEEE 802.16 base station 22. The M2M application is operated based on the 802.16 M2M device 28 and the M2M server 23.

The basic M2M service system architecture 20 supports two kinds of M2M communication: M2M communication between one or more 802.16 M2M devices and an M2M server or point-to-multipoint communication between 802.16 M2M devices and an IEEE 802.16 base station. do. The basic M2M service system architecture of FIG. 2 allows an 802.16 M2M device to act as an aggregation point for a non-IEEE 802.16 M2M device. Non-IEEE 802.16 M2M devices use a wireless interface different from IEEE 802.16, such as IEEE 802.11, IEEE 802.15 or PLC. At this time, the change of the air interface of the non-IEEE 802.16 M2M device to IEEE 802.16 is not allowed.

3 illustrates an advanced M2M service system structure of IEEE 802.16 supporting M2M communication.

Similarly, in the enhanced M2M service system structure, an 802.16 M2M device may operate as an aggregation point for a non-IEEE 802.16 M2M device and may also operate as an aggregation point for an 802.16 M2M device. In this case, the wireless interface may be changed to IEEE 802.16 in order to perform the aggregation function for the 802.16 M2M device and the non-802.16 M2M device. In addition, an enhanced M2M service system architecture may support peer-to-peer (P2P) connectivity between 802.16 M2M devices, where the P2P connection may be over IEEE 802.16 or over another wireless interface such as IEEE 802.11, IEEE 802.15 or PLC. Can be connected.

4 shows an example of a frame structure of IEEE 802.16m.

Referring to FIG. 4, a superframe (SF) includes a superframe header (SFH) and four frames (frames, F0, F1, F2, and F3). Each frame in the superframe may have the same length. The size of each superframe is 20ms and the size of each frame is illustrated as 5ms, but is not limited thereto. The length of the superframe, the number of frames included in the superframe, the number of subframes included in the frame, and the like may be variously changed. The number of subframes included in the frame may be variously changed according to channel bandwidth and length of a cyclic prefix (CP).

One frame includes a plurality of subframes (subframe, SF0, SF1, SF2, SF3, SF4, SF5, SF6, SF7). Each subframe may be used for uplink or downlink transmission. One subframe includes a plurality of orthogonal frequency division multiplexing (OFDM) symbols or an orthogonal frequency division multiple access (OFDMA) in a time domain, and includes a plurality of subcarriers in the frequency domain. do. The OFDM symbol is used to represent one symbol period, and may be called another name such as an OFDMA symbol or an SC-FDMA symbol according to a multiple access scheme. The subframe may be composed of 5, 6, 7 or 9 OFDMA symbols, but this is only an example and the number of OFDMA symbols included in the subframe is not limited. The number of OFDMA symbols included in the subframe may be variously changed according to the channel bandwidth and the length of the CP. A type of a subframe may be defined according to the number of OFDMA symbols included in the subframe. For example, the type-1 subframe may be defined to include 6 OFDMA symbols, the type-2 subframe includes 7 OFDMA symbols, the type-3 subframe includes 5 OFDMA symbols, and the type-4 subframe includes 9 OFDMA symbols. have. One frame may include subframes of the same type. Alternatively, one frame may include different types of subframes. That is, the number of OFDMA symbols included in each subframe in one frame may be the same or different. Alternatively, the number of OFDMA symbols of at least one subframe in one frame may be different from the number of OFDMA symbols of the remaining subframes in the frame.

A TDD scheme or a frequency division duplex (FDD) scheme may be applied to the frame. In the TDD scheme, each subframe is used for uplink transmission or downlink transmission at different times at the same frequency. That is, subframes in a frame of the TDD scheme are classified into an uplink subframe and a downlink subframe in the time domain. In the FDD scheme, each subframe is used for uplink transmission or downlink transmission at different frequencies at the same time. That is, subframes in the frame of the FDD scheme are divided into an uplink subframe and a downlink subframe in the frequency domain. Uplink transmission and downlink transmission occupy different frequency bands and may be simultaneously performed.

The SFH may carry essential system parameters and system configuration information. The SFH may be located in the first subframe in the superframe. SFH may occupy the last five OFDMA symbols of the first subframe. The superframe header may be classified into primary SFH (P-SFH) and secondary SFH (S-SFH; secondary-SFH). The P-SFH may be transmitted every superframe. Information transmitted to the S-SFH can be divided into three subpackets (S-SFH SP1, S-SFH SP2, S-SFH SP3). Each subpacket may be transmitted periodically with a different period. The importance of information transmitted through S-SFH SP1, S-SFH SP2, and S-SFH SP3 may be different from each other. S-SFH SP1 may be transmitted in the shortest period, and S-SFH SP3 may be transmitted in the longest period. S-SFH SP1 includes information on network re-entry, and the transmission period of S-SFH SP1 may be 40 ms. S-SFH SP2 includes information about initial network entry and network discovery, and the transmission period of S-SFH SP2 may be 80 ms. S-SFH SP3 includes the remaining important system information, and the transmission period of S-SFH SP3 may be either 160 ms or 320 ms.

One OFDMA symbol includes a plurality of subcarriers, and the number of subcarriers is determined according to the FFT size. There are several types of subcarriers. The types of subcarriers can be divided into data subcarriers for data transmission, pilot subcarriers for various measurements, guard bands and null carriers for DC carriers. Parameters that characterize an OFDMA symbol are BW, N _used , n, G, and the like. BW is the nominal channel bandwidth. N _used is the number of subcarriers _used (including DC subcarriers). n is a sampling factor. This parameter is combined with BW and N _used to determine subcarrier spacing and useful symbol time. G is the ratio of CP time to useful time.

Table 1 below shows OFDMA parameters. The OFDMA parameters of Table 1 may be equally used for the frame structure of 802.16e of FIG. 4.

Channel bandwidth, BW (MHz) 5 7 8.75 10 20 Sampling factor, n 28/25 8/7 8/7 28/25 28/25 Sampling frequency, F _s (MHz) 5.6 8 10 11.2 22.4 FFT size, N _FFT 512 1024 1024 1024 2048 Subcarrier spacing, Δf (kHz) 10.94 7.81 9.77 10.94 10.94 Useful symbol time, T _b (μs) 91.4 128 102.4 91.4 91.4 G = 1/8 Symbol time, T _s (μs) 102.857 144 115.2 102.857 102.857 FDD Number of
ODFMA symbols
per 5ms frame 48 34 43 48 48 Idle time (μs) 62.857 104 46.40 62.857 62.857 TDD Number of
ODFMA symbols
per 5ms frame 47 33 42 47 47 TTG + RTG (μs) 165.714 248 161.6 165.714 165.714 G = 1/16 Symbol time, T _s (μs) 97.143 136 108.8 97.143 97.143 FDD Number of
ODFMA symbols
per 5ms frame 51 36 45 51 51 Idle time (μs) 45.71 104 104 45.71 45.71 TDD Number of
ODFMA symbols
per 5ms frame 50 35 44 50 50 TTG + RTG (μs) 142.853 240 212.8 142.853 142.853 G = 1/4 Symbol time, T _s (μs) 114.286 160 128 114.286 114.286 FDD Number of
ODFMA symbols
per 5ms frame 43 31 39 43 43 Idle time (μs) 85.694 40 8 85.694 85.694 TDD Number of
ODFMA symbols
per 5ms frame 42 30 38 42 42 TTG + RTG (μs) 199.98 200 136 199.98 199.98 Number of Guard subcarriers Left 40 80 80 80 160 Right 39 79 79 79 159 Number of used subcarriers 433 865 865 865 1729 Number of PRU in type-1 subframe 24 48 48 48 96

In Table 1, N _FFT is the most small 2 ⁿ in the water is greater than N _used is the least power (Smallest power of two greater than N _used), sampling factor _{F s = floor (n · BW} / 8000) , and × 8000, Subcarrier spacing Δf = F _s / N _FFT , effective symbol time T _b = 1 / Δf, CP time T _g = G · T _b , OFDMA symbol time T _s = T _b + T _g , and sampling time is T _b / N _FFT .

According to the characteristics of the M2M device, the operation of the M2M device may be optimized. In particular, characteristics related to power saving of the M2M device may be defined according to the characteristics of the M2M device. For example, a power saving mode for entering each M2M device may be determined according to mobility, communication type, and scheduling type of the M2M device. The power saving mode that the M2M device may enter may be either an idle mode or a degistration with context retention (DCR) mode. The DCR mode indicates a mode in which the terminal is deregistered from the network, but the context of the terminal is kept in the network before the context maintenance timer expires. While the context persistence timer is valid, the network retains the information of the terminal so that the network reentry of the terminal can be processed quickly. In addition, a context retention identifier (CRID) assigned to each terminal may be used to identify the terminal in the DCR mode.

Table 2 shows an example of a power saving class and a power saving mode of the M2M device determined according to the mobility, communication type, and scheduling delay of the M2M device.

M2M power saving class properties Mobility
(mobility) Communication type Scheduling delay Power saving mode M2M PSC1 No Device originated only Tolerant DCR Mode M2M PSC2 No Network originated only tolerant Idle mode M2M PSC3 No Both originated Unbearable Idle mode M2M PSC4 Yes network originated only intolerant Idle mode M2M PSC5 Yes network originated only tolerant Idle mode M2M PSC6 Yes both originated intolerant Idle mode ... ... ... ... ... M2M PSCN Yes device originated only tolerant DCR Mode

Referring to Table 2, characteristics of mobility, communication type, and scheduling delay may be used to determine a power saving mode of the M2M device. Mobility indicates whether the M2M device is fixed or mobile. The communication type indicates the direction of data transmitted in the M2M communication. That is, when the communication type is 'device originated only', only traffic transmitted by the M2M device to the base station exists, and when the communication type is 'network originated only', only traffic transmitted by the base station to the M2M device exists. The scheduling delay indicates whether the transmitted traffic is sensitive to delay.

The M2M power saving class defined as shown in Table 2 may be predetermined between the M2M device and the base station or another network entity, or may be determined by negotiating with the M2M device and the base station at the network entry stage. The power saving mode of the M2M device may be determined based on the determined M2M power saving class.

Table 3 shows the functions required and unnecessary functions for each M2M device and the power saving mode of each M2M device based on the M2M power saving class defined by Table 2.

M2M power saving class Explanation M2M PSC 1 Only when there is no mobility and the M2M device has data to transmit Since data is transmitted, no paging and location update procedures are required.
Paging: not supported
Timer-based location update: not supported
Paging group-based location update: not supported
Paging Group ID, Paging Controller ID: Unassigned
Deregistration ID (idle mode identifier): not used
No paging cycles, paging offsets, paging listening intervals
Power Saving Mode: DCR Mode M2M PSC 2 Because of its mobility, no paging group-based location update is required. Since only the base station transmits data to the M2M device, a DL notification mechanism to the M2M device is required. Therefore, paging must be supported.
Paging: Supported
Timer-based location update: supported
Paging group-based location update: not supported
Paging Group ID: Unassigned, paging by M2M group ID (MGID)
Paging Controller ID: Assigned
Deregistration ID: Used (M2M DID (device ID))
Paging Cycle, Paging Offset Allocation
Power Saving Mode: Idle Mode M2M PSC 3 Because of its mobility, no paging group-based location update is required. Since the base station can transmit data to the M2M device, a DL notification mechanism to the M2M device is required. Therefore, paging must be supported.
Paging: Supported
Timer-based location update: supported
Paging group-based location update: not supported
Paging Group ID: Unassigned, paging by M2M group ID (MGID)
Paging Controller ID: Assigned
Deregistration ID: Used (M2M DID)
Paging Cycle, Paging Offset Allocation
Power Saving Mode: Idle Mode M2M PSC 4 Because of its mobility, a location update procedure is required. Since the base station can transmit data to the M2M device, a DL notification mechanism to the M2M device is required. Therefore, paging must be supported.
Paging: Supported
Timer-based location update: supported
Paging Group-Based Location Updates: Supported
Paging Group ID, Paging Controller ID: Assigned
Deregistration ID: Used (M2M DID)
Paging Cycle, Paging Offset Allocation
Power Saving Mode: Idle Mode … … M2M PSC N Only when there is no mobility and the M2M device has data to transmit Since data is sent, no paging and location update procedures are required.
Paging: not supported
Timer-based location update: not supported
Paging group-based location update: not supported
Paging Group ID, Paging Controller ID: Unassigned
Deregistration ID (idle mode identifier): not used
Paging Cycle, Paging Offset, No Paging Receive Interval
Power Saving Mode: DCR Mode

As shown in Table 2 and Table 3, when the M2M device is required to transmit uplink (UL) data to the base station and the corresponding UL data is not sensitive to the scheduling delay, the DCR to the power saving mode of the M2M device Mode can be used.

5 shows an example of the operation of the M2M device entering the DCR mode.

In step S100, the network entity transmits a CRID (hereinafter referred to as M2M CRID) of the M2M device to the base station. In step S101, the M2M device performs network entry to the base station. The M2M power saving class may be negotiated when the M2M device performs network entry, and the base station assigns the M2M CRID to the M2M device.

In step S102, DCR mode initialization is performed between the M2M device and the base station. DCR mode initialization may be performed in a connected mode or in an idle mode. When DCR mode initialization is performed in the connected mode, the M2M device may initialize the DCR mode by transmitting a deregistration request message (AAI-DREG-REQ). The M2M device may request the base station to maintain specific service and operation information for the DCR mode through an AAI-DREG-REQ message. When the base station accepts the request of the M2M device, the base station may transmit a deregistration response message (AAI-DREG-RSP) to the M2M device. The M2M device that receives the AAI-DREG-RSP message starts a context maintenance timer. When the DCR mode initialization is performed in the idle mode, the M2M device may initialize the DCR mode by performing a location update through a ranging request message (AAI-RNG-REQ). When the base station accepts the request of the M2M device, the base station may transmit a ranging response message (AAI-RNG-RSP) to the M2M device. The M2M device that receives the AAI-RNG-RSP message starts a context maintenance timer. While the context hold timer is valid, the network maintains the information of the M2M device.

In step S103, the M2M device in the DCR mode generates UL data to transmit. In step S104, network reentry is performed between the M2M device and the base station. In this case, optimized network reentry may be performed through the M2M CRID. The M2M device may initiate network reentry by transmitting an AAI-RNG-REQ message including the M2M CRID to the base station. In step S105, the base station retrieves information of the M2M device maintained by the network using the M2M CRID.

The DCR mode may be terminated when the M2M device re-enters the network or the context hold timer expires.

In the DCR mode, the M2M device does not receive the paging message and thus cannot receive the multicast traffic transmitted by the base station or the network entity. This is because the paging message includes information indicating the presence or absence of multicast traffic. The multicast traffic is data transmitted from the base station to the plurality of M2M devices at the same time and may include firmware upgrade related data.

When the DCR mode is terminated due to network re-entry, a method for M2M device to receive multicast traffic may be required. To this end, a multicast traffic indication extended header (MTIEH) may be newly defined.

Table 4 shows an example of MTIEH newly defined by the present invention.

field Size (bit) Explanation Multicast Transmission Indication Extended Header Format () { Type 4 Extended header type = 0b1001 (MTIEH type) Response Indication One 0: indicates a request
1: indicates a response (eg ACK) to a request if (Response Indication = = 1) { Multicast Transmission Indication One Indicates the presence of multicast traffic.
0: no multicast traffic
1: has multicast traffic   } if (Multicast Transmission Indication == 1) { Multicast transmission start time (MTST) 8 8 bits of LSB (least significant bit) of the frame number at which the base station starts to transmit DL multicast data. } Reserved variable Byte alignment } - -

Referring to Table 4, the MTIEH includes a Response Indication field and includes a Multicast Transmission Indication field when the value of the Response Indication field is 1. The Multicast Transmission Indication field indicates whether there is multicast traffic to be transmitted by the base station.

MTIEH of Table 4 indicates the presence of multicast traffic in a multicast manner, but can similarly indicate the presence of DL traffic in a unicast manner. In order to indicate the existence of DL traffic in a unicast manner, a traffic indication extended header (TIEH) similar to Table 4 may be defined as shown in Table 5.

field Size (bit) Explanation Transmission Indication Extended Header Format () { Type 4 Extended header type = 0b1001 (TIEH type) Response Indication One 0: indicates a request
1: indicates a response (eg ACK) to a request if (Response Indication = = 1) { Traffic Indication One Indicates the presence of DL traffic.
0: no DL traffic
1: DL traffic   } if (Traffic Indication == 1) { Traffic start time 8 LSB 8 bits of frame number at which base station starts to transmit DL data } Reserved variable Byte alignment } - -

Referring to Table 5, if the TIEH includes a Response Indication field, the TIEH includes a Traffic Indication field when the value of the Response Indication field is 1. The Traffic Indication field indicates whether there is DL traffic to be transmitted by the base station.

6 shows an embodiment of the proposed multicast traffic reception method.

When the M2M device terminates the DCR mode through network re-entry, the M2M device may receive multicast traffic from the base station through MTIEH. M2M devices, such as smart metering devices that only transmit the collected information to the network, periodically monitor the DL to receive multicast traffic, and do not check for the presence of multicast traffic, and the DCR mode ends. When the UL data is transmitted, it is possible to confirm the presence of multicast traffic.

Referring to FIG. 6, in step S200, the network entity transmits an M2M CRID to the base station. In step S201, the M2M device performs network entry to the base station. The M2M power saving class may be negotiated when the M2M device performs network entry, and the base station assigns the M2M CRID to the M2M device. In step S202, DCR mode initialization is performed between the M2M device and the base station. In step S203, the M2M device in the DCR mode generates UL data to transmit. Accordingly, the M2M device performs network reentry to the base station.

In step S204, the M2M device transmits the MAC message with the MTIEH defined in Table 4 to the base station. At this point, a value of the Response Indication field in the MTIEH may be zero. That is, the Response Indication field may indicate a request. In step S205, the base station transmits the MAC message with MTIEH to the M2M device. At this point, a value of the Response Indication field in the MTIEH may be 1. That is, the Response Indication field may indicate a response. Accordingly, the base station can indicate to the M2M device whether multicast traffic is present through the Multicast transmission Indication field in the MTIEH.

In step S206, the M2M device transmits the generated UL data to the base station and, if there is multicast traffic, receives the multicast traffic from the base station.

7 shows another embodiment of the proposed multicast traffic reception method.

Referring to FIG. 7, in step S210, the network entity transmits an M2M CRID to the base station. In step S211, the M2M device performs network entry to the base station. The M2M power saving class may be negotiated when the M2M device performs network entry, and the base station assigns the M2M CRID to the M2M device. In step S212, DCR mode initialization is performed between the M2M device and the base station. In step S213, the M2M device in the DCR mode generates UL data to transmit. Accordingly, the M2M device performs network reentry to the base station.

In step S214, the base station transmits a MAC message with MTIEH to the M2M device. MTIEH may be defined as shown in Table 6. Table 6 is a variation of Table 4.

field Size (bit) Explanation Multicast Transmission Indication Extended Header Format () { Type 4 Extended header type = 0b1001 (MTIEH type) Multicast Traffic Indication One Indicates the presence of multicast traffic
0: no multicast traffic
1: has multicast traffic if (Multicast Traffic Indication == 1) { Multicast transmission start time (MTST) 8 LSB 8 bits of the frame number at which the base station begins to transmit DL multicast data } Reserved variable Byte alignment } - -

Referring to Table 6, the base station may indicate to the M2M device whether multicast traffic is present through the Multicast Traffic Indication field in the MTIEH.

Alternatively, TIEH may be defined as shown in Table 7 to indicate whether DL traffic exists in a unicast manner. Table 7 is a variation of Table 5.

field Size (bit) Explanation Transmission Indication Extended Header Format () { Type 4 Extended header type = 0b1001 (TIEH type) Traffic Indication One Indicates the presence of DL traffic.
0: no DL traffic
1: DL traffic if (Traffic Indication == 1) { Traffic start time 8 LSB 8 bits of frame number at which base station starts to transmit DL data } Reserved variable Byte alignment } - -

Referring to Table 7, the base station may indicate to the M2M device whether DL traffic exists through the Traffic Indication field in the TIEH.

Referring back to FIG. 7, in step S215, the M2M device transmits generated UL data to the base station, and receives multicast traffic from the base station if the multicast traffic exists.

8 shows another embodiment of the proposed multicast traffic reception method.

Referring to FIG. 8, in step S220, the network entity transmits an M2M CRID to the base station. In step S221, the M2M device performs network entry to the base station. The M2M power saving class may be negotiated when the M2M device performs network entry, and the base station assigns the M2M CRID to the M2M device. In step S222, DCR mode initialization is performed between the M2M device and the base station. In step S223, the M2M device in the DCR mode generates UL data to be transmitted. Accordingly, the M2M device performs network reentry to the base station.

In step S224, the M2M device transmits a ranging request message (AAI-RNG-REQ) to the base station. In step S225, the base station transmits a ranging response message (AAI-RNG-RSP) to the M2M device in response to the AAI-RNG-REQ message. At this time, the AAI-RNG-RSP message includes a multicast traffic indication. That is, the AAI-RNG-RSP message can inform the M2M device whether the multicast traffic is present. Table 8 shows an example of an AAI-RNG-RSP message including a multicast traffic indication.

field Size (bit) Explanation Condition AAI-RNG-RSP {   ... Multicast Traffic Indication One Indicates the presence of multicast traffic
0: no multicast traffic
1: has multicast traffic The base station has multicast traffic to be sent to the M2M device if (Multicast Traffic Indication == 1) { Multicast transmission start time (MTST) 8 LSB 8 bits of the frame number at which the base station begins to transmit DL multicast data } ... } - -

Referring to Table 8, the base station may indicate to the M2M device whether multicast traffic is present through the Multicast Traffic Indication field in the AAI-RNG-RSP message.

Or, the AAI-RNG-RSP message may include a traffic indication in order to indicate whether DL traffic exists in a unicast manner. Table 9 shows an example of an AAI-RNG-RSP message including a traffic indication.

field Size (bit) Explanation Condition AAI-RNG-RSP {   ... Traffic Indication One Indicates the presence of DL traffic
0: no DL traffic
1: DL traffic The base station has DL traffic to be sent to the M2M device if (Traffic Indication == 1) { Traffic start time 8 LSB 8 bits of frame number at which base station starts to transmit DL data } ... } - -

As described in FIGS. 6 to 8, when the M2M device receives the MTIEH or AAI-RNG-RSP message with the Multicast Traffic Indication field set to 1 in the network reentry phase after the DCR mode ends, until the M2M device receives all the multicast data Perform communication with the base station. However, since the M2M device cannot know when the last multicast data transmitted by the base station is transmitted, the M2M device cannot accurately determine when to enter the DCR mode again when there is no UL data to transmit. In addition, there is a problem in that a delay occurs in entering the DCR mode again.

Therefore, the base station needs to inform the M2M device that it is the last multicast traffic. The present invention attaches a multicast traffic end extended header (MTEEH) to the last multicast traffic transmitted by the base station, and informs the M2M device that the base station is the last multicast traffic. Upon receiving the MTEEH, the M2M device can immediately enter the DCR mode to reduce power consumption.

9 shows another embodiment of the proposed multicast traffic reception method.

Referring to FIG. 9, in step S300, the network entity transmits an M2M CRID to the base station. In step S301, the M2M device performs network entry to the base station. The M2M power saving class may be negotiated when the M2M device performs network entry, and the base station assigns the M2M CRID to the M2M device. In step S302, DCR mode initialization is performed between the M2M device and the base station. In step S303, the M2M device in the DCR mode generates UL data to transmit. Accordingly, the M2M device performs network reentry to the base station. In step S304, the base station transmits the MAC message with MTIEH to the M2M device. MTIEH may be defined as shown in Table 6. The base station may indicate to the M2M device whether multicast traffic is present through the Multicast Traffic Indication field in the MTIEH. In step S305, the M2M device transmits the generated UL data to the base station, and receives the multicast traffic from the base station if there is multicast traffic.

In step S306, the base station transmits the MAC message including the MTEEH to the M2M device. MTEEH may be defined as shown in Table 10.

field Size (bit) Explanation Multicast Traffic End Extended Header Format () { Type 4 Extended header type = 0b1001 (MTEEH type) } - -

Alternatively, a traffic end extended header (TEEH) similar to Table 10 may be defined as shown in Table 11 to indicate whether the last DL traffic is unicast.

field Size (bit) Explanation Traffic End Extended Header Format () { Type 4 Extended header type = 0b1001 (TEEH type) } - -

Referring back to FIG. 9, the M2M device receiving the MAC message including the MTEEH may initialize the DCR mode again. In step S307, the M2M device transmits an AAI-DREG-REQ message to the base station, and in step S308, the base station transmits an AAI-DREG-RSP message to the M2M device in response to the AAI-DREG-REQ message.

10 shows another embodiment of the proposed multicast traffic reception method.

Referring to FIG. 10, in step S310, the network entity transmits an M2M CRID to the base station. In step S311, the M2M device performs network entry to the base station. The M2M power saving class may be negotiated when the M2M device performs network entry, and the base station assigns the M2M CRID to the M2M device. In step S312, DCR mode initialization is performed between the M2M device and the base station. In step S313, the M2M device in the DCR mode generates UL data to be transmitted. Accordingly, the M2M device performs network reentry to the base station. In step S314, the base station transmits the MAC message with MTIEH to the M2M device. MTIEH may be defined as shown in Table 6. The base station may indicate to the M2M device whether multicast traffic is present through the Multicast Traffic Indication field in the MTIEH. In step S315, the M2M device transmits the generated UL data to the base station and, if there is multicast traffic, receives the multicast traffic from the base station.

In step S316, the base station transmits a MAC message including MTEEH to the M2M device. In this case, the MAC message may further include a DCR mode reinitialization request. The DCR mode reinitialization request may be included in the MTEEH. That is, the base station may request the M2M device to enter the DCR mode in an unsolicited manner while indicating that the base station is the last multicast traffic. Table 12 shows an example of an MTEEH including an action code requesting DCR mode reinitialization.

field Size (bit) Explanation Multicast Traffic End Extended Header Format () { Type 4 Extended header type = 0b1001 (MTEEH type) Multicast End Indication One Indicate termination of multicast traffic
1: Terminate multicast traffic Request DCR mode initiation One Exists when the value of the Multicast End Indication field is 1
1: Request M2M device to initialize DCR mode unconditionally } - -

Or, if the base station instructs whether to terminate the DL traffic through the TEEH in a unicast manner, a TEEH including an action code for unconditionally requesting DCR mode reinitialization may be defined as shown in Table 13.

field Size (bit) Explanation Traffic End Extended Header Format () { Type 4 Extended header type = 0b1001 (TEEH type) Traffic End Indication One Indicate the end of DL traffic
1: Terminate DL traffic Request DCR mode initiation One Exists when the value of the Traffic End Indication field is 1
1: Request M2M device to initialize DCR mode unconditionally } - -

Referring back to FIG. 10, in step S317, the M2M device receiving the MTEEH including the DCR mode reinitialization request transmits an AAI-DREG-REQ message to the base station and enters the DCR mode in response. The AAI-DREG-REQ message may include a confirmation of the DCR mode reinitialization request of the base station. Table 14 shows an example of an AAI-DREG-REQ message including confirmation of a DCR mode reinitialization request of a base station.

field Size (bit) Explanation Condition AAI-DREG-REQ { De-registration-Request_Code 3 Indicates the purpose of the AAI-DREG-REQ message
0x00: UE deregistration request from base station and network
0x01: UE deregistration request from S-ABS and initialization mode of idle mode of UE
0x02: Response to AAI-DREG-RSP message with action code 0x05 sent from base station
0x03: Rejection for an AAI-DREG-RSP message with an action code 0x05 sent from the base station. This code is applicable only if the terminal has UL data to transmit.
0x04: UE deregistration request from S-ABS to enter DCR mode
0x04: request for AMS
0x05: a) response to AAI-DREG-RSP message with action code 0x00, 0x01, 0x02 or 0x03, b) response to MTEEH or TEEH including Request_DCR_Mode_Initiation field ... } - -

Referring to Table 14, the AAI-DREG-REQ message includes a De-registration-Request_code field. When the value of the De-registration-Request_code field is 0x05, the De-registration-Request_code field may indicate a response to MTEEH or TEEH including the Request_DCR_Mode_Intiation field.

11 shows another embodiment of the proposed multicast traffic reception method.

Referring to FIG. 11, in step S320, the network entity transmits an M2M CRID to the base station. In step S321, the M2M device performs network entry to the base station. The M2M power saving class may be negotiated when the M2M device performs network entry, and the base station assigns the M2M CRID to the M2M device. In step S322, DCR mode initialization is performed between the M2M device and the base station. In step S323, the M2M device in the DCR mode generates UL data to be transmitted. Accordingly, the M2M device performs network reentry to the base station. In step S324, the base station transmits the MAC message with MTIEH to the M2M device. MTIEH may be defined as shown in Table 6. The base station may indicate to the M2M device whether multicast traffic is present through the Multicast Traffic Indication field in the MTIEH. In step S325, the M2M device transmits the generated UL data to the base station, and receives the multicast traffic from the base station if there is multicast traffic.

In step S326, the base station transmits a MAC message including MTEEH to the M2M device. In step S327, the base station transmits an AAI-DREG-RSP message to the M2M device. In this case, the AAI-DREG-RSP message may further include a DCR mode reinitialization request. That is, the base station may request the M2M device to enter the DCR mode unconditionally through the AAI-DREG-RSP message. Table 15 shows an example of an AAI-DREG-RSP message including an action code requesting DCR mode reinitialization.

field Size (bit) Explanation Condition AAI-DREG-RSP { Action code 4 Indicates the purpose of an AAI-DREG-RSP message
0x00: the terminal immediately terminates the service with the base station, and attempts to enter the network to another base station
0x01: The UE currently receives from the base station, but does not transmit until it receives an RES-CMD message or an AAI-DREG-RSP message having an action code of 0x02 or 0x03
0x02: The terminal currently receives from the base station, but transmits only on a control connection
0x03: UE returns to normal operation and transmits on active connection
0x04: Valid in response to AAI-DREG-REQ message with De-Registration Request Code = 0x00. The terminal terminates the current connected state with the base station.
0x05: UE starts idle mode initialization: a) Instructs UE to start idle mode, b) Allows UE to send idle mode request from UE when REQ-Duration expires.
0x06: Valid in response to AAI-DREG-REQ message with De-Registration Request Code = 0x01. a) rejecting an idle mode request originating from the terminal, or b) allowing the terminal to transmit an idle mode request originating from the terminal when the REQ-Duration expires.
0x07: Valid in response to AAI-DREG-REQ message with De-Registration Request Code = 0x01, allowing idle mode request from the terminal.
0x08: Valid in response to the AAI-DREG-REQ message with De-Registration Request Code = 0x04, allowing the maintenance of connection information of the terminal.
0x09: Valid in response to the AAI-DREG-REQ message with De-Registration Request Code = 0x04, and refuses to maintain connection information of the terminal.
0x10: Request for unconditional DCR mode initialization to M2M device.
0x11-0x15: reserved ... } - -

Referring to Table 15, the AAI-DREG-RSP message includes an Action code field. If the value of the action code field is 0x10, the AAI-DREG-RSP message may indicate unconditional DCR mode reinitialization to the M2M device.

Referring back to FIG. 11, in step S328, the M2M device that receives the AAI-DREG-RSP message having the Action code field having a value of 0x10 transmits an AAI-DREG-REQ message to the base station in response to this and enters the DCR mode. do. The AAI-DREG-REQ message may include acknowledgment of the DCR mode reinitialization request of the base station. Table 16 shows an example of an AAI-DREG-REQ message including confirmation of a DCR mode reinitialization request of a base station.

field Size (bit) Explanation Condition AAI-DREG-REQ { De-registration-Request_Code 3 Indicates the purpose of the AAI-DREG-REQ message
0x00: UE deregistration request from base station and network
0x01: UE deregistration request from S-ABS and initialization mode of idle mode of UE
0x02: Response to AAI-DREG-RSP message with action code 0x05 sent from base station
0x03: Rejection for an AAI-DREG-RSP message with an action code 0x05 sent from the base station. This code is applicable only if the terminal has UL data to transmit.
0x04: UE deregistration request from S-ABS to enter DCR mode
0x04: request for AMS
0x05: a) response to AAI-DREG-RSP message with action code 0x00, 0x01, 0x02, 0x03 or 0x10, b) response to MTEEH or TEEH including Request_DCR_Mode_Initiation field ... } - -

12 shows an example of the operation of the M2M device entering the idle mode.

In step S400, the M2M device performs network entry to the base station. The M2M power saving class may be negotiated when the M2M device performs network entry.

In step S401, idle mode initialization is performed between the M2M device and the base station. In this case, the base station may transmit a paging period and a paging offset to the M2M device. In the state of entering the idle mode, the base station periodically transmits a paging message in step S402. After receiving the paging message in step S403, the M2M device transmits a location update to the base station.

In step S404, the M2M device in idle mode generates UL data to transmit. In step S405, network reentry is performed between the M2M device and the base station.

In the above description, when the M2M device in the DCR mode transmits UL data, the present invention has described a method of transmitting UL data generated after network reentry to a base station.

Hereinafter, when the M2M device in the DCR mode transmits UL data, a method of transmitting UL data while maintaining the DCR mode without ending the DCR mode will be described. That is, according to the present invention described below, the M2M device in the DCR mode may transmit UL data to the base station without performing network reentry to the base station.

13 shows an embodiment of the proposed data transmission method.

Referring to FIG. 13, in step S500, the network entity transmits an M2M CRID to the base station. In step S501, the M2M device performs network entry to the base station. The M2M power saving class may be negotiated when the M2M device performs network entry, and the base station assigns the M2M CRID to the M2M device. In step S502, DCR mode initialization is performed between the M2M device and the base station. In step S503, the M2M device in the DCR mode generates UL data to transmit.

In step S504, the M2M device transmits an AAI-RNG-REQ message including the generated UL data to the base station. In this case, the UL data may be a short message service (SMS) message that does not exceed 140 bytes. By including UL data not exceeding 140 bytes in the AAI-RNG-REQ message, UL data can be transmitted while maintaining the DCR mode. Table 17 shows an example of an AAI-RNG-REQ message according to the proposed data transmission method.

field Size (bit) Explanation Condition AAI-RNG-REQ { Ranging Purpose Indication 4 0b0000 = initial network entry
0b0001 = reentry handover (HO)
0b0010 = network reentry from idle mode
...
0b1101 = NS / EP Call Setup
0b1110 = Location update for short message transmission in DCR mode
0b1111 = reserved   ... else if (Ranging Purpose Indication == 0b1110) { CRID 72 M2M device ID currently assigned and maintained by the M2M device for DCR mode. } ... } - -

Referring to Table 17, the Ranging Purpose indication field indicating the purpose of the AAI-RNG-REQ message includes a value indicating that the M2M device can transmit UL data in the DCR mode. In addition, when the Ranging Purpose Indication field indicates a location update for short message transmission in the DCR mode, an M2M CRID may be included in the AAI-RNG-REQ message to distinguish the M2M device in the DCR mode.

Referring back to FIG. 13, in step S505, the base station transmits an AAI-RNG-RSP message to the M2M device in response to the received AAI-RNG-REQ message.

Meanwhile, when the size of the UL data exceeds 140 bytes, since the UL data cannot be included in the AAI-RNG-REQ message, network reentry may be performed to terminate the DCR mode and transmit the UL data.

14 shows another embodiment of the proposed data transmission method.

Referring to FIG. 14, in step S510, the network entity transmits an M2M CRID to the base station. In step S511, the M2M device performs network entry to the base station. The M2M power saving class may be negotiated when the M2M device performs network entry, and the base station assigns the M2M CRID to the M2M device. In step S512, DCR mode initialization is performed between the M2M device and the base station. In step S513, the M2M device in the DCR mode generates UL data to be transmitted.

In step S514, the M2M device transmits the AAI-RNG-REQ message including the generated UL data to the base station. In this case, the UL data may be an SMS message that does not exceed 140 bytes. AAI-RNG-REQ message may be defined as shown in Table 17.

In step S515, the base station transmits the AAI-RNG-RSP message to the M2M device in response to the received AAI-RNG-REQ message. In this case, the AAI-RNG-RSP message may indicate whether there is DL traffic to be transmitted by the base station. Table 18 shows an example of an AAI-RNG-RSP message according to the proposed data transmission method.

field Size (bit) Explanation Condition AAI-RNG-RSP {   Location update response 4 0x0: Success of location update
0x1: Location update failed
0x2: reserved
0x3: Location update succeeded and DL traffic pending
0x4: Allow DCR mode initialization request or DCR mode extension request from UE
0x5: DCR mode initialization request or DCR mode extension request rejection of UE
0x6: Location update succeeded for short message transmission in DCR mode
0x7 ~ 0xF: reserved Include only if this message is a response to an AAI-RNG-REQ message used to perform a location update, initiate DCR mode from idle mode, or extend DCR mode if (Location update response == 0x6) { CRID 72 M2M device ID currently assigned and maintained by the M2M device for DCR mode. Include only when M2M CRID changes Traffic Indication One Indicates the presence of DL traffic
0: no DL traffic
1: DL traffic

DL traffic for the firmware upgrade is an example of DL traffic to be sent to the M2M device in DCR mode. The base station has DL traffic to be sent to the M2M device } ... } - -

Referring to Table 18, the Location update response field in the AAI-RNG-RSP message may indicate a location update for short message transmission in DCR mode. In addition, when the value of the Location update response field is 0x06, the AAI-RNG-RSP message may include a Traffic Indication field indicating whether there is DL traffic to be transmitted to the M2M CRID and the M2M device. The Traffic Indication field may indicate whether there is DL traffic to be transmitted by the base station.

Referring back to FIG. 14, in step S516, the M2M device terminates the DCR mode and performs network reentry with the base station. If there is DL traffic to be transmitted by the base station in step S517, the M2M device receives the DL traffic from the base station.

Meanwhile, as shown in Table 18, the AAI-RNG-RSP message may indicate whether there is DL traffic to be transmitted by the base station, but may also indicate whether there is DL traffic to be transmitted by the base station through the aforementioned MTIEH or TIEH.

15 shows another embodiment of the proposed data transmission method.

Referring to FIG. 15, in step S520, the network entity transmits an M2M CRID to the base station. In step S521, the M2M device performs network entry to the base station. The M2M power saving class may be negotiated when the M2M device performs network entry, and the base station assigns the M2M CRID to the M2M device. In step S522, DCR mode initialization is performed between the M2M device and the base station. In step S523, the M2M device in the DCR mode generates UL data to transmit.

In step S524, the M2M device transmits an AAI-RNG-REQ message including the generated UL data to the base station. In this case, the UL data may be an SMS message that does not exceed 140 bytes. AAI-RNG-REQ message may be defined as shown in Table 17.

In step S525, the base station transmits the AAI-RNG-RSP message to the M2M device in response to the received AAI-RNG-REQ message. In this case, the AAI-RNG-RSP message may indicate whether there is DL traffic to be transmitted by the base station. Table 19 shows an example of an AAI-RNG-RSP message according to the proposed data transmission method. Table 19 is a variation of Table 18.

field Size (bit) Explanation Condition AAI-RNG-RSP {   Location update response 4 0x0: Success of location update
0x1: Location update failed
0x2: reserved
0x3: Location update succeeded and DL traffic pending
0x4: Allow DCR mode initialization request or DCR mode extension request from UE
0x5: DCR mode initialization request or DCR mode extension request rejection of UE
0x6: Location update succeeded for short message transmission in DCR mode
0x7 ~ 0xF: reserved Include only if this message is a response to an AAI-RNG-REQ message used to perform a location update, initiate DCR mode from idle mode, or extend DCR mode if (Location update response == 0x6) { CRID 72 M2M device ID currently assigned and maintained by the M2M device for DCR mode. Include only when M2M CRID changes Traffic Indication One Indicates the presence of DL traffic
0: no DL traffic
1: DL traffic

DL traffic for the firmware upgrade is an example of DL traffic to be sent to the M2M device in DCR mode. The base station has DL traffic to be sent to the M2M device } if (Traffic Indication == 1) { DL Traffic Start Time 8 LSB 8 bits of frame number at which base station starts to transmit DL data } ... } - -

Referring to Table 19, when the value of the Traffic Indication field is 1, the AAI-RNG-RSP message includes a DL Traffic Start Time field. By the DL Traffic Start Time field, the M2M device may know when DL traffic is received.

Referring back to FIG. 15, if there is DL traffic to be transmitted by the base station in step S526, the M2M device receives the DL traffic from the base station while maintaining the DCR mode. In step S527, the M2M device receives the last DL traffic. The M2M device may receive DL traffic while maintaining the DCR mode, and monitor the DL only from the time indicated by the DL Traffic Start Time field in the AAI-RNG-RSP message to the last DL traffic to reduce power consumption. . The last DL traffic may include the aforementioned MTEEH or TEEH. Accordingly, the M2M device may know that the received DL traffic is the last DL traffic, thereby reducing the power consumption of the M2M device.

16 is a block diagram of a wireless communication system in which an embodiment of the present invention is implemented.

The base station 800 includes a processor 810, a memory 820, and an RF unit 830. Processor 810 implements the proposed functions, processes, and / or methods. Layers of the air interface protocol may be implemented by the processor 810. The memory 820 is connected to the processor 810 and stores various information for driving the processor 810. The RF unit 830 is connected to the processor 810 to transmit and / or receive a radio signal.

The M2M device 900 includes a processor 910, a memory 920, and an RF unit 930. Processor 910 implements the proposed functions, processes, and / or methods. Layers of the air interface protocol may be implemented by the processor 910. The memory 920 is connected to the processor 910 and stores various information for driving the processor 910. The RF unit 930 is connected to the processor 910 to transmit and / or receive a radio signal.

Processors 810 and 910 may include application-specific integrated circuits (ASICs), other chipsets, logic circuits, and / or data processing devices. The memory 820, 920 may include read-only memory (ROM), random access memory (RAM), flash memory, memory card, storage medium, and / or other storage device. The RF unit 830 and 930 may include a baseband circuit for processing a radio signal. When the embodiment is implemented in software, the above-described technique may be implemented as a module (process, function, etc.) for performing the above-described function. The module may be stored in the memory 820, 920 and executed by the processor 810, 910. The memories 820 and 920 may be inside or outside the processors 810 and 910, and may be connected to the processors 810 and 910 by various well-known means.

In the exemplary system described above, the methods are described based on a flowchart as a series of steps or blocks, but the invention is not limited to the order of steps, and certain steps may occur in a different order or concurrently with other steps than those described above. Can be. In addition, those skilled in the art will appreciate that the steps shown in the flowcharts are not exclusive and that other steps may be included or one or more steps in the flowcharts may be deleted without affecting the scope of the present invention.

The above-described embodiments include examples of various aspects. While not all possible combinations may be described to represent the various aspects, one of ordinary skill in the art will recognize that other combinations are possible. Accordingly, the invention is intended to embrace all other replacements, modifications and variations that fall within the scope of the following claims.

Claims (15)

A data transmission method by a machine-to-machine (M2M) device in a deregistration with context retention (DCR) mode in a wireless communication system,
Generate uplink (UL) data having a size smaller than 140 bytes,
Transmitting a ranging request message (AAI-RNG-REQ) including the UL data to a base station;
Receiving a ranging response message (AAI-RNG-RSP) in response to the ranging request message from the base station,
The ranging request message includes a ranging purpose indication field indicating a location update for transmitting the UL data in the DCR mode.
The ranging response message includes a location update response field indicating a success of a location update for transmission of the UL data in response to the ranging purpose indication field. The method of claim 1,
The ranging request message further includes a context retention identifier (CRID) which is an M2M device identifier currently assigned to the M2M device in the DCR mode. The method of claim 1,
The ranging response message further includes a traffic indication field indicating whether there is downlink (DL) data to be transmitted from the base station to the M2M device in the DCR mode. . The method of claim 3, wherein
Terminating the DCR mode by performing network reentry to the base station;
Receiving the DL data from the base station. The method of claim 3, wherein
The value of the traffic indication field is 1,
The traffic indication field is a data transmission method, characterized in that there is DL data to be transmitted to the base station to the M2M device. The method of claim 5,
The ranging response message further includes a DL traffic start time field indicating 8 bits of LSB (least significant bit) of a frame number at which the base station starts to transmit the DL data. Characterized in that the data transmission method. The method of claim 5,
And receiving the DL data from the base station without terminating the DCR mode. The method of claim 7, wherein
The last DL data of the DL data transmitted by the base station includes a multicast traffic end extended header (MTEEH) or a traffic end extended header (TEEH). Way. The method of claim 1,
The DCR mode is determined based on an M2M power saving class negotiated with the base station at the time of network entry. The method of claim 9,
Receiving the CRID of the M2M device from the base station upon entering the network. A machine-to-machine (M2M) device in a deregistration with context retention (DCR) mode in a wireless communication system,
RF (radio frequency) unit for transmitting or receiving a radio signal; And
Including a processor connected to the RF unit,
The processor,
Generate uplink (UL) data having a size smaller than 140 bytes,
Transmitting a ranging request message (AAI-RNG-REQ) including the UL data to a base station;
Receive a ranging response message (AAI-RNG-RSP) in response to the ranging request message from the base station,
The ranging request message includes a ranging purpose indication field indicating a location update for transmitting the UL data in the DCR mode.
The ranging response message includes a location update response field indicating a success of a location update for transmission of the UL data in response to the ranging purpose indication field. The method of claim 11,
The ranging request message further includes a context retention identifier (CRID) which is an M2M device identifier currently assigned to the M2M device in the DCR mode. The method of claim 11,
The ranging response message further includes a traffic indication field indicating whether there is downlink (DL) data to be transmitted by the base station to the M2M device in the DCR mode. The method of claim 13,
The processor,
Terminating the DCR mode by performing network reentry to the base station;
M2M device, characterized in that further configured to receive the DL data from the base station. The method of claim 13,
The value of the traffic indication field is 1,
The traffic indication field is an M2M device, characterized in that there is DL data to be transmitted to the base station to the M2M device.

Images