CN103416090B - Method and apparatus for handling bursty network entry and re-entry in a machine-to-machine network - Google Patents

Abstract

A kind of for processing the method and apparatus that sudden network is logined and again logined in M2M network.Such as, base station (BS) can receive the triggering from least one equipment being associated with BS.At least one equipment described can be wireless transmitter/receiver unit (WTRU), or it can be the network equipment.Described BS can determine the most abnormal whether closing on based on described triggering.Extremely if closing on universal, described BS can transmit an indication at least one equipment described.Described instruction can be that at least one equipment described instruction BS has been received by universal exception reporting.Described WTRU can receive instruction, and respond described instruction and terminate network and login process.Described WTRU can respond described instruction and enter battery saving mode.

Description

for handling bursty network logins and re-logins in machine-to-machine networks method and device

Cross References to Related Applications

This application claims the benefit of US Provisional Application No. 61/451,852, filed March 11, 2011, the contents of which are incorporated herein by reference.

Background technique

Communication systems for machine-to-machine (M2M) applications is an emerging market. M2M applications can cover a wide range of use cases such as healthcare, smart meters, industrial remote maintenance and control, track, trace and restore, secure access and surveillance, public safety, consumer devices, retail, payment, home/building automation. While business characteristics generally vary with each M2M use case, some specific business characteristics can be identified as common across multiple M2M applications. For example, data traffic for periodic monitoring and reporting in M2M applications is characterized by periodicity, small bursts (e.g., <=100 bytes), high capacity in end-to-end delivery and acknowledgment latency limit. For example, this waiting time can be seconds, minutes, hours or days for a large number of M2M devices (e.g. 5000 to 30000 smart meters in a typical cell size of 0.5km to 2km in an urban area have very little time in effective idle time). low duty cycle). Therefore, a communication system for M2M applications may face a new challenge of effectively transmitting data services.

In addition to regular monitoring and reporting of M2M traffic, real-time M2M traffic data also exists, for example, alerts or alarm reports. Handling such real-time traffic from a large number of devices may bring new challenges to M2M communication systems, since these devices may be low latency and transmissions may be aperiodic and have large burst sizes.

Furthermore, in many cases, communication for M2M applications can be introduced as a new addition of application layer services to existing communication systems (eg, wireless access networks currently configured for mobile phones or computers). Also, it is unlikely that new communication systems will be configured to support M2M applications and other applications. Therefore, it is important to carefully consider how to support non-M2M services as well as M2M services in the network.

Contents of the invention

A method and apparatus for handling bursty network entry and re-entry in an M2M network. For example, a base station (BS) may receive a trigger from at least one device associated with the BS. The at least one device may be a wireless transmit/receive unit (WTRU), or it may be a network device. The BS may determine whether a general anomaly is imminent based on the trigger. The BS may transmit an indication to the at least one device if a widespread exception is imminent. The indication may indicate to the at least one device that the BS has received a general anomaly report. The WTRU may receive the indication and terminate the network entry procedure in response to the indication. The WTRU may enter a power save mode in response to the indication.

Description of drawings

A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which:

FIG. 1A is a system diagram of an example communication system in which one or more disclosed embodiments may be implemented;

FIG. 1B is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communication system shown in FIG. 1A;

Figure 1C is a system diagram of an example radio access network and an example core network that may be used within the communication system shown in Figure 1A;

Figure 2 is a schematic diagram of an example method for reporting a critical general anomaly (critical);

FIG. 3 is a schematic diagram of an example method used in an M2M device;

4 is a schematic diagram of an example method for performing network entry/re-entry according to dedicated random access (RA) occasions;

5 is a schematic diagram of an example method for polling-based network entry/re-entry;

6 is a schematic diagram of an example method for performing system notification of a network login flood;

7 is a schematic diagram of an example method for performing network login/re-login; and

8 is a schematic diagram of another example method for performing network entry/re-entry.

detailed description

FIG. 1A is a system diagram of an example communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple access system that provides voice, data, video, messaging, broadcast, etc. content to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, communication system 100 may use one or more channel access methods such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA) and so on.

As shown in FIG. 1A, a communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks and/or network elements. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), mobile station (MS), station (STA), fixed or mobile subscriber unit, Pagers, cellular phones, personal digital assistants (PDAs), smart phones, laptops, netbooks, personal computers, wireless sensors, consumer electronics, and more.

The communication system 100 may also include a base station 114a and a base station 114b. Each base station 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, Internet 110 and/or network 112. By way of example, base stations 114a, 114b may be base transceiver stations (BTSs), Node Bs, eNodeBs, Home NodeBs, Home eNodeBs, site controllers, access points (APs), wireless routers, stations ( STA) and so on. Although each of the base stations 114a, 114b are described as being a single element, it should be appreciated that the base stations 114a, 114b may comprise any number of interconnected base stations and/or network elements.

Base station 114a may be part of RAN 104, which may also include other base stations and/or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. . Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic area known as a cell (not shown). A cell may also be divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, that is, one transceiver for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and, thus, may utilize multiple transceivers for each sector in the cell.

A base station 114a, 114b may communicate with one or more WTRUs 102a, 102b, 102c, 102d via an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared ( IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

More specifically, as described above, communication system 100 may be a multiple access system and may utilize one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base station 114a and WTRUs 102a, 102b, 102c in RAN 104 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may be established with Wideband CDMA (WCDMA) air interface 116 . WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may then include High Speed Downlink Packet Access (HSDPA) and/or High Speed Uplink Packet Access (HSUPA).

In another embodiment, the base station 114a and WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved-UMTS Terrestrial Radio Access (E-UTRA), which in turn may use Long Term Evolution (LTE) and/or or LTE-Advanced (LTE-A) to establish the air interface 116 .

In other embodiments, base station 114a and WTRU 102a, 102b, 102c may implement such as IEEE802.16 (ie Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA20001X, CDMA2000EV-DO, Interim Standard 2000 (IS-2000 ), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN) and other radio access technologies.

By way of example, base station 114b in FIG. 1A may be a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may use any suitable RAT to facilitate wireless connectivity in a local area, such as a business, residence, Transportation, campus, and more. In one embodiment, the base station 114b and WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In another embodiment, the base station 114b and WTRUs 102c, 102d may establish a pico or femto cell by using a cellular based RAT (eg, WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.). As shown in FIG. 1A , the base station 114b may be directly connected to the Internet 110 . Thus, the base station 114b does not necessarily need to access the Internet 110 via the core network 106 .

The RAN 104 may be in communication with a core network 106, which may be configured to provide voice, data, applications, and/or Voice over Internet Protocol (VOIP) to one or more of the WTRUs 102a, 102b, 102c, 102d. VoIP) service of any type of network. For example, core network 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and/or perform advanced security functions, such as user authentication. Although not shown in FIG. 1A , it should be appreciated that RAN 104 and/or core network 106 may communicate directly or indirectly with other RANs using the same RAT as RAN 104 or a different RAT. For example, in addition to being connected to RAN 104, which may use E-UTRA radio technology, core network 106 may communicate with another RAN (not shown) using GSM radio technology.

