US20130301501A1 - Methods and apparatus for handling mtc long drx cycle/sleep lengths - Google Patents
Methods and apparatus for handling mtc long drx cycle/sleep lengths Download PDFInfo
- Publication number
- US20130301501A1 US20130301501A1 US13/829,642 US201313829642A US2013301501A1 US 20130301501 A1 US20130301501 A1 US 20130301501A1 US 201313829642 A US201313829642 A US 201313829642A US 2013301501 A1 US2013301501 A1 US 2013301501A1
- Authority
- US
- United States
- Prior art keywords
- wtru
- cycle
- sfn
- processor
- long
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H04W76/048—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
- H04W76/28—Discontinuous transmission [DTX]; Discontinuous reception [DRX]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
- H04W52/02—Power saving arrangements
- H04W52/0209—Power saving arrangements in terminal devices
- H04W52/0212—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
- H04W52/0216—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave using a pre-established activity schedule, e.g. traffic indication frame
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Definitions
- Machine type communication (MTC) devices may not need to frequently connect to a network to deliver or receive data. Additionally, a network may schedule a radio resource for a MTC device on a small number of occasions. Accordingly, MTC devices may not need to monitor a network for a signal or page as often as non-MTC devices.
- current wireless networks do not allow for long discontinuous reception (DRX) cycles or sleep lengths.
- the embodiments may allow systems and MTC devices, such as a wireless transmit/receive unit (WTRU), to operate with long DRX cycles, sleep cycles, and/or periods.
- WTRU wireless transmit/receive unit
- the embodiments may provide and/or enable MTC operations to permit infrequent system access or system reaching.
- the embodiments may allow MTC devices to sleep for a long period with low power consumption.
- the embodiments may also allow wireless networks to use an eNodeB (eNB) to perform energy saving algorithms.
- eNB eNodeB
- a WTRU may be provided that may include a processor configured to perform a number of actions.
- the processor may be configured to determine a cycle base unit type and a length of a discontinuous reception (DRX) cycle.
- a number of base units of the cycle base unit type may be generated using the length of the long DRX cycle.
- the long DRX cycle may be generated from the number of base units.
- a WTRU for determining when to receive a signal may be provided.
- the WTRU may include a processor that may be configured to perform a number of actions.
- the processor may be configured to determine a system frame number cycle number (SCN) within a total DRX period.
- SCN system frame number cycle number
- a long DRX cycle length may be determined.
- An offset SCN may be generated using the SCN and the long DRX cycle length.
- the WTRU may include a processor that may be configured to perform a number of actions.
- the processor may be configured to determine a long sleep length, a clock drift rate for a WTRU, and a wake-up time.
- An adjustment window may be generated using the long sleep length, the clock drift rate, and the wake up time.
- a WTRU may be provided that may include a processor configured to perform a number of actions.
- the processor may be configured to receive a first system frame number (SFN) cycle order number from a network.
- SFN system frame number
- a second SFN cycle order number may be determined
- a drift range may be calculated using the first SFN cycle order number and the second SFN cycle order number.
- FIG. 1A depicts a system diagram of an example communications system in which one or more disclosed embodiments may be implemented.
- FIG. 1B depicts a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A .
- WTRU wireless transmit/receive unit
- FIG. 1C depicts a system diagram of an example radio access network and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A .
- CN core network
- FIG. 1D depicts a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A .
- FIG. 1E depicts a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A .
- FIG. 2 depicts an example of a short discontinuous reception cycle (DRX) cycle scheduled within a long DRX cycle.
- DRX discontinuous reception cycle
- FIG. 3 depicts an example of a short cycle being used in between long DRX cycles.
- FIG. 4 depicts an example method for DRX configuration that may be initiated by a service capability server (SCS).
- SCS service capability server
- FIG. 5 depicts an example method for a DRX cycle configuration that may be initiated by a radio access network (RAN).
- RAN radio access network
- FIG. 6 depicts another example method for a DRX cycle configuration that may be initiated by a RAN.
- FIG. 7 depicts example network and WTRU procedures for busy reaching and monitoring.
- FIG. 8 depicts example SFN cycle order numbers 0 and 1.
- FIG. 9 depicts example local SFN cycle order numbers 0, 1, 2, and 3.
- FIG. 10 depicts an example WTRU clock realignment.
- FIG. 11 depicts another example WTRU clock realignment.
- Some mobile networks may be optimized for human-to-human communications and may be less optimal for machine-to-machine (M2M) communications.
- M2M machine-to-machine
- Support for machine-type communications (MTC) may be used to accommodate the demand for machine type communications in wireless networks, such as 3GPP LTE wireless networks.
- Machine Type Communication (MTC) devices may include wireless transmit/receive units, such as cell phones, metering devices, or the like that may access the network less frequently than devices used for human-to-human use.
- the MTC devices may be wireless sensors or the like that may be deployed to remote areas for monitoring tasks or other tasks, where there may be limited access to power.
- MTC devices may not request to be continually connected for deliver or receive data. For example, a network may allocate radio resources for an MTC device on a reduce number of occasions, which may follow a pattern. MTC devices may not be requested listen to network signaling or network paging for long periods. MTC devices may monitor network signaling or paging less often than non-MTC devices.
- a network may have knowledge of the location of a MTC device or may have knowledge of a geographic location where an MTC device may be found.
- MTC devices may perform less mobility related tasks (e.g. TAU) or cell measurements, or may not perform mobility related tasks during a sleep/dormant period.
- TAU mobility related tasks
- cell measurements or may not perform mobility related tasks during a sleep/dormant period.
- MTC devices deployed in a remote area or in an inconvenient area may operate on battery power and may wish to save power.
- MTC battery life may be expected to last for an extended amount of time, such as ten years.
- a device may shut down for a long period of time, which may be scheduled, and may not listen to a network during this scheduled period of time.
- the MTC device may continue timing and timer maintenance procedures during this period. After this period is over, the device may wake up and may listen to signals, such as MTC downlink paging signals, triggering signals, reaching signals, or the like. This may be done, for example, to determine if the network wishes to communicate with the device.
- a device may wake up. For example, a device may wake up and may attempt a system access to deliver user data content. As another example, a device may wake up to read system information where the network may try to deliver user data content.
- a device may wake up and may attempt to access a system to delivery data. This may occur, for example, when a power meter wakes up a month at a time to report a power meter reading. As another example, a device may wake up to read system information in case the network may try to deliver data. This may occur, for example, when a device wakes up once a week to determine if the network has an administrative request or task for it, such as an instruction to cut off electric supply for a tenant who may be moving out of an apartment.
- a prolonged sleeping period may be referred to as a long DRX cycle or an extended DRX cycle.
- a long DRX cycle may be a cycle length of a month, a week, a day, or the like. Provisioning of a long or DRX cycle may place a MTC device into an offline shutdown state where the device may not measure the serving cell frequently to ensure coverage for a long period. This may provide opportunities for base stations to perform energy saving tasks, such as planned power downs.
- An uncoordinated scheme may rely on a device pulling mechanism where the device may check at regular intervals whether there may be data waiting instead of having the network push data upon arrival based on paging slots.
- a DRX-like mechanism may be provided for devices that may sleep longer than the current LTE System Frame Number (SFN) cycle may allow. This may provide a device-network synchronization mechanism that may allow a manageable distribution of devices waking up to access the system. This may also enable the network to deliver user data to devices that may have slept for long periods of time without relying on data pulling mechanisms.
- SFN System Frame Number
- a Long-DRX length unit and/or a Total-DRX-Definition-Period may be a time, a SFN cycle, a combination thereof, or the like, and may be used to allow a device to sleep in days/weeks/months, etc.
- Scheduling formulas may be provided for configuring WTRUs for long-DRX in a Total-DRX-Definition-Period. Methods may be provided to arrange short DRX within a long-DRX period.
- An adjustment-window length may be provided and may be a function of the long DRX cycle length and the clock drift rate.
- Procedures may be provided to schedule an adjustment window for a network and/or a WTRU that may assure that the WTRU may not miss network paging/signaling when the WTRU wakes up with misaligned timing that may be caused by, for example, drift.
- Network assisted WTRU resynchronization and WTRU autonomous adjustment may be provided.
- Procedures for coordination of long DRX cycles between a RAN, a WTRU, and Service Capability Server (SCS) may be provided.
- a DRX mechanism may be used for devices that may use a cycle that may be longer than the current LTE System Frame Number cycle. This may allow a manageable distribution of devices to wake up and access a system. Additionally, this may ensure that the network may deliver data to devices that may have slept for long periods of time without relying on data pulling mechanisms.
- a default paging cycle length for a WTRU is, in general, configured to be between 32 to 256 LTE frames (i.e. a device sleeps for about 32 to 256 frames or 0.32 to 2.56 seconds, then wakes up) within a complete SFN cycle (1024 LTE frames).
- This time period definition may not be long enough to accommodate longer DRX requirements for MTC devices that may request long sleeping periods, such as days, hours, or the like. Thus, the devices may request longer periods than what is offered by the current LTE or UMTS complete SFN cycle.
- a MTC device such as a WTRU
- the WTRU may not be able to receive network paging messages that were previously scheduled.
- a WTRU may be in a power saving mode for a long sleep that may last days or weeks. During this period the WTRU may not have contact with the network.
- a clock used by the WTRU to count timing for a scheduled wake-up may drift. The longer the long-deep-sleep, the more the timing may drift when the device wakes-up. When the WTRU wakes up, the monitoring clock may have drifted. If local clock has drifted beyond a limit, the WTRU may not be able to synchronize and the WTRU may not be able to receive network signaling or paging around the scheduled time.
- the current LTE SFN cycle may not evenly distribute delay tolerant MTC device traffic and network access during low system load periods with a long DRX cycle. Additionally, the current LTE SNF cycle may not allow for different DRX or sleep time length units, such as a calendar time unit, that may be used to enable the configuration of MTC DRX or sleep period in order to wake up at the service desired time or moment.
- DRX or sleep time length units such as a calendar time unit
- Extended DRX cycles may allow for closer coordination between the RAN and the Service Capability Server (SCS) and/or MTC interworking function (IWF).
- SCS Service Capability Server
- IWF MTC interworking function
- Long DRX cycles may be used to limit when other entities may be able to contact the device as the device may be contacted when the device may be available.
- the SCS may contact the device over the user plane or via a trigger. Since SCS operation may be impacted by the DRX cycle of its registered devices, the SCS may be part of the DRX cycle negotiation or the SCS may be made aware of the DRX cycle of its registered devices.
- the SCS may attempt to contact the device over the SGi/Gi user plane or via T sp trigger requests while the device may be sleeping. These contact attempts may cause unwanted signaling between the core network (CN) and the SCS.
- Mechanisms may be provided to allow the RAN to inform the SCS of the MTC device's DRX cycle.
- the core network may reject any communication attempt towards a device that may be is in a long DRX cycle. Additional measures may be taken to ensure that the SCS and its associated network applications may not attempt to continuously reach sleeping devices.
- the core network may not know how long devices may be allowed to sleep without breaking application level functionality.
- the SCS may know this information or may be able to learn it when the MTC device registers with the SCS.
- Mechanisms may be provided to allow the SCS to inform the RAN of the DRX requests of an MTC device, such as how long the device may sleep without breaking the application requirements.
- the device may simply inform the RAN of its DRX requests. However, it may be more efficient if the SCS coordinated when it may poll the meters, how often they may be polled, and when they may be available for SW upgrades.
- Embodiments described herein may provide units and mechanisms for long-drx time scenarios that may allow and support the LTE time unit for time periods longer than a complete SFN cycle.
- Procedures and messages may be provided to allow the SCS to coordinate the allowable DRX cycle lengths with the RAN.
- Embodiments disclosed herein may provide methods to mitigate synchronization issues that may occur when the local WTRU clock drifts beyond a recovering period. These methods may include mechanisms that may allow the reception of paging messages within a time window, which may be affected by factors such as the long sleep time, WTRU speed, WTRU capabilities, or the like. For example, given a clock drift rate, the length of the adjustment-window may be a function of the long-deep-sleep length such that the longer the long-deep-sleep length, the greater the adjustment-widow length/size. Embodiments may allow for a relationship between an adjustment-window and a long-deep-sleep-length. The embodiments may also provide actions that may be taken by a WTRU, a network (such as eNB and MME), or both the WTRU and network before or during the adjustment-window period.
- a WTRU such as eNB and MME
- extended DRX cycle As used herein, the term extended DRX cycle, the term long DRX cycle, and the term long sleep cycle/period may be used interchangeably.
- adjustment-window and the term receive-window may also be used interchangeably.
- the embodiments may be described in terms of an LTE network, the embodiments may also apply to other radio access technologies, networks, devices, and periodic operations, such as network broadcast/multicast and WTRU receptions.
- the long DRX cycle and its operation configuration may be configured for WTRUs that may request a long sleep.
- a serving node and may refer to mobile switching center (MSC), a serving general packet radio service (GPRS) support node (SGSN), or mobility manager gateway (MME).
- MSC mobile switching center
- GPRS general packet radio service
- SGSN serving general packet radio service support node
- MME mobility manager gateway
- FIG. 1A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented.
- the communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users.
- the communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth.
- 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.
- CDMA code division multiple access
- TDMA time division multiple access
- FDMA frequency division multiple access
- OFDMA orthogonal FDMA
- SC-FDMA single-carrier FDMA
- the communications system 100 may include wireless transmit/receive units (WTRUs) 102 a , 102 b , 102 c , and/or 102 d (which generally or collectively may be referred to as WTRU 102 ), a radio access network (RAN) 103 / 104 / 105 , a core network 106 / 107 / 109 , 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.
- WTRUs wireless transmit/receive units
- RAN radio access network
- PSTN public switched telephone network
- Each of the WTRUs 102 a , 102 b , 102 c , 102 d may be any type of device configured to operate and/or communicate in a wireless environment.
- the WTRUs 102 a , 102 b , 102 c , 102 d 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.
- UE user equipment
- PDA personal digital assistant
- the communications systems 100 may also include a base station 114 a and a base station 114 b .
- Each of the base stations 114 a , 114 b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102 a , 102 b , 102 c , 102 d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109 , the Internet 110 , and/or the networks 112 .
- the base stations 114 a , 114 b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114 a , 114 b are each depicted as a single element, it will be appreciated that the base stations 114 a , 114 b may include any number of interconnected base stations and/or network elements.
- BTS base transceiver station
- AP access point
- the base station 114 a may be part of the RAN 103 / 104 / 105 , which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc.
- BSC base station controller
- RNC radio network controller
- the base station 114 a and/or the base station 114 b 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.
- the cell associated with the base station 114 a may be divided into three sectors.
- the base station 114 a may include three transceivers, i.e., one for each sector of the cell.
- the base station 114 a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
- MIMO multiple-input multiple output
- the base stations 114 a , 114 b may communicate with one or more of the WTRUs 102 a , 102 b , 102 c , 102 d over an air interface 115 / 116 / 117 , which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.).
- the air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).
- RAT radio access technology
- 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.
- the base station 114 a in the RAN 103 / 104 / 105 and the WTRUs 102 a , 102 b , 102 c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 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).
- the base station 114 a and the WTRUs 102 a , 102 b , 102 c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115 / 116 / 117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).
- E-UTRA Evolved UMTS Terrestrial Radio Access
- LTE Long Term Evolution
- LTE-A LTE-Advanced
- the base station 114 a and the WTRUs 102 a , 102 b , 102 c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
- IEEE 802.16 i.e., Worldwide Interoperability for Microwave Access (WiMAX)
- CDMA2000, CDMA2000 1X, CDMA2000 EV-DO Code Division Multiple Access 2000
- IS-95 Interim Standard 95
- IS-856 Interim Standard 856
- GSM Global System for Mobile communications
- GSM Global System for Mobile communications
- EDGE Enhanced Data rates for GSM Evolution
- GERAN GSM EDGERAN
- the base station 114 b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like.
- the base station 114 b and the WTRUs 102 c , 102 d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN).
- the base station 114 b and the WTRUs 102 c , 102 d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN).
- WPAN wireless personal area network
- the base station 114 b and the WTRUs 102 c , 102 d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell.
- a cellular-based RAT e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.
- the base station 114 b may have a direct connection to the Internet 110 .
- the base station 114 b may not be requested to access the Internet 110 via the core network 106 / 107 / 109 .
- the RAN 103 / 104 / 105 may be in communication with the core network 106 / 107 / 109 , 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 102 a , 102 b , 102 c , 102 d .
- the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.
- the RAN 103 / 104 / 105 and/or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 or a different RAT.
- the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) employing a GSM radio technology.
- the core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102 a , 102 b , 102 c , 102 d 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).
- POTS plain old telephone service
- the Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite.
- the networks 112 may include wired or wireless communications networks owned and/or operated by other service providers.
- the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 or a different RAT.
- the WTRUs 102 a , 102 b , 102 c , 102 d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102 a , 102 b , 102 c , 102 d may include multiple transceivers for communicating with different wireless networks over different wireless links.
- the WTRU 102 c shown in FIG. 1A may be configured to communicate with the base station 114 a , which may employ a cellular-based radio technology, and with the base station 114 b , which may employ an IEEE 802 radio technology.
- FIG. 1B is a system diagram of an example WTRU 102 .
- the WTRU 102 may include a processor 118 , a transceiver 120 , a transmit/receive element 122 , a speaker/microphone 124 , a keypad 126 , a display/touchpad 128 , non-removable memory 130 , removable memory 132 , a power source 134 , a global positioning system (GPS) chipset 136 , and other peripherals 138 .
- GPS global positioning system
- the base stations 114 a and 114 b , and/or the nodes that base stations 114 a and 114 b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. 1B and described herein.
- BTS transceiver station
- Node-B a Node-B
- AP access point
- eNodeB evolved home node-B
- HeNB home evolved node-B gateway
- proxy nodes among others, may include some or all of the elements depicted in FIG. 1B and described herein.
- the processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like.
- the processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment.
- the processor 118 may be coupled to the transceiver 120 , which may be coupled to the transmit/receive element 122 . While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
- the transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114 a ) over the air interface 115 / 116 / 117 .
- a base station e.g., the base station 114 a
- the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
- the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example.
- the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
- 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 115 / 116 / 117 .
- 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 .
- the WTRU 102 may have multi-mode capabilities.
- 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.
- 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 .
- 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.
- SIM subscriber identity module
- SD secure digital
- 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).
- 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 .
- the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
- 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 .
- location information e.g., longitude and latitude
- the WTRU 102 may receive location information over the air interface 115 / 116 / 117 from a base station (e.g., base stations 114 a , 114 b ) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
- 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.
- the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
- the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game
- FIG. 1C is a system diagram of the RAN 103 and the core network 106 according to an embodiment.
- the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102 a , 102 b , 102 c over the air interface 115 .
- the RAN 103 may also be in communication with the core network 106 .
- the RAN 103 may include Node-Bs 140 a , 140 b , 140 c , which may each include one or more transceivers for communicating with the WTRUs 102 a , 102 b , 102 c over the air interface 115 .
- the Node-Bs 140 a , 140 b , 140 c may each be associated with a particular cell (not shown) within the RAN 103 .
- the RAN 103 may also include RNCs 142 a , 142 b . It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.
- the Node-Bs 140 a , 140 b may be in communication with the RNC 142 a . Additionally, the Node-B 140 c may be in communication with the RNC 142 b .
- the Node-Bs 140 a , 140 b , 140 c may communicate with the respective RNCs 142 a , 142 b via an Iub interface.
- the RNCs 142 a , 142 b may be in communication with one another via an Iur interface.
- Each of the RNCs 142 a , 142 b may be configured to control the respective Node-Bs 140 a , 140 b , 140 c to which it is connected.
- each of the RNCs 142 a , 142 b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.
- the core network 106 shown in FIG. 1C may include a media gateway (MGW) 144 , a mobile switching center (MSC) 146 , a serving GPRS support node (SGSN) 148 , and/or a gateway GPRS support node (GGSN) 150 . 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.
- MGW media gateway
- MSC mobile switching center
- SGSN serving GPRS support node
- GGSN gateway GPRS support node
- the RNC 142 a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface.
- the MSC 146 may be connected to the MGW 144 .
- the MSC 146 and the MGW 144 may provide the WTRUs 102 a , 102 b , 102 c with access to circuit-switched networks, such as the PSTN 108 , to facilitate communications between the WTRUs 102 a , 102 b , 102 c and traditional land-line communications devices.
- the RNC 142 a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface.
- the SGSN 148 may be connected to the GGSN 150 .
- the SGSN 148 and the GGSN 150 may provide the WTRUs 102 a , 102 b , 102 c with access to packet-switched networks, such as the Internet 110 , to facilitate communications between and the WTRUs 102 a , 102 b , 102 c and IP-enabled devices.
- the core network 106 may also be connected to the networks 112 , which may include other wired or wireless networks that are owned and/or operated by other service providers.
- FIG. 1D is a system diagram of the RAN 104 and the core network 107 according to an embodiment.
- the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102 a , 102 b , 102 c over the air interface 116 .
- the RAN 104 may also be in communication with the core network 107 .
- the RAN 104 may include eNode-Bs 160 a , 160 b , 160 c , though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment.
- the eNode-Bs 160 a , 160 b , 160 c may each include one or more transceivers for communicating with the WTRUs 102 a , 102 b , 102 c over the air interface 116 .
- the eNode-Bs 160 a , 160 b , 160 c may implement MIMO technology.
- the eNode-B 160 a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102 a.
- Each of the eNode-Bs 160 a , 160 b , 160 c 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. 1D , the eNode-Bs 160 a , 160 b , 160 c may communicate with one another over an X2 interface.
- the core network 107 shown in FIG. 1D may include a mobility management gateway (MME) 162 , a serving gateway 164 , and a packet data network (PDN) gateway 166 . While each of the foregoing elements are depicted as part of the core network 107 , 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.
- MME mobility management gateway
- PDN packet data network
- the MME 162 may be connected to each of the eNode-Bs 160 a , 160 b , 160 c in the RAN 104 via an S1 interface and may serve as a control node.
- the MME 162 may be responsible for authenticating users of the WTRUs 102 a , 102 b , 102 c , bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102 a , 102 b , 102 c , and the like.
- the MME 162 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.
- the serving gateway 164 may be connected to each of the eNode-Bs 160 a , 160 b , 160 c in the RAN 104 via the S1 interface.
- the serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102 a , 102 b , 102 c .
- the serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102 a , 102 b , 102 c , managing and storing contexts of the WTRUs 102 a , 102 b , 102 c , and the like.
- the serving gateway 164 may also be connected to the PDN gateway 166 , which may provide the WTRUs 102 a , 102 b , 102 c with access to packet-switched networks, such as the Internet 110 , to facilitate communications between the WTRUs 102 a , 102 b , 102 c and IP-enabled devices.
- the PDN gateway 166 may provide the WTRUs 102 a , 102 b , 102 c with access to packet-switched networks, such as the Internet 110 , to facilitate communications between the WTRUs 102 a , 102 b , 102 c and IP-enabled devices.
- the core network 107 may facilitate communications with other networks.
- the core network 107 may provide the WTRUs 102 a , 102 b , 102 c with access to circuit-switched networks, such as the PSTN 108 , to facilitate communications between the WTRUs 102 a , 102 b , 102 c and traditional land-line communications devices.
- the core network 107 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 107 and the PSTN 108 .
- the core network 107 may provide the WTRUs 102 a , 102 b , 102 c with access to the networks 112 , which may include other wired or wireless networks that are owned and/or operated by other service providers.
- IMS IP multimedia subsystem
- FIG. 1E is a system diagram of the RAN 105 and the core network 109 according to an embodiment.
- the RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102 a , 102 b , 102 c over the air interface 117 .
- ASN access service network
- the communication links between the different functional entities of the WTRUs 102 a , 102 b , 102 c , the RAN 105 , and the core network 109 may be defined as reference points.
- the RAN 105 may include base stations 180 a , 180 b , 180 c , and an ASN gateway 182 , though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment.
- the base stations 180 a , 180 b , 180 c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102 a , 102 b , 102 c over the air interface 117 .
- the base stations 180 a , 180 b , 180 c may implement MIMO technology.
- the base station 180 a may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102 a .
- the base stations 180 a , 180 b , 180 c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like.
- the ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109 , and the like.
- the air interface 117 between the WTRUs 102 a , 102 b , 102 c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification.
- each of the WTRUs 102 a , 102 b , 102 c may establish a logical interface (not shown) with the core network 109 .
- the logical interface between the WTRUs 102 a , 102 b , 102 c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.
- the communication link between each of the base stations 180 a , 180 b , 180 c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations.
- the communication link between the base stations 180 a , 180 b , 180 c and the ASN gateway 182 may be defined as an R6 reference point.
- the R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102 a , 102 b , 102 c.
- the RAN 105 may be connected to the core network 109 .
- the communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example.
- the core network 109 may include a mobile IP home agent (MIP-HA) 184 , an authentication, authorization, accounting (AAA) server 186 , and a gateway 188 . While each of the foregoing elements are depicted as part of the core network 109 , 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.
- MIP-HA mobile IP home agent
- AAA authentication, authorization, accounting
- the MIP-HA may be responsible for IP address management, and may enable the WTRUs 102 a , 102 b , 102 c to roam between different ASNs and/or different core networks.
- the MIP-HA 184 may provide the WTRUs 102 a , 102 b , 102 c with access to packet-switched networks, such as the Internet 110 , to facilitate communications between the WTRUs 102 a , 102 b , 102 c and IP-enabled devices.
- the AAA server 186 may be responsible for user authentication and for supporting user services.
- the gateway 188 may facilitate interworking with other networks.
- the gateway 188 may provide the WTRUs 102 a , 102 b , 102 c with access to circuit-switched networks, such as the PSTN 108 , to facilitate communications between the WTRUs 102 a , 102 b , 102 c and traditional land-line communications devices.
- the gateway 188 may provide the WTRUs 102 a , 102 b , 102 c with access to the networks 112 , which may include other wired or wireless networks that are owned and/or operated by other service providers.
- the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks.
- the communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102 a , 102 b , 102 c between the RAN 105 and the other ASNs.
- the communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.
- Embodiments may provide Long DRX cycle length definition and configuration of the long DRX cycle for MTC devices. Some MTC devices require low power consumption. Thus, frequent monitoring, paging, and/or listening to system information may unnecessarily waste the battery power of these MTC devices. Extended DRX cycle or the long DRX cycle length units may be used for these types of MTC devices to enable these devices to sleep/DRX under scheduling or configuration.
- a long DRX cycle may be provided. To accommodate the long DRX cycle operation, one or more cycle length base units may be described herein. A long DRX cycle may be one or more of the base units.
- a long DRX cycle length unit may be based on an SFN cycle.
- one or more of the SFN cycle(s) may be used as the base unit. This may be referred to as an extended SFN cycle(s).
- a long DRX cycle length, which may be the extended SFN cycle, may be of n SFN cycle(s), where the n value may be:
- n value or the values used for deriving n may be predefined or network configured.
- the long DRX cycle, the extended DRX cycle, or the long-deep-sleep period may consist of one or more of the extended SFN cycles described herein.
- a long DRX cycle, an extended DRX cycle, or a long deep sleep period unit may be based on time units or calendar time units, such as a second, a minute, an hour, a day, a week, a month, a combination of those units, or the like.
- a long DRX cycle may be two-days, two-weeks, or one-month-plus-two-days, etc.
- the network may assign the MTC devices with service specific extended DRX cycle length.
- a system may use broadcast or MTC specific messages to convey the MTC extended DRX cycle and parameters to MTC devices.
- a combination of the two units described above may be used, i.e. the time unit(s)+the extended SFN cycles.
- a long DRX cycle length unit (definition-C) may be 2-week+5*extended SFN cycles or may be one-week+7*SFN cycles. This may be used to provide a long DRX cycle that may have a length of in days and a low activity period of the day.
- a mechanism may be provided to distribute the MTC device evenly among the low activity period in the extended/long DRX cycle.
- the system may configure the MTC device to stay in a normal DRX cycle for some time after one or more long DRX cycles.
- the long DRX cycle may be a three-tuple, such as:
- extended DRX cycle number of Day+low Activity Period+OnTimePeriod
- the “number of Days” may be the days of the extended DRX cycle
- the “low Activity Period” may be the period of low activity during the day (e.g. 4 am)
- the “OnTimePeriod” may be the length of time the WTRU may monitor the paging over a shorter or regular DRX.
- a Total-DRX-Definition-Period may be provided.
- the Total-DRX-Definition-Period may be a multiple of a long DRX cycle.
- the Total-DRX-Definition-Period may be a combination of some multiples of the DRX base units described herein.
- a Total-DRX-Definition-Period may be based on an extended SFN cycle, a time unit, a calendar time unit, or combination of an extended SNF cycle and a time unit, or any combination thereof, or the like.
- a Total-DRX-Definition period may be as a combination of one or more of the descriptions provided in the following paragraphs.
- a Total-DRX-Definition-Period may be a multiple of an extended SFN cycle base unit as described herein.
- the Total-DRX-Definition-Period may be a multiple of an extended SFN cycle, such as 32 extended SFN cycles.
- a Total-DRX-Definition-Period may be a combination of an extended SFN cycle and a base unit, such as 36 extended SFN cycle plus 12-SFN cycles. If the Total-DRX-Definition-Period may be m extended SFN cycles, each with (n) SFN cycles, the Total-DRX-Definition-Period may have (m*n) SFN cycles. This may be numbered as [0, 1, . . .
- the Total-DRX-Definition-Period may be a combination of multiples of some of the base units described herein, then the Total-DRX-Definition-Period may have a combination of (j) extended SFN cycles and (k) SFN cycles and it may have (j*n)+k SFN cycles. This may be numbered as [0, 1, . . . , j*n, j*n+1, j*n+2, . . . j*n+k ⁇ 1].
- the MTC device such as a WTRU, and the network supporting the long-DRX operation may count the SFN Cycle Number (SCN) from 0 to the end of the Total-DRX-Definition-Period (i.e. the m*n ⁇ 1 or the j*n+k ⁇ 1 SFN cycles) and may wrap-around to the next period from the 0 SFN cycle again.
- SCN SFN Cycle Number
- a Total-DRX-Definition-Period may be a base unit, such as 6-months, or a combination of multiples time units, such as 9-months plus 12-weeks.
- the conversion of the Total-DRX-Definition-Period to the number of extended DRX cycle or the number of SNF cycles may be rounded up to the nearest Extended DRX cycle or to the nearest SNF cycle.
- a Total-DRX-Definition-Period may be some combination of the base units described herein, such as a combination of an extended SNF cycle and a time unit.
- the Total-DRX-Definition-period may be 24 weeks plus 42 extended SFN cycles.
- the conversion of the Total-DRX-Definition-Period to the number of extended DRX cycle or the number of SNF cycles may be rounded up to the nearest extended DRX cycle or to the nearest SNF cycle.
- a Total-DRX-Definition-Period may also be a combination of any of the embodiments described herein.
- MTC device configurations may be provided for utilizing the long DRX cycle.
- the Total-DRX-Definition-Period and the Long-DRX-base-units (which may include the extended SFN cycle, a base unit, or combinations thereof) may provide MTC devices for long dormant periods of sleep that may preserve power.
- the Total-DRX-Definition-Period and/or the long DRX base unit may be configured for a MTC device to allow the device to operate in a discontinuous reception mode, idle mode, an offline mode, or the like. This may allow the MTC device, such as a WTRU, to identify its paging time after the long sleep or long DRX.
- a formula may be used for scheduling a page/signal/reach for a MTC device that may have been in a long sleep.
- one or more SFN cycle(s) may be identified in a Total-DRX-Definition-period such that the network may page the device in that cycle and the device may perform monitoring and reception.
- the SNF cycle may also be identified such that the MTC device may find its paging frame(s) and the paging subframe occasion(s) either with the an idle mode paging reception formula or with some other formula or rules.
- a WTRU may obtain the monitoring/reception N th SFN cycle while configured for long DRX or long deep sleep using the following:
- a shorter DRX cycle may be scheduled inside a long DRX cycle.
- Temporary network congestion or RAN resource jamming may cause a MTC device, such as a WTRU, to miss a network paging or signal after a long-sleep.
- a short DRX cycle within a long DRX cycle may be configured.
- the short DRX cycle may be configured in a second long DRX cycle that may occur after a first long DRX cycle.
- long DRX cycle 202 may be configured such that it may not include one or more short cycles.
- Long DRX cycle 204 may occur after long DRX cycle 202 .
- One or more short DRX cycles may be configured within long DRX cycle 204 , such as short DRX cycles 206 .
- a short DRX cycle, such as short DRX cycles 206 may be used, for example, to provide occasions for a network to re-transmit and/or for a WTRU to re-receive a signal.
- Network paging/signaling repetitions may run with the one or more short DRX cycles from short DRX cycles 206 .
- Network paging/signaling may be scheduled from the long DRX cycle boundary.
- a network may configure a WTRU with a long DRX cycle, which may be followed a number, M, DRX cycles. After a MTC device, such as a WTRU, wakes up from a long DRX, it may use a short DRX cycle for a period of time.
- MTC device such as a WTRU
- Short DRX cycles may be placed before, around, or after a long DRX cycle boundary; before, around, or after a scheduled paging SFN cycle; or before, around, or after the network paging/signaling frames. These schedules may be configured by the WTRU or the network. Network paging/signaling may be scheduled at those boundary, cycle, or frames.
- short cycles may be used in between long DRX cycles.
- a network may configure a WTRU with an extended/long DRX cycle followed with m number of DRX cycles.
- extended DRX cycle 300 may be scheduled.
- Short DRX cycles 302 may be scheduled after extended DRX cycle 300 .
- Extended DRX cycle 304 may be scheduled after short DRX cycles 302 .
- the MTC device may be configured with an extended DRX cycle that may follow the extended DRX cycle in idle mode.
- a network may configure a MTC device with an extended DRX cycle using a RRC message, or a NAS message.
- a WTRU may trigger a tracking area update (TAU) procedure and may send a TAU message to the network.
- TAU tracking area update
- the WTRU may indicate its ongoing MTC applications.
- the network may configure the MTC device with an extended DRX cycle or may modify the configured extended DRX cycle.
- MTC device When MTC device is configure with extended DRX cycle, MTC device may calculate its wake up time. For example, the MTC may use the following formula:
- LongDRXCycleUnit may be a number that given by the system or calculated from UeID.
- an uneven sleep period assignment may be provided.
- the uneven sleep period or periods may be assigned by the network to the WTRU such that the WTRU may sleep for a different period from time to time according to the assigned long sleep length. For example, a WTRU may sleep for 5 hours, wake up, and then may sleep for 5 months.
- the uneven sleep period may be assigned by a message or may be assigned by rules.
- the uneven sleep period(s) may be assigned one a time or several uneven periods may be assigned at once.
- DRX cycle configuration may be provided.
- DRX configurations determination may be provided by an operator.
- Information may be obtained from the SCS before calculating the DRX cycle.
- a MTC-IWF and a SCS may be informed of the DRX configuration.
- a SCS may initiate a DRX cycle configuration.
- FIG. 4 depicts a method for DRX configuration that may be initiated by a SCS.
- the allowable length of a long DRX cycle may depend on an application and may be dynamic.
- the network may assume that the device may be using existing DRX methods.
- the SCS may indicate the application requested sleep parameters to the core network and RAN (eNB or RNC).
- the RAN eNB or RNC
- the RAN may then calculate the long DRX cycle parameters that may be used by the device.
- MTC WTRU 402 may register with a core network, which may include RNC/eNodeB 404 , MSC/SGSN/MME 406 , and HSS 408 .
- Subscription information for MTC WTRU 402 in HSS 408 may include an indication that MTC WTRU 402 may support Long DRX. A long DRX cycles may not have been configured.
- one or more MTC Applications on MTC WTRU 402 may register with the service layer using application/service layer procedures, which may involve RNC/eNodeB 404 , MSC/SGSN/MME 406 , HSS 408 , MTC-IWF 410 , and SCS 412 .
- SCS 412 may register the application(s) DRX parameters with the core network. This information may be passed to MTC-IWF 410 via, for example, a Tsp reference point. This may occur, for example, using a message on the Tsp reference point. This message may be provided as shown in Table 1:
- the device external ID (e.g. MSISDN, FQDN, Identifier etc)
- This field may be populated with a group identifier so that the SCS may request DRX parameters for a group of devices.
- SCS Identifier M The SCS ID (e.g. MSISDN, FQDN, etc)
- Application O The application ID (e.g. Port Number, SCS Identifier assigned name, etc.)
- This field may be populated with a group identifier so that the SCS may request DRX parameters for a group of applications.
- Max Off Time The maximum amount of time that the appli- cation may be allowed to sleep.
- the units of this field may be seconds or some period of time.
- Min On Time O The minimum amount of time that the device may stay on when coming out of sleep.
- the units of this field may be seconds or some period of time.
- the units of this field may be seconds or some period of time.
- the units of this field may be seconds or some period of time.
- MTC-IWF 410 may use an S6m reference point to resolve the device and SCS identifiers to subscription identifiers.
- the MTC-IWF may also identify the serving node of the device. This may include a check of the HSS subscription parameters to verify that MTC WTRU 402 supports long DRX cycles.
- MTC-IWF 410 may pass updated DRX information to the serving node using, for example, a T5 reference point. This may be done, for example, using a message, such as the message shown below in Table 2:
- the device internal ID (e.g. IMSI) Identifier
- This field may be populated with a group identifier so that the SCS may request DRX parameters for a group of devices.
- MTC-IWF M IP Address, SS7 address, ISDN, etc.
- Identifier Application O The application ID (e.g. Port Number, SCS Identifier assigned name, etc.) The serving node or RAN may use this ID to keep track of the multiple applications that may be on a device and how their DRX parameter re- quests may overlap.
- This field may be populated with a group identifier so that the SCS may request DRX parameters for a group of devices.
- Max Off Time O The maximum amount of time that the appli- cation may be allowed to sleep.
- the units of this field may be seconds or some period of time.
- Min On Time O The minimum amount of time that the device may stay on when coming out of sleep.
- the units of this field be seconds or some period of time.
- the units of this field may be seconds or some period of time.
- the units of this field be seconds or some period of time.
- the serving CN node may use an Iu or S 1-MME reference point to pass the updated DRX information to the RAN. This may be done using, for example, a NAS message that may be sent to the RAN, which may include the information shown in Table 2 (the MTC-IWF address may not be requested).
- DRX parameters may be calculated and the device may be configured with the DRX parameters.
- the CN serving node may inform/configure the MTC device directly with a NAS message, such as described above, on the long DRX or long sleep activity.
- the RAN may pass the DRX parameters to the serving node via the Iu or S 1-MME reference points.
- This message may include the information that may be shown in Table 2.
- the MTC-IWF address may not be included.
- the RAN may configure the device with parameters that may be different than what was requested. Different parameters may be selected due to network congestion or the RAN may select different parameters in order to accommodate other applications on the same device may have different DRX parameter requests (i.e. another application may request to be on at different times).
- the serving note may pass DRX parameters received at 432 to MTC-IWF 410 . This may be done, for example, using a T5 reference point. MTC-IWF 410 may store updated DRX parameters so that it may manage trigger requests. At 436 , MTC-IWF 410 , may send the DRX parameters to SCS 412 using, for example, a Tsp reference point. The DRX parameters may be different than what may have been requested at 420 .
- FIG. 5 depicts a method for DRX cycle configuration that may be initiated by a RAN.
- the WTRU or RAN may reconfigure a DRX cycle for the WTRU.
- the WTRU and RAN eNB and RNC
- the SCS may be informed.
- MTC WTRU 504 and a RAN may negotiate a DRX cycle. This may be initiated by the WTRU or the RAN (eNB or RNC).
- the information exchanged may be the same as what is shown in Table 1.
- An MTC-IWF address may or may not be used.
- the RAN may inform the serving node, MSC/SGSN/MME 506 , of the DRX cycle parameters.
- the serving node may be a MSC, SGSN, or a MME. This may be done, for example, by sending a message using the Iu and S1-MME reference points.
- the fields of the message may be the same as what is shown in Table 2.
- An MTC-IWF address may or may not be included.
- MSC/SGSN/MME 506 may send a get MTC-IWF address message to HSS 508 . This may be done, for example, to allow the serving node to query HSS 508 with the international mobile subscriber identify (IMSI) for a device for the MTC-IWF, such as MTW-IWF 510 , that may be used to reach the SCS, such as SCS 512 , that the device may be registered to.
- IMSI international mobile subscriber identify
- the message may be sent on an S6m reference point.
- MSC/SGSN/MME 506 may inform MTC-IWF 510 of the DRX cycle parameters. This may be done, for example, sending a message using the T5 reference point.
- the fields of this message may be the same as what may be shown in Table 2.
- MTC-IWF 510 may inform SCS 512 of the DRX cycle parameters. This may be done, for example, by sending a message using on the Tsp reference point. The fields of this message may be the same as what may be shown in Table 1.
- DRX cycle configuration may be initiated by a WTRU or a RAN.
- the SCS may be informed of a DRX cycle for a device.
- FIG. 6 depicts another method for DRX cycle configuration that may be initiated by RAN.
- MTC WTRU 602 and a RAN may negotiate a DRX cycle. This may be initiated by the WTRU or RAN (eNB or RNC).
- the information exchanged may be similar to what may be shown in Table 1.
- the MTC-IWF address may or may not be used.
- the service layer of MTC WTRU 602 may inform SCS 612 of a DRX update over a user plane connection.
- This communication may happen between service layers (i.e. European Telecommunications Standards Institute (ETSI)).
- ETSI European Telecommunications Standards Institute
- This message may include the fields that may be shown in Table 1.
- the MTC-IWF address may or may not be used.
- MSC/SGSN/MME 606 and MTC-IWF 610 may not be informed of the of the DRX cycle.
- SCS 612 may be trusted not to continuously attempt to contact the device when it may be sleeping.
- Device trigger requests may be provided. For example, device triggering procedures may occur over a Tsp reference point. The procedures on this interface may be updated to account for the where a SCS may attempt to trigger a device that may be in a long DRX cycle.
- the MTC-IWF may choose to reject or buffer the trigger request. For example, the device may not be scheduled to be awake for several hours and MTC-IWF policies may determine how long the MTC-IWF may buffer triggers.
- the MTC-IWF may send the SCS a Device Trigger Confirm message with a value that may indicate that the request may be rejected because the device may be in a long DRX cycle.
- the Device Trigger Confirm message may indicate a time when the trigger may be attempted again.
- the MTC-IWF may send the SCS a Device Trigger Confirm message with a value the may indicate that the request may be buffered because the device may be in a long DRX cycle.
- the Device Trigger Confirm message may indicate an estimate as to when the trigger may be delivered.
- the SCS may know the DRX cycle of the MTC applications that may be registered to it. The SCS may avoid making triggering requests to an application that may not be reachable.
- DRX classes may be provided. To reduce the amount of signaling inside of the CN, between the CN and SCS, or between the WTRU and RAN, a set of DRX classes may be defined. The Max On and Max Off times of Table 1 may then be determined by a predefined class number. An example may be shown in Table 3. The predefined classes may be used to determine the duty cycle of the DRX cycle, and may not be used to determine when the duty cycle starts.
- An adjustment-window may be defined from the length of the scheduled long-sleep period.
- the WTRU and/or network may perform procedures for the adjustment.
- a receiving window or an adjustment-window may be defined at the WTRU side and may be used interchangeably.
- a WTRU may monitor the paging channel as it may do in an IDLE state.
- the receiving window may start as a WTRU may wake up from the long sleep and the window may end when the WTRU may have received the paging or may end after a period of time (such as a receiving window length).
- the receiving window length may be predefined, indicated by the network, or calculated from the long sleep period.
- WTRU may perform synchronizing with the network, reading MIB and SIBs.
- the WTRU may start monitoring the paging channel with a DRX cycle, which may be a paging cycle.
- the paging occasions may be related to SFN. Since the WTRU and the network may be synchronized with SFN, the WTRU may not miss the paging.
- the receiving window length for the WTRU may be long enough to cover the drifted time and the receiving window for the WTRU may start earlier than the network starts the transmitting window.
- An adjustment window may be defined from the length of the scheduled long sleep period.
- a MTC WTRU When a MTC WTRU goes dormant, it may not perform any activities that may involve contact with the network to save power. For example, the MTC WTRU may not perform measurement of the cell or perform any mobility area update. The WTRU may not have a chance to learn the network timing and adjust its own clock and the WTRU clock may drift from the network clock. This may occur at a certain rate and may depend on the make of the clock. The longer the MTC WTRU may sleep, the more it may drift from the network timing on which the activity of communication synchronization may be based.
- the long sleep MTC WTRU When the long sleep MTC WTRU wakes up for a scheduled activity with the network, it may fail because of missed timing or synchronization. This may occur, for example, with schedule activities such as monitoring or receiving network paging or work signals. This may also occur when accessing the network.
- An adjustment window period may be provided to avoid missed timing or synchronization due to clocking drifting during a long sleep period.
- the MTC WTRU and/or the network may take action to resynchronize or to remediate the negative impact of the missed timing.
- the adjustment window may be defined as a function of the long sleep period and the clock drift rate, known or estimated:
- Adjustment window length Long-Sleep-Length*ClockDriftRate+RoundUpTime
- RoundUpTime maybe predefined, configured or a value related to the Long-Sleep-Length or the ClockDriftRate
- the adjustment window may also be defined using the following formula:
- Adjustment window length (Long-Sleep-Length*ClockDriftRate)*N
- N could be [1, 1.2, 1.4, 1.6, . . . , 2].
- the adjustment window length unit may be a unit such as the LTE SFN cycle, an LTE frame, or the like.
- the length of the receiving window (i.e. the adjustment window) length may also be a value of time (e.g. 512 ms), a number of default paging cycles (e.g. 2 ⁇ Paging Cycles), a number of radio frames (e.g. 20 ⁇ Radio Frames), or the like.
- the receiving window length or the ClockDriftRate may be broadcasted in the system information.
- a network may start paging before the calculated receive window starts in a WTRU and may use a longer window length to cover the drifted time to make the paging more reliable.
- a WTRU may determine a window length to be used for the WTRU.
- the WTRU may notify the network of its receiving window length or the clock drift rate in the initial Attach or TAU message.
- the network paging message may also carry the receiving window length or clock drift rate information.
- FIG. 7 depicts network and WTRU procedures for busy reaching and/or monitoring.
- the network such as network 702 , and a long sleep WRTU, such as WTRU 708 , may avoid an issued caused by clock drift when the WTRU has computed the adjustment window length (i.e. the drift estimates).
- network 702 may employ a Busy Reaching Window around scheduled wake up time 704 , which may be a boundary of a Long DRX cycle such as Long-DRX cycle 715 .
- the network may send paging or other reaching signal to a WTRU that may be waking up from a long sleep.
- the length of Busy Reaching Window 706 may be based on the estimated longest adjustment window length. For example, three quarters, one, one and one half or twice the length of an estimated longest adjustment window length may be used for the length of Busy Reaching Window 706 ; however, any length may be used.
- Network 702 may place Busy Reaching Window 706 centered on scheduled wake-up time 704 (in FIG. 7 centered O).
- Busy Reaching Window 706 length may be predetermined or configured and may be broadcast to the WTRUs via system information.
- Busy Reaching Window 706 may be selected to be as short as may be possible to reduce overhead and inefficiency. Additionally, Busy Reaching Window 706 may not be employed if the WTRU clock does not drift.
- WTRU 708 may know its clock drift direction. That is, WTRU 708 may know whether its clock may drift towards shorter time ( ⁇ drift) or towards longer time (+drift).
- the adjustment window or the drift window may be used to compensate the long DRX cycle counting (i.e. add the drift length if the “ ⁇ drift” and subtract the drift length if the “+drift”), so WTRU 708 may know or learn approximately when scheduled wake-up time 704 may be.
- WTRU 708 may then configure WTRY Busy Monitoring Window 716 around or centered the estimated the scheduled wake-up time, which may overlap the network busy reaching window for activity.
- WTRU Busy Monitoring Window 716 may be any length. For example, WTRU Busy Monitoring Window 716 may be one or one and one half or twice of the computed adjustment-window length.
- WTRU 708 may not know the clock drift direction.
- WTRU 708 may set the length of a WTRU Busy Monitor Window, such as WTRU Busy Monitor Window 718 and WTRU Busy Monitor Window 720 , to at least twice the computed adjustment window length.
- WTRU 708 may start the Busy Monitoring Window, such as at 722 and 724 , one adjustment-window earlier than the scheduled wake up time, such as at 726 and 728 , so that approximately half of the Busy Monitoring Window or one adjustment-window time may overlap with the network Busy Reach Window for activity.
- WTRU Busy Monitor Window 718 and/or WTRU Busy Monitoring Window 720 may overlap with Network Busy Reaching Window 706 .
- network 702 may send paging or other signaling at the configured normal paging frames (PF) and paging subframe occasions (PO) in any of the SFN cycles within the period, which may be in addition to the PFs and POs in the scheduled SFN cycle.
- PF normal paging frames
- PO paging subframe occasions
- WTRU 708 may perform the monitoring and reception of the scheduled network paging or signaling in any SFN cycle during the period in the PFs and POs configured by network 702 in terms of “paging” and signaling.
- network 702 may store information regarding WTRU 708 its associated adjustment-window length in an MME when the long sleep DRX or sleep is configured. For example, when a WTRU may be configured for long sleep, the network may save a copy of WTRU information and the adjustment-window-length in the MME node. This WTRU information may be used by the network to provide the busy window to the WTRU.
- the WTRU may flag this long sleep nature of the operation and the possible clock drift rate related indication to the network when the WTRU registers with the network.
- Network assisted SFN cycle adjustment methods may be provided.
- the network may provide information that may assist a WTRU that may have woken-up to self-adjust to the scheduled SFN cycle for the network paging or signaling.
- the network may publish a SFN cycle order number within the Total-DRX-Definition-Period in the system information. This may be done, for example, so that when the long sleep WTRU wakes up, it may use the network published SFN cycle order number to align its own SFN cycle to the network SFN cycle number. The WTRU may then perform the monitoring of the PFs and POs in the right SFN cycle for the network paging or signaling.
- the network may provide the current count-number/order-number of the SFN cycle (e.g. the 15 th or the 234 th SFN cycle within the Total-DRX-Definition-Period) to the public or to the MTC devices.
- the long sleep WTRU wakes up, it may use the SFN cycle count-number/order-number from the system information to adjust its number/order of the SFN cycle with the systems.
- This count-number/order-number quantity in the system may take a log 2 (SCN inTotalDRXDefinitionPeriod ) bit quantity in the SIB space, e.g. 18 bit for a wrap-around period in 31 days.
- the system may publish it eight to sixteen times per SFN cycle evenly distributed.
- FIG. 8 depicts local SFN cycle order number 0 and 1.
- FIG. 8 shows a drift range 0 case at 802 that with a 0 on the SFN cycle 0 at 804 , a 1 on SFN cycle 1 at 808 , and a 1 on SFN cycle ⁇ 1 at 806 . If the WTRU wakes up and sees the network indicating a local-SFN cycle order value of 1, it may know it may be in the previous cycle, such as the SFN cycle ⁇ 1 at 806 . This may not be cycle 1 at 808 , because cycle 1 at 808 may be beyond the basic clock drifting range assumption of no greater than ⁇ 1 SFN cycle.
- FIG. 9 depicts local SFN cycle order number 0, 1, 2, and 3.
- a WTRU may see the local-SFN cycle order value 2 or 3 at 906 or 904 at wake-up and may know that the clock may be on the left (earlier) of the intended reference wake-up time over the time axis.
- a WTRU that may see a local SFN cycle order value 0 or 1 at 908 or 910 may know it is on the right (right or late) of the wake-up reference time.
- Using a localized-SFN cycle-number indication may cost less signaling overhead than the order number uses (e.g. 18 bits).
- a system may provide time information.
- the network system or the eNB may provide the time+n-SFN cycle based long DRX cycle adjustment information to a MTC WTRU.
- the eNB may provide SIB-8 or an equivalent for the time information.
- the eNB may provide the Nth SFN cycle order number in the intervals of a day or a half day or a time interval, such as a hour, minute, or the like via SIB or a message.
- a NAS may provide a universal time and a local time zone to a MTC device when the MTC device may access the network, such as a periodic TAU.
- a network may reuse EPS mobility management (EMM) information message or may include the universal time information element (IE) in the TAU accept message or other NAS message.
- EMM EPS mobility management
- IE universal time information element
- a WTRU may perform autonomous synchronization of SFN and/or SFN cycle.
- a SFN Sync Timer may also be pre-configured in a WTRU. The timer may be a configured fixed value or the timer value may be adjusted with respect to the cycle end based on previous measurement. When the timer expires, the WTRU may wake up, read and align the SFN, and may align the SFN cycle with the network.
- the SFN sync timer may be reset and restarted again at the SFN cycle boundary after WTRU goes back to sleep.
- the MTC WTRU may resynchronize with the network by itself.
- Self-recovery schemes described herein may be used if the estimated drift, or the computed adjustment window show that the clock drift may be within half (512 SFNs) of the SFN cycle.
- FIG. 10 depicts WTRU clock realignment.
- a WTRU may be scheduled during long DRX cycle 1006 to wake up in the middle of a SFN cycle, such as at SFN cycle ⁇ 1 at 1002 , which may be between frame number (FN) 500 to FN 524 . This may be prior to SFN cycle 0 at 1004 where the network may be scheduled to send paging or signaling to the WTRU in the early half of the SFN cycle.
- the WTRU may align itself (its clocking) with the network on the LTE frame numbers via MIB and SIB acquisition.
- the WTRU may get ready to monitor/receive the network paging in the next SFN cycle (SFN cycle 0) on the PFs and POs scheduled and configured.
- FIG. 11 depicts another WTRU clock realignment.
- the network may be scheduled to send paging or signaling to the WTRU in the latter half of the SFN cycle at 1104 .
- the WTRU and the network may be in the same SFN cycle (SFN cycle 0), at 1108 .
- the WTRU may be able to adjust or confirm its SFN cycle and the LTE frame number, and may be ready to monitor/receive the network paging/signaling at the scheduled PF and PO.
- Network paging coordination may be performed with respect to the receiving window.
- the WTRU may follow camping procedures and may start monitoring the paging channel discontinuously.
- the paging cycle during the period of the receiving window may be the normal default paging cycle, or it may be the WTRU specific paging cycle.
- the paging occasion may be calculated.
- the network may delay the transmission of the paging message until the WTRU may be within the receiving window.
- the calculated start of the receiving window for the WTRU at the network side may not be exactly aligned with the start of the receiving window for the WTRU at the WTRU side due to the clock shift.
- the network may start transmission in advance to the start of window and may extend the length of the window to make the paging delivery more reliable.
- a network system may keep alive time.
- the system may depend on periodic TAU to know whether the concerned device may still be up to its designated or prescribed functions or technically alive.
- the longest periodic TAU timer may be longer than the longest long DRX cycle, for example, twice as long.
- the MTC WTRU configured with the long DRX cycle may use the wake up time to perform the periodic TAU if the long periodic TAU timer expires between two scheduled wake-up times with one long DRX cycle.
- MTC WTRUs that may usually be offline with the long DRX cycle may register or attach themselves with a flag that may indicate their long-dormant operational nature. The network system may then not rely on the periodic TAU to maintain their functional status. The monitoring of those MTC WTRUs may be the responsibility of the MTC-server or the relevant MTC-applications.
- a MTC WTRU may have multiple applications running and a MTC server may know the status of those applications.
- the network or the MTC server may configure the MTC WTRU to report the status of a configured application.
- the report may be done in several ways.
- the MTC WTRU may report application status directly to MTC server on a PDN connection.
- the MTC WTRU may report application status using SMS.
- MTC application status may be combined with alive time method and the MTC application status may be attached in the NAS message.
- a MME may forward the status report to MTC server.
- the MTC device may report application status by synchronizing its time with network when it access to the network.
- a WTRU may be provided.
- the WTRU may include a processor that may be configured to perform a number of actions.
- the processor may be configured to determine a cycle base unit type and a length of a long discontinuous reception (DRX) cycle.
- a number of base units of the cycle base unit type may be generated using the length of the long DRX cycle.
- the cycle base unit type may be an extended subframe number (SFN) cycle type, a time unit type, or the like.
- the processor may be configured to generate the number of base units of the cycle base unit type using the length of the long DRX cycle in a number of ways. For example, the processor may determine n number of SFN cycles to be used for an extended SFN cycle type base unit. A number of extended SFN cycles to make up the length of the long DRX cycle may be generated. Each extended SFN cycle in the number of extended SFN cycles may include n SFN cycles. As another example, the processor may determine a length of time for the time unit type. A number of time units to make up the length of the long DRX cycle may be determined. The number of time units may be generated. Each time unit in the number of time units may include the length of time for the time unit type.
- a long DRX cycle may be generated from the number of base units.
- the long DRX cycle may be generated from the number of base units by generating the long DRX cycle from the number of extended SFN cycles.
- a WTRU may be provided for determining when to receive a signal.
- the WTRU may include a processor that may be configured to perform a number of actions.
- the processor may be configured to determine a system frame number cycle number (SCN) within a total DRX period.
- SCN system frame number cycle number
- a long DRX cycle length may be determined.
- An offset SCN may be generated using the SCN and the long DRX cycle length.
- a page timing may be determined using the offset SCN.
- a paging signal may be received from a network using the page timing.
- a number of short DRX cycles may be determined to be used to receive the paging signal.
- a long DRX cycle may be scheduled using the offset SCN and the long DRX cycle length.
- the number of short DRX cycles may be scheduled within the long DRX cycle using the short DRX cycle length, before the long DRX cycle using the short DRX cycle length, after the long DRX cycle using the short DRX cycle length, or the like.
- a number of short cycles may be scheduled and may be used to receive the paging signal. For example, a first long DRX cycle and a second long DRX cycle may be scheduled using the offset SCN and the long DRX cycle length. The number of short DRX cycles may be scheduled between the first long DRX cycle and the second long DRX cycle.
- the WTRU may include a processor that may be configured to perform a number of actions.
- the processor may be configured to determine a long sleep length, a clock drift rate for the WTRU, and a wake-up time.
- An adjustment window may be generated using the long sleep length, the clock drift rate, and the wake-up time.
- a clock drift direction may be determined
- a signal maybe received from a network using the adjustment window.
- the processor may be configured to generate the adjustment window using the long sleep length, the clock drift rate, and the wake-up time. For example, the processor may determine the adjustment window using the long sleep length. The adjustment window may be scheduled using the wake-up time. The adjustment window may be adjusted using the clock drift rate such that a signal may be received from a network during the adjustment window.
- the processor may be configured schedule the adjustment window using the wake-up time.
- a length of the adjustment window may be decreased using the clock drift rate when the clock drift direction indicates that a clock is drifting towards longer time.
- a length of the adjustment window may be increased using the clock drift rate when the clock drift direction indicates that a clock is drifting towards shorter time.
- a WTRU may be provided to adjust a SFN cycle using assistance from a network.
- the WTRU may include a processor.
- the processor may be configured to receive a first system frame number (SFN) cycle order number from a network.
- the first SNF cycle order number may be received from the network via a system information.
- a second SFN cycle order number may be determined
- a drift range may be calculated using the first SFN cycle order number and the second SFN cycle order number.
- the drift range may be used to receive a signal from the network.
- the processor may be configured to receive a signal from the network in a next SFN cycle when the drift range indicates the network is scheduled to transmit the signal in the next SFN cycle.
- the processor may be configured to align a local SFN cycle number with the first SFN cycle order number when the drift range indicates that first SFN cycle order number and the second SFN cycle order number may not be aligned.
- the aligned SFN cycle number may be used to receive a signal from the network using the aligned SFN cycle number.
- ROM read only memory
- RAM random access memory
- register cache memory
- semiconductor memory devices magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
- a processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Description
- This application claims the benefit of U.S. Provisional Patent Application No. 61/644,922, filed May 9, 2012; and U.S. Provisional Patent Application No. 61/653,706, filed on May 31, 2012; the contents of which are hereby incorporated by reference herein.
- Machine type communication (MTC) devices may not need to frequently connect to a network to deliver or receive data. Additionally, a network may schedule a radio resource for a MTC device on a small number of occasions. Accordingly, MTC devices may not need to monitor a network for a signal or page as often as non-MTC devices. However, current wireless networks do not allow for long discontinuous reception (DRX) cycles or sleep lengths.
- Disclosed herein are methods and apparatus to enable wireless networks to provide a long discontinuous reception (DRX) cycle or sleep length. The embodiments may allow systems and MTC devices, such as a wireless transmit/receive unit (WTRU), to operate with long DRX cycles, sleep cycles, and/or periods. The embodiments may provide and/or enable MTC operations to permit infrequent system access or system reaching. The embodiments may allow MTC devices to sleep for a long period with low power consumption. The embodiments may also allow wireless networks to use an eNodeB (eNB) to perform energy saving algorithms.
- A WTRU may be provided that may include a processor configured to perform a number of actions. For example, the processor may be configured to determine a cycle base unit type and a length of a discontinuous reception (DRX) cycle. A number of base units of the cycle base unit type may be generated using the length of the long DRX cycle. The long DRX cycle may be generated from the number of base units.
- A WTRU for determining when to receive a signal may be provided. The WTRU may include a processor that may be configured to perform a number of actions. For example, the processor may be configured to determine a system frame number cycle number (SCN) within a total DRX period. A long DRX cycle length may be determined. An offset SCN may be generated using the SCN and the long DRX cycle length.
- A WTRU for minimizing clock drift impact may be provided. The WTRU may include a processor that may be configured to perform a number of actions. For example, the processor may be configured to determine a long sleep length, a clock drift rate for a WTRU, and a wake-up time. An adjustment window may be generated using the long sleep length, the clock drift rate, and the wake up time.
- A WTRU may be provided that may include a processor configured to perform a number of actions. For example, the processor may be configured to receive a first system frame number (SFN) cycle order number from a network. A second SFN cycle order number may be determined A drift range may be calculated using the first SFN cycle order number and the second SFN cycle order number.
- The Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, not is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to any limitations that solve any or all disadvantages noted in any part of this disclosure.
- A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings.
-
FIG. 1A depicts a system diagram of an example communications system in which one or more disclosed embodiments may be implemented. -
FIG. 1B depicts a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated inFIG. 1A . -
FIG. 1C depicts a system diagram of an example radio access network and an example core network (CN) that may be used within the communications system illustrated inFIG. 1A . -
FIG. 1D depicts a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated inFIG. 1A . -
FIG. 1E depicts a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated inFIG. 1A . -
FIG. 2 depicts an example of a short discontinuous reception cycle (DRX) cycle scheduled within a long DRX cycle. -
FIG. 3 depicts an example of a short cycle being used in between long DRX cycles. -
FIG. 4 depicts an example method for DRX configuration that may be initiated by a service capability server (SCS). -
FIG. 5 depicts an example method for a DRX cycle configuration that may be initiated by a radio access network (RAN). -
FIG. 6 depicts another example method for a DRX cycle configuration that may be initiated by a RAN. -
FIG. 7 depicts example network and WTRU procedures for busy reaching and monitoring. -
FIG. 8 depicts example SFNcycle order numbers -
FIG. 9 depicts example local SFNcycle order numbers -
FIG. 10 depicts an example WTRU clock realignment. -
FIG. 11 depicts another example WTRU clock realignment. - A detailed description of illustrative embodiments will now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.
- Some mobile networks may be optimized for human-to-human communications and may be less optimal for machine-to-machine (M2M) communications. Support for machine-type communications (MTC) may be used to accommodate the demand for machine type communications in wireless networks, such as 3GPP LTE wireless networks.
- Machine Type Communication (MTC) devices may include wireless transmit/receive units, such as cell phones, metering devices, or the like that may access the network less frequently than devices used for human-to-human use. The MTC devices may be wireless sensors or the like that may be deployed to remote areas for monitoring tasks or other tasks, where there may be limited access to power.
- MTC devices may not request to be continually connected for deliver or receive data. For example, a network may allocate radio resources for an MTC device on a reduce number of occasions, which may follow a pattern. MTC devices may not be requested listen to network signaling or network paging for long periods. MTC devices may monitor network signaling or paging less often than non-MTC devices.
- A network may have knowledge of the location of a MTC device or may have knowledge of a geographic location where an MTC device may be found. MTC devices may perform less mobility related tasks (e.g. TAU) or cell measurements, or may not perform mobility related tasks during a sleep/dormant period.
- MTC devices deployed in a remote area or in an inconvenient area may operate on battery power and may wish to save power. In some cases, MTC battery life may be expected to last for an extended amount of time, such as ten years.
- For power saving purposes, a device may shut down for a long period of time, which may be scheduled, and may not listen to a network during this scheduled period of time. In some cases, the MTC device may continue timing and timer maintenance procedures during this period. After this period is over, the device may wake up and may listen to signals, such as MTC downlink paging signals, triggering signals, reaching signals, or the like. This may be done, for example, to determine if the network wishes to communicate with the device.
- There may be a number of scenarios where a device may wake up. For example, a device may wake up and may attempt a system access to deliver user data content. As another example, a device may wake up to read system information where the network may try to deliver user data content.
- As an example, a device may wake up and may attempt to access a system to delivery data. This may occur, for example, when a power meter wakes up a month at a time to report a power meter reading. As another example, a device may wake up to read system information in case the network may try to deliver data. This may occur, for example, when a device wakes up once a week to determine if the network has an administrative request or task for it, such as an instruction to cut off electric supply for a tenant who may be moving out of an apartment.
- A prolonged sleeping period may be referred to as a long DRX cycle or an extended DRX cycle. A long DRX cycle may be a cycle length of a month, a week, a day, or the like. Provisioning of a long or DRX cycle may place a MTC device into an offline shutdown state where the device may not measure the serving cell frequently to ensure coverage for a long period. This may provide opportunities for base stations to perform energy saving tasks, such as planned power downs.
- Although devices may simply shut off and power back on as requested, this uncoordinated behavior may lead to having a large amount of devices that may waking up around the same time. This may result in congestion surges. An uncoordinated scheme may rely on a device pulling mechanism where the device may check at regular intervals whether there may be data waiting instead of having the network push data upon arrival based on paging slots.
- A DRX-like mechanism may be provided for devices that may sleep longer than the current LTE System Frame Number (SFN) cycle may allow. This may provide a device-network synchronization mechanism that may allow a manageable distribution of devices waking up to access the system. This may also enable the network to deliver user data to devices that may have slept for long periods of time without relying on data pulling mechanisms.
- A Long-DRX length unit and/or a Total-DRX-Definition-Period may be a time, a SFN cycle, a combination thereof, or the like, and may be used to allow a device to sleep in days/weeks/months, etc. Scheduling formulas may be provided for configuring WTRUs for long-DRX in a Total-DRX-Definition-Period. Methods may be provided to arrange short DRX within a long-DRX period. An adjustment-window length may be provided and may be a function of the long DRX cycle length and the clock drift rate. Procedures may be provided to schedule an adjustment window for a network and/or a WTRU that may assure that the WTRU may not miss network paging/signaling when the WTRU wakes up with misaligned timing that may be caused by, for example, drift. Network assisted WTRU resynchronization and WTRU autonomous adjustment may be provided. Procedures for coordination of long DRX cycles between a RAN, a WTRU, and Service Capability Server (SCS) may be provided.
- To provide device-network synchronization, a DRX mechanism may be used for devices that may use a cycle that may be longer than the current LTE System Frame Number cycle. This may allow a manageable distribution of devices to wake up and access a system. Additionally, this may ensure that the network may deliver data to devices that may have slept for long periods of time without relying on data pulling mechanisms.
- In current LTE, a default paging cycle length for a WTRU is, in general, configured to be between 32 to 256 LTE frames (i.e. a device sleeps for about 32 to 256 frames or 0.32 to 2.56 seconds, then wakes up) within a complete SFN cycle (1024 LTE frames).
- The current complete LTE SFN cycle is 1024 frames=10.24 seconds or 4096 UMTS frames=40.96 seconds. This time period definition may not be long enough to accommodate longer DRX requirements for MTC devices that may request long sleeping periods, such as days, hours, or the like. Thus, the devices may request longer periods than what is offered by the current LTE or UMTS complete SFN cycle.
- If a MTC device, such as a WTRU, were to go into a long sleep for a period long than a SFN cycle, synchronization issues may occur and the local clock may not be adjusted by the network clock. Additionally, the WTRU may not be able to receive network paging messages that were previously scheduled. For example, a WTRU may be in a power saving mode for a long sleep that may last days or weeks. During this period the WTRU may not have contact with the network. A clock used by the WTRU to count timing for a scheduled wake-up may drift. The longer the long-deep-sleep, the more the timing may drift when the device wakes-up. When the WTRU wakes up, the monitoring clock may have drifted. If local clock has drifted beyond a limit, the WTRU may not be able to synchronize and the WTRU may not be able to receive network signaling or paging around the scheduled time.
- The current LTE SFN cycle may not evenly distribute delay tolerant MTC device traffic and network access during low system load periods with a long DRX cycle. Additionally, the current LTE SNF cycle may not allow for different DRX or sleep time length units, such as a calendar time unit, that may be used to enable the configuration of MTC DRX or sleep period in order to wake up at the service desired time or moment.
- Extended DRX cycles may allow for closer coordination between the RAN and the Service Capability Server (SCS) and/or MTC interworking function (IWF).
- Long DRX cycles may be used to limit when other entities may be able to contact the device as the device may be contacted when the device may be available. For example, the SCS may contact the device over the user plane or via a trigger. Since SCS operation may be impacted by the DRX cycle of its registered devices, the SCS may be part of the DRX cycle negotiation or the SCS may be made aware of the DRX cycle of its registered devices.
- When the SCS may not be aware of the DRX cycles or of its connected devices, then the SCS may attempt to contact the device over the SGi/Gi user plane or via Tsp trigger requests while the device may be sleeping. These contact attempts may cause unwanted signaling between the core network (CN) and the SCS. Mechanisms may be provided to allow the RAN to inform the SCS of the MTC device's DRX cycle.
- The core network may reject any communication attempt towards a device that may be is in a long DRX cycle. Additional measures may be taken to ensure that the SCS and its associated network applications may not attempt to continuously reach sleeping devices.
- The core network may not know how long devices may be allowed to sleep without breaking application level functionality. The SCS may know this information or may be able to learn it when the MTC device registers with the SCS. Mechanisms may be provided to allow the SCS to inform the RAN of the DRX requests of an MTC device, such as how long the device may sleep without breaking the application requirements.
- There may be some cases where the device may simply inform the RAN of its DRX requests. However, it may be more efficient if the SCS coordinated when it may poll the meters, how often they may be polled, and when they may be available for SW upgrades.
- Embodiments described herein may provide units and mechanisms for long-drx time scenarios that may allow and support the LTE time unit for time periods longer than a complete SFN cycle.
- Procedures and messages may be provided to allow the SCS to coordinate the allowable DRX cycle lengths with the RAN.
- Embodiments disclosed herein may provide methods to mitigate synchronization issues that may occur when the local WTRU clock drifts beyond a recovering period. These methods may include mechanisms that may allow the reception of paging messages within a time window, which may be affected by factors such as the long sleep time, WTRU speed, WTRU capabilities, or the like. For example, given a clock drift rate, the length of the adjustment-window may be a function of the long-deep-sleep length such that the longer the long-deep-sleep length, the greater the adjustment-widow length/size. Embodiments may allow for a relationship between an adjustment-window and a long-deep-sleep-length. The embodiments may also provide actions that may be taken by a WTRU, a network (such as eNB and MME), or both the WTRU and network before or during the adjustment-window period.
- As used herein, the term extended DRX cycle, the term long DRX cycle, and the term long sleep cycle/period may be used interchangeably. The term adjustment-window and the term receive-window may also be used interchangeably.
- Although the embodiments may be described in terms of an LTE network, the embodiments may also apply to other radio access technologies, networks, devices, and periodic operations, such as network broadcast/multicast and WTRU receptions.
- The long DRX cycle and its operation configuration may be configured for WTRUs that may request a long sleep. As used herein, a serving node and may refer to mobile switching center (MSC), a serving general packet radio service (GPRS) support node (SGSN), or mobility manager gateway (MME).
-
FIG. 1A is a diagram of anexample communications system 100 in which one or more disclosed embodiments may be implemented. Thecommunications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. Thecommunications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, thecommunications 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. - As shown in
FIG. 1A , thecommunications system 100 may include wireless transmit/receive units (WTRUs) 102 a, 102 b, 102 c, and/or 102 d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, acore network 106/107/109, a public switched telephone network (PSTN) 108, theInternet 110, andother 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 theWTRUs WTRUs - The
communications systems 100 may also include abase station 114 a and abase station 114 b. Each of thebase stations WTRUs core network 106/107/109, theInternet 110, and/or thenetworks 112. By way of example, thebase stations base stations base stations - The
base station 114 a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. Thebase station 114 a and/or thebase station 114 b 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 thebase station 114 a may be divided into three sectors. Thus, in one embodiment, thebase station 114 a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, thebase station 114 a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell. - The
base stations WTRUs - 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, thebase station 114 a in the RAN 103/104/105 and theWTRUs - In another embodiment, the
base station 114 a and theWTRUs - In other embodiments, the
base station 114 a and theWTRUs - The
base station 114 b inFIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, thebase station 114 b and theWTRUs base station 114 b and theWTRUs base station 114 b and theWTRUs FIG. 1A , thebase station 114 b may have a direct connection to theInternet 110. Thus, thebase station 114 b may not be requested to access theInternet 110 via thecore network 106/107/109. - The RAN 103/104/105 may be in communication with the
core network 106/107/109, 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 theWTRUs core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown inFIG. 1A , it will be appreciated that the RAN 103/104/105 and/or thecore network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, thecore network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology. - The
core network 106/107/109 may also serve as a gateway for theWTRUs PSTN 108, theInternet 110, and/orother networks 112. ThePSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). TheInternet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. Thenetworks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, thenetworks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT. - Some or all of the
WTRUs communications system 100 may include multi-mode capabilities, i.e., theWTRUs WTRU 102 c shown inFIG. 1A may be configured to communicate with thebase station 114 a, which may employ a cellular-based radio technology, and with thebase station 114 b, which may employ anIEEE 802 radio technology. -
FIG. 1B is a system diagram of anexample WTRU 102. As shown inFIG. 1B , theWTRU 102 may include aprocessor 118, atransceiver 120, a transmit/receiveelement 122, a speaker/microphone 124, akeypad 126, a display/touchpad 128,non-removable memory 130,removable memory 132, apower source 134, a global positioning system (GPS)chipset 136, andother peripherals 138. It will be appreciated that theWTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that thebase stations base stations FIG. 1B and described herein. - The
processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. Theprocessor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables theWTRU 102 to operate in a wireless environment. Theprocessor 118 may be coupled to thetransceiver 120, which may be coupled to the transmit/receiveelement 122. WhileFIG. 1B depicts theprocessor 118 and thetransceiver 120 as separate components, it will be appreciated that theprocessor 118 and thetransceiver 120 may be integrated together in an electronic package or chip. - The transmit/receive
element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., thebase station 114 a) over the air interface 115/116/117. For example, in one embodiment, the transmit/receiveelement 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receiveelement 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/receiveelement 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receiveelement 122 may be configured to transmit and/or receive any combination of wireless signals. - In addition, although the transmit/receive
element 122 is depicted inFIG. 1B as a single element, theWTRU 102 may include any number of transmit/receiveelements 122. More specifically, theWTRU 102 may employ MIMO technology. Thus, in one embodiment, theWTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117. - The
transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receiveelement 122 and to demodulate the signals that are received by the transmit/receiveelement 122. As noted above, theWTRU 102 may have multi-mode capabilities. Thus, thetransceiver 120 may include multiple transceivers for enabling theWTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example. - The
processor 118 of theWTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, thekeypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). Theprocessor 118 may also output user data to the speaker/microphone 124, thekeypad 126, and/or the display/touchpad 128. In addition, theprocessor 118 may access information from, and store data in, any type of suitable memory, such as thenon-removable memory 130 and/or theremovable memory 132. Thenon-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Theremovable 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, theprocessor 118 may access information from, and store data in, memory that is not physically located on theWTRU 102, such as on a server or a home computer (not shown). - The
processor 118 may receive power from thepower source 134, and may be configured to distribute and/or control the power to the other components in theWTRU 102. Thepower source 134 may be any suitable device for powering theWTRU 102. For example, thepower source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like. - The
processor 118 may also be coupled to theGPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of theWTRU 102. In addition to, or in lieu of, the information from theGPS chipset 136, theWTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g.,base stations WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment. - The
processor 118 may further be coupled toother 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, theperipherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like. -
FIG. 1C is a system diagram of the RAN 103 and thecore network 106 according to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with theWTRUs core network 106. As shown inFIG. 1C , the RAN 103 may include Node-Bs WTRUs Bs RNCs - As shown in
FIG. 1C , the Node-Bs RNC 142 a. Additionally, the Node-B 140 c may be in communication with theRNC 142 b. The Node-Bs respective RNCs RNCs RNCs Bs RNCs - The
core network 106 shown inFIG. 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of thecore 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. - The
RNC 142 a in the RAN 103 may be connected to theMSC 146 in thecore network 106 via an IuCS interface. TheMSC 146 may be connected to theMGW 144. TheMSC 146 and theMGW 144 may provide the WTRUs 102 a, 102 b, 102 c with access to circuit-switched networks, such as thePSTN 108, to facilitate communications between theWTRUs - The
RNC 142 a in the RAN 103 may also be connected to theSGSN 148 in thecore network 106 via an IuPS interface. TheSGSN 148 may be connected to theGGSN 150. TheSGSN 148 and theGGSN 150 may provide the WTRUs 102 a, 102 b, 102 c with access to packet-switched networks, such as theInternet 110, to facilitate communications between and theWTRUs - As noted above, the
core network 106 may also be connected to thenetworks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers. -
FIG. 1D is a system diagram of theRAN 104 and the core network 107 according to an embodiment. As noted above, theRAN 104 may employ an E-UTRA radio technology to communicate with theWTRUs air interface 116. TheRAN 104 may also be in communication with the core network 107. - The
RAN 104 may include eNode-Bs 160 a, 160 b, 160 c, though it will be appreciated that theRAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160 a, 160 b, 160 c may each include one or more transceivers for communicating with theWTRUs air interface 116. In one embodiment, the eNode-Bs 160 a, 160 b, 160 c may implement MIMO technology. Thus, the eNode-B 160 a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, theWTRU 102 a. - Each of the eNode-Bs 160 a, 160 b, 160 c 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. 1D , the eNode-Bs 160 a, 160 b, 160 c may communicate with one another over an X2 interface. - The core network 107 shown in
FIG. 1D may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, 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. - The MME 162 may be connected to each of the eNode-Bs 160 a, 160 b, 160 c in the
RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of theWTRUs WTRUs RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA. - The serving gateway 164 may be connected to each of the eNode-Bs 160 a, 160 b, 160 c in the
RAN 104 via the S1 interface. The serving gateway 164 may generally route and forward user data packets to/from theWTRUs WTRUs WTRUs - The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102 a, 102 b, 102 c with access to packet-switched networks, such as the
Internet 110, to facilitate communications between theWTRUs - The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102 a, 102 b, 102 c with access to circuit-switched networks, such as the
PSTN 108, to facilitate communications between theWTRUs PSTN 108. In addition, the core network 107 may provide the WTRUs 102 a, 102 b, 102 c with access to thenetworks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers. -
FIG. 1E is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with theWTRUs WTRUs - As shown in
FIG. 1E , the RAN 105 may include base stations 180 a, 180 b, 180 c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180 a, 180 b, 180 c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with theWTRUs WTRU 102 a. The base stations 180 a, 180 b, 180 c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like. - The air interface 117 between the
WTRUs WTRUs WTRUs - The communication link between each of the base stations 180 a, 180 b, 180 c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180 a, 180 b, 180 c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the
WTRUs - As shown in
FIG. 1E , the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, 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. - The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102 a, 102 b, 102 c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102 a, 102 b, 102 c with access to packet-switched networks, such as the
Internet 110, to facilitate communications between theWTRUs PSTN 108, to facilitate communications between theWTRUs networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers. - Although not shown in
FIG. 1E , it will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of theWTRUs - Embodiments may provide Long DRX cycle length definition and configuration of the long DRX cycle for MTC devices. Some MTC devices require low power consumption. Thus, frequent monitoring, paging, and/or listening to system information may unnecessarily waste the battery power of these MTC devices. Extended DRX cycle or the long DRX cycle length units may be used for these types of MTC devices to enable these devices to sleep/DRX under scheduling or configuration.
- A long DRX cycle may be provided. To accommodate the long DRX cycle operation, one or more cycle length base units may be described herein. A long DRX cycle may be one or more of the base units.
- To align with the current 3GPP wireless DRX cycle base unit, a long DRX cycle length unit may be based on an SFN cycle. For example, one or more of the SFN cycle(s) may be used as the base unit. This may be referred to as an extended SFN cycle(s). A long DRX cycle length, which may be the extended SFN cycle, may be of n SFN cycle(s), where the n value may be:
- [1, 2, 4, 8, . . . ] or [1, 3, 6, 12, . . . ] or [kmb, where k=2, 3, 4, . . . and m=0, 1, 2, . . . and b=1, 2, 3, 4, . . . ], etc
- The n value or the values used for deriving n, such as k, m, and b, may be predefined or network configured. The long DRX cycle, the extended DRX cycle, or the long-deep-sleep period may consist of one or more of the extended SFN cycles described herein.
- To align with possible MTC operation service time definitions, a long DRX cycle, an extended DRX cycle, or a long deep sleep period unit may be based on time units or calendar time units, such as a second, a minute, an hour, a day, a week, a month, a combination of those units, or the like. For example, a long DRX cycle may be two-days, two-weeks, or one-month-plus-two-days, etc. Depending on the service the MTC device may be configured for, the network may assign the MTC devices with service specific extended DRX cycle length. A system may use broadcast or MTC specific messages to convey the MTC extended DRX cycle and parameters to MTC devices. When using a time unit for sleep/DRX in a configuration and if the configured time does not start or end on an SFN cycle boundary, then the counting of the start and the end of such a time unit may be rounded forward to the next SFN cycle boundary.
- To align with the MTC service time and to facilitate DRX operation with frame-based 3GPP DRX operations, a combination of the two units described above may be used, i.e. the time unit(s)+the extended SFN cycles. For example, a long DRX cycle length unit (definition-C) may be 2-week+5*extended SFN cycles or may be one-week+7*SFN cycles. This may be used to provide a long DRX cycle that may have a length of in days and a low activity period of the day. A mechanism may be provided to distribute the MTC device evenly among the low activity period in the extended/long DRX cycle.
- To ensure that an MTC server may have a chances to trigger a MTC device, the system may configure the MTC device to stay in a normal DRX cycle for some time after one or more long DRX cycles. For example, the long DRX cycle may be a three-tuple, such as:
- extended DRX cycle=number of Day+low Activity Period+OnTimePeriod where the “number of Days” may be the days of the extended DRX cycle, the “low Activity Period” may be the period of low activity during the day (e.g. 4 am), and the “OnTimePeriod” may be the length of time the WTRU may monitor the paging over a shorter or regular DRX.
- A Total-DRX-Definition-Period may be provided. The Total-DRX-Definition-Period may be a multiple of a long DRX cycle. The Total-DRX-Definition-Period may be a combination of some multiples of the DRX base units described herein. For example, a Total-DRX-Definition-Period may be based on an extended SFN cycle, a time unit, a calendar time unit, or combination of an extended SNF cycle and a time unit, or any combination thereof, or the like.
- A Total-DRX-Definition period may be as a combination of one or more of the descriptions provided in the following paragraphs.
- A Total-DRX-Definition-Period may be a multiple of an extended SFN cycle base unit as described herein. For example, the Total-DRX-Definition-Period may be a multiple of an extended SFN cycle, such as 32 extended SFN cycles. A Total-DRX-Definition-Period may be a combination of an extended SFN cycle and a base unit, such as 36 extended SFN cycle plus 12-SFN cycles. If the Total-DRX-Definition-Period may be m extended SFN cycles, each with (n) SFN cycles, the Total-DRX-Definition-Period may have (m*n) SFN cycles. This may be numbered as [0, 1, . . . m×n−1]. If the Total-DRX-Definition-Period may be a combination of multiples of some of the base units described herein, then the Total-DRX-Definition-Period may have a combination of (j) extended SFN cycles and (k) SFN cycles and it may have (j*n)+k SFN cycles. This may be numbered as [0, 1, . . . , j*n, j*n+1, j*n+2, . . . j*n+k−1]. The MTC device, such as a WTRU, and the network supporting the long-DRX operation may count the SFN Cycle Number (SCN) from 0 to the end of the Total-DRX-Definition-Period (i.e. the m*n−1 or the j*n+k−1 SFN cycles) and may wrap-around to the next period from the 0 SFN cycle again.
- A Total-DRX-Definition-Period may be a base unit, such as 6-months, or a combination of multiples time units, such as 9-months plus 12-weeks. In some scenarios, the conversion of the Total-DRX-Definition-Period to the number of extended DRX cycle or the number of SNF cycles may be rounded up to the nearest Extended DRX cycle or to the nearest SNF cycle.
- A Total-DRX-Definition-Period may be some combination of the base units described herein, such as a combination of an extended SNF cycle and a time unit. For example, the Total-DRX-Definition-period may be 24 weeks plus 42 extended SFN cycles. In some scenarios, the conversion of the Total-DRX-Definition-Period to the number of extended DRX cycle or the number of SNF cycles may be rounded up to the nearest extended DRX cycle or to the nearest SNF cycle.
- A Total-DRX-Definition-Period may also be a combination of any of the embodiments described herein. MTC device configurations may be provided for utilizing the long DRX cycle. As described herein, the Total-DRX-Definition-Period and the Long-DRX-base-units (which may include the extended SFN cycle, a base unit, or combinations thereof) may provide MTC devices for long dormant periods of sleep that may preserve power. The Total-DRX-Definition-Period and/or the long DRX base unit may be configured for a MTC device to allow the device to operate in a discontinuous reception mode, idle mode, an offline mode, or the like. This may allow the MTC device, such as a WTRU, to identify its paging time after the long sleep or long DRX.
- A formula may be used for scheduling a page/signal/reach for a MTC device that may have been in a long sleep. For example, one or more SFN cycle(s) may be identified in a Total-DRX-Definition-period such that the network may page the device in that cycle and the device may perform monitoring and reception. The SNF cycle may also be identified such that the MTC device may find its paging frame(s) and the paging subframe occasion(s) either with the an idle mode paging reception formula or with some other formula or rules.
- For example, a WTRU may obtain the monitoring/reception Nth SFN cycle while configured for long DRX or long deep sleep using the following:
-
SCN % ConfiguredLongDRXCycleLength=OffsetSCN, -
- where the SCN may be the counting of the SFN cycle number, described herein, within the Total-DRX-Definition-Period;
- the ConfiguredLongDRXCycleLength may be the extended DRX cycle or the long DRX cycle length configured to the WTRU in numbers of SFN cycles; and
- the OffsetSCN may be an offset in unit of SCN given by the network
- As shown in
FIG. 2 , a shorter DRX cycle may be scheduled inside a long DRX cycle. Temporary network congestion or RAN resource jamming may cause a MTC device, such as a WTRU, to miss a network paging or signal after a long-sleep. For the network and/or the MTC device to avoid missing a network paging or signaling after a long-sleep, a short DRX cycle within a long DRX cycle may be configured. The short DRX cycle may be configured in a second long DRX cycle that may occur after a first long DRX cycle. For example, as shown inFIG. 2 ,long DRX cycle 202 may be configured such that it may not include one or more short cycles.Long DRX cycle 204 may occur afterlong DRX cycle 202. One or more short DRX cycles may be configured withinlong DRX cycle 204, such as short DRX cycles 206. A short DRX cycle, such as short DRX cycles 206, may be used, for example, to provide occasions for a network to re-transmit and/or for a WTRU to re-receive a signal. Network paging/signaling repetitions may run with the one or more short DRX cycles from short DRX cycles 206. Network paging/signaling may be scheduled from the long DRX cycle boundary. - A network may configure a WTRU with a long DRX cycle, which may be followed a number, M, DRX cycles. After a MTC device, such as a WTRU, wakes up from a long DRX, it may use a short DRX cycle for a period of time.
- Configured LongDRXCycleLength may be a multiple (m) of the ShortDRXLength in the following formula such that the short DRX occasions may be on the SCNs with ((SCN−OffsetSCN) % ConfiguredLongDRXCycleLength)=(n*ShortDRXLength), where n=(1, 2, . . . m−1) configurable.
- Short DRX cycles may be placed before, around, or after a long DRX cycle boundary; before, around, or after a scheduled paging SFN cycle; or before, around, or after the network paging/signaling frames. These schedules may be configured by the WTRU or the network. Network paging/signaling may be scheduled at those boundary, cycle, or frames.
- As shown in
FIG. 3 , short cycles may be used in between long DRX cycles. A network may configure a WTRU with an extended/long DRX cycle followed with m number of DRX cycles. In this configuration, after a MTC device wakes up from the extended DRX, it may take shorter DRX cycles for a period of time and then may start another long or extended DRX cycle. For example, as shown inFIG. 3 ,extended DRX cycle 300 may be scheduled. Short DRX cycles 302 may be scheduled afterextended DRX cycle 300.Extended DRX cycle 304 may be scheduled after short DRX cycles 302. - The MTC device may be configured with an extended DRX cycle that may follow the extended DRX cycle in idle mode. If the extended DRX cycle may be configure through a WTRU dedicated message, a network may configure a MTC device with an extended DRX cycle using a RRC message, or a NAS message. For example, a WTRU may trigger a tracking area update (TAU) procedure and may send a TAU message to the network. In the message, the WTRU may indicate its ongoing MTC applications. Based on the ongoing WTRU applications, or the changes in the ongoing WTRU applications, the network may configure the MTC device with an extended DRX cycle or may modify the configured extended DRX cycle.
- When MTC device is configure with extended DRX cycle, MTC device may calculate its wake up time. For example, the MTC may use the following formula:
-
StartTime=(number of Day) % (LongDRXCycleUnit)+low Activity Start Time+(low Activity length) % (LongDRXCycleUnit) - where LongDRXCycleUnit may be a number that given by the system or calculated from UeID.
- An uneven sleep period assignment may be provided. For MTC devices, the uneven sleep period or periods may be assigned by the network to the WTRU such that the WTRU may sleep for a different period from time to time according to the assigned long sleep length. For example, a WTRU may sleep for 5 hours, wake up, and then may sleep for 5 months. The uneven sleep period may be assigned by a message or may be assigned by rules. The uneven sleep period(s) may be assigned one a time or several uneven periods may be assigned at once.
- DRX cycle configuration may be provided. DRX configurations determination may be provided by an operator. Information may be obtained from the SCS before calculating the DRX cycle. A MTC-IWF and a SCS may be informed of the DRX configuration.
- A SCS may initiate a DRX cycle configuration.
FIG. 4 depicts a method for DRX configuration that may be initiated by a SCS. The allowable length of a long DRX cycle may depend on an application and may be dynamic. When an MTC device first connects to a network, the network may assume that the device may be using existing DRX methods. When the MTC device application registers with the SCS, the SCS may indicate the application requested sleep parameters to the core network and RAN (eNB or RNC). The RAN (eNB or RNC) may then calculate the long DRX cycle parameters that may be used by the device. - For example, as shown in
FIG. 4 , at 416,MTC WTRU 402 may register with a core network, which may include RNC/eNodeB 404, MSC/SGSN/MME 406, andHSS 408. Subscription information forMTC WTRU 402 inHSS 408 may include an indication thatMTC WTRU 402 may support Long DRX. A long DRX cycles may not have been configured. At 418, one or more MTC Applications onMTC WTRU 402 may register with the service layer using application/service layer procedures, which may involve RNC/eNodeB 404, MSC/SGSN/MME 406,HSS 408, MTC-IWF 410, andSCS 412. At 420,SCS 412 may register the application(s) DRX parameters with the core network. This information may be passed to MTC-IWF 410 via, for example, a Tsp reference point. This may occur, for example, using a message on the Tsp reference point. This message may be provided as shown in Table 1: -
TABLE 1 Application DRX Request Message Information Element M/O Description Device External M The device external ID (e.g. MSISDN, FQDN, Identifier etc) Note: This field may be populated with a group identifier so that the SCS may request DRX parameters for a group of devices. SCS Identifier M The SCS ID (e.g. MSISDN, FQDN, etc) Application O The application ID (e.g. Port Number, SCS Identifier assigned name, etc.) Note: This field may be populated with a group identifier so that the SCS may request DRX parameters for a group of applications. Max Off Time O The maximum amount of time that the appli- cation may be allowed to sleep. The units of this field may be seconds or some period of time. Min On Time O The minimum amount of time that the device may stay on when coming out of sleep. The units of this field may be seconds or some period of time. Mandatory O Periods of the day when the device may be On Times reachable. The units of this field may be seconds or some period of time. Permitted O Periods of the day when the device may not Off Times be reachable. The units of this field may be seconds or some period of time. - Referring again to
FIG. 4 , at 424, MTC-IWF 410 may use an S6m reference point to resolve the device and SCS identifiers to subscription identifiers. The MTC-IWF may also identify the serving node of the device. This may include a check of the HSS subscription parameters to verify thatMTC WTRU 402 supports long DRX cycles. At 426, MTC-IWF 410 may pass updated DRX information to the serving node using, for example, a T5 reference point. This may be done, for example, using a message, such as the message shown below in Table 2: -
TABLE 2 Application DRX Update Message Information Element M/O Description Device Internal M The device internal ID (e.g. IMSI) Identifier Note: This field may be populated with a group identifier so that the SCS may request DRX parameters for a group of devices. MTC-IWF M IP Address, SS7 address, ISDN, etc. Identifier Application O The application ID (e.g. Port Number, SCS Identifier assigned name, etc.) The serving node or RAN may use this ID to keep track of the multiple applications that may be on a device and how their DRX parameter re- quests may overlap. Note: This field may be populated with a group identifier so that the SCS may request DRX parameters for a group of devices. Max Off Time O The maximum amount of time that the appli- cation may be allowed to sleep. The units of this field may be seconds or some period of time. Min On Time O The minimum amount of time that the device may stay on when coming out of sleep. The units of this field be seconds or some period of time. Mandatory O Periods of the day when the device may be On Times reachable. The units of this field may be seconds or some period of time. Permitted O Periods of the day when the device may not Off Times be reachable. The units of this field be seconds or some period of time. - At 428, the serving CN node may use an Iu or S 1-MME reference point to pass the updated DRX information to the RAN. This may be done using, for example, a NAS message that may be sent to the RAN, which may include the information shown in Table 2 (the MTC-IWF address may not be requested). At 430, DRX parameters may be calculated and the device may be configured with the DRX parameters. The CN serving node may inform/configure the MTC device directly with a NAS message, such as described above, on the long DRX or long sleep activity.
- At 432, the RAN may pass the DRX parameters to the serving node via the Iu or S 1-MME reference points. This message may include the information that may be shown in Table 2. The MTC-IWF address may not be included. The RAN may configure the device with parameters that may be different than what was requested. Different parameters may be selected due to network congestion or the RAN may select different parameters in order to accommodate other applications on the same device may have different DRX parameter requests (i.e. another application may request to be on at different times).
- At 434, the serving note may pass DRX parameters received at 432 to MTC-
IWF 410. This may be done, for example, using a T5 reference point. MTC-IWF 410 may store updated DRX parameters so that it may manage trigger requests. At 436, MTC-IWF 410, may send the DRX parameters toSCS 412 using, for example, a Tsp reference point. The DRX parameters may be different than what may have been requested at 420. - DRX cycle configuration may be initiated by a WTRU or a RAN.
FIG. 5 depicts a method for DRX cycle configuration that may be initiated by a RAN. When network conditions change, when an MTC devices moves, or when an MTC application wakes up, the WTRU or RAN may reconfigure a DRX cycle for the WTRU. When the WTRU and RAN (eNB and RNC) change the DRX parameters for the WTRU, the SCS may be informed. - As shown in
FIG. 5 , at 516,MTC WTRU 504 and a RAN, such as RNC/eNodeB 504, may negotiate a DRX cycle. This may be initiated by the WTRU or the RAN (eNB or RNC). The information exchanged may be the same as what is shown in Table 1. An MTC-IWF address may or may not be used. - At 518, the RAN (eNB/RNC 504) may inform the serving node, MSC/SGSN/
MME 506, of the DRX cycle parameters. The serving node may be a MSC, SGSN, or a MME. This may be done, for example, by sending a message using the Iu and S1-MME reference points. The fields of the message may be the same as what is shown in Table 2. An MTC-IWF address may or may not be included. - At 520, MSC/SGSN/
MME 506 may send a get MTC-IWF address message toHSS 508. This may be done, for example, to allow the serving node to queryHSS 508 with the international mobile subscriber identify (IMSI) for a device for the MTC-IWF, such as MTW-IWF 510, that may be used to reach the SCS, such asSCS 512, that the device may be registered to. The message may be sent on an S6m reference point. - At 522, MSC/SGSN/
MME 506 may inform MTC-IWF 510 of the DRX cycle parameters. This may be done, for example, sending a message using the T5 reference point. The fields of this message may be the same as what may be shown in Table 2. - At 524, MTC-
IWF 510 may informSCS 512 of the DRX cycle parameters. This may be done, for example, by sending a message using on the Tsp reference point. The fields of this message may be the same as what may be shown in Table 1. - DRX cycle configuration may be initiated by a WTRU or a RAN. For example, the SCS may be informed of a DRX cycle for a device.
FIG. 6 depicts another method for DRX cycle configuration that may be initiated by RAN. - As shown in
FIG. 6 at 618,MTC WTRU 602 and a RAN, such as RNC/eNodeB 604, may negotiate a DRX cycle. This may be initiated by the WTRU or RAN (eNB or RNC). The information exchanged may be similar to what may be shown in Table 1. The MTC-IWF address may or may not be used. - At 620, the service layer of
MTC WTRU 602 may informSCS 612 of a DRX update over a user plane connection. This communication may happen between service layers (i.e. European Telecommunications Standards Institute (ETSI)). This message may include the fields that may be shown in Table 1. The MTC-IWF address may or may not be used. MSC/SGSN/MME 606 and MTC-IWF 610 may not be informed of the of the DRX cycle.SCS 612 may be trusted not to continuously attempt to contact the device when it may be sleeping. - Device trigger requests may be provided. For example, device triggering procedures may occur over a Tsp reference point. The procedures on this interface may be updated to account for the where a SCS may attempt to trigger a device that may be in a long DRX cycle. The MTC-IWF may choose to reject or buffer the trigger request. For example, the device may not be scheduled to be awake for several hours and MTC-IWF policies may determine how long the MTC-IWF may buffer triggers.
- If the MTC-IWF chooses to reject the trigger request, the MTC-IWF may send the SCS a Device Trigger Confirm message with a value that may indicate that the request may be rejected because the device may be in a long DRX cycle. The Device Trigger Confirm message may indicate a time when the trigger may be attempted again.
- If the MTC-IWF chooses to cache the trigger request until the device may be reachable, the MTC-IWF may send the SCS a Device Trigger Confirm message with a value the may indicate that the request may be buffered because the device may be in a long DRX cycle. The Device Trigger Confirm message may indicate an estimate as to when the trigger may be delivered. The SCS may know the DRX cycle of the MTC applications that may be registered to it. The SCS may avoid making triggering requests to an application that may not be reachable.
- DRX classes may be provided. To reduce the amount of signaling inside of the CN, between the CN and SCS, or between the WTRU and RAN, a set of DRX classes may be defined. The Max On and Max Off times of Table 1 may then be determined by a predefined class number. An example may be shown in Table 3. The predefined classes may be used to determine the duty cycle of the DRX cycle, and may not be used to determine when the duty cycle starts.
-
TABLE 3 DRX Class Example Class MIN ON MAX OFF Number TIME TIME Example Use- Case 0 30 Seconds 1 Hour Environmental Sensor, Asset Tracking 1 1 Minute 23 Hour Smart Meter, Patient Surveillance 2 10 Minutes 1 Week Retail Monitoring, Product management, Vehicle diagnostics 3 15 Minutes 1 Month Disaster Detection (sensor may initiate contact at any time - SCS may initiate contact one a month) - An adjustment-window may be defined from the length of the scheduled long-sleep period. The WTRU and/or network may perform procedures for the adjustment. A receiving window or an adjustment-window may be defined at the WTRU side and may be used interchangeably. With the receiving window, a WTRU may monitor the paging channel as it may do in an IDLE state. The receiving window may start as a WTRU may wake up from the long sleep and the window may end when the WTRU may have received the paging or may end after a period of time (such as a receiving window length). The receiving window length may be predefined, indicated by the network, or calculated from the long sleep period. When the receiving window starts, WTRU may perform synchronizing with the network, reading MIB and SIBs. The WTRU may start monitoring the paging channel with a DRX cycle, which may be a paging cycle. The paging occasions may be related to SFN. Since the WTRU and the network may be synchronized with SFN, the WTRU may not miss the paging. The receiving window length for the WTRU may be long enough to cover the drifted time and the receiving window for the WTRU may start earlier than the network starts the transmitting window.
- An adjustment window may be defined from the length of the scheduled long sleep period. When a MTC WTRU goes dormant, it may not perform any activities that may involve contact with the network to save power. For example, the MTC WTRU may not perform measurement of the cell or perform any mobility area update. The WTRU may not have a chance to learn the network timing and adjust its own clock and the WTRU clock may drift from the network clock. This may occur at a certain rate and may depend on the make of the clock. The longer the MTC WTRU may sleep, the more it may drift from the network timing on which the activity of communication synchronization may be based.
- When the long sleep MTC WTRU wakes up for a scheduled activity with the network, it may fail because of missed timing or synchronization. This may occur, for example, with schedule activities such as monitoring or receiving network paging or work signals. This may also occur when accessing the network.
- An adjustment window period may be provided to avoid missed timing or synchronization due to clocking drifting during a long sleep period. During the adjustment window period, the MTC WTRU and/or the network may take action to resynchronize or to remediate the negative impact of the missed timing.
- The adjustment window may be defined as a function of the long sleep period and the clock drift rate, known or estimated:
-
Adjustment window length=Long-Sleep-Length*ClockDriftRate+RoundUpTime - where the RoundUpTime maybe predefined, configured or a value related to the Long-Sleep-Length or the ClockDriftRate
- The adjustment window may also be defined using the following formula:
-
Adjustment window length=(Long-Sleep-Length*ClockDriftRate)*N - where the N could be [1, 1.2, 1.4, 1.6, . . . , 2].
- The adjustment window length unit may be a unit such as the LTE SFN cycle, an LTE frame, or the like. The length of the receiving window (i.e. the adjustment window) length may also be a value of time (e.g. 512 ms), a number of default paging cycles (e.g. 2×Paging Cycles), a number of radio frames (e.g. 20×Radio Frames), or the like.
- The receiving window length or the ClockDriftRate may be broadcasted in the system information.
- A network may start paging before the calculated receive window starts in a WTRU and may use a longer window length to cover the drifted time to make the paging more reliable.
- A WTRU may determine a window length to be used for the WTRU. The WTRU may notify the network of its receiving window length or the clock drift rate in the initial Attach or TAU message. In this case, the network paging message may also carry the receiving window length or clock drift rate information.
- WTRU and network procedures may be performed during the adjustment window.
FIG. 7 depicts network and WTRU procedures for busy reaching and/or monitoring. The network, such asnetwork 702, and a long sleep WRTU, such asWTRU 708, may avoid an issued caused by clock drift when the WTRU has computed the adjustment window length (i.e. the drift estimates). At 706,network 702 may employ a Busy Reaching Window around scheduled wake uptime 704, which may be a boundary of a Long DRX cycle such as Long-DRX cycle 715. During BusyReaching Window 706, the network may send paging or other reaching signal to a WTRU that may be waking up from a long sleep. The length of BusyReaching Window 706 may be based on the estimated longest adjustment window length. For example, three quarters, one, one and one half or twice the length of an estimated longest adjustment window length may be used for the length of BusyReaching Window 706; however, any length may be used.Network 702 may place Busy ReachingWindow 706 centered on scheduled wake-up time 704 (inFIG. 7 centered O). BusyReaching Window 706 length may be predetermined or configured and may be broadcast to the WTRUs via system information. - Busy
Reaching Window 706 may be selected to be as short as may be possible to reduce overhead and inefficiency. Additionally, Busy ReachingWindow 706 may not be employed if the WTRU clock does not drift. - At 710,
WTRU 708 may know its clock drift direction. That is,WTRU 708 may know whether its clock may drift towards shorter time (−drift) or towards longer time (+drift). The adjustment window or the drift window may be used to compensate the long DRX cycle counting (i.e. add the drift length if the “−drift” and subtract the drift length if the “+drift”), soWTRU 708 may know or learn approximately when scheduled wake-up time 704 may be.WTRU 708 may then configure WTRYBusy Monitoring Window 716 around or centered the estimated the scheduled wake-up time, which may overlap the network busy reaching window for activity. WTRUBusy Monitoring Window 716 may be any length. For example, WTRUBusy Monitoring Window 716 may be one or one and one half or twice of the computed adjustment-window length. - At 712 and 714,
WTRU 708 may not know the clock drift direction.WTRU 708 may set the length of a WTRU Busy Monitor Window, such as WTRUBusy Monitor Window 718 and WTRUBusy Monitor Window 720, to at least twice the computed adjustment window length.WTRU 708 may start the Busy Monitoring Window, such as at 722 and 724, one adjustment-window earlier than the scheduled wake up time, such as at 726 and 728, so that approximately half of the Busy Monitoring Window or one adjustment-window time may overlap with the network Busy Reach Window for activity. For example, WTRUBusy Monitor Window 718 and/or WTRUBusy Monitoring Window 720 may overlap with Network BusyReaching Window 706. - During period of the Busy
Reaching Window 706,network 702 may send paging or other signaling at the configured normal paging frames (PF) and paging subframe occasions (PO) in any of the SFN cycles within the period, which may be in addition to the PFs and POs in the scheduled SFN cycle. During the period of the Busy Monitoring Window, such as at 716, 718, and/or 720,WTRU 708 may perform the monitoring and reception of the scheduled network paging or signaling in any SFN cycle during the period in the PFs and POs configured bynetwork 702 in terms of “paging” and signaling. - To assist this busy compensation method,
network 702 may storeinformation regarding WTRU 708 its associated adjustment-window length in an MME when the long sleep DRX or sleep is configured. For example, when a WTRU may be configured for long sleep, the network may save a copy of WTRU information and the adjustment-window-length in the MME node. This WTRU information may be used by the network to provide the busy window to the WTRU. - The WTRU may flag this long sleep nature of the operation and the possible clock drift rate related indication to the network when the WTRU registers with the network.
- Network assisted SFN cycle adjustment methods may be provided. The network may provide information that may assist a WTRU that may have woken-up to self-adjust to the scheduled SFN cycle for the network paging or signaling.
- The network may publish a SFN cycle order number within the Total-DRX-Definition-Period in the system information. This may be done, for example, so that when the long sleep WTRU wakes up, it may use the network published SFN cycle order number to align its own SFN cycle to the network SFN cycle number. The WTRU may then perform the monitoring of the PFs and POs in the right SFN cycle for the network paging or signaling.
- The network may provide the current count-number/order-number of the SFN cycle (e.g. the 15th or the 234th SFN cycle within the Total-DRX-Definition-Period) to the public or to the MTC devices. When the long sleep WTRU wakes up, it may use the SFN cycle count-number/order-number from the system information to adjust its number/order of the SFN cycle with the systems. This count-number/order-number quantity in the system may take a log2(SCNinTotalDRXDefinitionPeriod) bit quantity in the SIB space, e.g. 18 bit for a wrap-around period in 31 days. Depending on the space the SCN order number may take and the urgency of WTRU realignment to the order of the SFN cycle, the system may publish it eight to sixteen times per SFN cycle evenly distributed.
- Another method may be to have the system indicate a local SFN cycle (from 0 to 2n−1) order number it may be in (where n=1 or 2 or 3) to help the WTRU that may have woken up to figure out the SFN cycle number so as to tolerate the drift of 1, 2 and 4 SFN cycles. For example, if the WTRU may wake up at the SFN-0 of the beginning of
SFN cycle 0 and let n=1, the network indication (which may be a SIB bit) of the SFN cycle order may be an alternating 0 and 1. -
FIG. 8 depicts local SFNcycle order number FIG. 8 shows adrift range 0 case at 802 that with a 0 on theSFN cycle 0 at 804, a 1 onSFN cycle 1 at 808, and a 1 on SFN cycle −1 at 806. If the WTRU wakes up and sees the network indicating a local-SFN cycle order value of 1, it may know it may be in the previous cycle, such as the SFN cycle −1 at 806. This may not becycle 1 at 808, becausecycle 1 at 808 may be beyond the basic clock drifting range assumption of no greater than ±1 SFN cycle. -
FIG. 9 depicts local SFNcycle order number FIG. 9 , usingSFN 0 at SFN cycle 0 (shown at 902) as the reference wake-up time, a WTRU may see the local-SFNcycle order value cycle order value - A system may provide time information. The network system or the eNB may provide the time+n-SFN cycle based long DRX cycle adjustment information to a MTC WTRU. For example, the eNB may provide SIB-8 or an equivalent for the time information. The eNB may provide the Nth SFN cycle order number in the intervals of a day or a half day or a time interval, such as a hour, minute, or the like via SIB or a message. A NAS may provide a universal time and a local time zone to a MTC device when the MTC device may access the network, such as a periodic TAU. A network may reuse EPS mobility management (EMM) information message or may include the universal time information element (IE) in the TAU accept message or other NAS message. The WTRU may obtain the time information using any of the methods described herein
- A WTRU may perform autonomous synchronization of SFN and/or SFN cycle. A SFN Sync Timer may also be pre-configured in a WTRU. The timer may be a configured fixed value or the timer value may be adjusted with respect to the cycle end based on previous measurement. When the timer expires, the WTRU may wake up, read and align the SFN, and may align the SFN cycle with the network.
- The timer may be counting the SFN cycles; the value of the timer may be the integer times of SFN cycle. The value of the timer may ensure that the timing drift in the WTRU may not be greater than 512 radio frames before the timer expires. However, the timer may also be configured to stop at the turn of the SFN cycles (i.e. SFN=0), or stop in the middle of a SFN cycle or any other frame number within a SFN cycle.
- If the SFN Sync timer for the WTRU expires (i.e. the WTRU “wakes up”), the SFN sync timer may be reset and restarted again at the SFN cycle boundary after WTRU goes back to sleep.
- If the WTRU clock and the network clock may not or may not be estimated to drift apart beyond plus/minus 512 SFNs (±5.12 seconds), the MTC WTRU may resynchronize with the network by itself.
- Self-recovery schemes described herein may be used if the estimated drift, or the computed adjustment window show that the clock drift may be within half (512 SFNs) of the SFN cycle.
-
FIG. 10 depicts WTRU clock realignment. At 1001, a WTRU may be scheduled during long DRX cycle 1006 to wake up in the middle of a SFN cycle, such as at SFN cycle −1 at 1002, which may be between frame number (FN) 500 toFN 524. This may be prior toSFN cycle 0 at 1004 where the network may be scheduled to send paging or signaling to the WTRU in the early half of the SFN cycle. The WTRU may align itself (its clocking) with the network on the LTE frame numbers via MIB and SIB acquisition. The WTRU may get ready to monitor/receive the network paging in the next SFN cycle (SFN cycle 0) on the PFs and POs scheduled and configured. -
FIG. 11 depicts another WTRU clock realignment. At 1100, a WTRU may be scheduled to wake up at the end oflong DRX cycle 1102 to the SFN cycle (SFN cycle 0, SFN=0). The network may be scheduled to send paging or signaling to the WTRU in the latter half of the SFN cycle at 1104. When the sync timer expires and the WTRU may the network SFN, the SFN cycle may be aligned by comparing the stored SFN (=0) on the WTRU with the derived network SFN. If the derived SFN>=512, then the SFN cycle for the WTRU may fall in the previous SFN cycle (SFN cycle −1) for the network, such as at 1106. If the derived SFN<=512, then the WTRU and the network may be in the same SFN cycle (SFN cycle 0), at 1108. The WTRU may be able to adjust or confirm its SFN cycle and the LTE frame number, and may be ready to monitor/receive the network paging/signaling at the scheduled PF and PO. - Network paging coordination may be performed with respect to the receiving window. Upon the start of the receiving window (i.e. wake-up from the long sleep), the WTRU may follow camping procedures and may start monitoring the paging channel discontinuously. The paging cycle during the period of the receiving window may be the normal default paging cycle, or it may be the WTRU specific paging cycle. The paging occasion may be calculated.
- If the network has a paging message waiting for the UE, it may delay the transmission of the paging message until the WTRU may be within the receiving window. The calculated start of the receiving window for the WTRU at the network side may not be exactly aligned with the start of the receiving window for the WTRU at the WTRU side due to the clock shift. By implementation, the network may start transmission in advance to the start of window and may extend the length of the window to make the paging delivery more reliable.
- A network system may keep alive time. The system may depend on periodic TAU to know whether the concerned device may still be up to its designated or prescribed functions or technically alive. To preserve the keep-alive-time in the network system while implementing a long DRX cycle scheme, the longest periodic TAU timer may be longer than the longest long DRX cycle, for example, twice as long.
- The MTC WTRU configured with the long DRX cycle may use the wake up time to perform the periodic TAU if the long periodic TAU timer expires between two scheduled wake-up times with one long DRX cycle.
- Those MTC WTRUs that may usually be offline with the long DRX cycle may register or attach themselves with a flag that may indicate their long-dormant operational nature. The network system may then not rely on the periodic TAU to maintain their functional status. The monitoring of those MTC WTRUs may be the responsibility of the MTC-server or the relevant MTC-applications.
- A MTC WTRU may have multiple applications running and a MTC server may know the status of those applications. The network or the MTC server may configure the MTC WTRU to report the status of a configured application. The report may be done in several ways. The MTC WTRU may report application status directly to MTC server on a PDN connection. The MTC WTRU may report application status using SMS. MTC application status may be combined with alive time method and the MTC application status may be attached in the NAS message. After receiving the MTC WTRU application status via a NAS message, a MME may forward the status report to MTC server. The MTC device may report application status by synchronizing its time with network when it access to the network.
- A WTRU may be provided. The WTRU may include a processor that may be configured to perform a number of actions. For example, the processor may be configured to determine a cycle base unit type and a length of a long discontinuous reception (DRX) cycle. A number of base units of the cycle base unit type may be generated using the length of the long DRX cycle. The cycle base unit type may be an extended subframe number (SFN) cycle type, a time unit type, or the like.
- The processor may be configured to generate the number of base units of the cycle base unit type using the length of the long DRX cycle in a number of ways. For example, the processor may determine n number of SFN cycles to be used for an extended SFN cycle type base unit. A number of extended SFN cycles to make up the length of the long DRX cycle may be generated. Each extended SFN cycle in the number of extended SFN cycles may include n SFN cycles. As another example, the processor may determine a length of time for the time unit type. A number of time units to make up the length of the long DRX cycle may be determined. The number of time units may be generated. Each time unit in the number of time units may include the length of time for the time unit type.
- A long DRX cycle may be generated from the number of base units. For example, the long DRX cycle may be generated from the number of base units by generating the long DRX cycle from the number of extended SFN cycles.
- A WTRU may be provided for determining when to receive a signal. The WTRU may include a processor that may be configured to perform a number of actions. For example, the processor may be configured to determine a system frame number cycle number (SCN) within a total DRX period. A long DRX cycle length may be determined. An offset SCN may be generated using the SCN and the long DRX cycle length. A page timing may be determined using the offset SCN. A paging signal may be received from a network using the page timing. A number of short DRX cycles may be determined to be used to receive the paging signal.
- A long DRX cycle may be scheduled using the offset SCN and the long DRX cycle length. For example, the number of short DRX cycles may be scheduled within the long DRX cycle using the short DRX cycle length, before the long DRX cycle using the short DRX cycle length, after the long DRX cycle using the short DRX cycle length, or the like.
- A number of short cycles may be scheduled and may be used to receive the paging signal. For example, a first long DRX cycle and a second long DRX cycle may be scheduled using the offset SCN and the long DRX cycle length. The number of short DRX cycles may be scheduled between the first long DRX cycle and the second long DRX cycle.
- A WTRU for minimizing clock drift impact may be provided. The WTRU may include a processor that may be configured to perform a number of actions. For example, the processor may be configured to determine a long sleep length, a clock drift rate for the WTRU, and a wake-up time. An adjustment window may be generated using the long sleep length, the clock drift rate, and the wake-up time. A clock drift direction may be determined A signal maybe received from a network using the adjustment window.
- The processor may be configured to generate the adjustment window using the long sleep length, the clock drift rate, and the wake-up time. For example, the processor may determine the adjustment window using the long sleep length. The adjustment window may be scheduled using the wake-up time. The adjustment window may be adjusted using the clock drift rate such that a signal may be received from a network during the adjustment window.
- As another example, the processor may be configured schedule the adjustment window using the wake-up time. A length of the adjustment window may be decreased using the clock drift rate when the clock drift direction indicates that a clock is drifting towards longer time. A length of the adjustment window may be increased using the clock drift rate when the clock drift direction indicates that a clock is drifting towards shorter time.
- A WTRU may be provided to adjust a SFN cycle using assistance from a network. The WTRU may include a processor. The processor may be configured to receive a first system frame number (SFN) cycle order number from a network. The first SNF cycle order number may be received from the network via a system information. A second SFN cycle order number may be determined A drift range may be calculated using the first SFN cycle order number and the second SFN cycle order number. The drift range may be used to receive a signal from the network. For example, the processor may be configured to receive a signal from the network in a next SFN cycle when the drift range indicates the network is scheduled to transmit the signal in the next SFN cycle.
- The processor may be configured to align a local SFN cycle number with the first SFN cycle order number when the drift range indicates that first SFN cycle order number and the second SFN cycle order number may not be aligned. The aligned SFN cycle number may be used to receive a signal from the network using the aligned SFN cycle number.
- Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.
Claims (25)
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/829,642 US20130301501A1 (en) | 2012-05-09 | 2013-03-14 | Methods and apparatus for handling mtc long drx cycle/sleep lengths |
US16/010,759 US11032870B2 (en) | 2012-05-09 | 2018-06-18 | Methods and apparatus for handling MTC long DRX cycle/sleep lengths |
US17/246,199 US11856639B2 (en) | 2012-05-09 | 2021-04-30 | Methods and apparatus for handling MTC long DRX cycle/sleep lengths |
US18/493,890 US20240057214A1 (en) | 2012-05-09 | 2023-10-25 | Methods and Apparatus for Handling MTC Long DRX Cycle/Sleep Lengths |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201261644922P | 2012-05-09 | 2012-05-09 | |
US201261653706P | 2012-05-31 | 2012-05-31 | |
US13/829,642 US20130301501A1 (en) | 2012-05-09 | 2013-03-14 | Methods and apparatus for handling mtc long drx cycle/sleep lengths |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/010,759 Continuation US11032870B2 (en) | 2012-05-09 | 2018-06-18 | Methods and apparatus for handling MTC long DRX cycle/sleep lengths |
Publications (1)
Publication Number | Publication Date |
---|---|
US20130301501A1 true US20130301501A1 (en) | 2013-11-14 |
Family
ID=48045734
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/829,642 Abandoned US20130301501A1 (en) | 2012-05-09 | 2013-03-14 | Methods and apparatus for handling mtc long drx cycle/sleep lengths |
US16/010,759 Active US11032870B2 (en) | 2012-05-09 | 2018-06-18 | Methods and apparatus for handling MTC long DRX cycle/sleep lengths |
US17/246,199 Active 2033-04-12 US11856639B2 (en) | 2012-05-09 | 2021-04-30 | Methods and apparatus for handling MTC long DRX cycle/sleep lengths |
US18/493,890 Pending US20240057214A1 (en) | 2012-05-09 | 2023-10-25 | Methods and Apparatus for Handling MTC Long DRX Cycle/Sleep Lengths |
Family Applications After (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/010,759 Active US11032870B2 (en) | 2012-05-09 | 2018-06-18 | Methods and apparatus for handling MTC long DRX cycle/sleep lengths |
US17/246,199 Active 2033-04-12 US11856639B2 (en) | 2012-05-09 | 2021-04-30 | Methods and apparatus for handling MTC long DRX cycle/sleep lengths |
US18/493,890 Pending US20240057214A1 (en) | 2012-05-09 | 2023-10-25 | Methods and Apparatus for Handling MTC Long DRX Cycle/Sleep Lengths |
Country Status (5)
Country | Link |
---|---|
US (4) | US20130301501A1 (en) |
EP (2) | EP2848081A1 (en) |
CN (2) | CN110602669B (en) |
TW (2) | TWI685234B (en) |
WO (1) | WO2013169376A1 (en) |
Cited By (94)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120300655A1 (en) * | 2010-02-09 | 2012-11-29 | Young Dae Lee | Method of receiving and transmitting message in a mobile communication system using a mtc device and apparatus for the same |
US20130044761A1 (en) * | 2011-08-17 | 2013-02-21 | Teemu Koponen | Hierarchical controller clusters for interconnecting two or more logical datapath sets |
US20130250783A1 (en) * | 2012-03-26 | 2013-09-26 | Harris Corporation | Systems and methods registration and maintenance of wireless clients via a proxy wireless network service |
US20140119258A1 (en) * | 2011-09-01 | 2014-05-01 | Sony Corporation | Communication device, communication method, communication system, and base station |
WO2014070077A1 (en) * | 2012-10-29 | 2014-05-08 | Telefonaktiebolaget L M Ericsson (Publ) | Wake-up for measurements during drx cycles |
US20140323165A1 (en) * | 2013-04-29 | 2014-10-30 | Telefonaktiebolaget L M Ericsson (Publ) | Extended monitoring window for robust paging |
US20140321343A1 (en) * | 2013-04-26 | 2014-10-30 | Maruti Gupta | User equipment and methods for adapting system parameters based on extended paging cycles |
US20150098381A1 (en) * | 2013-10-08 | 2015-04-09 | Luis Cucala García | Method, system and devices for improving discontinous reception in wireless communication networks |
US20150282208A1 (en) * | 2012-11-01 | 2015-10-01 | Lg Electronics Inc. | Method and apparatus for supporting scheduling groups of devices characteristics in a wireless communication system |
WO2015148128A1 (en) * | 2014-03-27 | 2015-10-01 | Qualcomm Incorporated | Methods and apparatus for low power tracking of network system timing for long paging cycles |
US20150296434A1 (en) * | 2014-04-15 | 2015-10-15 | Qualcomm Incorporated | Systems, methods and apparatus for optimizing machine to machine device performance by dynamically varying slot cycle index |
US20150312351A1 (en) * | 2014-04-24 | 2015-10-29 | Alcatel Lucent | Method, device and system for device trigger in iot |
WO2015177774A1 (en) * | 2014-05-22 | 2015-11-26 | Telefonaktiebolaget L M Ericsson (Publ) | Optimized synchronization procedure for prolonged periods of sleep |
KR20160002240A (en) * | 2014-06-30 | 2016-01-07 | 삼성전자주식회사 | Method and apparatus for optimizing communications of low power devices |
US20160029344A1 (en) * | 2013-04-04 | 2016-01-28 | Rath Vannithamby | Paging repetition for increased robustness for extended paging cycles |
US20160044605A1 (en) * | 2014-08-06 | 2016-02-11 | Qualcomm Incorporated | Ran procedures for extended discontinuous reception (drx) |
CN105338008A (en) * | 2014-06-10 | 2016-02-17 | 阿尔卡特朗讯 | Equipment scheduling method, device and system for internet of things |
US20160050624A1 (en) * | 2013-04-12 | 2016-02-18 | Telefonaktiebolaget L M Ericsson (Publ) | System frame number synchronization |
US20160057701A1 (en) * | 2013-03-29 | 2016-02-25 | Intel IP Corporation | Extended paging discontinuous reception (drx) cycles in wireless communication networks |
WO2016055086A1 (en) * | 2014-10-06 | 2016-04-14 | Nokia Solutions And Networks Oy | High latency communication |
US20160105365A1 (en) * | 2014-10-13 | 2016-04-14 | General Motors Llc | Network-coordinated drx transmission reduction for a network access device of a telematics-equipped vehicle |
US20160112948A1 (en) * | 2013-04-02 | 2016-04-21 | China Academy Of Telecommunications Technology | Method and device for computing activation time |
US9351251B2 (en) | 2013-08-22 | 2016-05-24 | Telefonaktiebolaget Lm Ericsson (Publ) | Mobile station, core network node, base station subsystem, and methods for implementing longer paging cycles in a cellular network |
US20160192323A1 (en) * | 2013-08-02 | 2016-06-30 | Samsung Electronics Co., Ltd. | Method and apparatus for receiving system information and paging in mobile communication system |
US9398634B2 (en) | 2013-08-22 | 2016-07-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Mobile station, core network node, base station subsystem, and methods for implementing longer paging cycles in a cellular network |
WO2016114698A1 (en) * | 2015-01-16 | 2016-07-21 | Telefonaktiebolaget Lm Ericsson (Publ) | A wireless communication device, a core network node and methods therein, for extended drx paging cycle |
US20160211986A1 (en) * | 2015-01-16 | 2016-07-21 | Telefonaktiebolaget Lm Ericsson (Publ) | EXTENDED DISCONTINUOUS RECEIVE (eDRX) CYCLES |
WO2016148816A1 (en) * | 2015-03-15 | 2016-09-22 | Qualcomm Incorporated | On-demand paging indicator |
WO2016178756A1 (en) * | 2015-05-04 | 2016-11-10 | Qualcomm Incorporated | Techniques for paging in extended discontinuous reception |
WO2016182498A1 (en) * | 2015-05-13 | 2016-11-17 | Telefonaktiebolaget Lm Ericsson (Publ) | Paging coordination between wireless communication device and core network node |
US20160337061A1 (en) * | 2015-05-13 | 2016-11-17 | Qualcomm Incorporated | Access point synchronization in shared spectrum |
GB2541009A (en) * | 2015-08-05 | 2017-02-08 | Samsung Electronics Co Ltd | Power saving for cellular internet of things devices |
US20170099649A1 (en) * | 2015-10-02 | 2017-04-06 | Sierra Wireless, Inc. | Method and system for paging user equipment |
US9706373B1 (en) * | 2014-09-09 | 2017-07-11 | Amazon Technologies, Inc. | Message delivery acknowledgment |
JP2017523723A (en) * | 2014-08-06 | 2017-08-17 | クゥアルコム・インコーポレイテッドQualcomm Incorporated | Improved idle mode for extended idle intermittent reception |
US9743268B2 (en) | 2013-03-29 | 2017-08-22 | Intel IP Corporation | Control of WLAN selection policies in roaming scenarios |
CN107113716A (en) * | 2015-04-03 | 2017-08-29 | 株式会社Ntt都科摩 | Base station and user's set |
CN107197508A (en) * | 2017-05-17 | 2017-09-22 | 电子科技大学 | A kind of device sleeps method based on CSM mechanism DRX |
JP2017529020A (en) * | 2014-09-29 | 2017-09-28 | コンヴィーダ ワイヤレス, エルエルシー | Service capability server / EPC coordination for power saving mode and paging |
JP2017529763A (en) * | 2014-08-11 | 2017-10-05 | エルジー エレクトロニクス インコーポレイティド | Method and apparatus for terminal proximity monitoring in a wireless communication system |
US20170325194A1 (en) * | 2013-05-03 | 2017-11-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Paging for longer paging cycles |
CN107432048A (en) * | 2015-04-10 | 2017-12-01 | 英特尔公司 | Discontinuous reception (DRX) under device ready state |
CN107637163A (en) * | 2015-04-05 | 2018-01-26 | Lg电子株式会社 | For adjusting the method and its equipment of tracking area update timing in a wireless communication system |
US9900928B2 (en) | 2013-04-05 | 2018-02-20 | Telefonaktiebolaget Lm Ericsson (Publ) | User equipment, network node, and methods for managing an extended discontinuous reception cycle mode |
US20180070406A1 (en) * | 2016-09-02 | 2018-03-08 | Qualcomm Incorporated | Enhanced discontinuous reception management in wireless communication systems |
US20180213431A1 (en) * | 2015-08-05 | 2018-07-26 | Nec Corporation | Communication system, communication control apparatus, communication control method, and program |
US20180227981A1 (en) * | 2016-05-16 | 2018-08-09 | Ntt Docomo, Inc. | Switching equipment, control server, and communication method |
US10123320B2 (en) * | 2012-05-21 | 2018-11-06 | Sony Corporation | System, method and base station for allocating resources in a plurality of subframes |
US10129865B2 (en) * | 2012-05-21 | 2018-11-13 | Sony Corporation | Method and terminal device for allocating resources in a plurality of subframes |
EP3391696A4 (en) * | 2015-12-16 | 2018-12-12 | Telefonaktiebolaget LM Ericsson (publ) | Paging a wireless device |
US10172183B2 (en) | 2015-05-19 | 2019-01-01 | Telefonaktiebolaget Lm Ericsson (Publ) | Radio access network node and method—time coordinated cells for extended discontinuous receive (eDRX) |
US10172112B2 (en) | 2015-05-19 | 2019-01-01 | Telefonaktiebolaget Lm Ericsson (Publ) | Core network node and method—time coordinated cells for extended discontinuous receive (eDRX) |
WO2019010089A1 (en) * | 2017-07-06 | 2019-01-10 | Qualcomm Incorporated | Techniques and apparatuses for configuring an extended discontinuous reception cycle |
US20190045447A1 (en) * | 2017-08-04 | 2019-02-07 | Apple Inc. | MicroSleep for Machine-type Communication Devices |
US20190053192A1 (en) * | 2016-07-22 | 2019-02-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Tracking Area Code Allocation |
CN109462839A (en) * | 2018-11-26 | 2019-03-12 | 电子科技大学 | A kind of DRX mechanism communication means based on adaptive re-configuration police |
US10250647B2 (en) * | 2013-05-06 | 2019-04-02 | Convida Wireless, Llc | Device triggering |
US10382256B2 (en) * | 2015-11-20 | 2019-08-13 | Geotab Inc. | Big telematics data network communication fault identification device |
US10470077B1 (en) | 2018-06-08 | 2019-11-05 | At&T Intellectual Property I, L.P. | Messaging centers with rule based adaptive retry profiles for 5G or other next generation network |
US10536891B1 (en) * | 2018-06-29 | 2020-01-14 | Texas Instruments Incorporated | Using estimated time drift to determine keep alive periodicity in synchronized networks |
US10587389B2 (en) | 2013-01-03 | 2020-03-10 | Apple Inc. | Apparatus and method for single-tone device discovery in wireless communication networks |
US10602447B2 (en) * | 2013-05-10 | 2020-03-24 | Hfi Innovation Inc. | Long paging cycle and paging enhancement for power saving LTE devices |
CN110999413A (en) * | 2017-08-11 | 2020-04-10 | 鸿颖创新有限公司 | Apparatus and method for discontinuous reception in new radio |
US10667213B2 (en) | 2015-08-05 | 2020-05-26 | Samsung Electronics Co., Ltd. | Apparatus and method for power saving for cellular internet of things devices |
US10687308B2 (en) | 2016-03-24 | 2020-06-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Core network node and methods for determining reachability of wireless devices in extended discontinuous receive (eDRX) operation |
US10694462B2 (en) | 2015-05-19 | 2020-06-23 | Huawei Technologies Co., Ltd. | Downlink scheduling data monitoring method, downlink scheduling data sending method, and apparatus |
EP3677085A1 (en) * | 2017-09-01 | 2020-07-08 | QUALCOMM Incorporated | Methods, apparatuses and systems for supporting long term channel sensing in shared spectrum |
US10979977B2 (en) * | 2012-07-11 | 2021-04-13 | Blackberry Limited | Mechanisms to support UE power preference signaling |
WO2021087310A1 (en) * | 2019-10-31 | 2021-05-06 | Itron, Inc. | Downlink event allocation in a network |
US11025446B2 (en) | 2015-06-15 | 2021-06-01 | Samsung Electronics Co., Ltd. | Method and apparatus for group communication in wireless communication system |
US11050705B2 (en) | 2017-03-20 | 2021-06-29 | At&T Intellectual Property I, L.P. | Signaling optimization during short messaging for internet of things devices in a mobility network |
US20210227497A1 (en) * | 2016-04-05 | 2021-07-22 | Sony Group Corporation | Method and device for paging a machine to machine device |
US11076440B2 (en) | 2014-05-28 | 2021-07-27 | Qualcomm Incorporated | Methods and apparatus for reducing collisions between CDRX and paging operations |
US11088902B1 (en) | 2020-04-06 | 2021-08-10 | Vmware, Inc. | Synchronization of logical network state between global and local managers |
US11088916B1 (en) | 2020-04-06 | 2021-08-10 | Vmware, Inc. | Parsing logical network definition for different sites |
US11088919B1 (en) | 2020-04-06 | 2021-08-10 | Vmware, Inc. | Data structure for defining multi-site logical network |
US11132246B2 (en) | 2015-11-20 | 2021-09-28 | Geotab Inc. | Big telematics data network communication fault identification system |
US11140631B2 (en) | 2015-11-20 | 2021-10-05 | Geotab Inc. | Big telematics data network communication fault identification system method |
JP2021170825A (en) * | 2013-11-29 | 2021-10-28 | 日本電気株式会社 | Network node, ue, base station, and communication method thereof |
US11212746B2 (en) | 2015-11-20 | 2021-12-28 | Geotab Inc. | Big telematics data network communication fault identification method |
US11223518B2 (en) | 2015-11-20 | 2022-01-11 | Geotab Inc. | Big telematics data network communication fault identification device |
CN113938995A (en) * | 2020-07-14 | 2022-01-14 | 华为技术有限公司 | Communication method and device |
US11228979B2 (en) * | 2018-09-20 | 2022-01-18 | Mediatek Singapore Pte. Ltd. | Method and apparatus for reducing power consumption with wake-up mechanism in mobile communications |
US20220030547A1 (en) * | 2017-08-15 | 2022-01-27 | Huawei Technologies Co., Ltd. | Communications Method and Apparatus |
US11259358B2 (en) | 2017-03-23 | 2022-02-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and device for determining timer configuration |
US11303557B2 (en) | 2020-04-06 | 2022-04-12 | Vmware, Inc. | Tunnel endpoint group records for inter-datacenter traffic |
US11317364B2 (en) | 2017-02-13 | 2022-04-26 | Telefonaktiebolaget Lm Ericsson (Publ) | Synchronization for extended DRX |
US11343227B2 (en) | 2020-09-28 | 2022-05-24 | Vmware, Inc. | Application deployment in multi-site virtualization infrastructure |
CN114567920A (en) * | 2022-02-23 | 2022-05-31 | 重庆邮电大学 | Mixed discontinuous receiving method of strategy optimization MTC (machine type communication) equipment |
US11363532B2 (en) | 2019-10-31 | 2022-06-14 | Itron, Inc. | Downlink event allocation in a network |
US11438837B2 (en) | 2019-10-31 | 2022-09-06 | Itron, Inc. | Downlink event allocation in a network |
US11496392B2 (en) | 2015-06-27 | 2022-11-08 | Nicira, Inc. | Provisioning logical entities in a multidatacenter environment |
US11777793B2 (en) | 2020-04-06 | 2023-10-03 | Vmware, Inc. | Location criteria for security groups |
US12107722B2 (en) | 2022-07-20 | 2024-10-01 | VMware LLC | Sharing network manager between multiple tenants |
Families Citing this family (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104812031A (en) * | 2014-01-26 | 2015-07-29 | 中兴通讯股份有限公司 | Energy-saving method and energy-saving system of machine type communication (MTC) user equipment, user equipment and radio network controller (RNC) |
US10455544B2 (en) * | 2015-01-30 | 2019-10-22 | Qualcomm Incorporated | Enhanced paging procedures for machine type communications (MTC) |
WO2016122384A1 (en) * | 2015-01-30 | 2016-08-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Network node and method in a wireless telecommunications network |
US10085300B2 (en) * | 2015-02-16 | 2018-09-25 | Qualcomm Incorporated | Connected mode extended discontinuous reception |
CN108924913A (en) | 2017-03-31 | 2018-11-30 | 电信科学技术研究院 | A kind of information sends, channel-monitoring processing method and processing device |
US11252669B2 (en) * | 2018-07-25 | 2022-02-15 | Qualcomm Incorporated | Selective extension of an active period of a DRX cycle for reselection |
CN110958668B (en) * | 2018-09-27 | 2021-11-05 | 大唐移动通信设备有限公司 | Terminal state conversion method, network equipment and terminal |
CN113632585B (en) * | 2019-01-21 | 2024-09-17 | 上海诺基亚贝尔股份有限公司 | Discontinuous reception configuration for terminal equipment |
CN112399527A (en) | 2019-08-13 | 2021-02-23 | 苹果公司 | Notification support in extended discontinuous reception mode |
EP3876383A1 (en) | 2020-03-02 | 2021-09-08 | Nokia Technologies Oy | Data communications |
CN111787611B (en) * | 2020-06-23 | 2023-05-23 | 广东小天才科技有限公司 | Method for updating paging cycle, terminal equipment and network equipment |
US11812495B2 (en) * | 2021-04-09 | 2023-11-07 | Qualcomm Incorporated | Discontinuous reception short cadence |
US11722961B2 (en) * | 2021-04-09 | 2023-08-08 | Qualcomm Incorporated | Discontinuous reception short cadence |
US20230318680A1 (en) * | 2022-03-31 | 2023-10-05 | Qualcomm Incorporated | Enhanced ue behavior for bfd/bfr in drx mode |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100272004A1 (en) * | 2007-12-17 | 2010-10-28 | Mitsubishi Electric Corporation | Mobile communication system |
US20120082077A1 (en) * | 2010-10-01 | 2012-04-05 | Yujian Zhang | Apparatus and methods of time domain multiplexing solutions for in-device coexistence |
US20120269173A1 (en) * | 2009-11-13 | 2012-10-25 | Qualcomm Incorporated | Method and Apparatus for Resolving Paging Monitoring Conflicts in Multimode Wireless Equipment |
US20120300685A1 (en) * | 2010-01-12 | 2012-11-29 | Samsung Electronics Co. Ltd. | Method and apparatus for supporting discontinuous reception operation in mobile communication system |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7760676B2 (en) | 2006-06-20 | 2010-07-20 | Intel Corporation | Adaptive DRX cycle length based on available battery power |
TWI467964B (en) * | 2006-09-15 | 2015-01-01 | Qualcomm Inc | Methods and apparatus for establishing communications between devices with differing capabilities |
MX2009010693A (en) * | 2007-05-23 | 2009-10-20 | Ericsson Telefon Ab L M | Method and arrangement for reducing battery power consumption of a user equipment. |
CN102098783B (en) * | 2007-12-03 | 2012-12-12 | 华为技术有限公司 | Equipment for determining paging moment |
CN101453788B (en) * | 2007-12-03 | 2011-04-06 | 华为技术有限公司 | Method for determining paging time |
US20090275368A1 (en) * | 2008-05-01 | 2009-11-05 | Interdigital Patent Holdings, Inc. | Method and apparatus for distributing paging load in long term evolution |
US8595486B2 (en) | 2008-07-15 | 2013-11-26 | Industrial Technology Research Institute | Systems and methods for authorization and data transmission for multicast broadcast services |
US8971933B2 (en) * | 2008-11-18 | 2015-03-03 | Qualcomm Incorporated | Method and apparatus for determining DRX cycle used for paging |
WO2011087233A2 (en) * | 2010-01-12 | 2011-07-21 | Samsung Electronics Co., Ltd. | Method and apparatus for supporting discontinuous reception operation in mobile communication system |
JP2012010202A (en) * | 2010-06-25 | 2012-01-12 | Sony Corp | Communication apparatus and communication method, and communication system |
CN102421148B (en) | 2010-09-28 | 2016-03-30 | 华为技术有限公司 | A kind of method and subscriber equipment controlling plurality of communication systems realization communication |
CN102257859B (en) * | 2011-06-01 | 2013-08-07 | 华为技术有限公司 | Mixing nocontinuous receiving method, base station and user equipment |
KR101800700B1 (en) * | 2011-07-27 | 2017-11-24 | 삼성전자주식회사 | Mobile communication system and method for managing of terminal paging thereof |
GB2483752A (en) * | 2011-08-16 | 2012-03-21 | Renesas Mobile Corp | Extended drx time periods for machine-type communications using an absolute timing reference |
US8467813B2 (en) * | 2011-11-01 | 2013-06-18 | Mediatek Inc. | Method for monitoring a paging message without paging lost and communication apparatuses utilizing the same |
WO2013110284A1 (en) * | 2012-01-23 | 2013-08-01 | Deutsche Telekom Ag | Method for using a user equipment with a first public land mobile network and with a second public land mobile network, user equipment, program and computer program product |
CN104350795B (en) * | 2012-04-05 | 2019-02-01 | 奥普蒂斯蜂窝技术有限责任公司 | Paging information is transferred to the method and related device of terminal installation from mobile network |
-
2013
- 2013-03-14 EP EP13714109.9A patent/EP2848081A1/en not_active Withdrawn
- 2013-03-14 CN CN201910888422.XA patent/CN110602669B/en active Active
- 2013-03-14 WO PCT/US2013/031696 patent/WO2013169376A1/en active Application Filing
- 2013-03-14 US US13/829,642 patent/US20130301501A1/en not_active Abandoned
- 2013-03-14 CN CN201380024141.0A patent/CN104303586B/en active Active
- 2013-03-14 EP EP20180098.4A patent/EP3735007B1/en active Active
- 2013-03-15 TW TW102109254A patent/TWI685234B/en active
- 2013-03-15 TW TW108148726A patent/TWI744762B/en active
-
2018
- 2018-06-18 US US16/010,759 patent/US11032870B2/en active Active
-
2021
- 2021-04-30 US US17/246,199 patent/US11856639B2/en active Active
-
2023
- 2023-10-25 US US18/493,890 patent/US20240057214A1/en active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100272004A1 (en) * | 2007-12-17 | 2010-10-28 | Mitsubishi Electric Corporation | Mobile communication system |
US20120269173A1 (en) * | 2009-11-13 | 2012-10-25 | Qualcomm Incorporated | Method and Apparatus for Resolving Paging Monitoring Conflicts in Multimode Wireless Equipment |
US20120300685A1 (en) * | 2010-01-12 | 2012-11-29 | Samsung Electronics Co. Ltd. | Method and apparatus for supporting discontinuous reception operation in mobile communication system |
US20120082077A1 (en) * | 2010-10-01 | 2012-04-05 | Yujian Zhang | Apparatus and methods of time domain multiplexing solutions for in-device coexistence |
Cited By (213)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8953477B2 (en) * | 2010-02-09 | 2015-02-10 | Lg Electronics Inc. | Method of receiving and transmitting message in a mobile communication system using a MTC device and apparatus for the same |
US20120300655A1 (en) * | 2010-02-09 | 2012-11-29 | Young Dae Lee | Method of receiving and transmitting message in a mobile communication system using a mtc device and apparatus for the same |
US10091028B2 (en) * | 2011-08-17 | 2018-10-02 | Nicira, Inc. | Hierarchical controller clusters for interconnecting two or more logical datapath sets |
US20130044761A1 (en) * | 2011-08-17 | 2013-02-21 | Teemu Koponen | Hierarchical controller clusters for interconnecting two or more logical datapath sets |
US10931481B2 (en) | 2011-08-17 | 2021-02-23 | Nicira, Inc. | Multi-domain interconnect |
US10193708B2 (en) | 2011-08-17 | 2019-01-29 | Nicira, Inc. | Multi-domain interconnect |
US11804987B2 (en) | 2011-08-17 | 2023-10-31 | Nicira, Inc. | Flow generation from second level controller to first level controller to managed switching element |
US20140119258A1 (en) * | 2011-09-01 | 2014-05-01 | Sony Corporation | Communication device, communication method, communication system, and base station |
US9585096B2 (en) * | 2011-09-01 | 2017-02-28 | Sony Corporation | Communication device, communication method, communication system, and base system |
US9363751B2 (en) * | 2011-09-01 | 2016-06-07 | Sony Corporation | Communication device, communication method, communication system, and base station |
US20130250783A1 (en) * | 2012-03-26 | 2013-09-26 | Harris Corporation | Systems and methods registration and maintenance of wireless clients via a proxy wireless network service |
US9295020B2 (en) * | 2012-03-26 | 2016-03-22 | Harris Corporation | Systems and methods registration and maintenance of wireless clients via a proxy wireless network service |
US10129865B2 (en) * | 2012-05-21 | 2018-11-13 | Sony Corporation | Method and terminal device for allocating resources in a plurality of subframes |
US10582488B2 (en) * | 2012-05-21 | 2020-03-03 | Sony Corporation | Method and terminal device for allocating resources in a plurality of subframes |
US11102772B2 (en) | 2012-05-21 | 2021-08-24 | Sony Corporation | Method and terminal device for allocating resources in a plurality of subframes |
US10123320B2 (en) * | 2012-05-21 | 2018-11-06 | Sony Corporation | System, method and base station for allocating resources in a plurality of subframes |
US10979977B2 (en) * | 2012-07-11 | 2021-04-13 | Blackberry Limited | Mechanisms to support UE power preference signaling |
US10051565B2 (en) | 2012-10-29 | 2018-08-14 | Telefonaktiebolaget L M Ericsson (Publ) | Wake-up for measurements during DRX cycles |
WO2014070077A1 (en) * | 2012-10-29 | 2014-05-08 | Telefonaktiebolaget L M Ericsson (Publ) | Wake-up for measurements during drx cycles |
US20150282208A1 (en) * | 2012-11-01 | 2015-10-01 | Lg Electronics Inc. | Method and apparatus for supporting scheduling groups of devices characteristics in a wireless communication system |
US9603163B2 (en) * | 2012-11-01 | 2017-03-21 | Lg Electronics Inc. | Method and apparatus for supporting scheduling groups of devices characteristics in a wireless communication system |
US10587389B2 (en) | 2013-01-03 | 2020-03-10 | Apple Inc. | Apparatus and method for single-tone device discovery in wireless communication networks |
US20160057701A1 (en) * | 2013-03-29 | 2016-02-25 | Intel IP Corporation | Extended paging discontinuous reception (drx) cycles in wireless communication networks |
US10470122B2 (en) | 2013-03-29 | 2019-11-05 | Intel IP Corporation | Extended paging discontinuous reception (DRX) cycles in wireless communication networks |
US9794876B2 (en) * | 2013-03-29 | 2017-10-17 | Intel IP Corporation | Extended paging discontinuous reception (DRX) cycles in wireless communication networks |
US9743268B2 (en) | 2013-03-29 | 2017-08-22 | Intel IP Corporation | Control of WLAN selection policies in roaming scenarios |
US9414306B2 (en) | 2013-03-29 | 2016-08-09 | Intel IP Corporation | Device-to-device (D2D) preamble design |
US10397866B2 (en) * | 2013-04-02 | 2019-08-27 | China Academy Of Telecommunications Technology | Method and device for computing activation time |
US20160112948A1 (en) * | 2013-04-02 | 2016-04-21 | China Academy Of Telecommunications Technology | Method and device for computing activation time |
US9930647B2 (en) | 2013-04-04 | 2018-03-27 | Intel IP Corporation | Enhanced node B and method for RRC connection establishment for small data transfers |
US20160029344A1 (en) * | 2013-04-04 | 2016-01-28 | Rath Vannithamby | Paging repetition for increased robustness for extended paging cycles |
US9763235B2 (en) * | 2013-04-04 | 2017-09-12 | Intel IP Corporation | Paging repetition for increased robustness for extended paging cycles |
US9900928B2 (en) | 2013-04-05 | 2018-02-20 | Telefonaktiebolaget Lm Ericsson (Publ) | User equipment, network node, and methods for managing an extended discontinuous reception cycle mode |
US20160050624A1 (en) * | 2013-04-12 | 2016-02-18 | Telefonaktiebolaget L M Ericsson (Publ) | System frame number synchronization |
US9294714B2 (en) * | 2013-04-26 | 2016-03-22 | Intel IP Corporation | User equipment and methods for adapting system parameters based on extended paging cycles |
US10420065B2 (en) | 2013-04-26 | 2019-09-17 | Intel IP Corporation | User equipment and methods for adapting system parameters based on extended paging cycles |
US20140321343A1 (en) * | 2013-04-26 | 2014-10-30 | Maruti Gupta | User equipment and methods for adapting system parameters based on extended paging cycles |
US9743380B2 (en) | 2013-04-26 | 2017-08-22 | Intel IP Corporation | MTSI based UE configurable for video region-of-interest (ROI) signaling |
US9288434B2 (en) | 2013-04-26 | 2016-03-15 | Intel IP Corporation | Apparatus and method for congestion control in wireless communication networks |
US9325937B2 (en) | 2013-04-26 | 2016-04-26 | Intel IP Corporation | Radio access technology information storage in a mobile network |
US9621845B2 (en) | 2013-04-26 | 2017-04-11 | Intel IP Corporation | Architecture for web-based real-time communications (WebRTC) to access internet protocol multimedia subsystem (IMS) |
US9392539B2 (en) | 2013-04-26 | 2016-07-12 | Intel IP Corporation | User equipment and method for feedback of user equipment performance metrics during dynamic radio switching |
US10225817B2 (en) | 2013-04-26 | 2019-03-05 | Intel IP Corporation | MTSI based UE configurable for video region-of-interest (ROI) signaling |
US9307192B2 (en) | 2013-04-26 | 2016-04-05 | Intel IP Corporation | Interactive zooming in video conferencing |
US20160249323A1 (en) * | 2013-04-29 | 2016-08-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Extended monitoring window for robust paging |
US9763224B2 (en) * | 2013-04-29 | 2017-09-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Extended monitoring window for robust paging |
US9338762B2 (en) * | 2013-04-29 | 2016-05-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Extended monitoring window for robust paging |
US20140323165A1 (en) * | 2013-04-29 | 2014-10-30 | Telefonaktiebolaget L M Ericsson (Publ) | Extended monitoring window for robust paging |
US10362558B2 (en) * | 2013-05-03 | 2019-07-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Paging for longer paging cycles |
US20170325194A1 (en) * | 2013-05-03 | 2017-11-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Paging for longer paging cycles |
US11444986B2 (en) | 2013-05-06 | 2022-09-13 | Convida Wireless, Llc | Device triggering |
US10250647B2 (en) * | 2013-05-06 | 2019-04-02 | Convida Wireless, Llc | Device triggering |
US10848526B2 (en) | 2013-05-06 | 2020-11-24 | Convida Wireless, Llc | Device triggering |
US10602447B2 (en) * | 2013-05-10 | 2020-03-24 | Hfi Innovation Inc. | Long paging cycle and paging enhancement for power saving LTE devices |
US10484962B2 (en) * | 2013-08-02 | 2019-11-19 | Samsung Electronics Co., Ltd | Method and apparatus for receiving system information and paging in mobile communication system |
US20160192323A1 (en) * | 2013-08-02 | 2016-06-30 | Samsung Electronics Co., Ltd. | Method and apparatus for receiving system information and paging in mobile communication system |
US9706494B2 (en) | 2013-08-22 | 2017-07-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Mobile station, core network node, base station subsystem, and methods for implementing longer paging cycles in a cellular network |
US10064135B2 (en) | 2013-08-22 | 2018-08-28 | Telefonaktiebolaget Lm Ericsson (Publ) | Mobile station, core network node, base station subsystem, and methods for implementing longer paging cycles in a cellular network |
US9398634B2 (en) | 2013-08-22 | 2016-07-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Mobile station, core network node, base station subsystem, and methods for implementing longer paging cycles in a cellular network |
US9351251B2 (en) | 2013-08-22 | 2016-05-24 | Telefonaktiebolaget Lm Ericsson (Publ) | Mobile station, core network node, base station subsystem, and methods for implementing longer paging cycles in a cellular network |
US20150098381A1 (en) * | 2013-10-08 | 2015-04-09 | Luis Cucala García | Method, system and devices for improving discontinous reception in wireless communication networks |
US9313736B2 (en) * | 2013-10-08 | 2016-04-12 | Telefonica, S.A. | Method, system and devices for improving discontinous reception in wireless communication networks |
US11856074B2 (en) | 2013-11-29 | 2023-12-26 | Nec Corporation | Apparatus, system and method for MTC |
JP2021170825A (en) * | 2013-11-29 | 2021-10-28 | 日本電気株式会社 | Network node, ue, base station, and communication method thereof |
US9398633B2 (en) | 2014-03-27 | 2016-07-19 | Qualcomm Incorporated | Methods and apparatus for low power tracking of network system timing for long paging cycles |
WO2015148128A1 (en) * | 2014-03-27 | 2015-10-01 | Qualcomm Incorporated | Methods and apparatus for low power tracking of network system timing for long paging cycles |
US20150296434A1 (en) * | 2014-04-15 | 2015-10-15 | Qualcomm Incorporated | Systems, methods and apparatus for optimizing machine to machine device performance by dynamically varying slot cycle index |
US20150312351A1 (en) * | 2014-04-24 | 2015-10-29 | Alcatel Lucent | Method, device and system for device trigger in iot |
RU2649313C1 (en) * | 2014-05-22 | 2018-04-02 | Телефонактиеболагет Лм Эрикссон (Пабл) | Optimized synchronization procedure for extended standby periods |
US20150341884A1 (en) * | 2014-05-22 | 2015-11-26 | Telefonaktiebolaget L M Ericsson (Publ) | Optimized synchronization procedure for prolonged periods of sleep |
WO2015177774A1 (en) * | 2014-05-22 | 2015-11-26 | Telefonaktiebolaget L M Ericsson (Publ) | Optimized synchronization procedure for prolonged periods of sleep |
US9699828B2 (en) * | 2014-05-22 | 2017-07-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Optimized synchronization procedure for prolonged periods of sleep |
US11076440B2 (en) | 2014-05-28 | 2021-07-27 | Qualcomm Incorporated | Methods and apparatus for reducing collisions between CDRX and paging operations |
CN105338008A (en) * | 2014-06-10 | 2016-02-17 | 阿尔卡特朗讯 | Equipment scheduling method, device and system for internet of things |
US10327208B2 (en) | 2014-06-30 | 2019-06-18 | Samsung Electronics Co., Ltd. | Method and apparatus for increasing communication effectiveness of terminal in power-saving mode |
KR20160002240A (en) * | 2014-06-30 | 2016-01-07 | 삼성전자주식회사 | Method and apparatus for optimizing communications of low power devices |
KR102151031B1 (en) | 2014-06-30 | 2020-09-02 | 삼성전자주식회사 | Method and apparatus for optimizing communications of low power devices |
KR102352148B1 (en) * | 2014-08-06 | 2022-01-14 | 퀄컴 인코포레이티드 | Ran procedures for extended discontinuous reception(drx) |
KR20170040235A (en) * | 2014-08-06 | 2017-04-12 | 퀄컴 인코포레이티드 | Ran procedures for extended discontinuous reception(drx) |
US10440661B2 (en) * | 2014-08-06 | 2019-10-08 | Quacomm Incorporated | RAN procedures for extended discontinuous reception (DRX) |
US20160044605A1 (en) * | 2014-08-06 | 2016-02-11 | Qualcomm Incorporated | Ran procedures for extended discontinuous reception (drx) |
AU2015301147B2 (en) * | 2014-08-06 | 2019-08-08 | Qualcomm Incorporated | Ran procedures for Extended Discontinuous Reception (DRX) |
JP2017523723A (en) * | 2014-08-06 | 2017-08-17 | クゥアルコム・インコーポレイテッドQualcomm Incorporated | Improved idle mode for extended idle intermittent reception |
WO2016022651A1 (en) * | 2014-08-06 | 2016-02-11 | Qualcomm Incorporated | Ran procedures for extended discontinuous reception (drx) |
AU2015301147B9 (en) * | 2014-08-06 | 2019-12-05 | Qualcomm Incorporated | Ran procedures for Extended Discontinuous Reception (DRX) |
JP2017529763A (en) * | 2014-08-11 | 2017-10-05 | エルジー エレクトロニクス インコーポレイティド | Method and apparatus for terminal proximity monitoring in a wireless communication system |
US10555160B2 (en) | 2014-08-11 | 2020-02-04 | Lg Electronics Inc. | Method for monitoring UE reachability in wireless communication system, and device for same |
US10206091B2 (en) | 2014-08-11 | 2019-02-12 | Lg Electronics Inc. | Method for monitoring UE reachability in wireless communication system, and device for same |
US9706373B1 (en) * | 2014-09-09 | 2017-07-11 | Amazon Technologies, Inc. | Message delivery acknowledgment |
US10299086B1 (en) | 2014-09-09 | 2019-05-21 | Amazon Technologies, Inc. | Message delivery acknowledgment |
JP2017529020A (en) * | 2014-09-29 | 2017-09-28 | コンヴィーダ ワイヤレス, エルエルシー | Service capability server / EPC coordination for power saving mode and paging |
US10602441B2 (en) | 2014-09-29 | 2020-03-24 | Convida Wireless, Llc | Service capability server / EPC coordination for power savings mode and paging |
EP3657866A1 (en) * | 2014-09-29 | 2020-05-27 | Convida Wireless, LLC | Service capability server / epc coordination for power savings mode and paging |
US11019566B2 (en) | 2014-09-29 | 2021-05-25 | Convida Wireless, Llc | Service capability server / EPC coordination for power savings mode and paging |
WO2016055086A1 (en) * | 2014-10-06 | 2016-04-14 | Nokia Solutions And Networks Oy | High latency communication |
US20160105365A1 (en) * | 2014-10-13 | 2016-04-14 | General Motors Llc | Network-coordinated drx transmission reduction for a network access device of a telematics-equipped vehicle |
US9716758B2 (en) * | 2014-10-13 | 2017-07-25 | General Motors Llc | Network-coordinated DRx transmission reduction for a network access device of a telematics-equipped vehicle |
US10111201B2 (en) | 2015-01-16 | 2018-10-23 | Telefonaktiebolaget Lm Ericsson (Publ.) | Wireless communication device, core network node and methods therein for extended DRX paging cycle |
US20160211986A1 (en) * | 2015-01-16 | 2016-07-21 | Telefonaktiebolaget Lm Ericsson (Publ) | EXTENDED DISCONTINUOUS RECEIVE (eDRX) CYCLES |
WO2016114698A1 (en) * | 2015-01-16 | 2016-07-21 | Telefonaktiebolaget Lm Ericsson (Publ) | A wireless communication device, a core network node and methods therein, for extended drx paging cycle |
US10225101B2 (en) * | 2015-01-16 | 2019-03-05 | Telefonaktiebolaget Lm Ericsson (Publ) | Extended discontinuous receive (eDRX) cycles |
JP2018509101A (en) * | 2015-03-15 | 2018-03-29 | クアルコム,インコーポレイテッド | Flexible paging and on-demand page indicators |
WO2016148816A1 (en) * | 2015-03-15 | 2016-09-22 | Qualcomm Incorporated | On-demand paging indicator |
TWI659668B (en) * | 2015-03-15 | 2019-05-11 | 美商高通公司 | Flexible paging and on-demand page indicator |
US10051601B2 (en) | 2015-03-15 | 2018-08-14 | Qualcomm Incorporated | Flexible paging and on-demand page indicator |
US10420164B2 (en) * | 2015-04-03 | 2019-09-17 | Ntt Docomo, Inc. | Base station and user equipment for configuring an extended DRX |
CN107113716A (en) * | 2015-04-03 | 2017-08-29 | 株式会社Ntt都科摩 | Base station and user's set |
EP3282732A4 (en) * | 2015-04-05 | 2018-10-31 | LG Electronics Inc. | Method for adjusting tracking area update timing in wireless communication system, and apparatus therefor |
US10750568B2 (en) | 2015-04-05 | 2020-08-18 | Lg Electronics Inc. | Method for adjusting tracking area update timing in wireless communication system, and apparatus therefor |
CN107637163A (en) * | 2015-04-05 | 2018-01-26 | Lg电子株式会社 | For adjusting the method and its equipment of tracking area update timing in a wireless communication system |
US20180279408A1 (en) * | 2015-04-10 | 2018-09-27 | Intel Corporation | Discontinuous reception (drx) in a device ready state |
CN107432048A (en) * | 2015-04-10 | 2017-12-01 | 英特尔公司 | Discontinuous reception (DRX) under device ready state |
US10631359B2 (en) * | 2015-04-10 | 2020-04-21 | Intel Corporation | Discontinuous reception (DRX) in a device ready state |
KR20230006587A (en) * | 2015-05-04 | 2023-01-10 | 퀄컴 인코포레이티드 | Techniques for paging in extended discontinuous reception |
KR20170142173A (en) * | 2015-05-04 | 2017-12-27 | 퀄컴 인코포레이티드 | Techniques for paging in extended discontinuous reception |
WO2016178756A1 (en) * | 2015-05-04 | 2016-11-10 | Qualcomm Incorporated | Techniques for paging in extended discontinuous reception |
US10045394B2 (en) | 2015-05-04 | 2018-08-07 | Qualcomm Incorporated | Techniques for paging in extended discontinuous reception |
KR102479434B1 (en) * | 2015-05-04 | 2022-12-19 | 퀄컴 인코포레이티드 | Techniques for paging in extended discontinuous reception |
KR102633246B1 (en) | 2015-05-04 | 2024-02-02 | 퀄컴 인코포레이티드 | Techniques for paging in extended discontinuous reception |
US10531514B2 (en) | 2015-05-04 | 2020-01-07 | Qualcomm Incorporated | Techniques for paging in extended discontinuous reception |
US10973077B2 (en) | 2015-05-13 | 2021-04-06 | Telefonaktiebolaget Lm Ericsson (Publ) | Wireless communication device, a core network node and methods therein |
WO2016182498A1 (en) * | 2015-05-13 | 2016-11-17 | Telefonaktiebolaget Lm Ericsson (Publ) | Paging coordination between wireless communication device and core network node |
US20160337061A1 (en) * | 2015-05-13 | 2016-11-17 | Qualcomm Incorporated | Access point synchronization in shared spectrum |
US10172183B2 (en) | 2015-05-19 | 2019-01-01 | Telefonaktiebolaget Lm Ericsson (Publ) | Radio access network node and method—time coordinated cells for extended discontinuous receive (eDRX) |
US10694494B2 (en) | 2015-05-19 | 2020-06-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Core network node and method—time coordinated cells for extended discontinuous receive (eDRX) |
US10172112B2 (en) | 2015-05-19 | 2019-01-01 | Telefonaktiebolaget Lm Ericsson (Publ) | Core network node and method—time coordinated cells for extended discontinuous receive (eDRX) |
US10694462B2 (en) | 2015-05-19 | 2020-06-23 | Huawei Technologies Co., Ltd. | Downlink scheduling data monitoring method, downlink scheduling data sending method, and apparatus |
US10708974B2 (en) * | 2015-05-19 | 2020-07-07 | Telefonaktiebolaget Lm Ericsson (Publ) | Radio access network node and method—time coordinated cells for extended discontinuous receive (eDRX) |
US20190104566A1 (en) * | 2015-05-19 | 2019-04-04 | Telefonaktiebolaget Lm Ericsson (Publ) | RADIO ACCESS NETWORK NODE AND METHOD - TIME COORDINATED CELLS FOR EXTENDED DISCONTINUOUS RECEIVE (eDRX) |
US11025446B2 (en) | 2015-06-15 | 2021-06-01 | Samsung Electronics Co., Ltd. | Method and apparatus for group communication in wireless communication system |
US11496392B2 (en) | 2015-06-27 | 2022-11-08 | Nicira, Inc. | Provisioning logical entities in a multidatacenter environment |
US10743209B2 (en) * | 2015-08-05 | 2020-08-11 | Nec Corporation | Communication system, communication control apparatus, communication control method, and program |
US20180213431A1 (en) * | 2015-08-05 | 2018-07-26 | Nec Corporation | Communication system, communication control apparatus, communication control method, and program |
GB2541009A (en) * | 2015-08-05 | 2017-02-08 | Samsung Electronics Co Ltd | Power saving for cellular internet of things devices |
US10667213B2 (en) | 2015-08-05 | 2020-05-26 | Samsung Electronics Co., Ltd. | Apparatus and method for power saving for cellular internet of things devices |
GB2541009B (en) * | 2015-08-05 | 2019-03-06 | Samsung Electronics Co Ltd | Power saving for cellular internet of things devices |
US20170099649A1 (en) * | 2015-10-02 | 2017-04-06 | Sierra Wireless, Inc. | Method and system for paging user equipment |
US11382060B2 (en) * | 2015-10-02 | 2022-07-05 | Sierra Wireless, Inc. | Method and system for paging user equipment |
US11881988B2 (en) | 2015-11-20 | 2024-01-23 | Geotab Inc. | Big telematics data network communication fault identification device |
US11132246B2 (en) | 2015-11-20 | 2021-09-28 | Geotab Inc. | Big telematics data network communication fault identification system |
US11755403B2 (en) | 2015-11-20 | 2023-09-12 | Geotab Inc. | Big telematics data network communication fault identification system |
US11212746B2 (en) | 2015-11-20 | 2021-12-28 | Geotab Inc. | Big telematics data network communication fault identification method |
US11800446B2 (en) | 2015-11-20 | 2023-10-24 | Geotab Inc. | Big telematics data network communication fault identification method |
US11778563B2 (en) | 2015-11-20 | 2023-10-03 | Geotab Inc. | Big telematics data network communication fault identification system method |
US11223518B2 (en) | 2015-11-20 | 2022-01-11 | Geotab Inc. | Big telematics data network communication fault identification device |
US11140631B2 (en) | 2015-11-20 | 2021-10-05 | Geotab Inc. | Big telematics data network communication fault identification system method |
US10382256B2 (en) * | 2015-11-20 | 2019-08-13 | Geotab Inc. | Big telematics data network communication fault identification device |
EP3391696A4 (en) * | 2015-12-16 | 2018-12-12 | Telefonaktiebolaget LM Ericsson (publ) | Paging a wireless device |
US10165544B2 (en) | 2015-12-16 | 2018-12-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Network node, wireless device and corresponding methods for paging the wireless device |
US10687308B2 (en) | 2016-03-24 | 2020-06-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Core network node and methods for determining reachability of wireless devices in extended discontinuous receive (eDRX) operation |
US10687307B2 (en) | 2016-03-24 | 2020-06-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Core network node and methods for determining reachability of wireless devices in extended discontinuous receive (eDRX) operation |
US20210227497A1 (en) * | 2016-04-05 | 2021-07-22 | Sony Group Corporation | Method and device for paging a machine to machine device |
US11533710B2 (en) * | 2016-04-05 | 2022-12-20 | Sony Group Corporation | Method and device for paging a machine to machine device |
US20180227981A1 (en) * | 2016-05-16 | 2018-08-09 | Ntt Docomo, Inc. | Switching equipment, control server, and communication method |
US11096147B2 (en) * | 2016-07-22 | 2021-08-17 | Telefonaktiebolaget Lm Ericsson (Publ) | Tracking area code allocation |
US20190053192A1 (en) * | 2016-07-22 | 2019-02-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Tracking Area Code Allocation |
US20180070406A1 (en) * | 2016-09-02 | 2018-03-08 | Qualcomm Incorporated | Enhanced discontinuous reception management in wireless communication systems |
WO2018045192A1 (en) * | 2016-09-02 | 2018-03-08 | Qualcomm Incorporated | Enhanced discontinuous reception management in wireless communication systems |
CN109661840A (en) * | 2016-09-02 | 2019-04-19 | 高通股份有限公司 | Enhanced discontinuous reception management in wireless communication system |
US11317364B2 (en) | 2017-02-13 | 2022-04-26 | Telefonaktiebolaget Lm Ericsson (Publ) | Synchronization for extended DRX |
US11050705B2 (en) | 2017-03-20 | 2021-06-29 | At&T Intellectual Property I, L.P. | Signaling optimization during short messaging for internet of things devices in a mobility network |
US11539658B2 (en) | 2017-03-20 | 2022-12-27 | At&T Intellectual Property I, L.P. | Signaling optimization during short messaging for internet of things devices in a mobility network |
US11832337B2 (en) | 2017-03-23 | 2023-11-28 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and device for determining timer configuration |
US11259358B2 (en) | 2017-03-23 | 2022-02-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and device for determining timer configuration |
CN107197508A (en) * | 2017-05-17 | 2017-09-22 | 电子科技大学 | A kind of device sleeps method based on CSM mechanism DRX |
US10455638B2 (en) | 2017-07-06 | 2019-10-22 | Qualcomm Incorporated | Techniques and apparatuses for configuring an extended discontinuous reception cycle |
WO2019010089A1 (en) * | 2017-07-06 | 2019-01-10 | Qualcomm Incorporated | Techniques and apparatuses for configuring an extended discontinuous reception cycle |
US20190045447A1 (en) * | 2017-08-04 | 2019-02-07 | Apple Inc. | MicroSleep for Machine-type Communication Devices |
US10869275B2 (en) * | 2017-08-04 | 2020-12-15 | Apple Inc. | Microsleep for machine-type communication devices |
CN110999413A (en) * | 2017-08-11 | 2020-04-10 | 鸿颖创新有限公司 | Apparatus and method for discontinuous reception in new radio |
US20220030547A1 (en) * | 2017-08-15 | 2022-01-27 | Huawei Technologies Co., Ltd. | Communications Method and Apparatus |
US11641638B2 (en) * | 2017-08-15 | 2023-05-02 | Huawei Technologies Co., Ltd. | Communications method and apparatus |
EP3677085A1 (en) * | 2017-09-01 | 2020-07-08 | QUALCOMM Incorporated | Methods, apparatuses and systems for supporting long term channel sensing in shared spectrum |
US10470077B1 (en) | 2018-06-08 | 2019-11-05 | At&T Intellectual Property I, L.P. | Messaging centers with rule based adaptive retry profiles for 5G or other next generation network |
US10536891B1 (en) * | 2018-06-29 | 2020-01-14 | Texas Instruments Incorporated | Using estimated time drift to determine keep alive periodicity in synchronized networks |
US11089532B2 (en) * | 2018-06-29 | 2021-08-10 | Texas Instruments Incorporated | Using estimated time drift to determine keep alive periodicity in synchronized networks |
US11228979B2 (en) * | 2018-09-20 | 2022-01-18 | Mediatek Singapore Pte. Ltd. | Method and apparatus for reducing power consumption with wake-up mechanism in mobile communications |
CN109462839A (en) * | 2018-11-26 | 2019-03-12 | 电子科技大学 | A kind of DRX mechanism communication means based on adaptive re-configuration police |
US11363532B2 (en) | 2019-10-31 | 2022-06-14 | Itron, Inc. | Downlink event allocation in a network |
US11871345B2 (en) | 2019-10-31 | 2024-01-09 | Itron, Inc. | Downlink event allocation in a network |
AU2020375024B2 (en) * | 2019-10-31 | 2024-03-07 | Itron, Inc. | Downlink event allocation in a network |
WO2021087310A1 (en) * | 2019-10-31 | 2021-05-06 | Itron, Inc. | Downlink event allocation in a network |
US11438837B2 (en) | 2019-10-31 | 2022-09-06 | Itron, Inc. | Downlink event allocation in a network |
US11316773B2 (en) | 2020-04-06 | 2022-04-26 | Vmware, Inc. | Configuring edge device with multiple routing tables |
US11683233B2 (en) | 2020-04-06 | 2023-06-20 | Vmware, Inc. | Provision of logical network data from global manager to local managers |
US11394634B2 (en) | 2020-04-06 | 2022-07-19 | Vmware, Inc. | Architecture for stretching logical switches between multiple datacenters |
US11509522B2 (en) | 2020-04-06 | 2022-11-22 | Vmware, Inc. | Synchronization of logical network state between global and local managers |
US11528214B2 (en) | 2020-04-06 | 2022-12-13 | Vmware, Inc. | Logical router implementation across multiple datacenters |
US11381456B2 (en) | 2020-04-06 | 2022-07-05 | Vmware, Inc. | Replication of logical network data between global managers |
US11374850B2 (en) | 2020-04-06 | 2022-06-28 | Vmware, Inc. | Tunnel endpoint group records |
US11374817B2 (en) | 2020-04-06 | 2022-06-28 | Vmware, Inc. | Determining span of logical network element |
US11153170B1 (en) | 2020-04-06 | 2021-10-19 | Vmware, Inc. | Migration of data compute node across sites |
US11088919B1 (en) | 2020-04-06 | 2021-08-10 | Vmware, Inc. | Data structure for defining multi-site logical network |
US11088916B1 (en) | 2020-04-06 | 2021-08-10 | Vmware, Inc. | Parsing logical network definition for different sites |
US11870679B2 (en) | 2020-04-06 | 2024-01-09 | VMware LLC | Primary datacenter for logical router |
US11736383B2 (en) | 2020-04-06 | 2023-08-22 | Vmware, Inc. | Logical forwarding element identifier translation between datacenters |
US11743168B2 (en) | 2020-04-06 | 2023-08-29 | Vmware, Inc. | Edge device implementing a logical network that spans across multiple routing tables |
US11882000B2 (en) | 2020-04-06 | 2024-01-23 | VMware LLC | Network management system for federated multi-site logical network |
US11438238B2 (en) | 2020-04-06 | 2022-09-06 | Vmware, Inc. | User interface for accessing multi-site logical network |
US11336556B2 (en) | 2020-04-06 | 2022-05-17 | Vmware, Inc. | Route exchange between logical routers in different datacenters |
US11777793B2 (en) | 2020-04-06 | 2023-10-03 | Vmware, Inc. | Location criteria for security groups |
US11799726B2 (en) | 2020-04-06 | 2023-10-24 | Vmware, Inc. | Multi-site security groups |
US11115301B1 (en) | 2020-04-06 | 2021-09-07 | Vmware, Inc. | Presenting realized state of multi-site logical network |
US11303557B2 (en) | 2020-04-06 | 2022-04-12 | Vmware, Inc. | Tunnel endpoint group records for inter-datacenter traffic |
US11258668B2 (en) | 2020-04-06 | 2022-02-22 | Vmware, Inc. | Network controller for multi-site logical network |
US11088902B1 (en) | 2020-04-06 | 2021-08-10 | Vmware, Inc. | Synchronization of logical network state between global and local managers |
CN113938995A (en) * | 2020-07-14 | 2022-01-14 | 华为技术有限公司 | Communication method and device |
US11757940B2 (en) | 2020-09-28 | 2023-09-12 | Vmware, Inc. | Firewall rules for application connectivity |
US11343227B2 (en) | 2020-09-28 | 2022-05-24 | Vmware, Inc. | Application deployment in multi-site virtualization infrastructure |
US11343283B2 (en) | 2020-09-28 | 2022-05-24 | Vmware, Inc. | Multi-tenant network virtualization infrastructure |
US11601474B2 (en) | 2020-09-28 | 2023-03-07 | Vmware, Inc. | Network virtualization infrastructure with divided user responsibilities |
CN114567920A (en) * | 2022-02-23 | 2022-05-31 | 重庆邮电大学 | Mixed discontinuous receiving method of strategy optimization MTC (machine type communication) equipment |
US12107722B2 (en) | 2022-07-20 | 2024-10-01 | VMware LLC | Sharing network manager between multiple tenants |
Also Published As
Publication number | Publication date |
---|---|
CN104303586A (en) | 2015-01-21 |
CN110602669B (en) | 2023-08-18 |
TW202027475A (en) | 2020-07-16 |
EP3735007A1 (en) | 2020-11-04 |
EP2848081A1 (en) | 2015-03-18 |
CN110602669A (en) | 2019-12-20 |
US11032870B2 (en) | 2021-06-08 |
EP3735007B1 (en) | 2024-09-25 |
CN104303586B (en) | 2019-10-18 |
WO2013169376A1 (en) | 2013-11-14 |
TWI685234B (en) | 2020-02-11 |
US20180302946A1 (en) | 2018-10-18 |
US20210259043A1 (en) | 2021-08-19 |
US20240057214A1 (en) | 2024-02-15 |
TWI744762B (en) | 2021-11-01 |
US11856639B2 (en) | 2023-12-26 |
TW201401821A (en) | 2014-01-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11856639B2 (en) | Methods and apparatus for handling MTC long DRX cycle/sleep lengths | |
US10028074B2 (en) | Group-based machine to machine communication | |
US11564170B2 (en) | Wake up signals operation | |
KR102166986B1 (en) | Grantless actions | |
EP3446537B1 (en) | Mobility signaling load reduction | |
US9668234B2 (en) | Method and apparatus for triggering a machine type communication device | |
US9185673B2 (en) | Machine type communication preregistration | |
TWI508593B (en) | Group-based machine to machine communication | |
US10306552B2 (en) | Coordination using the UE application | |
US10973077B2 (en) | Wireless communication device, a core network node and methods therein | |
TW201640937A (en) | System enhancements for using extended DRX |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERDIGITAL PATENT HOLDINGS, INC., DELAWARE Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:OLVERA-HERNANDEZ, ULISES;PELLETIER, GHYSLAIN;WANG, PETER S.;AND OTHERS;SIGNING DATES FROM 20140115 TO 20140304;REEL/FRAME:034984/0837 Owner name: INTERDIGITAL COMMUNICATIONS CORPORATION, PENNSYLVA Free format text: NON-DISCLOSURE AND ASSIGNMENT OF IDEAS AGREEMENT;ASSIGNOR:LIU, KAI;REEL/FRAME:035049/0290 Effective date: 20050218 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE |