WO2014071171A2

WO2014071171A2 - Method and apparatus for machine-type communication device monitoring

Info

Publication number: WO2014071171A2
Application number: PCT/US2013/068032
Authority: WO
Inventors: Guanzhou Wang; Pascal M. Adjakple; Peter S. Wang; Kai Liu
Original assignee: Interdigital Patent Holdings, Inc.
Priority date: 2012-11-02
Filing date: 2013-11-01
Publication date: 2014-05-08
Also published as: WO2014071171A3

Abstract

A method and apparatus for machine-type communication (MTC) group configuration are described herein. A method in an MTC-interworking function (IWF) includes receiving a monitoring configuration command from an MTC server, transmitting an inquiry to a HSS/HLR for a location of a targeted device group, receiving an inquiry result from the HSS/HLR, and transmitting a configuration request to a MME. A method and apparatus for detection of a mismatch between a wireless transmit/receive unit (WTRU) and a universal integrated circuit card (UICC) are described herein. A method in the WTRU includes transmitting an attach request message to a MME including a request for an IMEI, receiving an attach accept message from the MME including the requested IMEI, comparing the received IMEI against the IMEI of the WTRU, and on a condition that the received IMEI does not match the IMEI of the WTRU, triggering a monitoring report to the network.

Description

METHOD AND APPARATUS FOR MACHINE-TYPE

COMMUNICATION DEVICE MONITORING

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. provisional application

No. 61/721,918 filed November 2, 2012, the contents of which is hereby incorporated by reference herein.

BACKGROUND

[0002] Machine-type communication (MTC) device monitoring is a mechanism that enables an MTC device or network entities to report to the authorized MTC users in case a configured monitoring event is triggered. MTC devices usually work without human interaction or supervision. When an MTC device has some malfunction or loses network connectivity, the MTC device monitoring mechanism may help the users to find out the problems timely and get the device back to service promptly. Moreover, the MTC devices may be deployed at the places where abuse cannot be easily prevented. For example, someone may replace the universal integrated circuit card (UICC) in the MTC device with a new one which is not allowed. The MTC users may be notified when these undesired events occur.

SUMMARY

[0003] A method and apparatus for machine-type communication (MTC) group configuration are described herein. A method in an MTC-interworking function (IWF) includes receiving a monitoring configuration command from an MTC server, transmitting an inquiry to a home subscriber server

(HSS)/home location register (HLR) for a location of a targeted device group, receiving an inquiry result from the HSS/HLR, and transmitting a configuration request to a mobility management entity (MME).

[0004] A method and apparatus for detection of a mismatch between a wireless transmit/receive unit (WTRU) and a universal integrated circuit card

(UICC) are described herein. A method in the WTRU includes transmitting an attach request message to a mobility management entity (MME) including a request for an international mobile subscriber identity (IMSI)-international mobile equipment identity (IMEI), receiving an attach accept message from the MME including the requested IMEI, comparing the received IMEI against the IMEI of the WTRU, and on a condition that the received IMEI does not match the IMEI of the WTRU, triggering a monitoring report to the network.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

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

[0007] FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A;

[0008] FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A;

[0009] FIG. 2 shows an example Third Generation Partnership Project

(3GPP) network architecture for MTC;

[0010] FIG. 3 is a signaling diagram of an example process for MTC group configuration in accordance with one embodiment;

[0011] FIG. 4 is a signaling diagram of an example process for monitoring configuration at the mobility management entity (MME) or serving GPRS support node (SGSN) in accordance with one embodiment;

[0012] FIG. 5 is a signaling diagram of an example process for MTC monitoring configuration at the evolved NodeB (eNB) or radio network controller (RNC); [0013] FIG. 6 is a signaling diagram of an example process for MTC monitoring configuration at the home subscriber server (HSS)/home location register (HLR); and

[0014] FIG. 7 is a signaling diagram of an example process for international mobile subscriber identity (IMSI)-international mobile equipment identity (IMEI) mismatch detection at the WTRU.

DETAILED DESCRIPTION

[0015] FIG. 1A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ 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 the like.

[0016] As shown in FIG. 1A, the communications 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, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0017] The communications systems 100 may also include a base station

114a and a base station 114b. Each of the base stations 114a, 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, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0018] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple -input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0019] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over 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). [0020] More specifically, as noted above, the communications system

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

[0021] In another embodiment, the base station 114a and the WTRUs

102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE-A).

[0022] In other embodiments, the base station 114a and the WTRUs

102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-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 the like.

[0023] The base station 114b in FIG. 1A may be a wireless router, Home

Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the 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 the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106.

[0024] The RAN 104 may be in communication with the core network

106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high- level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing an E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0025] The core network 106 may also serve as a gateway for the

WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT. [0026] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular -based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

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

[0028] The 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 in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0029] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the 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 an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0030] In addition, although the transmit/receive element 122 is depicted in FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0031] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0032] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light- emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non- removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The 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 on a server or a home computer (not shown).

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

[0034] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location- determination method while remaining consistent with an embodiment.

[0035] The processor 118 may further 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, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0036] FIG. 1C is a system diagram of the RAN 104 and the core network 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106.

[0037] The RAN 104 may include eNode-Bs 140a, 140b, 140c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 140a, 140b, 140c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 140a, 140b, 140c may implement MIMO technology. Thus, the eNode-B 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0038] Each of the eNode-Bs 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 1C, the eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.

[0039] The core network 106 shown in FIG. 1C may include a mobility management gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0040] The MME 142 may be connected to each of the eNode-Bs 142a,

142b, 142c in the RAN 104 via an Si interface and may serve as a control node. For example, the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 142 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0041] The serving gateway 144 may be connected to each of the eNode

Bs 140a, 140b, 140c in the RAN 104 via the Si interface. The serving gateway 144 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 144 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0042] The serving gateway 144 may also be connected to the PDN gateway 146, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0043] The core network 106 may facilitate communications with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0044] Figure 2 in an example of 3GPP architecture for Machine-Type

Communication (MTC). A Services Capability Server (SCS) 205 is an entity which connects to the 3GPP network to communicate with WTRUs 225 used for MTC and the MTC-inter-working function (MTC-IWF) 201 in the HPLMN 240 or a short message service (SMS) service center (SMS-SC) 210 for device triggering. The SCS 205 may offer capabilities for use by one or multiple MTC Applications 250. The WTRU 225 may host one or multiple MTC Applications 250. The corresponding MTC Applications 250 in the external network may be hosted on one or multiple Application Servers (ASs) 260 ultimately connected to the SCS 205.

[0045] Tsms 255 may be the interface that encompasses all the various proprietary SMS-SC 210 to a short message entity (SME) interface 265 standards and may be outside the scope of 3GPP specifications. The Tsms 255 may be used to transmit a trigger to a WTRU 225 encapsulated in a MT SMS as an over-the-top application by any network entity acting as an SME 265. Tsp 270 is a 3GPP standardized interface to facilitate value-added services motivated by MTC-IWF 201, for example control pane device triggering, and provided by the SCS 205.

[0046] An Application Programming Interface (API) may be used as an abstract to illustrate an example of an end-to-end view for MTC and to simplify mapping to MTC specifications of other standardization organizations. In an indirect model, MTC capabilities and the MTC Application in the external network may be collocated on the same SCS 205.

[0047] For a roaming scenario, the MTC-IWF 201 may have the connection with a home subscriber server (HSS) 215 and SMS-SC 210 within the home network only and with serving SGSN/MME/MSC 220(a)/(b)/(c) in a visited network.

[0048] MTC device triggering may start from the MTC application 250.

An MTC application 250 may configure the SCS 205 for MTC device triggering. The SCS 205 may transmit a device triggering request to the MTC-IWF 201 with external MTC device identities (not necessarily 3GPP identifiers) via the Tsp interface 270.

