METHOD AND APPARATUS INCLUDING POWER SAVING MECHANISMS TO LIMIT PHYSICAL DOWNLINK CONTROL CHANNEL

MONITORING FIELD OF THE INVENTION

The present disclosure is directed to methods and apparatus for managing the monitoring of the physical downlink control channel, and more specifically to a particular user equipment that avoids monitoring the channel, in instances in which the channel is unlikely to be communicating information more directly relevant to the particular user equipment.

BACKGROUND OF THE INVENTION

Presently, user equipment, such as wireless communication devices, communicate with other communication devices using wireless signals, such as within a network environment that can include one or more cells within which various communication connections with the network and other devices operating within the network can be supported. Network environments often involve one or more sets of standards, which each define various aspects of any communication connection being made when using the corresponding standard within the network environment. Examples of developing and/or existing standards include new radio access technology (NR), Long Term Evolution (LTE), Universal Mobile Telecommunications Service (UMTS), Global System for Mobile Communication (GSM), and/or Enhanced Data GSM Environment (EDGE).

As part of communicating with the network, a user equipment does not always know when an incoming communication is going to be received from the network. Furthermore, always actively monitoring for an incoming communication by the user equipment can involve needing to maintain certain portions of the electronic circuitry in an active state, where larger amounts of power may be required by the corresponding circuitry to maintain the circuitry in the active state. As a way to help conserve power, various forms of discontinuous reception modes have been implemented, which seek to limit the duration in which a user device needs to be actively monitoring for incoming communications. This can sometimes involve limiting the periods of time in which the user equipment is actively monitoring for incoming communication. These periods are often generally known to the network, so that attempts to contact the user equipment by the network can be limited to one of these previously determined windows of availability.

One of the challenges with managing the periods of availability in which the user equipment is monitoring for incoming communications, is that in some instances, any incoming communication may sometimes need to be delayed until an active window of monitoring for a particular user equipment becomes available. In some instances, the incoming communication could be associated with a requested scheduling grant related to the anticipated transmission to the network by the user equipment of data to be sent to the network, that may have different degrees of tolerance for any such delay.

For some types of devices, there may be an increased incentive for managing the available periods of time that a device is available for receiving an incoming communication, and correspondingly when a device is unavailable and may be able to place one or more portions of its electronic circuitry into an inactive state during which overall power consumption for the device can be reduced. One such type of device can include at least some forms of reduced capability user equipment, which can sometimes be intended to operate for extended periods of time unattended under a single charge. To the extent that overall power consumption can be further reduced, the device may be better able to operate under a single charge for an even larger extended period of time.

The present inventors have recognized that it would be beneficial to better manage the monitoring of a control channel that includes uplink grants to better coincide with instances in which an uplink grant is expected to be communicated, such as after a scheduling request has been made, or after a buffer status report has been sent, which identifies that the buffer contains information that is desired to be sent to the network. In some instances a timer can be used to even further manage the monitoring of the control channel, to help identify the time between when the user equipment identifies that it has data to send in an uplink, and the anticipated delay associated with the network in responding to such a request.

SUMMARY The present application provides a method in a user equipment for communicating within a network. The method includes determining if the user equipment has data to transmit to the network in an uplink. An indication that the user equipment has data to transmit to the network in the uplink is communicated to the network. Physical downlink control channel candidates carrying an uplink downlink control information format is attempted to be decoded only after the user equipment has communicated to the network that the user equipment has data to transmit.

According to another possible embodiment, a method in a user equipment for communicating within a network is provided. The method includes receiving a first decode delay timer from the network including configuration details for the timer, which identifies a first predetermined amount of time to elapse. A determination is then made that the user equipment has data to send in the uplink. A scheduling request is then transmitted to the network indicating a desire to send data on the uplink, where upon transmitting the scheduling request the first decode delay timer is initiated. A monitoring of a physical downlink control channel for uplink data transmission is then delayed until after the first decode delay timer has identified that the predetermined amount of time has finished elapsing. The physical downlink control channel for uplink data transmission is attempted to be decoded, after expiry of first timer duration. According to another possible embodiment, a user equipment for communicating within a network is provided. The user equipment includes a controller that determines if the user equipment has data to transmit to the network in an uplink. The user equipment further includes a transceiver that communicates to the network, an indication that the user equipment has data to transmit to the network in the uplink. Physical downlink control channel candidates carrying an uplink downlink control information format are attempted to be decoded only after the user equipment has communicated to the network that the user equipment has data to transmit.

According to a further possible embodiment, a method in a network entity for communicating with a user equipment is provided. The method includes transmitting a first decode delay timer to the user equipment including configuration details for the timer, which identifies a first predetermined amount of time to elapse, when delaying a monitoring of a physical downlink control channel for uplink data transmission until after the first decode delay timer has identified that the predetermined amount of time has finished elapsing, after the user equipment transmits a scheduling request to the network indicating a desire to send data on the uplink, where upon transmitting the scheduling request the first decode delay timer is to be initiated in the user equipment. The physical downlink control channel for uplink data transmission is transmitted at a time after the predetermined amount of time has finished elapsing on the first decode delay timer. According to a still further possible embodiment, a network entity for communicating with a user equipment is provided. The network entity includes a controller and a transceiver that transmits a first decode delay timer to the user equipment including configuration details for the timer, which identifies a first predetermined amount of time to elapse, when delaying a monitoring of a physical downlink control channel for uplink data transmission until after the first decode delay timer has identified that the predetermined amount of time has finished elapsing, after the user equipment transmits a scheduling request to the network indicating a desire to send data on the uplink, where upon transmitting the scheduling request the first decode delay timer is to be initiated in the user equipment. The transceiver further transmits the physical downlink control channel for uplink data transmission at a time after the predetermined amount of time has finished elapsing on the first decode delay timer.

These and other features, and advantages of the present application are evident from the following description of one or more preferred embodiments, with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an exemplary network environment in which the present invention is adapted to operate;

FIG. 2 is a flow diagram in a user equipment associated with establishing the instances during which the monitoring of the physical downlink control channel in the user equipment is set to occur, in accordance with at least one embodiment;

FIG. 3 is a flow diagram in a user equipment associated with establishing the instances during which the monitoring of the physical downlink control channel in the user equipment is set to occur, in accordance with at least a further embodiment; FIG. 4 is a flow diagram in a network entity associated with establishing the instances during which the monitoring of the physical downlink control channel in a user equipment is set to occur; and

FIG. 5 is an example block diagram of an apparatus according to a possible embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT (S)

While the present disclosure is susceptible of embodiment in various forms, there is shown in the drawings and will hereinafter be described presently preferred embodiments with the understanding that the present disclosure is to be considered an exemplification of the invention and is not intended to limit the invention to the specific embodiments illustrated.

Embodiments provide power saving mechanisms to limit physical downlink control channel (PDCCH) monitoring.

