Method for communication for a machine type communication device and corresponding wireless transmit/receive unit

The present application relates to efficient signaling for machine type communication.

(Cross-reference of related applications) This application is filed with US Patent Provisional Application No. 61/316596, entitled "Methods and MFP for indicating Network Machine Type Communication Capabilities," filed March 23, 2010, and April 2, 2010. US Patent Provisional Application No. 61/320610, entitled "Improving Efficiency by Signaling Reduction for MTC Devices," and "Methods of Improving Power Efficiency by Signaling Reduction for," filed April 29, 2010. Claiming interests with US Patent Provisional Application No. 61/329392 entitled "MTC Devices", the disclosure of which is incorporated herein by reference.

Machine-type communication (MTC) is a form of data communication involving one or more devices or entities that do not necessarily require human interaction to communicate. Measuring or tracking devices are examples of MTC devices. The capabilities of MTC devices can vary and can depend on the requirements of one or more MTC applications.

MTC applications use services such as transport and communication services provided by GERAN, UTRAN, E-UTRAN, such as 3GPP access networks, or other systems for end-to-end communication between MTC devices. it can. For example, MTC applications can use the power of 3GPP systems for end-to-end communication between MTC devices and MTC servers. For example, an MTC device can use the capabilities of a 3GPP system for end-to-end communication with another MTC device. The specific MTC services or capabilities provided by each network may vary.

This specification discloses embodiments for machine type communication (MTC). The disclosed technology can also reduce signaling by transmitting MTC data over the control plane, eliminating the need for all cycles of the typical connection procedure required for transmission. In an exemplary embodiment, MTC data can be attached directly to the control plane message. In addition, to reduce the signaling load, the WTRU can autonomously disconnect without being commanded by another network.

The specification also discloses a technique capable of displaying the machine type communication (MTC) capability of a network provider. One or more of the MTC services can be shared for several MTC applications. Also, one or more MTC services / capabilities can be limited to the requirements of a particular MTC application. The MTC services or capabilities that each network operator can provide can be communicated to WTRU.

An overview of the present invention is provided to introduce one choice of concept in a simplified form of the form for carrying out the invention further described below. The outline of the present invention is not intended to clarify the main features or essential features of the subject matter of the claimed invention, and is not intended to limit the scope of the subject matter of the claimed invention. Moreover, the subject matter of the claimed invention is not limited to the limitation that resolves some or all of the advantages described in any part of this disclosure.

A more detailed understanding can be obtained by combining the following explanation given as an example with the attached drawings.

<figref num="1A">FIG. 6 is a system diagram of an exemplary communication system capable of implementing one or more of the disclosed embodiments.</figref><figref num="1B">FIG. 5 is a system diagram of an exemplary radio transmit / receive unit (WTRU) that can be used in the communication system shown in FIG. 1A.</figref><figref num="1C">It is a system diagram of an exemplary radio access network and an exemplary core network that can be used in the communication system shown in FIG. 1A.</figref><figref num="2">FIG. 5 illustrates an exemplary architectural view of M2M that can incorporate techniques for reducing signal overhead and / or power consumption.</figref><figref num="3">It is an exemplary block diagram of a communication service notification strategy using system information.</figref><figref num="4">It is an exemplary block diagram of a communication service notification strategy using RRC.</figref><figref num="5">It is an exemplary block diagram of a communication service notification strategy using immediate allocation.</figref><figref num="6A">It is an exemplary block diagram of the non-access layer of the communication service notification strategy.</figref><figref num="6B">It is an exemplary block diagram of the communication service notification strategy using the non-access layer.</figref><figref num="7">It is a figure which shows the procedure of RRC connection request.</figref><figref num="8A">It is an exemplary block diagram of a communication service notification strategy using RRC.</figref><figref num="8B">It is an exemplary block diagram of a communication service notification strategy using RRC.</figref><figref num="9">It is an exemplary block diagram of a communication service notification strategy using RRC.</figref><figref num="10">It is an exemplary block diagram of a communication service notification strategy using RRC.</figref><figref num="11">It is an exemplary block diagram of a communication service notification strategy using RRC.</figref>

FIG. 1A is a diagram of an exemplary communication system 100 capable of implementing one or more of the disclosed embodiments. The communication system 100 can be a multiple access system that provides content such as voice, data, video, messaging, and broadcast to multiple wireless users. Communication system 100 allows multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 includes 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. Alternatively, multiple channel access methods can be used.

As shown in FIG. 1A, the communication system 100 includes wireless transmit / receive units (WTRU) 102a, 102b, 102c, 102d, a wireless access network (RAN) 104, a core network 106, and a public switched telephone network (PSTN). Recognizing that 108, the Internet 110, and other networks 112 can be included, but the disclosed embodiments also assume any number of WTRUs, base stations, networks, and / or network elements. I want to be. Each of the WTRU102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. As an example, WTRU102a, 102b, 102c, 102d may be configured to transmit and / or receive radio signals, such as user equipment (UE), mobile stations, fixed or mobile subscriber units, pages, mobile phones. It may include telephones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, home appliances and the like.

Communication system 100 can also include base station 114a and base station 114b. Each of the base stations 114a, 114b wirelessly interfaces with at least one of the WTRU102a, 102b, 102c, 102d to one or more communication networks, such as core network 106, internet 110, and / or network 112. It may be any type of device configured to facilitate access. As an example, base stations 114a and 114b may be base transceiver base stations (BTS), nodes B, e-nodes B, home nodes B, home e-nodes B, site controllers, access points (APs), wireless routers and the like. Although base stations 114a and 114b are shown as single elements, respectively, it should be recognized that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

Base station 114a can be part of RAN104, where RAN is another base station and / or network element (not shown) such as base station controller (BSC), wireless network controller (RNC), relay node, etc. ) Can also be included. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals within a particular geographic area, which may be referred to as a cell (not shown). The cell can be further divided into cell sectors. For example, the cell associated with base station 114a can be divided into three sectors. Thus, in one embodiment, base station 114a can include three transceivers, i.e. one transceiver per sector of the cell. In another embodiment, the base station 114a can use MIMO (Multiple-input multiple-output) technology, so that a plurality of transceivers can be used per sector of the cell.

Base stations 114a, 114b can communicate with one or more of the WTRU102a, 102b, 102c, 102d via the radio interface 116, providing the radio interface with any suitable radio frequency (eg, radio frequency (RF)), It may be microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The radio interface 116 can be established using any suitable radio access technology (RAT).

More specifically, as described above, the communication system 100 can be a multiple access system and can use one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA. .. For example, base stations 114a and WTRU102a, 102b, 102c in RAN104 can establish radio interface 116 using wide area CDMA (WCDMA), such as Universal Mobile Communication System (UMTS) Terrestrial Radio Access (UTRA). Can implement the technology. WCDMA can include communication protocols such as High Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA +). HSPA can include High Speed Downlink Packet Access (HSDPA) and / or High Speed Uplink Packet Access (HSUPA).

In another embodiment, base stations 114a and WTRU102a, 102b, 102c can establish a radio interface 116 using Long Term Evolution (LTE) and / or LTE Advanced (LTE-A), an advanced UMTS terrestrial radio. Wireless technologies such as access (E-UTRA) can be implemented.

In other embodiments, base stations 114a and WTRU102a, 102b, 102c are IEEE802.16 (ie, global interoperability for microwave access (WiMAX)), CDMA2000, CDMA20001X, CDMA2000EV-DO, IS-2000. (Interim Standard 2000), IS-95 (Interim Standard 95), IS-856 (Interim Standard 856), Global System for Mobile Communications (GSM®), Extended Data Rate for GSM Evolution (EDGE) ), GSM EDGE (GERAN) and other wireless technologies can be implemented.

