User equipment with reduced capability handling of emergency call in barred access cell

By introducing an emergency support field in system information block 1, RedCap and eRedCap UEs are allowed to initiate emergency calls in prohibited access cells, which solves the problem that UEs cannot initiate emergency calls in prohibited access cells and ensures the reliability of emergency services.

CN122122932APending Publication Date: 2026-05-29APPLE INC

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
APPLE INC
Filing Date
2023-11-01
Publication Date
2026-05-29

Smart Images

  • Figure CN122122932A_ABST
    Figure CN122122932A_ABST
Patent Text Reader

Abstract

This application relates to devices and assemblies, including apparatuses, systems, and methods for providing emergency calls for user equipment with reduced capabilities via barred access cells in a wireless communication system.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of wireless technology, and more specifically to emergency call processing of degraded user equipment in restricted access cells. Background Technology

[0002] The 3GPP (3rd Generation Partnership Project) network enables User Equipment (UE) to operate with reduced capabilities for various reasons. For example, it allows UEs to operate with a single receive chain and / or in half-duplex (FDD) operation. However, during normal operation, one or more cells in the 3GPP network may not support calls initiated by a UE with reduced capabilities. The UE can identify these unsupported cells as prohibited access cells and avoid using such prohibited access cells when initiating calls. Attached Figure Description

[0003] Figure 1 Example tables illustrating use case information based on some implementation schemes are provided.

[0004] Figure 2 Example information blocks for preventing access to a cell are shown according to some implementation schemes.

[0005] Figure 3 Example network layouts based on some implementation schemes are illustrated.

[0006] Figure 4 Example signaling diagrams based on some implementation schemes are shown.

[0007] Figure 5 An example system information block 1 (SIB1) information element related to method 5 is illustrated according to some implementation schemes.

[0008] Figure 6 Example SIB1 information elements related to method 6 are shown according to some implementation schemes.

[0009] Figure 7 Example SIB1 information elements related to method 7 are illustrated according to some implementation schemes.

[0010] Figure 8 Example SIB1 information elements related to method 8 are shown according to some implementation schemes.

[0011] Figure 9 Example processes based on some implementation schemes are illustrated.

[0012] Figure 10 Example processes based on some implementation schemes are illustrated.

[0013] Figure 11 Example processes based on some implementation schemes are illustrated.

[0014] Figure 12 Exemplary user equipment (UE) according to some implementation schemes are illustrated.

[0015] Figure 13 An example next-generation node B (gNB) according to some implementation schemes is illustrated. Detailed Implementation

[0016] The following detailed description refers to the accompanying drawings. The same reference numerals may be used in different drawings to identify the same or similar elements. In the following description, specific details, such as particular structures, architectures, interfaces, technologies, etc., are set forth for illustrative and not limiting purposes in order to provide a thorough understanding of various aspects of the various embodiments. However, it will be apparent to those skilled in the art that various aspects of the various embodiments may be practiced in other examples departing from these specific details. In some instances, descriptions of well-known devices, circuits, and methods have been omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of this document, the phrase “A or B” means (A), (B), or (A and B); and the phrase “based on A” means “at least partially based on A,” for example, it can be “based only on A” or it can be “partially based on A.”

[0017] The following is a glossary of terms that may be used in this disclosure.

[0018] As used herein, the term "circuit" refers to, is part of, or includes the following: hardware components such as electronic circuits, logic circuits, processors (shared, dedicated, or grouped) or memories (shared, dedicated, or grouped), application-specific integrated circuits (ASICs), field-programmable devices (FPDs) (e.g., field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), structured ASICs, or programmable system-on-chips (SoCs)), digital signal processors (DSPs), etc. In some embodiments, the circuit may execute one or more software or firmware programs to provide at least some of the described functionalities. The term "circuit" may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) and program code for executing the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuit.

[0019] As used herein, the term "processor circuit" means, is part of, or includes a circuit capable of sequentially and automatically performing a series of arithmetic or logical operations or recording, storing, or transmitting digital data. The term "processor circuit" may also refer to an application processor, baseband processor, central processing unit (CPU), graphics processing unit, single-core processor, dual-core processor, triple-core processor, quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions (such as program code, software modules, and / or functional procedures).

[0020] As used herein, the term "interface circuit" refers to, is part of, or includes a circuit that enables the exchange of information between two or more components or devices. The term "interface circuit" can refer to one or more hardware interfaces, such as buses, I / O interfaces, peripheral component interfaces, or network interface cards.

[0021] As used herein, the term "user equipment" or "UE" refers to a device with radio communication capabilities and can describe network resources in a communication network. Furthermore, the term "user equipment" or "UE" can be considered synonymous and can refer to a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Additionally, the term "user equipment" or "UE" can include any type of wireless / wired equipment or any computing device that includes a wireless communication interface.

[0022] As used herein, the term "computer system" means any type of interconnected electronic device, computer device, or component thereof. Additionally, the term "computer system" or "system" may refer to various components of a computer that are communicatively coupled to each other. Furthermore, the term "computer system" or "system" may refer to multiple computer devices or multiple computing systems that are communicatively coupled to each other and configured to share computing resources or network resources.

[0023] As used herein, the term "resource" refers to physical or virtual devices, physical or virtual components within a computing environment, or physical or virtual components within a specific device, such as computer equipment, mechanical equipment, memory space, processor / CPU time, processor / CPU utilization, processor and accelerator load, hardware time or utilization, power supply, input / output operations, port or network sockets, channel / link allocation, throughput, memory utilization, storage, network, databases and applications, units of workload, etc. "Hardware resource" can refer to computing, storage, or networking resources provided by physical hardware components. "Virtualized resource" can refer to computing, storage, or networking resources provided by virtualization infrastructure to applications, devices, systems, etc. The terms "network resource" or "communication resource" can refer to resources that a computer device / system can access via a communication network. The term "system resource" can refer to any kind of shared entity providing services and can include computing or network resources. System resources can be considered as a coherent set of functions, network data objects, or services that can be accessed through a server, wherein such system resources reside on a single host or multiple hosts and can be clearly identified.

[0024] As used herein, the term "channel" refers to any tangible or intangible transmission medium used to transmit data or data streams. The term "channel" may be synonymous or equivalent with "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," or any other similar term indicating a means or medium through which data is transmitted. Additionally, as used herein, the term "link" refers to a connection between two devices used for transmitting and receiving information.

[0025] As used in this article, the terms "instantiate" and "instantiate" refer to the creation of an instance. "Instance" also refers to the concrete occurrence of an object, which may occur, for example, during the execution of program code.

[0026] The term "connection" can refer to an established signaling relationship between two or more elements at a common communication protocol layer through a communication channel, link, interface, or reference point.

[0027] As used herein, the term "network element" refers to physical or virtualized equipment or infrastructure used to provide wired or wireless communication network services. The term "network element" may be considered synonymous with or referred to as networked computers, network hardware, network equipment, network nodes, virtualized network functions, etc.

[0028] The term "information element" refers to a structural element that contains one or more fields. The term "field" refers to the individual content of an information element, or the data element that contains that content. An information element may include one or more additional information elements.

[0029] As used herein, the term "at least partially based on" can indicate that an item is based solely on another item and / or on an item of another item plus one or more additional items. For example, in an embodiment, determining item 1 based at least partially on item 2 can indicate determining item 1 based solely on item 2 and / or determining item 1 based on item 2 and one or more other items.

[0030] As used herein, the term "(e)RedCap UE" can refer to a RedCap UE and / or an enhanced RedCap UE. For example, a statement indicating that an (e)RedCap UE is capable of accessing a cell may mean that both RedCap UEs and eRedCap UEs are capable of accessing the cell.

[0031] During operation, a user equipment (UE) with reduced capabilities can determine that certain cells within the network will be considered blocked from access based on the fact that one or more cells do not support the UE with reduced capabilities. The UE may avoid initiating calls on these cells, and / or these cells may also block call establishment for the UE with reduced capabilities. Problems may arise when all available cells in the location of the UE with reduced capabilities do not support it. In conventional approaches, a UE with reduced capabilities would be unable to make calls, including emergency calls. The method described herein enables a UE with reduced capabilities to complete emergency calls using blocked access cells that do not support non-emergency calls.

[0032] Objectives of the Research Project of Working Group 2 (RAN2) for Radio Access Networks The first identified objective (which may be referred to as Objective 1) may include identifying and studying potential UE complexity reduction features, including [Radio Access Networks Working Group 1 (RAN1), RAN2] reduced number of UE receive (RX) / transmit (TX) antennas, UE bandwidth reduction, half-duplex-frequency division duplex (FDD), relaxed UE processing time and / or relaxed UE processing capabilities. Regarding UE bandwidth reduction, it should be noted that the Release 15 (Rel-15) Synchronization Signal Block (SSB) bandwidth should be reused, and Layer 1 (L1) modifications should be minimized.

[0033] The second identified objective (which may be referred to as Objective 2) may include investigating UE power savings and battery life enhancements [RAN2, RAN1] for UEs with reduced capabilities in applicable use cases (e.g., latency tolerance), including reducing physical downlink control channel (PDCCH) monitoring [RAN1] through a smaller number of blind decoding and control channel element (CCE) limitations. Furthermore, extended discontinuous reception (DRX) in radio resource control (RRC) inactive and / or idle [RAN2] states may be investigated.

[0034] Further analysis on usage User equipment within the network can include a variety of different use cases. One type of use case is Industrial Internet. Industrial Internet can include devices that are not part of Ultra Reliable Low Latency Communication (URLLC) / Industrial Internet of Things (IIOT) but exist as part of Industrial Internet. Such devices are not highly sensitive to latency, are fixed in location (low mobility), and / or have low complexity in terms of capabilities and hardware.

[0035] Another type of use case could include monitoring. Monitoring may be very similar to the requirements of Industrial Connectivity, but with a higher UL data rate.

[0036] Another type of use case may include wearable devices. Wearable devices may have higher uplink (UL) / downlink (DL) data rates, comparable mobility to conventional UEs, high power saving requirements, and / or lower hardware complexity.

[0037] Figure 1 Example Table 100 illustrates use case information according to some implementation schemes. For example, Table 100 illustrates information for the different use cases mentioned above.

[0038] Enhanced capability reduction (eRedCap) information eRedCap is a feature of the planned version (Rel-18) with further reductions in planned capabilities (compared to RedCap version (R17) devices). eRedCap further reduces UE complexity in the frequency range FR1 [RAN1, RAN2, RAN4]. UE broadband (BB) bandwidth reduction is enabled. The reduced UE BB bandwidth may include 5 MHz BB bandwidth used only for the Physical Downlink Shared Channel (PDSCH) (for both unicast and broadcast) and the Physical Uplink Shared Channel (PUSCH), and 20 MHz RF bandwidth used for UL and DL. Other physical channels and signals may still be allowed to use a portion of the UE RF+BB bandwidth up to a maximum of 20 MHz (BWP).

[0039] eRedCap may reduce UE peak data rate. The constraint on peak data rate reduction can be relaxed (vLayers·Qm·f ≥ 4). The relaxed constraint can be, for example, 1 (instead of 4). The parameters (vLayers, Qm, f) can be the same as in version 17 (Rel-17) RedCap.

[0040] It supports 15kHz and 30kHz SCS. The legacy UE capability framework can be used, and changes to capability signaling can be specified only when necessary. By default, all UE capabilities applicable to Rel-17 RedCap UEs are available unless otherwise stated.