The core network 106 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. PSTN 108 may comprise a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a globally interconnected system of computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) of the TCP/IP Internet protocol suite. Network 112 may include wired or wireless communication networks owned and/or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs that may use the same or a different RAT than RAN 104 .

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multimode capabilities, that is, the WTRUs 102a, 102b, 102c, 102d may include multiple wireless networks communicating with different wireless networks over different wireless links. transceivers. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a using a cellular-based radio technology, and with a base station 114b that may use an IEEE 802 radio technology.

FIG. 1B is a system diagram of an example WTRU 102 . As shown in FIG. 1B , WTRU 102 may include processor 118 , transceiver 120 , transmit/receive element 122 , speaker/microphone 124 , keypad 126 , display/touchpad 128 , non-removable memory 130 , removable memory 132 , a power supply 134 , a global positioning system (GPS) chipset 136 , and other peripherals 138 . It should be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with the embodiments.

Processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microprocessor Controllers, application-specific integrated circuits (ASICs), field-programmable gate array (FPGA) circuits, integrated circuits (ICs), state machines, and more. Processor 118 may perform signal encoding, data processing, power control, input/output processing, and/or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120 , which may be coupled to transmit/receive element 122 . Although FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may both be integrated in an electronic package or chip.

Transmit/receive element 122 may be configured to transmit signals to and receive signals from a base station (eg, base station 114a ) over air interface 116 . For example, in one embodiment, transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be, for example, an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals. In another embodiment, the transmit/receive element 122 may be configured to transmit and receive RF and optical signals. It should be appreciated that transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

Furthermore, although the transmit/receive element 122 is depicted as a single element in FIG. 1B , the WTRU 102 may include any number of transmit/receive elements 122 . More specifically, the WTRU 102 may use MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (eg, multiple antennas) for transmitting and receiving wireless signals over the air interface 116 .

The transceiver 120 may be configured to modulate signals to be transmitted by the transmit/receive element 122 and to demodulate signals received by the transmit/receive element 122 . As noted above, the WTRU 102 may be multimode capable. Thus, the transceiver 120 may include multiple transceivers that allow the WTRU 102 to communicate via various RATs, such as UTRA and IEEE 802.11.

The processor 118 of the WTRU 102 may be coupled to a speaker/microphone 124, a keypad 126, and/or a display/touchpad 128 (such as a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit) and may receive information from these devices. user input data. Processor 118 may also output user data to speaker/microphone 124 , keyboard 126 and/or display/touchpad 128 . In addition, processor 118 may access information from, and store information in, any suitable memory (eg, non-removable memory 130 and/or removable memory 132 ). The non-removable memory 130 may include random access memory (RAM), read only memory (ROM), hard disk or any other type of memory storage device. Removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as memory located on a server or home computer (not shown).

Processor 118 may receive power from power supply 134 and may be configured to distribute and/or control power for other components in WTRU 102 . Power source 134 may be any suitable device for powering WTRU 102 . For example, power source 134 may include one or more dry cells (eg, nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, and the like.

Processor 118 may also be coupled to a GPS chipset 136 that may be configured to provide location information (eg, longitude and latitude) related to the current location of WTRU 102 . In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) over the air interface 116, and/or timed based on signals received from two or more nearby base stations. to determine its location. It should be appreciated that the WTRU 102 may obtain location information by any suitable method of location determination while remaining consistent with the embodiments.

Processor 118 may also be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connectivity. For example, peripherals 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photo and video), Universal Serial Bus (USB) ports, vibrating devices, television transceivers, hands-free headsets, modules, frequency modulation (FM) radio units, digital music players, media players, video game console modules, Internet browsers, and more.

Figure 1C is a system diagram of the RAN 104 and core network 106, according to an embodiment. The RAN 104 may be an Access Service Network (ASN) using IEEE 802.16 radio technology in communication with the WTRUs 102a, 102b, 102c via the air interface 116 . As discussed further below, the communication links between the functional entities of the WTRU 102a, 102b, 102c, the RAN 104 and the core network 106 may be defined as reference points.

As shown in Figure 1C, RAN 104 may include base stations 140a, 140b, 140c, and ASN gateway 142, but it should be appreciated that RAN 104 may include any number of base stations and ASN gateways while remaining consistent with the embodiments. Each of the base stations 140a, 140b, 140c may be associated with a particular cell (not shown) in the RAN 104, and each may include one or Multiple transceivers. In one embodiment, the base stations 140a, 140b, 140c may implement MIMO technology. Thus, for example, base station 140a may use multiple antennas to transmit wireless signals to and receive wireless signals from WTRU 102a. The base stations 140a, 140b, 140c may also provide mobility management functions such as handover triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. ASN gateway 142 may act as a traffic aggregation point and may be responsible for paging, caching subscriber profiles, routing to core network 106, and the like.

The air interface 116 between the WTRUs 102a, 102b, 102c and the RAN 104 may be defined as an R1 reference point implementing the IEEE 802.16 specification. Additionally, each WTRU 102a, 102b, 102c may establish a logical interface with the core network 106 (not shown). The logical interface between the WTRUs 102a, 102b, 102c and the core network 106 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

The communication link between each base station 140a, 140b, 140c may be defined as an R8 reference point, which includes protocols for facilitating WTRU handover and transferring data between base stations. The communication link between the base stations 140a, 140b, 140c and the ASN gateway 215 may be defined as the R6 reference point. This R6 reference point may include protocols to facilitate mobility management based on mobility events associated with each WTRU 102a, 102b, 102c.

As shown in FIG. 1C , RAN 104 may be connected to core network 106 . The communication link between the RAN 104 and the core network 106 may be defined by an R3 reference point that includes protocols to facilitate, for example, data transfer and mobility management capabilities. Core network 106 may include mobile IP home agent (MIP-HA) 144 , authentication, authorization, accounting (AAA) server 146 and gateway 148 . Although each of the elements described above are described as being part of the core network 106, it should be appreciated that any of these elements may be owned and/or operated by entities other than the core network operator.