Base station 114b in Figure 1A can be, for example, a wireless router, home node B, home e-node B, or access point, facilitating wireless connectivity in local areas such as offices, homes, cars, and campuses. You may use any RAT that is suitable for you. In one embodiment, base stations 114b and WTRU102c, 102d can implement wireless technologies such as IEEE 802.11 that establish a wireless local area network (WLAN). In another embodiment, base stations 114b and WTRU102c, 102d can implement wireless technologies such as IEEE 802.11 that establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRU102c, 102d can utilize cell-based RATs (eg, WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocells or femtocells. As shown in FIG. 1A, base station 114b can connect directly to the Internet 110. As such, base station 114b does not need to access Internet 110 via core network 106.

The RAN104 can communicate with the core network 106 so that the core network 106 provides voice, data, applications, and / or voice over Internet Protocol (VoIP) services to one or more of the WTRU102a, 102b, 102c, 102d. It may be any type of network configured in. For example, core network 106 can provide call control, billing services, mobile location-based services, prepaid phone, internet connectivity, video delivery, and / or perform high-level security features such as user authentication. .. Not shown in Figure 1A, but be aware that RAN104 and / or core network 106 can be in direct or indirect communication with other RATs using the same or different RATs as RAN104. For example, the core network 106 can be connected to a RAN 104 that uses E-UTRA radio technology and can also communicate with another RAN (not shown) that uses GSM radio technology.

The core network 106 can also act as a gateway for the WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 can include a circuit-switched telephone network that provides traditional voice telephone services (POST). The Internet 110 can include a global system of computer networks and devices interconnected using common communication protocols such as TCP, UDP and IP in the TCP / IP Internet Protocol Suite. The network 112 may include a wired or wireless communication network owned and / or operated by another service provider. For example, network 112 can include another core network connected to one or more RANs, which can use the same or different RATs as RAN104.

Some or all of the WTRU 102a, 102b, 102c, 102d within the communication system 100 can include multimode capabilities. That is, the WTRU102a, 102b, 102c, 102d can include multiple transceivers that communicate with different radio networks over different radio links. For example, the WTRU102c shown in FIG. 1A can be configured to communicate between a base station 114a capable of using cell-based radio technology and a base station 114b capable of using IEEE802 radio technology.

FIG. 1B is an exemplary WTRU102 system diagram. As shown in FIG. 1B, the WTRU102 includes a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, and a removable. It can include a memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be recognized that WTRU102 may include any combination of the above elements, while maintaining consistency with the embodiments.

Processor 118 can be a general purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors that work with a DSP core, a microcontroller, an application specific integrated circuit (ASIC), It can be a field programmable gate array (FPGA) circuit, other types of integrated circuits (ICs), state machines, and so on. Processor 118 can perform signal coding, data processing, power control, input / output processing, and / or other functionality that allows the WTRU102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120 and the transceiver 120 can be coupled to the transmit / receive element 122. Although Figure 1B shows the processor 118 and transceiver 120 as separate components, it should be noted that the processor 118 and transceiver 120 can be combined in an electronic package or chip.

The transmit / receive element 122 can be configured to send and receive signals to and from a base station (eg, base station 114a) via wireless interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmit / receive element 122 can be, for example, an emitter / detector configured to transmit and / or receive an IR, UV, or visible light signal. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and receive both RF and optical signals. Recognize that the transmit / receive element 122 can be configured to transmit and / or receive any combination of radio signals.

Further, although the transmit / receive element 122 is shown as a single element in FIG. 1B, the WTRU102 may include any number of transmit / receive elements 122. More specifically, the WTRU102 can use MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (eg, a plurality of antennas) that transmit and receive radio signals via interface 116.

The transceiver 120 can be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As mentioned above, the WTRU102 can have multi-mode capabilities, thus the transceiver 120 allows the WTRU102 to communicate through multiple RATs, such as UTRA and IEEE 802.11. Can include transceivers.

User input data by coupling WTRU102 processor 118 to speaker / microphone 124, keypad 126, and / or display / touchpad 128 (eg, liquid crystal display (LCD) display unit or organic light emitting diode (OLED) display unit). Can be received. Processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. In addition, processor 118 can access information from any suitable type of memory, such as non-removable memory 130 and / or removable memory 132, and store data in those memories. The non-removable memory 130 can include random access memory (RAM), read-only memory (ROM), hard disk, or other type of memory storage device. The removable memory 132 can include a SIM card, a memory stick, an SD memory card, and the like. In other embodiments, processor 118 can access information from memory that is not physically located in WTRU102, such as a server or home computer (not shown), and store the data in those memories.

Processor 118 can receive power from power supply 134 and can be configured to distribute and / or control that power to other components within WTRU102. The power supply 134 may be any device suitable for powering the WTRU102. For example, the power supply 134 includes one or more dry batteries (eg, nickel cadmium (NiCd), nickel zinc (NiZn), nickel hydrogen (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, and the like. be able to.

The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (eg, latitude and longitude) about the current position of the WTRU102. As an addition or alternative, with information from GPS chipset 136, the WTRU102 receives location information from a base station (eg, base stations 114a, 114b) via wireless interface 116 and / or two or more neighbors. It can determine its own position based on the timing of the signal received from the base station of. It should be recognized that WTRU102 may acquire position information by any suitable position determination method while maintaining consistency with the embodiment.

Processor 118 can be coupled to yet other peripherals 138, which provide additional features, functionality and / or wired or wireless connectivity, one or more software modules and / or hardware. Can include wear modules. For example, peripherals 138 include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos or videos), USB ports, vibrating devices, television transceivers, hands-free headsets, Bluetooth® modules, frequency modulation (FM). ) Can include wireless units, digital music players, media players, video game player modules, internet browsers, etc.

FIG. 1C is a system diagram of the RAN 104 and the core network 106 according to the embodiment. As mentioned above, the RAN104 can communicate with the WTRU102a, 102b, 102c via the radio interface 116 using E-UTRA radio technology. The RAN104 can also communicate with the core network 106.

It should be noted that RAN104 may include e-nodes B140a, 140b, 140c, but RAN104 may include any number of e-nodes B, consistent with embodiments. The e-nodes B140a, 140b, 140c can each include one or more transceivers that communicate with the WTRU102a, 102b, 102c via wireless interface 116, respectively. In one embodiment, the e-nodes B140a, 140b, 140c can implement MIMO technology. Thus, for example, the e-node B140a can use a plurality of antennas for transmitting and receiving radio signals to and from the WTRU102a.

Each of the e-nodes B140a, 140b, 140c can be associated with a particular cell (not shown) and handles radio resource management decisions, handover decisions, uplink and / or downlink user scheduling, and more. Can be configured as As shown in Figure 1C, the e-nodes B140a, 140b, 140c can communicate with each other via the X2 interface. The core network 106 shown in Figure 1C can include a mobility management gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. Although each of the above elements is shown as part of the core network 106, it should be recognized that any of these elements may be owned and / or operated by an entity other than the core network operator.

The MME142 can be connected to each of the e-nodes B140a, 140b, and 140c in the RAN104 via the S1 interface, and can function as a control node. For example, the MME142 can authenticate users of WTRU102a, 102b, 102c, activate / deactivate bearers, select a specific serving gateway during the initial attach of WTRU102a, 102b, 102c, etc. Can be involved in. The MME142 can also provide a control plane function to switch between the RAN 104 and other RANs (not shown) that use other radio technologies such as GSM or WCDMA.

The serving gateway 144 can be connected to each of the e-nodes B140a, 140b and 140c in the RAN104 via the S1 interface. The serving gateway 144 can generally route and forward user data packets from / to WTRU102a, 102b, 102c. Serving gateway 144 anchors the user plane during handover between e-node B, triggers paging when downlink data becomes available for WTRU102a, 102b, 102c, context of WTRU102a, 102b, 102c. You can also perform other functions such as managing and storing.

The serving gateway 144 can also be connected to the PDN gateway 146, which can provide access to packet-switched networks such as the Internet 110 for WTRU102a, 102b, 102c and IP communication with WTRU102a, 102b, 102c. (IP-enabled) Communication with the device can be facilitated.

The core network 106 can easily communicate with other networks. For example, the core network 106 can provide WTRU102a, 102b, 102c with access to circuit exchange networks such as PSTN108, facilitating communication between WTRU102a, 102b, 102c and communication devices over conventional fixed telephone lines. .. For example, the core network 106 can include or can communicate with an IP gateway (eg, an IP Multimedia Subsystem (IMS) server) that acts as an interface between the core network 106 and the PSTN108. In addition, core network 106 can provide access to network 112 to WTRU102a, 102b, 102c, which can include other wired or wireless communication networks owned and / or operated by other service providers.

FIG. 2 shows an architectural diagram of a 3GPP M2M system that can incorporate the embodiments described herein. The M2M System 200 is described in connection with a 3GPP network where 3GPP can provide transport and communication services optimized for MTC, including 3GPP bearer services, IMS and SMS. As defined in 3GPP, machine type communication (MTC) shall involve MTC user 202, MTC server 203, and MTC device 204a-204d. The illustrated entities are linked via network operator 201. In this way, the MTC device can communicate with the MTC server 203 (with the MTC server 203 either inside or outside the network operator domain 201). The MTC device 204a-204d can be connected to the operator domain 201 on the 3GPP network (eg UTRAN, E-UTRAN, GERAN, 1-WLAN, etc.) and communicate with the MTC server 203 via the 3GPP network. Although Figure 2 represents an exemplary architecture, it should be noted that the architecture is not limited to a limited number of devices or a combination of devices illustrated. That is, the components may be incorporated in any number or combination.

End-to-end applications between the MTC device 204a-204d and the MTC server 203 can use the services provided by the 3GPP system. Each MTC device 204a-204d can incorporate a future, which is a network function optimized for M2M applications. For example, each MTC device 204a-204d can have futures such as MTC Future 1, MTC Future 2, and MTC Future 3 illustrated in association with device 204d.

The MTC server 203 can be an entity that connects to the 3GPP network and can be an entity outside the operator domain 201 or an entity inside the operator domain 201. The MTC server 203 can be an entity that communicates directly with the mobile network and indirectly with the MTC device through the mobile network. The MTC server 203 can also provide an interface to the MTC user 202, and the MTC user 202 becomes a user who uses the service of the M2M server.

MTC applications and MTC devices may not have the same feature and / or service requirements. In order for MTC devices to implement the methods described herein, MTC devices will need to understand the MTC capabilities that radio operators can offer.

Among the capabilities that wireless network operators can provide (and MTC devices can have) are, for example, low data utilization (or small data utilization) online and / or offline, low mobility, time-controlled transmission, and permissible time. Transmission, packet switching (PS) dedicated, mobile outgoing only, infrequent mobile termination, MTC monitoring, offline display, congestion display, priority alarm message (PAM), spare low power consumption, secure connection, location There are limited triggers, group-based MTC features, group-based policy making, and / or group-based addressing. Depending on the particular MTC capability provided by the communications network, users of the MTC device may select a particular communications network and / or operator. Also, if a communication network can provide a particular MTC capability, it is useful for the MTC device to receive an indication of how it communicates with the MTC device so that the provided MTC capability is available to the MTC device. right.

Methods and devices that can display the MTC capabilities of a network are disclosed herein. The MTC capability can be displayed on the WTRU (eg, MTC-enabled device). One or more MTC capabilities can be shared for several MTC applications. Also, one or more MTC capabilities can be limited to the requirements of a particular MTC application. The MTC capabilities that each network can provide can be displayed on the WTRU prior to registration. The WTRU can include one or more configurable elements that can be programmed to implement the disclosed embodiments.

The specific capability requirements for MTC applications include low data usage requirements that can be categorized as "Online Small Data Transmission" or "Offline Small Data Transmission". Can include. MTC features called "online small data transmission" can be used for online or connected MTC devices to send or receive small amounts of data frequently.

An MTC feature called "offline small data transmission" can be used for "offline" or "disconnected" equipment. After connecting, the "offline" or "disconnected" device sends and / or receives a small amount of predefined data and then disconnects from the communication network. "Offline" or "disconnected" means an MTC device that is unreachable by a communication network for MTC signaling or user plane data. To support the MTC feature of offline small data transmission, MTC devices can efficiently access the communication network, send data, receive an acknowledgment of the transmitted data, and disconnect from the network. For both online and offline small data transfers, a small amount of data definition can be configured on a per-subscription basis.

To support MTC enhancements, such as the methods described herein, MTC devices have specific methods, services, or capabilities to transfer small online / offline data supported by their respective wireless communication networks. Will need to be recognized. Therefore, mechanisms, devices, devices, and / or methods that notify MTC devices of the MTC capabilities of each wireless communication network associated with the MTC application would be useful.

In embodiments, one or more nodes or devices in a wireless communication network can include one or more configurable elements. A configurable node or device in a wireless communication network can be configured to notify one or more MTC devices of one or more supported MTC capabilities using the steps in Broadcast System Information. Broadcasting of information may relate to, but is not limited to, the MTC capabilities supported for MTC or WTRU applications, such as low data utilization online and / or offline. Information related to supported MTC capabilities can be added to existing / legacy system information blocks (SIBs). As an alternative, for GSM EDGE Radio Access Network (GERAN) access, information related to supported MTC capabilities can be added to existing system information (SI) messages. For example, in FIG. 3, UTRAN320 can transmit system information to WTRU310.

In an alternative embodiment, information related to the supported MTC capabilities can be added to the newly created SIB. Also, for GERAN access, information related to the supported MTC capabilities can be added to the newly created System Information (SI) message. For newly created SIBs or newly created SIs, the SIB or SI can be an MTC-only SIB or SI and can carry some or all of the MTC-related information. As an example, a newly created SIB or SI can carry the load information needed to support Time Tolerant Transmissions.

In embodiments, the radio resource control (RRC) connection configuration message can be further extended to include information about the MTC capabilities supported for MTC applications, such as low data utilization online and / or offline. Not limited to. You can use the information in the extended RRC connection configuration message to show the WTRU which MTC capabilities are supported by each wireless communication network. FIG. 4 is an exemplary diagram of the signaling that can occur between WTRU and E-UTRAN during the RRC Connection Establishment Procedure.

In embodiments, the WTRU410 can send an RRC connection request 402, which can include an information element (IE) that requires the capabilities of a communication network for an MTC application or feature, such as small data transmission. The RRC connection request 402 can include information that allows the WTRU410 to become an MTC device or support the ability to belong to MTC features, groups, and so on. In response, each communication network, E-UTRAN420, can send an RRC connection configuration message 404 that can be changed to the new IE. The new IE can display, for example, one or more specific ways to transfer data for limited MTC features or applications. The WTRU410 can recognize the new IE sent to itself, and the WTRU410 can decrypt the information associated with the new IE to access the MTC or other capabilities of the network. For example, the WTRU410 can determine based on the received IE that the communication network 420 can support a piggy bag of data on the control plane message, in which case the WTRU420 will use the new IE to provide short data (or small). Data) can be encapsulated in RRC connection setup completion message 406.