[0041] UE-executed cell access denial - traditional RAN2 logic If a UE cannot support "basic" DL and UL capabilities to support connected-mode sessions, the UE may disable access to the cell. Some capabilities may include unsupported channel bandwidths, including carrier and BWP bandwidth. Additionally, some capabilities may include unsupported subcarrier spacing for operating frequency / bandwidth (BW).

[0042] Features not supported by the cell may include subcarrier offsets supported by non-terrestrial networks (NTN) and / or used for RedCap capability reduction. For RedCap UEs, the cell does not want them to operate in 1 Rx chain and / or 2 Rx chain modes within the cell. For enhanced RedCap capability reduction (eRedCap) UEs, the cell does not want them to operate in 1 Rx chain and / or 2 Rx chain modes within the cell. Furthermore, the cell also does not want the UE to operate in half-duplex mode within the cell, which is the same for both RedCap and eRedCap.

[0043] The UE is expected to mark cells that do not support its simplified features as "Access Denied". In conventional implementations, UEs are not allowed to initiate emergency calls on these cells. Figure 2 Example information block 200 for cell access denial according to some implementation schemes is illustrated. For example, information block 200 provides information about when a UE may consider a cell to be access denial (e.g., assigning a “denied access” state to the cell) and / or the UE’s operations relative to the cell to which access is denied.

[0044] Statement of Issues Many wearable UE types are RedCap UEs and eRedCap UEs. They provide voice services to users and should allow them to make emergency calls! In the conventional scenario where (e)RedCap UEs must "deny access" to the cell due to undesirable sub-features of the UE, the UE cannot provide EM call services to users. Crucially, the provision of emergency (EM) calls must be guaranteed even when the network (NW) is "capable" of handling them! For example, even when the NW prefers a 2Rx (e)RedCap UE, it should be able to handle Internet Protocol Multimedia Subsystem (IMS)-based EM calls using a 1Rx (single MIMO layer). Furthermore, the NW should support the ability to schedule DL / UL for IMS-based EM calls in half-duplex mode. In these cases, conventional methods do not provide EM calls. How can this problem be solved? The method described in this paper provides options to address the issue of supporting EM calls for eRedCap UEs and / or RedCap UEs.

[0045] method UE idle mode behavior When a UE powers on or transitions from connected mode to idle (inactive) mode, the UE can be in an "arbitrary cell selection state". The UE can search for cells (see Technical Specification (TS) 38.304 - Sections 5.2.7 / 5.2.8 (sec)) (Technical Specification 38.304 (3rd Generation Partnership Project; Technical Specification Group Radio Access Networks; NR; User Equipment (UE) Procedures in Idle Mode and RRC Inactive State (Revision 17). (2023).) 3GPP TS 38.304, 17.6.0 The purpose of the search can be to find a suitable cell. If found, the UE can transition to a "normal camping" state. If no suitable cell is found, the UE can attempt to find an acceptable cell. If no acceptable cell is found, the UE can transition to a "camping on any cell" state and remain in that state. It is anticipated that the UE may attempt the search again based on external triggering conditions (e.g., when a user initiates a call, or periodically).

[0046] An acceptable cell can be a cell that is not prohibited from access (as defined in Section 5.3.1 of TS 38.304). It can also meet the cell selection criteria (as defined in Section 5.2.3.2 of TS 38.304).

[0047] A suitable cell can be a cell that is not prohibited from access (as defined in Section 5.3.1 of TS 38.304). It can meet the cell selection criteria (as defined in Section 5.2.3.2 of TS 38.304). The cell can be part of a registered Public Land Mobile Network (PLMN), and there may be other requirements.

[0048] Methodological directions for using UE idle mode behavior One objective is to make the approach as simple as possible, minimizing changes to the UE process. Another objective is to ensure backward compatibility. If this change request (CR) is introduced in Rel-18, it will allow R17 UEs to also implement this change.

[0049] One approach is to allow the UE to consider cells that it has previously blocked from access as "acceptable" cells. The following series of methods will propose various implementation approaches based on the above logic.

[0050] Figure 3 Example network arrangement 300 according to some implementation schemes is illustrated. The methods described throughout this disclosure can be implemented within network arrangement 300. For example, the network illustrated by network arrangement 300, or a portion thereof, can implement one or more methods described throughout this disclosure to provide emergency support for emergency calls made by a UE via a prohibited access cell.

[0051] Network deployment 300 may include base station 302. Base station 302 may include next-generation node B (gNB) 1300 ( Figure 13 The base station 302 may be coupled to, or may include at least a portion of, the core network of a network capable of providing services to the UE.

[0052] Base station 302 may host one or more cells. For example, in the illustrated implementation, base station 302 hosts a first cell 304, a second cell 306, and a third cell 308. Each of these cells may define an area where the UE can access services. As shown in the illustrated implementation, these areas of the cells may overlap.

[0053] Each of these cells may have different capabilities, and one or more cells may not support certain capabilities. For example, one or more of these cells may not support UEs operating on a 1 RX chain and / or may not support UEs operating in half-duplex frequency division duplex (HD-FDD), at least for non-emergency calls.

[0054] Network deployment 300 may include UE 310. UE 310 may be a RedCap UE or an eRedCap UE. UE 310 may be located in one or more cells. For example, in the illustrated embodiment, UE 310 is located in a first cell 304, a second cell 306, and a third cell 308. UE 310 may attempt to connect to the network (e.g., via base station 302) and / or may collect information from the network about the different cells in which UE 310 is located (e.g., via base station 302).

[0055] UE 310 may receive System Information Block 1 (SIB1), which provides information about the cell where UE 310 is located. For example, UE 310 may receive SIB1 for each cell for which UE 310 is searching for information, and / or may receive a single SIB1 providing information about multiple cells. UE 310 may determine whether a cell, or which of these cells, supports UE 310's requirements, such as UE 310's 1 RX chain and / or HD-FDD requirements. If UE 310 determines that a cell does not support UE 310's requirements, UE 310 may treat that cell as a forbidden access cell (which may be referred to as a forbidden access cell). For example, if first cell 304 does not support UE 310's requirements, UE 310 may treat first cell 304 as a forbidden access cell. While this prevents UE 310 from establishing non-emergency calls via forbidden access cells, the method described herein provides an example of UE 310 establishing emergency calls via forbidden access cells.

[0056] Figure 4 Example signaling diagram 400 is illustrated according to some implementation schemes. Signaling diagram 400 illustrates how the method described herein can be used in a UE (such as UE 310). Figure 3 )) and base stations (such as base station 302 ( Figure 3 Operations, signals, and / or elements exchanged between them.

[0057] Signaling diagram 400 may include UE 402. UE 402 may include UE 310 and / or UE 1200. Figure 12 One or more of the features of ). Signaling diagram 400 may also include base station 404. The base station may include base station 302 and / or gNB 1300 ( Figure 13 One or more of the features of ).

[0058] UE 402 can perform discovery operation 406 to search for cells that can provide services to UE 402. For example, UE 402 may be in an idle state and may initiate discovery operation 406 to search for cells with which UE 402 can establish a connection.

[0059] As part of discovery operation 406, UE 402 may send query 408 to base station 404. For example, UE 402 may be located in a cell hosted by base station 404, and may send query 408 to base station 404 based on the fact that UE 402 is located in that cell. Query 408 may request information related to that cell.

[0060] Base station 404 may send SIB1 410 to UE 402 in response to query 408. SIB1 410 may be included in a message that may include one or more other information elements, or may include only SIB1 410. SIB1 410 may include information about the cell's capabilities in relation to query 408, including one or more features described throughout the methods of this disclosure as included in SIB1. UE 402 may determine, based on the information within SIB1 410, whether the cell will be considered a prohibited access cell and / or whether an emergency call can be established with a prohibited access cell.

[0061] Although in the illustrated implementation, SIB1 410 is described as being sent from base station 404 to UE 402 as part of discovery operation 406, it should be understood that in other implementations and / or instances, base station 404 may send SIB1 410 including these features at different times.

[0062] Methods without NW signaling The first approach (which may be referred to as Approach 1) may include: “If (e)RedCap prohibits access to the cell due to lack of support for the Rx chain requirement, then allow the (e)RedCap UE to access the cell.” For example, if a RedCap UE or eRedCap UE treats a prohibited cell as prohibited because the prohibited cell does not support the Rx chain requirement of the RedCap UE or eRedCap UE, then Approach 1 may allow the RedCap UE or eRedCap UE to establish an emergency call using the prohibited cell. In some instances, the Rx chain requirement may be a 1 Rx chain requirement. The technical specifications may specify this “allow” separately for RedCap and eRedCap.

[0063] Furthermore, the first approach may include: "If (e)RedCap prohibits access to the cell due to lack of support for HD-FDD requirements, then allow (e)RedCap UE access to the cell." For example, if a RedCap UE or eRedCap UE treats a prohibited cell as prohibited because the prohibited cell does not support the HD-FDD requirements of the RedCap UE or eRedCap UE, the first approach may allow the RedCap UE or eRedCap UE to establish an emergency call using the prohibited cell. The technical specifications may specify this "allowance" separately for RedCap and eRedCap.

[0064] For the first method, the UE may receive the cell's SIB1 (such as SIB1 410) during a discovery operation. The SIB1 may include a field instructing the cell to provide emergency support for an emergency call (which may be...). ims-EmergencySupport (field).

[0065] The following paragraphs provide an example section of section 5.3.1 of the technical specification 38.304 of Method 1.

[0066] when cellBarredNTN When there is no broadcast in the community, - For NTN access, the UE should treat the cell as having a "barred access" cell status.

[0067] when cellBarredRedCap1Rx When the RedCap UE is marked as "Access Denied" in the cell and equipped with a 1Rx branch, - if ims-EmergencySupport If the cell is marked as "true", then the RedCap UE will treat the cell as having an "access denied" cell state, except for emergency calls.

[0068] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0069] when cellBarred-eRedCap1Rx When the cell is marked as "Access Denied" and the eRedCap UE is equipped with a 1Rx branch, - if ims-EmergencySupport If the cell is marked as "true", then except for emergency calls, the eRedCap UE will treat the cell as having a "barred access" cell state.

[0070] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0071] when halfDuplexRedCapAllowed When there is no broadcast in the community, - if ims-EmergencySupport If indicated as "true" in the cell, then (e)RedCap UEs that can only operate in half-duplex FDD mode, except for emergency calls, will consider the cell to have a "barred access" cell state.

[0072] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0073] The second method (which may be referred to as Method 2 and is a variant of Method 1) allows the (e)RedCap UE to access a cell "if" (e)RedCap prohibits access due to lack of support for the Rx chain requirement. For example, if a RedCap UE or eRedCap UE treats a prohibited cell as prohibited because the prohibited cell does not support its Rx chain requirement, the second method allows the RedCap UE or eRedCap UE to use the prohibited cell to establish an emergency call. The technical specification may specify that the UE may assume it complies with the Rx requirement and use it only to initiate an emergency call.

[0074] The same logic can be applied to HD-FDD. For example, the second approach could include: "If (e)RedCap prohibits access to the cell due to lack of support for HD-FDD requirements, then allow (e)RedCap UE access to the cell." For example, if a RedCap UE or eRedCap UE treats a prohibited cell as prohibited because the prohibited cell does not support its HD-FDD requirements, the second approach could allow the RedCap UE or eRedCap UE to establish an emergency call using the prohibited cell. The technical specifications can specify this "allowance" separately for RedCap and eRedCap.