[0049] The MTC-IWF 201 plays a role in bridging the SCS 205 and the public land mobile network (PLMN) for handling the MTC device triggering and other functionalities. An MTC-IWF 201 may co-exist with the SMS-SC 210 with an interface T4 230 or may connect to the SMS-SC 210 externally with a T4 230.

[0050] The MTC-IWF 201 interrogates the home location register

(HLR)/HSS 215, when needed, to map external identifiers to international mobile subscriber identity (IMSI) or to some other MTC device internal ID (known to 3GPP network) and gather the device/WTRU 225 reachability and configuration information. The MTC-IWF 201 then selects the trigger delivery mechanism, for example, T4-SMS 240, T5-direct 235, or T5-direct- SMS 235, and performs protocol translation if necessary, and routes the request towards a relevant core network (CN) entity. For example, protocol translation may be necessary to reformat the triggered request to match the selected trigger delivery method.

[0051] The MTC device trigger requests generated by the MTC-IWF 201 may go to the CN controlling nodes over the T5 interface 235. For example, the CN controlling nodes may be a mobility management entity (MME) 220(b), serving general packet radio service (GPRS) support node (SGSN) 220(c), or mobile switching center (MSC) 220(a). The CN controlling node may make a decision on how the MTC device triggering is delivered to the MTC devices/WTRUs 225. An MTC device trigger may then be transmitted to the MTC devices/WTRUs 225 to invoke the MTC devices/WTRUs 225 performing certain actions and/or respond back.

[0052] The MTC-IWF 201 may transmit an SMS request in terms of an

MTC device trigger over the T4 interface 230 to the SMS-SC 210, which may then generate and/or package the MTC device trigger in SMS form and dispatch the SMS to an MSC 220(a). It may then go to the WTRU 225 directly or via the SGSN/MME 220(c)/(b).

[0053] The embodiments disclosed herein may use the MTC architecture as shown in Figure 2, but may be implemented using different network architectures. The terms "service capability server" and "MTC server" may be used interchangeably. The term "device," "MTC device," and "WTRU" may be used interchangeably. It may be noted that even though the embodiments are disclosed herein in the context of the MTC communications, the embodiments may be applicable to any type of WTRUs.

[0054] An MTC monitoring mechanism may have the following building blocks: an MTC monitoring configuration, monitoring events detection, monitoring event reporting, and reactions to the monitoring event.

[0055] The MTC monitoring may be mostly about monitoring some MTC device related events. The events and the conditions that may trigger those events may be configured in the MTC devices or related network entities. How the MTC devices and network entities may report the triggered events that need to be configured. The MTC monitoring configuration procedures which may involve the interfaces between MTC server, 3GPP network entities, and MTC device need to be defined.

[0056] The MTC devices or the network entities that are configured to monitor configured events may be able to detect those events. The detection method may require interaction between MTC devices and network entities through a standard interface.

[0057] When the configured events are triggered, the MTC device or the network entity may notify the MTC user of the events. The event reporting method and the procedures that may involve the interfaces between an MTC server, 3GPP network entities, and a MTC device need to be defined.

[0058] When the configured monitoring events are triggered, it may require certain intervention from the network or authorized MTC user. The required reaction may be different depending on various events.

[0059] Embodiments are disclosed for the MTC monitoring mechanism.

[0060] There may be two types of MTC monitoring events. One type of

MTC monitoring event may be a non-3GPP network specific event which may depend on the MTC device itself to detect and may not involve 3GPP network entities. The configuration and reporting of these events may happen directly between the MTC device and MTC server/application server in the application layer and may be transparent to the 3GPP network. The monitoring configuration may be pre-configured in the device, configured through Open Mobile Alliance (OMA) Device Management (DM), or by the MTC server/application server through application layer signaling or data. Some examples of this type of monitoring events may be device malfunction (for example, hardware or software problem of the device itself) or dysfunction, application related events that may trigger certain application logic or reaction, power supply events (for example, change from external power supply to battery or vice versa, battery low, battery recharged, and the like), environmental events (for example, overheat, and the like) or operational condition changes, location change, (for example, Global Positioning System (GPS) coordinates), out-of or return-to the defined area scopes, others such as malicious attack, human proximity, and the like.

[0061] The other type of MTC monitoring event may be a 3GPP-network specific event which may involve the 3GPP network entities in order to configure, detect, and report the events. Some examples of this type of monitoring events may be association of an MTC device and an authentication card such as a Universal Integrated Circuit Card (UICC) (for example, mismatched International Mobile Subscriber Identity (IMSI) and International Mobile Equipment Identity (IMEI)), alignment of WTRU behaviors and configured features (for example, a fixed or low mobility WTRU transmitting frequent location update request), change in point of attachment (that may include change of connected eNB or change of access point name (APN) or attached PDN gateway (PGW)), loss of network connectivity (for example, detached from network, no response to paging, and the like), abnormal network behavior (for example, repeated triggering, extended access barring (EAB) not alleviated for a long time, and the like), unauthorized change in device configuration (for example, security setting, access class, EAB settings, IP address cloning, and the like), device capability or device software (for example, modem software, firmware, or driver including system parameters such as radio or radio frequency (RF) settings, and the like), and the like. [0062] The embodiments disclosed herein may mainly address the

3GPP-network specific events configuration, detection, and reporting, but may also be applicable to non-3GPP- specific events.

[0063] Depending on various monitoring events, the configuration may be performed at different entities. The configuration of the 3GPP-network specific events may be initiated by the authorized MTC user. In this case, a configuration command may be passed by the MTC server to other entities in the 3GPP network and MTC devices. The resulting event may be provided to the MTC server, or may be provided to the 3GPP network or may be displayed or made available locally on the MTC device.

[0064] In another embodiment, a configuration command may be initiated by the 3GPP network operator. In this case, the configuration command may be transmitted by a 3GPP network entity through the 3GPP network to the MTC devices. For example, the operations and maintenance (O&M) entity may transmit to the MME or eNB the configuration parameters for distribution to the MTC devices (for example, via common messages such as a system information broadcast, via dedicated non-access stratum (NAS) or radio resource control (RRC) messages, or via OMA Device Management (DM) messages). Alternatively, the configuration message may be self-initiated from the 3GPP network entities (for example, MME, SGSN, MSC, eNB/NodeB, or HSS/HLR). This may be the case if the information is pre- configured in the 3GPP network entities (for example, MME, SGSN, MSC, eNB/NodeB, or HSS/HLR). The 3GPP-network specific events may also be pre-configured in the MTC devices.

[0065] The configuration command may be initiated by the MTC server.

Alternatively, the configuration command may be initiated by the 3GPP network entities (for example, MME, SGSN, MSC, eNB/NodeB, HSS/HLR, and the like). Alternatively, the device may inform the network or the MTC server of its configuration for validation by the 3GPP network or by the MTC server. For example, if a device is preconfigured to detect and report certain events, the device may periodically (for example, upon predetermined configurable time interval), upon power up, upon attachment to the network, or upon tracking, routing, or location update, report its configuration information to the 3GPP network of MTC server for validation.

[0066] In the case where the configuration is initiated by a 3GPP network entity, the configuration may not be reported to the MTC server or any receiving entity outside of the 3GPP network.

[0067] In the case where the configuration is initiated by the MTC server, the configuration information may be carried transparently across the 3GPP network. This may be the case if the 3GPP network does not need to be informed of the configuration detail. Alternatively, the configuration information may be carried in a non-transparent manner across the 3GPP network. This may be the case if the 3GPP network needs to be informed of some of the events or all the events being configured.