Alternatively, the communication network 420 can send a new IE displaying one or more specific ways to transfer small data without an explicit request from the WTRU410 (eg, the communication network is part or more). IE can be sent to all WTRUs).

In another exemplary embodiment, different RRC signaling solutions can be implemented for 2G (GERAN access) networks, as shown in Figure 5. Figure 5 shows the signaling that can occur between the mobile station / user equipment / WTRU510 and the base station substation (BSS) 520 during the RRC connection establishment procedure in GERAN.

Immediate allocation (or extended immediate allocation) messages can be extended to include information about supported MTC capabilities, such as, but not limited to, MTC capabilities for low data usage. The information in the instant allocation message can be used to indicate to the WTRU (ie, MS / UE) which MTC services or capabilities can be supported by their respective wireless communication networks.

For example, in FIG. 5, the WTRU510 can send a channel request (or EGPRS channel request) message 502 with IE requesting the MTC capability of the communication network 520, such as small data transmission. Alternatively, the WTRU510 can send a channel request (or EGPRS channel request) message 502 with information that the WTRU510 is an MTC device. In response, the communications network and / or BSS520 can send an immediate allocation 504, for example, with a new IE that can display one or more specific methods for transferring small data. Alternatively, the communications network and / or BSS520 can send IE displaying one or more specific ways to transfer small data without explicit request from the WTRU510 (ie, the communications network and / or BSS can send IE to some or all WTRUs). The WTRU510 can recognize IE (or the new IE), and the WTRU510 can decrypt the information associated with IE to access the MTC capabilities of network 520.

In another embodiment, non-access layer (NAS) signaling can be used, as shown in the exemplary message exchanges of FIGS. 6A and 6B. The NAS attach acceptance message can be extended to include information about one or more supported MTC capabilities, such as low data utilization. That information can be used to show the WTRU which MTC capabilities can be supported by each wireless communication network. For example, as shown in FIG. 6A, the WTRU610 can send attach request 602, which can include IE requesting the MTC capability of network 620 for small data transmissions. Alternatively, the attach request 602 can include information that the WTRU is an MTC device.

In response to attach request 602, communication network 620 can include, for example, a new IE that displays one or more specific methods that can be used to transfer small data, modified attach. Acceptance 604 can be sent. Alternatively, the telecommunications network 620 can send a new IE showing one or more specific ways to transfer small data from the WTRU610 without explicit request (eg, the telecommunications network may be part or more). Information can be sent to all WTRUs).

The WTRU610 can recognize the new IE and decrypt the information associated with the new IE to access the MTC capabilities of network 620. If the communication network 620 supports a piggy bag of data on NAS messages, the WTRU610 can use the new IE to encapsulate short data within the attachment completion message 606.