[0075] For the second method, the UE may receive the cell's SIB1 (such as SIB1 410) during a discovery operation. The SIB1 may include a field instructing the cell to provide emergency support for an emergency call (which may be...). ims-EmergencySupport (field).

[0076] The following paragraphs provide an example section of section 5.3.1 of the technical specification 38.304 for method 2.

[0077] When a cell is marked as "Access Denied" or is considered to be in a "Access Denied" state, - The UE may not select or reselect the cell, even in the event of an emergency call, except in the following circumstances: - If the UE is a RedCap UE and the UE does not support... cellBarredRedCap1Rx If the request is to deem the cell a no-access zone, then only when... ims-EmergencySupport RedCap UE can only consider a cell as an acceptable cell for emergency calls only when it is indicated as "true" in that cell.

[0078] - If the UE is an eRedCap UE and the UE does not support cellBarred-eRedCap1RxIf the request is to deem the cell a no-access zone, then only when... ims-EmergencySupport eRedCapUE can only consider a cell as an acceptable cell for emergency calls only when it is indicated as "true" in the cell.

[0079] - If the UE is a (e)RedCap UE and the UE does not support hd-fdd-EmergencySupport If the request is to deem the cell a no-access zone, then only when... ims-EmergencySupport (e)RedCap UE can only consider a cell as an acceptable cell for emergency calls only when it is indicated as "true" in that cell.

[0080] - The UE will select another cell based on the following rules: - Is the cell considered to be in a "barred access" state because the MIB cannot be obtained?

[0081] Methods with NW signaling The third method (which may be referred to as Method 3 and is a variant of Method 1) may include: "If (e)RedCap blocks access to the cell due to lack of support for HD-FDD requirements, then the (e)RedCap UE is allowed to access the cell only if the NW explicitly signals such support." For example, if a RedCap UE or eRedCap UE treats a blocked cell as blocked because the blocked cell does not support its HD-FDD requirements, and the NW provides instructions regarding support for emergency calls with HD-FDD requirements from the blocked cell, then the third method may allow the RedCap UE or eRedCap UE to establish an emergency call using the blocked cell.

[0082] For the third method, the UE may receive the cell's SIB1 (such as SIB1 410) during discovery operation. SIB1 may include a field indicating whether the cell supports emergency calls utilizing HD-FDD (which may be...). hd-fdd- Emergency Support In addition, SIB1 may include fields instructing the cell to provide emergency support for emergency calls (which may be fields). ims-EmergencySupport (field).

[0083] The following paragraphs provide an example section of section 5.3.1 of the technical specification 38.304 of Method 1.

[0084] when cellBarredNTN When there is no broadcast in the community, - For NTN access, the UE should treat the cell as having a "barred access" cell status.

[0085] when cellBarredRedCap1Rx When the RedCap UE is marked as "Access Denied" in the cell and equipped with a 1Rx branch, - if ims-EmergencySupport If the cell is marked as "true", then the RedCap UE will treat the cell as having an "access denied" cell state, except for emergency calls.

[0086] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0087] when cellBarred-eRedCap1Rx When the cell is marked as "Access Denied" and the eRedCap UE is equipped with a 1Rx branch, - if ims-EmergencySupport If the cell is marked as "true", then except for emergency calls, the eRedCap UE will treat the cell as having a "barred access" cell state.

[0088] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0089] when halfDuplexRedCapAllowed When there is no broadcast in the community, - if ims-EmergencySupport In that cell, it is indicated as "true", and if hd-fdd- Emergency Support If indicated as "true", then (e)RedCap UEs that can only operate in half-duplex FDD mode, except for emergency calls, will treat the cell as having a "barred access" cell state.

[0090] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0091] The fourth method (which may be referred to as Method 4 and is a variant of Method 2) may include: "if (e)RedCap allows the (e)RedCap UE to access the cell only if the NW explicitly signals such support for HD-FDD. For example, if the RedCap UE or eRedCap UE treats the forbidden cell as forbidden access because the forbidden cell does not support the HD-FDD requirement of the RedCap UE or eRedCap UE, and the NW explicitly signals support for HD-FDD, then the fourth method may allow the RedCap UE or eRedCap UE to establish an emergency call using the forbidden cell."

[0092] For the fourth method, the UE may receive the cell's SIB1 (such as SIB1 410) during discovery operations. SIB1 may include a field indicating that the cell supports emergency calls utilizing HD-FDD (which may be...). hd-fdd- Emergency Support In addition, SIB1 may include fields instructing the cell to provide emergency support for emergency calls (which may be fields). ims-EmergencySupport (field).

[0093] The following paragraphs provide an example section of section 5.3.1 of technical specification 38.304 according to method 4.

[0094] When a cell is marked as "Access Denied" or is considered to be in a "Access Denied" state, - The UE may not select or reselect the cell, even in the event of an emergency call, except in the following circumstances: - If the UE is a RedCap UE and the UE does not support... cellBarredRedCap1Rx If the request is to deem the cell a no-access zone, then only when... ims-EmergencySupport RedCap UE can only consider a cell as an acceptable cell for emergency calls only when it is indicated as "true" in that cell.

[0095] - If the UE is an eRedCap UE and the UE does not support cellBarred-eRedCap1Rx If the request is to deem the cell a no-access zone, then only when... ims-EmergencySupport eRedCapUE can only consider a cell as an acceptable cell for emergency calls only when it is indicated as "true" in the cell.

[0096] - If the UE is an (e)RedCap UE, and the UE does not support hd-fdd-EmergencySupport If the request is to deem the cell a no-access zone, then only when... ims-EmergencySupport and hd-fdd-EmergencySupport (e)RedCap UE can only consider a cell as an acceptable cell for emergency calls only when it is indicated as "true" in that cell.

[0097] - The UE will select another cell based on the following rules: - Is it because it cannot be obtained? MIB The community is considered to be in a "no access" state.

[0098] The fifth method (which may be referred to as Method 5) may include allowing the NW to have complete control over the entire EM call permission process using the indications in SIB1. The NW may signal a new field that allows the (e)RedCap UE to consider initiating an EM call on a prohibited access cell. This new field may be applied to "all" restrictions, including Rx requirements and HD-FDD requirements. In some implementations, the NW may signal two separate fields, one for allowing RedCap UEs and another for allowing eRedCap UEs.

[0099] The following paragraphs provide an example section of section 5.3.1 of the technical specification 38.304 for method 5.

[0100] when cellBarredNTN When there is no broadcast in the community, - For NTN access, the UE should treat the cell as having a "barred access" cell status.

[0101] when cellBarredRedCap1Rx When the RedCap UE is marked as "Access Denied" in the cell and equipped with a 1Rx branch, - In this community, if ims-EmergencySupport Indicated as "true" and emergencySupportRedCap If indicated as "true", the RedCap UE will treat the cell as having an "access denied" cell status, except for emergency calls.

[0102] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0103] when cellBarred-eRedCap1Rx When the cell is marked as "Access Denied" and the eRedCap UE is equipped with a 1Rx branch, - In this community, if ims-EmergencySupport Indicated as "true" and emergencySupportRedCap If indicated as "true", the eRedCap UE will treat the cell as having an "access denied" cell state, except for emergency calls.

[0104] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0105] when halfDuplexRedCapAllowed When there is no broadcast in the community, - if ims-EmergencySupport In this community, it was indicated as "true" and emergencySupportRedCap If indicated as "true" in the cell, then (e)RedCap UEs that can only operate in half-duplex FDD mode, except for emergency calls, will consider the cell to have a "barred access" cell state.

[0106] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0107] Figure 5 Example SIB1 information element 500 related to method 5 according to some implementation schemes is illustrated. SIB1 information element 500 may be included from a base station (such as base station 404). Figure 4 )) To UE 402 ( Figure 4 SIB1 (such as SIB1 410) sent Figure 4 In this context, SIB1 may include information about the cell.

[0108] SIB1 information element 500 may include a first field 502. The first field 502 may indicate whether the cell provides emergency support for emergency calls from RedCap UEs. In some implementations, the first field 502 may be... emergencySupportRedCap-r18 Field. The first field 502 may have a "true" value to indicate that the cell provides emergency support for emergency calls from RedCap UEs, or it may have a "false" value to indicate that the cell does not provide emergency support for emergency calls from RedCap UEs.

[0109] SIB1 information element 500 may include a second field 504. The second field 504 may indicate whether the cell provides emergency support for emergency calls to the eRedCapUE. In some implementations, the second field 504 may be... emergencySupport- eRedCap-r18 Field. The second field 504 may have a "true" value to indicate that the cell provides emergency support for emergency calls from the eRedCap UE, or it may have a "false" value to indicate that the cell does not provide emergency support for emergency calls from the eRedCap UE.

[0110] The UE can use the value of either the first field 502 or the second field 504 to determine whether a cell provides emergency support for the UE's emergency call. For example, if the UE is a RedCap UE, if the first field 502 has a "true" value, the UE can determine that the cell supports the UE's emergency call; and if the first field 502 has a "false" value, the UE can determine that the cell does not support the UE's emergency call. If the UE is an eRedCap UE, if the second field 504 has a "true" value, the UE can determine that the cell supports the UE's emergency call; and if the second field 504 has a "false" value, the UE can determine that the cell does not support the UE's emergency call. In some implementations, the SIB1 information element 500 may include only one of the first field 502 and the second field 504, instead of including both fields.

[0111] A sixth method (which may be referred to as method 6 and is a variation of method 5) may include allowing the NW to have complete control over the entire EM call permission process using the indications in SIB1. The NW may signal a new field that allows the (e)RedCap UE to consider initiating an EM call on a prohibited access cell. The NW may include separate indications for Rx and HD-FDD requirements. In some implementations, the NW may signal two separate fields, one for allowing a RedCap UE and another for allowing an eRedCap UE.

[0112] The following paragraphs provide an example section of section 5.3.1 of technical specification 38.304 according to method 6.

[0113] when cellBarredNTN When there is no broadcast in the community, - For NTN access, the UE should treat the cell as having a "barred access" cell status.

[0114] when cellBarredRedCap1Rx When the RedCap UE is marked as "Access Denied" in the cell and equipped with a 1Rx branch, - In this community, if ims-EmergencySupport Indicated as "true" and emergencySupportRedCap If indicated as "true", the RedCap UE will treat the cell as having an "access denied" cell status, except for emergency calls.

[0115] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0116] when cellBarred-eRedCap1Rx When the cell is marked as "Access Denied" and the eRedCap UE is equipped with a 1Rx branch, - In this community, if ims-EmergencySupport Indicated as "true" and emergencySupportRedCap If indicated as "true", the eRedCap UE will treat the cell as having an "access denied" cell state, except for emergency calls.

[0117] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0118] when halfDuplexRedCapAllowed When there is no broadcast in the community, - if ims-EmergencySupport In this community, it was indicated as "true" and emergencySupport- Hd-FDD-RedCapIf indicated as "true" in the cell, then (e)RedCap UEs that can only operate in half-duplex FDD mode, except for emergency calls, will consider the cell to have a "barred access" cell state.

