U.S. patent application number 13/715685 was filed with the patent office on 2013-06-20 for method and apparatus for triggering machine type communications applications.
This patent application is currently assigned to INTERDIGITAL PATENT HOLDINGS, INC.. The applicant listed for this patent is INTERDIGITAL PATENT HOLDINGS, INC.. Invention is credited to Pascal M. Adjakple, Behrouz Aghili, Saad Ahmad, Samian Kaur, Kai Liu, Ulises Olvera-Hernandez, Guanzhou Wang, Peter S. Wang, Mahmoud Watfa.
Application Number | 20130155954 13/715685 |
Document ID | / |
Family ID | 47605726 |
Filed Date | 2013-06-20 |
United States Patent
Application |
20130155954 |
Kind Code |
A1 |
Wang; Peter S. ; et
al. |
June 20, 2013 |
METHOD AND APPARATUS FOR TRIGGERING MACHINE TYPE COMMUNICATIONS
APPLICATIONS
Abstract
A method and apparatus for triggering at least one machine type
communications (MTC) application using at least one wireless
transmit/receive unit (WTRU) is disclosed. The method includes
receiving a triggering message including a device trigger (DT) and
a maximum delayed response time value from a core network entity
(CN), storing the DT in the WTRU, initiating a timer in the WTRU
set to the maximum delayed response time value, and on a condition
that the timer expires, the WTRU transitioning to a radio resource
control (RRC) connected mode and dispatching the DT to the MTC
application.
Inventors: |
Wang; Peter S.; (East
Setauket, NY) ; Olvera-Hernandez; Ulises; (Kirkland,
CA) ; Aghili; Behrouz; (Commack, NY) ;
Adjakple; Pascal M.; (Great Neck, NY) ; Liu; Kai;
(South Huntington, NY) ; Watfa; Mahmoud; (Saint
Leonard, CA) ; Ahmad; Saad; (Montreal, CA) ;
Kaur; Samian; (Plymouth Meeting, PA) ; Wang;
Guanzhou; (Longueuil, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
INTERDIGITAL PATENT HOLDINGS, INC.; |
Wilmington |
DE |
US |
|
|
Assignee: |
INTERDIGITAL PATENT HOLDINGS,
INC.
Wilmington
DE
|
Family ID: |
47605726 |
Appl. No.: |
13/715685 |
Filed: |
December 14, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61570682 |
Dec 14, 2011 |
|
|
|
61590941 |
Jan 26, 2012 |
|
|
|
Current U.S.
Class: |
370/328 |
Current CPC
Class: |
H04W 76/27 20180201;
H04W 4/70 20180201; H04W 72/048 20130101; H04W 84/02 20130101; H04W
68/02 20130101; H04W 4/06 20130101; H04W 72/0446 20130101; H04W
68/005 20130101 |
Class at
Publication: |
370/328 |
International
Class: |
H04W 4/00 20060101
H04W004/00 |
Claims
1. A method for triggering at least one machine type communications
(MTC) application using at least one wireless transmit/receive unit
(WTRU), the method comprising: receiving a triggering message
including a device trigger (DT) and a maximum delayed response time
value from a core network entity (CN); storing the DT in the WTRU;
initiating a timer in the WTRU set to the maximum delayed response
time value; and on a condition that the timer expires, the WTRU
transitioning to a radio resource control (RRC) connected mode and
dispatching the DT to the MTC application.
2. The method as in claim 1, wherein the CN entity is a mobility
management entity (MME).
3. The method as in claim 1, wherein the CN entity is a serving
general packet radio service (GPRS) support node (SGSN).
4. The method as in claim 1, wherein the CN entity is a mobile
switching center (MSC).
5. The method as in claim 1, wherein the triggering message is
received in a cell broadcast.
6. The method as in claim 1, wherein the triggering message is
received in a non-access stratum (NAS) message.
7. A method for triggering at least one machine type communications
(MTC) application using at least one wireless transmit/receive unit
(WTRU), the method comprising: receiving a triggering message
including a device trigger (DT) and a maximum delay value from a
core network (CN) entity; the WTRU dispatching the DT to the MTC
application; receiving, at the WTRU, a trigger response message
from the MTC application; storing the trigger response message in
the WTRU; initiating a timer in the WTRU set to the maximum delay
value; and on a condition that the timer expires, the WTRU
transitioning to a radio resource control (RRC) connected mode and
forwarding the trigger response message to an MTC server.
8. The method as in claim 7, wherein the CN entity is a mobility
management entity (MME).
9. The method as in claim 7, wherein the CN entity is a serving
general packet radio service (GPRS) support node (SGSN).
10. The method as in claim 7, wherein the CN entity is a mobile
switching center (MSC).
11. The method as in claim 7, wherein the triggering message is
received in a cell broadcast.
12. The method as in clam 7, wherein the triggering message is
received in a non-access stratum (NAS) message.
13. A method for triggering at least one machine type
communications (MTC) application using a control) in a core network
(CN) entity, the method comprising: receiving an MTC device trigger
request from an MTC-interworking function (IWF); transmitting an
acknowledgment that the MTC device trigger request is being
processed; determining if the MTC device trigger request includes a
preference of point-to-point delivery; and transmitting the MTC
device triggering request to a wireless transmit/receive unit
(WTRU) using point-to-point delivery.
14. The method as in claim 13, wherein the CN is a mobility
management entity (MME).
15. The method as in claim 13, wherein the CN entity is a serving
general packet radio service (GPRS) support node (SGSN).
16. The method as in claim 13, wherein the CN entity is a mobile
switching center (MSC).
17. The method as in claim 13, wherein the MTC device triggering
request message is received in a cell broadcast.
18. The method as in claim 13, wherein the MTC device triggering
request message is received a non-access stratum (NAS) message.
19. A wireless transmit/receive unit (WTRU) for triggering at least
one machine type communications (MTC) application, the WTRU
comprising: a receiver configured to receive a triggering message
including a device trigger (DT) and a maximum delayed response time
value from a core network entity (CN); a processor configured to
store the DT; the processor further configured to initiate a timer
set to the maximum delayed response time value; and on a condition
that the timer expires, the processor is further configured to
transition to a radio resource control (RRC) connected mode and a
transmitter configured to dispatch the DT to the MTC application.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional
Application No. 61/570,682, filed Dec. 14, 2011 and U.S.
Provisional Application No. 61/590,941, filed Jan. 26, 2012, the
contents of which are hereby incorporated by reference herein.
BACKGROUND
[0002] With the progress of the wireless technologies and mobile
network deployments, wireless services for machine type
communication (MTC) through the mobile network has become an
important agenda under the third generation partnership project
(3GPP). Mobile networks are currently designed for human-to-human
communications, and are less optimal for machine-to-machine (M2M)
or machine-to-human applications. MTC provides data communication
involving one or more entities that do not necessarily need human
interaction.
[0003] Wireless transmit/receive units (WTRUs) are generally
programmed to autonomously set up a connection to report an event
through the mobile network. However, in some applications and
services it may be required that the network trigger the WTRUs. For
example, during a storm, a water authority may desire to monitor
dike and dam sensors in a specific area. It is expected that
millions of these types of WTRUs may be deployed, and may be polled
or triggered to initialize a message or a short message service
(SMS) by a network signal.
[0004] Since a large number of WTRUs may be triggered at the same
time in a relatively localized area for specific applications,
causing too many network resources to be consumed, enhancement of a
point-to-point delivery mechanism for WTRU triggering may be
desirable.
SUMMARY
[0005] A method and apparatus for triggering at least one machine
type communications (MTC) application using at least one wireless
transmit/receive unit (WTRU) is disclosed. The method includes
receiving a triggering message including a device trigger (DT) and
a maximum delayed response time value from a core network entity
(CN), storing the DT in the WTRU, initiating a timer in the WTRU
set to the maximum delayed response time value, and on a condition
that the timer expires, the WTRU transitioning to a radio resource
control (RRC) connected mode and dispatching the DT to the MTC
application.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] A more detailed understanding may be had from the following
description, given by way of example in conjunction with the
accompanying drawings wherein:
[0007] FIG. 1A shows an example communications system in which one
or more disclosed embodiments may be implemented;
[0008] FIG. 1B shows an example wireless transmit/receive unit
(WTRU) that may be used within the communications system shown in
FIG. 1A;
[0009] FIG. 1C shows an example radio access network and an example
core network that may be used within the communications system
shown in FIG. 1A;
[0010] FIG. 2 shows an example of 3GPP architecture for
Machine-Type Communication (MTC);
[0011] FIG. 3 shows an example network architecture for delivering
a trigger via cell broadcast services (CBS);
[0012] FIG. 4 shows an example of downlink non-access stratum (NAS)
evolved packet system (EPS) mobility management (EMM) MTC device
trigger request message used to carry content to an MTC
application;
[0013] FIG. 5 shows an example of a downlink NAS EMM MTC device
trigger request message used to carry short message service (SMS)
content;
[0014] FIG. 6 shows an example of a paging method;
[0015] FIG. 7 shows an example subframe allocation used by MTC
Device trigger/reach paging;
[0016] FIG. 8 shows an example paging message indicating that a
paging trigger is for MTC device triggering;
[0017] FIG. 9 shows an example RRC paging/MTC device trigger
message having the new message format;
[0018] FIG. 10 shows an example of a delay response procedure;
[0019] FIG. 11 shows that an MTC device/WTRU may delay a response
message transmitted by an MTC application;
[0020] FIG. 12 shows an example of the message format of dual
purpose MTC device service or attach+trigger response message;
[0021] FIG. 13 shows an example of extended-service request message
content;
[0022] FIG. 14 shows an example bit map that defines a cause value;
and
[0023] FIG. 15 shows the primary EMM states in an MTC
device/WTRU.
DETAILED DESCRIPTION
[0024] FIG. 1A shows 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,
and the like, 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.
[0025] As shown in FIG. 1A, the communications system 100 may
include 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.
[0026] 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 other networks
112. By way of example, the base stations 114a, 114b may be a base
transceiver station (BTS), a Node-B, an evolved Node-B (eNB), a
Home Node-B (HNB), a Home eNB (HeNB), 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.
[0027] 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, and the like. 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.
[0028] 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, and the like). The air interface 116 may be established
using any suitable radio access technology (RAT).
[0029] 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).
[0030] In another embodiment, the base station 114a and the WTRUs
102a, 102b, 102c may implement a radio technology such as evolved
UTRA (E-UTRA), which may establish the air interface 116 using long
term evolution (LTE) and/or LTE-Advanced (LTE-A).
[0031] 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 1X, CDMA2000 evolution-data optimized
(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 RAN (GERAN), and the like.
[0032] The base station 114b in FIG. 1A may be a wireless router,
HNB, HeNB, or AP, 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, and the like), 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.
[0033] 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, and the like, 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.
[0034] 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 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.
[0035] 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.
[0036] FIG. 1B shows an example WTRU 102 that may be used within
the communications system 100 shown in FIG. 1A. As shown in FIG.
1B, the WTRU 102 may include a processor 118, a transceiver 120, a
transmit/receive element, (e.g., an antenna), 122, a
speaker/microphone 124, a keypad 126, a display/touchpad 128, a
non-removable memory 130, a removable memory 132, a power source
134, a global positioning system (GPS) chipset 136, and 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.
[0037] The processor 118 may be a general purpose processor, a
special purpose processor, a conventional processor, a digital
signal processor (DSP), a microprocessor, one or more
microprocessors in association with a DSP core, a controller, a
microcontroller, an application specific integrated circuit (ASIC),
a field programmable gate array (FPGA) circuit, an 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. 1B depicts the processor
118 and the transceiver 120 as separate components, the processor
118 and the transceiver 120 may be integrated together in an
electronic package or chip.
[0038] 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. The transmit/receive element 122
may be configured to transmit and/or receive any combination of
wireless signals.
[0039] In addition, although the transmit/receive element 122 is
depicted in FIG. 1B 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.
[0040] 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.
[0041] 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).
[0042] 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), and the like), solar cells, fuel
cells, and the like.
[0043] 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. The
WTRU 102 may acquire location information by way of any suitable
location-determination method while remaining consistent with an
embodiment.
[0044] 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.RTM. 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.
[0045] FIG. 1C shows an example RAN 104 and an example core network
106 that may be used within the communications system 100 shown in
FIG. 1A. 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.
[0046] The RAN 104 may include eNBs 140a, 140b, 140c, though it
will be appreciated that the RAN 104 may include any number of eNBs
while remaining consistent with an embodiment. The eNBs 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 eNBs 140a, 140b, 140c may implement MIMO
technology. Thus, the eNB 140a, for example, may use multiple
antennas to transmit wireless signals to, and receive wireless
signals from, the WTRU 102a.
[0047] Each of the eNBs 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 eNBs 140a, 140b, 140c may communicate with one another over
an X2 interface.
[0048] The core network 106 shown in FIG. 1C may include a mobility
management entity (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.
[0049] The MME 142 may be connected to each of the eNBs 140a, 140b,
140c in the RAN 104 via an S1 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.
[0050] The serving gateway 144 may be connected to each of the eNBs
140a, 140b, 140c in the RAN 104 via the S1 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-eNB 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.
[0051] 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.
[0052] 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.
[0053] Hereinafter, the terms "WTRU," "MTC device," and "device"
may be used interchangeably.
[0054] FIG. 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 240. The
WTRU 225 may host one or multiple MTC Applications 240. The
corresponding MTC Applications 225 in the external network may be
hosted on one or multiple Application Servers (ASs) 260 ultimately
connected to the SCS 205.
[0055] 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 201, for example control pane device triggering, and
provided by the SCS 205.
[0056] 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.
[0057] For a roaming scenario, the MTC-IWF 204 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.
[0058] 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.
[0059] 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.
[0060] 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.
[0061] 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.
[0062] 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).
[0063] The MTC device may already be attached to the network and
have a data connection with the network, or it may be attached to
the network but have no connection established. In this case, it is
called "online," which means that the MTC devices are registered
with the network.
[0064] The MTC device may be unattached to the network or
"offline," which means that the device is currently in an
"unregistered" state with the network. The network may still have
some knowledge about the MTC device. The MTC-IWF may need to keep
the SGSN/MME addresses of an MTC device, per its IMSI or its device
ID.
[0065] Additionally, the 3GPP network may support control signaling
between the network entity SCS/SME and the 3GPP system via the Tsms
reference point for submission of the device trigger requests as
part of user data of a mobile terminated SMS (MT-SMS). The Tsms
reference point is provided by an SMS-SC. The SMS-SC may reside at
the edge of the operators' network. The SCS may request the SMS-SC
to deliver a device trigger over the Tsp.
[0066] In LTE, the network may reach the idle mode WTRUs through
paging operations such that the network transmits paging messages
at specific time occasions to the WTRUs having an incoming call.
The WTRUs may be monitoring the paging periodically in occasions
assigned to them based on their WTRU IDs. The WTRUs may be
identified by the WTRU ID in the paging message.
[0067] Alternatively, the network may reach idle mode WTRUs by
broadcasting a system information broadcast periodically according
to a schedule. WTRUs looking for system information may check and
receive the system information when it is broadcast according to
the scheduling.
[0068] Alternatively, the network may reach the idle mode WTRUs
through multimedia broadcast multicast services (MBMS) mechanisms
such that the network multicasts MBMS information and data over the
multimedia broadcast over single frequency network (MBSFN)
subframes (where no regular unicast is ongoing) and the WTRUs
supporting MBSFN subframe reception may monitor the control
information and receive the MBMS data on the MBSFN subframes
according to the MBMS scheduling.
[0069] For MTC devices that are location fixed or location known,
the network may employ some broadcast/multicast mechanisms for
device triggering whether they are currently registered or not. The
PLMN may multicast/broadcast a trigger message in a relevant cell
or group of cells for efficiency to meet MTC communication scaling
requirements. The MTC devices may be programmed to monitor a preset
cell broadcast channel, even when they are not attached to the
network, and have assigned a unique paging identity (UPID). The SCS
may transmit the MTC device trigger in cell broadcast messages to
its MTC devices this way if the location information is available
in the SCS.
[0070] For cell broadcast service (CBS) configuration, a mobile
network operator may provide an interface to the cell broadcast
center (CBC) to third parties. The SCS may transmit a trigger
containing, for instance, geographic information and trigger
information to the MTC-IWF over Tsp. The MTC-IWF may then act as a
cell broadcast entity (CBE) to deliver the message to the CBC. The
CBC may then distribute the cell broadcast message to the relevant
MME. The CBS in LTE may be equated to the emergency warning message
distribution.
[0071] FIG. 3 shows an example network architecture for delivering
a trigger via CBS. The network architecture in FIG. 3 includes the
CBE 301, the MTC-IWF 305, the CBC 310, the MME 315, the RNCs 320,
the eNBs 325, a 3G network 330, and an LTE network 335.
[0072] In 3GPP 330, for the Earthquake and Tsunami Warning Service
(ETWS) and Area Mail systems, the distribution area may be
specified in cell units. However, in LTE 335, the distribution area
may be specified in three different granularities: cell, tracking
area, or emergency area (EA).
[0073] When the CBC 310 receives a request for emergency
information distribution from the CBE 301, it may create a text to
be transmitted to the terminals and specifies the distribution area
from the information in the request. The CBC 310 may then transmit
a write replace warning request message to the MME 315. When the
MME 315 receives this message, it transmits the information to the
eNBs 325 as specified in the distribution area.
[0074] When the eNBs 325 begin transmission of the emergency
information, a paging message in which the ETWS indication is set
is transmitted to the mobile terminal, for example, the WTRU. If a
paging message containing an ETWS indication is received, the
terminal begins receiving the system information broadcast that
contains the emergency information. The eNBs 325 may use the
message identifier to determine how the message is broadcasted, the
distribution area (cell list), primary notification identifier, and
secondary notification information, if available. Upon completion
of a broadcast, the eNBs 325 return the result to the MME 315.
[0075] Core network congestion avoidance and backoff (BO) timers
may be used in conjunction with MTC devices. A BO timer may be used
to avoid congestion in a network due to access by numerous devices.
Note that the BO timers also apply to WTRUs that are not MTC
devices. BO timers may apply to WTRUs that are configured as low
priority devices, for example, MTC devices, and to WTRUs that are
not configured for low priority devices. Devices that are
configured as low priority may set the radio resource control (RRC)
establishment cause to "delay tolerant" when they attempt to obtain
an RRC connection.
[0076] There may be a general mobility management BO timer per core
network (CN) domain. For example, T3346 may be used for a packet
switched (PS) domain and T3246 may be used for a circuit switched
(CS) domain. This BO timer may also be referred to as a session
management BO timer.
[0077] There may be a BO timer per access point name (APN). This
timer may be used for session management to setup, modify, or
release packet data network (PDN) connections. The WTRU may run at
least one BO timer. Each timer may map to only one APN. This BO
timer may also be referred to as a session management BO timer.
[0078] The WTRU may run both a mobility management and session
management timer. If a mobility management timer is running in the
WTRU, then the WTRU may not initiate a request, except if the WTRU
is establishing a PDN connection for emergency calls or already has
such a PDN connection established, or the WTRU is accessing the
system with a specific access class 11-15. In both of these cases,
the establishment cause used to obtain an RRC connection may not be
set to "delay tolerant". The eNB may, upon detection of congestion,
reject a connection after identifying a device as low priority, for
example the RRC establishment cause="delay tolerant". The eNB may
also provide a WTRU with a BO timer at the RRC layer. This BO timer
may be known as an extended wait timer (EWT). When this happens,
the RRC layer in the WTRU may provide the timer to the non-access
stratum (NAS) which may run the mobility management timer with a
value set to that of the indicated EWT.
[0079] A WTRU that is requesting a connection and the establishment
cause does not indicate "delay tolerant", (even if the WTRU is
configured as a low priority device, e.g., the WTRU sets an
establishment cause to "emergency", despite being a "delay
tolerant" device), may receive an EWT. If this occurs, the RRC may
provide it to the NAS, which may ignore the EWT as this only
applies to accesses with establishment cause set to "delay
tolerant".
[0080] Given the T5 interface in FIG. 2 and the mechanism with the
T5 direct MTC device triggering to the WTRU using an NAS message
though the CN controlling node, embodiments for the new NAS message
based solutions are disclosed including the T5 interface protocol.
The new NAS message triggering mechanism may need new procedures
over new parameters that would fulfill the task of device
triggering within the 3GPP network.
[0081] Since a large number of MTC devices may be triggered around
the same time in a relatively localized area for certain specific
MTC applications, the point-to-point delivery mechanism for MTC
device triggering may not be optimum since it may consume too many
network resources at the same time. For downlink reaching methods,
multicast mechanisms and enhanced paging mechanisms may be
used.
[0082] A BO timer may be applied to devices that are low priority
as well as devices that are not low priority. If the BO timer is
running in the WTRU, for example, the mobility BO timer, the WTRU
may request a connection and access the system if the WTRU needs to
setup an emergency call, (or already has setup one), or if the WTRU
is accessing the system with access class 11-15. The WTRU may be
allowed to receive emergency calls, but the network operator may
not want the WTRU to transmit additional requests for other PDN
connections that are not related to emergency calls, for example,
not related to IMS emergency calls. However, since the WTRU may
only be running a mobility management timer, but not a session
management timer, the WTRU may not see any restriction that
prevents it from transmitting session management requests.
[0083] One possible method to combat this may be to configure the
WTRU such that, if the WTRU is already running a BO timer, then the
WTRU may not initiate other session management requests unrelated
to the emergency call if it has a PDN connection for emergency
calls and the WTRU was backed off. Also, the network may provide
the WTRU with session management BO timers to prevent this from
occurring. However, the primary problem may be that when the WTRUs
ignore the BO timers and transition to a connected mode, (for
example, for emergency calls or because of accessing the system
with access class 11-15), the network may not be able to
differentiate between the WTRUs that are requesting emergency calls
but do not belong to access class 11-15, and WTRUs requesting
emergency calls but belong to access class 11-15. If this
information is missing at the network, the network may block
non-emergency requests from all WTRUs that have an emergency PDN
connection, even though the WTRUs that belong to access class 11-15
have the "right" to access the system for non-emergency
purposes.
[0084] Embodiments for delivering the MTC device triggers from the
MTC-IWF to the WTRU are described hereafter.
[0085] A T5 interface may connect an MTC interworking function
(MTC-IWF) to a relevant CN node. Specifically, the T5a interface
may connect the MTC-IWF to an SGSN, the T5b interface may connect
to an MME, and the T5c interface may connect to an MSC. Both T5a
and T5b interfaces may be IP network interfaces. GTPv2 is the top
level protocol and GTPv2 runs over the UDP transport. The T5
interface may be used to carry MTC related SMS messages as well as
other MTC related formatted messages such as NAS messages, for MTC
device triggering or other purposes. One or more of the following
attributes may be used to build a GTP tunnel (a distinct TEID) over
the T5 interface: MTC message type (for example, SMS vs. other
plain format messages) or a delivery mechanism; delivery scheduling
priority and/or delivery schedules and/or traffic types (for
example, establishing connection over c-plane only or u-plane
connection needed or other types of triggering results); an
individual RAN node or a group of RAN nodes (for example, eNBs or
NodeBs or HeNBs/HNBs); local networks (for example, selected IP
traffic offload (SIPTO)/local IP access (LIPA) nodes, such as
L-GWs); mobile location areas (for example, tracking areas or
routing areas); MTC device type or device service/application
category; and MTC device (WTRU) current connection status (for
example, idle vs. connected). The T5 interface may not only
transport an MTC device trigger request and response messages
between the MTC-IWF and the relevant CN nodes, the T5 interface may
also carry the message for MTC device (upon roaming) location
update information or the WTRU registration status information,
including its DRX/sleep cycle configuration and lengths, from the
CN nodes to the MTC-IWF.
[0086] The following procedures, messaging, transactions may be
used in any combination. The CN node may transmit an
acknowledgement that a request is being processed. The CN node may
transmit an acknowledgement that a request is being processed, with
a result of the processing. For example, the result of the
processing may be failure or success and a reason code. The reason
code may indicate the failure of the reachability using a specific
method, for example, failure to reach via SMS, or failure to reach
via user plane (UP). This may be used by the recipient (e.g.,
MTC-IWF) to try another reachability method. The CN node may
transmit a failure due to unavailability of resources,
alternatively with a backoff (BO) period during which the recipient
(e.g., MTC-IWF) may not retry. The BO time may be for a specific
device or for all devices, or a group of devices. In general, one
node that implements the T5 interface may at any time inform
another node about congestion start or end for one, a group, or all
devices. The BO indication may be associated with an interval
during which no request may be made. An exception to this rule may
be requests for urgent or emergency communication or communication
to a device that is high priority or that is a member of a specific
class, and the like. Thus, a node (e.g., MTC-IWF) may indicate in
all the T5 messages whether the request is for a "regular" or
"prioritized" device or application within a device.
[0087] When the MTC-IWF has determined to invoke an MTC device
trigger via the T5 interface, a T5 MTC device trigger message may
be dispatched to the target. The T5 MTC device trigger message may
be transmitted from the MTC-IWF to the CN controlling node, such as
MME, SGSN, or MSC. The content and parameters of the message and
the related semantics are described below. An MTC device trigger
message from the MTC-IWF to the CN controlling node may contain one
or more device triggers to one or more MTC devices or to one or
more MTC device groups.
[0088] One or more of the following parameters may be transmitted
in the T5 message to the CN controlling node for a device to be
triggered: trigger request validity time, triggered device internal
identities, MTC device locations, device reaching mechanisms,
trigger device response expected, MTC device application profile,
MTC device response time, MTC response type, trigger delivery
urgency, and MTC device application ID.
[0089] The trigger request validity time may be the time that is
passed to the CN controlling node to determine if the trigger is
still valid. The triggered device internal identities, within a
PLMN, may include the WTRU device ID, assigned MTC device ID,
device paging/multicast ID, and/or device group ID in paging or
multicast.
[0090] The MTC device locations may be, for example,
tracking/routing area IDs, cells, such as cell-IDs physical cell
identities/primary scrambling codes (PCIs/PSCs), a local health
network (LHN) ID, home NodeB (HNB) ID, and closed subscriber group
(CSG) ID. The device reaching mechanism may be, for example,
point-to-point, paging, broadcast, and multicast. The trigger
device response expected may be, for example, user plane (U-plane),
control plane (C-plane) only, and simple-ACK.
[0091] The MTC device application profile may be, for example,
access point name (APN) and operating system (OS) profile. The MTC
device response time may be the time at which the device may
respond, the time before which the device may manage or respond,
the time after which the device may respond, or a time interval,
(i.e., specified by a start and end time) during which a device may
respond. The MTC response type may be whether an individual
response is required for an independent device or a device that is
part of a group of devices or a group-based response is
desired.
[0092] The trigger delivery urgency indicator may be a trigger that
needs to be delivered regardless of whether the network is
overloaded or not.
[0093] The MTC device application ID may be used to trigger at
least one application or multiple applications within the device.
This may be a bitmap that identifies the applications. A value of 1
may indicate that the trigger applies to the application related to
the bit position and a value of 0 may indicate that the application
(corresponding to the position of the bit in question) is not being
triggered. The relation of bit position to the type of application
may be configured and known to both the device and the network, or
may be negotiated upon registration of the device. In addition,
there may be one application ID for which all of the above items
are provided, for example, regarding response time, response type.
Alternatively, all of the previous items may be applicable to all
the applications that are being triggered. Moreover, some of the
above items may apply to all or specific applications. For example,
the response time or type may be for all applications, or there may
be such information per application.
[0094] The above parameters may be used in any combination and are
not restricted to MTC devices. Alternatively, these parameters may
be pre-configured in the devices or preconfigured in the CN nodes
or according to operator policies. The CN nodes may provide the
required response characteristics, for example, as per the above
parameters.
[0095] For an MTC-IWF generating MTC trigger requests to the CBC,
to enable group MTC device triggering, another granularity of
triggering area may be introduced to specify an MTC triggering area
for MTC devices belonging to a certain PLMN, operator, and the
like. A PLMN specific message identifier may be used so that WTRUs
not interested in the messages may discard them.
[0096] When the MTC-IWF receives MTC device trigger requests from
the SCS, the MTC-IWF may determine which device trigger delivery
mechanism to use to reach the concerned MTC device or MTC devices.
The MTC device trigger delivery mechanisms may include (but not
limited to) one or more of the following. An SMS delivery mechanism
over the T4 interface towards the SMS-SC, subsequently using SMS
delivery path. A direct message transmitted over the T5 interface
towards the CN controlling node. An SMS properly formed at the
MTC-IWF and encapsulated in a T5 Protocol Data Unit to the
MME/SGSN. A control or command transmitted towards the PDN gateway
(P-GW)/gateway GPRS support node (GGSN) or to serving gateway
(S-GW) for the MTC device trigger to go over the usual user-plane
path to the MTC devices.
[0097] In the case that a particular WTRU (MTC device) has so
registered such that more than one delivery mechanism may be used,
for example, a WTRU has registered with CS and PS for SMS and PS
for NAS message triggering, the delivery mechanism may be chosen by
the MTC-IWF according to one or more of the following: information
acquired from the HSS subscription record, information accumulated
in the MTC-IWF, for example, during WTRU registration operation,
mobility management operations, network load management (SON) from
the CN nodes, or information supplied by the MTC-server or the MTC
operation, administration, and maintenance (OAM).
[0098] The MTC-IWF may try several methods according to a specific
order which may be based on an ordered list of methods as received
from the HSS, or as preconfigured in the MTC-IWF or as per
recommended method that may be received from any CN node. The above
methods may be used in any combination.
[0099] The MTC user, for example, a power meter company, may
specify a delivery method for all the devices it tries to reach, or
the user of the MTC device/WTRU in the subscription data may give
consent for a preferred method.
[0100] The MTC device may be in one of the following operating
states: connected currently active, connected in long discontinuous
reception (DRX) state/mode, idle state but remain registered, or
offline or deregistered. For connection currently active, the MTC
may use a point-to-point delivery method such as SMS or direct NAS
message. For connected in long discontinuous reception (DRX)
state/mode, the MTC may use a T5 delivery method to invoke
multicast triggering. For idle state but remain registered, the MTC
may use a T5 delivery method to invoke multicast triggering. For
offline or de-registered, the MTC may use a T5 delivery method to
invoke multicast triggering.
[0101] The MTC-IWF may receive relevant CN load conditions and/or
relevant RAN load conditions, and may choose a lighter-loaded path
(hence the delivery mechanism) to dispatch the triggering
indication. MTC device location in the PLMN network may be
considered where a certain delivery mechanism is available or
preferred. If a U-plane path for MTC-device response is expected,
the point-to-point SMS or NAS message trigger may be used. If a
C-plane response is needed, any method may be used. If a simple ACK
is needed, a NAS message+a multicast method may be used.
[0102] The MTC-IWF may deliver the MTC triggers over the T5
interface if the target CN is not overloaded. However the MTC
device triggers, marked with a "trigger delivery urgency
indicator," may be delivered to the congested CN. The MTC device
triggers with the "trigger delivery urgency indicator" may come
from those particular SCSs specifically authorized and/or
authenticated to input such urgent device triggers.
[0103] The MTC-IWF may collect the responses from the T5 interface
on various T5 trigger requests. If a negative acknowledgment comes
back from the MME, or no response is received during a specific
time interval, one of more of the following may be performed by the
MTC-IWF. The MTC-IWF may initiate another delivery if the original
request is still valid, for example, remaining time in validity
period. Alternatively, if the CN is overloaded and the validity
time is not over, a suspend report and subsequent actions of the
MTC-IWF may be based on a failure value from the MME/SGSN/MSC.
Alternatively, the MTC-IWF may transmit a failure report to the
SCS, or to a default node. The default node may be preconfigured in
the MTC-IWF or may be specific to every device. For example, the
HSS may provide the MTC-IWF that the SMS-SC is the default node, or
last resort destination, for a particular device or group of
devices in which all or a subset of other reachability methods
fail.
[0104] The MME/SGSN may decide whether the MTC device trigger may
be delivered using point-to-point NAS message, SMS, via RAN level
paging, or CBS. The MME/SGSN may also decide whether the MTC device
trigger maybe delivered using a multicast method based on the WTRU
state, WTRU location, WTRU capability, such as, registered
information, RAN load situation, and the trigger request validity
time duration. One or more of the following considerations maybe
used by the MME/SGSN.
[0105] The MME/SGSN may decide that the device trigger may be
delivered point-to-point via an NAS MTC device trigger message or
an SMS message, if the MTC device/WTRU is in a connected state with
an active C-plane connection, if the trigger validity time is
longer than the expected MTC device/WTRU's next non-MTC related
uplink activity, if the device is in a RAN, cell, or area, for
example, a tracking area (TA), routing area (RA), location area
(LA), that is not heavily loaded, or if the trigger request comes
from the MTC-IWF with the preference of point-to-point delivery.
For example, related uplink activity may be the next tracking area
update (TAU).
[0106] The MME/SGSN may decide to use one-to-many signaling, for
example, paging, CBS, or multicast, if one or more of the following
is relevant: if the MTC device/WTRU is in a connected state but
under long DRX mode (in the MTC this may mean one half minute to
several days or more) or the MTC device/WTRU does not have an RRC
Connection, if the WTRU capability indicates it may receive
one-to-many signals, for example, paging, CBS or multicast; if the
trigger validity time remaining indicates a trigger action needs to
be taken soon; if the trigger request comes from the MTC-IWF with
the preference of a point-to-many delivery method; if there is a
large number of triggers from the MTC-IWF; or if the eNB, where the
device to be triggered resides, supports one or more of the
point-to-many delivery for MTC device triggers.
[0107] When the MME decides to use point-to-many delivery
mechanism, for MTC device trigger requests from the MTC-IWF, the
MME may buffer/accumulate the similar requests together for a while
for the same eNB or for a similar trigger time. For example, the
MME may buffer/accumulate a certain portion of the request validity
time.
[0108] The MME/SGSN may hold back the delivery of triggers to the
RAN that have indicated overload. However those triggers that are
marked with an "urgency indicator" may be delivered to the RAN
regardless of overloading/congestion or not.
[0109] Alternatively the delivery mechanism decision may be made by
an eNB or jointly by the MME and the eNB. For point-to-many
delivery of the MTC device triggers, the eNB may decide which
mechanism to use, how the MTC device responds, and how to schedule
the trigger delivery.
[0110] The MME and/or the eNB may collect the responses or the
acknowledgments from the MTC devices/WTRUs and determine whether a
re-attempt or a failure report or failure action may be taken.
[0111] For a network node CBC in the MTC device trigger system,
when the CBC transmits a trigger related message to the MME, a new
message identifier may be introduced from the CBC to the MME to
initiate the MTC device trigger start/replace. The new message may
map to an existing or new primary notification and include
additional information such as distribution area, MTC group
identifier, a list of MTC devices that are being triggered,
repetition period, and number of broadcasts requested.
[0112] In order to avoid that this capability does not interfere
with the original purpose of the CBS, for example, warning system
for natural disasters and other events, the CBC may assign
priorities to the entities assigned to it, and the message
identifiers it receives. The CBC may ensure that all public warning
messages are broadcast before any MTC triggering messages are
broadcast.
[0113] In order to address the scalability of using the broadcast
resources for triggering a large number of devices, the CBC may
spread the MTC triggering notifications to restrict the number of
devices triggered per message, or transmitted a new distribution
period to the eNB.
[0114] A home NodeB (HNB) and home evolved NodeB (H(e)NB) gateway
(H(e)NB-GW) may be deployed as a proxy to handle the MTC devices.
Under this model MTC devices may be locally attached to the H(e)NB
without requiring periodic network registrations. Such devices may
be present at the H(e)NB subsystem level.
[0115] In a deployment where MTC devices, low priority devices or
any other device holding similar characteristics, need to be
contacted to either push or pull data, the concept of HeNB GW may
be used to enable at least the following capability. The MTC device
may register to the HeNB GW prior or during regular network
registration and the HeNB GW may be used as a proxy to allow for
addressing the device using a group-ID based on the HeNB GW-ID or
for periodic HeNB GW registration with a periodicity less or equal
to the regular periodic network registration.
[0116] If an MTC device roams into a different PLMN, or if the MTC
device incurs any tracking area change or serving cell change that
may involve a serving CN node change, the target CN node may need
to update the MTC-IWF on the location changing of the particular
MTC device or WTRU. The update information may include the WTRU-Id
including the MTC-ID or the MTC-Group-Id, the IMSI or other forms
of MTC device internal ID, or the new location information such as
cell-id, RAN-node-Id, or Area-Id. The device MTC information may
include one or more of the scheduling information, for example, the
DRX cycle length, the current C-plane and/or U-plane connection
information, and additional RAN mechanism information, for example,
using MBMS or using CBS for triggering.
[0117] The target CN node may obtain the information from the
source CN node during the roaming handling procedure, or the target
CN node may obtain these information from the RAN node or from the
WTRU directly. If an MTC device moves to a different tracking area
or changes to a different serving cell within the same CN node, the
target RAN node may need to update the CN node with one or more of
the pieces of information described above.
[0118] An NAS MTC device trigger, for example, an MTC device
trigger request, message may be constructed at the mobility
management (evolved packet system (EPS) mobility management (EMM)
or global multimedia mobility (GMM)) level at the MME. The NAS MTC
device trigger message may be delivered to an MTC device or WTRU
when it is in evolved packet system (EPS) mobility management
(EMM)-connected mode (EMM-registered-normal-service). Alternatively
an existing downlink NAS MM level message may be modified to
contain one or more of the following parameters with similar
semantics defined below to perform the MTC device trigger.
[0119] The NAS MTC device trigger message may contain one or more
of the following parameters: an MTC device ID or MTC device group
ID, an MTC device trigger authorization code, a security parameter
for subsequent device-network interaction, a trigger request type,
a response type and duration, a response ID, a response resource
type, a responding-area-scope, an MTC device message container, and
a type of MTC application or application ID.
[0120] The MTC device ID or the MTC device group ID may be that
with which the WTRU performs some authorization check to see if it
is the intended recipient given the group-paging, CBC and the
multicast. The MTC device trigger authorization code helps the WTRU
to verify the trigger source (SCS) feature for MTC feature control,
whether the MTC device is allowed to be triggered this way. The
security parameter for subsequent device-network interaction may be
for example, a KSI, an encryption-algorithm or a security nonce.
The presence or absence of this parameter may determine the WTRU
response security level.
[0121] The trigger request type may be, for example, the purpose of
the triggering. For example a trigger that is simply for monitoring
to see if the device is still alive or a trigger that may command
the device to perform some task, such as to open a gate, or a
trigger to ask the device to transmit certain data and then
download new software and then reset. The trigger request type may
dictate how the WTRU is to respond to the trigger.
[0122] The response type and duration may indicated whether the
WTRU response may be immediate or may be delay tolerant within the
duration or the WTRU may use higher priority approach if at the end
of the response duration. The response ID may be assigned by the
MME to identify the WTRU response. The response resource type may
be, for example, U-plane EPS-bearer, associated APN, LGW, or
C-plane, or a simple response such as ACK. The
responding-area-scope, for example, if the device is roaming, may
indicate in which cell, which area, or which PLMN the WTRU is
allowed to transmit the response.
[0123] The MTC device message container may include MTC application
specific contents to the possible MTC layer or to the MTC
application. The type of MTC application or application ID may be
used to indicate which one MTC application needs to transmit the
response if there are multiple MTC applications running on the
device.
[0124] FIG. 4 shows an example of a downlink non-access stratum
(NAS) evolved packet system (EPS) mobility management (EMM) MTC
device trigger request message used to carry content to an MTC
application. The "MTC specific message container" information
element (IE) may allow the MTC specific application information to
be encapsulated therein. This may facilitate the specific
information passing either to an MTC layer, if there are multiple
MTC applications on a device, or to the MTC application.
[0125] FIG. 4 includes information element indicator (IEI) 405, an
information element 410, a type/reference of the information
element 415, presence of the information element 420, format of the
information element 425, and length of the information element 430.
The information elements contained in the EMM message may be
protocol discriminator 410(a), security header type 410(b), MTC
device trigger request 410(c), MTC device ID or group ID 410(d),
authorization or security code 410(e), MTC device trigger request
type 410(f), trigger response resource type 410(g), response ID
410(h), response area scope 410(i), and MTC specific message
container 410(j). When the MTC device/WTRU receives the MTC device
trigger request message, the MTC device/WTRU may respond with an
MTC device trigger response message to the MME. The IEI for the MTC
specific message container IE 410(j) is XX 405(j).
[0126] The T5-Direct-SMS interface is between the MTC-IWF and the
MME, which may be used to carry MTC device trigger SMS for PS-only
WTRUs. When the network is equipped with this capability, the
network may indicate this capability/configuration/setup to the
WTRUs in system information directly or embedded in the NMO part of
the system information elements. The network may also indicate the
capability/confirmation/setup to the WTRUs in NAS response messages
to the first WTRU NAS request messages, for example, attach accept
or TAU accept. A PS-only WTRU with this T5-direct-SMS capability
may register to this type of service with special "PS-only-SMS"
attach type in single and combined attach activities.
[0127] If the WTRU has more than one MTC trigger reception
capability, the WTRU may choose one capability for the session, or
the WTRU may indicate all for subsequent MTC-related communications
and let the network pick one mechanism for subsequent operations.
For example, the MTC reception capabilities may be SMS, NAS
message, or direct-MTC-SMS.
[0128] When the MTC-IWF needs to transmit a trigger message over T5
SMS to the WTRU, the MTC-IWF may first verify, either through an
HSS, an SCS or some other entity in the network or directly,
whether or not it has a T5 connection to the MME. When the T5
association with the MME is created then the MTC-IWF may continue
with the procedure. The MTC-IWF may build and encapsulate the SMS
message into the value part of the NAS message container
information element of a T5-DOWNLINK-DATA message or a similar
message and transmit this message to the MME. This NAS message
container or the T5-downlink-data message may contain a new element
indicating that this SMS is over device trigger purpose.
[0129] When the MME receives a T5-downlink-data message, the MME
may copy the contents of the NAS message container information
element to the value part of the NAS message container information
element of a Downlink NAS Transport message and transmit the
downlink NAS transport message to the WTRU. It may also transmit a
special indication informing the WTRU that the SMS message is for
paging the MTC device. This procedure may be applied for the uplink
case when the device transmits an SMS response to the trigger
request message.
[0130] If the WTRU is in an idle mode, the MME may transmit a page
message for device trigger. This paging message may contain an
indication informing the WTRU that it is for device trigger. Upon
receiving this paging, the WTRU may start the service request
procedure, and the MME may then forward the trigger SMS as part of
a service request procedure.
[0131] In addition to carrying the MTC specific message in the
above described MTC device trigger request, the message may be used
to carry an SMS to an MTC device at the point of an MME. Message
format wise, this may be accomplished through explicit coding
through the IEI field, such that a special IEI=XY indicates the SMS
container.
[0132] FIG. 5 shows an example of a downlink NAS EMM MTC device
trigger request message used to carry SMS content. This message may
use a carrying container type to indicate which kind of payload,
(MTC specific or an SMS), is included. FIG. 5 includes IEI 505, an
information element 510, a type/reference of the information
element 515, presence of the information element 520, format of the
information element 525, and length of the information element 530.
The information elements contained in the EMM message may be
protocol discriminator 510(a), security header type 510(b), MTC
device trigger request 510(c), trigger content type 510(d), MTC
device ID or group ID 510(e), authorization or security code
410(f), and MTC SMS container 510(j). The IEI for the MTC SMS
container IE 510(j) is XY 505(j).
[0133] If the WTRU is in an EMM-idle mode or in an EMM-deregistered
state, the MME may page the WTRU. If the WTRU learns from the
paging that an MTC device triggering is in effect, other than a
pure WTRU paging, the MTC device may respond with a different first
MM message, other than the Service Request with "paging response",
as the MTC device trigger response and may establish a different
signaling path avoiding unnecessary U-plane bearer
establishment.
[0134] The current RRC paging message may be modified to inform
WTRUs that this is a paging for an MTC device trigger.
[0135] FIG. 6 shows an example of an RRC paging method. As shown in
FIG. 6, the WTRU-ID 601 may be set to be an MTC-ID-info 605 or an
MTC-group-ID-info inside the paging record IE paging WTRU-ID. A new
field called "MTC-ID-info" 615 may be added to indicate that the
concerned paging record is for an MTC device trigger or some other
MTC related downlink reaching activity. The MTC-ID-info 605 or the
MTC-group-ID-info IE may expand to the field MTC-identity-info 610,
which may contain one or more of the following information
specifically for the MTC activities: the value of the IMSI or
international mobile equipment identity (IMEI) of the MTC device;
the value of an assigned MTC identity or the MTC Group ID of the
device; the category or the purpose or the intended action command
of the MTC paging action, for example, for an MTC device trigger,
for an MTC small data Tx, for an MTC device monitoring check, for a
device to take an action (i.e., open/close a gate), or for a device
maintenance action; and the paging response type indicator
indicating how the WTRU responds to this paging. For example, the
WTRU may respond by establishing a regular EPS connection or
establishing a signaling connection or act for a simple response to
the paging.
[0136] In order to not impact the legacy WTRUs, or non MTC WTRUs,
with the existing paging procedures by the MTC device
triggering/reaching specifics (i.e. the more frequent paging
occasion intent), one or more of the following may be employed by
the network and the MTC devices/WTRUs.
[0137] In a first example, the paging message for MTC devices/WTRUs
may be transmitted on a different time occasion than the regular
paging. The paging message may be transmitted on a different LTE
frame than the regular WTRU paging frames as the following
scheduling form:
(SFN+j) mod T=(T div N)*(WTRU_ID mod N), Equation (1)
where j is an offset frame number separating an MTC paging frame
from a regular paging frame and j=[1, 2, . . . , (T div N)-1]. The
frame offset number j may be predetermined or network configured.
The WTRU ID may be calculated by IMSI or by MTC identity.
[0138] In a second example, the same or different LTE paging frame
may be used, but the MTC triggering/reaching signal/message may be
on a different subframe, for example, subframes other than #0, #4,
#5 and #9. In one example, subframe #3 and #8 may be allocated to
the MTC device trigger/reach, such that when MTC devices using
MTC-ID to compute for the subframe number, the new number of
subframes formula is modified to:
Ns=Max (1, nB/2T). Equation (2)
[0139] FIG. 7 shows an example subframe allocation used by MTC
Device trigger/reach paging. FIG. 7 includes the number of
subframes (Ns) 705, paging offset 710 (PO) when i_s=0, and PO 715
when i_s=1.
[0140] A new indication may be added to the paging message to
indicate the paging trigger is for an MTC device triggering. FIG. 8
shows an example paging message indicating that a paging trigger is
for MTC device triggering. An MTC WTRU in RRC_IDLE or RRC_CONNECTED
mode may read the mtc-Triggerindication 801 to know if this paging
message was initiated for MTC device triggering. The WTRUs that are
monitoring the MTC triggers may perform further actions on
receiving this indication which may include reading additional or
new system information fields to get further information associated
with the device trigger, and may initiate the trigger response
according to the device trigger received.
[0141] FIG. 9 shows an example RRC paging/MTC device trigger
message having the new message format. If an RRC paging/MTC device
trigger message 901 is dedicated to MTC device triggering/reaching,
one or more of the following may be specified. The L1/2 signaling
for the MTC device paging may use the same paging radio network
temporary identity (P-RNTI) or a new MTC-P-RNTI, but in a different
physical downlink control channel (PDCCH) search space for the MTC
devices or in an extended PDCCH (E-PDCCH) search space for the MTC
devices. The new search space for the MTC trigger/reach signal, for
example, MTC-P-RNTI, whether it is in a PDCCH or an E-PDCCH and the
associated paging/trigger message data may be confined to the
center portion of the carrier or channel frequency range to suit
the narrow bandwidth MTC devices/WTRUs. The RRC paging/MTC device
trigger message 901 may take a new message format so that the
paging/trigger message may also serve as a downlink MTC device
signal to wake the MTC device/WTRU 905 up and to directly command
the MTC device/WTRU 905 for certain actions desired by the MTC
service operator or application.
[0142] The cell broadcast service (CBS) mechanism in LTE may be
equated to the warning message broadcast in the form of the E-UTRAN
system information broadcast mechanisms. The cell-broadcast method
may be applied to both non-attached (offline) and attached (online)
devices. For MTC device triggering, one or more of the following
new actions may be employed.
[0143] A new system information block (SIB) or SIB set may be
devised for the MTC device triggering purpose. A separate system
information (SI) message may be used for this CBS for MTC device
triggering. In addition to an MTC triggering primary notification,
the new MTC device trigger system information may alternatively
include secondary notification data including MTC operator specific
group identifier, MTC operator specific individual identifier, and
secure information from the MTC server. The SI may be broadcast in
the cell, and the device trigger content may change at each
transmit occasion, not preserving the MP boundary rule. Therefore,
there would be no need to indicate the content change in the paging
messages. WTRUs may not wait for the modification period (MP)
boundary to read it. The WTRUs may read it anytime they need to,
for example, according to their own power saving schedule or the
MTC-trigger-SIB scheduling or both.
[0144] If the CBS MTC device trigger message is dedicated to MTC
device trigger/reach, one or more of the following may be
specified. In order to save system resources and create no impact
to the legacy WTRUs, an alternative method to schedule the MTC
device trigger/reaching SI, independently of the regular SI
scheduling, may be to use a different MTC-SI-RNTI for downlink
control information (DCI). For narrow bandwidth MTC devices, the
SI-RNTI or the MTC-SI-RNTI may be transmitted in PDCCH or E-PDCCH
in a search space that is in the center portion of the carrier or
channel frequency range.
[0145] The SI occasion frame number may take the form of [SFN mod
MTC-periodicity=MTC-offset], where both MTC-periodicity and
MTC-offset may be predetermined or network configured. For the
subframe number to begin the MTC device trigger transmission, it
may be from any subframe number excluding #0 and #5 since the WTRU
may need to acquire the MIB and SIB-1 at the time. The SI
transmission window length may be 1 to w, where w may be
predetermined or configured by the network. If the transmission
window size is one subframe, the SI may be transmitted with one or
more HARQ RV at the same time or the SI may be transmitted with no
hybrid automatic repeat request (HARQ) redundancy expected.
[0146] The MTC device trigger/reaching SIB may contain one or more
of the following information: one or more MTC-Group-ID, which may
contain the MTC-IDs within the group; the trigger category or
purpose or command or type of the MTC trigger for each MTC-ID; the
trigger response type; an indication on whether an access delay may
be applied and the parameter to calculate the access spread.
[0147] A new RRC message for MTC device trigger may be transmitted
in the MBSFN subframes. The MTC message may be changed anytime.
[0148] A new RRC message may be designed to carry the MTC device
trigger information to MTC devices. The scheduling of the new
message may be one of the following. The new message may be
transmitted in the same occasion as the existing MBSFN RRC
messages. The new message may be transmitted last if it collided in
transmission with the existing RRC MBMS messages. The MTC
device/WTRU may need to decode this message accordingly, skipping
the contents of the old MBMS messages.
[0149] The new RRC MTC message over an MBMS control channel (MCCH)
may be scheduled more frequently in specific MBSFN subframes such
as the first available MBSFM subframe in an LTE frame with [SFN mod
(mcch-RepetitionPeriod/n)=mtc-mcch-Offset], where n is a number of
[2, 4, 8, 16] and the mtc-mcch-Offset is a [1,2,3, . . . ,
mcch-RepetitionPeriod/n]. The new MTC device ID or the
MTC-Device-Group-ID may be employed as the MBMS-service-ID, for
example, the temporary mobile group identity (TMGI).
[0150] MTC devices/WTRUs may use the assigned MTC device or device
group identity, MTC service or service group identity, or MTC
application or application group identity, and the like as the
MBMS-service-identity, (i.e., TMGI), and the MBMS session identity
to look for MTC device trigger information in MBMS multicast data
stream. MTC Devices/WTRUs may receive the existing MBSFN area
configuration message to determine the presence/absence of a
specific MBMS service IDs that mapped to the above mentioned MTC
Device-ID or other MTC service/application related identities.
[0151] MTC devices/WTRUs may decode the MBSFN area configuration
message and use the mapped MBMS service-Id (i.e., TMGI) to receive
the specific MTC Device Trigger transmission information in an MBMS
transmission, for example, the logical channel identity of a
particular MBMS point-to-multipoint traffic channel (MTCH). MTC
devices/WTRUs may receive the MSI (i.e., medium access control
element (MAC CE)) to determine the MBSFN subframe(s) that contains
the MTC device trigger information from the MTCH logical channel
identity. The MBMS-Service-ID may be placed either in the beginning
or the end of the MBMS traffic channel (MTCH) transmission. For
example, the MBMS trigger information may be placed as the first
MTCH in the first MBSFN subframe or the last.
[0152] The MBMS service-ID of the MTC device/WTRU may be a certain
MTC identity, such as a device ID, service-ID or application-ID,
assigned in the universal subscriber identity module (USIM) or be
constructed by the MTC device with some parameter in the USIM and
some data from the system information.
[0153] If the WTRU is already connected, the MTC device trigger may
be transmitted via a new MAC CE. The new device trigger MAC CE may
contain the MTC application ID and other application specific
content. The new CE may be transmitted to the WTRU independently or
together with other downlink data packets. The eNB may decide
whether a device trigger MAC CE may be transmitted, depending on
the device trigger indication received on S1 signaling from the
MME. Upon receiving this MTC device trigger MAC CE, the WTRU MAC
layer may directly submit the content of the CE to the intended MTC
application.
[0154] If the MTC device/WTRU receives the MTC device trigger in a
connected state, the device/WTRU may respond by establishing a
specific U-plane connection even if the request does not
specifically ask for it but the device/WTRU has certain amount of
application data to transmit. For example, the specific U-plane
connection may be a packet data network (PDN) connection/packet
data protocol (PDP) context to a specific APN specified in the
trigger message or by the need of the application data
transfer.
[0155] Alternatively, the device/WTRU may respond with the existing
C-plane connection if there is no specific data or small data to be
transferred to the network.
[0156] Alternatively, the device may be provided with at least one
method of response, such as in a specific order. For example, the
device may perform a set of procedures in the given, or any other,
order: {control plane (CP)-SMS, CP-other, UP-PDN, UP-other,
UP-local IP access (LIPA), UP-selected IP traffic offload at local
network (SIPTO@LN)}. Thus, the device may attempt to respond
according to the list provided and its capabilities as well. For
example, the device may try a particular method or eliminate
certain methods if the device does not support these schemes.
Alternatively, the device may use the CP even if the response type
is set to UP, given the UP may not be set up, for example, due to
APN congestion or any other problem that might prohibit the setup
of the required/request/desired response type. The device may
attempt another method of response, even if not requested/specified
in the trigger, when the specified method fails or cannot be met
due to any problem, for example, congestion, device settings, radio
conditions, and capabilities.
[0157] In addition, the device may respond according to any time
limitation it may receive in the trigger. The possible time
limitations may be as defined above. Moreover, if the response type
indicates a response via a specific PDN/APN that may be a LGW, the
device may attempt to establish a PDN connection to the specific
PDN/APN, for example, a LIPA or SIPTO@LN connection may be
established by the device.
[0158] If the MTC device/WTRU does not have an RRC connection/MM
connection with the network then, depending on the MTC triggering
type the device/WTRU has received, the WTRU may respond to the
trigger message at various time occasions as follows.
[0159] If the trigger message the WTRU received is deemed
"non-definitive time constraint" for response, the WTRU may
transmit the response when the WTRU gets connected to the network
again for some other non-MTC related uplink transmission occasions,
for example, the next TAU or attach or detach.
[0160] If the trigger message comes with a response time duration,
either network worked configured time or predefined time, the WTRU
may transmit the response with the non-MTC uplink transmission
before the time duration is over, or start a RRC connection when
the response time duration is about to expire and transmit the
trigger response message. For example a predetermined time frame
may be that a water company wants the water meter to report the
water usage within a given time frame or predefined time frame.
[0161] If the trigger message requires the WTRU to respond
immediately, the WTRU may start to transmit the trigger response as
requested.
[0162] If the triggering is a group type triggering, if there is a
spread time included in the message, the WTRU may draw a random
number within the time frame given by the network and transmit back
the response message. If there is no timer given in the triggering
message, the WTRU may transmit back the trigger response message
immediately, or the WTRU may impose a delay to transmit back the
triggering response to avoid overloading the network and/or the
RAN.
[0163] Depending on type of triggering message the WTRU receives,
the response message may be transmitted in one or more of the
following ways. The MTC device may transmit back the trigger
response message via SMS. The MTC device may establish a PDP
context or a PDN connection and communicate to the MTC server via
the U-plane. The MTC trigger response message may be an MM level
NAS message. If the network expects an ACK or a short response from
the MTC device, the MTC device may transmit a triggering response
with one of more of the following.
[0164] The trigger response may be a simple ACK to acknowledge that
the MTC device has received the trigger message, a combined ACK
indicating that the MTC device has received the trigger and the
requested action has been performed successfully, or an action-NACK
indicating that the trigger message has been received by the MTC
device but the requested action is rejected or failed.
[0165] The trigger response may be encapsulated or included in an
existing RRC message. In case the access stratum (AS) level
authentication has not been completed, the eNodeB may alternatively
delay forwarding the trigger response message until the
authentication procedure has been completed. The trigger response
may be included in the RRC connection request message, or the
trigger response may be attached to the RRC connection complete
message.
[0166] If the RRC message is used to carry the trigger response, to
limit the resources used for MTC triggering and response procedure,
some enhancement to the authentication procedure may be made for
MTC. The network may enclose a standard or MTC specific
authentication request message or IEs in the trigger request
message. The authentication method may either be standard
authentication key agreement (AKA) or modified MTC-specific
authentication method. After the MTC device authenticates the
network, the MTC device may enclose an authentication response IE
in the trigger response message. When the network has authenticated
the MTC device, the network may forward the triggering response
message to the MTC-IWF and thereafter the MTC server.
[0167] The trigger response message may be encapsulated, attached,
or included in an NAS message, including but not limited to the
following; attach request message, TAU, service request or/extended
service request, uplink NAS transport, and the like.
[0168] In order to save WTRU battery life and reduce Uu interface
load, if a device trigger (DT) is not real time or emergency, the
WTRU/MTC application may delay the response. For example, a water
meter company may trigger a water meter application to upgrade its
software. The trigger may be transmitted to a group of MTC devices.
If the requirement is that all MTC applications have to upgrade to
a new version of software within a day, then it is not necessary
for all of the MTC applications to start upgrading their software
immediately after being triggered. In some cases, the triggering
response may be delayed.
[0169] In the DT trigger message, the network/SCS may specify a
delay response time that it expects of the MTC application. After
the WTRU receives the triggering message, the WTRU may delay to
dispatch the trigger to the MTC application until either the delay
response time expires or the WTRU goes back to connected mode by
another procedure, for example, TAU or MO call. Alternatively to
reduce Uu traffic, if the trigger the WTRU received is a group
trigger, the WTRU may randomly choose a response time within the
delay response time. Alternatively, the WTRU may dispatch the
trigger to the MTC application immediately, but when the MTC
application responds, the WTRU delays the response message until
either the delay response time expires or the WTRU returns to a
connected mode by another procedure, for example, TAU or MO
call.
[0170] FIG. 10 shows an example of a delay response procedure. FIG.
10 includes an MTC application 1005, an MTC device/WTRU 1010, a
RAN+MME 1015, an MTC-IWF 1020 and an SCS 1025. A device trigger
1030 is transmitted from SCS 1025 to MTC-IWF 1020. The device
trigger 1035 is forwarded to the RAN+MME 1015. When the RAN+MME
1015 triggers the MTC application 1005, it may use paging, a cell
broadcast, a NAS message, or SMS as a triggering message 1040
transmitted to the MTC device/WTRU 1010. In the triggering message
1040, the network may specify the MTC device ID or MTC group ID to
specify which WTRU, or a group of WTRUs, may receive this trigger.
The triggering message may include a maximum delayed response time
value, which indicates the latest time that the SCS 1025 expects to
receive a response from the MTC application 1005. The triggering
message 1040 may include an MTC application ID or an MTC
application group ID to identify at least one MTC application 1005
that has been triggered. The purpose of the triggering, for
example, a software upgrade, may be a value that is transparent to
the MTC device/WTRU 1010.
[0171] When the MTC device/WTRU 1010 receives a triggering message
1040 including a device trigger (DT), the MTC device/WTRU 1010 may
store 1045 the DT and start a timer. The timer may be set to a
maximum delayed response time value or a value based on the maximum
delayed response time value, for example, a maximum delayed
response time value-n DRX cycle. Alternatively, the timer may be
set to a random number selected from a value between 0 and the
maximum delayed response time value. When the WTRU transitions to
an RRC connected mode 1050, for example, after the timer expires,
the WTRU may dispatch 1055 the DT to the MTC application 1005. The
MTC application 1005 may establish 1060 an IP connection with the
MTC server 1025 if a response is requested.
[0172] FIG. 11 shows that the MTC device/WTRU may delay the
response message transmitted by an MTC application. FIG. 11
includes an MTC application 1105, an MTC device/WTRU 1110, a
RAN+MME 1115, an MTC-IWF 1120 and an SCS 1125. A device trigger
1130 is transmitted from SCS 1125 to MTC-IWF 1120. The device
trigger 1135 is forwarded to the RAN+MME 1115. When the MTC
device/WTRU 1110 receives the triggering message 1140, it may
dispatch 1145 it to the MTC application 1105. The MTC application
1105 may choose to transmit a trigger response message 1150, in
which the MTC application 1105 may specify the maximum delay that
the trigger response message may tolerate. The MTC device/WTRU 1110
may store 1155 the trigger response message if it is in idle mode.
The MTC device/WTRU 1110 may start a timer based on the maximum
delay value, for example, a maximum delay-n DRX cycle. When the
timer expires, the MTC device/WTRU 1110 may trigger the
establishment of an RRC connection 1160, establish an IP connection
1165 between the MTC application 1105 and the SCS 1125, and forward
the triggering response message to the SCS 1125. Alternatively,
when the MTC device/WTRU 1110 transitions to the RRC connected
mode, for example, after the timer expires, the MTC device/WTRU
1110 may then establish the IP connection between the MTC
application 1105 and the SCS 1125, and forward the triggering
response message to the SCS 1125.
[0173] The MTC device trigger response may be an NAS message at the
MM level. The response message may be transmitted as an independent
NAS message in response to the trigger if the device/WTRU is in a
connected state. The MTC device trigger response may also be a
first MM level message after the RRC connection has been
established, for example, to transmit the service request, such as
an extended service request, and the trigger response message
together in the RRC connection setup complete message as the
"DedicatedInfoNAS" component, if the device is in "online" state
but no RRC connection. If the device/WTRU is in the "offline"
state, the response message, as the first NAS message, may serve
for both the attach and the trigger response.
[0174] For the dual purpose message, for example, the extended
service request+trigger response or the attach+trigger response,
the necessary elements of the service-request or the attach-request
may need to be put together with the MTC device trigger response
elements to serve the dual purpose.
[0175] FIG. 12 shows an example of the message format of dual
purpose MTC device service or attach+trigger response message. FIG.
12 includes IEI 1205, an information element 1210, a type/reference
of the information element 1215, presence of the information
element 1220, format of the information element 1225, and length of
the information element 1230. The information elements contained in
the dual purpose MTC device service or attach+trigger response
message may be protocol discriminator 1210(a), MTC service message
identity 1210(b), MTC response type 1210(c), MTC trigger response
ID 1210(d), MTC response details 1210(e), MTC cause 1210(f), and
authentication response parameter 1210(g).
[0176] To avoid excessive authentication/security overhead,
authentication response parameters may be added in the trigger
response message, when the message is transmitted as the first NAS
message after RRC connection establishments. To help the network to
distinguish whether user plane EPS bearers may need to be
established or not upon receiving the MTC trigger response included
in the first NAS message extended-service request, an indicator of
flag may be added to the combined message, such as an EPS bearer
type. The indicator or flag may indicate whether the user plane EPS
bearers, in addition to the C-plane bearer, may need to be
established or not for this trigger response. The network may be
able to derive from one or the MTC response parameters, for example
the MTC trigger response type, the MTC trigger response ID or the
MTC cause.
[0177] FIG. 13 shows an example extended-service request message
content. FIG. 13 includes JET 1305, an information element 1310, a
type/reference of the information element 1315, presence of the
information element 1320, format of the information element 1325,
and length of the information element 1330. The information
elements contained in the extended-service request message may be
protocol discriminator 1310(a), security header type 1310(b),
extended service request message ID 1310(c), service type 1310(d),
NAS key set ID 1310(e), M-TMSI 1310(f), CSFB response 1310(g), EPS
bearer context status 1310(h), device properties 1310 (i), device
properties 1310(j), EPS bearer type 1310(k), MTC response type,
1310(l), MTC trigger response ID 1310(m), MTC response details
1310(n), MTC cause 1310(o), and authentication response parameter
1310(p).
[0178] The information elements for the MTC device trigger response
may include one or more of the following: the MTC trigger response
type 1310(l), which may include a simple ACK, a combined ACK, and a
NACK, and the like, the MTC trigger response ID 1310(m) assigned in
the MTC trigger request for associate the response to the request,
MTC response details 1310(n) from the MTC application, MTC-cause
1310(o) for the MTC-response-type value NACK.
[0179] FIG. 14 shows an example bit map that defines a cause value.
The bit value 000001 1405 may represent that the Requested
Application does not exist. The bit value 000010 1410 may represent
that the Requested Application does not respond. The bit value
000100 1415 may represent low battery. The bit value 001000 1420
may represent not enough memory. The bit value 010000 1425 may
represent other.
[0180] If the WTRU has several MTC applications, the following
situations may exist and need to be handled: the WTRU is Idle and
no MTC application is active. When a WTRU is connected and at least
one MTC device is active, a non-active MTC application may be
triggered. When the WTRU has multiple MTC applications and it is in
a connected mode with any non-MTC application running, or one of
the MTC applications is active, then the active application path
may be used to trigger the MTC device. The SCS may
include/encapsulate the MTC device trigger message in the
application data, for example, through the user-plane triggering
path and method. When the active MTC application or an MTC handling
entity receives that trigger message it may perform the device
trigger procedure and transmit the appropriate reply. This trigger
message may include some of the information elements described
above.
[0181] A WTRU/user may need to register with the network and with
operators to receive services that require registration. This
registration is described as network attachment. The WTRU registers
its presence to the network in the registration area of the chosen
cell if necessary by means of a location registration (LR), LTE
attach, GPRS attach, IMSI attach procedure or combined attach
procedures. For example, in the case of LTE, in the state
EMM-deregistered, no EMM context has been established and the WTRU
location is unknown to an MME and therefore it is unreachable by an
MME. In order to establish an EMM context, the WTRU may start the
attach or combined attach procedure.
[0182] An offline MTC device is a device/WTRU that is unattached to
the network, for example, the device is not registered with the
network. It may also have been registered with the network but then
may be de-registered with the network, for example, with some timer
and monitoring function remaining, in order to save power.
[0183] FIG. 15 shows the primary EMM states in an MTC device/WTRU.
The MTC device/WTRU may be in any one of 7 states: EMM-Registered
1505, EMM-Deregistered 1510, EMM-Null 1515,
EMM-Deregistered-Initiated 1520,
EMM-Tracking-Area-Updating-Initiated 1525,
EMM-Service-Request-Initiated 1530, and EMM-Registered-Initiated
1535.
[0184] For example, as shown in FIG. 15, an offline MTC device/WTRU
may be in an EMM-deregistered state 1510 or in an EMM-null state
1515. When the MTC device/WTRU transitions from a EMM-registered
state 1505 to the EMM-deregistered state 1510, the MTC device/WTRU
may communicate to the network with information to help the network
reach the MTC device/WTRU or trigger the MTC device/WTRU to
transition it from an offline state to an online state and/or to
perform certain commanded actions by MTC device server/application.
For example, an online state may be when the WTRU is again attached
to the network at trigger response.
[0185] In another embodiment, when the device is transitioning from
a state where the device is not registered 1510 to the network to a
state where the device is registered 1505 to the network, the MTC
device may communicate to the network information to help the
network reach the device or trigger the device to transition from
an offline state to an online state after the device returns to an
offline state or status. For example, an online state may be when
the WTRU is registered to the network.
[0186] In another embodiment, another terminal device or network
element may provide the offline triggering support parameters to
the network. For example, in a local network, the LGW or the H(e)NB
or any other MTC device aggregator node may store locally these
parameters and provide them to the rest of the network either upon
request or autonomously based on configurable triggers. For
example, a network element, such as a home network element, may
store locally these parameters and provide them to another network,
such as a visited network or another equivalent PLMN or another
shared network, upon request or autonomously based on configurable
triggers.
[0187] A certain portion of MTC devices may have an attribute that
they may be attached/registered to the network and perform data
transfer for a short period of time and go back to
un-attached/de-registered state (i.e., the offline MTC device) via
"de-registration" or other procedures for a longer period of time
for power-saving and other purpose while remaining alert to receive
network MTC device trigger/reach signals. MTC devices with the
above offline attribute may notify the network with the attribute
and the information enabling the network to trigger/reach them. The
network may know and be able to handle the "offline" devices in
terms of device triggering/reaching. The MTC devices/WTRUs may
transmit the information using one or more NAS messages or a
combination of RRC message together with a RAN interface message,
for example, a combination of RRC message+S1-AP or radio access
network application part (RANAP) message. The information provided
to the network may include one or more of the following.
[0188] The MTC device/WTRU may provide its "offline" attribute to
the network via NAS messages such as an ATTACH message or the NAS
area update message or a detach message. For example, the NAS area
update message may be a tracking area update (TAU). The MTC
device/WTRU may provide the device roaming area information to the
network in the NAS procedures (or messages) at EMM (or MM) level
such as the detach procedure, the attach procedure, or the
TAU/LAU/RAU procedures. For example the detach procedures may be a
detach request message, the attach procedures may be an attach
request message, and the TAU/LAU/RAU procedures may be a tracking
area update request message.
[0189] The information, for example, parameters, provided by the
MTC device to the network may be a list of tracking areas, location
areas, routing areas, or a list of cells identified, for example,
by their global identifier. Such list may be a subset from a super
list provided by the network to the WTRU during a prior information
exchange between the MTC device and the network. Such list may be
based on prior areas visited by the MTC device or registered by the
MTC device. The roaming area information may also be one single
area or a fixed location attribute, such as no roam/mobility.
[0190] The MTC devices may provide their device trigger/reaching
monitoring occasion information to the network. For MTC, the
network may define or provide a specific set of monitoring
schedules, timer values, or DRX/sleep cycle lengths and the device
may indicate which one or more of the schedules it follows when it
goes offline. The device may choose to transmit its monitoring
schedule explicitly in the message before it goes offline. If there
is more than one MTC monitoring mechanism, such as paging vs. CBS
vs. multicast, the MTC device may also need to indicate which one
or more than one is supported/used.
[0191] The validity of the information provided by the WTRU to the
network for the purpose of offline triggering may be controlled by
a timer. The timer value may be "infinity until waived by the
device or by administration." Upon expiry of such a timer, the
network may purge all such information from its database and
consider the offline MTC device not reachable. Alternatively, the
MTC device may be configured to connect to the network and refresh
the network with its reachability information before or upon expiry
of the timer.
[0192] The MME or SGSN or any equivalent CN node with NAS protocol
capability may receive and process the messages containing the
above MTC device offline and trigger/reaching information. The
function that makes the determination of whether or not a device is
"offline (and reachable)" may be located in the MME (or SGSN or
GGSN/S-GW/PGW), in the HSS (or HLR), in the MTC-IWF, in the SCS, or
in the MTC application inside or outside the 3GPP network.
[0193] The device reachability information may be propagated from
the MME to the network node where the function of offline status
determination is located, such as in the MTC-IWF. For example, the
device reachability information may be parameters of location,
triggering mechanism, and scheduling. Alternatively, the MTC-IWF,
upon receiving a request from the MTC server, may query the HSS
(HLR) in a scheme where the HSS is responsible for keeping track of
the device status together with the information on how to reach the
device when offline. The MTC-IWF may subsequently ask the MME to
trigger the device.
[0194] Alternatively, the SCS may contact the SMS-SC, which in turn
queries the HSS for the device status. Alternatively, once a
determination is made that a device is offline, such status may be
conveyed to the MTC-IWF or SCS of the MTC application.
Alternatively, the device may be offline but not reachable, for
example, the reachability information provided by the MTC device to
the network has expired. When the device is offline and previously
reachable becomes unreachable, such information may be propagated
back to the SCS of the MTC-IWF.
[0195] Various procedures may be implemented to identify WTRUs of a
certain priority, or identify applications for WTRUs that have
different priorities. This may be applicable when a WTRU has an
emergency bearer service or is requesting an emergency bearer
service. The terminology "priority WTRU" may refer to any
combination of the following: a high priority user/WTRU, a WTRU
that belongs to a specific access class, for example, 11-15, or a
WTRU having at least one priority application. Moreover, the
terminology "priority application" may refer to an application that
is known to carry priority content, a PDN connection that is
associated with a known APN that provides high priority
content/packet/application, an application, PDN connection, or a
dedicated bearer (PDP context) that has, or requests, a known
quality of service (QoS).
[0196] A WTRU profile may contain information indicating whether a
particular WTRU is a priority WTRU or runs a priority application.
The WTRU may be provided with information about being a priority
WTRU via open mobile alliance (OMA) device management (DM) or other
NAS messages. The WTRU may also have such information
preconfigured. The WTRU may always include such information in all
NAS messages, including mobility and session management messages,
or RRC messages. The WTRU may also always indicate if the access
made from idle mode is performed with access class 11-15 or any
other access class. Additionally, an eNB may indicate to the MME,
in all S1AP messages, the set of classes that the eNB is allowing
for access.
[0197] The network may include this information in all NAS messages
or RRC messages. When the RRC in the WTRU receives such an
indication, the RRC may inform the NAS about it or may pass the
information to the NAS.
[0198] BO timers may be provided on a per application basis. An
application ID may be introduced in NAS messages in order to
identify the referenced application. A WTRU that receives a BO
timer for an application may not transmit any NAS messages due to
requests from the application to which a BO was assigned. The WTRU
may stop such a timer if the network initiates session management
requests for bearers/PDN connections used by this application. An
application may be associated with a PDN connection mapping or a
bearer mapping. The mappings may be performed via an identification
that points out such an association. This identification may be
part of all NAS messages. For example, all NAS messages may include
an application ID and an association ID that maps the application
to a specific bearer. Alternatively, the application ID may be used
as the association parameter that maps the application to a
particular bearer. BO timers may also be provided on a per bearer
basis.
[0199] The CN nodes may exchange this indication. Further more this
indication may be on a per application basis. Also, the CN nodes
may exchange information about whether the WTRU in question is
allowed to be a priority WTRU or have priority applications.
[0200] When a WTRU receives an indication that it is a priority
WTRU or when it already has such information, for example, due to
configuration, the WTRU may transmit mobility and session
management messages that are not related to emergency calls, even
if the WTRU has an emergency call. The WTRU may transmit a NAS
message to update the network with the new priority level. The WTRU
may be allowed to transmit mobility and/or session management
messages that are due to requests from applications that are high
priority only. The WTRU may further include indications that a
particular request is for a high priority application. The WTRU may
also transmit requests due to low priority applications and may
indicate that the request is due to a low priority application. The
WTRU may request the modification of certain bearers such that they
are treated as bearers pertaining to a high priority
WTRU/application or non-high priority, depending on the current
WTRU/application priority. For example, if the current priority for
a WTRU/application is high, then the WTRU may indicate as such in
its request for modifying the bearers. If the priority for the WTRU
is low, then the WTRU may request modifications indicating a
non-high priority WTRU.
[0201] The above may be provided via RRC messages to the eNB/RNC.
In this case, the eNB/RNC may forward such indication/information
to the core network nodes via new/existing messages with
new/existing information elements (IEs).
[0202] The following are network (eNB/RNC/MME/SGSN or MSC/VLR)
actions when the network receives an indication about the WTRU's
priority or priority of applications. This may be received in the
form of NAS messages or S1AP/RANAP messages (or any similar
messages).
[0203] The network may use this indication/information to accept
requests regardless if they are not for emergency calls. For
example, if the MME receives a request,(NAS mobility or session
management message),with an indication that the WTRU/application is
a low priority, then the MME may provide a BO timer to the WTRU.
The BO timer may be per APN or per application. As another example,
if the MME receives a request from a WTRU that indicates high
priority, the MME may accept the request and process it.
[0204] The network may modify the bearers for the WTRU. For
example, the MME may indicate to the S-GW to modify the bearers of
the WTRU, for example, using the bearer modification request. The
S-GW may also in turn request the PDN GW to modify the bearers for
the WTRU. The modification may be such that the
QoS/treatment/priority of the connection is improved or degraded,
depending on the indication received. For example, if the MME
receives an indication about the WTRU being a high priority WTRU,
for example, an indication downloaded from an HSS or received from
the WTRU, then the MME may indicate to the S-GW that the WTRU's
bearers may be treated as those pertaining to a priority WTRU. This
may be achieved via a new or existing IE in the messages exchanged
between the MME and the S-GW.
[0205] The same methodology may also apply for the S-GW indication
towards the PDN GW. A reverse indication may also apply, for
example, the PDN GW may provide the S-GW/MME with an indication
about a change in the WTRU's priority, or application priority.
This may be performed by transmitting a message towards the S-GW,
which in turn may transmit a message with such an indication
towards the MME. The MME may then take the actions defined above.
Alternatively, the MME may use this indication to modify the
bearers for the WTRU and may therefore transmit NAS messages to the
WTRU to indicate the change of priority of the WTRU. The MME may
also inform the eNB that the WTRU priority has changed, for
example, using SlAP messages similar to a WTRU context modification
request. The eNB may, upon receipt of an indication of a change in
WTRU priority, execute an RRC reconfiguration procedure to
implement the change in WTRU priority.
[0206] The network, (i.e., MME/SGSN/GGSN/PDN GW, or MSC/VLR), may
decide to provide a BO timer to the WTRU, for example, if the
indication is from a low priority WTRU or from a WTRU that does not
indicate high priority. Furthermore, the network may decide to stop
any existing BO timers that are running for a WTRU/application that
indicates high priority.
[0207] The above procedures may be applicable to both LTE and
GERAN/UTRAN, and to both PS and CS domains/core networks, and may
be used in any combination.
[0208] Although features and elements are described above in
particular combinations, one of ordinary skill in the art will
appreciate that each feature or element may be used alone or in
combination with any of the other features and elements. In
addition, the embodiments 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, a cache memory, a
semiconductor memory device, a magnetic media, (e.g., an internal
hard disc or a removable disc), a magneto-optical media, and an
optical media such as a compact disc (CD) or a digital versatile
disc (DVD). A processor in association with software may be used to
implement a radio frequency transceiver for use in a WTRU, UE,
terminal, base station, Node-B, eNB, HNB, HeNB, AP, RNC, wireless
router or any host computer.
* * * * *