As shown in Figure 6A, the WTRU610 can send an attach complete message after the attach acceptance 604. If the offline small data transmission solution uses the attach completion message 606 to carry the MTC data, the MTC device 610 can attach the data to the attach completion message 606. In that case, the MTC device 610 does not necessarily have to remember the MTC device capability of network 620 because it communicates within the attach acceptance message 604, which may be sent immediately prior to the attach completion message 606, as shown in FIG. 6A. NAS Attach / Tracking Area Update (TAU) / Routing Area Update (RAU) / Location Update Acceptance Message (s) are also Attach / TAU / RAU / Mobile Subscriber Temporary Identifier (TMSI) to send MTC related data. ) Can be modified to notify the MTC device that reallocation completion messages (s) are available.

In the embodiment, as shown in FIG. 6B, if the attach request 652 from the WTRU650 is not successful, the attach rejection message 654 can be transmitted from the communication network 660. The attach rejection message 654 can be extended to include MTC capability information.

The attachment procedure described herein may be a registration process performed within a packet-switched (PS) domain. As an alternative, if the WTRU is registered within the circuit exchange (CS) domain, the attach procedure may not be used. The registration procedure within the CS domain may be "Location Update". If the location update procedure is most suitable for the procedure to be used, the procedure will be consistent with this disclosure of the attach procedure. For example, the WTRU can send location update requests, which can include, for example, information elements that require the MTC capability of the network for small data transmissions. In response to a location update request, the communication network can include, for example, a new IE that displays one or more specific methods that can be used to transfer small data, modified location updates. You can send acceptance. The WTRU can recognize the new IE and decrypt the information associated with the new IE to access the MTC capabilities of the network.

Alternatively, the WTRU can send a modified attach request, for example, asking the communication network for a supported MTC capability to transfer small data. Also, in response to the modified attach request, the communication network can notify the WTRU of the MTC capability of the communication network, if necessary.

In the embodiment, if the MTC device is already registered in the communication network (ie, the MTC device has completed the attach procedure), the MTC device still performs the registration renewal procedure based on periodic actions or mobility. Can be done. In such a scenario, the communication network can display to the MTC device which MTC services or capabilities can be supported by the communication network when sending an "accept" message. Examples of "accept" messages are TAU ACCEPT, RAU ACCEPT and Location Updating Accept.

In an embodiment, if the offline small data transmission MTC solution uses an attach request message to carry MTC data, the MTC device first performs the attach procedure on the new communication network, so that the MTC device communicates. You will not have the knowledge of the MTC capability of the network. In such situations, the MTC device will not be able to utilize the attach request message to carry the MTC data. However, an MTC device can use this procedure after the MTC device has learned that the communication network supports this procedure. The MTC device thereby puts this information in memory so that the MTC device can use it to make decisions about whether it can carry MTC data using attach requests in order to attempt data transfer in the future. Can be stored locally.

In another embodiment, as in the embodiment shown in FIG. 3, the system information block / message (SIB / SI) is extended to allow the MTC device to send MTC-related data over the attach request message. You can notify the MTC device that it can be done.

The WTRU (eg MTC device) can be put into idle mode. WTRU wakes user data transmission when a series of signaling steps are performed to establish different levels of connectivity that can depend on the state of the non-access layer (NAS) (eg, attach or detach). can be used by up). In LTE or UMTS, legacy message series can include: 1) wireless resource control (RRC) connection establishment, 2) security enablement, 3) data bearer establishment, 4) data transmission on data bearer, 5 ) Data bearer release, 6) RRC connection release.

Legacy methods for connections that require the above cycles can also result in unnecessary signal overhead in some scenarios. Mechanisms such as discontinuous transmission / reception (DTX / DRX) and continuous packet connectivity (CPC) features (features) in various modes of operation are used to address signal overhead. However, such solutions may not be efficient for many MTC applications, especially for MTC devices that require low power consumption. For example, if an ultra-low power device remains in a power-saving state, such as idle mode or cell paging channel (CELL_PCH) / URA paging channel (URA_PCH), there will be considerable overhead associated with transmitting data. More specifically, idle mode devices will have to establish an RRC connection prior to the start of transmission. In addition, if the WTRU is detached from the network, the WTRU will have to perform NAS registration and additional steps to be able to send these data. For small data transmissions or other types of data transmissions, this can result in increased signal overhead and inefficient use of signal energy.

With the deployment of M2M systems, different devices with diverse capabilities can operate under different conditions. Different sequences and different backoffs can be defined for different groups to distinguish MTC groups. Note that the characteristics of MTC devices can be grouped based on MTC features as part of an effort to optimize the utilization of the operator network by addressing the various characteristics of M2M. For example, MTC features include: low mobility, time control, time tolerance, packet switching only, online small data transmission, offline small data transmission, mobile outgoing only, infrequent mobile termination, MTC monitoring, offline It can include display, congestion display, priority alarm message (PAM), spare low power consumption, secure connection, location-specific triggering, group-based MTC policy making, and group-based MTC addressing.

Various components of an M2M system consume power during processing, such as MTC servers, operator networks, and MTC devices. Signal overhead can also result in unnecessary power consumption within the M2M system. For example, unnecessary signal overhead can lead to battery power consumption of MTC devices. The need for low or ultra-low power consumption to use power more efficiently would be advantageous for MTC devices. An example of an ultra-low power device would be a device that is not processed for a long time, such as a month or a year. Another example of an ultra-low power device would be a device that sends small amounts of data or rarely.

As represented herein, methods proposed for overhead reduction or device power savings are control to send MTC data on the control plane (signaling bearer) or to carry user plane messages. To use plain messages. Such techniques allow the device to avoid the entire cycle of the connection procedure, thus reducing latency, signaling overhead, and power consumption.

Although described using several types of messages, it should be understood that the same solution may be applied to other existing or new messages. Even though the terms used herein consist of UMTS and / or Long Term Evolution (LTE), the concepts herein are for Long Term Evolution-Advanced (LTE-A), mobile communications. Note that it may be applied equally to other wireless technologies such as Global Systems (GSM) for, or to other wireless technologies such as GERAN, WiMax. Also, it should be understood that when idle mode is described within the context of UMTS, it may refer to one of the following RRC states: idle, CELL_PCH, URA_PCH, or CELL_FACH. Idle states similar to UMTS are assumed in other wireless technologies. The initiation of the method described herein can be accomplished by determining network capacity.

The embodiment is intended for MTC data transmission via a common control channel (CCCH) or using a dedicated control channel (DCCH) signaling bearer. As used herein, it is assumed that the concepts described for CCCH or DCCH can be shared.

For CCCH, when the WTRU is in idle mode, the initialization of data transmission from the WTRU or network can require that the wireless connection be first established by the RRC connection setup procedure, thereby the RRC entity and network of the WTRU. You can exchange a set of RRC signaling messages with your RRC entity. Such signaling messages can be designed to pass control and configuration information for establishing RRC connections and can be sent over CCCH logical channels. Note that CCCH is usually considered part of the control plane.

The ability to send messages over CCCH to carry MTC data using existing common control signaling eliminates the need to further establish data bearers and other signal bearers. This results in a reduction in signaling, which can reduce the power consumption of the device. This method can provide a connection procedure that results in reducing signaling overhead.

Signaling overhead can be reduced by including or attaching MTC data in messages involved in different steps of the RRC procedure (such as establishing an RRC connection or updating a cell), but it is actually established without an RRC connection. .. MTC data transmission over RRC messages is described herein for uplinks and downlinks.

For uplink transmissions, uplink CCCH messages RRC connection requests, cell updates, and UTRAN registration area (URA) updates can be used to carry and send MTC data. That transmission can be achieved by attaching the data to these messages. For example, in the case of WTRU in idle mode, the RRC connection request procedure can be started when the MTC data is triggered by the upper layer.

Figure 7 shows the procedure for requesting an RRC connection. As part of this procedure, the UE / WTRU can attach the data directly to the RRC connection request message without waiting for the RRC connection to be first established and the data radio bearer to be set up. Similarly, for WTRU in connection mode, data can be attached directly to a CELL_UPDATE message or URA_UPDATE. By attaching the data, the system can optimize delays and signaling exchanges because the WTRU does not have to wait for CELL_UPDATE confirmation.

To enable RRC messages (eg, RRC connection requests) to transport or send data to the network, the WTRU can display to the network that the data has been attached to the message. For example, a new RRC establishment factor or cell update or URA update factor can be introduced. For example, let this factor be "MTC data transmission". When message retransmission occurs, it is set to "MTC data retransmission".