[0068] Alternatively, in the case where the configuration is initiated by the MTC server, the report (once a configured event is detected) from the WTRU may be carried transparently across the 3GPP network. Alternatively, the report may not be carried transparently to the 3GPP network. This may be the case if the 3GPP network needs to be informed of some or all of the events.

[0069] MTC monitoring may be configured at a WTRU. The 3GPP network- specific events that may be detected by a WTRU include, but are not limited to, association of an MTC device and a UICC, change in point of attachment, loss of connectivity, abnormal network behavior, unauthorized change in device configuration, device capability, or device software (for example, modem software, firmware, driver, and the like).

[0070] Embodiments for MTC device group configuration are disclosed hereafter. The same monitoring events may be configured for a group of MTC devices. Figure 3 is a signaling diagram of an example process for MTC group configuration. Figure 3 includes an MTC device group 301, an eNB 302, an MME 303, an MTC-IWF 304, an HSS/HLF 305, and an MTC server 306.

[0071] Common monitoring configurations, (such as event specific triggering conditions, thresholds, reporting configurations, prohibit time, and the like) may be grouped into, for example, a new system information block (SIB) or part of an existing SIB and may be broadcasted 307 in a cell. The MTC device group 301 that are subject to the monitoring may read and update this SIB. Whether the MTC device group 301 is subject to the monitoring or not is a device configuration that may be pre-configured or configured through OMA DM, and the like.

[0072] A monitoring configuration command may be transmitted 308 from the MTC server 306 to the MTC-interworking function (IWF) 304, for example, over the Tsp interface. The monitoring configuration command may not include common configuration data which has already been broadcasted in the SIB, and may include the following information: a group device identifier, (for example, 3GPP identifier such as a group IMSI or some external identifier such as a session initiation protocol (SIP) uniform resource identifier (URI)), a list of event IDs to be configured at the WTRU side, a list of area identification (for example, cell lists, tracking area identity (TAI), and the like) where the devices inside the areas will be configured.

[0073] The MTC-IWF 304 may inquire 309 the HSS/HLR 305 for the location of the targeted device group, (for example, with which MME(s) 303 the group of devices are registered). If specific areas are indicated in the configuration command, the MTC-IWF 304 may include area information in the inquiry signaling to locate the group. The MTC-IWF 304 may also retrieve the 3GPP group identifier and other necessary information. The HSS/HLR 305 may transmit 310 an inquiry result to the MTC-IMF 304 with the requested information.

[0074] The MTC-IWF 304 may forward 311 the configuration request to the related MME 303, SGSN, or MSC/VLR. The MTC-IWF 304 may include in the configuration request the 3GPP group identifier which it has retrieved from the HSS/HLR 305.

[0075] The MME 303, SGSN, or MSC/VLR may initiate 312 group paging procedure inside the designated areas, and include the necessary configuration data in the paging message with the MTC device group 301. An additional indication may also be included indicating that the paging is for group monitoring configuration and there is no need to respond. To ensure the success of the group configuration, the group paging procedure may be repeated several times.

[0076] It should be noted that all the configuration procedure and parameters disclosed above may also apply to the non-3GPP network specific events monitoring as long as the configuration is at the WTRU side.

[0077] Embodiments for MTC monitoring configuration at the

MME/SGSN are disclosed. The 3GPP network- specific events that may be detected by the MME/SGSN include, but are not limited to, association of an MTC device and a UICC, change in point of attachment, loss of connectivity, and the like.

[0078] FIG. 4 is a signaling diagram of an example process for monitoring configuration at the MME/SGSN. Figure 4 includes an MME 401, an MTC-IWF 402, an HSS/HLR 403, and an MTC server 404. Similar to the embodiment disclosed above for monitoring configuration at the MTC device/WTRU, a monitoring configuration command may be transmitted 405 by the MTC server 404 to the MTC-IWF 402 over the Tsp interface. An indication may be included in the monitoring configuration command to indicate that the monitoring is configured at the MME/SGSN instead of the WTRU.

[0079] The MTC-IWF 402 may authorize the configuration request first.

If the request is valid, the MTC-IWF 402 may interrogate 406 the HSS/HLR 403 for the location (for example, registered MME 401) of the device that is to be configured, and retrieve 407 the 3GPP identifier (for example, IMSI) of the device and other additional information. The MTC-IWF 402 may initiate parallel inquiries if more than one device is included in the configuration command.

[0080] The MTC-IWF 402 may forward 408 the configuration request to the MME 401, SGSN, or MSC/VLR with which the targeted MTC device is registered. The MTC-IWF 402 may replace the device identifier(s) with the 3GPP identifier(s) which it has retrieved from the HSS/HLR 403.

[0081] Upon reception of the monitoring configuration, the MME/SGSN

401 may store the monitoring configuration in the WTRU's context and may respond 409 to the MTC-IWF 402 with a configuration confirmation message. The confirmation may be forwarded back 410 to the MTC server 404.

[0082] The above procedure may also be used for monitoring a group of

MTC devices at the MME/SGSN side with a few differences or additions as follows. An MTC device group ID may be included in the configuration command instead of individual device IDs. A list of area identification (for example, cell lists, TAI, etc.) may be included in the configuration command. If area identifications are included in the configuration command, the MTC- IWF 402 may include them in the inquiry signaling to the HSS/HLR 403 to locate the targeted MME(s) 401, and the MTC-IWF 402 may also retrieve the 3GPP group identifier from the HSS/HLR 403. The MTC-IWF 402 may include the 3GPP group identifier in the configuration request message between the MTC-IWF 402 and the targeted MME 401.

[0083] Embodiments for MTC monitoring configuration at the eNB or

RNC are disclosed. The 3GPP network- specific events that may be detected by the eNB or RNC include, but are not limited to, alignment of WTRU behaviors and configured features, change in point of attachment, loss of connectivity, and the like.

[0084] FIG. 5 is a signaling diagram of an example process for MTC monitoring configuration at the eNB or RNC. Figure 5 includes an eNB 501, an MME 502, an MTC-IWF 503, an HSS/HLR 504, and an MTC server 505. Similar to the embodiments disclosed above, a monitoring configuration command may be transmitted 506 from the MTC server 505 to the MTC-IWF 503 over the Tsp interface. An indication that the monitoring is configured at the eNB or RNC instead of the MME may be included in the monitoring configuration command. [0085] The MTC-IWF 503 may authorize the configuration request first.

If the request is valid, the MTC-IWF 503 may interrogate 507 the HSS/HLR 504 for the location (for example, registered MME) of the device that is to be configured, retrieve the 3GPP identifier (for example, IMSI) of the device and other additional information. The MTC-IWF 503 may initiate parallel inquiries if more than one device is included in the monitoring configuration command. The HSS/HLR 504 may transmit 508 an inquiry result to the MTC-IMF 503 with the requested information.

[0086] The MTC-IWF 503 may forward 509 the configuration request to the MME 502, SGSN, or MSC/VLR with which the targeted MTC device is registered. The MTC-IWF 503 may replace the device identifier(s) with the 3GPP identifier(s) which it has retrieved from the HSS/HLR 504. An indication that the monitoring is configured at the eNB 501 or RNC instead of the MME 502 may be included in the configuration request.

[0087] The MME 502 may locate in which eNBs 501 the targeted devices are currently connected. If the devices are not currently connected, the MME 502 may try to find the most possible eNBs 501 that the devices are probably connected to, (for example, the previously connected eNBs). Then the MME 502 may forward 510 the configuration request to those eNBs 501 through the Si -MME or Iu signaling. The eNBs 501 may transmit 511 a configuration confirmation to the MME 502. The MME 502 may forward 512 the configuration command to the MTC-IWF 503. The MTC-IWF 503 may forward 513 the configuration command to the MTC server 505.