FIG. 1 is an example block diagram of a system 100 according to a possible embodiment. The system 100 can include a wireless communication device 110, such as User Equipment (UE), a base station 120, such as an enhanced NodeB (eNB) or next generation NodeB (gNB), and a network 130. The wireless communication device 110 can be a wireless terminal, a portable wireless communication device, a smartphone, a cellular telephone, a flip phone, a personal digital assistant, a personal computer, a selective call receiver, a tablet computer, a laptop computer, or any other device that is capable of sending and receiving communication signals on a wireless network.

The network 130 can include any type of network that is capable of sending and receiving wireless communication signals. For example, the network 130 can include a wireless communication network, a cellular telephone network, a Time Division Multiple Access (TDMA)-based network, a Code Division Multiple Access (CDMA)-based network, an Orthogonal Frequency Division Multiple Access (OFDMA)-based network, a Long Term Evolution (LTE) network, a 5th generation (5G) network, a 3rd Generation Partnership Project (3GPP)-based network, a satellite communications network, a high altitude platform network, the Internet, and/or other communications networks.

Reduced capability UEs, such as industrial wireless sensors, video surveillance, and wearables, may need to be operated with a battery that should last from multiple days (e.g. wearables) to at least few years (e.g. industrial sensors). The present filing presents methods to allow power-efficient physical downlink control channel (PDCCH) monitoring.

5G has been introduced for the purposes of connecting everything to anything. Prominent among the use cases is the need to connect internet of things (IoT) devices to monitoring stations for purposes of generating actions based on data analytics. It is also desired to monitor in real time events in critical areas in order to provide security or other related monitoring functionality. Wireless sensors are one example of such devices. It can be advantages for these devices to have a long battery life in order to help better ensure that the cost of operations and maintenance is relatively low. In particular, it can be beneficial that the battery life of such devices are long in order to avoid replacement and avoid the cost of connecting to a wired power source. Power savings has for a long time been a prominent goal of wireless devices including smartphones. In the case of wireless sensors and similar IoT devices this desire may be even more pronounced due to the large number of such devices that is envisioned in a connected world. This motivation is reflected in at least some prior publications, such as 3GPP RP- 193238, entitled new study item (SID) on support of reduced capability NR devices, which aims to study various mechanisms that might be needed in support of reduced capability type devices, similar to other connected industries, such as 5G connectivity, which can serve as catalyst for the next wave smart city innovations. As an example, 3GPP technical report (TR) 22.804, entitled study on communication for automation in vertical domains (CAV) describes a smart city use case and several possible anticipated requirements for such a use case. The exemplary smart city vertical domains discussed cover data collection and processing, which is directed to more efficiently monitor and control city resources, and to provide services to city residents. This includes the deployment of surveillance cameras as being a potentially important aspect of the smart city but also of factories and industries of the future.

Further, the wearables use case can include smart watches, rings, eHealth related devices, and medical monitoring devices, etc. At least one characteristic for such a use case can include that the device is small in size.

As a baseline, exemplary requirements for these three use cases can include: Generic requirements:

• Device complexity: at least one motivation for the new device type may be to lower the device cost and complexity as compared to high-end enhanced mobile broadband (eMBB) and ultra-reliable low latency communication (URLLC) devices of Rel-15/Rel-16. Device cost is generally a factor for all devices, but device cost sensitivity can at least sometimes be more of a factor and/or a concern for at least some types of devices, such as industrial sensors.

• Device size: Requirement for most use cases is that the standard enables a device design with a compact form factor.