Table 1 shows another exemplary embodiment in which the information element (IE) of MTC data can be used in RRC messages. For example, you can introduce a new IE and include it in your RRC message. The content of this IE can include an enumerated IE that indicates that there is an "MTC data transmission". The IE can provide additional information that the network can use to de-multiplex MTC data from RRC messages, such as the length / size of the attached MTC data. For example, the size can be predefined or configured, where the WTRU does not have to display anything. In another example, a set of sizes can be defined and the WTRU can display an index that matches that size.

<tables num="1"><img id="000002" he="78" wi="123" file="JP5866397B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>

As shown in Figure 7, in the case of LTE, a new factor can be added to the establishment factor 701. The same concept may be applied to UMTS. Table 1 and Figure 7 show the addition of MTC data, but it should be understood that this may be obtained in other ways. Table 1 shows that IE of MTC data can be attached to the end of the RRC CONNECTION REQUEST message for downlink MTC data transmission in UMTS systems.

In an exemplary embodiment, the WTRU may be allowed to use the procedure described herein if the amount of data transmitted is equal to or less than the threshold. If the amount of data exceeds this threshold, the WTRU can add the same amount of data to the message as allowed, the network can indicate that the WTRU has additional data, and the amount of unprocessed data. It can also be displayed. Alternatively, the WTRU may initiate the procedure described herein as many times as necessary for the WTRU to complete the transmission of data. Alternatively, the WTRU can have the option to indicate that it has MTC data to transfer and can provide that amount of data to the network.

In another embodiment for uplink data transfer, the receiving node within a network entity does not have to decode and understand the MTC message. The WTRU can provide additional information in the RRC message carrying the data so that the data can be correctly routed to the desired destination. Such information can include, among other things, an MTC device identifier, a destination MTC server identifier, subscription information, and the type of data transmitted (eg, the type of logical channel).

The typical way in which network responses are processed can be changed to features with the disclosed technology. For example, to further optimize data transmission and reduce signaling overhead, the RRC establishment procedure does not predict that the RRC connection will be fully established when it initiates an RRC connection request. Can be changed. This can be achieved by the WTRU sending an RRC connection request message but not predicting a response.

It should be noted that this mechanism does not guarantee to the WTRU that the data was acknowledged correctly, but can be a mechanism that reduces signaling overhead and can be desirable for a particular environment. For example, if the probabilistic factor is MTC data transmission, the WTRU can send an RRC connection request message to the lower layer for transmission over the uplink CCCH, enter idle mode, and exit the procedure. In this example, the WTRU does not have to start the applicable timer V300 and counter N300. WTRU can use schemes that increase the reliability of lower layers, such as message iteration. Alternatively, the UE can wait for a message to be sent and acknowledged by the lower layer hybrid auto-repeat request (HARQ) mechanism until the procedure confirms it from the lower layer and considers it complete. If the lower layer shows a failure, the WTRU can resend the data.

On the network side, when the network receives a WTRU RRC request, the network can process the RRC connection request, extract the MTC data, route the data to the corresponding entity / node, and prevent it from responding to the WTRU. ..

An RRC connection configuration message can be sent in another exemplary embodiment of network response that can reduce signal overhead and provide reliability. Receiving RRC connection settings from the WTRU can serve as an implicit acknowledgment to the network receiving MTC data. RRC connection configuration can be received, but to further reduce signaling, WTRU can be prevented from sending RRC connection configuration complete messages. If the WTRU sends a request for MTC data and the WTRU receives an RRC connection setup complete message, the WTRU defines an implicit rule so that it can consider the procedure complete and return to idle mode. Yes (for example, you can prevent WTRU from sending RCC connection setup completion).

In another embodiment using RRC connection configuration messages, include display or IE in the RRC connection configuration message to explicitly indicate to the WTRU that the RRC connection configuration message is a response to a requester that includes data transfer. Can be displayed on. After receiving this display, the WTRU can complete the procedure. The RRC connection configuration can include a new field "MTC acknowledgment" or "MTC data complete". If an "MTC acknowledgment" is included in the RRC connection configuration message and the WTRU does not have to send an RRC connection configuration complete, the WTRU can be stopped and some or all of the timers (if applicable). Can be paused, the procedure can be considered complete, and it can return to idle mode. If no "MTC acknowledgment" is included, the WTRU can behave as if it had received a normal RRC connection configuration (ie, if it succeeds by applying the configuration sent by the network). Reply that RRC connection setting is completed).

In another exemplary embodiment in which an RRC connection configuration message is received, the WTRU indicates that the message or RRC establishment was responsible for the MTC data transmission, or the WTRU indicates that the connection is disconnected. , You can respond when the RRC connection setting is completed. However, the WTRU can return to idle mode (eg, disconnect the RRC connection) if it sends the message and considers the procedure complete.

In another exemplary embodiment of network response, which can reduce signal overhead and provide reliability, an RRC connection denial message can be sent. The response to the reception of MTC data can be an RRC connection refusal message. An RRC connection denied message response can be expected by the WTRU when sending an RRC connection request for MTC data. Receiving an RRC connection denied message can serve as an implicit acknowledgment that the network has successfully received the data. RRC connection denial can specify an "unspecified" denial factor. Alternatively, a new rejection factor can be added, for example, "MTC data completion" or "data acknowledgment".

After receiving the RRC connection denial message, the WTRU can either implicitly detect that the denial message is a response to MTC data transmission or explicitly detect the denial factor. In either example, the WTRU may consider the procedure successful, enter idle mode, and exit the procedure. Thus, the WTRU does not have to resend the RRC connection request message. If the network responds with the RRC connection configuration, the WTRU can continue to establish the RRC connection by following the normal procedure.

The concept for using RRC connection denial may be applied to CELL UPDATE / CELL UPDATE CONFIRM / WTRU_RESPONSE_TO_CELL_UPDATE AND URA UPDATE / URA UPDATE CONFIRM / UE_RESPONSE_TO_URA_UPDATE messages.

As described herein, the reception of a response can be an implicit acknowledgment that MTC data has been received. If an RRC response is received, this implies that the RRC message was received and that the network acted on it. This means that the MTC data attached to this message was also successfully received.

However, additional acknowledgment mechanisms that can take many forms can be added to address the additional failures that occur on the network side. In an exemplary embodiment of an additional acknowledgment mechanism, an RRC response message can be used to explicitly acknowledge a message. For example, this can be achieved by defining a new factor called "MTC data acknowledgment". For example, in the case of UL data transmission, it is possible to set the "MTC data acknowledgment" in the message, in which a new factor is added in the RRC connection refusal message or RRC connection request message. A negative response can also be sent to the WTRU, for example by adding a new factor or field. A negative response can be used, for example, when the network cannot identify the server or WTRU, or for some other reason, MTC data may not be forwarded.

Alternatively, if the factor is not set to "MTC data acknowledgment", the WTRU may take the normal RRC connection request procedure as it may receive this as an indication that the network does not support the procedure. In another alternative of explicit acknowledgment, for example, IE, which may be called "MTC data ACK", can be introduced in the RRC message. "MTC data ACK" IE can display acknowledgment reception or negative response reception of MTC data.

In another example of an additional acknowledgment, a new message can be defined to display an acknowledgment. In another example of the additional acknowledgment, the data transfer acknowledgment can be made by the upper layers. Alternatively, if the server does not receive the data it predicts in time, the server can poll the WTRU again.

Handling transmission failures is another part of the M2M system that may require changes to implement some of the disclosed power reduction techniques. In an exemplary embodiment, CCCH messages can use failure mechanisms, such as the start of the T300, which are used to ensure that data is received on the network side. If no response is received within the T300, the WTRU can resend the message up to the maximum number of times the N300. The WTRU can use MTC-specific retransmission and counter values (eg, T300 and N300 or T302 / N302, etc.) or, optionally, the same values as the RRC connection establishment mechanism.

The T300 / T302 and the like discussed in the examples herein can be timer variables that include values configured by the network. After transmitting the RRC connection request message, the timer T300 can be started in the WTRU. The WTRU can wait for a response from the network for the duration of the T300, and if no response is received and the timer expires, the WTRU can resend the RRC connection request. The N300 / N302, etc. discussed in the examples herein can be constants (eg, variables that contain values configured by the network) that can be used to retransmit RRC connection request messages. Determine the maximum number.

In an alternative solution for handling transmission failures, WTRU may be allowed to attempt a one-time RRC message-based transfer procedure without introducing any retransmission mechanism at the RRC layer. If a failure is detected (for example, the timer has expired and no response is received), legacy procedures can be used to resend the RRC connection request message. More specifically, you can trigger a new RRC connection request message without attaching MTC data. MTC data transfer can be performed by using the legacy method.