[0088] If the MTC monitoring for some device is configured in the eNB and a handover happens for this device, the source eNB (where the monitoring is configured) may forward the configuration among other WTRU context to the target eNB over X2 interface.

[0089] Embodiments for MTC monitoring configuration at the HSS/HLR are disclosed. The 3GPP network- specific events that may be detected by the HSS/HLR include, but are not limited to, association of MTC device and UICC, and the like. [0090] FIG. 6 is a signaling diagram of an example process for MTC monitoring configuration at the HSS/HLR. Figure 6 includes an MTC-IWF 601, an HSS/HLR 602, and an MTC server 603. A monitoring configuration command 604 may be transmitted by the MTC server 603 to the MTC-IWF 601 over the Tsp interface. The monitoring configuration command may include a device ID, a list of device IDs, or a group ID of the MTC device(s) that is/are requested to be monitored. The device ID, the list of IDs, or the group ID may be 3GPP identifiers (such as IMSI, or IMEI) or external identifiers (such as E.164 Mobile Station International Subscriber Directory Number (MSISDN), or Fully Qualified Domain Name (FQDN)), or newly defined identifiers. The monitoring configuration command may also include an indication that the monitoring is configured at the HSS/HLR, and/or a list of event IDs to be configured at the HSS/HLR side.

[0091] For each of the events in the configured event ID list, the event

ID specific parameters, like the conditions under which the event may be triggered, and threshold parameters may also be configured.

[0092] For each of the events in the configured event ID list, reporting configurations may be configured which may include the reporting type. The reporting type may be one of the following: a periodic reporting (without event triggered), an immediate reporting after an event triggered, a periodic reporting after an event triggered, or the like.

[0093] The configuration command may also include a prohibition time.

After one specific event is triggered and reported, a prohibition timer may be started to prevent the same event from being triggered and reported again.

[0094] The MTC-IWF 601 may transmit a monitoring configuration request 605 to the HSS/HLR 602. The HSS/HLR 602 may transmit a monitoring configuration ACK 606 to the MTC-IWF 601. The MTC-IWF 601 may transmit a monitoring configuration ACK to the MTC server 603. The MTC-IWF 601 may authorize the monitoring configuration request first. If the request is valid, the MTC-IWF 601 may request the HSS/HLR 602 to store the configuration data in the WTRU profile for each identified WTRU or WTRU group.

[0095] Even though the embodiments for configuration at different entities are separately described above, the configuration may be done at more than one entity. For example, to monitor the mismatch in authentication, such as mismatch between an MTC device and its UICC, it may be configured at both the HSS and the MME for that event. Any combination of the above embodiments may be implemented.

[0096] Embodiments for MTC device monitoring event detection are disclosed hereafter. The monitored events may be a mismatch between an MTC device and a UICC, alignment of WTRU behaviors and configured features, change in geographic locations and point of attachment, loss of connectivity, the WTRU abnormal behavior, or the like.

[0097] FIG. 7 is a signaling diagram of an example process for IMSI-

IMEI mismatch detection at the WTRU. Figure 7 includes an MTC device, or WTRU, 701, an eNB 702, an MME 703, an MTC-IWF 704, an HSS/HLR 705, and an MTC server 706. The mismatch between an MTC device and a UICC may be caused by replacing the UICC in the MTC device with another UICC card, or using the MTC device's UICC card in another device. Either the new UICC or the new device may be valid and may pass the normal authentication of the network. However, the MTC service provider or the network operator may not allow such kind of abuse of MTC devices.

[0098] It is assumed that both the UICC and the device are genuine and may pass the normal authentication and provide a method to detect mismatch between the UICC and the device, (for example, mismatch between the IMSI and the IMEI). The monitoring of the mismatch may be configured at different entities, (for example, the WTRU, the MME, or the HSS), and the detection may take place at different entities. For example, a personalization feature may allow the WTRU (for example, mobile equipment (ME)) to check the UICC against pre-configured information and if it fails, the WTRU may work in a limited service state. However, this method may be limited in its use as it may not check the situation when the UICC card is placed in other devices, and the check cannot be dynamically configured or de-configured.

[0099] In one embodiment, if a WTRU 701 is configured to monitor the mismatch between the UICC and the device, the WTRU 701 may transmit an indication in the initial attach message 707, TAU request message, service request message, or other WTRU-to-MME NAS messages that the WTRU requires valid IMEI information to the MME 703.

[0100] Upon receiving the indication from the WTRU 701, the MME 703 may request the valid IMEI information 708 from the HSS/HLR 705 in which an IMSI-IMEI pair has already been configured in the WTRU's database. One IMSI may have more than one associated valid IMEI, or vice versa, and more than one IMSI may be associated with the same IMEI.

[0101] The MME 703 may transmit the valid IMEI information in a ciphered NAS message 709 to the WTRU 701, (for example, Attach Accept, TAU Accept message, or any other NAS message).

[0102] The WTRU 701 may check the received valid IMEI against the

IMEI in the device 710, and if it does not match, the configured monitoring event may be triggered and a monitoring report 711 may be transmitted to the network or MTC application server 706. The WTRU 701 may enter the limited service state 712 before or after the report has been transmitted.

[0103] Embodiments for detecting alignment of WTRU behaviors and configured features are disclosed hereafter. There are cases to monitor whether the MTC behavior is compliant with the configured feature. For example, the network may need to monitor whether the MTC operator deploys and configures its MTC devices compliant to the services agreed. Another example is that the MTC operator may want to know whether the deployed MTC devices behave as they are configured.

[0104] There is undefined number of WTRU behaviors. Some of them may be tied up to a specific feature of a certain type of MTC devices. In one embodiment, a new interface may be defined between the MTC-IWF and the Operation, Administration, and Maintenance (OAM). Through this interface, the network operator and the MTC server may configure the network to monitor the specific behavior of the MTC devices. The event configuration and evaluation may be performed by proprietary procedure. The system may provide some basic functions to support the OAM monitoring function. The functions may provide measurements on the number of TAU/RAU for a specific MTC device or group of MTC devices, provide measurements on the total traffic per access priority (for example, low, normal, high, or emergency) of a specific MTC device or group of MTC devices over a certain period of time, provide measurements on the frequency of network access per access priority (for example, low, normal, high, or emergency) of a specific MTC device or group of MTC devices over a certain period of time, and/or provide measurements on the frequency of handover of a specific MTC device or group of MTC devices over a certain period of time.

[0105] Embodiments for detecting change in geographic location or point of attachment are disclosed hereafter.

[0106] The geographic region may be defined, for example, as a cell, a list of cells, a tracking area identity (TAI), a list of TAIs, a GPS defined location, a predefined route, a town, city, state, country, or the like. Since the MTC operator may have specific requirements for this measurement, some of them may be out of the 3GPP scope.

[0107] For the measurements that are supported by 3GPP, the MTC server may transmit a monitoring request to the MTC-IWF. For some types of monitoring events, the MTC-IWF may configure the HSS to monitor it. For some other type of monitoring events that may need WTRU support, the MTC- IWF may forward a request to the MME and the MME may configure the WTRU, via existing or new NAS message.

[0108] When the WTRU detects the event, the WTRU may report it to the MME and the MME may forward the event report to the MTC-IWF or the MTC server. When the HSS detects the event, the HSS may forward the event report to the MTC-IWF or the MTC server. [0109] The change in location or point of attachment may be detected by the MTC device (WTRU). The MTC device may be attach point restricted or location restricted.

[0110] In the case of attach point restriction, attach point restricted

MTC devices (WTRUs) may be pre-configured or configured with an allowed- site white-list. One or more attach point identity descriptions may be included in the list. The device, upon mobility, may need to check to determine whether a detected attach-point (for example, a base station) is camped on with cell reselection or is connected through a handover belonging to the white-list. If the MTC device (for example, WTRU) is brought or forced to reselect or to be handed over (for example, no other base station detectable is on the white-list) to an attach point that is not in the white-list, the MTC device may need to report an "out of allowed attach point" event.