The MIP-HA may be responsible for IP address management and may enable WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 144 may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. AAA server 146 may be responsible for user authentication and for supporting user services. For example, gateway 148 may facilitate interworking with other networks. For example, the gateway 148 may provide the WTRU 102a, 102b, 102c with access to a circuit-switched network, such as the PSTN 108, to facilitate communication between the WTRU 102a, 102b, 102c and conventional landline communication equipment. In addition, the gateway 148 may provide the WTRUs 102a, 102b, 102c with access to the network 112, which may include wired or wireless networks owned and/or operated by other service providers. Access Router (AR) 150 of Wireless Local Area Network (WLAN) 155 may communicate with Internet 110 . AR 150 may facilitate communication between APs 160a, 160b, and 160c. APs 160a, 160b, and 160c may communicate with STAs 170a, 170b, and 170c.

Although not shown in Figure 1C, it should be appreciated that the RAN 104 can be connected to other ASNs and the core network 106 can be connected to other core networks. The communication link between the RAN 104 and other ASNs may be defined as an R4 reference point, which may include protocols for facilitating the coordination of mobility of WTRUs 102a, 102b, 102c between the RAN 104 and other ASNs. Communication links between the core network 106 and other core networks are defined as R5 reference points, which include protocols for facilitating interworking between the local core network and the visited core network.

In many machine-to-machine (M2M) applications, such as smart meters, surveillance monitoring, and public safety, the normal operation of M2M devices may be periodically monitored and reported, where reporting operations may require M2M devices to access data communication networks. As far as the network interface is concerned, eg the device's air interface to a base station (BS) in the radio access network, the M2M device may alternate between a connected state and an idle state. When in the connected state, the M2M device may be connected to the BS through the air interface and data traffic may be transmitted via the air link between the BS and the device. When in the idle state, the air interface of the M2M device may be inactive, for example, the air interface is not available to the BS for normal data exchange. Depending on the M2M application, the periodicity of the M2M reporting operation may result in a rather low duty cycle of the network interface of the M2M device, eg, kept in an idle state. In an access network supporting a large number of M2M devices, a low duty cycle of each individual M2M device may result in most devices operating in an idle state at a given time.

Common anomalies such as power outages, pipe leaks, pipe sabotage, or terrorist attacks may lead to very sudden network login/re-login requirements when multiple M2M devices are idle. In another example, a general anomaly event may be an event that will cause multiple devices in communication with a BS to lose communication with the BS. These example common anomalies may result in an overload of the system with respect to its ability to handle network login/re-login. Such a situation may lead to system congestion and even system failure, especially when a contention-based network access (also known as Random Access (RA)) procedure is used, which can be a common initial network access mechanism to Initiate network login/login again. In the examples below, the term network entry/re-entry may include network entry and/or network re-entry.

For example, a contention-based network access capability may be designed to handle N RA requests per second under normal network operating conditions. In the event of a general anomaly, a large number of M2M devices in the idle state may attempt to transmit messages and enter the connected state to report a system anomaly, which may cause a large number of M2M devices to initiate their network re-entry using contention-based network access process. The number of M2M devices may be much greater than N. Thus, the RA channel for network entry/re-entry can be very congested with many collisions, resulting in no or very low chance for any device to successfully re-entry into the network. Congestion of RA channels may not only cause failure of system anomaly reporting by M2M applications, but may significantly and negatively impact the operation of other applications supported by the same access network.

In the event of a general anomaly, and after the system recovers from an anomaly, there can be another burst of network login/re-login attempts. This may be due to the large number of M2M devices trying to quickly return to their normal operating duty cycle by first connecting to the network. For example, in the event of a system power outage, when power returns, all devices can be powered up and started again. During the initialization process, the devices may attempt to connect to the access system to initialize their network interfaces into a normal operating mode. In this case, network entry/re-entry attempts may be highly synchronized from a large number of M2M devices and may increase the possibility of network congestion.

Another example of a sudden network login/re-login situation can occur after a system reboot. A large number of subscriber stations including M2M devices and/or other subscribers may attempt to log into the network at the same time. On the other hand, if the system is designed to handle bursty network login/re-login requirements, it may be an overdesign for the system, which may result in poor system usage and inefficiency in normal network operation.

System indication messages may be used to report critical general anomaly events. A system indication message may indicate that the BS is aware of a general system error. The BS may transmit a system indication message to all devices upon receiving one or more critical real-time general anomaly reports, and upon receiving a system indication message from the BS, the devices may perform certain actions, e.g. terminate their RA attempts So that the congestion on the network entry/re-entry RA channel can be effectively controlled. A system indication message may be transmitted to one or more M2M devices to remind the M2M devices to stop transmitting event indication messages to avoid reporting the same error.

FIG. 2 is a schematic diagram of an example method 200 for reporting a critical pervasive anomaly. Referring to FIG. 2, the BS may receive a trigger (210), such as an event indication message or a critical real-time exception report. Based on the received trigger, the BS can detect that it is about to experience a general anomaly (220) and transmit a system indication message to all involved devices (230). System Indication messages can be sent to report a generally critical exception to the system so that devices still attempting to log into the network reporting the same system exception can take some action to reduce the load on the network access channel.

If the BS determines that the system has not recovered (240), system indication messages may be transmitted repeatedly at a selected period until network entry/re-entry RA channel congestion is controlled or until the system recovers from a critical general anomaly. When the BS determines that the system has recovered (240), it can resume normal operation (250). The BS determines that the system has recovered based on no longer detecting collisions on the RA channel or that the number of collisions on the RA channel is within tolerance limits. Another example for the BS to determine that the system has recovered may be based on receiving a message from a server on the network side, eg, an M2M application server, indicating that the system has recovered.

An example trigger for the BS to transmit the system indication message to the M2M device may be that the BS receives a critical general exception. Such critical general exceptions may be predefined/configured by the M2M application. In addition, the M2M application system elements including the BS and the M2M device in the access network can dynamically learn, update and maintain information about critical general anomalies during the use of the M2M application.

In addition, other trigger conditions can also be defined for the BS to transmit the system indication message to the M2M device. For example, another trigger for transmitting a system indication message may be based on receiving repeated reports from a predetermined number of M2M devices within a predetermined time window. For example, thresholds may be defined that may be static or configurable. If the number of messages of the same type received within a predetermined period of time exceeds, the system indicates that the message may be delivered to the relevant device. For example, if the BS receives 10 reports of emergency situations, the BS may transmit a system indication message of this message so that other M2M devices do not send the same reports to the BS. Related devices may include all devices or a subgroup of devices. An example of a received message may be a ranging request message with the ranging purpose field set to "abnormal power outage". Another example of a received message may be a set of ranging codes reserved for system anomaly reporting ranging. The BS can detect generalized system errors when the BS receives more than a predefined number of these codes within a predefined time window.

In an example where the system is under extreme load with a large number of collisions, grouped RA codes may allow the BS to answer questions without being able to fully decode the colliding RA codes. For example, when multiple devices attempt to report the same common anomaly, those devices may be considered a group. This group can be associated with a device type, such as a meter. Exceptions reported by groups, such as power outages, may include the type of device and the reported exception.

