Methods, systems, and apparatus, including computer program products, for on-demand ue request for network energy saving operation
Patent Information
- Application Number
- CN202580024748.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2024-04-03
- Filing Date
- 2025-03-27
- Publication Date
- 2026-11-03
AI Technical Summary
In wireless communication systems, the frequent broadcasting of SSB and SIB1 during energy-saving operations leads to high energy consumption, and existing technologies struggle to effectively reduce network energy consumption.
An on-demand operation mechanism is introduced, allowing user equipment (UE) to request the transmission of SSB and SIB1 through L1, L2 or L3 layers. The network node decides whether to transmit based on the request. It supports asynchronous signal block secondary cell operation of in-band and inter-band carrier aggregation and cell discontinuous transmission/reception. Requests and responses are made by configuring channels such as PRACH, PUCCH, and PUSCH.
By employing an on-demand operation mechanism, network energy consumption is reduced, network energy efficiency is improved, and the communication needs of UEs under different power-saving states are supported.
Smart Images

Figure CN123036948A_ABST
Abstract
Description
Technical Field
[0001] This application relates in general to wireless communication systems, including support for on-demand operation when the network is performing energy-saving operations. Background Technology
[0002] Wireless mobile communication technologies use various standards and protocols to transmit data between base stations and wireless communication devices. Wireless communication system standards and protocols may include, for example, 3GPP Long Term Evolution (LTE) (e.g., 4G), 3GPP New Radio (NR) (e.g., 5G), and the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard for Wireless Local Area Networks (WLANs) (often referred to as Wi-Fi within the industry organization). ® ).
[0003] As envisioned by 3GPP, different wireless communication system standards and protocols can use various radio access networks (RANs) for communication between RAN base stations (sometimes referred to as RAN nodes, network nodes, or simply nodes) and wireless communication equipment called user equipment (UEs). 3GPP RANs can include, for example, Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), and / or Next Generation Radio Access Network (NG-RAN).
[0004] Each RAN can use one or more Radio Access Technologies (RATs) to perform communication between the base station and the UE. For example, GERAN implements the GSM and / or EDGE RAT, UTRAN implements the Universal Mobile Telecommunications System (UMTS) RAT or other 3GPP RATs, E-UTRAN implements the LTE RAT (sometimes simply referred to as LTE), and NG-RAN implements the NR RAT (sometimes referred to herein as the 5G RAT, 5G NR RAT, or simply NR). In some deployments, E-UTRAN may also implement the NR RAT. In some deployments, NG-RAN may also implement the LTE RAT.
[0005] The base stations used by a RAN can be associated with that RAN. An example of an E-UTRAN base station is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly referred to as Evolved Node B, Enhanced Node B, eNodeB, or eNB). An example of an NG-RAN base station is a Next Generation Node B (sometimes also called gNode B or gNB).
[0006] The RAN provides communication services to external entities through its connection with the core network (CN). For example, E-UTRAN can utilize the evolved packet core (EPC), while NG-RAN can utilize the 5G core network (5GC).
[0007] 5G NR frequency bands can be divided into two or more distinct frequency ranges. For example, Frequency Range 1 (FR1) may include bands operating at frequencies below 6 GHz, some of which are available for previous standards and can potentially be extended to cover new spectrum offerings from 410 MHz to 7125 MHz. Frequency Range 2 (FR2) may include bands from 24.25 GHz to 52.6 GHz. It should be noted that in some systems, FR2 may also include bands from 52.6 GHz to 71 GHz (or higher). Bands in the millimeter-wave (mmWave) range of FR2 may have smaller coverage areas but potentially higher available bandwidth than bands in FR1. Those skilled in the art will recognize that these frequency ranges, presented by way of example, may change over time or in different regions. Attached Figure Description
[0008] To facilitate the identification of any particular element or action in the discussion, one or more of the most significant digits in the figure reference numerals refer to the figure number in which the element was first introduced.
[0009] Figure 1 A signal flow diagram illustrating an on-demand UE request is shown according to some implementation schemes.
[0010] Figure 2 Examples of methods performed by the UE according to some implementation schemes are shown.
[0011] Figure 3 Examples of methods executed by network nodes according to some implementation schemes are shown.
[0012] Figure 4 An example architecture of a wireless communication system according to the implementation scheme disclosed herein is illustrated.
[0013] Figure 5 A system for performing signaling transfer between a wireless device and a network device according to an embodiment disclosed herein is illustrated. Detailed Implementation
[0014] Various implementations are described with respect to the UE. However, references to the UE are provided for illustrative purposes only. The example implementations may be used with any electronic components capable of establishing a connection to a network and configured with hardware, software, and / or firmware for exchanging information and data with the network. Therefore, the UE described herein is used to represent any suitable electronic component.
[0015] Network energy-saving operations have been introduced in New Radio (NR) to address the growing concerns about energy consumption and efficiency as networks evolve. In Release 18, several technical details for achieving network energy savings have been specified, including the following.
[0016] Synchronization-free signal block (SSB) secondary cell (SCell) operation for inter-band carrier aggregation (CA) in FR1 and co-located cells. Version 15 NR supports the SSB-free SCell option for in-band CA, and version 18 extends SSB-free SCell operation to inter-band CA.
[0017] Network energy-saving schemes in the spatial and power domains may include the following. In the spatial domain, it may allow disabling / enabling all or a subset of antenna elements associated with logical antenna ports. Some implementations may support the configurability of non-zero power channel state information-reference signal (NZP CSI-RS) resources for channel measurements within a single resource setting corresponding to more than one spatial adaptation mode. Some implementations may support a single CSI reporting configuration comprising multiple CSI reporting sub-configurations, where each sub-configuration corresponds to a spatial adaptation mode.
[0018] The power domain allows adjustment of the power offset value between the Physical Downlink Shared Channel (PDSCH) and the CSI-RS. Some implementations support configuring one or more resources associated with one or more power offset values. Some implementations support configuring more than one power offset value for the PDSCH relative to the CSI-RS for CSI reports. Some implementations support a single CSI report configuration that includes multiple CSI report sub-configurations, where each sub-configuration corresponds to a different power offset value for the PDSCH relative to the CSI-RS. Additionally, Discontinuous Transmission (DTX) / Discontinuous Reception (DRX) operations can be used for network energy savings.
[0019] In NR, there are channels / signals that UEs expect the network to continuously transmit, which can lead to high network energy consumption: SSB and System Information Block 1 (SIB1). The SSB includes the Primary Synchronization Signal (PSS), Secondary Synchronization Signal (SSS), and MIB (Master Information Block). SIB1 carries the essential information required for the device to initiate communication with the network. Therefore, this information is typically broadcast frequently by the network. However, due to the transmission frequency, these channels / signals can consume a significant amount of energy.
[0020] Therefore, to reduce network energy consumption, some implementations can employ on-demand operation for SSB and SIB1. Such on-demand operation allows the network to reduce the frequency of broadcasting these signals or introduce periods during which SSB and SIB1 are not broadcast. For both in-band CA and inter-band CA, some implementations herein specify procedures and signaling methods for supporting on-demand SSB SCell operation for UEs configured using CA in connected mode. Furthermore, some implementations herein include procedures and signaling methods for supporting on-demand SIB1 for UEs in idle / inactive mode.
[0021] On-demand operation allows a UE to request an SSB or SIB1. Based on the UE request, the network node can decide whether to send an SSB or SIB1. The implementation described herein includes details on using Layer 1 (L1) Physical (PHY) layer, L2 Media Access Control (MAC) layer, and / or L3 RRC layer to support on-demand UE requests for network energy-saving operations.
[0022] Figure 1 A signaling flow diagram 118 illustrating an on-demand UE request according to some implementation schemes is provided. An on-demand UE request (also referred to herein as an on-demand request) refers to a request from UE 102 to send an SSB and / or SIB1 to a network node 104 in a power-saving state. A power-saving state can refer to any network energy-saving operation.
[0023] As shown in the figure, network node 104 can enter power-saving state 106. Power-saving state 106 allows network node 104 to conserve power. However, power-saving state 106 prevents network node 104 from sending SSB and SIB1.
[0024] UE 102 can determine that UE 102 expects to obtain SSB and / or SIB1 from one or more network nodes in a power-saving state. For example, UE 102 may expect to connect to network node 104, which might not be possible without SSB and / or SIB1. SIB1 is a message broadcast by network node 104 that includes basic information for UE 102 to connect to network node 104.
[0025] Due to power saving state 106, network node 104 may not broadcast SSB and / or SIB1. To obtain SSB and / or SIB1, the UE can generate an on-demand request 108. The on-demand request can request network node 104 to send SSB and / or SIB1. UE 102 can transmit the on-demand request 114 via L1 message, L2 message, or L3 message.
[0026] Network node 104 can receive on-demand requests and identify them as requests to send SSB and / or SIB1. Network node 104 can decide whether to transmit SSB and / or SIB1. Network node 104 can transmit SSB and / or SIB1. UE 102 can receive SSB and / or SIB1.
[0027] To support on-demand SSB or SIB1 operation for network energy saving, the UE can use various mechanisms to request SSB or SIB1 transmission (e.g., transmit 114 on-demand request). For example, in some implementations, the SSB or SIB1 request can be transmitted by the UE as an L1 (PHY layer message). For example, the request can be transmitted via PRACH (e.g., message 1 transmission). In some implementations, the UE can transmit the request in Uplink Control Information (UCI) via the Physical Uplink Control Channel (PUCCH). For example, the SSB / SIB1 request can be transmitted via a Scheduling Request (SR). In some implementations, the UE can transmit the request in UCI via the Physical Uplink Shared Channel (PUSCH). For example, the SSB / SIB1 request can be transmitted via a Configuration Grant (CG) PUSCH.
[0028] In some implementations, L2 or L3 can be used by the UE to send SSB requests or SIB1 requests to network nodes. For example, in some implementations, the request can be transmitted as an L2 (MAC layer) message. For example, the request can be included in the MAC-CE. In some implementations, the request can be transmitted as an L3 (RRC layer) message. For example, the request can be included in an RRC (e.g., UE Assistance Information (UAI)).
[0029] The following sections provide more details about on-demand requests based on whether they are transmitted via L1, L2, or L3 messages.
[0030] L1 On-Demand Request
[0031] In some implementations, to support on-demand SSB or SIB1 operation for network energy saving, the UE can use different mechanisms to request SSB or SIB1 transmission based on the RRC state. For example, for a UE in an RRC connected state (on-demand SSB request), in some implementations, the UE can use a UCI via PUCCH or a UCI via PUSCH for the request. In some implementations, for a UE in an RRC connected state (on-demand SSB request), the UE can use MAC-CE for the request. Furthermore, in some implementations, when the UE is in an RRC idle / inactive state (on-demand SIB1 request), the UE can transmit the request via PRACH.
[0032] To support on-demand SSB or SIB1 operation for network energy conservation, when the PRACH is used by the UE to transmit on-demand requests, the network node can send the following configuration information for the corresponding PRACH. In some implementations, the network node can configure the resources or other identification parameters that will be used by the UE when transmitting on-demand requests for SSB or SIB1. When the network node receives an on-demand request, it can identify the request based on the resources or other identification parameters used.
[0033] For example, a network node can configure resources in the frequency domain for a PRACH transmission corresponding to an on-demand request. In some implementations, the network node can configure the number of PRACH msg1s for frequency division multiplexing (FDM) in the frequency domain for the on-demand request. In some implementations, the network node can configure the start of PRACH frequency domain resource allocation for the on-demand request.
[0034] In some implementations, network nodes can configure resources in the time domain for PRACH transmissions corresponding to on-demand requests. For example, a network node can configure the periodicity of PRACH transmissions for on-demand requests. As another example, a network node can configure a selected index for the PRACH transmission period for on-demand PRACH requests.
[0035] In some implementations, network nodes can configure a power domain, i.e., power control for on-demand PRACH requests. For example, network nodes can configure the target PRACH receive power, the maximum transmit power, and / or the step size of the power ramp.
[0036] In some implementations, a network node can configure how many SSBs are associated with a single PRACH timing for an on-demand PRACH request. In some implementations, a network node can configure the index of the PRACH preamble for the on-demand PRACH request. In some implementations, a network node can configure the PRACH response (i.e., Random Access Response (RAR)) window for the on-demand PRACH request.
[0037] To support on-demand SSB or SIB1 operation for network energy saving, when PRACH is used by the UE to transmit on-demand requests, the following options can be used for the configuration of PRACH transmission if the request is for on-demand SIB1 of a UE in an RRC idle / inactive state. Typically, PRACH configuration is part of SIB1; however, due to the introduction of on-demand SIB1 PRACH requests, new methods for providing PRACH configuration to the UE can be introduced. In some implementations, PRACH configuration is delivered via a modified MIB using reserved bits in the Master Information Block (MIB).
[0038] In some implementations, the PRACH configuration is delivered via a different carrier. For example, the UE can be redirected to a frequency different from the cell it is camped on to obtain the configuration. For instance, the UE can camp on a cell in energy-saving mode and find another cell in which the network still transmits system information including the PRACH configuration that the UE can use for on-demand requests.
[0039] To support on-demand SSB or SIB1 operation for network energy conservation, contention-free random access or contention-based random access is considered when the PRACH is used by the UE to transmit on-demand requests. In some implementations, the UE and network node can use contention-free random access (CFRA) for on-demand requests. In some implementations, the UE and network node can use contention-based random access (CBRA) for on-demand requests.
[0040] In some implementations, a single PRACH preamble transmission may exist in terms of the number of steps in the PRACH procedure. For example, the system can use CFRA for on-demand requests, and the UE can transmit the PRACH preamble transmission. The network node may not need to identify which UE transmitted the on-demand request, but can instead broadcast SSB or SIB1, regardless of the UE's identity. In some implementations, the UE and network node can perform a four-step PRACH or a two-step PRACH.
[0041] To support on-demand SSB or SIB1 operation for NW energy saving, one or more of the following options can be used when a UCI (e.g., a scheduling request (SR)) on the PUCCH is provided to the UE for transmitting an on-demand request. In some implementations, the SchedulingRequestId for the on-demand request can be configured only for the Primary Cell Group (MCG). In some implementations, the SchedulingRequestId for the on-demand request is configured for both the MCG and SCG. In some implementations, the SchedulingRequestId for the on-demand request is configured per serving cell. The network node can configure the SR, and when the network node detects that a UE is using PUCCH resources, it can determine that an SSB or SIB1 request is being requested.
[0042] To support on-demand SSB or SIB1 operation for network energy saving, some implementations may include prioritizing the on-demand request relative to other scheduling requests when a UCI (e.g., SR) on the PUCCH is used by the UE to transmit an on-demand request. Regarding SR priority during UCI multiplexing, if more than one SR indication is affirmative, the following options may be used: In some implementations, the SR for the on-demand request has the same priority as other non-link recovery request (LRR) scheduling requests. In some implementations, the SR for the on-demand request has the same priority as an LRR SR. In some implementations, the SR for the on-demand request has a lower priority than a non-LRR SR. In some implementations, the SR for the on-demand request has a lower priority than an LRR SR but a higher priority than a non-LRR SR. An LRR SR is an SR for a link recovery request, namely schedulingRequestID-BFR-SCell-r16, schedulingRequestID-BFR-r17, or schedulingRequestID-BFR2-r17. The LRR SR has a higher priority compared to other SRs. Priority can be used by the UE to determine which SR to transmit in the case of multiple SRs, and can be used by the network node to determine which SR to respond to first.
[0043] To support on-demand SSB or SIB1 operation for network energy saving, when a UCI (e.g., SR) on the PUCCH is used by the UE to transmit an on-demand request, the following options can be used when the SR conflicts with a PUSCH transmission with uplink (UL) permission. In some implementations, when the SR for the on-demand request conflicts with a PUSCH transmission with UL permission, the SR for the on-demand request is dropped or postponed. For example, if a conflict occurs, the SR for the on-demand request can be postponed to the next time slot. In some implementations, when the SR for the on-demand request conflicts with a PUSCH transmission with UL permission, the PUSCH transmission is dropped. In some implementations, when the SR for the on-demand request conflicts with a PUSCH transmission with UL permission, the SR for the on-demand request is multiplexed on the PUSCH.
[0044] In some implementations, on-demand requests can be transmitted via UCI on the PUSCH (e.g., CG). To support on-demand SSB or SIB1 operation for network energy saving, the CG PUSCH can be used by the UE to transmit on-demand requests when UCI is used on the PUSCH. The CG is periodic. In some implementations, the UE reports UCI during some UL CG transmission times. In some implementations, the UE reports UCI during all UL CG transmission times.
[0045] In addition, to support on-demand SSB or SIB1 operation for network energy saving, the following options can be used when a UCI (e.g., CG PUSCH) on the PUSCH is available for the UE to transmit on-demand requests. In some implementations, the UE reports the UCI regardless of whether the UE has UL data (e.g., a transport block or uplink shared channel (UL-SCH)) to be transmitted at the same UL CG transmission time. In some implementations, the UE reports the UCI only if it has UL data (e.g., a transport block or UL-SCH) to be transmitted at the same UL CG transmission time.
[0046] In some implementations, to support on-demand SSB or SIB1 operation for network energy conservation, CG-UCI and Unused Transmission Opportunities (UTO)-UCI can be used when a UCI on the PUSCH (e.g., CG PUSCH) is available for the UE to transmit on-demand requests. The term "UTO-UCI" refers to an unused transmission opportunity indicated by uplink control information (UCI). The UE can use UTO-UCI to indicate which transmission opportunities it will not use, thereby allowing the network to manage network resources more efficiently. Note that CG-UCI was introduced for NR-U in Release 16 and UTO-UCI for XR in Release 18. In some implementations, the UE transmits the on-demand SSB or SIB request UCI along with CG-UCI / UTO-UCI. In some implementations, the UE can transmit the on-demand SSB or SIB request UCI without transmitting CG-UCI / UTO-UCI.
[0047] Furthermore, to support on-demand SSB or SIB1 operation for network energy saving, the following options can be used regarding PUSCH resource configuration when the UCI on the PUSCH (e.g., CG PUSCH) is used by the UE to transmit on-demand requests. For example, a β offset can be configured for the PUSCH resources used for on-demand requests. In some implementations, a separate β offset can be configured for on-demand UCI (e.g., Therefore, network nodes can configure the β offset separately for on-demand UCI (i.e., UCI carrying on-demand requests). In some implementations, the UE can reuse existing β offsets (e.g., or It should be noted that the β offset is configured by the network node to determine the amount of resources used to reuse different types of UCI in PUSCH.
[0048] In some implementations supporting on-demand SSB or SIB1 operation for network energy saving, when a UCI on the PUSCH (e.g., CG PUSCH) is provided by the UE for transmitting on-demand requests, the UE may or may not multiplex the UCI with HARQ-ACK if the on-demand UCI is scheduled to be transmitted on the same time slot as Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK). In some implementations, the on-demand UCI may be co-coded with HARQ-ACK. The network node can configure whether the UE should co-code the on-demand UCI with HARQ-ACK. When the on-demand UCI is co-coded with HARQ-ACK, the UE can use the β offset configured for HARQ-ACK (i.e., In some implementations, on-demand UCI cannot be co-coded with HARQ-ACK.
[0049] In some implementations, to support on-demand SSB or SIB1 operation for network energy conservation, when a UCI on a PUSCH (e.g., a CG PUSCH) is used by the UE to transmit on-demand requests, the following options can be used for UCI multiplexing in case of a conflict between on-demand UCI and HARQ-ACK. If the network does not configure the UE, or does not allow the UE to multiplex on-demand UCI with HARQ-ACK, conflict handling can be based on priority. In some implementations, if the HARQ-ACK has the same priority as the PUSCH with the on-demand UCI, the UE discards the PUSCH, and the HARQ-ACK is carried by a PUCCH or a different PUSCH. In some implementations, if the HARQ-ACK has a different priority than the PUSCH with the on-demand UCI, the UE discards the one with the lower priority.
[0050] L2 On-Demand Request
[0051] To support on-demand SSB or SIB1 operation for network energy saving, the following options can be used when the MAC-CE is provided to the UE for transmitting on-demand requests. In some implementations, when the UE has uplink permission, the UE can transmit on-demand requests in the MAC-CE carried by the PUSCH based on the uplink permission.
[0052] If the UE does not have uplink permission, it can transmit a scheduling request to request uplink permission for MAC-CE. For example, the UE can transmit a scheduling request to request uplink permission. The network node can receive the scheduling request and use the uplink permission to configure the UE. If the UE is configured using uplink permission, it can use that uplink permission to transmit on-demand requests via MAC-CE.
[0053] Regarding priority, scheduling requests for on-demand requests may have a priority according to one of the following options: In some embodiments, scheduling requests for on-demand requests have the same priority as other non-LRR scheduling requests. In some embodiments, scheduling requests for on-demand requests have the same priority as LRR scheduling requests. In some embodiments, scheduling requests for on-demand requests have a lower priority than non-LRR scheduling requests. In some embodiments, scheduling requests for on-demand requests have a lower priority than LRR scheduling requests but a higher priority than non-LRR scheduling requests.
[0054] To support on-demand SSB or SIB1 operation for NW energy saving, when the MAC-CE is used by the UE to transmit on-demand requests, the MAC-CE may include one or more of the following options: In some embodiments, the MAC-CE may include a single indication of a serving cell in which SSB / SIB1 needs to be transmitted, and the serving cell is the cell in which the UE transmits the MAC-CE. In some embodiments, the MAC-CE may include a list of serving cells (e.g., a list of serving cell IDs) indicating which serving cells the UE requests to transmit SSB / SIB1. In some embodiments, the MAC-CE may include a list of neighboring cells (e.g., a list of Physical Cell Identifiers (PCIs)) indicating which neighboring cells the UE requests to transmit SSB / SIB1. In some embodiments, the MAC-CE may include a list of SSB IDs, with the UE requesting the network to transmit SSBs having those indicated IDs. In some embodiments, the MAC-CE may include a recommended duration for which the UE requests the network to transmit SSB / SIB1. The recommended duration may be in milliseconds, seconds, etc.
[0055] L3 On-Demand Request
[0056] In some implementations, to support on-demand SSB or SIB1 operation for network energy saving, the UE can transmit on-demand requests via RRC through UE Assist Information (UAI).
[0057] In some implementations, to support on-demand SSB or SIB1 operation for network energy saving, for L1-based, L2-based, or L3-based UE on-demand requests, one or more of the following can be considered as conditions allowing the UE to transmit on-demand requests: In some implementations, a condition allowing the UE to transmit on-demand requests is that the UE has Radio Resource Management (RRM) measurements. The RRM measurements required to satisfy the condition may include the serving cell and / or neighboring cells. In some implementations, a condition allowing the UE to transmit on-demand requests is that the UE has time / frequency synchronization for handover or cell reselection. In some implementations, a condition allowing the UE to transmit on-demand requests is that the UE has PRACH configuration. In some implementations, a condition allowing the UE to transmit on-demand requests is that the UE has time / frequency tracking refinement for the serving cell.
[0058] To support on-demand SSB or SIB1 operations for network energy conservation, a disable timer can be introduced for L1-based, L2-based, or L3-based UE on-demand requests to avoid frequent on-demand requests. In some implementations, after a UE transmits an on-demand request, it cannot transmit another on-demand request until the disable timer expires.
[0059] Figure 2 A method 200 performed by a UE according to some implementation schemes is illustrated. The illustrated method 200 includes: generating 202 an on-demand request for a network node in a power-saving state to send one or both of SSB and SIB1. Method 200 further includes: transmitting 204 the on-demand request to the network node via an L1 message, an L2 message, or an L3 message. Method 200 further includes: receiving 206 one or both of SSB and SIB1 from the network node in response to the on-demand request.
[0060] In some implementations, on-demand requests are transmitted via L1 messages, and the L1 messages include PRACH transmissions or UCIs on PUCCH.
[0061] In some implementations, method 200 further includes receiving from a network node a PRACH configuration for PRACH transmission, the PRACH configuration including an index in the frequency domain, time domain, or PRACH preamble.
[0062] In some implementations, the PRACH configuration is received via a carrier different from the carriers corresponding to SSB and SIB1.
[0063] In some implementations, PRACH transmission includes a single PRACH preamble transmission.
[0064] In some implementations, when the UCI on the PUCCH is used to transmit on-demand requests, the UCI is an SR and the SchedulingRequestId used for on-demand requests is only configured for the MCG.
[0065] In some implementations, when a UCI on the PUCCH is used to transmit an on-demand request, the UCI is an SR and the SR used for the on-demand request has the same priority as other non-LRR scheduling requests.
[0066] In some implementations, when the UCI on the PUCCH is used to transmit an on-demand request, the UCI is the SR, and the SR used for the on-demand request is dropped or postponed when the SR conflicts with a PUSCH transmission with uplink permission.
[0067] In some implementations, the on-demand request is transmitted via an L2 message, wherein the L2 message includes a MAC-CE, wherein when the UE has uplink permission, method 200 further includes transmitting the on-demand request in the MAC-CE carried by the PUSCH based on the uplink permission, and wherein when the UE does not have uplink permission, method 200 further includes transmitting a scheduling request to request uplink permission for the MAC-CE.
[0068] In some implementations, on-demand requests include the UE requesting to send a list of serving cells or a list of neighboring cells for SSB or SIB1.
[0069] In some implementations, method 200 further includes determining that one or more conditions are met before transmitting the on-demand request, wherein the conditions include: the UE having RRM measurements, time and frequency synchronization for handover or cell reselection, PRACH configuration, time and frequency tracking refinement for the serving cell, or a combination thereof.
[0070] The embodiments contemplated herein include an apparatus comprising components for performing one or more elements of method 200. This apparatus may be, for example, a UE (such as wireless device 502 as a UE, as described herein).
[0071] The embodiments contemplated herein include one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of method 200. The non-transitory computer-readable medium may be, for example, the memory of a UE (such as memory 506 of a wireless device 502 serving as a UE, as described herein).
[0072] The embodiments contemplated herein include an apparatus comprising logic components, modules, or circuitry for performing one or more elements of method 200. This apparatus may be, for example, a UE (such as wireless device 502 as a UE, as described herein).
[0073] The embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of method 200. The apparatus may be, for example, a UE (such as wireless device 502 as a UE, as described herein).
[0074] The implementation scheme envisioned herein includes a signal as described in or related to one or more elements of method 200.
[0075] The embodiments contemplated herein include a computer program or computer program product comprising instructions, wherein execution by a processor causes the processor to perform one or more elements of method 200. The processor may be a processor of the UE (such as processor 504 as a wireless device 502 of the UE, as described herein). These instructions may, for example, reside in the processor and / or in the memory of the UE (such as memory 506 as a wireless device 502 of the UE, as described herein).
[0076] Figure 3 A method 300 performed by a UE according to some implementation schemes is illustrated. The illustrated method 300 includes entering a power-saving state 302. Method 300 further includes receiving from the UE a request 304 for a network node in the power-saving state to send one or both of SSB and SIB1. The request is received via an L1 message, an L2 message, or an L3 message. Method 300 further includes transmitting to the UE 306 one or both of SSB and SIB1 in response to the request.
[0077] In some implementations, on-demand requests are received via L1 messages, and the L1 messages include PRACH transmissions or UCIs on PUCCH.
[0078] In some implementations, method 300 further includes transmitting to the UE a PRACH configuration for PRACH transmission, the PRACH configuration including an index in the frequency domain, time domain, or PRACH preamble.
[0079] In some implementations, the PRACH configuration is transmitted via a carrier different from the carriers corresponding to SSB and SIB1.
[0080] In some implementations, PRACH transmission includes a single PRACH preamble transmission.
[0081] In some implementations, when the UCI on the PUCCH is used to receive on-demand requests, the UCI is an SR and the SchedulingRequestId used for on-demand requests is only configured for the MCG.
[0082] In some implementations, when the UCI on the PUCCH is used to receive on-demand requests, the UCI is an SR and the SR used for on-demand requests has the same priority as other non-LRR scheduling requests.
[0083] In some implementations, when the UCI on the PUCCH is used to receive on-demand requests, the UCI is the SR and the SR used for on-demand requests is dropped or postponed when the SR conflicts with a PUSCH transmission with uplink permission.
[0084] In some implementations, the on-demand request is received via an L2 message, wherein the L2 message includes a MAC-CE, wherein when the UE has uplink permission, method 300 further includes receiving the on-demand request in the MAC-CE carried by the PUSCH based on the uplink permission, and wherein when the UE does not have uplink permission, method 300 further includes receiving a scheduling request to request uplink permission for the MAC-CE.
[0085] In some implementations, on-demand requests include the UE requesting to send a list of serving cells or a list of neighboring cells for SSB or SIB1.
[0086] The embodiments contemplated herein include an apparatus comprising components for performing one or more elements of method 300. This apparatus may be, for example, a base station (such as network device 518 as described herein, serving as a base station).
[0087] The embodiments contemplated herein include one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of method 300. The non-transitory computer-readable medium may be, for example, the memory of a base station (such as memory 522 of a network device 518 serving as a base station, as described herein).
[0088] The embodiments contemplated herein include an apparatus comprising logic components, modules, or circuitry for performing one or more elements of method 300. This apparatus may be, for example, an apparatus for a base station (such as network device 518 as a base station, as described herein).
[0089] The embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of method 300. The apparatus may be, for example, an apparatus for a base station (such as network device 518 as a base station, as described herein).
[0090] The implementation scheme envisioned herein includes a signal as described in or related to one or more elements of method 300.
[0091] The embodiments contemplated herein include a computer program or computer program product comprising instructions, wherein execution by a processing element causes the processing element to perform one or more elements of method 300. The processor may be a processor of a base station (such as processor 520 of network device 518 as a base station, as described herein). These instructions may, for example, reside in the processor and / or in the memory of the base station (such as memory 522 of network device 518 as a base station, as described herein).
[0092] Figure 4 An example architecture of a wireless communication system 400 according to an embodiment disclosed herein is illustrated. The following description is provided for an example wireless communication system 400 operating in conjunction with LTE system standards and / or 5G or NR system standards provided by 3GPP technical specifications.
[0093] like Figure 4 As shown, the wireless communication system 400 includes UE 402 and UE 404 (but any number of UEs may be used). In this example, UE 402 and UE 404 are exemplified as smartphones (e.g., handheld touchscreen mobile computing devices capable of connecting to one or more cellular networks), but may also include any mobile or non-mobile computing device configured for wireless communication.
[0094] UE 402 and UE 404 can be configured to communicatively couple with RAN 406. In an embodiment, RAN 406 can be NG-RAN, E-UTRAN, etc. UE 402 and UE 404 utilize connections (or channels) with RAN 406 (shown as connection 408 and connection 410, respectively), each of these connections including a physical communication interface. RAN 406 may include one or more base stations (such as base station 412 and base station 414) implementing connection 408 and connection 410.
[0095] In this example, Connection 408 and Connection 410 are the air interfaces that enable this communication coupling and are compliant with the RAT used by RAN 406, such as LTE and / or NR, for example.
[0096] In some implementations, UE 402 and UE 404 may also exchange communication data directly via sidelink interface 416. UE 404 is shown configured to access an access point (shown as AP 418) via connection 420. For example, connection 420 may include a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, while AP 418 may include Wi-Fi. ® Router. In this example, AP 418 may connect to another network (e.g., the Internet) without using CN 424.
[0097] In the implementation, UE 402 and UE 404 may be configured to communicate with each other or with base station 412 and / or base station 414 on a multi-carrier communication channel using orthogonal frequency division multiplexing (OFDM) communication signals according to various communication technologies, such as, but not limited to, orthogonal frequency division multiple access (OFDMA) communication technology (e.g., for downlink communication) or single-carrier frequency division multiple access (SC-FDMA) communication technology (e.g., for uplink and ProSe or sidelink communication)); however, the scope of the implementation is not limited in this respect. The OFDM signal may include multiple orthogonal subcarriers.
[0098] In some implementations, all or some of the base stations in base station 412 or base station 414 may be implemented as one or more software entities running on a server computer as part of a virtual network. Furthermore, or in other implementations, base station 412 or base station 414 may be configured to communicate with each other via interface 422. In implementations where the wireless communication system 400 is an LTE system (e.g., when CN 424 is an EPC), interface 422 may be an X2 interface. The X2 interface may be defined between two or more base stations (e.g., two or more eNBs, etc.) connected to the EPC and / or between two eNBs connected to the EPC. In implementations where the wireless communication system 400 is an NR system (e.g., when CN 424 is a 5GC), interface 422 may be an Xn interface. The Xn interface is defined between two or more base stations (e.g., two or more gNBs, etc.) connected to the 5GC, between a base station 412 (e.g., a gNB) connected to the 5GC and an eNB, and / or between two eNBs connected to the 5GC (e.g., CN 424).
[0099] RAN 406 is shown communicatively coupled to CN 424. CN 424 may include one or more network elements 426 configured to provide various data and telecommunications services to customers / subscribers (e.g., users of UE 402 and UE 404) connected to CN 424 via RAN 406. Components of CN 424 may be implemented in a single physical device or a separate physical device including components for reading and executing instructions from machine-readable or computer-readable media (e.g., non-transitory machine-readable storage media).
[0100] In the implementation scheme, CN 424 may be an EPC, and RAN 406 may be connected to CN 424 via S1 interface 428. In the implementation scheme, S1 interface 428 may be divided into two parts: an S1 user plane (S1-U) interface, which carries service data between base station 412 or base station 414 and service gateway (S-GW); and an S1-MME interface, which is the signaling interface between base station 412 or base station 414 and mobility management entity (MME).
[0101] In the implementation scheme, CN 424 may be a 5GC, and RAN 406 may be connected to CN 424 via NG interface 428. In the implementation scheme, NG interface 428 may be divided into two parts: an NG user plane (NG-U) interface, which carries service data between base station 412 or base station 414 and user plane function (UPF); and an S1 control plane (NG-C) interface, which is the signaling interface between base station 412 or base station 414 and access and mobility management function (AMF).
[0102] Generally, application server 430 may be an element that provides applications (e.g., packet-switched data services) that use Internet Protocol (IP) bearer resources with CN 424. Application server 430 may also be configured to support one or more communication services (e.g., VoIP sessions, group communication sessions, etc.) for UE 402 and UE 404 via CN 424. Application server 430 can communicate with CN 424 through IP communication interface 432.
[0103] Figure 5 A system 500 for performing signaling transfer 534 between a wireless device 502 and a network device 518 according to an embodiment disclosed herein is illustrated. System 500 may be part of a wireless communication system as described herein. Wireless device 502 may be, for example, a UE (User Equipment) of a wireless communication system. Network device 518 may be, for example, a base station (e.g., an eNB or gNB) of a wireless communication system.
[0104] Wireless device 502 may include one or more processors 504. Processor 504 is executable instructions that cause various operations of wireless device 502 to be performed as described herein. Processor 504 may include one or more baseband processors, which are implemented using, for example, a central processing unit (CPU), digital signal processor (DSP), application-specific integrated circuit (ASIC), controller, field-programmable gate array (FPGA) device, another hardware device, firmware device, or any combination thereof configured to perform the operations described herein.
[0105] Wireless device 502 may include memory 506. Memory 506 may be a non-transitory computer-readable storage medium that stores instructions 508, which may include, for example, instructions executed by processor 504. Instructions 508 may also be referred to as program code or a computer program. Memory 506 may also store data used by processor 504 and results calculated by the processor.
[0106] Wireless device 502 may include one or more transceivers 510, which may include radio frequency (RF) transmitter circuitry and / or receiver circuitry, which use antenna 512 of wireless device 502 to facilitate signaling to and / or from wireless device 502 and other devices (e.g., signaling 534) in accordance with corresponding RAT.
[0107] Wireless device 502 may include one or more antennas 512 (e.g., one, two, four or more). In embodiments with multiple antennas 512, wireless device 502 may fully utilize the spatial diversity of such multiple antennas 512 to transmit and / or receive multiple different data streams on the same time-frequency resources. This behavior may be referred to as, for example, multiple-input multiple-output (MIMO) behavior (referring to multiple antennas used at each of the transmitting and receiving devices to implement this aspect). MIMO transmission by wireless device 502 may be implemented according to pre-decoding (or digital beamforming) applied to wireless device 502, which multiplexes the data streams among antennas 512 based on known or assumed channel characteristics, such that each data stream is received with appropriate signal strength relative to the others at a desired location in the spatial domain (e.g., the location of the receiver associated with that data stream). Some implementations may use a single-user MIMO (SU-MIMO) approach (where all data streams are directed to a single receiver) and / or a multi-user MIMO (MU-MIMO) approach (where individual data streams may be directed to individual (different) receivers at different locations in the airspace).
[0108] In some implementations with multiple antennas, wireless device 502 can implement analog beamforming technology, whereby the phase of the signal transmitted by antenna 512 is relatively adjusted so that the (joint) transmission of antenna 512 can be directed (this is sometimes referred to as beam control).
[0109] Wireless device 502 may include one or more interfaces 514. Interfaces 514 can be used to provide input to or output to wireless device 502. For example, wireless device 502 as a UE may include interfaces 514, such as microphones, speakers, touchscreens, and buttons, to allow input and / or output from a user of the UE to the UE. Other interfaces of such UEs may consist of transmitters, receivers, and other circuitry that allow the UE to communicate with other devices (e.g., in addition to the transceiver 510 / antenna 512 described), and may be based on known protocols (e.g., Wi-Fi). ® and Bluetooth ® (etc.) to perform the operation.
[0110] Wireless device 502 may include an on-demand request module 516. The on-demand request module 516 may be implemented via hardware, software, or a combination thereof. For example, the on-demand request module 516 may be implemented as a processor, circuitry, and / or instructions 508 stored in memory 506 and executed by processor 504. In some examples, the on-demand request module 516 may be integrated within processor 504 and / or transceiver 510. For example, the on-demand request module 516 may be implemented via a combination of software components (e.g., executed by a DSP or general-purpose processor) and hardware components (e.g., logic gates and circuitry) within processor 504 or transceiver 510.
[0111] The on-demand request module 516 can be used in various aspects of this disclosure, for example, Figures 1 to 4 All aspects. The on-demand request module 516 is configured to generate on-demand requests for SSB or SIB1 for transmission by transceiver 510.
[0112] Network device 518 may include one or more processors 520. Processor 520 may execute instructions to perform various operations of network device 518 as described herein. Processor 520 may include one or more baseband processors, which may be implemented using, for example, a CPU, DSP, ASIC, controller, FPGA device, another hardware device, firmware device, or any combination thereof configured to perform the operations described herein.
[0113] Network device 518 may include memory 522. Memory 522 may be a non-transitory computer-readable storage medium that stores instructions 524, which may include, for example, instructions executed by processor 520. Instructions 524 may also be referred to as program code or a computer program. Memory 522 may also store data used by processor 520 and results calculated by the processor.
[0114] Network device 518 may include one or more transceivers 526, which may include RF transmitter circuitry and / or receiver circuitry that use antenna 528 of network device 518 to facilitate signaling transmission to and / or from network device 518 and other devices (e.g., signaling transmission 534) in accordance with corresponding RAT.
[0115] Network device 518 may include one or more antennas 528 (e.g., one, two, four or more). In embodiments having multiple antennas 528, network device 518 may perform MIMO, digital beamforming, analog beamforming, beam control, etc., as described.
[0116] Network device 518 may include one or more interfaces 530. Interfaces 530 may be used to provide input to or output to network device 518. For example, network device 518 as a base station may include interfaces 530 consisting of transmitters, receivers, and other circuitry (e.g., in addition to the transceiver 526 / antenna 528 described), which enable the base station to communicate with other equipment in the core network and / or to communicate with external networks, computers, databases, etc., for the purpose of performing operations, management, and maintenance of the base station or other equipment operatively connected to the base station.
[0117] Network device 518 may include an on-demand response module 532. The on-demand response module 532 may be implemented via hardware, software, or a combination thereof. For example, the on-demand response module 532 may be implemented as a processor, circuitry, and / or instructions 524 stored in memory 522 and executed by processor 520. In some examples, the on-demand response module 532 may be integrated within processor 520 and / or transceiver 526. For example, the on-demand response module 532 may be implemented via a combination of software components (e.g., executed by a DSP or general-purpose processor) and hardware components (e.g., logic gates and circuitry) within processor 520 or transceiver 526.
[0118] The on-demand response module 532 can be used in various aspects of this disclosure, for example, Figures 1 to 4All aspects. The on-demand response module 532 is configured to receive and identify on-demand requests when the network device 518 is performing network energy-saving operations, and to cause the network device 518 to transmit SSB and / or SIB1 in response.
[0119] For one or more embodiments, at least one of the components illustrated in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, and / or methods as described herein. For example, a baseband processor as described herein in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples illustrated herein. Similarly, circuitry associated with a UE, base station, network element, etc., as described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples illustrated herein.
[0120] Unless otherwise explicitly stated, any of the embodiments described above may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific embodiments provides illustrative and descriptive information, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. In light of the teachings above, modifications and variations are possible, or modifications and variations may be derived from practice with various embodiments.
[0121] Implementations and specific embodiments of the systems and methods described herein may include various operations embodied in machine-executable instructions to be executed by a computer system. The computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system may include hardware components, including specific logical parts for performing the operations; or may include a combination of hardware, software, and / or firmware.
[0122] It should be recognized that the systems described herein include descriptions of specific implementations. These implementations may be combined into a single system, partially integrated into other systems, divided into multiple systems, or otherwise partitioned or combined. Furthermore, it is conceivable to use parameters, attributes, aspects, etc., of one implementation in one implementation. For clarity, these parameters, attributes, aspects, etc., are described only in one or more implementations, and it should be recognized that, unless expressly stated herein, these parameters, attributes, aspects, etc., may be combined with or substituted for parameters, attributes, aspects, etc., of another implementation.
[0123] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.
[0124] Although the foregoing has been described in considerable detail for clarity, it will be apparent that certain changes and modifications can be made without departing from the principles of the invention. It should be noted that there are many alternative ways to implement both the processes and apparatus described herein. Therefore, embodiments of the invention should be considered illustrative rather than restrictive, and this specification is not limited to the details given herein, but can be modified within the scope and equivalents of the appended claims.
Claims
1. A method for user equipment (UE), the method comprising: Generate on-demand requests for network nodes in power-saving mode to send one or both of the Synchronization Signal Block (SSB) and System Information Block 1 (SIB1); The on-demand request is transmitted to the network node via Layer 1 (L1) messages, Layer 2 (L2) messages, or Layer 3 (L3) messages; and In response to the on-demand request, one or both of the SSB and the SIB1 are received from the network node.
2. The method of claim 1, wherein the on-demand request is transmitted via the L1 message, and wherein the L1 message includes uplink control information (UCI) transmitted on the Physical Random Access Channel (PRACH) or on the Physical Uplink Control Channel (PUCCH).
3. The method according to claim 2, further comprising: Receive from the network node a PRACH configuration for PRACH transmission, the PRACH configuration including an index in the frequency domain, time domain, or PRACH preamble.
4. The method of claim 3, wherein the PRACH configuration is received via a carrier different from the carrier corresponding to the SSB and the SIB1.
5. The method of claim 2, wherein the PRACH transmission includes a single PRACH preamble transmission.
6. The method of claim 2, wherein when the UCI on the PUCCH is used to transmit the on-demand request, the UCI is a scheduling request (SR) and the SchedulingRequestId for the on-demand request is configured only for the primary cell group (MCG).
7. The method of claim 2, wherein when the UCI on the PUCCH is used to transmit the on-demand request, the UCI is a scheduling request (SR), and wherein the SR used for the on-demand request has the same priority as other non-link recovery request (LRR) scheduling requests.
8. The method of claim 2, wherein when the UCI on the PUCCH is used to transmit the on-demand request, the UCI is a scheduling request (SR), and wherein when the SR conflicts with a PUSCH transmission with uplink permission, the SR for the on-demand request is dropped or postponed.
9. The method of claim 1, wherein the on-demand request is transmitted via the L2 message, and wherein the L2 message includes a Media Access Control (MAC) control element (CE). When the UE has uplink permission, the method further includes: Based on the uplink permission, the on-demand request is transmitted in the MAC-CE carried by the Physical Uplink Shared Channel (PUSCH), and When the UE does not have the uplink permission, the method further includes: transmitting a scheduling request to request uplink permission for the MAC-CE.
10. The method of claim 1, wherein the on-demand request includes the UE requesting the network node to send the serving cell list or neighboring cell list of the SSB or the SIB1.
11. The method according to claim 1, further comprising: Before transmitting the on-demand request, it is determined that one or more conditions are met, including: the UE has radio resource management (RRM) measurements, time and frequency synchronization for handover or cell reselection, physical random access channel (PRACH) configuration, time and frequency tracking refinement for the serving cell, or a combination thereof.
12. A method for a network node, the method comprising: Enter power-saving mode; Receives on-demand requests from the user equipment (UE) for the network node in the power-saving state to transmit one or both of a synchronization signal block (SSB) and a system information block 1 (SIB1). The on-demand request is received via a Layer 1 (L1) message, a Layer 2 (L2) message, or a Layer 3 (L3) message; and In response to the on-demand request, one or both of the SSB and the SIB1 are transmitted to the UE.
13. The method of claim 12, wherein the on-demand request is received via the L1 message, and wherein the L1 message includes uplink control information (UCI) transmitted on the Physical Random Access Channel (PRACH) or on the Physical Uplink Control Channel (PUCCH).
14. The method according to claim 13, further comprising: The PRACH configuration for PRACH transmission is transmitted to the UE, the PRACH configuration including frequency domain, time domain, or PRACH preamble index.
15. The method of claim 14, wherein the PRACH configuration is transmitted via a carrier different from the carrier corresponding to the SSB and the SIB1.
16. The method of claim 13, wherein the PRACH transmission comprises a single PRACH preamble transmission.
17. The method of claim 13, wherein when the UCI on the PUCCH is used to receive the on-demand request, the UCI is a scheduling request (SR) and the SchedulingRequestId for the on-demand request is configured only for the primary cell group (MCG).
18. The method of claim 13, wherein when the UCI on the PUCCH is used to receive the on-demand request, the UCI is a scheduling request (SR), and wherein the SR used for the on-demand request has the same priority as other non-link recovery request (LRR) scheduling requests.
19. The method of claim 12, wherein the on-demand request is received via the L2 message, and wherein the L2 message includes a Media Access Control (MAC) control element (CE). When the UE has uplink permission, the method further includes: Based on the uplink permission, the on-demand request is received in the MAC-CE carried by the Physical Uplink Shared Channel (PUSCH), and When the UE does not have the uplink permission, the method further includes: receiving a scheduling request to request uplink permission for the MAC-CE.
20. A user equipment (UE) device, the user equipment (UE) device comprising: processor; and The memory stores instructions that, when executed by the processor, configure the UE device to: Generate on-demand requests for network nodes in power-saving mode to send one or both of the Synchronization Signal Block (SSB) and System Information Block 1 (SIB1); The on-demand request is transmitted to the network node via Layer 1 (L1) messages, Layer 2 (L2) messages, or Layer 3 (L3) messages; and In response to the on-demand request, one or both of the SSB and the SIB1 are received from the network node.
21. An apparatus comprising components for performing the method according to any one of claims 1 to 19.
22. A computer-readable medium comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform the method according to any one of claims 1 to 19.
23. An apparatus comprising a logic component, module, or circuit for performing the method according to any one of claims 1 to 19.
24. A baseband processor for a user equipment (UE), the baseband processor being configured to cause the UE to perform one or more elements according to any one of claims 1 to 11.
25. A baseband processor for a network node, the baseband processor being configured to cause the network node to perform one or more elements according to any one of claims 12 to 19.