[0111] In the case of location restriction, the MTC device may be confined within one or more geographical sections marked by the geographical coordinates. In this case, the white-list may contain the set of coordinates for the allowed geographical sections. In this case, the GPS application may measure the coordinates of the device/WTRU location if it is on the move. An "out of allowed location" event may be reported if the MTC device/WTRU is brought to a place where its location coordinates are not contained in the white-list.

[0112] The change in location or point of attachment may be detected by the network nodes. The network nodes (for example, the eNodeB or the MME) may be configured to detect the violation of the mobile device/WTRU with respect to its location confinement or attach-point restriction. The employed network nodes may be configured on the coordinates of the location confinement or the MTC device/WTRU identities of the relevant WTRUs.

[0113] For location confinement detection, the network nodes (for example, the eNodeB, the MME, the evolved Serving Mobile Location Center (E-SMLC), and the like) may invoke 3GPP positioning or location service procedures to collect the monitored device/WTRU location information and to determine if the monitored device/WTRU is out of its location confinement area.

[0114] For attach-point restriction, the network nodes may request the attaching device/WTRUs to report its device/WTRU-identity. The attach-point restricted MTC devices/WTRUs may report its device/WTRU identities and/or the allowed attach-point identities. When in an idle state, the device/WTRU may reselect onto a new cell that is not in the white-list if the white-list is present. If the white-list is not present, there may be no restriction of the attach point and the WTRU may reselect any suitable cell following the existing rules. The device/WTRU may include, for example, in an RRC Connection Request message, its WTRU-ID (such as IMSI, System Architecture Evolution (SAE) Temporary Mobile Subscriber Identity (S- TMSI), MTC-ID, and the like) and an establishment cause of, for example, "MTC-Monitoring-report". The device/WTRU may also include the allowed attach-point IDs, for example, in the RRC Connection Complete message. The eNB after acquiring the WTRU-ID or the attach-point IDs may terminate or release the RRC connection.

[0115] If the attach-point is configured with the allowed WTRU-IDs, it may detect the violation by comparing the reported and the configured device/WTRU identities. If the attach-point is not configured with the allowed WTRU-IDs but obtains the allowed attach-point identities from the device/WTRU, it may compare the reported attach point identity with its own and detect the violation if the identities do not match.

[0116] For handing-over attach-point restricted MTC devices/WTRUs, the WTRU-ID or the allowed attach-point IDs may be provided to the new cell via X2 Handover Request messages. This way the network node may be able to detect the attach-point violation.

[0117] The MTC devices that are monitoring timing critical events, (for example, earthquake, tsunami, and the like) may need to be able to connect to the network; therefore they may report on the timing critical events on time. The network or the MTC sever may need to know whether these devices are functioning normally and are able to access to the network. If those devices lose their connectivity, the network or the MTC server/operator may need to know in a timely fashion. The MTC server/operator may configure the maximum time of delay of knowing the loss of connectivity of the device. The required time of detecting the loss of connectivity may be shorter than the periodic TA update timer.

[0118] Network nodes (for example, MTC-IWF, MME, eNB, and the like) may be configured to perform the MTC device connectivity monitoring. The configured node may probe one or more particular device/WTRU periodically. For example, the configured node may solicit a WTRU response. An MTC-IWF may make MTC device triggering. An MME may either transmit paging or a dedicated message. An eNB may page or transmit an RRC message (such as UEInformationRequest or a new RRC message/MAC- CE) for the WTRU probing purpose.

[0119] The paging method may have a signaling overhead because the base stations in one or multiple tracking area(s) may need to page the WTRU. In an alternative embodiment, a special "search area" may be defined for the WTRU that the network may monitor for its connectivity. The special "search area" may be as small as a single cell or as large as a paging area. A WTRU may indicate to the network if it moves out of the search area. Therefore, the network may limit the WTRU in a small area and reduce the paging overhead.

[0120] The paging or other kind of NAS message may force a WTRU to enter into a connected mode. As an alternative embodiment, a procedure may be implemented for the probing purpose such that the network may know whether the WTRU is still alive without establishing a live RRC connection.

[0121] To probe the WTRU, the network may use a special paging

(special probe-radio network temporary identity (RNTI)) containing an assigned special RACH preamble. When an MTC device receives the paging, the MTC device may initiate a RACH attempt with the assigned RACH preamble. When the network detects the preamble, the network knows that the WTRU's connection with the network is still functioning normally. [0122] In case the targeted device/WTRU does not render the expected response, the network node may report the "loss of connectivity" event. The network node may repeat the probing action N times with a T interval (N & T are configurable) before reporting the "loss of connectivity."

[0123] In another embodiment, the network may configure the WTRU to periodically transmit a connection test message to the network. The message may be an MTC special TAU that may be configured at much shorter time period compared to the normal periodic TAU. The period may be shorter than the required maximum time between the actual loss connectivity and the detected loss of connectivity given by the MTC server, OAM, HSS, or MME, and the like

[0124] When a network receives the WTRU message, the network may know that the WTRU's connection to the network is good. Otherwise, if the network misses consecutively N number of WTRU periodic messages, (N is configurable and may be set as small as 1), it may report the "loss of connectivity".

[0125] If a device/WTRU is pre-configured or configured to detect the Uu connectivity, the device/WTRU may perform the air link checking periodically.

[0126] For the detection of downlink connectivity, a WTRU may check the cell downlink transmissions over the common channels (such as broadcast, paging or RACH access response (RAR)) or check on the cell specific reference signals for reference signal received power (RSRP) or reference signal received quality (RSRQ). If the WTRU may not decode the downlink signals or the received signal power and the quality is below the cell selection threshold, the WTRU may determine that the downlink connectivity is lost.

[0127] For the detection of uplink connectivity, a WTRU in an idle mode may start the RACH access procedure and check the random access response (RAR) to see if the eNB responds appropriately. A WTRU in a connected mode may apply an uplink grant and/or transmit an acknowledged mode (AM) RRC message (such as UplinklnformationTransfer with a special indicator) or a medium access control- control element (MAC-CE) to see if the eNB responds appropriately.

[0128] The device/WTRU may perform the "loss of connectivity" reporting upon detecting the loss immediately, if the device/WTRU may attach and connect through another base station (include another radio access technology (RAT)) and transmit the report message. The message may be directly addressed to the target MTC device monitoring report receive entity. Alternatively, the device/WTRU may report at a later time when the lost connectivity is regained.

[0129] An MTC device is not under human supervision and therefore when it malfunctions, it may disrupt normal system operation.

[0130] The MTC device abnormal behavior that the network is interested in may be the behavior that may interrupt the network behavior. These behaviors include, but are not limited to, too many retransmission and transmission errors, too many dropped communications, too frequent network accesses, too many network access failures, repeated messages, unnecessary message, unexpected message, or abnormal traffic, and the like.

[0131] The network may be able to detect the above abnormality and take corresponding action(s) to maintain the network normal functions. Too many retransmission and transmission errors may be detected by the eNB and reported to the MME or OAM. Too many dropped communications, too frequent network accesses, and too many network access failures may be detected by the MME and reported to the OAM. Control plane repeated messages, unnecessary messages, or unexpected messages may be detected by the MME and reported to the OAM.

[0132] Abnormal traffic may include too many TCP session create messages to a specific IP address, too much traffic to an APN/IP address, redundant or identical IP package, redundant or identical or overwhelmed SMS messages, or the like. Redundant or identical or overwhelmed SMS messages may be detected by the MME or the MSC and reported to the OAM and/or the MME. The rest of the abnormal traffic may be detected by the PGW and reported to the OAM and/or the MME.