[0119] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0120] Figure 6 An example SIB1 information element 600 related to method 6 according to some implementation schemes is illustrated. The SIB1 information element 600 may be included from a base station (such as base station 404). Figure 4 )) To UE 402 ( Figure 4 SIB1 (such as SIB1 410) sent Figure 4 In this context, SIB1 may include information about the cell.

[0121] SIB1 information element 600 may include a first field 602. The first field 602 may indicate whether the cell provides emergency support for emergency calls from RedCap UEs with a 1 Rx chain. In some implementations, the first field 602 may be... emergencySupport-1Rx-RedCap-r18 Field. The first field 602 may have a "true" value to indicate that the cell provides emergency support for emergency calls from RedCap UEs with a 1Rx chain, or it may have a "false" value to indicate that the cell does not provide emergency support for emergency calls from RedCap UEs with a 1Rx chain.

[0122] SIB1 information element 600 may include a second field 604. The second field 604 may indicate whether the cell provides emergency support for emergency calls from eRedCap UEs with a 1 Rx chain. In some implementations, the second field 604 may be... emergencySupport-1Rx-eRedCap-r18 Field. The second field 604 may have a "true" value to indicate that the cell provides emergency support for emergency calls from the eRedCap UE, or it may have a "false" value to indicate that the cell does not provide emergency support for emergency calls from the eRedCap UE.

[0123] SIB1 information element 600 may include a third field 606. The third field 606 may indicate whether the cell provides emergency support for emergency calls from UEs with HD-FDD. In some implementations, the third field 606 may be... emergencySupport-Hd-FDD-RedCap-r18The third field 606 may have a "true" value to indicate that the cell provides emergency support for emergency calls from UEs with HD-FDD, or it may have a "false" value to indicate that the cell does not provide emergency support for emergency calls from UEs with HD-FDD. In some implementations, the SIB1 information element 600 may include one or more of the first field 602, the second field 604, or the third field 606, instead of including all three fields.

[0124] The UE can use the values ​​of the first field 602, the second field 604, and / or the third field 606 to determine whether a cell provides emergency support for the UE's emergency call. For example, if the UE is a RedCap UE with 1 Rx chain, if the first field 602 has a "true" value, the UE can determine that the cell supports the UE's emergency call; and if the first field 602 has a "false" value, the UE can determine that the cell does not support the UE's emergency call. If the UE is an eRedCap UE with 1 Rx chain, if the second field 604 has a "true" value, the UE can determine that the cell supports the UE's emergency call; and if the second field 604 has a "false" value, the UE can determine that the cell does not support the UE's emergency call. If the UE uses HD-FDD, if the third field 606 has a "true" value, the UE can determine that the cell supports the UE's emergency call; and if the third field 606 has a "false" value, the UE can determine that the cell does not support the UE's emergency call. In some implementations, the UE may use more than one field to determine whether the cell supports the UE's emergency call. For example, if the UE is a RedCap UE with 1 Rx chain and uses HD-FDD, the UE may determine whether the cell supports the UE's emergency call based on the values ​​of the first field 602 and the third field 606.

[0125] Method with NW signaling - Further restricted access The seventh method (which may be referred to as Method 7) differs in that the NW only allows EM call access "if" the NW knows that no other cell in that frequency supports (e)RedCap UEs with the same 1Rx requirement (and HD-FDD requirement). For example, if there are no other cells in the frequency range accessible to RedCap UEs and / or eRedCap UEs that support 1Rx and / or HD-FDD requirements, the NW may allow emergency call access to RedCap UEs and / or eRedCap UEs with 1Rx and / or HD-FDD requirements via cells operating in that frequency range. Since the NW knows there are no other cells in that frequency, the NW allows this access. In other words, if other cells exist in the same frequency, the NW will directly suggest that the UE search for other cells in the same frequency to find a suitable cell. It can be viewed as two separate fields: one field for allowing RedCap UE (intraFreqReselectionRedCap-r17), and another field for allowing eRedCap UE (intraFreqReselection-eRedCapr18).

[0126] The following paragraphs provide an example section of section 5.3.1 of technical specification 38.304 according to method 7.

[0127] When cellBarredNTN is not broadcast in the cell - For NTN access, the UE should treat the cell as having a "barred access" cell status.

[0128] when cellBarredRedCap1Rx When the RedCap UE is marked as "Access Denied" in the cell and equipped with a 1Rx branch, - In this community, if ims-EmergencySupport Indicated as "true" and intraFreqReselectionRedCap If indicated as "not allowed," the RedCap UE will treat the cell as having a "barred access" cell state, except for emergency calls.

[0129] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0130] when cellBarred-eRedCap1Rx When the cell is marked as "Access Denied" and the eRedCap UE is equipped with a 1Rx branch, - In this community, if ims-EmergencySupport Indicated as "true" and intraFreqReselectioneRedCapIf indicated as "not allowed," the eRedCap UE will treat the cell as having a "barred access" cell state, except for emergency calls.

[0131] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0132] when halfDuplexRedCapAllowed When there is no broadcast in the community, - if ims-EmergencySupport In this community, it was indicated as "true" and intraFreqReselectionRedCap If a cell is marked as "not allowed", then a RedCap UE that can only operate in half-duplex FDD mode, except for emergency calls, will consider the cell to have a "barred access" cell state.

[0133] - if ims-EmergencySupport In this community, it was indicated as "true" and intraFreqReselection-eRedCap If the cell is marked as "not allowed", then the eRedCap UE, which can only operate in half-duplex FDD mode except for emergency calls, will treat the cell as having a "barred access" cell state.

[0134] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0135] Figure 7 Example SIB1 information element 700 related to method 7 according to some implementation schemes is illustrated. SIB1 information element 700 may be included from a base station (such as base station 404) Figure 4 )) To UE 402 ( Figure 4 SIB1 (such as SIB1 410) sent Figure 4 In this context, SIB1 may include information about the cell.

[0136] SIB1 information element 700 may include a first field 702. The first field 702 may indicate whether the RedCap UE should search for other cells within the same frequency range that supports the UE's requirements. In some implementations, the first field 702 may be... intraFreqReselectionRedCap-r17 Field. The first field 702 may have an “Allow” value to indicate that the RedCap UE should search for other cells in the same frequency range, and may have an “Disallow” value to indicate that the RedCap UE does not need to search for other cells (this may indicate that the RedCap UE can use the cell for an emergency call).

[0137] SIB1 information element 700 may include a second field 704. The second field 704 may indicate whether the eRedCap UE should search for other cells supporting the UE's requirements within the same frequency range. In some implementations, the second field 704 may be...intraFreqReselection-eRedCap-r18 The second field 704 may have an "Allow" value to indicate that the eRedCap UE should search for other cells within the same frequency range, and may have an "Disallow" value to indicate that the eRedCap UE does not need to search for other cells (this may indicate that the eRedCap UE can use the cell for an emergency call). In some implementations, the SIB1 information element 700 may include either the first field 702 or the second field 704, instead of including both fields.

[0138] The UE can use the value of either the first field 702 or the second field 704 to determine whether a cell provides emergency support for the UE's emergency call, or whether the UE should search for other cells in the same frequency range. For example, if the UE is a RedCap UE, if the first field 702 has a "disallowed" value, the UE can determine that the cell supports the UE's emergency call; and if the first field 702 has a "allowed" value, the UE can determine that the UE should search for other cells in the same frequency range. If the UE is an eRedCap UE, if the second field 704 has a "disallowed" value, the UE can determine that the cell supports the UE's emergency call; and if the second field 702 has a "allowed" value, the UE can determine that the UE should search for other cells in the same frequency range. In some implementations, the first field 702 and the second field 704 can be combined into a single field, which can be used for both RedCap and eRedCap UEs.

[0139] The eighth method (which may be referred to as Method 8) can be an extension of Method 7 (allowing EM access if no other cell in the same frequency can support the UE). NW can also utilize a new flag indicating whether an EM call can be initiated to implement control. This flag can be a single new field. emergencySupport-r18 This applies to both RedCap and eRedCap. In other implementations, this flag can be considered as two separate fields: one for enabling RedCap UE (…). intraFreqReselectionRedCap-r17 )of emergencySupportRedCap-r18 and for allowing eRedCap UE ( intraFreqReselection-eRedCap-r18 )of emergencySupport-eRedCap-r18 This method can also distinguish between Rx and HD-FDD requirements.

[0140] The following paragraphs provide an example section of section 5.3.1 of technical specification 38.304 according to method 8.

[0141] when cellBarredNTN When there is no broadcast in the community, - For NTN access, the UE should treat the cell as having a "barred access" cell status.

[0142] whencellBarredRedCap1Rx When the RedCap UE is marked as "Access Denied" in the cell and equipped with a 1Rx branch, - In this community, if ims-EmergencySupport Indicated as "true" and emergencySupportRedCap It was indicated as "true", and intraFreqReselectionRedCap If indicated as "not allowed", the RedCap UE will treat the cell as having a "barred access" cell status, except for emergency calls.

[0143] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0144] when cellBarred-eRedCap1Rx When the cell is marked as "Access Denied" and the eRedCap UE is equipped with a 1Rx branch, - In this community, if ims-EmergencySupport Indicated as "true" and emergencySupportRedCap It was indicated as "true", and intraFreqReselection-eRedCap If indicated as "not allowed", the eRedCap UE will treat the cell as having a "barred access" cell state, except for emergency calls.

[0145] Otherwise, the UE will treat the cell as having a "barred access" cell status.

[0146] when halfDuplexRedCapAllowed When there is no broadcast in the community, - if ims-EmergencySupport In this community, it was indicated as "true" and emergencySupport- Hd-FDD-RedCap In this community, it was indicated as "true", and intraFreqReselectionRedCap In this cell, the RedCap UE, which is only allowed to operate in half-duplex FDD mode except for emergency calls, is designated as having a "barred access" cell state.

[0147] - if ims-EmergencySupport In this community, it was indicated as "true" and emergencySupport- Hd-FDD-RedCap If the eRedCap setting is "True" in the cell and `intraFreqReselectioneRedCap` is "Disallowed" in the cell, the UE can only operate in half-duplex FDD mode, except for emergency calls. Otherwise, the UE will treat the cell as having a "Disallowed" cell state.