RA codes for reporting exceptions may be designed and/or selected based on device ID and/or group. If the devices reporting the general anomaly have common RA ID components, conflicts can render individual device IDs unreadable. However, the group identification component of the RA code may still be decodable if the code includes a common group component.

In common abnormal events reported by many devices, the group component of the RA code may allow the BS to identify the reported group. The BS may be aware of the general anomaly, and transmit a system indication message to indicate that the BS has received this general anomaly report. The system indication message may allow the device to take action as needed, such as terminating the RA attempt. The critical general anomaly report can be transmitted to the BS via the air link by the M2M device that has detected the system anomaly or other entities in the M2M application system, such as an M2M server or an M2M gateway.

FIG. 3 is a schematic diagram of an example method 300 used in an M2M device. Referring to FIG. 3, an M2M device may receive a system indication message from a BS (310). The M2M device may determine whether the system indication message indicates a general critical exception (320). If no general critical exception is detected, the M2M device may restart its network entry/re-entry process (330).

If a general critical anomaly is detected, the M2M device may adjust its network entry/re-entry procedure (340). Examples for adjusting the network entry/re-entry process may include terminating the network entry/re-entry, or randomly deciding whether to continue the network entry/re-entry attempt with a pre-specified probability of continuing or terminating. For example, a device may use a 1/1000 probability to continue a network entry/re-entry attempt and a 999/1000 probability to terminate a network entry/re-entry attempt.

The M2M device can detect a critical general abnormality event, and can attempt to report to the M2M server through the BS connected to the network. The BS may need to correctly receive a critical general anomaly report from at least one or more M2M devices before it transmits a System Indication message to the M2M devices in response to being aware of the system anomaly. A general anomaly can lead to system congestion and even failure due to a large number of M2M devices attempting to log-in/re-login to the network. Therefore, in order to improve efficiency, some mechanisms may be used to help one or more M2M devices report critical general anomalies successfully and in a timely manner. Reports of critical general anomalies can be transmitted before or during congestion or failures, and can be transmitted in the normal network entry/re-entry RA channel. Reporting critical general exceptions in such a manner can be exploited by M2M devices in the connected state.

After the system recovers from said critical general anomaly, the M2M device may report the collected data about the system anomaly to the BS and/or the M2M server due to actions taken by any responsible M2M application entity. Such post-system-recovery reports may be encoded in network interface control and/or management messages, eg MAC messages in the air interface. Alternatively, this information can also be communicated between the M2M device and the BS, or between the M2M device and the M2M server or gateway using M2M application layer server messages. The information field in the post-system-recovery message may include: an indicator for indicating whether the device has experienced a system critical exception; and identifying and describing information about the experienced exception, such as which system exception, time and elapsed time s position.

Priority Alert Messages (PAM) may be used to indicate events that may require immediate attention. Devices can generate priority alerts in the event of critical general anomalies. PAM can be delivered via multicast or broadcast messages. The specified method of broadcasting the message may include many examples.

In a first example, the network may multicast/broadcast an indication that PAM is received by devices in the same cell or location area, such as Routing Area Update/Tracking Area Update (RAU/TAU). The devices can then determine whether they are still transmitting their PAM.

In a second example, the network may multicast/broadcast an indication that PAM is received by devices in the same cell or same location area, eg RAU/TAU together with an indication of the purpose or cause of the PAM. The reason may be a set of predefined values determined by the network operator and possibly agreed to by the subscriber. Based on the reason for their alert, the devices can then determine whether they will still transmit their PAM.

In a third example, where the devices belong to a predefined group, the network may multicast/broadcast an indication that PAM is received by devices belonging to a particular group. Based on the group it belongs to and the relationship between the groups, the devices can determine whether they will still transmit their PAM.

In a fourth example, together with an indication of the purpose or cause of PAM, the 3GPP network may multicast or broadcast an indication that PAM is received by devices belonging to a particular group, in case the device belongs to a predefined group. The reason may be a set of predefined values determined by the network operator and agreed to by the subscriber. The set of reasons may be group-specific, eg, each group may have its own set of possible reasons. Based on the group they belong to, the reason for their alert, and possibly the relationship between groups, the devices can determine whether they are still transmitting their PAM.

4 is a schematic diagram of an example method 400 of performing network entry/re-entry based on dedicated RA occasions. Referring to FIG. 4 , the BS allocates a dedicated RA occasion ( 410 ) to one or more selected M2M devices of the M2M application to report a critical general anomaly, so that the critical general anomaly can be correctly reported. Such dedicated RA occasions may be pre-allocated to selected delegates in a static or semi-static manner, or dynamically allocated based on detection of substantial RA congestion. In some examples, RA opportunities may not be assigned.

Based on receiving anomaly reports from one or more M2M devices 420, the BS may determine whether a general anomaly is imminent (430). If the BS determines that a general anomaly event is imminent (430), the BS may transmit a system indication message to indicate receipt of a critical general anomaly report (440). The BS may determine whether the system has recovered (450). If the system has recovered, the BS can resume normal operations (460). If the system has not recovered, the BS may transmit another system indication message (440).

System indication messages may be broadcast to all subscribers in the access network. In this way, subscribers including M2M devices and other user equipments can be aware of RA channel congestion for network entry/re-entry. Subscribers can take certain actions based on system indication messages to help avoid or control congestion. Alternatively, the BS may multicast the system indication message to one or more M2M devices, where the M2M devices may belong to the same M2M application, for example, smart meters. A specific subscriber group may be formed in the access system of the M2M devices, and the BS may multicast a system indication message to the M2M device group.

On condition that the BS is triggered to transmit the received system indication message of a critical general anomaly report, the BS may decide to transmit the system indication message repeatedly at a selected period. The selected period may be predetermined or it may be variable. This situation will occur until the congestion of the RA channel for network entry/re-entry is under control or until the system recovers from a borderline general anomaly.

Dedicated RA based network entry/re-entry may provide dedicated RA occasions to selected M2M devices so that they can successfully enter/re-enter the network without experiencing collisions in the RA channel. In case of RA channel congestion due to access attempts from a large number of M2M devices, this can ensure that critical general exceptions can be correctly reported to the BS and M2M server.

RA timing generally refers to the timing for a subscriber to transmit an RA request. For example, RA occasions can be described by time, RA channel, and RA code. In other words, the subscriber can transmit the RA request to the BS with a predetermined RA code (such as in the code domain) within a predetermined time period (such as in the time domain) and a predetermined channel (such as in the frequency domain).