[0133] Embodiments for MTC device monitoring event reporting are disclosed hereinafter. The reporting may be individual reporting or group based reporting.

[0134] For group reporting, the reported information may be consolidated at an MTC device (for example, an MTC device acting as a relay to neighboring MTC devices) or the report information may be consolidated in a network node (for example, MME, SGSN, MSC, eNB, Node B, SMS-SC, and the like). The events to be reported may be standardized with predefined labels or values. As such, for any given event, a single bit may be used to report the event. The reporting may be signaled at the physical layer level or above the physical layer.

[0135] In MTC device monitoring event reporting, both the devices

(WTRUs) and the network nodes that are tasked or configured to do so may report the predefined or configured events to the their designated report receiver(s) according to the predefined or configured report scheduling, resource allocation, event generation or triggering conditions, and the report priority definition, and the like.

[0136] Depending on the designated MTC device functionality and the configuration or pre-configuration, different forms of MTC monitoring reporting may be configured.

[0137] The reporting may be periodic. The reporting entity (for example, a device/WTRU or a network node) may perform the reporting according to a predefined or configured interval, (for example, every 5 minutes, every one hour, or every day) or in a configured time range (for example, every 10 minutes between 9pm to 6am and every 30 minutes between 6am and 9pm). The periodic reporting for MTC device monitoring may be deployed to monitor the general (or normal) operation status of the device and the specific functionalities that the device is designated to perform at the deployed site of the device. [0138] The reporting entity (for example, a device/WTRU or a network node) may either take a snapshot status of the device operation/functioning or accumulate status during the reporting interval and generate and transmit a report in the end of the report interval (with or without processing such as filtering, averaging, or the like).

[0139] The monitoring report receiver entity may collect the report and determine the device operating status and corresponding actions based on the reading of the reported contents, for example after filtering or other statistical processing.

[0140] The monitoring entity receiver may count the periodic report flow in order to determine the overall alive- status of the device and the connectivity- status to/from the device.

[0141] The reporting may be event triggered. The reporting entity may perform a special reporting when one or more predefined or configured event condition(s) occur. The reporting entity may be configured to perform the special event reporting immediately with a priority. Alternatively, the reporting entity may start to accumulate the event contents or event related contents until the next MTC device/WTRU uplink connection/reporting time. Alternatively, the event may be reported when the reporting entity (for example, a device/WTRU or a network node) is polled or triggered by the network or the monitoring entity.

[0142] The reporting may be event triggered periodic reporting. The reporting entity may perform periodic reporting once the predefined or configured event occurs. The reporting entity may perform a first event report. The reporting entity may be predefined or configured to report N times on a fixed time interval and then stop. Alternatively, the reporting entity may be predefined or configured to report periodically until the event triggering condition(s) are no longer met or the condition meets a different stopping threshold value.

[0143] Alternatively, the reporting entity may be predefined or configured to report with increasing or decreasing frequency (for example, adjustable reporting intervals or prohibit time) on different measured/monitored levels, degrees, amount or numbers of the monitoring objects (for example, temperatures, pressures, chemical concentrations, cars passing, and the like), once the event is triggered. The reporting may stop when the base triggering condition no longer exists or meets a different stopping criterion.

[0144] In many cases, the MTC device monitoring with triggered event reporting may be used for better (or more precisely) defined events whose occurrence is less often. The triggered event reporting may avoid unnecessarily consuming network resources unless the defined event is triggered. However, the triggered event may need timely reporting, (for example, may need immediate network accommodation with high priority).

[0145] The reporting may be network solicited or polled reporting. The network (or the network on behalf of the MTC server, application, user, or subscriber) may transmit a polling message soliciting the MTC device/WTRU for MTC device monitoring report (for example, the polling may be considered as a report trigger alternative). The polling message may solicit one or more reports from the device/WTRU with one report category or different report categories (for example, a snap shot report, a summed report, or an averaged report, and the like). The message may specify one or more report occasion(s) or resource(s) with one or different reporting priorities. The message may specify one or more target monitoring report receive entity for a report and a different signaling route for a report. The network may use the polling message to change the MTC device monitoring configuration to the device/WTRU, (for example, changing the reporting mechanism from periodic to polled or to event triggered).

[0146] A combination of any of the above described reporting forms or mechanisms may be employed, (for example, the polled reporting plus the event triggered reporting). In this case, the MTC device monitoring may operate with the event triggered reporting to report the precisely measured and evaluated events. When the MTC monitoring application, server, user, or subscriber needs to know the monitored situation, the network may transmit the polling message to retrieve the monitoring report, which may be one or more snap-shot of the current status or an accumulated report or a combination of the two.

[0147] Embodiments for reporting procedure and signaling are described hereafter.

[0148] The MTC device monitoring may employ a network node(s) (RAN nodes, CN controlling nodes, and/or CN data gateway nodes) for MTC device monitoring and reporting. The network nodes may use a generic formatted message or one or more formatted information element (IE) to perform the designated reporting.

[0149] The generic path of the reporting (assuming the target is the application server) may take, for example, the following generic control path over the CN controlling node (such as MME and SGSN) and 3GPP MTC-IWF node as follows: eNB/NB/RNC to MME/SGSN to MTC-IWF to MTC-server to application server; or SGW/GGSN to MME/SGSN to MTC-IWF to MTC server to application server; or PGW to SGW to MME to MTC-IWF to MTC-server to application server.

[0150] Alternatively for the SGW and the PGW, if the PGW connects physically or logically to the application server, the reporting path may be the SGW to the PGW to application server; or the PGW to application server.

[0151] The MTC device monitoring report message or the report IE(s) may be formed as a new message at a new specific MTC AP protocol level; or a new message created at a 3GPP wireline interface application protocol level, (for example, Sl-AP or T5-AP or GTPv2 over Sll and over S5/S8 interface, such as the Sl-AP "UPLINK/DOWNLINK NON WTRU LPPA TRANSPORT" messages); or one or more specific IEs carried by the application interface (as disclosed above) level transport message such as the Sl-AP UPLINK/DOWNLINK NAS TRANSPORT messages.

[0152] The intermediate node (for example, the MME) may need to transfer the message from one interface to the next at the terminating point, (for example, the MME may need to take the eNB report message content from a message over the Si interface to a T5 interface message towards the MTC-IWF).

[0153] The above wireline transport of MTC device monitoring report messages may also apply to reports generated from a MTC device/WTRU.

[0154] For an MTC device monitoring report generated by a device/WTRU, it may take one of two forms. The report content may be contained in an SMS or MTC application level or the report may be contained in a message in a network transport protocol level.

[0155] The report may take the U-plane path between the device/WTRU and the MTC monitoring entity, if one exists at the reporting time, or if the reporting data volume and/or duration exceed some limit.

[0156] The reporting path may take the form of a generic message over

WTRU->(eNB)->MME->IWF->MTC server or an SMS over WTRU->MME- >SMS-SC->MTC server, if the U-plane connectivity does not exist at the reporting time and one or more of the following condition is met: an MTC device monitoring report or an event report may include less or equal number of octets than a maximum number definition; or the delivery is one-time within a certain time period (for example, once every X seconds or longer). The periodic status report and event triggered report may fall into this category.

[0157] If the MTC device/WTRU under monitoring is outside of its normally defined location range but it has been configured or authorized to issue a report outside the defined location range, the reporting procedure may follow the following procedure.