[0148] Figure 8Example SIB1 information element 800 related to method 8 according to some implementation schemes is illustrated. SIB1 information element 800 may be included from a base station (such as base station 404) Figure 4 )) To UE 402 ( Figure 4 SIB1 (such as SIB1 410) sent Figure 4 In this context, SIB1 may include information about the cell.

[0149] SIB1 information element 800 may include a first field 802. The first field 802 may indicate whether the RedCap UE should search for other cells within the same frequency range that supports the UE's requirements. In some implementations, the first field 802 may be... intraFreqReselectionRedCap-r17 Field. The first field 802 may have an “Allow” value to indicate that the RedCap UE should search for other cells in the same frequency range, and may have an “Disallow” value to indicate that the RedCap UE does not need to search for other cells (this may indicate that the RedCap UE can use the cell for an emergency call).

[0150] SIB1 information element 800 may include a second field 804. The second field 804 may indicate whether the eRedCap UE should search for other cells supporting the UE's requirements within the same frequency range. In some implementations, the second field 804 may be... intraFreqReselection-eRedCap-r18 The second field 804 may have an "Allow" value to indicate that the eRedCap UE should search for other cells within the same frequency range, and may have an "Disallow" value to indicate that the eRedCap UE does not need to search for other cells (this indicates that the eRedCap UE can utilize the cell for an emergency call). In some implementations, the first field 802 and the second field 804 may be combined into a single field that can be used by both the RedCap UE and the eRedCap UE.

[0151] SIB1 information element 800 may include a third field 806. The third field 806 may indicate whether the cell provides emergency support for emergency calls from RedCap UEs with a 1 Rx chain. In some implementations, the third field 806 may be... emergencySupport-1Rx-RedCap-r18 Field. The third field 806 may have a "true" value to indicate that the cell provides emergency support for emergency calls from RedCap UEs with a 1Rx chain, or it may have a "false" value to indicate that the cell does not provide emergency support for emergency calls from RedCap UEs with a 1Rx chain.

[0152] SIB1 information element 800 may include a fourth field 808. The fourth field 808 may indicate whether the cell provides emergency support for emergency calls to an eRedCap UE with a 1 Rx chain. In some implementations, the fourth field 808 may be... emergencySupport-1Rx-eRedCap-r18 Field 808. The fourth field may have a "true" value to indicate that the cell provides emergency support for emergency calls from the eRedCap UE, or it may have a "false" value to indicate that the cell does not provide emergency support for emergency calls from the eRedCap UE.

[0153] SIB1 information element 800 may include a fifth field 810. The fifth field 810 may indicate whether the cell provides emergency support for emergency calls from UEs with HD-FDD. In some implementations, the fifth field 810 may be... emergencySupport-Hd-FDD-RedCap-r18 Field 810. The fifth field may have a "true" value to indicate that the cell provides emergency support for emergency calls from UEs with HD-FDD, or it may have a "false" value to indicate that the cell does not provide emergency support for emergency calls from UEs with HD-FDD.

[0154] In some implementations, the third field 806 and the fourth field 808 may be combined into a single field that can be used for both RedCap UE and eRedCap UE with a 1 Rx chain. In some implementations, the third field 806, the fourth field 808, and the fifth field 810 may be combined into a single field that can be used for both RedCap UE and eRedCap UE, as well as for both 1 Rx chain and HD-FDD. In some implementations, the SIB1 information element 800 may include one or more of the first field 802, the second field 804, the third field 806, the fourth field 808, and / or the fifth field 810, rather than including all five fields.

[0155] The UE can use the values ​​of the first field 802, the second field 804, the third field 806, the fourth field 808, and / or the fifth field 810 to determine whether a cell provides emergency support for the UE's emergency call, or whether the UE should search for other cells in the same frequency range. For example, the UE can use the values ​​of the first field 802 and the second field 804 to determine whether the UE should search for other cells in the same frequency range. If the UE is a RedCap UE, if the first field 802 has a "disallowed" value, the UE can determine that the UE does not need to search for other cells, and if the first field 802 has a "allowed" value, the UE can determine that the UE should search for other cells in the same frequency range. If the UE is an eRedCap UE, if the second field 804 has a "disallowed" value, the UE can determine that the UE does not need to search for other cells, and if the second field 802 has a "allowed" value, the UE can determine that the UE should search for other cells in the same frequency range.

[0156] The UE can use the values ​​of the third field 806, the fourth field 808, and / or the fifth field 810 to determine whether a cell provides emergency support for the UE's emergency call. For example, if the UE is a RedCap UE with 1 Rx chain, if the third field 806 has a "true" value, the UE can determine that the cell supports the UE's emergency call, and if the third field 806 has a "false" value, the UE can determine that the cell does not support the UE's emergency call. If the UE is an eRedCap UE with 1 Rx chain, if the fourth field 808 has a "true" value, the UE can determine that the cell supports the UE's emergency call, and if the fourth field 808 has a "false" value, the UE can determine that the cell does not support the UE's emergency call. If the UE uses HD-FDD, if the fifth field 810 has a "true" value, the UE can determine that the cell supports the UE's emergency call, and if the fifth field 808 has a "false" value, the UE can determine that the cell does not support the UE's emergency call. In some implementations, the UE may use more than one field to determine whether the cell supports the UE's emergency call. For example, if the UE is a RedCap UE with 1 Rx chain and uses HD-FDD, the UE may determine whether the cell supports the UE's emergency call based on the values ​​of the third field 806 and the fifth field 810.

[0157] For example, if the UE is a RedCap UE, if the first field 702 has a "disallowed" value, the UE can determine that the cell supports the UE's emergency call, and if the first field 702 has a "allowed" value, the UE can determine that the UE should search for other cells in the same frequency range. If the UE is an eRedCap UE, if the second field 704 has a "disallowed" value, the UE can determine that the cell supports the UE's emergency call, and if the second field 702 has a "allowed" value, the UE can determine that the UE should search for other cells in the same frequency range. In some implementations, the first field 702 and the second field 704 can be combined into a single field, which can be used for both RedCap and eRedCap UEs.

[0158] Figure 9 An example process 900 according to some implementation schemes is illustrated. Process 900 may be provided by a UE (such as UE 310). Figure 3 ), UE 402 ( Figure 4 ) and / or UE 1200 ( Figure 12 )) Execution. The UE can have the capability to reduce, and can be a RedCap UE or an eRedCap UE.

[0159] Process 900 may include identifying a request for an emergency call in 902. For example, the UE may identify a request for an emergency call, wherein the request for an emergency call may be based on input from the UE's user.

[0160] Process 900 may include establishing a connection to a prohibited cell of the network in 904. For example, the UE may establish a connection to a prohibited cell of the network based at least in part on the identification of a request for an emergency call.

[0161] In some implementations, process 900 may include: identifying an indication for a prohibited access cell, which instructs the prohibited access cell to provide emergency support to a UE with reduced capabilities. The UE may establish a connection based at least in part on the identification of this indication.

[0162] In some implementations, process 900 may include identifying an indication of a prohibited cell, which indicates that intra-frequency reselection is not allowed. The UE may establish a connection based at least in part on the identification of this indication.

[0163] In some embodiments, process 900 may include determining the reason why the UE considers the forbidden access cell to be forbidden access. Process 900 may include identifying an indication for the forbidden access cell that instructs the forbidden access cell to provide emergency support to the UE that considers the forbidden access cell to be forbidden access due to the reason in these embodiments. The UE may establish a connection based at least in part on the identification of this indication. In some embodiments of these embodiments, the reason may include that the UE is only able to operate in HD-FDD mode. Furthermore, the indication may instruct the forbidden access cell to provide emergency support to the UE that considers the forbidden access cell to be forbidden access because the UE is only able to operate in HD-FDD mode.

[0164] In some implementations, the UE may treat a forbidden cell as forbidden access at least in part based on the fact that the forbidden cell does not support the UE's receive chain requirements. The UE may establish a connection at least in part based on the fact that the forbidden cell does not support the UE's receive chain requirements.

[0165] In some implementations, the UE may treat a forbidden cell as forbidden access at least in part based on the fact that the forbidden cell does not support the UE's HD-FDD requirements. The UE may establish a connection at least in part based on the fact that the forbidden cell does not support the UE's HD-FDD requirements.

[0166] In some implementations, a UE may treat a prohibited cell as a prohibition on access for non-emergency calls. Conversely, a UE may treat a prohibited cell as acceptable for emergency calls.

[0167] In some implementations, the UE may be a RedCap UE. Process 900 may include: identifying an indication regarding the prohibition of access to the cell for providing emergency support to the RedCap UE. The UE may establish an emergency call based at least in part on the identification of this indication.

[0168] In some implementations, the UE may be an eRedCap UE. Process 900 may include: identifying an indication regarding the prohibition of access to the cell to provide emergency support to the eRedCap UE. The UE may establish an emergency call based at least in part on the identification of this indication.

[0169] Procedure 900 may include establishing an emergency call via a prohibited cell in 906. For example, the UE may establish an emergency call via a prohibited cell.

[0170] Although Figure 9The order of processes 900 is implied in the argument, but it should be understood that in other embodiments, one or more of these operations may be performed in a different order and / or one or more of these operations may be performed simultaneously. Furthermore, it should be understood that in other embodiments, one or more of these operations may be omitted, and / or one or more additional operations may be added to process 900.

[0171] Figure 10 Example process 1000 according to some implementation schemes is illustrated. Process 1000 may be provided by a UE (such as UE 310). Figure 3 ), UE 402 ( Figure 4 ) and / or UE 1200 ( Figure 12 )) Execution. The UE can have the capability to reduce, and can be a RedCap UE or an eRedCap UE.

[0172] Procedure 1000 may include receiving the SIB1 of the prohibited access cell in 1002. For example, the UE may receive the SIB1 of the prohibited access cell from the base station.

[0173] Process 1000 may include identifying a request for an emergency call in 1004. For example, the UE may identify a request for an emergency call, wherein the request for an emergency call may be based on input from the UE's user.

[0174] Process 1000 may include determining in 1006 whether the prohibited access cell provides emergency support to the UE. For example, the UE may determine whether the prohibited access cell provides emergency support to the UE based at least in part on SIB1.

[0175] In some implementations, determining whether a prohibited access cell provides emergency support to the UE may include: determining that a field in SIB1 indicates that the prohibited access cell provides emergency support for the UE's emergency call. Furthermore, determining whether a prohibited access cell provides emergency support to the UE may include: determining that the prohibited access cell provides emergency support to the UE based at least in part on a field in SIB1 indicating that the prohibited access cell provides emergency support for the UE's emergency call.

[0176] In some implementations, determining whether a prohibited access cell provides emergency support to the UE may include: determining that a field in SIB1 indicates that the prohibited access cell provides emergency support for the UE's emergency call. Furthermore, determining whether a prohibited access cell provides emergency support to the UE may include: considering the prohibited access cell as acceptable for emergency calls, at least in part, based on the indication from the SIB1 field that the prohibited access cell provides emergency support for the UE's emergency call.

[0177] In some implementations, the UE may consider a forbidden access cell as forbidden access based at least in part on the fact that the forbidden access cell does not support HD-FDD. Determining whether a forbidden access cell provides emergency support may include: determining that a field in SIB1 indicates that the forbidden access cell provides emergency support for HD-FDD. Furthermore, determining whether a forbidden access cell provides emergency support may include: determining that the forbidden access cell provides emergency support for the UE based at least in part on a field in SIB1 indicating that the forbidden access cell provides emergency support for HD-FDD.

[0178] In some implementations, the UE may consider a forbidden access cell as forbidden access at least in part based on the fact that the forbidden access cell does not support HD-FDD. Determining whether a forbidden access cell provides emergency support to the UE may include: determining that a field in SIB1 indicates that the forbidden access cell provides emergency support for HD-FDD. Furthermore, determining whether a forbidden access cell provides emergency support to the UE may include: considering the forbidden access cell acceptable for emergency calls based at least in part on a field in SIB1 indicating that the forbidden access cell provides emergency support for HD-FDD.

[0179] In some implementations, the UE may be a RedCap UE. Determining whether a prohibited access cell provides emergency support to the UE may include: determining that a field in SIB1 indicates that a prohibited access cell provides emergency support to a RedCap UE. Determining whether a prohibited access cell provides emergency support to the UE may include: determining that the prohibited access cell provides emergency support to the UE based at least in part on a field in SIB1 indicating that a prohibited access cell provides emergency support for an emergency call of a RedCap UE.

[0180] In some implementations, the UE may be an eRedCap UE. Determining whether a prohibited access cell provides emergency support to the UE may include: determining that a field in SIB1 indicates that a prohibited access cell provides emergency support to the eRedCap UE. Furthermore, determining whether a prohibited access cell provides emergency support to the UE may include: determining that the prohibited access cell provides emergency support to the UE based at least in part on a field in SIB1 indicating that a prohibited access cell provides emergency support for an emergency call from the eRedCap UE.