8A and 8B show exemplary message sequences for uplink data transfer for the disclosed signaling techniques. 8A and 8B are exemplary of the design described herein, exemplary of uplink MTC data transmission, which can comprise attaching data to an RRC signaling message RRC connection request over CCCH. Shows the message sequence. Data transmission can be based on WTRU, which would originally be in idle mode or turned off.

In Figure 8A, the WTRU810 can initiate MTC data transmission on 802 by sending an RRC connection request message. In 802, the RRC connection request message can be composed of MTC data attached as part of the message. In 802, ESTABLISHMENT_CAUSE can be set to the defined value of "MTC data transmission". Following the transmission of the RRC connection request message, the WTRU810 can set the counter V300 to 1 and / or start the timer T300. The V300 discussed in the examples herein can be the counter variable used by the WTRU. The V300 can be a variable that counts the number of times an RRC connection request message has been sent. Once the value of V300 exceeds the maximum number of times the WTRU can retransmit (eg N300), the WTRU goes into idle mode.

In 804, an RRC connection request message may be sent. This is due to the reason why MTC data transmission failed in 802. Here, for example, in WTRU810, no response from UTRAN / E-UTRAN820 was received by time T300, so in 804, an RRC connection request message with the same MTC data attached from 802 was sent. ESTABLISHMENT_CAUSE can be sent to a newly defined value, such as the "MTC Data Retransmission" factor, or the same "MTC Data Transmission" factor. In addition, the WTRU810 can increment the counter V300 to start another timer T300.

In 804, iterative messages can be responsible for consecutive failed transmissions. If the counter V300 is greater than the maximum number of preconfigured values N300 that are allowed to be retransmitted, the WTRU810 can stop retransmitting and return to idle mode.

After receiving the RRC connection request, the UTRAN / E-UTRAN820 can decide to accept the data transmission. The UTRAN / E-UTRAN820 can decode MTC data and forward that data to the upper layers that reach the MTC server. The UTRAN / E-UTRAN820 can also respond to the WTRU810 by sending an RRC connection denial message with a defined rejection factor of "MTC data acknowledgment".

In 806, after receiving an RRC connection rejection with a rejection factor set in "MTC data acknowledgment", the WTRU810 can consider the data transfer to be successful and can return to idle mode. Alternatively, the network can also use the RRC connection configuration, for example, as an alternative response to the RRC connection denial described above.

In Figure 8B, the WTRU850 can initiate MTC data transmission at 852 by sending an RRC connection request message to network 860. In 852, the RRC connection request message can consist of MTC data attached as part of the message. In 852, ESTABLISHMENT_CAUSE can be set to the defined value of "MTC data transmission". Following the transmission of the RRC connection request message, the WTRU850 can set the counter V300 to 1 and / or start the timer T300.

In 854, before the timer T300 expires, it is possible to receive an RRC connection refusal message having a rejection factor set in "MTC data acknowledgment". The WTRU850 can consider the data transfer successful and return to idle mode. This example demonstrates the use of explicit rejection factors. As described herein, new non-explicit rejection factors may be added or the rejection factors may be set to different values, such as "MTC data completion".

Similar to uplink transmission, it has been proposed that for downlink (DL) transmission, MTC data can be transported from the network to the WTRU using several RRC messages sent on DL over CCCH. ing. Such messages can include, for example, RRC connection denial, RRC connection settings, Cell_Update confirmation, and URA_Update confirmation.

For example, the RRC connection request procedure can be initiated when MTC data is triggered by a layer above the DL. As part of this procedure, the network can attach the data directly to the RRC connection request message without waiting for the RRC connection to be first established and the data radio bearer to be set up.

The network can page WTRU with the factor "MTC data transmission". After receiving this paging, the WTRU can initiate an RRC connection request, cell update or URA update to the network. When the WTRU sends an RRC connection request (or cell or URA update), the WTRU can, for example, display a new factor called "waiting for MTC data" or respond only to paging.

When the network receives an RRC connection request (or cell or URA update) message, the network can attach MTC data to the response message (eg, RRC connection denied, cell or URA update confirmation, or RRC connection configuration message).

A new factor for RRC connection denial, such as "MTC data transmission", can be defined, or an existing factor, such as "unspecified", can be used (and the WTRU implies that the response is for MTC data. Can be known). Alternatively, you can add IE to indicate that the message was sent to attach MTC data.

Messages sent by the network can contain one IE or a combination of IEs. IE will display below that the data will be attached to the message, the MTC data, the size of the data, and whether one or several messages will be used to send the data, and the MTC data. Some messages that can be sent to fully transmit (for example, if some messages are requested) and an indication that the message is the last message that contains MTC data (eg "MTC data end"". It can include an indication of whether the message was first transmitted or retransmitted, the type of logical channel, and the priority of the MTC data.

The WTRU can wait for RRC connection denial, connection settings, cell update confirmation or URA update confirmation, as specified herein (ie, for a period of time if the WTRU has not yet received it. Then retry sending the request up to the maximum number of retries). The network can specify different timers and a maximum number of retries.

For cell or URA updates, the WTRU can decide not to release the resource when the maximum number of retries is reached without receiving a confirmation message. The WTRU can return to its previous mode (eg idle mode). The failure mechanism procedure described above can also be applied to the downlink transfer procedure. For example, the WTRU can decide not to send additional RRC connection requests, cell updates or URA update messages if it has not received any response message from the network, and the WTRU will after a period of time. You can abort the procedure and return to your previous mode. Here, the WTRU can send a message to the network stating that it will not wait any longer for MTC data, or it can turn off the network at all.

The WTRU can implicitly know that the received RRC connection denial, cell update confirmation or URA update confirmation was sent by the network in order to send the MTC data. The WTRU is recognizable because the message received may contain a request to receive MTC data, or the paging message may have a factor in the MTC data. Alternatively, the WTRU can check the information in the MTC data and / or whether the MTC data is present within the messages defined herein. After receiving DL data with MTC data, the WTRU can return to idle mode or the previous mode (ie, the WTRU is on another cell, as in the normal procedure when receiving an RRC connection denial). Does not try to send an RRC connection request).

If an acknowledgment is desired by the network, the WTRU can use the RRC connection request message to send an acknowledgment (eg, by adding the factor "MTC acknowledgment" described herein). After sending an acknowledgment to the lower layer or receiving confirmation from the lower layer, the WTRU can return to idle mode to complete the procedure.

If the WTRU can receive the RRC connection configuration instead of rejecting the RRC connection, the WTRU can respond in several ways. In an exemplary embodiment, the WTRU can continue the RRC connection procedure by sending an RRC connection setup completion. The completion of the setting can function as an acknowledgment mechanism in which the WTRU receives the data. At this point, if the factor is MTC data, the WTRU can send a configuration completion, return to idle mode, and end the procedure without moving to a different state. WTRU can return to idle mode once it confirms that the RRC message has been successfully delivered.

In another embodiment, when the WTRU receives the RRC connection configuration instead of rejecting the RRC connection, the RRC connection configuration message is that the WTRU has fully established and entered connection mode or subsequently idle mode. It can have an explicit indication that allows you to choose whether to return to. In another embodiment, the WTRU can ignore requests from the network and not return any messages. In another embodiment, the WTRU attaches IE within the RRC connection setup completion, or by sending a new type of message, or by sending another RRC connection request asking for MTC data again. You can notify the network to ignore the RRC connection configuration message. If the WTRU also needs to send MTC data to the network, the WTRU can attach the data to the completion of the RRC connection setup to send to the network (see DCCH-related here for details). In another embodiment, if the WTRU has the forwarding uplink data that the message received on the DL is responsible for, the WTRU may choose to maintain the RRC connection and send the RRC connection configuration with a legacy response.

In an embodiment, instead of attaching the data in the RRC connection denial, the network can attach the MTC data in the RRC connection configuration. Similarly, the IE and behavior described herein can be used to attach MTC data to RRC connection denials.

In the embodiment, once the WTRU is paged to receive MTC data, the WTRU receives RRC connection denials, cell update confirmations, and URA update confirmations without sending a request message to the network. Will be able to. In another embodiment, the network can attach MTC data within the paging message itself. In this case, the network can use the same type of IE as defined herein in the paging message. One or more paging messages may be used by the network to transfer MTC data. In this case, the WTRU may or may not acknowledge the data. In the case of an acknowledgment, the WTRU can reuse an existing message, such as an RRC connection request, to attach IE that is only used for acknowledgment of data, or a new message can be used, which from the network. It does not wait for any type of answer (ie, it does not wait for RRC connection setup or connection rejection). Upon receiving this special type of RRC connection request, the network can know that the request message can be used as an acknowledgment without initiating the connection procedure.