[0158] If the MTC device/WTRU does not have an RRC connection, the device/WTRU may establish one with high priority or a special establishment cause. The device/WTRU may include in the subsequent first NAS message, (for example, ATTACH REQUEST, (EXTENDED) SERVICE REQUEST or TRACKING AREA UPDATE REQUEST), an indicator for lifting the MTC device monitoring specific area/public land mobile network (PLMN) restriction (for example, for allowing the device/WTRU at any network access point). [0159] The device/WTRU may include in the same message the authorization code (for example, for anti-theft, emergency, and the like) of such an access action. The device/WTRU may include in the same message the trigger event report (for example, for actions such as anti-theft, anti- confinement-break, illegal trafficking, and the like). The device/WTRU may include other MTC device monitoring triggered event parameters such as the access priority, the target monitoring entity address, the routing address, and the like. The device/WTRU may then transmit the report as soon as possible.

[0160] The MTC device monitoring report may have at least two main parts: the report part (or the triggered event report part) and the header part (network trafficking part) that may help the report navigate through the network to the reporting destination.

[0161] A normal MTC device monitoring report may include the following parameter contents from the reporting entity to the monitoring (report receive) entity.

[0162] Reporting device identities may be included in the report (for example, the network recognized IMSI or MTC-ID, or the MTC device monitoring layer or MTC application, user, subscriber, or server recognized MTC device identity(s)). Report device location parameter may be included in the report (for example, the network recognized locations (such as area-ID or cell-ID), the GPS or other positioning system coordinates, or the MTC application, layer, server, user, or subscriber recognized location information).

[0163] Report definitions and report parameter values may be included in the report, such as a designated functionality report code (normal function, malfunction, dysfunction), or device functionality specific parameter values (for example, MTC application specific).

[0164] A triggered event report may need to be delivered as soon as possible. Thus, it may mark the "report priority" with a high value. In addition, it may include a triggered event including triggered event- ID(s) and related event parameter values, triggered time or time period, other monitored or measured conditions associated with the monitoring task or the reporting event, reporting device identities, reporting device location parameters, or the like.

[0165] The network traffic control part (header) may bear the significance of how the report is treated during its traffic to the destination. The header may include name and address of the ultimate monitoring report receiving entity (for example, an SCS or an application server or an MTC device monitoring OAM entity or a MTC-IWF), which may include its IP address, Hyper Text Mark-up Language (HTML) address, PLMN related address, and the like. The header may include routing address, which may include the PLMN and other network identities of the MME/SGSN or the MTC-IWF that finally delivers the report to its destination. The header may include report priority. A normal or top level priority may help the report overcome many restrictions associated with lower priority activities. The report top priority value may be indicated in the RRC Connection Request message or the NAS messages such as the ATTACH REQUEST, the TRACKING AREA UPDATE REQUEST, the EXTENDED SERVICE REQUEST or SERVICE REQUEST, or the UPLINK (GENERIC) NAS TRANSPORT, or the like.

[0166] In general, the MTC device/WTRU traffic may be considered low- priority and somehow delay-tolerant in terms of air link access right and network transport scheduling and it may be subject to various MTC device mobile originated activity restrictions, (for example, the extended access barring, the normal access barring, and network congestion control, and the like). However, in case of MTC device monitoring report and triggered event reporting, certain event reporting may be urgent and therefore may need to be transmitted immediately or timely. Hence the application-level WTRU report or the 3GPP configured WTRU report from an MTC device/WTRU may need to override certain network restrictions associated with at least the "low-priority" to expedite the report delivery.

[0167] In one embodiment, the MTC device/WTRU may be given certain privileges to override access or delivery restrictions. The network restrictions and parameter values may be overridden by an urgent MTC monitoring event report from an MTC device/WTRU including, but not limited to, low priority delay tolerant indication and/or low priority backoff timer, normal priority backoff timer, extended access barring (EAB) or EAB access class restrictions or EAB roaming categories, normal access barring, blacklisted (neighbor) cell access restrictions, primary or secondary cell access restrictions in carrier aggregation, TAI, routing area identity (RAI), or location area identity (LAI) network area access restrictions, PLMN or roaming network restrictions, closed subscriber group (CSG) membership restrictions, or the like.

[0168] The MTC device, under the circumstances, may employ the high priority (or emergency priority higher than normal priority) which may then help the MTC device/WTRU override the restrictions associated with lower priority (or normal priority) activities.

[0169] The MTC device monitoring report may be explicitly configured to possess "emergency priority" (or high priority). The MTC device/WTRU may use this specifically configured emergency/high priority to acquire the needed resources to air or landline connectivity by default. The MTC device/WTRU may select to use the configured emergency or high priority when the urgent situation requires, such as reporting of natural disaster signs or public safety warnings.