Depending on the specific M2M application, the selection of M2M devices for receiving dedicated RA occasion allocations may be provided by the M2M application server. The selection may also be randomly decided by the BS accessing the network or based on some considerations, eg, physical location or representational factors among M2M devices. Some examples to consider include, but are not limited to, selecting M2M devices based on physical characteristics such as physical location, available output power, advanced antenna systems, advanced interference mitigation features, device storage capabilities, and reported BS signal strength. Some examples to consider include, but are not limited to, based on factors such as whether the M2M device is battery-powered, powered by the grid instead of a battery, powered by a Select the M2M device for power supply from grid power disconnection.

Dedicated RA occasions may be assigned to selected M2M devices in a static or semi-static manner. For example, a specific RA code may be reserved only for selected M2M devices for reporting their network entry/re-entry attempts of borderline general anomaly. The allocation of this specific RA code may be signaled by the BS to one or more selected M2M devices at their initial network entry. The RA code can also change later but not frequently.

Alternatively, dedicated RA occasions may be dynamically allocated to selected M2M devices based on high congestion detected within the RA channel. If in the RA channel, the BS detects power or noise but cannot decode it in multiple RA channels (eg, in the frequency domain) and multiple RA allocations (eg, in the time domain), then the BS can perceive that there may be congestion in the RA channel, And the allocation of one or more dedicated RA occasions may be triggered.

The allocation of dedicated RA occasions may be encoded in network interface control channel information elements (IEs) and/or control/management messages, eg, MAP IEs and/or medium access control (MAC) messages in the air interface. Allocations can be encoded in separate new MAP IEs and/or MAC messages, or added as new use cases in some existing MAP IEs and/or MAC messages. Alternatively, such information may also be encoded within M2M application layer service messages exchanged between the M2M device and the BS or M2M server or gateway.

The dedicated RA opportunity allocation signal to the selected M2M device may explicitly or implicitly include the following information field: identification information of the recipient of the dedicated RA occasion allocation, such as in A specific M2M device ID assigned in the access network of the network entry/re-entry process; a 48-bit universal MAC address; or a specific ID assigned to the device in the idle state, such as the deregistration ID (DID ), IP address, or Uniform Resource Identifier (URI); and descriptive information about a dedicated RA occasion or multiple dedicated RA occasions, such as time, RA channel, and/or RA code.

5 is a schematic diagram of an example method 500 for polling-based network entry/re-entry. The BS may poll one or more selected M2M devices (510) of the M2M application to detect if they are trying to log into the network. The BS may select the devices to poll in a random manner. In addition, the BS may select a device based on available information about the device such as device type, traffic characteristics, and the like. If the BS determines that one or more selected M2M devices are attempting to log in to the network (520), the BS may determine a reason for network entry/re-entry based on the received polling response (530). Based on network entry/re-entry reasons, the BS may allow access (540). In one example, the BS may determine to poll the one or more selected M2M devices based on detection of congestion in the RA channel.

The poll from the BS may be a downlink (DL) message providing an uplink (UL) assignment or an assignment to the selected M2M representative device. Polling can be unicast polling or multicast polling, eg, BS can poll a single device or poll a group of devices.

Instead of using contention-based access, poll-based network entry/re-entry procedures can be used to initiate network entry/re-entry procedures where the M2M device may not transmit in the UL until It receives polls for the network login/re-login process. When normal RA-based network entry/re-entry procedures experience difficulties due to RA channel congestion (such as overloading of RA attempts from a large number of M2M devices in a borderline pervasive exception situation), the above approach may help polled devices succeed Log in/log back in to access the network.

Based on detecting congestion in the RA channel for network entry/re-entry, the BS may poll one or more selected M2M devices of the M2M application to detect if they are trying to enter the network. M2M device selection and congestion detection of RA channels can be performed using similar mechanisms. The polling from the BS may be a DL signal providing UL allocation to the selected M2M device or multiple selected M2M devices. If a polled UL assignment is assigned to one device, the polling may be a unicast poll and access to a given UL assignment may be non-contentionable. If the polled UL assignment is assigned to multiple selected devices, the polling may be a multicast poll and access to a given UL assignment may be contentioned or non-contentioned. In one example, multicast polling can provide contention free if only one device in the group of multicast polling devices is active and listening to DL at any time for one or more M2M application-specific reasons. UL assignment. Multicast polling can provide contention for UL allocation to devices in a multicast polling recipient group that is otherwise much smaller than the entire domain of M2M devices supported by the access network group. An example of an M2M application specific cause may be one or more mutually exclusive active monitors or sensors.

In one example, based on receiving a poll from a BS, the M2M device may transmit a poll response in a predetermined UL allocation. The polling response may include the M2M device's identity, an indication of its network entry/re-entry attempt, the reason for the network entry and one or more UL bandwidth requests if it requires further UL transmissions.

After transmitting a poll to one or more selected M2M devices, the BS may wait for a poll response in a predetermined UL allocation. If the BS successfully receives and decodes the polling response, the BS and device can be connected and further data exchange can be performed over the link to complete the network entry/re-entry process.

If the BS does not successfully receive and decode the polling response, the polling fails. There may be various reasons for polling failure, for example, the polling device may not be actively listening to the DL, or multicast polling may have conflicted. If the BS does not detect any signal in a given poll to a device (eg, no energy on the radio channel) the BS may determine that the polled device did not transmit in the given poll. If the BS detects a signal (eg, energy on the radio channel) in a given poll to a device but it cannot decode the signal, the BS may determine that a collision occurred in the poll. If the BS detects that the polled device did not transmit in the poll, it can determine that the polled device did not attempt to log in/re-log in to the network. In this example, the BS can terminate the polling process to the device and can choose to poll a different device. If the BS detects that there is a conflict in the polled UL allocation, it can terminate the polling process, use unicast polling instead, or poll a smaller multicast polling group instead.

Polling from the BS and polling responses from devices may be encoded in network interface control channel information elements and/or control/management messages, eg, MAP IEs and/or MAC messages in the air interface. Polls and poll responses can be encoded in separate new MAP IEs and/or MAC messages, or added as new use cases in some existing MAP IEs and/or MAC messages. Alternatively, such information may also be encoded within M2M application layer service messages exchanged between the M2M device and the BS or M2M server or gateway.

The poll from the BS may explicitly or implicitly include the following information fields: identification information of the recipient of the poll and specification information on the polled UL allocation. Regarding the identification information of the polling receiver, in a unicast example, the polling receiver's identification can uniquely identify the polling device in the access network. For example, a specific M2M device ID can be assigned specifically for this poll-based network entry/re-entry process in the access network; a 48-bit generic MAC address can be used; or a specific ID can be assigned to the device in idle state , as DID in 802.16m system, IP address can be used, or URI can be used. In the multicast polling example, the identifier of the multicast group of the polling receiver may be a pre-assigned group ID, a multicast connection ID or a stream ID.