Regarding the transmission behavior, after confirming the status of MTC transmission in WTRU, whether it is successful or not, WTRU can return directly to idle mode. If the WTRU decides to establish an RRC connection to a legacy method of data transmission (the option described herein), an RRC disconnect procedure can be requested before the WTRU returns to idle mode.

Additional signaling indicators can be incorporated into the disclosed signaling techniques. To assist in the transmission of MTC data over RRC messages on CCCH, IE, which defines several RRC message factors, can include the required signaling settings during the MTC data transmission procedure. IE can define the setting of the paging factor, PAGING TYPE1 message, set by the establishment factor that can be defined by IE, RRC CONNECTION REQUEST, set by the rejection factor that can be defined by IE, RRC CONNECTION REJECT, and IE It can include CELL UPDATE, which is set by the cell update factor that can be defined.

The settings are as follows: "1st MTC data transmission" to display the 1st MTC data transmission, "MTC data retransmission", "MTC data retransmission" to display MTC data retransmission, and MTC. "MTC data affirmative response" that affirms the correct reception of data, "DL MTC data transfer request" that requests downlink MTC data transfer, and "UL MTC data transfer request" that requests uplink MTC data transfer. , "MTC data denial" that rejects further actions of MTC data transfer, "MTC data polling" that polls for the existence of MTC data, and "MTC data absence" that responds to MTC data polling. Can include one or a combination.

FIG. 9 is an exemplary message sequence for downlink MTC data transmission relating to attaching MTC data to RRC signaling messages, RRC connection denials over CCCH, as described herein. Another implementation can include having the network send data within the paging message itself, where "paging type 1" can be sent to page the paging message to the UE in the paging channel (PCH). Can be an RRC message. Data transmission can be based on networks with paging messages.

The downlink data transfer cycle can include following RRC connection denial messages. UTRAN / E-UTRAN925 (eg network) can send the paging factor of paging message 902 set in IE defined in "DL MTC data transmission request" to WTRU920. The WTRU920 can respond to paging message 902 by sending an ESTABLISHMENT_CAUSE set to the defined factor of the "DL MTC Data Transfer Request" or an RRC CONNECTION REQUEST 904 that can contain another legacy setting. The RRC CONNECTION REJECT message 906 can be sent from the UTRAN 925, which has the MTC data attached to the "MTC data transmission" and the rejection factor set in the "MTC data transmission". WTRU920 is another RRC CONNECTION with a defined probability factor of "MTC data acknowledgment" You can respond with an acknowledgment by sending REQUEST908. At this point, the WTRU920 can enter idle mode 910, assuming that DL data transmission is complete. The UTRAN / E-UTRAN925 can be considered to have completed the DL data transmission by receiving the RRC CONNECTION REQUEST 908 having the probability factor set in the "MTC data acknowledgment".

Alternatively, if the UTRAN / E-UTRAN925 receives a second RRC CONNECTION REQUEST, the UTRAN / E-UTRAN925 can consider the previous MTC data transmission 906 as a failure, and "MTC data retransmission". Retransmission of MTC data can be initiated by repeating the same transmission as in sequence 906, except for the rejection factor which can be set to.

Figure 10 is an exemplary message sequence that carries MTC data using RRC connection settings. The sequence is similar to FIG. As shown in FIG. 10, in 1005, the RRC connection setting completion message is transmitted from the WTRU1010 to the UTRAN / E-UTRAN1015 (that is, the network), the MTC data is successfully received, and the WTRU1010 ends the data exchange. And it can be displayed to return to idle mode 1007.

Another change that can support the disclosed signaling technology is downlink transmission with the initiation of WTRU. For example, instead of WTRU launching to listen for paging opportunities, WTRU launches at a predefined time interval (possibly configured with the MTC configuration), for example, regular reporting, to populate the data. You can poll the network you need to send to the WTRU.

Downlink transmission with the initiation of the WTRU can be performed by the WTRU polling the network using one or a combination of RRC connection requests, cell update messages, or URA update messages. A new factor can be added to this message to indicate that the WTRU is polling the data. The DL response message can include MTC data that can be sent as an attachment to the WTRU using any of the procedures described herein. Alternatively, you can send a DL response indicating that there is no data. For example, an RRC connection denial message with the "MTC data absent" factor can be sent. This concept can be applied to other DL messages, and the procedures described herein can also be applied.

FIG. 11 is an exemplary message sequence of downlink transmission with the initiation of WTRU. The WTRU1120 can poll the UTRAN / E-UTRAN1125 (ie, network) with RRC connection requests at a predefined time. At 1103, network 1125 can respond with an RRC connection denial message with the factor "MTC data absent" indicating that there is no data available for transmission. The WTRU1120 can return to idle mode 1105. At 1107, the WTRU1120 can poll the network 1125 again when the periodic timer expires. Network 1125 has data to be transmitted in DL and can start transmitting data in 1109.

The embodiment can also implement MTC data transmission using a DCCH signaling bearer. Direct forwarding messages can be used for uplink and downlink MTC data transmission. Direct forwarding messages can carry encoded NAS messages and can be sent over signaling radio bearers RB3 and RB4 for UMTS and on SRB2 for LTE. The embodiments described herein can also be implemented for other wireless bearers. In addition, one or several radio bearers can be dedicated to MTC messages. The MTC radio bearer parameters can be broadcast on the DL's broadcast control channel (BCCH) in the system information configured in the RRC message by the network, or can be the default configuration stored in the WTRU.

When a direct transfer message containing MTC data was sent, the WTRU may have performed an attach procedure as well as an authentication / security procedure. Alternatively, direct forwarding messages containing MTC data can be sent without being attached to the WTRU and / or without the WTRU performing authentication and security procedures.

In connected mode, the MTC device can send data to the network by sending an initial direct transfer, an uplink direct transfer, or a UL information transfer message. Whenever the network needs to send data to the MTC device, the network can send a downlink direct transfer or DL information transfer message to the WTRU. You can add one or a combination of subsequent IEs to different types of direct forwarding messages. The IE packet exchanges the IE MTC data (eg option IE) with the IE MTC data size and the MTC service or CN domain identifier to indicate that the MTC data is present in the message (eg Boolean message). Displays the legacy IE core network (CN) domain identifier set in the domain identifier that can be set in the existing value of (PS), the legacy IE establishment factor set in the MTC data transfer value, and the MTC data reception identifier. IE, IE MTC device identifier, and IE MTC controller identifier can be included.

In an alternative embodiment of the use of legacy direct transfer messages, one or several new messages can be defined and may be referred to as, for example, initial MTC data transfer, uplink MTC data transfer, and downlink MTC data transfer. .. In addition, other legacy RRC messages used to carry NAS messages can be used, for example, for LTE's RRCConnectionSetupComplete or RRCConnectionReconfiguration.

When the RRC on the WTRU side or the network side receives the direct transfer message, it can check the direct transfer message to determine whether the message contains MTC data. The determination can be made by checking the IE that displays the presence of MTC data or by checking the IE of the MTC data. MTC data can be a signal that can be used to send NAS messages, or can be sent to the upper layers with the same signal rather than different signals.

In another exemplary embodiment of MTC data transmission using the direct transfer procedure, the NAS message itself can be used to transmit the MTC data instead of just attaching the MTC data to the direct transfer message. For example, IE can be added to existing NAS messages such as attach request, attach accept, attach reject, attach complete, location area update / accept / reject, and / also routing area update / accept / reject. The ability of the WTRU to periodically send some NAS messages, such as location area updates and routing area updates, allows the WTRU to send data to the network without increasing the signaling load. In this embodiment, one or a combination of IEs for direct forwarding messages described herein can be added to the NAS message.

The network utilizes a PAGING TYPE2 message or another existing message with a new paging factor, which may be referred to as "MTC data transmission over NAS message", or, for example, a UL MTC forwarding request. Uplink MTC data transfer can be initiated by using a new message that may be available.

MTC data can be added, for example, by sending a new message, which may be called a "DL MTC forwarding request", or by reusing an existing message and adding an IE called, for example, an "MTC data reception request". Allows you to initiate a downlink MTC data transfer.

MTC data transmission can also be achieved using the RRC connection setup completion message. Uplink MTC data transmission in DCCH can be achieved by using an RRC connection configuration complete message that can request the establishment of a spare RRC connection.