[0170] The MTC device monitoring event reporting may be predetermined or preconfigured to have the capability of automatic priority elevation (for example, to employ the top level access priority on high severity or emergency event reporting. With this top priority, an MTC device monitoring event report may overcome access and transmit restrictions and be delivered to the monitoring (report receiving) entity as soon as possible.

[0171] For MTC device monitoring, it may be defined that a certain

MTC device monitoring report may be configured to have a delay-limit such that when the reporting delay from the defined periodical report moment exceeds a certain time limit (t >= ts + tl, where ts is the time for the scheduled report Tx time and tl is the configured or predetermined delay limit), the report priority may be elevated (for example, from low to normal or to top priority) such that the MTC deviceAVTRU may overcome the currently applicable congestion or access barring control restrictions and may obtain the access resources and transmit the report with the elevated priority to the network and/or to the monitoring entity.

[0172] For example if a car is stolen it may enable the on-board anti- theft device with a top priority to connect to any compatible base- station regardless of the PLMN or tracking area, routing area, or location area restriction to report its location and allow the report to route through the network towards the MTC device monitoring entity usually in the vicinity of its home PLMN.

[0173] In addition to overcome access restrictions, the MTC deviceAVTRU may have some privileges on a RACH access when performing device monitoring reporting (or other low-overhead idle mode WTRU initial access) with one or more of the following measures.

[0174] The device/WTRU may select a RACH access preamble from a specific RACH preamble group (for example, either RACH preamble groups A or B). The deviceAVTRU may employ a stronger initial transmit power (than preamblelnitialReceivedTargetPower). The device/WTRU may employ a larger power-ramping step figure (than powerRampingStep). The deviceAVTRU may have a larger number of maximum Msg3 HARQ (re)transmissions (than maxHARQ-Msg3Tx).

[0175] The MTC device monitoring report may be transmitted in an

SMS or in a formatted message or information element (used in the MTC device monitoring protocol level or the MTC device monitoring application level). If the MTC device/WTRU is in an RRC connected state and is being connected via U-plane to the MTC device monitoring entity, the report message/IE may be initially carried, for example, in the "UPLINK NAS TRANSPORT" message or the "UPLINK GENERIC NAS TRANSPORT " message to the target monitoring report receive entity. [0176] If the MTC device/WTRU is in an RRC connected state but not connected to the MTC device monitoring entity via a U-plane bearer directly or if the MTC device/WTRU is in an RRC idle mode already attached, the report message/IE may be initially carried, for example, over the NAS "SERVICE REQUEST," the "EXTENDED SERVICE REQUEST" message, the NAS "TRACKING (or ROUTING/LOCATION) AREA UPDATE REQUEST" message, or an equivalent new message towards the target monitoring report receive entity.

[0177] If the MTC device/WTRU is not attached to the network, the report message/IE may be initially carried, for example, over the "ATTACH REQUEST" message or an equivalent new NAS message that may serve for both MTC device network registration and report data carrying. For the MTC device monitoring reporting, the message may have an indication which requests the network to relay the MTC device monitoring report to the target monitoring receive entity via an MTC-monitoring-report-path. The MTC- monitoring report path may comprise network control signaling nodes, for example, skipping establishment of the U-plane path from the device/WTRU to the monitoring report receive entity.

[0178] When the network detects an abnormal MTC behavior, it may report it to the MTC server and take action depending on the abnormality type. The system may bar the malfunctioned device from accessing the network. The system may reject the access request from the device and set a barring timer on the device. The system may limit the RACH resource the malfunctioned device may use by setting a barring timer on the device.

[0179] The system may limit the device to certain types of services, (for example, limit the APN it may access, limit the priority it may use, limit the throughput and duration of the connection, limit to emergency only, limit to mobile originated or mobile terminated). The system may use an extended access barring (EAB) to bar the subcategory of malfunctioned MTC devices if necessary. [0180] Embodiments

1. A method for machine-type communication (MTC) group configuration in an MTC-interworking function (IWF), the method comprising: receiving a monitoring configuration command from an MTC server.

2. The method as in embodiment 1, further comprising:

transmitting an inquiry to a home subscriber server (HSS)/home location register (HLR) for a location of a targeted device group.

3. The method as in any one of embodiments 1-2, further comprising:

receiving an inquiry result from the HSS/HLR.

4. The method as in any one of embodiments 1-3, further comprising:

transmitting a configuration request to a mobility management entity (MME).

5. The method as in any one of embodiments 1-4, wherein the monitoring configuration command includes a group device identifier, a list of event IDs, and a list of area identification.

6. The method as in any one of embodiments 1-5, wherein the inquiry result includes a group identifier.

7. The method as in any one of embodiments 1-6, wherein the monitoring configuration command is transmitted over a Tsp interface.

8. A machine-type communication (MTC)-interworking function (IWF) for MTC group configuration comprising:

a receiver configured to receive a monitoring configuration command from an MTC server.

9. The MTC-IWF as in embodiment 8, further comprising:

a transmitter configured to transmit an inquiry to a home subscriber server (HSS)/home location register (HLR) for a location of a targeted device group.

10. The MTC-IWF as in any one of embodiments 8-9, further comprising: the receiver is further configured to receive an inquiry result from the HSS/HLR.

11. The MTC-IWF as in any one of embodiments 8-10, further comprising:

the transmitter is further configured to transmit a configuration request to a mobility management entity (MME).

12. The MTC-IWF as in any one of embodiments 8-11, wherein the monitoring configuration command includes a group device identifier, a list of event IDs, and a list of area identification.

13. The MTC-IWF as in any one of embodiments 8-12, wherein the inquiry result includes a group identifier.

14. The MTC-IWF as in any one of embodiments 8-13, wherein the monitoring configuration command is transmitted over a Tsp interface.

15. A method for detection of a mismatch between a wireless transmit/receive unit (WTRU) and a universal integrated circuit card (UICC) in the WTRU, the method comprising:

transmitting an attach request message to a mobility management entity (MME) including a request for an international mobile subscriber identity (IMSI)-international mobile equipment identity (IMEI).

16. The method as in embodiment 15, further comprising:

receiving an attach accept message from the MME including the requested IMEI.

17. The method as in any one of embodiments 15-16, further comprising:

comparing the received IMEI against the IMEI of the WTRU.

18. The method as in any one of embodiments 15-17, further comprising:

on a condition that the received IMEI does not match the IMEI of the WTRU, triggering a monitoring report to the network.

19. The method as in any one of embodiments 15-18, further comprising: entering a limited service state after the monitoring report has been triggered.

20. The method as in any one of embodiments 15-19, wherein the attach request message is transmitted using non-access stratum (NAS) messaging.

21. The method as in any one of embodiments 15-20, wherein the attach accept message is received in a ciphered non-access stratum (NAS) message.

22. A wireless transmit/receive unit (WTRU) for detection of a mismatch between the WTRU and a universal integrated circuit card (UICC) comprising:

a transmitter configured to transmit an attach request message to a mobility management entity (MME) including a request for an international mobile subscriber identity (IMSI)-international mobile equipment identity (IMEI).

23. The WTRU an in embodiment 22, further comprising:

a receiver configured to receive an attach accept message from the MME including the requested IMEI.

24. The WTRU as in any one of embodiments 22-23, further comprising:

a processor configure to compare the received IMEI against the IMEI of the WTRU.

25. The WTRU as in any one of embodiments 22-24, further comprising:

the transmitter is further configured to trigger a monitoring report to the network on a condition that the received IMEI does not match the IMEI of the WTRU.

26. The WTRU as in any one of embodiments 22-25, wherein the processor is further configured to enter a limited service state after the monitoring report has been triggered. 27. The WTRU as in any one of embodiments 22-26, wherein the attach request message is transmitted using non-access stratum (NAS) messaging.

28. The WTRU as in any one of embodiments 22-27, wherein the attach accept message is received in a ciphered non-access stratum (NAS) message.

[0181] Although features and elements are 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 the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto -optical media, and optical media such as CD- ROM disks, and digital versatile disks (DVDs). A processor in association 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

CLAIMS What is claimed:

1. A method for machine-type communication (MTC) group configuration in an MTC-interworking function (IWF), the method comprising: receiving a monitoring configuration command from an MTC server; transmitting an inquiry to a home subscriber server (HSS)/home location register (HLR) for a location of a targeted device group;

receiving an inquiry result from the HSS/HLR; and

transmitting a configuration request to a mobility management entity (MME).

2. The method as in claim 1, wherein the monitoring configuration command includes a group device identifier, a list of event IDs, and a list of area identification.

3. The method as in claim 1, wherein the inquiry result includes a group identifier.

4. The method as in claim 1, wherein the monitoring configuration command is transmitted over a Tsp interface.

5. A machine-type communication (MTC)-interworking function (IWF) for MTC group configuration comprising:

a receiver configured to receive a monitoring configuration command from an MTC server;

a transmitter configured to transmit an inquiry to a home subscriber server (HSS)/home location register (HLR) for a location of a targeted device group;

the receiver is further configured to receive an inquiry result from the HSS/HLR; and the transmitter is further configured to transmit a configuration request to a mobility management entity (MME).

6. The MTC-IWF as in claim 5, wherein the monitoring configuration command includes a group device identifier, a list of event IDs, and a list of area identification.

7. The MTC-IWF as in claim 5, wherein the inquiry result includes a group identifier.

8. The MTC-IWF as in claim 5, wherein the monitoring configuration command is transmitted over a Tsp interface.

9. A method for detection of a mismatch between a wireless transmit/receive unit (WTRU) and a universal integrated circuit card (UICC) in the WTRU, the method comprising:

transmitting an attach request message to a mobility management entity (MME) including a request for an international mobile subscriber identity (IMSI)-international mobile equipment identity (IMEI);

receiving an attach accept message from the MME including the requested IMEI;

comparing the received IMEI against the IMEI of the WTRU; and on a condition that the received IMEI does not match the IMEI of the WTRU, triggering a monitoring report to the network.

10. The method as in claim 9, further comprising:

entering a limited service state after the monitoring report has been triggered.

11. The method as in claim 9, wherein the attach request message is transmitted using non-access stratum (NAS) messaging.

12. The method as in claim 9, wherein the attach accept message is received in a ciphered non-access stratum (NAS) message.

13. A wireless transmit/receive unit (WTRU) for detection of a mismatch between the WTRU and a universal integrated circuit card (UICC) comprising:

a transmitter configured to transmit an attach request message to a mobility management entity (MME) including a request for an international mobile subscriber identity (IMSI)-international mobile equipment identity (IMEI);

a receiver configured to receive an attach accept message from the MME including the requested IMEI;

a processor configure to compare the received IMEI against the IMEI of the WTRU; and

14. The WTRU as in claim 13, wherein the processor is further configured to enter a limited service state after the monitoring report has been triggered.

15. The WTRU as in claim 13, wherein the attach request message is transmitted using non-access stratum (NAS) messaging.

16. The WTRU as in claim 13, wherein the attach accept message is received in a ciphered non-access stratum (NAS) message.