For specification information on polled UL allocations, the time domain specification may include: superframe index, frame index, subframe index, or symbol index/offset. The frequency domain specification may include subchannel index/offset and resource block index/offset. Modulation code processes and antenna/Multiple-Input Multiple-Output (MIMO) related parameters may also be included.

A polling response from an M2M device may explicitly or implicitly include the following information fields: identification information of the sender of the polling response, where a similar identifier is used in unicast polling; its network entry/re-entry attempt ; a description of the reason for logging into the network, which may be an indicator for a borderline general anomaly; and a UL bandwidth request for further UL transmissions.

FIG. 6 is a schematic diagram of an example method 600 for performing system notification of network login overflow. Referring to FIG. 6, the BS may receive (610) one or more system recovery signals from network elements on the network side and/or subscriber side, detect system recovery, or detect congestion in a network entry/re-entry channel. In response, the BS may transmit a notification to one or more devices and subscribers informing them of the perceived or detected network entry/re-entry channel overflow (620). The notification can also be used to instruct one or more devices and subscribers to use the network entry overflow control process for their network entry/re-entry attempts.

In the event of a flood where there may be network login attempts, for example, after the system recovers from a critical system exception, the system notification process may allow some devices to successfully connect to the network in a timely manner. The BS may transmit a notification when triggered by one or more predefined trigger conditions. Examples of such triggers may include: receiving a signal from one or more network elements indicating that the system is recovering from a critical system-general anomaly; receiving one or more signals from one or more WTRUs indicating that the system is recovering from a critical system - Recovery from general anomalies; detection of system recovery from critical system-general anomalies; and detection of congestion on network entry/re-entry channels. Upon receipt of a system notification message indicating network entry flooding, WTRUs attempting to log into the network may change their network entry procedures from normal network entry procedures to network entry overflow control procedures.

A system notification indicating network entry overflow may be broadcast to all subscribers of the BS or multicast to a group of related subscribers. A system notification indicating network entry overflow can be encoded in one or more network interface control and/or management messages (such as MAC messages in the air interface), in a separate new MAC message, or in some existing MAC messages (eg AAI-RNG-ACK message) is added as a new use case. Alternatively, such information may also be encoded within M2M application layer service messages exchanged between the M2M device and the BS or M2M server or gateway.

In an example where an 802.11 based wireless LAN system may be used as an access link of an M2M system, system notifications indicating network entry overflow may be encoded in one or more multicast/unicast class-1 management frames. Multicast/unicast Category-1 management frames may be received by the WTRU in all possible states, whether authenticated or associated. A system notification indicating network entry overflow may be encoded in a separate new category-1 management frame, or it may be encoded in a new information element (IE) and/or information field, which may Added to some existing multicast/unicast class-1 management frames (eg, beacon frames, public response frames, etc.).

Example information fields in a system notification message may include: an identification of the intended recipient, such as a unicast ID, broadcast ID, multicast ID, or group ID; an identification that the system has recovered from a critical general anomaly; Descriptive information recovered in critical general anomalies; BS's advice to receivers regarding actions and corresponding parameters to take when receiving system notifications indicating network entry overflow.

In the network entry overflow control procedure, the BS and/or its subscriber stations including M2M devices and other types of subscribers may use a network entry/re-entry procedure which differs from the normal network entry/re-entry procedure. An overflow control mechanism can be used to handle bursty network login/re-login attempts from a large number of devices. Examples of network entry overflow control mechanisms may include, but are not limited to: temporarily allocating additional network entry/re-entry opportunities, using larger initial windows of network entry opportunities; using larger backup windows for network entry RA contention resolution; using Dedicated network login RA process or use poll-based network login process.

There is a difference between the System Indication process and the System Notification process, where the System Indication process can be used by the BS to notify devices that it is aware of a critical exception so that devices that are still attempting to log into the network reporting the same exception can terminate their network entry attempts . The system notification process can be used by the BS to notify devices of its perceived or detected network entry flooding, so that the network entry flooding control process can be triggered to help a large number of devices successfully connect to the network in a timely manner. The system notification process can be used by the BS to send specific commands to one or more receiving devices to help devices connect to the network. Specific commands may vary from device to device and may be group based.

Each embodiment can be implemented individually or in any combination. For example, network entry/re-entry with dedicated RA occasions and polling-based network entry/re-entry can be used in parallel to ensure critical system-wide anomaly reports can be properly received by the BS. Upon receiving a critical general anomaly report, the BS can transmit a system indication message to avoid congestion in network entry/re-entry.

The network entry flood control process can handle situations where there may be an overflow of network entry/re-entry attempts for devices to establish or restart their connection to the access network. The network login overflow control process may be triggered at the device by receiving a system notification message indicating network login overflow or by device detection of network login overflow. Upon receiving a system notification message or a self-detection of network login overflow, devices that are attempting to log into the network can terminate their current network login process and start a network login flood control process.

An overflow control mechanism can be used to handle bursty network login/re-login attempts from a large number of devices. Examples of network overflow control mechanisms include: temporarily allocating additional radio resources for network entry channels until congestion on the network entry channel is under control; using a large initial window of network entry opportunities and where devices randomly select opportunities to start their network entries attempts so that their attempts can be evenly spaced over the selected large window; use of larger compensation windows for network entry RA contention resolution if RA is used to initiate the network entry process; dedicated network use of the login RA process; and use of a poll-based network login process.

FIG. 7 is a schematic diagram of an example method 700 for performing network entry/re-entry. Referring to FIG. 7, the M2M device may initiate network entry/re-entry (710). Upon receiving a received BS acknowledgment of a borderline general anomaly report (720), the M2M device may take certain actions to aid in congestion control on the RA channel for network entry/re-entry. For example, the M2M device may terminate its network entry/re-entry attempt (730).

FIG. 8 is a schematic diagram of another example method 800 for performing network entry/re-entry. Referring to FIG. 8, the M2M device may attempt network login/re-login (810). Upon receiving a received BS acknowledgment of a critical pervasive anomaly report (820), the M2M device may determine that its power supply is above a threshold (830). If the power supply of the M2M device is above a threshold, the M2M device may remain awake and monitor DL from the BS (840). If the power supply is below a threshold, the M2M device may enter a power saving mode (850).

The M2M device may randomly decide whether it should continue its network re-entry attempt with a pre-specified probability of continuing or terminating. For example, an M2M device may continue with a probability of k/1000, and it may terminate with a probability of (1000-k)/1000, where k may be an integer in the range (0, 1000). The M2M device can dynamically adjust its RA compensation window. For example, the M2M device can extend its RA compensation window to a large extent, so that RA retries can be carried out at a longer interval. Alternatively, the M2M device may select the second AP for network entry if the second AP is within range.