The WTRU can initiate an MTC data transmission request, for example, by sending an RRC connection request message to the network with a probabilistic factor set to a newly defined factor, which may be referred to as an MTC data transmission request. If the network accepts the request, the WTRU can continue the normal RRC connection setup procedure by sending an RRC connection setup message to the WTRU. The RRC connection configuration message should indicate that the following IE: MTC data transmission permission has been granted, the maximum size of MTC data that WTRU is allowed to send, and that WTRU will send it to attach the MTC data. Can display the number of messages that can be done (for example, WTRU can use several RRC connection setup completion messages, not just one) and if WTRU needs several messages to send MTC data. It can include one or a combination of indications that the WTRU can send the following message with its MTC data.

If the network decides to reject the MTC data transmission request from the WTRU, the network has an IE-set rejection factor, which may be referred to as, for example, "MTC data transmission rejection", RRC connection rejection. Can be sent. Alternatively, instead of denying the connection with RRC connection denial, the network can send an RRC connection configuration with IE indicating that MTC data transmission has been denied.

When the WTRU receives an RRC connection setup message that accepts the MTC data transmission request, the WTRU sends an RRC connection setup completion message with the MTC data attached as part of IE in this message. Data transmission can be started. The following IE: part of MTC data or MTC data, size of MTC data or part of MTC data, total size of MTC data, and messages that WTRU must send to attach all MTC data The number and one or combination of the receiving identifier, such as an MTC controller dedicated to MTC data, and the priority of MTC data can be added to the RRC connection setup completion message.

When the network receives an RRC connection setup completion that includes MTC data, the network can send an RRC Connection Release to the WTRU to disconnect. This RRC disconnection can include IE to indicate that the WTRU must stop sending MTC data. Alternatively, the network can wait for as many RRC connection configuration complete messages as the WTRU needs to send all MTC data before sending the RRC disconnect. The WTRU can also send another message indicating to the WTRU that it can continue to send the RRC connection setup completion message with the attached MTC data. This message can be another RRC connection configuration with IE that is attached to another legacy RRC message or new message.

When the WTRU receives the RRC disconnect, the WTRU can stop sending MTC data to the network and include IE to indicate to the network that the WTRU has stopped sending MTC data, RRC disconnect complete. You can send (RRC Connection Release Complete). Instead of waiting for the RRC disconnect, the WTRU autonomously stops sending MTC data and either by sending an RRC disconnect complete without receiving any RRC disconnect, or by interrupting MTC data transmission. Discontinuing MTC data transmission to the network by sending another existing RRC message with IE to display, or, for example, by sending an RRC message that may be referred to as "MTC data transmission complete". You can notify.

To reduce the signaling load, the WTRU can autonomously disconnect without being instructed by the network. For example, a time-controlled device can autonomously disconnect without being commanded by the network, where the network and WTRU know in advance when the WTRU will send and receive data. Different solutions for autonomous RRC disconnection are presented below, but they may be used alone or in combination.

You can know in advance the expected duration of sending or receiving data. The WTRU can be disconnected after the duration has expired, where the start time can be, for example, the time when transmission or reception begins on the network or WTRU. In addition, the disconnect time may be configured to take into account the duration of transmission (or reception) and a certain time delay. The time delay can be a default value and / or a user or network configurable value.

In embodiments, the duration can be stored in the WTRU and configured once or at regular intervals by the network. In other words, there will be a default duration stored in the WTRU, but the network can update it via control messages, for example via RRC messages. The WTRU can save this new duration until it receives the updated duration.

In addition, the duration can be configured by the network during the connection setup phase. In this case, there will also be a default configuration used by WTRU. The values sent by the network can be reconfigured within the WTRU after each connection is closed.

The WTRU can autonomously disconnect the RRC connection after transmitting data. In an embodiment, the WTRU can autonomously disconnect the RRC connection after a period of time has passed since the last data was transmitted. In another embodiment, the WTRU autonomously makes an RRC connection if no uplink (UL) data is executed during a predefined time period and no DL data is received during this time period. Can be released. Data transmission may refer to upper layer data transmission or may take into account second layer (L2) transmission. Determining if no more data is available can be based on the buffer status of wireless link control (RLC). If the RLC acknowledgment mode (AM) and negative response data in use are still in the buffer, the WTRU can maintain the connection. Otherwise, the WTRU can disconnect when the above criteria are met.

The network can recognize that the WTRU has disconnected using one or a combination of the following methods: In the embodiment, the network can determine that the connection is terminated after a certain timer time has passed without receiving any data from the WTRU. In another embodiment, the WTRU can use an existing RRC message or a new RRC message to send an indication to the network to disconnect the RRC. Alternatively, the WTRU can send an L2 display (eg, a MAC message, in the header of an SI or as part of a payload or a special value) or an L1 signal. In another embodiment, the network is aware of the amount of data that the WTRU intends to send and can disconnect after this amount of data is received. This amount of data can be the default value or can be displayed by the WTRU or network before starting data transmission. Timers can be defined to define the maximum duration that a transmission can take to avoid a stall situation if the WTRU is unable to send some or all of its data. When the timer expires, the network can disconnect. This timer can be stopped once the entire data has been received by the network.

The network can autonomously disconnect the RRC connection when sending data to the WTRU. The WTRU can determine that the network has terminated the connection after a certain period of time after the WTRU has stopped receiving data from the network, where the WTRU can disconnect on the WTRU side. In addition, the WTRU can also terminate the connection if there is no uplink data to send over a period of time.

When the network sends data to the WTRU, it can autonomously disconnect the RRC connection, where the WTRU can know in advance a certain amount of data that the network will send to the WTRU, a fixed amount of it. Data was received. The amount of data can be the default value, or it can be configured by the network at the beginning of each data transmission, by a certain number of data transmissions, or by the amount until a reconfiguration occurs. If the network is unable to send some or all of the data, a timer can be defined within the WTRU to represent the schedule for receiving data for maximum duration. The WTRU can autonomously disconnect when the timer expires, even if the WTRU has not received the expected amount of data. Alternatively, when some or all of the data is received by the WTRU before the timer expires, the timer can be stopped and the WTRU can autonomously disconnect.

The WTRU can also be autonomously detached from the NAS when the conditions described herein are met. For example, once the RRC connection is disconnected, the WTRU has the following criteria: 1) No UL transmission in a given time period (eg, no request to start an RRC connection), 2) Time period No polling message requesting information on the WTRU has not been received, 3) there is no paging message for this WTRU, or no paging message has been received to cause the WTRU to initiate an RRC connection, 4) this time The NAS attachment can be disengaged when one or a combination of the time difference between and the next scheduled occurrence is greater than the threshold.

Note that the techniques disclosed herein can be used with any WTRU. The signaling reductions described herein will lead to power-reducing solutions that favor low-power devices. It should be understood that the concepts herein are applicable and extensible to many other use cases related to MTC communications. The disclosed technology results in the device being able to save power by transmitting MTC data over the control plane. It also discloses a technique that eliminates the need for connection procedures typically required by legacy transmission techniques. Part of this concept is applicable to some MTC applications, so it can be applied to an increasing number of scenarios.

It should also be noted that MTC devices can contain a subset of MTC futures. For example, a single MTC device can have the following futures: 1) time allowance, 2) time control, 3) congestion display. In this disclosure, the MTC futures referred to include features that result from MTC devices defined by 3GPP, but to other features that result from MTC devices within the 3GPP network, or to MTC devices in the context of other wireless networks. It can also include other features that result from it. The optimal combination of disclosed technologies depends on the specific features of the limited MTC device. Note that the concepts described herein can be applied to WTRUs other than MTC embodiments.

Although the features and elements have been described above in particular combinations, one of ordinary skill in the art should be aware that each feature or element can be used alone or in any combination with other functions and elements. In addition, the methods described herein can be implemented in computer programs, software, or firmware embedded in computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks and magnetic media such as removable disks, optical magnetic media, and CD-ROMs. Includes, but is not limited to, optical media such as digital multipurpose discs (DVDs). A processor that works with the software can be used to implement radio frequency transceivers for use with WTRUs, UEs, terminals, base stations, RNCs, or any host computer. Note that the messaging naming conventions used in the UMTS and LTE specifications may be expressed slightly differently. Unless otherwise noted, messaging naming conventions may be self-proclaimed in specific terms and in the context of their use disclosed as a whole. The terms futur, capabilities, and services herein may be used interchangeably. The methods herein are also applicable to WTRUs, which are not necessarily MTC devices.