• Deployment scenarios: System should support all frequency range 1 (FRiyfrequency range 2 (FR2) bands for frequency division duplex (FDD) and time division duplex (TDD). Use case specific requirements: • Industrial wireless sensors: reference use cases and requirements are described in 3GPP technical report (TR) 22.832, entitled technical specification group services and system aspects, study on enhancements for cyber-physical control applications in vertical domains, and TS 22.104, entitled technical specification group services and system aspects, service requirements for cyber-physical control applications in vertical domains: communication service availability is 99.99% and end-to-end latency less than 100 ms. The reference bit rate is less than 2 Mbps (potentially asymmetric e.g. uplink (UL) heavy traffic) for all use cases and the device is stationary. The battery should last at least few years. For safety related sensors, latency requirement is lower, 5-10 ms (see TR 22.804)

• Video Surveillance: as described in TR 22.804, references an economic video bitrate that would be 2-4 Mbps, have a latency < 500 ms, and have a reliability of between 99%-99.9%. High-end video e.g. for farming would require 7.5-25 Mbps. It is noted that traffic pattern is dominated by UL transmissions.

Wearables: Reference bitrate for smart wearable application can be 10-50 Mbps for downlink (DL) and a minimum of 5 Mbps for UL and the peak bit rate of the device could be higher, such as 150 Mbps for downlink and 50 Mbps for uplink. The battery of the device should last multiple days (up to 1-2 weeks).

It is therefore interesting to study and specify a UE feature and parameter list with lower end capabilities, relative to Release 16 eMBB and URLLC NR to serve the three use cases mentioned above and identify methods to achieve power saving and lower complexity operations.

PDCCH monitoring in 3GPP NR Rel-15/16

3GPP TS 38.213, entitled technical specification group radio access network, NR, physical layer procedures for control, specifies the procedures in the 5G UE to monitor and decode PDCCH grants addressed to it.

A UE monitors a set of PDCCH candidates in one or more core resource sets (CORESETs) on the active DL bandwidth part (BWP) on each activated serving cell configured with PDCCH monitoring according to corresponding search space sets where monitoring implies decoding each PDCCH candidate according to the monitored downlink control information (DCI) formats.

If a UE is provided PDCCHMonitoringCapabilityConfig for a serving cell, the UE obtains an indication to monitor PDCCH on the serving cell for a maximum number of PDCCH candidates and non-overlapping control channel elements (CCEs) per slot, as in Tables 10.1-2 and 10.1-3, if PDCCHMornitoringCapabilityConfig = R15 PDCCH monitoring capability , or - per span, as in Tables 10.1-2A and 10.1-3 A, if

PDCCHMornitoringCapabilityConfig = R16 PDCCH monitoring capability If the UE is not provided PDCCHMonitoringCapabilityConfig , the UE monitors PDCCH on the serving cell per slot.

A UE capability for PDCCH monitoring per slot or per span on an active DL BWP of a serving cell is defined by a maximum number of PDCCH candidates and non-overlapped CCEs the UE can monitor per slot or per span, respectively, on the active DL BWP of the serving cell.

A set of PDCCH candidates for a UE to monitor is defined in terms of PDCCH search space sets. A search space set can be a common search space (CSS) set or a UE specific search space (USS) set. A UE monitors PDCCH candidates in one or more of the following search spaces sets

- a TypeO-PDCCH CSS set configured by pdcch-ConfigSIB 1 in MIB or by searchSpaceSIB 1 in PDCCH-ConfigCommon or by searchSpaceZero in PDCCH -ConfigCommon for a DCI format with cyclic redundancy check (CRC) scrambled by a system information radio network temporary identifier (SI-

RNTI) on the primary cell of the master cell group (MCG)

- a TypeOA-PDCCH CSS set configured by searchSpaceOtherSystemlnformation in PDCCH-ConfigCommon for a DCI format with CRC scrambled by a SI- RNTI on the primary cell of the MCG - a Typel-PDCCH CSS set configured by ra-SearchSpace in PDCCH-

ConfigCommon for a DCI format with CRC scrambled by a random access radio network temporary identifier (RA-RNTI) or a temporary cell radio network temporary identifier (TC-RNTI) on the primary cell

- a Type2-PDCCH CSS set configured by pagingSearchSpace in PDCCH- ConfigCommon for a DCI format with CRC scrambled by a paging radio network temporary identifier (P-RNTI) on the primary cell of the MCG

- a Type3-PDCCH CSS set configured by SearchSpace in PDCCH-Config with searchSpaceType = common for DCI formats with CRC scrambled by interruption radio network temporary identifier (INT-RNTI), slot format indication radio network temporary identifier (SFI-RNTI), transmit power control physical uplink shared channel radio network temporary identifier

(TPC-PUSCH-RNTI), transmit power control physical uplink control channel radio network temporary identifier (TPC-PUCCH-RNTI), transmit power control sounding reference symbols radio network temporary identifier (TPC- SRS-RNTI), CI-RNTI, or PS-RNTI and, only for the primary cell, cell radio network temporary identifier (C-RNTI), modulation coding scheme cell radio network temporary identifier (MCS-C-RNTI), or configured scheduling radio network temporary identifiers (CS-RNTI(s)), and

- a USS set configured by SearchSpace in PDCCH-Config with searchSpaceType = ue-Specific for DCI formats with CRC scrambled by C-RNTI, MCS-C-RNTI, SP-CSI-RNTI, CS-RNTI(s), SL-RNTI, SL-CS-RNTI, or SL-L-CS-RNTI.

A PDCCH transports downlink control information for one or more cells with one RNTI.

The following coding steps can be identified:

- Information element multiplexing - CRC attachment

- Channel coding

- Rate matching

The DCI formats defined in table 7.3.1-1 of TS 38.212, entitled technical specification group radio access network, NR, multiplexing and channel coding, are supported. Table 7.3.1-1: DCI formats

The fields defined in the DCI formats below are mapped to the information bits a ₀ to a _A-Y as follows. Each field is mapped in the order in which it appears in the description, including the zero-padding bit(s), if any, with the first field mapped to the lowest order information bit a ₀ and each successive field mapped to higher order information bits. The most significant bit of each field is mapped to the lowest order information bit for that field, e.g. the most significant bit of the first field is mapped to a _{0 .}

If the number of information bits in a DCI format is less than 12 bits, zeros shall be appended to the DCI format until the payload size equals 12. The size of each DCI format is determined by the configuration of the corresponding active bandwidth part of the scheduled cell and shall be adjusted as described in clause 7.3.1.0 if necessary.

It is known [TR 38.840 entitled technical specification group radio access network, NR, study on user equipment power saving in NR] that the UE power consumption can be reduced when the number of UE PDCCH monitoring occasions and/or the number of PDCCH blind decoding is reduced.

The power saving schemes to reduce PDCCH monitoring and blind decoding for further studies are as follows, - Triggering of PDCCH monitoring - dynamic trigger through layer 1 (LI) signal/signalling

- Power saving signal triggering PDCCH monitoring

- Go-to-sleep signalling to skip PDCCH monitoring

- PDCCH skipping - - DCI based indication for PDCCH skipping (e.g., indication in DCI content, new slot format indication (SFI) state).

- LI signal/signalling (other than DCI) based triggering-

- Multiple CORESET/search space configurations

- Configuration of different PDCCH periodicities with dynamic signalling - Adaptation of CORESET/search space configuration - DCI/timer/HARQ-

ACK based indication

- Dynamic/semi-persistent CORESET/search space ON/OFF

- Adaptation between discontinuous reception (DRX) ON duration timer and inactivitytimer - Separated PDCCH monitoring of DL and UL - LI signalling triggering to assist UE in reducing the number of PDCCH blind decoding

- Reduced PDCCH monitoring on SCell (including cross carrier scheduling)

- Network assistance - reference signal (RS) is dynamically transmitted based on the need to assist UE performing synchronization, channel tracking, measurements and channel estimations before PDCCH decoding

The power saving schemes for reducing PDCCH monitoring shows 5%-85% power saving gains with different detailed schemes comparing to the assumed baseline scheme of Rel-15 PDCCH monitoring for the purpose of evaluation, although each of the different detailed schemes offers various power saving gains. Lower power saving gains 5%-15% were observed for the continuous traffic. High power saving gains 50%-85% was observed for sporadic traffic arrival. This comes at the expense of reduced UPT throughput in the range of 5%-43%, and increased latency in the range of 0%-l 15% (which does not necessarily result in exceeding the corresponding delay budget). This also comes at the expense of additional overhead in the range of 0%-26.53% in terms of DL resource usage.

For Discontinuous Reception (DRX) in TS 38.321, entitled technical specification group radio access network, NR, medium access control protocol specification:

The MAC entity may be configured by radio resource control (RRC) with a DRX functionality that controls the UE's PDCCH monitoring activity for the medium access control (MAC) entity's C-RNTI, CI-RNTI, CS-RNTI, INT-RNTI, SFI-RNTI, SP-CSI-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, and TPC-SRS-RNTT When using DRX operation, the MAC entity shall also monitor PDCCH according to requirements found in other clauses of this specification. When in RRC CONNECTED, if DRX is configured, for all the activated Serving Cells, the MAC entity may monitor the PDCCH discontinuously using the DRX operation specified in this clause; otherwise the MAC entity shall monitor the PDCCH as specified in TS 38.213. RRC controls DRX operation by configuring the following parameters:

- drx-onDurationTimer : the duration at the beginning of a DRX Cycle;

- drx-SlotOffset. the delay before starting the drx-onDurationTimer ;

- drx-InactivityTimer. the duration after the PDCCH occasion in which a PDCCH indicates a new UL or DL transmission for the MAC entity;

- drx-RetransmissionTimerDL (per DL HARQ process except for the broadcast process): the maximum duration until a DL retransmission is received;

- drx-RetransmissionTimerUL (per UL HARQ process): the maximum duration until a grant for UL retransmission is received;

- drx-LongCycleStartOffset the Long DRX cycle and drx-StartOffset which defines the subframe where the Long and Short DRX Cycle starts;

- drx-ShortCycle (optional): the Short DRX cycle;

- drx-ShortCycleTimer (optional): the duration the UE shall follow the Short DRX cycle;

- drx-HARQ-RTT-TimerDL (per DL HARQ process except for the broadcast process): the minimum duration before a DL assignment for HARQ retransmission is expected by the MAC entity;

- drx-HARQ-RTT-TimerUL (per UL HARQ process): the minimum duration before a UL HARQ retransmission grant is expected by the MAC entity;

- ps-Wakeup (optional): the configuration to start associated drx- onDurationTimer in case DCP is monitored but not detected;

- ps-Periodic CS1 Transmit (optional): the configuration to report periodic CSI during the time duration indicated by drx-onDurationTimer in case DCP is configured but associated drx-onDurationTimer is not started;

- ps-TransmitPeriodicLl-RSRP (optional): the configuration to transmit periodic Ll-RSRP report(s) during the time duration indicated by drx-onDurationTimer in case DCP is configured but associated drx-onDurationTimer is not started.

When a DRX cycle is configured, the Active Time includes the time while:

- drx-onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimerDL or drx-RetransmissionTimerUL or ra-ContentionResolutionTimer (as described in clause 5.1.5) is running; or - a Scheduling Request is sent on PUCCH and is pending (as described in clause

5.4.4); or

- a PDCCH indicating a new transmission addressed to the C-RNTI of the MAC entity has not been received after successful reception of a Random Access Response for the Random Access Preamble not selected by the MAC entity among the contention-based Random Access Preamble (as described in clause

5.1.4).

When DRX is configured, the MAC entity shall: l>if a MAC PDU is received in a configured downlink assignment:

2> start the drx-HARQ-RTT-TimerDL for the corresponding HARQ process in the first symbol after the end of the corresponding transmission carrying the DL HARQ feedback;

2> stop the drx-RetransmissionTimerDL for the corresponding HARQ process. l>if a MAC PDU is transmitted in a configured uplink grant:

2> start the drx-HARQ-RTT-TimerUL for the corresponding HARQ process in the first symbol after the end of the first repetition of the corresponding PUSCH transmission;

2>stop the drx-RetransmissionTimerUL for the corresponding HARQ process. 1> if a drx-HARQ-RTT-TimerDL expires:

2>if the data of the corresponding HARQ process was not successfully decoded:

3> start the drx-RetransmissionTimerDL for the corresponding HARQ process in the first symbol after the expiry of drx-HARQ-RTT-TimerDL.

1> if a drx-HARQ-RTT-TimerUL expires:

2> start the drx-RetransmissionTimerUL for the corresponding HARQ process in the first symbol after the expiry of drx-HARQ-RTT-TimerUL.

1> if a DRX Command MAC CE or a Long DRX Command MAC CE is received: 2> stop drx-onDurationTimer

2> stop drx-InactivityTimer .

1> if drx-InactivityTimer expires or a DRX Command MAC CE is received:

2>if the Short DRX cycle is configured: 3> start or restart drx-ShortCycle Timer in the first symbol after the expiry of drx-InactivityTimer or in the first symbol after the end of DRX Command MAC CE reception;

3>use the Short DRX Cycle. 2>else:

3>use the Long DRX cycle.

1> if drx-ShortCycleTimer expires:

2>use the Long DRX cycle.

1> if a Long DRX Command MAC CE is received: 2> stop drx-ShortCycle Timer ;

2>use the Long DRX cycle. l>if the Short DRX Cycle is used, and [(SFN x 10) + subframe number] modulo (drx-ShortCycle) = {drx-StartOffset) modulo ( drx-ShortCycle ):

2> start drx-onDurationTimer after drx-SlotOffset from the beginning of the subframe. l>if the Long DRX Cycle is used, and [(SFN x 10) + subframe number] modulo (drx-LongCycle) = drx-StartOffset :

2> if DCP is configured for the active DL BWP:

3> if DCP indication associated with the current DRX Cycle received from lower layer indicated to start drx-onDurationTimer , as specified in TS

38.213; or

3>if all DCP occasion(s) in time domain, as specified in TS 38.213, associated with the current DRX Cycle occurred in Active Time considering grants/assignments/DRX Command MAC CE/Long DRX Command MAC CE received and Scheduling Request sent until 4 ms prior to start of the last DCP occasion, or within BWP switching interruption length, or during a measurement gap; or

3>if ps-Wakeup is configured with value true and DCP indication associated with the current DRX Cycle has not been received from lower layers: 4> start drx-onDurationTimer after drx-SlotOffset from the beginning of the subframe. 2> else:

3> start drx-onDurationTimer after drx-SlotOffset from the beginning of the subframe.

NOTE 1 : In case of unaligned SFN across carriers in a cell group, the SFN of the SpCell is used to calculate the DRX duration.

1> if the MAC entity is in Active Time:

2>monitor the PDCCH as specified in TS 38.213;

2>if the PDCCH indicates a DL transmission:

3> start the drx-HARQ-RTT-TimerDL for the corresponding HARQ process in the first symbol after the end of the corresponding transmission carrying the DL HARQ feedback, regardless of LBT failure indication from lower layers;

NOTE 2: When HARQ feedback is postponed by PDSCH-to-HARQ_feedback timing indicating a non-numerical kl value, as specified in TS 38.213, the corresponding transmission opportunity to send the DL HARQ feedback is indicated in a later PDCCH requesting the HARQ-ACK feedback. 3>stop the drx-RetransmissionTimerDL for the corresponding HARQ process.

3> if the PDSCH-to-HARQ_feedback timing indicate a non-numerical kl value as specified in TS 38.213:

4> start the drx-RetransmissionTimerDL in the first symbol after the PDSCH transmission for the corresponding HARQ process.

2>if the PDCCH indicates a UL transmission:

3> start the drx-HARQ-RTT-TimerUL for the corresponding HARQ process in the first symbol after the end of the first repetition of the corresponding PUSCH transmission, regardless of LBT failure indication from lower layers;

3>stop the drx-RetransmissionTimerUL for the corresponding HARQ process.

2>if the PDCCH indicates a new transmission (DL or UL): 3> start or restart drx-InactivityTimer in the first symbol after the end of the PDCCH reception. l>if DCP is configured for the active DL BWP; and

1> if the current symbol n occurs within drx-onDurationTimer duration; and 1> if drx-onDurationTimer associated with the current DRX cycle is not started as specified in this clause; and

1> if the MAC entity would not be in Active Time considering grants/assignments/DRX Command MAC CE/Long DRX Command MAC CE received and Scheduling Request sent until 4 ms prior to symbol n when evaluating all DRX Active Time conditions as specified in this clause:

2>not transmit periodic SRS and semi-persistent SRS defined in TS 38.214, entitled technical specification group radio access network, NR, physical layer procedures for data;

2>not report semi-persistent CSI configured on PUSCH; 2> if ps-Periodic CSI Transmit is not configured with value true:

3> if ps-TransmitPeriodicLl-RSRP is not configured with value true.

4>not report periodic CSI on PUCCH.

3>else:

4>not report periodic CSI on PUCCH, except Ll-RSRP report(s). l>else:

2>in current symbol n, if the MAC entity would not be in Active Time considering grants/assignments/DRX Command MAC CE/Long DRX Command MAC CE received and Scheduling Request sent until 4 ms prior to symbol n when evaluating all DRX Active Time conditions as specified in this clause:

3>not transmit periodic SRS and semi-persistent SRS defined in TS 38.214; 3>not report CSI on PUCCH and semi-persistent CSI configured on PUSCH.

2>if CSI masking ( csi-Mask ) is setup by upper layers: 3>in current symbol n, if drx-onDurationTimer would not be running considering grants/assignments/DRX Command MAC CE/Long DRX Command MAC CE received until 4 ms prior to symbol n when evaluating all DRX Active Time conditions as specified in this clause: 4>not report CSI on PUCCH.

NOTE 3: If a UE multiplexes a CSI configured on PUCCH with other overlapping UCI(s) according to the procedure specified in TS 38.213 clause 9.2.5 and this CSI multiplexed with other UCI(s) would be reported on a PUCCH resource outside DRX Active Time, it is up to UE implementation whether to report this CSI multiplexed with other UCI(s). Wake up signal A Rel-15 device is expected to monitor all ON-durations in its cDRX pattern.

In Rel-16, a wakeup signal can be transmitted to the device ahead of an ON-duration if the network intends to schedule the device in that ON-duration. Thus, if the device does not detect the WUS during the monitoring occasion (MO), it can skip the upcoming PDCCH monitoring. This can provide up to 10 percent additional connected mode energy savings for infrequently scheduled devices, depending on the cDRX settings.

The wake up signal is transmitted using DCI format 2 6 using PS-RNTI. The detailed mechanisms are as follows [TS 38.213]

PDCCH MONITORING INDICATION AND DORMANCY/NON- DORMANCY BEHAVIOUR FOR SCELLS

A UE configured with DRX mode operation [11, TS 38.321] on the PCell or on the SpCell [12, TS 38.331, entitled technical specification group radio access network, NR, radio resource control (RRC) protocol specification]

- a PS-RNTI for DCI format 2 6 by ps-RNTI - a number of search space sets, by dci-Format2-6 , to monitor PDCCH for detection of DCI format 2 6 on the active DL BWP of the PCell or of the SpCell according to a common search space as described in Clause 10.1

- a payload size for DCI format 2 6 by SizeDCl 2-6

- a location in DCI format 2 6 of a Wake-up indication bit by PSPositionDCI2-6 , where - the UE may not start the drx-onDurationTimer for the next long DRX cycle when a value of the Wake-up indication bit is O', and

- the UE starts the drx-onDurationTimer for the next long DRX cycle when a value of the Wake-up indication bit is T - a bitmap, when the UE is provided a number of groups of configured SCells by

Scell-groups-for-dormancy-outside-active-time , where

- the bitmap location is immediately after the Wake-up indication bit location

- the bitmap size is equal to the number of groups of configured SCells where each bit of the bitmap corresponds to a group of configured SCells from the number of groups of configured SCells

- a O' value for a bit of the bitmap indicates an active DL BWP, provided by dormant-BWP, for the UE [11, TS38.321] for each activated SCell in the corresponding group of configured SCells

- a ¹ 1 ' value for a bit of the bitmap indicates - an active DL BWP, provided by first-non-dormant-BWP-ID-for-DCI- outside -active -time, for the UE for each activated SCell in the corresponding group of configured SCells, if a current active DL BWP is the dormant DL BWP

- a current active DL BWP, for the UE for each activated SCell in the corresponding group of configured SCells, if the current active DL BWP is not the dormant DL BWP

- an offset by ps-Offset indicating a time, where the UE starts monitoring PDCCH for detection of DCI format 2 6 according to the number of search space sets, prior to a slot where the drx-onDuarationTimer would start on the PCell or on the SpCell [11, TS 38.321]

- for each search space set, the PDCCH monitoring occasions are the ones in the first T _s slots indicated by duration, or T _s = 1 slot if duration is not provided, starting from the first slot of the first T _s slots and ending prior to the start of drx-onDurationTimer . The UE does not monitor PDCCH for detecting DCI format 2 6 during Active

Time [11, TS 38.321] If a UE reports for an active DL BWP a requirement of X slots prior to the beginning of a slot where the UE would start the drx-onDurationTimer, the UE is not required to monitor PDCCH for detection of DCI format 2 6 during the X slots, where X corresponds to the requirement of the SCS of the active DL BWP. If a UE is provided search space sets to monitor PDCCH for detection of DCI format 2 6 in the active DL BWP of the PCell or of the SpCell and the UE does not detect DCI format 2 6

- if the UE is provided ps-WakeupOrNot , the UE is indicated by ps- WakeupOrNot whether the UE may not start or whether the UE shall start the drx-onDurationTimer for the next DRX cycle

- if the UE is not provided ps-WakeupOrNot, the UE may not start Active Time indicated by drx-onDurationTimer for the next DRX cycle

If a UE is provided search space sets to monitor PDCCH for detection of DCI format 2 6 in the active DL BWP of the PCell or of the SpCell and the UE - is not required to monitor PDCCH for detection of DCI format 2 6, as described in Clauses 10, 11.1, 12, and in Clause 5.7 of [14, TS 38.321] for all corresponding PDCCH monitoring occasions outside Active Time prior to a next DRX cycle, or

- does not have any PDCCH monitoring occasions for detection of DCI format 2 6 outside Active Time of a next DRX cycle the UE shall start the drx-onDurationTimer for the next DRX cycle.

If a UE is provided search space sets to monitor PDCCH for detection of DCI format 0 1 and DCI format 1 1 and if one or both of DCI format 0 1 and DCI format 1 1 include a SCell dormancy indication field, - the SCell dormancy indication field is a bitmap with size equal to a number of groups of configured SCells, provided by Scell-groups-for-dormancy-within- active-time ,

- each bit of the bitmap corresponds to a group of configured SCells from the number of groups of configured Scells - if the UE detects a DCI format 0 1 or a DCI format 1 1 that does not include a carrier indicator field, or detects a DCI format 0 1 or DCI format 1 1 that includes a carrier indicator field with value equal to 0

- a O' value for a bit of the bitmap indicates an active DL BWP, provided by dormant-BWP , for the UE for each activated SCell in the corresponding group of configured SCells

- a ¹ 1 ' value for a bit of the bitmap indicates

- an active DL BWP, provided by first-non-dormant-BWP-ID-for-DCI-inside- active-time , for the UE for each activated SCell in the corresponding group of configured SCells, if a current active DL BWP is the dormant DL BWP

- a current active DL BWP, for the UE for each activated SCell in the corresponding group of configured SCells, if the current active DL BWP is not the dormant DL BWP

- the UE sets the active DL BWP to the indicated active DL BWP

If a UE is provided search space sets to monitor PDCCH for detection of DCI format 1 1, and if

- the CRC of DCI format 1 1 is scrambled by a C-RNTI or a MCS-C-RNTI, and if

- re source Allocation = resourceAllocationTypeO and all bits of the frequency domain resource assignment field in DCI format 1 1 are equal to 0, or

- re source Allocation = resourceAllocationTypel and all bits of the frequency domain resource assignment field in DCI format 1 1 are equal to 1

- re source Allocation = dynamicSwitch and all bits of the frequency domain resource assignment field in DCI format 1 1 are equal to 0 or 1 the UE considers the DCI format 1 1 as indicating SCell dormancy, not scheduling a PDSCH reception or indicating a SPS PDSCH release, and for transport block 1 interprets the sequence of fields of

- modulation and coding scheme

- new data indicator

- redundancy version and of - HARQ process number

- antenna port(s)

- DMRS sequence initialization as providing a bitmap to each configured SCell, in an ascending order of the SCell index, where

- a O' value for a bit of the bitmap indicates an active DL BWP, provided by dormant-BWP , for the UE for a corresponding activated SCell

- a ¹ 1 ' value for a bit of the bitmap indicates

- an active DL BWP, provided by first-non-dormant-BWP-ID-for-DCI-inside- active-time , for the UE for a corresponding activated SCell, if a current active DL BWP is the dormant DL BWP

- a current active DL BWP, for the UE for a corresponding activated SCell, if the current active DL BWP is not the dormant DL BWP

- the UE sets the active DL BWP to the indicated active DL BWP

If an active DL BWP provided by dormant-BWP for a UE on an activated SCell is not a default DL BWP for the UE on the activated SCell, as described in Clause 12, the BWP inactivity timer is not used for transitioning from the active DL BWP provided by dormant-BWP to the default DL BWP on the activated SCell.

A UE is expected to provide HARQ-ACK information in response to a detection of a DCI format 1 1 indicating SCell dormancy after N symbols from the last symbol of a PDCCH providing the DCI format 1 1. If processingTypelEnabled of PDSCH-ServingCellConfig is set to enable for the serving cell with the PDCCH providing the DCI format 1 1, N = 5 for m = 0, N = 5.5 for m = 1, and N = 11 for m = 2; otherwise, N = 10 for m = 0, N = 12 for m = 1, N = 22 for m = 2, and JV = 25 for m = 3, where m is the smallest SCS configuration between the SCS configuration of the PDCCH providing the DCI format 1 1 and the SCS configuration of a PUCCH with the HARQ-ACK information in response to the detection of the DCI format 1 1. According to current specified behaviour, UE goes immediately after having sent a scheduling request (SR) on PUCCH in ActiveTime and starts monitoring PDCCH (DL+UL DCI formats).

As a solution, UE may according to one embodiment only need to monitor for UL grants (DCI formats related to PUSCH) in response to having sent a SR on physical uplink control channel (PUCCH). By not being required to monitor for DL grants, the UE may reduce the power consumption. In one example, the UE may not monitor or attempt to decode UL DCI formats (e.g., for UL DCI format sizes different than DL DCI sizes; the UE may continue to monitor UL DCI that is the same size as the DL DCI - e.g, fallback DCI 1 0 and DCI 0 0) when the UE does not have UL data available in the UL buffer for transmission. The UE MAC entity may monitor the PDCCH discontinuously using the DRX operation specified and may monitor only DL DCI formats (and may continue to monitor UL DCI that is the same as the DL DCI - e.g, fallback DCI 1 0 and DCI 0 0). The UE starts to monitor UL DCI formats in response to transmitting a buffer status report (BSR) indicating further UL data available in the buffer for transmission or transmisssion of a SR. In another example, the UE may monitor UL DCI formats (e.g., UL DCI format sizes different than DL DCI sizes) with a reduced number of PDCCH candidates/blind decodes and/or CCE limits when the UE does not have UL data available in the UL buffer for transmission.

As a further solution and according to another embodiment the UE may not go immediately to ActiveTime in response to having sent SR on PUCCH, but only after a preconfigured time offset after having sent the SR on PUCCH, i.e. considering the required processing time at gNB side. Since UE could be configured with multiple SR configurations, e.g. each SR configuration corresponding to one or more logical channels and/or to SCell beam failure recovery and/or for consistent listen before talk (LBT) failure, the time offset may be different for different SR configurations. For example, when sending a SR on PUCCH for a SR configuration which corresponds to a logical channel (LCH) carrying delay non-critical data the UE may stay a bit longer in DRX before starting to monitor for PDCCH. However for SR(s) corresponding to delay critical data, the time offset should be rather small. The UE may be configured with a one or more time offsets corresponding to one or more SR configurations by higher layer signaling. In one example, a time offset may correspond to a group of SR configurations.

UE considers itself in ActiveTime once having sent a transport block (TB) on a configured grant (CG) PUSCH containing a BSR. In one implementation the UE may only monitor for UL grants upon having sent a BSR MAC CE on a CG PUSCH resource, unless drx-onDurationTimer, drx-InactivityTimer , drx- RetransmissionTimerDL , or ra-ContentionResolutionTimer is running. Similar to the first solution UE may not need to go immediately to ActiveTime and monitor PDCCH (UL grants) in response to having sent a BSR MAC on CG PUSCH but only after a time offset, i.e. considering the processing time at gNB side which is longer compared to the SR/PUCCH case due to the MAC PDU decoding. Here, also the time offset may depend on the priority/QoS of the data reported in the BSR. The UE may be configured with a one or more time offsets corresponding to one or more priority/QoS of the data (e.g., associated to the Logical Channel Group ID of the group of logical channel(s) whose buffer status is being reported) or logical channel groups by higher layers signaling. In one example, if BSR indicates the buffer size for more than one logical channel groups, then the time offset may be the smallest time offset of the time offsets associated to the each of the more than one logical channel groups. Different cases can be enumerated depending on UE has UL data to send and/or DL data to receive.

Case 1 : The UE has no uplink data to transmit. In one embodiment, the UE will then skip decoding uplink DCI formats or monitor UL DCI formats with reduced number of PDCCH candidates and/or CCE limits thus reducing both complexity and power. It need not perform as many blind decoding attempts and also saves power by not doing so. In this case, the UE may or may not have data to receive in the downlink. If the wake-up signal (e.g., DCI format 2 6 with CRC scrambled with PS- RNTI (Power Saving RNTI) indicates that it should wake up from DRX at the scheduled time (e.g., slot where the drx-onDuarationTimer would start), then it wakes up and attempts to decode DL PDCCH assignments only. In one example, the UE may also continue to monitor UL DCI that is the same size as the DL DCI. The UE may make a determination that it has no data to send based on contents of the uplink MAC buffer or the lack of a B SR having been generated.

Case 2: The UE did not receive any wake-up signal and thus has no DL DCI to decode after wake-up. It is possible however that the UE has uplink data to transmit in this case. Hence the UE will wake up to transmit data in the uplink.

In this case, as it will be described in details below, the UE sends a scheduling request (SR) to network asking it to provide an UL grant to allow it to transmit the uplink data. In another embodiment the network can configure the UE to enter sleep or micro-sleep, whereby all or some of its receiver components are turned off. The network can in such an implementation configure the UE with a first timer, the first timer duration associated with the length of time the UE enters micro-sleep or sleep following transmission of the SR. The first timer is started after transmission of the SR. The network in one implementation may base the value of the first timer on the basis of the time it needs to process the SR. In this implementation, the timer is a semi-static parameter configured by the network either through RRC or MAC protocols. After transmission of the SR, the UE skips decoding of the UL DCI for a first timer duration and then attempts to decode UL PDCCH grants sent to it in response to the SR. Once this timer expires, the UE starts blind decoding UL DCI.

In another implementation, the UE may stay awake during the first timer duration but simply skips UL PDCCH monitoring. This might be necessary if the UE has downlink data it might be receiving and therefore needs to decode DL PDCCH assignments. In one example, the UE may also monitor UL DCI that is the same size as the DL DCI.

In an additional implementation, the network may configure a first timer for each SR configuration it provides to the UE. The network may configure multiple SR configurations in order to address different service priorities reflected in the logical channel priorities configured at the UE.

In another implementation the network may configure the UE with a first scheduling period and a second timer. The UE on wake up following the expiry of the first timer, will attempt to decode UL PDCCH grants in response to the SR transmitted after expiry of the first timer, and shall do so for a first scheduling period of time. After expiry of the first scheduling duration, the UE shall enter sleep or skip UL PDCCH monitoring for a second timer duration of time. The second timer is started after the expiry of the first scheduling period. After expiry of the second timer, the UE shall attempt to decode UL PDCCH grants. The network may configure the second timer in order to provide it with additional scheduling flexibility in case of congestion and in case the traffic associated with the SR is not of high priority.

In another implementation, after transmission of the first SR, the UE shall limit UL PDCCH monitoring on only the UL DCI formats and not attempt to blindly decode UL/DL common DCI formats (e.g., UL and DL DCI that are the same size).

In another implementation, the network may configure the UE with a third timer, on the expiry of which the UE shall attempt to decode both regular UL PDCCH DCI formats and UL/DL common PDCCH formats. The third timer shall be started at the earliest at some point after the expiry of the first scheduling period. Alternatively, the third timer can be started after the expiry of the second timer.

Case 3 : UE has received a wake-up signal for potential DL data reception and has UL data to send.

In this case, where the UE has to blind decode both UL and DL DCI formats, the UE still can wait for a certain time before starting to decode based on a sleep pattern known to the network.

Case 4: While in the sleep mode or in DRX, the UE may have UL data to send. According to the current standards specifications the UE shall wake up in response to arrival of the data in its buffer. In this case, the UE typically would not have received a wake up signal since it in the midst of its DRX sleep time (e.g., prior to a time corresponding to a slot where the drx-onDuarationTimer would start less a configured time offset (e.g., ps-Offset)). In one implementation, the UE shall transmit an SR and enter micro-sleep or sleep or alternatively skip UL PDCCH monitoring for a first timer duration. During the first timer duration, the UE would not monitor DL PDCCH assignments. In a further implementation it can also skip monitoring UL/DL common DCI formats. In some examples, UL and DL DCI formats are of different size and there is also a default or fallback UL/DL DCI format (e.g. DCI format 0 0, 1 0) that is of the same size but smaller than the UL or DL specific DCI formats (e.g., DCI format 0 1, 0_2, 1_1, 1_2). In some of the embodiments, the UL and/or DL DCI formats correspond to

DCI formats with CRC scrambled by C-RNTI (e.g., at least one of C-RNTI or CS- RNTI or MCS-C-RNTI). The UL and/or DL DCI PDCCH may be received in a UE- specific search space set or a Type3-PDCCH common search set (e.g., DL DCI and UL DCI of the same size).

Embodiment 1: Timer configuration from network to sleep based on SR

A UE should not go immediately to ActiveTime, but only after a preconfigured time offset after having sent the PUCCH, i.e. considering the required processing time at gNB side.

Embodiment 2: UE decodes UL DCI only if data to send

UE may only need to monitor for UL grants (DCI formats related to PUSCH). By not being required to monitor for DL grants, the UE may reduce the power consumption.

In some instances, a timer is started when SR is sent

-upon expiry of the timer, the UE wakes up and monitors PDCCH,

-the timer could be configured by SR configuration, and -the UE wakes up after a certain predefined time of sending a BSR and monitors for PDCCH [uplink grant].

According to current specified behavior, the UE goes into an active state immediately after having sent a SR on PUCCH and starts monitoring PDCCH (DL+UL). In contrast to the above previously identified and/or proposed behaviors, the first and second timer, and the first scheduling period for UL PDCCH following SR transmission are believed to be unique relatively to previous implementations and/or proposals.

FIG. 2 illustrates a flow diagram 200 in a user equipment associated with establishing the instances during which the monitoring of the physical downlink control channel in the user equipment is set to occur, in accordance with at least one embodiment. In accordance with at least one embodiment, the method can include determining 202 if the user equipment has data to transmit to the network in an uplink. An indication that the user equipment has data to transmit to the network in the uplink can be communicated 204 to the network. Physical downlink control channel candidates carrying an uplink downlink control information format can be attempted to be decoded 206 only after the user equipment has communicated to the network that the user equipment has data to transmit.

In some instances, the indication can be included as part of the communication to the network that the user has data to transmit to the network is included as part of a scheduling request that is communicated to the network. In some of these instances, the scheduling request can be communicated on a physical uplink control channel.

In some instances, the indication included as part of the communication to the network that the user has data to transmit to the network can be included as part of a buffer status report that is communicated to the network. In some of these instances, the buffer status report is communicated on a configured grant physical uplink shared channel.

In some instances, attempting to decode the physical downlink control channel candidates carrying the uplink downlink control information format can be part of physical downlink control channel monitoring, which is started only after the user equipment has communicated to the network that the user equipment has data to transmit, and for the period of time during which the user equipment continues to have data to transmit in the uplink. In some of these instances, physical downlink control channel monitoring can include blind decoding of uplink and downlink control information formats. In some instances, upon communicating to the network an indication that the user equipment has data to transmit to the network in the uplink, the user equipment can initiate a first timer, which measures a predetermined amount of time to elapse, where the attempt to decode the physical downlink control channel candidates carrying the uplink downlink control information format can be delayed until after the first timer indicates that the predetermined amount of time has finished elapsing. In some of these instances, configuration details for the first timer can be received from the network.

FIG. 3 illustrates a flow diagram 300 in a user equipment associated with establishing the instances during which the monitoring of the physical downlink control channel in the user equipment is set to occur, in accordance with at least a further embodiment. In accordance with at least one embodiment, the method can include receiving 302 a first decode delay timer from the network including configuration details for the timer, which identifies a first predetermined amount of time to elapse. A determination 304 can then be made that the user equipment has data to send in the uplink. A scheduling request can then be transmitted 306 to the network indicating a desire to send data on the uplink, where upon transmitting the scheduling request the first decode delay timer can be initiated. A monitoring of a physical downlink control channel for uplink data transmission can then be delayed 308 until after the first decode delay timer has identified that the predetermined amount of time has finished elapsing. The physical downlink control channel for uplink data transmission can be attempted to be decoded 310, after expiry of first timer duration.

In some instances, delaying the monitoring of the physical downlink control channel for uplink data transmission can include skipping decoding of the physical downlink control channel carrying an uplink downlink control information format.

In some instances, the method can further include receiving a discontinuous reception configuration to apply when connected to the network, receiving a wake-up signal from the network, and determining that the wake-up signal indicates that the network does not have downlink data for the user equipment. In some instances, the method can further include receiving a first scheduling period from the network, and attempting to decode the physical downlink control channel for uplink data transmission following the expiry of the first timer, for a duration based on the received first scheduling period. In some of these instances, the method can still further include receiving a second timer from the network for identifying, after being initiated, a second predetermined amount of time to elapse, determining the expiry of the first scheduling period, and initiating the second timer, delaying monitoring of the physical downlink control channel for uplink data transmission until after the second timer has identified that the second predetermined amount of time has elapsed, and attempting to decode the physical downlink control channel for uplink data transmission following the expiry of the second timer.

FIG. 4 illustrates a flow diagram 400 in a network entity associated with establishing the instances during which the monitoring of the physical downlink control channel in a user equipment is set to occur. In accordance with at least one embodiment, the method can include transmitting 402 a first decode delay timer to the user equipment including configuration details for the timer, which identifies a first predetermined amount of time to elapse, when delaying a monitoring of a physical downlink control channel for uplink data transmission until after the first decode delay timer has identified that the predetermined amount of time has finished elapsing, after the user equipment transmits a scheduling request to the network indicating a desire to send data on the uplink, where upon transmitting the scheduling request the first decode delay timer is to be initiated in the user equipment. The physical downlink control channel for uplink data transmission can be transmitted 404 at a time after the predetermined amount of time has finished elapsing on the first decode delay timer.

It should be understood that, notwithstanding the particular steps as shown in the figures, a variety of additional or different steps can be performed depending upon the embodiment, and one or more of the particular steps can be rearranged, repeated or eliminated entirely depending upon the embodiment. Also, some of the steps performed can be repeated on an ongoing or continuous basis simultaneously while other steps are performed. Furthermore, different steps can be performed by different elements or in a single element of the disclosed embodiments.

FIG. 5 is an example block diagram of an apparatus 500, such as the wireless communication device 110, according to a possible embodiment. The apparatus 500 can include a housing 510, a controller 520 within the housing 510, audio input and output circuitry 530 coupled to the controller 520, a display 540 coupled to the controller 520, a transceiver 550 coupled to the controller 520, an antenna 555 coupled to the transceiver 550, a user interface 560 coupled to the controller 520, a memory 570 coupled to the controller 520, and a network interface 580 coupled to the controller 520. The apparatus 500 can perform the methods described in all the embodiments.

The display 540 can be a viewfinder, a liquid crystal display (LCD), a light emitting diode (LED) display, a plasma display, a projection display, a touch screen, or any other device that displays information. The transceiver 550 can include a transmitter and/or a receiver. The audio input and output circuitry 530 can include a microphone, a speaker, a transducer, or any other audio input and output circuitry. The user interface 560 can include a keypad, a keyboard, buttons, a touch pad, a joystick, a touch screen display, another additional display, or any other device useful for providing an interface between a user and an electronic device. The network interface 580 can be a Universal Serial Bus (USB) port, an Ethernet port, an infrared transmitter/receiver, an IEEE 1394 port, a WLAN transceiver, or any other interface that can connect an apparatus to a network, device, or computer and that can transmit and receive data communication signals. The memory 570 can include a random access memory, a read only memory, an optical memory, a solid state memory, a flash memory, a removable memory, a hard drive, a cache, or any other memory that can be coupled to an apparatus.

The apparatus 500 or the controller 520 may implement any operating system, such as Microsoft Windows®, UNIX®, or LINUX®, Android™, or any other operating system. Apparatus operation software may be written in any programming language, such as C, C++, Java or Visual Basic, for example. Apparatus software may also run on an application framework, such as, for example, a Java® framework, a .NET® framework, or any other application framework. The software and/or the operating system may be stored in the memory 570 or elsewhere on the apparatus 500. The apparatus 500 or the controller 520 may also use hardware to implement disclosed operations. For example, the controller 520 may be any programmable processor. Disclosed embodiments may also be implemented on a general-purpose or a special purpose computer, a programmed microprocessor or microcontroller, peripheral integrated circuit elements, an application-specific integrated circuit or other integrated circuits, hardware/electronic logic circuits, such as a discrete element circuit, a programmable logic device, such as a programmable logic array, field programmable gate-array, or the like. In general, the controller 520 may be any controller or processor device or devices capable of operating an apparatus and implementing the disclosed embodiments. Some or all of the additional elements of the apparatus 500 can also perform some or all of the operations of the disclosed embodiments. The method of this disclosure can be implemented on a programmed processor. However, the controllers, flowcharts, and modules may also be implemented on a general purpose or special purpose computer, a programmed microprocessor or microcontroller and peripheral integrated circuit elements, an integrated circuit, a hardware electronic or logic circuit such as a discrete element circuit, a programmable logic device, or the like. In general, any device on which resides a finite state machine capable of implementing the flowcharts shown in the figures may be used to implement the processor functions of this disclosure.

While this disclosure has been described with specific embodiments thereof, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. For example, various components of the embodiments may be interchanged, added, or substituted in the other embodiments. Also, all of the elements of each figure are not necessary for operation of the disclosed embodiments. For example, one of ordinary skill in the art of the disclosed embodiments would be enabled to make and use the teachings of the disclosure by simply employing the elements of the independent claims. Accordingly, embodiments of the disclosure as set forth herein are intended to be illustrative, not limiting. Various changes may be made without departing from the spirit and scope of the disclosure.

In this document, relational terms such as "first," "second," and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The phrase "at least one of," "at least one selected from the group of," or "at least one selected from" followed by a list is defined to mean one, some, or all, but not necessarily all of, the elements in the list. The terms "comprises," "comprising," "including," or any other variation thereof, are intended to cover a non- exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "a," "an," or the like does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element. Also, the term "another" is defined as at least a second or more. The terms "including," "having," and the like, as used herein, are defined as "comprising." Furthermore, the background section is written as the inventor's own understanding of the context of some embodiments at the time of filing and includes the inventor's own recognition of any problems with existing technologies and/or problems experienced in the inventor's own work.