[0181] In some implementations, determining whether a prohibited access cell provides emergency support to the UE may include: determining that the SIB1 field indicates that intra-frequency reselection is not allowed. Furthermore, determining whether a prohibited access cell provides emergency support may include: determining that the prohibited access cell provides emergency support to the UE based at least in part on the SIB1 field indicating that intra-frequency reselection is not allowed.

[0182] In some implementations, determining whether a prohibited access cell provides emergency support to the UE may include: determining that a field in SIB1 indicates that intra-frequency reselection is not allowed. Furthermore, determining whether a prohibited access cell provides emergency support to the UE may include: determining that the prohibited access cell provides emergency support to the UE based at least in part on a field in SIB1 indicating that intra-frequency reselection is allowed.

[0183] Process 1000 may include continuing to establish an emergency call in 1008. For example, the UE may continue to establish an emergency call based on whether the determined restricted access cell provides emergency support for an emergency call of a UE with reduced capabilities.

[0184] In some implementations, continuing to establish an emergency call may include: establishing an emergency call with the prohibited access cell based at least in part on the determination of the prohibited access cell to provide emergency support to the UE.

[0185] In some implementations, continuing to establish an emergency call includes: establishing an emergency call with the prohibited cell based at least in part on the premise that the prohibited cell is acceptable for an emergency call.

[0186] In some implementations, continuing to establish an emergency call may include: identifying a second cell that provides emergency support to the UE, based at least in part on a field indication in SIB1 that allows intra-frequency reselection. The second cell may operate within the same frequency range as the prohibited cell. Furthermore, continuing to establish an emergency call may include establishing an emergency call with the second cell.

[0187] Although Figure 10 The order of processes 1000 is implied in the argument, but it should be understood that in other embodiments, one or more of these operations may be performed in a different order and / or one or more of these operations may be performed simultaneously. Furthermore, it should be understood that in other embodiments, one or more of these operations may be omitted, and / or one or more additional operations may be added to process 1000.

[0188] Figure 11 Example process 1100 according to some implementation schemes is illustrated. Process 1100 may be provided by a base station (such as base station 302). Figure 3 ), Base Station 404 ( Figure 4 ) and / or gNB 1300 ( Figure 13 ))implement.

[0189] Process 1100 may include generating the SIB1 of the network's cells in 1102. For example, a base station may generate the SIB1 of the network's cells. The SIB1 may include at least one field related to an emergency call from a UE with reduced capabilities.

[0190] In some implementations, SIB1 may include a field indicating whether the cell provides emergency support for HD-FDD. Additionally, in some implementations, SIB1 may include a field indicating whether the cell provides emergency support for RedCap UEs. In some implementations, SIB1 may include a field indicating whether the cell provides emergency support for eRedCap UEs.

[0191] In some implementations, the cell may be a first cell. SIB1 may include a field indicating whether the UE wants to search for a second cell operating in the same frequency range as the first cell to provide emergency support for the UE's emergency calls.

[0192] In some implementations, the cell may be a first cell. SIB1 may include a first field indicating whether the RedCap UE wants to search for another cell operating in the same frequency range as the first cell to provide emergency support for the RedCap UE's emergency calls. In some of these implementations, SIB1 may include a second field indicating whether the eRedCap UE wants to search for another cell operating in the same frequency range as the first cell to provide emergency support for the eRedCap UE's emergency calls.

[0193] Process 1100 may include receiving a query for cell-related information in 1104. For example, the base station may receive a query for cell-related information from the UE.

[0194] Process 1100 may include sending SIB1 in 1106. For example, the base station may send SIB1 to the UE based at least in part on the query.

[0195] Although Figure 11 The order of processes 1100 is implied in the argument, but it should be understood that in other embodiments, one or more of these operations may be performed in a different order and / or one or more of these operations may be performed simultaneously. Furthermore, it should be understood that in other embodiments, one or more of these operations may be omitted, and / or one or more additional operations may be added to process 1100.

[0196] Figure 12Example UE 1200 is illustrated according to some implementations. UE 1200 can be any mobile or non-mobile computing device, such as, for example, a mobile phone, computer, tablet, industrial wireless sensors (e.g., microphones, carbon dioxide sensors, pressure sensors, humidity sensors, thermometers, motion sensors, accelerometers, laser scanners, fluid level sensors, inventory sensors, voltmeters / ammeters, actuators, etc.), video surveillance / monitoring devices (e.g., cameras, camcorders, etc.), wearable devices (e.g., smartwatches), and loosely coupled IoT devices. In some implementations, UE 1200 can be a RedCap UE or an NR-Light UE.

[0197] UE 1200 may include a processor 1204, RF interface circuitry 1208, memory / storage device 1212, user interface 1216, sensor 1220, drive circuitry 1222, power management integrated circuit (PMIC) 1224, antenna structure 1226, and battery 1228. The components of UE 1200 may be implemented as integrated circuits (ICs), portions of such integrated circuits, discrete electronic devices or other modules, logic components, hardware, software, firmware, or combinations thereof. Figure 12 The block diagram is intended to show a high-level view of some of the components of the UE 1200. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other specific implementations.

[0198] The components of UE 1200 can be coupled to various other components via one or more interconnects 1232, which can represent any type of interface, input / output, bus (local, system, or extension), transmit line, trace, optical connection, etc., allowing various circuit components (on common or different chips or chipsets) to interact with each other.

[0199] Processor 1204 may include processor circuitry, such as, for example, baseband processor circuitry (BB) 1204A, central processing unit circuitry (CPU) 1204B, and graphics processing unit circuitry (GPU) 1204C. Processor 1204 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions (such as program code, software modules, or functional procedures from memory / storage device 1212) to cause UE 1200 to perform the operations described herein.

[0200] In some implementations, the baseband processor circuit 1204A can access the communication protocol stack 1236 in the memory / storage device 1212 to communicate over a 3GPP-compliant network. Generally, the baseband processor circuit 1204A can access the communication protocol stack to perform user plane functions at the PHY, MAC, RLC, PDCP, SDAP, and PDU layers; and control plane functions at the PHY, MAC, RLC, PDCP, RRC, and non-access layer layers. In some implementations, PHY layer operations may additionally / optionally be performed by components of the RF interface circuit 1208.

[0201] The baseband processor circuit 1204A can generate or process baseband signals or waveforms carrying information in a 3GPP-compliant network. In some implementations, the waveforms used for NR can be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and Discrete Fourier Transform Extended OFDM (DFT-S-OFDM) in the uplink.

[0202] The memory / storage device 1212 may include one or more non-transitory computer-readable media, including instructions (e.g., a communication protocol stack 1236) that can be executed by one or more processors in processor 1204 to cause UE 1200 to perform the various operations described herein. The memory / storage device 1212 includes any type of volatile or non-volatile memory that can be distributed throughout UE 1200. In some embodiments, some of the memory / storage devices 1212 may be located on processor 1204 itself (e.g., L1 cache and L2 cache), while other memory / storage devices 1212 are external to processor 1204 but accessible via a memory interface. The memory / storage device 1212 may include any suitable volatile or non-volatile memory, such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, or any other type of memory device technology.

[0203] The RF interface circuit 1208 may include transceiver circuitry and a radio frequency front-end module (RFEM) that allows the UE 1200 to communicate with other devices via a radio access network. The RF interface circuit 1208 may include various components arranged in the transmit or receive path. These components may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

[0204] In the receiving path, the RFEM can receive the radiated signal from the air interface via antenna structure 1226, and continue to filter and amplify the signal (using a low-noise amplifier). This signal can be provided to the receiver of the transceiver, which downconverts the RF signal into a baseband signal that is provided to the baseband processor of processor 1204.

[0205] In the transmission path, the transceiver's transmitter up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM can amplify the RF signal using a power amplifier before it is radiated across the air interface via antenna structure 1226.

[0206] In various implementations, the RF interface circuit 1208 can be configured to transmit / receive signals in a manner compatible with NR access technology.

[0207] Antenna structure 1226 may include antenna elements for converting electrical signals into radio waves to travel through the air and for converting received radio waves back into electrical signals. These antenna elements may be arranged in one or more antenna panels. Antenna structure 1226 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple-input multiple-output (MIMO) communication. Antenna structure 1226 may include microstrip antennas, patch antennas, phased array antennas, printed antennas fabricated on the surface of one or more printed circuit boards, etc. Antenna structure 1226 may have one or more panels designed for a specific frequency band included in FR1 or FR2.

[0208] User interface 1216 includes various input / output (I / O) devices designed to enable users to interact with UE 1200. User interface 1216 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual components for accepting input, particularly including one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touchscreen, a microphone, a scanner, or a head-mounted device. Output device circuitry includes any physical or virtual components for displaying information or otherwise conveying information, such as sensor readings, actuator positions, or other similar information. Output device circuitry may include any number or combination of audio or visual displays, particularly including one or more simple visual outputs / indicators (e.g., binary status indicators, such as light-emitting diodes "LEDs," and multi-character visual outputs), or more complex outputs, such as display devices or touchscreens (e.g., liquid crystal displays (LCDs), LED displays, quantum dot displays, projectors, etc.), wherein the output of characters, graphics, multimedia objects, etc., is generated or produced through the operation of UE 1200.

[0209] Sensor 1220 may include devices, modules, or subsystems designed to detect events or changes in their environment and transmit information about the detected events (sensor data) to other devices, modules, subsystems, etc. Examples of such sensors include, in particular: inertial measurement units including accelerometers, gyroscopes, or magnetometers; microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEMS) including 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (e.g., thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (e.g., cameras or lensless aperture sensors); light detection and ranging sensors; proximity sensors (e.g., infrared radiation detectors, etc.); depth sensors; ambient light sensors; ultrasonic transceivers; microphones or other similar audio capture devices; and so on.

[0210] The driving circuitry 1222 may include software and hardware elements that operate to control a specific device embedded in, attached to, or otherwise communicatively coupled to the UE 1200. The driving circuitry 1222 may include various drivers that allow other components to interact with or control various input / output (I / O) devices that may exist within or be connected to the UE 1200. For example, the driving circuitry 1222 may include: a display driver for controlling and allowing access to a display device; a touchscreen driver for controlling and allowing access to a touchscreen interface; a sensor driver for obtaining sensor readings from the sensor circuitry 1220 and controlling and allowing access to the sensor circuitry 1220; a driver for obtaining actuator positioning of an electromechanical component or controlling and allowing access to an electromechanical component; a camera driver for controlling and allowing access to an embedded image capture device; and an audio driver for controlling and allowing access to one or more audio devices.

[0211] The PMIC 1224 manages the power supplied to various components of the UE 1200. Specifically, relative to the processor 1204, the PMIC 1224 controls power selection, voltage scaling, battery charging, or DC-DC conversion.

[0212] In some implementations, the PMIC 1224 can control or otherwise become part of various power-saving mechanisms of the UE 1200. For example, if the platform UE is in the RRC_Connected state, where it remains connected to the RAN node as it anticipates receiving traffic soon, then after a period of inactivity, the platform UE can enter a state known as Discontinuous Receive Mode (DRX). During this state, the UE 1200 can power down for short intervals, thus saving power. If there is no data service activity during an extended period, the UE 1200 can switch to the RRC_Idle state, where the UE disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The UE 1200 enters a very low-power state, and the UE performs paging, where it periodically wakes up again to listen to the network and then power down again. The UE 1200 cannot receive data in this state; to receive data, the UE must transition back to the RRC_Connected state. An additional power-saving mode renders the device unusable for a period exceeding the paging interval (from seconds to hours). During this time, the device is completely unconnected to the network and may be completely powered off. Any data transmitted during this period will incur significant latency, which is assumed to be acceptable.

[0213] Battery 1228 can power UE 1200, but in some examples, UE 1200 may be installed and deployed in a fixed location and may have a power source coupled to the power grid. Battery 1228 may be a lithium-ion battery, a metal-air battery such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some specific implementations, such as in vehicle-based applications, battery 1228 may be a typical lead-acid automotive battery.

[0214] Figure 13 An example gNB 1300 is illustrated according to some implementation schemes. The gNB 1300 may include a processor 1304, an RF interface circuit 1308, a core network (CN) interface circuit 1312, a memory / storage device circuit 1316, and an antenna structure 1326.

[0215] The components of gNB 1300 can be coupled to various other components via one or more interconnects 1328.

[0216] The processor 1304, RF interface circuit 1308, memory / storage device circuit 1316 (including communication protocol stack 1310), antenna structure 1326, and interconnector 1328 are similar to those described above. Figure 12 Elements with similar names as shown and described.

[0217] The CN interface circuit 1312 can provide connectivity to a core network (e.g., a 5GC using a 5G core network (5GC) compatible network interface protocol, such as carrier Ethernet or some other suitable protocol). Network connectivity can be provided to / from the gNB 1300 via fiber optic or wireless backhaul. The CN interface circuit 1312 may include one or more dedicated processors or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the CN interface circuit 1312 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0218] 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.