System indication messages may be encoded in one or more network interface control/management messages (eg, MAC messages in the air interface as defined in 802.16/WiMAX). The system indication message may be encoded in a separate new MAC message, or it may be added as a new use case in an existing MAC message (eg, the AAI-RNG-ACK message in 802.16m). Alternatively, the system indication message may be generated by an M2M application service layer located on or connected to the BS, for example, an M2M server or a gateway.

In an example where an 802.11-based wireless LAN system is used as an access link of an M2M system, the system indication message may be encoded in a multicast/broadcast Class-1 (Class-1) management frame. Multicast/Broadcast Category-1 Management Frames may be received by a WTRU in all possible states, whether authenticated or associated. The system indication message may be encoded in a separate new category-1 management frame, or it may be encoded in a new information element (IE) and/or information field, which may be added to some existing multicast/broadcast class-1 management frames (eg, beacon frames, public response frames, etc.).

The information fields in the system indication message may include: the identification of the intended recipient, for example, unicast ID, broadcast ID, multicast ID or group ID; Descriptive information; the BS's recommendation to the recipient about actions to take upon receipt of the system indication message, e.g., terminate RA attempt, continue RA attempt with predefined possibilities, extend backoff window or connect to BS/ AP; BS assignment of dedicated RA channels to one or more specific devices; and polled BS assignments to specific devices.

In another example, an 802.11 based wireless LAN system may be used as an access link of the M2M system. In this example, an enhanced 802.11 contention-free (CF) access mechanism may be used as the network entry overflow control mechanism. For example, Enhanced CF Polling/QoS-CF Polling and/or Enhanced Power Save Multi-Polling (PSMP) may be used. This example process may include enhancements such as: enabling contention-free wireless LAN link access opportunities to be offered with or without an assigned Association Identifier (AID) as specified in 802.11; and providing a new addressing process to identify a WTRU that has previously associated and authenticated with an AP, but is currently inactive on the access wireless LAN link. In this example, at least 6000 M2M devices can be supported.

In the enhanced CF-Poll/QoS-CF-Poll procedure, CF-Poll (No Data) and QoS CF-Poll (No Data) frames may be allowed to be transmitted to the WTRU, regardless of the state of the WTRU. This procedure may provide the WTRU with a contention-free link access opportunity to start or restart the communication link with the AP. A WTRU for a particular link access occasion assignment may be identified by its MAC address in the Destination Address (DA) field of a CF-Poll/QoS-CF-Poll frame (no data) transmitted by the AP.

In the enhanced PSMP procedure, a contention-free link access opportunity may be assigned to one or more WTRUs that may not have an associated ID assigned. In this example, enhanced PSMP frames may be used to specify link access opportunity assignments. In an enhanced PSMP frame with individual addresses, each WTRU may be identified by an identifier assigned by the WTRU's addressing process that supports a large number of M2M applications. The number of WTRUs supported may exceed the maximum number of AIDs specified in 2007, 802.11. Such an identifier may be assigned to the WTRU prior to entering a power saving mode to support M2M applications.

The AP may offer the WTRU a contention-free link access opportunity to restart the communication link with the AP and may be based on a restart priority associated with the WTRU. These priorities may be predetermined when there are a large number of WTRUs when the WTRU is in associated mode/state with the AP. In one example, the WTRU and AP may negotiate a restart priority for the WTRU. In this example, the WTRU may transmit a request to the AP for a certain restart priority, and the AP may authorize that restart priority or a different restart priority based on BSS load or one or more BSS operating conditions. The restart priority requested by the WTRU may be based on supported applications, eg, time-critical sensor applications; or the type of WTRU, eg, medical equipment. Each WRTU may have a unique restart priority, where no two WTRUs have the same restart priority. In another example, an AP may support a set of restart priority classes/groups, and a WTRU may be assigned to a specific restart priority class/group.

The network entry overflow control mechanism can be used alone or in conjunction with the network entry overflow control process. For example, a large initial network entry opportunity window for RA contention resolution and a large backoff window can be used in conjunction to spread out initial attempts and retry attempts over time.

The choice of network entry overflow control mechanism may be indicated in the system notification message for indicating network entry overflow, and it may also be predefined based on system design decisions.

An M2M device may refer to an M2M subscriber station in an access network, and may be a user premises device, such as a smart meter, or a hub, or a data aggregation point (DAP). A BS may refer to an access point or point of attachment in an access network that connects subscriber stations to the network, and may be a Node B or Evolved Node B in the Third Generation Partnership Project (3GPP), in 802.16/WiMAX BS or Advanced BS. The BS may also refer to a BS supporting the M2M application layer local service, and also a BS connected to another entity such as an M2M server or a gateway supporting the M2M application layer service.

Example

1. A method used in a base station (BS), the method comprising:

receiving a trigger from at least one device; and

In the case of a general anomaly imminent, a system indication is delivered to the at least one device.

2. according to the method described in embodiment 1, this method also comprises:

It is determined whether a general anomaly is imminent based on the trigger.

3. according to the method described in embodiment 1 or 2, this method also comprises:

It is determined whether the wireless communication system has been restored.

4. According to the method described in any one of the above embodiments, the method also includes:

In case the system is not restored, another system indication is transmitted to the at least one device.

5. The method as in any preceding embodiment, wherein the system indication is transmitted periodically.

6. The method of embodiment 5, wherein the periodic transmission of the system indication is variable.

7. The method of embodiment 5, wherein the periodic transmission of the system indication is dynamic.

8. The method as in any one of the preceding embodiments, wherein the trigger is an exception report.

9. The method as in any preceding embodiment, wherein the triggering is based on receiving a plurality of reports.

10. The method of embodiment 9, wherein the plurality of reports are received from a plurality of M2M devices.

11. The method of embodiment 9 or 10, wherein the plurality of reports are received within a predetermined time window.

12. The method as in any preceding embodiment, wherein the triggering is based on receiving a plurality of messages of a particular type.

13. The method of embodiment 12, wherein the plurality of messages of a particular type are of the same type.

14. The method as in embodiment 12 or 13, wherein the plurality of messages of a particular type are of different types.

15. The method as in any one of embodiments 12-14, wherein the plurality of messages of a particular type are received within a predetermined time window.

16. The method as in any preceding embodiment, wherein the at least one device comprises one or more devices of the same type.

17. The method as in any one of embodiments 1-15, wherein the at least one device comprises one or more devices of different types.

18. The method as in any preceding embodiment, wherein the at least one device is a wireless transmit/receive unit (WTRU).

19. The method as in any preceding embodiment, wherein the at least one device is a network entity.

20. The method as in any preceding embodiment, wherein the at least one device is a machine-to-machine (M2M) server.

21. The method as in any preceding embodiment, wherein the at least one device is a machine-to-machine (M2M) gateway.

22. A base station (BS), comprising:

a receiver configured to receive a trigger from at least one device;

A transmitter configured to transmit a system indication to the at least one device if a general anomaly is imminent.

23. The BS of embodiment 22, further comprising:

A processor configured to determine whether a general exception is imminent based on the trigger.

24. The BS of embodiment 23, wherein the processor is further configured to determine whether the wireless communication system has recovered.

25. The BS as in any one of embodiments 22-24, wherein the transmitter is further configured to transmit another system indication to the at least one device.

26. The BS as in any one of embodiments 22-25, wherein the transmitter is further configured to transmit another system indication if the system does not recover.

27. The BS as in any one of embodiments 22-26, wherein the system indication is transmitted periodically.

28. The BS of embodiment 27, wherein the periodic transmission of the system indication is variable.

29. The BS of embodiment 27, wherein the periodic transmission of the system indication is dynamic.

30. The BS as in any one of embodiments 22-29, wherein the trigger is an exception report.

31. The BS as in any one of embodiments 22-30, wherein the triggering is based on receiving a plurality of reports.

32. The BS of embodiment 31, wherein the plurality of reports are received from a plurality of M2M devices.

33. The BS as in embodiment 31 or 32, wherein the plurality of reports are received within a predetermined time window.

34. The BS as in any one of embodiments 22-33, wherein the trigger is based on receiving a plurality of messages of a particular type.

35. The BS of embodiment 34, wherein the plurality of messages of a particular type are of the same type.

36. The BS as in embodiment 34 or 35, wherein the plurality of messages of a particular type are of different types.

37. The BS as in any one of embodiments 34-36, wherein the plurality of messages of a particular type are received within a predetermined time window.

38. The BS as in any one of embodiments 22-37, wherein the at least one device comprises one or more devices of the same type.

39. The BS as in any one of embodiments 22-37, wherein the at least one device comprises one or more devices of different types.

40. The BS as in any one of embodiments 22-39 wherein the at least one device is a wireless transmit/receive unit (WTRU).

41. The BS as in any one of embodiments 22-40, wherein the at least one device is a network entity.

42. The BS as in any one of embodiments 22-41, wherein the at least one device is a machine-to-machine (M2M) server.

43. The BS as in any one of embodiments 22-42, wherein the at least one device is a machine-to-machine (M2M) gateway.

44. A method for use in a wireless transmit/receive unit (WTRU), the method comprising:

attempt a network login process; and

An indication of a general anomaly report from a base station (BS) is received.

45. The method of embodiment 44, further comprising:

In response to the indication, the network entry process is terminated.

46. The method of embodiment 44 or 45, further comprising:

A power saving mode is entered in response to the indication.

47. The method of any one of embodiments 44-46, further comprising:

A determination is made as to whether the power supply of the WTRU is above a threshold.

48. The method as in any one of embodiments 44-47, further comprising entering a power saving mode if the power supply is above a threshold.

49. The method of any one of embodiments 44-47, further comprising:

In case the power supply is below a threshold, stay awake and monitor a downlink (DL) channel from the BS.

50. A wireless transmit/receive unit (WTRU), the WTRU comprising:

a processor configured to attempt a network login process; and

A receiver configured to receive an indication of a general anomaly report from a base station (BS).

51. The WTRU of embodiment 50, wherein the processor is further configured to terminate the network entry process in response to the indication.

52. The WTRU as in embodiment 50 or 51, wherein the processor is configured to enter a power saving mode in response to the indication.

53. The WTRU as in any one of embodiments 50-52 wherein the processor is further configured to determine whether the WTRU's power supply is above a threshold.

54. The WTRU as in any one of embodiments 50-53 wherein the processor is further configured to enter a power saving mode.

55. The WTRU of embodiment 54, wherein the processor is further configured to enter a power saving mode if the power supply is above a threshold.

56. The WTRU of embodiment 19 wherein the processor is further configured to remain awake and monitor a downlink (DL) channel from the BS if the power supply is below a threshold .

Although features and elements have been described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software or firmware incorporated into a computer readable medium and executed by a computer or a processor. Examples of computer readable media include electrical signals (transmitted via wired or wireless connections) and computer readable storage media. Examples of computer readable media include, but are not limited to, read only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor storage devices, magnetic media such as internal hard disks and removable disks, magnetic Optical media, and optical media such as CD-ROM discs and digital versatile discs (DVDs). A processor associated with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC or any host computer.

Claims (12)

1. A method used in a base station, the method comprising: receiving an event indication message from a device of a plurality of devices in communication with the base station; determining whether a general anomaly event is imminent based on the event indication message, wherein a general anomaly event is an event that will cause the plurality of devices in communication with the base station to lose communication with the base station; and In the event that a general anomaly event is imminent, transmitting a first system indication message to one or more of the plurality of devices in communication with the base station, wherein the first system indication message indicates communication with the base station The plurality of devices should stop transmitting event indication messages to the beacons of the base station. 2. The method of claim 1, further comprising: determining whether the base station has recovered from the general anomaly event; and In case the base station has not recovered from the general anomaly event, transmitting a second system indication message to at least one of the plurality of devices. 3. The method of claim 1, wherein the system indication message is transmitted periodically. 4. The method of claim 1, wherein the event indication message is an exception report. 5. The method of claim 1, wherein the first system indication message is transmitted by the base station based on the base station receiving a plurality of exception reports from the plurality of devices within a predetermined time period. 6. The method of claim 1, wherein the first system indication message is transmitted by the base station based on the base station receiving a plurality of messages of a particular type within a predetermined time period. 7. A base station, the base station comprising: a receiver configured to receive an event indication message from a device of a plurality of devices in communication with the base station; a processor configured to determine whether a general anomaly event is imminent based on the event indication message, wherein a general anomaly event is an event that will cause the plurality of devices in communication with the base station to lose communication with the base station; and a transmitter configured to transmit a first system indication message to one or more of the plurality of devices in communication with the base station in the event that a general anomaly event is imminent, wherein the first system indication message is A beacon indicating that the plurality of devices in communication with the base station should cease transmitting event indication messages to the base station. 8. The base station of claim 7, wherein the processor is further configured to determine whether the base station has recovered from the general anomaly event, and wherein the transmitter is further configured to In the case of recovery, the second system indication message is sent to at least one device among the plurality of devices. 9. The base station of claim 7, wherein the system indication message is transmitted periodically. 10. The base station of claim 7, wherein the event indication message is an exception report. 11. The base station of claim 7, wherein the transmitter is further configured to transmit the first system indication based on the base station receiving a plurality of exception reports from the plurality of devices within a predetermined time period information. 12. The base station of claim 7, wherein the transmitter is further configured to transmit the first system indication message based on the base station receiving a plurality of messages of a particular type within a predetermined time period.