[0219] For one or more embodiments, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, or methods described in the Embodiments section below. For example, the baseband circuitry described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more embodiments described below. Similarly, circuitry associated with the UE, base station, network element, etc., described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more embodiments described in the Embodiments section below.

[0220] Example Further exemplary implementations are provided in the following sections.

[0221] Example 1 may include a method of operating a user equipment (UE) with reduced capabilities, the method comprising: identifying a request for an emergency call; establishing a connection to a prohibited access cell of a network based at least in part on the identification of the request for the emergency call; and establishing the emergency call via the prohibited access cell.

[0222] Example 2 may include the method according to Example 1, comprising: identifying an indication for the prohibited access cell, the indication instructing the prohibited access cell to provide emergency support to a UE with reduced capabilities, wherein the UE establishes the connection based at least in part on the identification of the indication.

[0223] Example 3 may include the method according to Example 1, including identifying an indication for the prohibited access cell, the indication indicating that intra-frequency reselection is not allowed, wherein the UE establishes the connection at least in part based on identifying the indication.

[0224] Example 4 may include the method according to Example 1, comprising: determining the reason why the UE considers the forbidden access cell as forbidden access; and identifying an indication to the forbidden access cell, the indication instructing the forbidden access cell to provide emergency support to the UE that considers the forbidden access cell as forbidden access for the reason, wherein the UE establishes the connection based at least in part on identifying the indication.

[0225] Example 5 may include the method according to Example 4, wherein the reason includes that the UE can only operate in half-duplex frequency division duplex (HD-FDD), and wherein the indication instructs the prohibited access cell to provide emergency support for a UE that considers the prohibited access cell to be prohibited from access because the UE can only operate in HD-FDD.

[0226] Example 6 may include the method according to Example 1, wherein the UE considers the forbidden access cell as forbidden access based at least in part on the fact that the forbidden access cell does not support the UE's receive chain requirement, and wherein the UE establishes the connection based at least in part on the fact that the forbidden access cell does not support the UE's receive chain requirement.

[0227] Example 7 may include the method according to Example 1, wherein the UE regards the forbidden access cell as forbidden access based at least in part on the fact that the forbidden access cell does not support the UE's half-duplex frequency division duplex (HD-FDD) requirement, and wherein the UE establishes the connection based at least in part on the fact that the UE regards the forbidden access cell as forbidden access based at least in part on the fact that the forbidden access cell does not support the UE's HD-FDD requirement.

[0228] Example 8 may include the method according to Example 1, wherein the UE considers the prohibited access cell as prohibited for non-emergency calls, and wherein the UE considers the prohibited access cell as acceptable for emergency calls.

[0229] Example 9 may include the method according to Example 1, wherein the UE with reduced capability is a RedCap UE, and wherein the method includes: identifying an indication regarding the prohibited access cell to provide emergency support for the RedCap UE, wherein the UE establishes the emergency call based at least in part on the identification of the indication.

[0230] Example 10 may include the method according to Example 1, wherein the UE with reduced capability is an enhanced capability-reduced (eRedCap) UE, and wherein the method includes: identifying an indication regarding the prohibited access cell to provide emergency support for the eRedCap UE, wherein the UE establishes the emergency call based at least in part on the identification of the indication.

[0231] Example 11 may include a method of operating a user equipment (UE) with reduced capabilities, the method comprising: receiving a system information block 1 (SIB1) of a prohibited access cell from a base station; identifying a request for an emergency call; determining, at least in part, based on the SIB1, whether the prohibited access cell provides emergency support for the UE; and continuing to establish the emergency call based on the determination that the prohibited access cell provides emergency support for the emergency call of the UE with reduced capabilities.

[0232] Example 12 may include the method according to Example 11, wherein determining whether the prohibited access cell provides emergency support to the UE includes: determining that a field of the SIB1 indicates that the prohibited access cell provides emergency support for the UE's emergency call; and determining that the prohibited access cell provides emergency support to the UE based at least in part on the field of the SIB1 indicating that the prohibited access cell provides emergency support for the UE's emergency call, and continuing to establish the emergency call includes: establishing the emergency call with the prohibited access cell based at least in part on the determination that the prohibited access cell provides emergency support to the UE.

[0233] Example 13 may include the method according to Example 11, wherein determining whether the prohibited access cell provides emergency support for the UE includes: determining that a field of the SIB1 indicates that the prohibited access cell provides emergency support for the UE's emergency call; and considering the prohibited access cell as acceptable for the emergency call at least in part based on the field of the SIB1 indicating that the prohibited access cell provides emergency support for the UE's emergency call, and continuing to establish the emergency call includes: establishing the emergency call with the prohibited access cell at least in part based on considering the prohibited access cell as acceptable for the emergency call.

[0234] Example 14 may include the method according to Example 11, wherein the UE considers the forbidden access cell as forbidden access based at least in part on the fact that the forbidden access cell does not support half-duplex frequency division duplex (HD-FDD), and wherein determining whether the forbidden access cell provides emergency support to the UE includes: determining that a field of the SIB1 indicates that the forbidden access cell provides emergency support for HD-FDD, and determining that the forbidden access cell provides emergency support to the UE based at least in part on the fact that the field of the SIB1 indicates that the forbidden access cell provides emergency support for HD-FDD, and continuing to establish the emergency call includes: establishing the emergency call with the forbidden access cell based at least in part on the determination that the forbidden access cell provides emergency support to the UE.

[0235] Example 15 may include the method according to Example 11, wherein the UE considers the forbidden access cell as forbidden access based at least in part on the fact that the forbidden access cell does not support half-duplex frequency division duplex (HD-FDD), and wherein determining whether the forbidden access cell provides emergency support to the UE includes: determining that a field of the SIB1 indicates that the forbidden access cell provides emergency support for HD-FDD, and considering the forbidden access cell as acceptable for emergency calls based at least in part on the fact that the field of the SIB1 indicates that the forbidden access cell provides emergency support for HD-FDD, and continuing to establish the emergency call includes: establishing the emergency call with the forbidden access cell based at least in part on the determination that the forbidden access cell is acceptable for emergency calls.

[0236] Example 16 may include the method according to Example 11, wherein the UE is a RedCap UE, and wherein determining whether the prohibited access cell provides emergency support for the UE includes: determining that a field of the SIB1 indicates that the prohibited access cell provides emergency support for the RedCap UE; and determining that the prohibited access cell provides emergency support for the UE based at least in part on the field of the SIB1 indicating that the prohibited access cell provides emergency support for the RedCap UE, and continuing to establish the emergency call includes: establishing the emergency call with the prohibited access cell based at least in part on the determination that the prohibited access cell provides emergency support for the UE.

[0237] Example 17 may include the method according to Example 11, wherein the UE is an enhanced capability degraded (eRedCap) UE, and wherein determining whether the prohibited access cell provides emergency support for the UE includes: determining that a field of the SIB1 indicates that the prohibited access cell provides emergency support for the eRedCap UE; and determining that the prohibited access cell provides emergency support for the UE based at least in part on the field of the SIB1 indicating that the prohibited access cell provides emergency support for the eRedCap UE, and continuing to establish the emergency call includes: establishing the emergency call with the prohibited access cell based at least in part on the determination that the prohibited access cell provides emergency support for the UE.

[0238] Example 18 may include the method according to Example 11, wherein determining whether the prohibited access cell provides emergency support to the UE includes: determining that a field of the SIB1 indicates that intra-frequency reselection is not allowed; and determining that the prohibited access cell provides emergency support to the UE based at least in part on the field of the SIB1 indicating that intra-frequency reselection is not allowed, and continuing to establish the emergency call includes: establishing the emergency call with the prohibited access cell based at least in part on the determination that the prohibited access cell provides emergency support to the UE.

[0239] Example 19 may include the method according to Example 11, wherein determining whether the prohibited access cell provides emergency support to the UE includes: determining that a field indication of SIB1 does not allow intra-frequency reselection; and determining that the prohibited access cell provides emergency support to the UE based at least in part on the field indication of SIB1 allowing intra-frequency reselection, and continuing to establish the emergency call includes: identifying a second cell providing emergency support to the UE based at least in part on the field indication of SIB1 allowing intra-frequency reselection, the second cell operating in the same frequency range as the prohibited access cell; and establishing the emergency call with the second cell.

[0240] Example 20 may include a method of operating a base station, the method comprising: generating a system information block 1 (SIB1) of a cell of a network, the SIB1 including at least one field related to an emergency call of a user equipment (UE) with reduced capabilities; receiving a query from the UE for information related to the cell; and sending the SIB1 to the UE based at least in part on the query.

[0241] Example 21 may include the method according to Example 20, wherein SIB1 includes a field indicating whether the cell provides emergency support for half-duplex frequency division duplex (HD-FDD).

[0242] Example 22 may include the method according to Example 20, wherein the SIB1 includes a field indicating whether the cell provides emergency support for a RedCap UE.

[0243] Example 23 may include the method according to Example 20, wherein the SIB1 includes a field indicating whether the cell provides emergency support for an enhanced capability degraded (eRedCap) UE.

[0244] Example 24 may include the method according to Example 20, wherein the cell is a first cell, and wherein the SIB1 includes a field indicating whether the UE wants to search for a second cell operating in the same frequency range as the first cell to provide emergency support for the UE's emergency calls.

[0245] Example 25 may include the method according to Example 20, wherein the cell is a first cell, and wherein the SIB1 includes a first field and a second field, the first field indicating whether a RedCap UE should search for another cell operating in the same frequency range as the first cell to provide emergency support for an emergency call of the RedCap UE, and the second field indicating whether an eRedCap UE should search for another cell operating in the same frequency range as the first cell to provide emergency support for an emergency call of the eRedCap UE.

[0246] Example 26 may include an apparatus comprising one or more elements for performing the method described or associated with any of Examples 1 to 25 or any other method or process described herein.

[0247] Example 27 may include one or more non-transitory computer-readable media, the non-transitory computer-readable media including one or more elements of instructions to cause the electronic device to perform, when executed by one or more processors of the electronic device, one or more of the elements of the method described or associated with any of Examples 1 to 25 or any other method or process described herein.

[0248] Example 28 may include an apparatus comprising one or more elements of a logic component, module, or circuit for performing a method described or associated with any of Examples 1 to 25 or any other method or process described herein.

[0249] Example 29 may include the methods, techniques or processes, or parts or components thereof, described or associated with any of Examples 1 to 25.

[0250] Example 30 may 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 a method, technique, or process, or a portion thereof, described or associated with any of Examples 1 to 25.

[0251] Example 31 may include signals, or parts thereof, described or associated with any of Examples 1 to 25.

[0252] Example 32 may include datagrams, information elements, packets, frames, segments, PDUs, or messages, or portions or components thereof, as described or associated with any of Examples 1 to 25 or otherwise described in this disclosure.

[0253] Example 33 may include a data-encoded signal, or a portion thereof, described or associated with any of Examples 1 to 25 or otherwise described in this disclosure.

[0254] Example 34 may include signals, or portions thereof, encoded as datagrams, IEs, packets, frames, segments, PDUs, or messages as described or associated with any of Examples 1 to 25 or otherwise described in this disclosure.

[0255] Example 35 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform a method, technique, or process, or a portion thereof, described or associated with any of Examples 1 to 25.

[0256] Example 36 may include a computer program comprising instructions, wherein execution of the program by a processing element will cause the processing element to perform a method, technique, or process, or a portion thereof, described or associated with any of Examples 1 to 25.

[0257] Example 37 may include a signal in a wireless network as shown and described herein.

[0258] Example 38 may include a method for communicating in a wireless network as shown and described herein.

[0259] Example 39 may include a system for providing wireless communication as shown and described herein.

[0260] Example 40 may include a device for providing wireless communication as shown and described herein.

[0261] Unless otherwise expressly stated, any embodiment described above may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific embodiments is illustrative and descriptive, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. In view of the teachings above, modifications and variations are possible, or modifications and variations may be obtained from practice of various embodiments.

[0262] Although the above embodiments have been described in considerable detail, many variations and modifications will become apparent to those skilled in the art once the above disclosure is fully understood. It is intended that the following claims be construed as encompassing all such variations and modifications.

Claims

1. A method for operating user equipment (UE) with reduced capabilities, the method comprising: Identify requests for emergency calls; A connection to a prohibited cell of the network is established, at least in part, based on the identification of the request in the emergency call. as well as The emergency call is established via the prohibited access cell.

2. The method according to claim 1, wherein the method comprises: Identify an indication to the prohibited access cell, the indication instructing the prohibited access cell to provide emergency support to a UE with reduced capabilities, wherein the UE establishes the connection based at least in part on the identification of the indication.

3. The method according to claim 1, wherein the method comprises: The UE identifies an indication for the prohibited cell, the indication indicating that intra-frequency reselection is not allowed, wherein the UE establishes the connection based at least in part on the identification of the indication.

4. The method according to claim 1, wherein the method comprises: Determine the reason why the UE considers the prohibited cell as a prohibited access point; as well as Identify an indication to the forbidden cell, the indication instructing the forbidden cell to provide emergency support to a UE that considers the forbidden cell as forbidden for the reason, wherein the UE establishes the connection based at least in part on the identification of the indication.

5. The method of claim 4, wherein the reason includes that the UE is only capable of operating in half-duplex frequency division duplex (HD-FDD), and wherein the indication instructs the prohibited access cell to provide emergency support for a UE that considers the prohibited access cell as prohibited access because the UE is only capable of operating in HD-FDD.

6. The method of claim 1, wherein the UE considers the forbidden access cell as forbidden access based at least in part on the fact that the forbidden access cell does not support the UE's receive chain requirement, and wherein the UE establishes the connection based at least in part on the fact that the UE considers the forbidden access cell as forbidden access based at least in part on the fact that the forbidden access cell does not support the UE's receive chain requirement.

7. The method of claim 1, wherein the UE considers the forbidden access cell as forbidden access based at least in part on the fact that the forbidden access cell does not support the UE's half-duplex frequency division duplex (HD-FDD) requirement, and wherein the UE establishes the connection based at least in part on the fact that the UE considers the forbidden access cell as forbidden access based at least in part on the fact that the forbidden access cell does not support the UE's HD-FDD requirement.

8. The method of claim 1, wherein the UE considers the prohibited access cell as prohibited for non-emergency calls, and wherein the UE considers the prohibited access cell as acceptable for emergency calls.

9. The method of claim 1, wherein the UE with reduced capability is a RedCap UE, and wherein the method comprises: Identify an instruction regarding the prohibited access cell to provide emergency support to a RedCap UE, wherein the UE establishes the emergency call based at least in part on the identification of the instruction.

10. The method of claim 1, wherein the UE having reduced capability is an enhanced capability-reduced (eRedCap) UE, and wherein the method comprises: Identify an instruction regarding the prohibited access cell to provide emergency support to an eRedCap UE, wherein the UE establishes the emergency call based at least in part on the identification of the instruction.

11. A method of operating user equipment (UE) with reduced capabilities, the method comprising: Receive System Information Block 1 (SIB1) from the base station, which prohibits access to the cell. Identify requests for emergency calls; Whether the prohibited access cell should provide emergency support to the UE is determined at least in part based on the SIB1. as well as The emergency call can continue to be established based on whether the prohibited access cell provides emergency support for an emergency call of a UE with reduced capabilities.

12. The method according to claim 11, wherein: Determining whether the prohibited access cell should provide emergency support to the UE includes: The field of SIB1 is determined to instruct the prohibited access cell to provide emergency support for the UE's emergency call; and The prohibited access cell is determined to provide emergency support to the UE based at least in part on the field of SIB1 indicating that the prohibited access cell provides emergency support for the UE's emergency call; and Continuing to establish the emergency call includes: establishing the emergency call with the prohibited access cell based at least in part on the determination that the prohibited access cell provides emergency support to the UE.

13. The method according to claim 11, wherein: Determining whether the prohibited access cell should provide emergency support to the UE includes: The field of SIB1 is determined to instruct the prohibited access cell to provide emergency support for the UE's emergency call; and At least in part, based on the field of SIB1 indicating that the prohibited access cell provides emergency support for the UE's emergency call, the prohibited access cell is considered acceptable for emergency calls; and Continuing to establish the emergency call includes: establishing the emergency call with the prohibited cell at least in part based on the assumption that the prohibited cell is acceptable for an emergency call.

14. The method of claim 11, wherein the UE considers the prohibited access cell as prohibited access based at least in part on the fact that the prohibited access cell does not support half-duplex frequency division duplex (HD-FDD), and wherein: Determining whether the prohibited access cell should provide emergency support to the UE includes: The field of SIB1 is determined to indicate that the prohibited access cell provides emergency support for HD-FDD; and At least in part based on the field of SIB1, the prohibited access cell is instructed to provide emergency support for HD-FDD, and it is determined that the prohibited access cell provides emergency support for the UE; and Continuing to establish the emergency call includes: establishing the emergency call with the prohibited access cell based at least in part on the determination that the prohibited access cell provides emergency support to the UE.

15. The method of claim 11, wherein the UE considers the prohibited access cell as prohibited access based at least in part on the fact that the prohibited access cell does not support half-duplex frequency division duplex (HD-FDD), and wherein: Determining whether the prohibited access cell should provide emergency support to the UE includes: The field of SIB1 is determined to indicate that the prohibited access cell provides emergency support for HD-FDD; and At least in part, based on the field of SIB1, the prohibited access cell is indicated to provide emergency support for HD-FDD, and the prohibited access cell is considered acceptable for emergency calls; and Continuing to establish the emergency call includes: establishing the emergency call with the prohibited cell at least in part based on the assumption that the prohibited cell is acceptable for an emergency call.

16. The method of claim 11, wherein the UE is a capability-reduced (RedCap) UE, and wherein: Determining whether the prohibited access cell should provide emergency support to the UE includes: The field of SIB1 is determined to indicate that the prohibited access cell provides emergency support for the RedCap UE; and The prohibited access cell is determined to provide emergency support to the RedCap UE, at least in part based on the field of SIB1 indicating that the prohibited access cell provides emergency support to the UE; and Continuing to establish the emergency call includes: establishing the emergency call with the prohibited access cell based at least in part on the determination that the prohibited access cell provides emergency support to the UE.

17. The method of claim 11, wherein the UE is an enhanced capability-reduced (eRedCap) UE, and wherein: Determining whether the prohibited access cell should provide emergency support to the UE includes: The field of SIB1 is determined to indicate that the prohibited access cell provides emergency support for the eRedCap UE; and At least in part based on the field of SIB1, the prohibited access cell is instructed to provide emergency support to the eRedCap UE, thus determining that the prohibited access cell provides emergency support to the UE; and Continuing to establish the emergency call includes: establishing the emergency call with the prohibited access cell based at least in part on the determination that the prohibited access cell provides emergency support to the UE.

18. The method according to claim 11, wherein: Determining whether the prohibited access cell should provide emergency support to the UE includes: It is determined that the field indication of SIB1 does not allow intra-frequency reselection; and At least in part based on the field indication of SIB1 indicating that intra-frequency reselection is not allowed, the prohibited access cell is determined to provide emergency support to the UE; and Continuing to establish the emergency call includes: establishing the emergency call with the prohibited access cell based at least in part on the determination that the prohibited access cell provides emergency support to the UE.

19. The method according to claim 11, wherein: Determining whether the prohibited access cell should provide emergency support to the UE includes: It is determined that the field indication of SIB1 does not allow intra-frequency reselection; and At least in part based on the field indication of SIB1 allowing intra-frequency reselection, the prohibited access cell is determined to provide emergency support to the UE; and To continue establishing the emergency call, the following steps are required: The second cell, operating within the same frequency range as the prohibited access cell, is identified at least in part based on the field indication of SIB1 that allows intra-frequency reselection; and Establish the emergency call with the second cell.

20. A method of operating a base station, the method comprising: The system information block 1 (SIB1) of the cell of the network is generated, the SIB1 including at least one field related to an emergency call of a user equipment (UE) with reduced capabilities; Receive queries from the UE for information related to the cell; as well as The SIB1 is sent to the UE based at least in part on the query.

21. The method of claim 20, wherein the SIB1 includes a field indicating whether the cell provides emergency support for half-duplex frequency division duplex (HD-FDD).

22. The method of claim 20, wherein the SIB1 includes a field indicating whether the cell provides emergency support for a RedCap UE.

23. The method of claim 20, wherein the SIB1 includes a field indicating whether the cell provides emergency support for an enhanced capability degraded (eRedCap) UE.

24. The method of claim 20, wherein the cell is a first cell, and wherein the SIB1 includes a field indicating whether the UE wants to search for a second cell operating in the same frequency range as the first cell to provide emergency support for the UE's emergency calls.

25. The method of claim 20, wherein the cell is a first cell, and wherein SIB1 comprises: The first field indicates whether a RedCap UE with reduced capability should search for another cell operating in the same frequency range as the first cell to provide emergency support for emergency calls from RedCap UEs. and The second field indicates whether the enhanced capability reduced (eRedCap) UE should search for another cell operating in the same frequency range as the first cell to provide emergency support for emergency calls of the eRedCap UE.