System and method for using a radio frequency device with reduced capabilities for emergency service access

Abstract

The present disclosure relates to systems and methods for emergency service access using radio frequency devices with reduced capabilities. An electronic device may transmit a communication request to a base station, the communication request having an indication of the number of receive branches of the electronic device and an indication of whether the communication request is designated for urgent service fulfillment. The base station may delay the rejection of the communication request until it receives an indication of whether the communication request is designated for use with the urgent service fulfillment to reduce the likelihood of prematurely rejecting the communication request. The base station may also transfer the communication request to a base station that supports the urgent service fulfillment. When the communication request of the user equipment is designated for urgent service fulfillment, the base station may also be prohibited from transferring the user equipment to a frequency layer preferred by the base station.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 196,550, filed on June 3, 2021, entitled "SYSTEMS AND METHODS FOR EMERGENCY SERVICE ACCESS BY REDUCED CAPABILITY RADIO FREQUENCY DEVICES", the entire disclosure of which is incorporated herein by reference for all purposes. BACKGROUND OF THE DISCLOSURE

[0003] The present disclosure relates generally to wireless communications, and more particularly, to emergency service network access by reduced-capability radio frequency devices.

[0004] In cellular communications, user equipment (e.g., a mobile phone) may communicate (e.g., with a base station) under guidelines or rules that may be set and enforced by regulatory and / or standards bodies such as the Federal Communications Commission (FCC), the Third Generation Partnership Project (3GPP), the European Telecommunications Standards Institute (ETSI), etc. These guidelines may limit access of reduced-capability user equipment to certain portions of the wireless network. Reduced-capability user equipment (e.g., as defined by 3GPP) may include user equipment having a reduced number of receive chains (e.g., a cascade of electronic components and subunits for receiving wireless signals, which may include amplifiers, filters, mixers, attenuators, etc.) compared to a full-capability or "baseline" radio frequency device. However, these guidelines or rules may cause the network to deny emergency-related network access requests (e.g., 911 calls, alarm calls) based on the number of antennas or receive chains without first ascertaining whether the network access request is an emergency-related network request. SUMMARY OF THE DISCLOSURE

[0005] A summary of certain embodiments disclosed herein is set forth below. It should be understood that these aspects are presented merely to provide the reader with a concise summary of these particular embodiments and are not intended to limit the scope of the present disclosure. Indeed, the present disclosure may cover a variety of aspects that may not be set forth below.

[0006] In one embodiment, a method of operating a base station may include the base station receiving a random access preamble corresponding to a connection request from a user equipment. The random access preamble may include a first indication of the number of receive branches associated with the user equipment. The base station may include a second indication from the user equipment that the connection request is associated with an emergency. The base station may determine to fulfill the connection request based on the first indication and the second indication, and may transmit a contention resolution response in response to determining to fulfill the connection request.

[0007] In another embodiment, the user equipment with reduced capabilities may include one or more antennas coupled to a transmit branch and include only one receive branch. The user equipment may include processing circuitry that transmits a random access preamble to a base station using the transmit branch, where the random access preamble includes a first indication of only one receive branch and a second indication of a request for access to an emergency service. The processing circuitry may also use only one receive branch to receive a contention resolution response from the base station to establish a connection with the base station in response to the base station accepting the request for access to the emergency service.

[0008] In yet another embodiment, the base station may include a transceiver and processing circuitry that may receive, via the transceiver, a connection request from an electronic device to establish communication over a desired frequency range used by the transceiver. The processing circuitry may determine that the desired frequency range indicated in the connection request is outside a preferred frequency range. In response to determining that the desired frequency range is outside the preferred frequency range, the processing circuitry may determine that the connection request corresponds to a critical service fulfillment, and in response to determining that the connection request corresponds to a critical service fulfillment, the processing circuitry may establish communication with the electronic device over the desired frequency range.

[0009] Various improvements to the above features may exist with respect to various aspects of the present invention. Other features may also be added to these various aspects. These improvements and additional features may exist alone or in any combination. For example, the various features discussed below in connection with one or more of the illustrated embodiments may be incorporated, alone or in any combination, into any one of the above aspects of the present invention. The brief summary presented above is only intended to familiarize the reader with particular aspects and contexts of the embodiments of the present disclosure and does not limit the subject matter claimed. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Aspects of the present disclosure may be better understood when the following detailed description is read and reference is made to the drawings described below, in which like numerals refer to like parts.

[0011] Figure 1 is a block diagram of an electronic device according to an embodiment of the present disclosure;

[0012] Figure 2 is according to an embodiment of the present disclosure Figure 1 of the electronic device;

[0013] Figure 3 is according to an embodiment of the present disclosure Figure 2 of the receiver;

[0014] Figure 4 is supported by a base station and communicatively coupled to according to an embodiment of the present disclosure Figure 1A schematic diagram of a wireless communication network of electronic devices;

[0015] Figure 5A and Figure 5B (collectively referred to herein as FIG. 5 ) is a flow chart of a method according to an embodiment of the present disclosure for providing a random access preamble (MSG1) Figure 1 An indication of the number of receiving (RX) branches of an electronic device and an indication of an emergency situation and preventing Figure 4 The base station causes the electronic device to be disconnected when connected for emergency purposes;

[0016] Figure 6A and Figure 6B (collectively referred to herein as FIG. 6 ) is a flow chart of a method according to an embodiment of the present disclosure for providing a random access preamble (MSG1) Figure 1 The number of receiving (RX) branches of the electronic device and the indication of the emergency situation in the RRCSetupRequest (MSG3) and prevent Figure 4 The base station causes the electronic device to be disconnected when connected for emergency purposes;

[0017] Figure 7 is a method for ensuring that Figure 4 The base station from Figure 4 A flowchart of a method for handing over an electronic device to another base station supporting communications for emergency purposes; and

[0018] Figure 8 According to the embodiment of the present disclosure, Figure 4 Flowchart of a method for enabling an electronic device, even a device with reduced capabilities, to operate on a non-preferred or prohibited frequency layer for emergency purposes. DETAILED DESCRIPTION

[0019] One or more specific embodiments will be described below. In order to provide a brief description of these embodiments, not all features of the actual implementation are described in this specification. It should be understood that in the development of any such actual implementation, as in any engineering or design project, decisions specific to many implementations must be made to achieve the developer's specific goals, such as compliance with system-related and business-related constraints that may change from one implementation to another. In addition, it should be understood that such development work may be complex and time-consuming, but for those of ordinary skill in the art who benefit from this disclosure, it will still be a routine task of design, processing and manufacturing.

[0020] When introducing elements of the various embodiments of the present disclosure, the articles "a" and "the" are intended to mean that there is one or more of the elements. The terms "comprising," "including," and "having" are intended to be inclusive and mean that additional elements may exist in addition to the listed elements. Additionally, it should be understood that references to "one embodiment" or "an embodiment" of the present disclosure are not intended to be construed as excluding the existence of additional embodiments that also incorporate the recited features. Furthermore, the specific features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. The use of the terms "substantially," "nearly," "about," and / or "essentially" should be understood to mean including being close to the target (e.g., design, value, quantity), such as within any suitable or conceivable margin of error (e.g., within 0.1% of the target, within 1% of the target, within 5% of the target, within 10% of the target, within 25% of the target, etc.).

[0021] In wireless (e.g., cellular) communications, a user equipment (e.g., a cellular phone, a smart phone, a tablet, a wearable device, a laptop computer, etc.) can communicate with a network (e.g., a wireless communication network) via one or more communication nodes (e.g., a base station) on a channel in a frequency band (e.g., a Frequency Range 1 (FR1) band (0.41 megahertz (GHz) to 7.125 GHz) band, a Frequency Range 2 (FR2) band (24.25 GHz to 52.6 GHz), etc.). Specifically, according to the current 3rd Generation Partnership Project (3GPP) standard, when establishing communication with the network via a base station, the user equipment can detect network coverage (e.g., at a cell supported by the base station) and receive system information including the frequency of the channel from the base station. If the user equipment supports the frequency, the user equipment so indicates to the base station, and the network can allocate the channel to the user equipment, noting that the user equipment supports the frequency band including the frequency of the channel (e.g., the FR1 band, the FR2 band, etc.). When performing a handover event (e.g., transferring the network coverage of the user equipment from a base station to another base station), the base station can indicate that the user equipment supports the frequency band (e.g., to another base station) based on the user equipment indicating that it supports the frequency of the channel.

[0022] The Release 17 (Rel-17) New Radio (NR) work plan of the 3rd Generation Partnership Project (3GPP) considers supporting Reduced Capability (RedCap) devices, which will be a change from previous iterations that mandated user equipment to have multiple Receiver (RX) chains or branches (e.g., two RX branches, four RX branches). In fact, the current work item (RP-210918) mandates network support for devices with one Receiver (RX) chain (e.g., one antenna and one receiver), which are referred to as RedCap devices in this document. Specifically, Rel-17 defines RedCap devices based on the number of RX branches of a full-capability or "baseline" device. According to Rel-17, for bands that require a baseline NR device to be equipped with at least two RX branches (e.g., FR2, some bands in FR1), a RedCap device only needs to have one RX branch. The specification also supports two RX branches for RedCap UEs in these bands. For bands that require a baseline NR device to be equipped with at least four RX branches (e.g., some bands in FR1), the minimum number of RX branches supported by the specification for RedCap UEs is 1. The specification also supports two RX branches for RedCap UEs in these bands. Table 1 below shows a comparison of the device capabilities between a baseline NR device (as defined by the Release 15 NR work plan of 3GPP) and a RedCap device as defined by Rel-17.

[0023]

[0024] Specifically, a baseline NR device is required to support 100 megahertz (MHz) in FR1 and 200 MHz in FR2 for transmission and reception. For RedCap devices, these requirements are reduced to 20 MHz and 100 MHz, respectively. Additionally, since the number of RX branches can be related to the number of RX antennas, reducing the number of RX branches results in a reduction in the number of RX antennas and cost savings. The requirement for the minimum number of RX branches can depend on the band. Some bands (most FR1 Frequency Division Duplexing (FDD) bands, a few FR1 Time Division Duplexing (TDD) bands, and all FR2 bands) require a baseline NR device to be equipped with two RX branches, while some other bands (mainly in FR1 TDD bands) require a baseline NR device to be equipped with four receive branches. As previously mentioned, for bands that require a baseline NR device to be equipped with at least two RX branches, a RedCap device is only required to have one RX branch, while two RX branches are also supported. For bands that require a baseline NR device to be equipped with at least four RX branches, a RedCap device is required to have one or two RX branches.

[0025] In addition, the maximum number of downlink multiple-input and multiple-output (MIMO) layers for a RedCap device is the same as the number of RX branches supported by the RedCap device. This represents a reduction compared to the requirements for a baseline device. The baseline NR device is also required to support 256 quadrature amplitude modulation (QAM) in the downlink in FR1. For RedCap devices, support for downlink 256QAM is optional. For both the FR1 uplink and both the FR2 downlink and uplink, RedCap devices are required to support 64QAM, the same as the requirements for a baseline device.

[0026] Regarding duplex operation, the baseline NR device is required to support full-duplex (FD) operation (e.g., transmit and receive simultaneously on different frequencies) in FDD bands. A full-duplex device can incorporate a duplex filter to isolate interference between the device's transmit and receive paths. In practice, the same device may need to support multiple FDD bands; thus, multiple duplex filters may be required to support FD-FDD operation.

[0027] For RedCap devices, support for FD-FDD is optional (e.g., it is not required to receive on a downlink frequency and transmit on an uplink frequency and vice versa). Instead, RedCap devices can support half-duplex FDD (HD-FDD) operation, which eliminates the need for a duplex filter. Instead, a switch can be used to select the transmitter or receiver to connect to the antenna. Since switches are less expensive than multiple duplexers, cost savings are achieved. In addition, it is expected that RedCap devices will operate in a single band at a time and will not support carrier aggregation and dual connectivity. Thus, enabling RedCap devices via Rel-17 allows devices with reduced material costs and complexity compared to baseline NR devices to access network resources.

[0028] A base station can deny access to its network by a user equipment (e.g., RRC connection rejection, cell barring) based on the number of RX branches of the user equipment, the amount of ongoing cell load, signal quality considerations, or other network conditions that occur or are expected to occur in response to the user equipment being accepted onto the network. For example, when a user equipment has a different number of RX branches than preferred, the base station can deny user equipment access to the network.

[0029] This rejection can occur when the base station receives an indication of the number of RX branches and before the user equipment transmits an indication that it is requesting access to emergency services (such as making a 911-related emergency call, calling the police station, communication initiated by a panic button, etc.). In fact, if the user equipment (UE) transmits an early indication of the number of RX branches in a random access request (MSG1), the base station may ignore the random access request from the user equipment and not transmit a random access response (MSG2), thereby causing the UE to time out and attempt to access another base station. Additionally, if the user equipment transmits an early indication of the number of RX branches in a random access request (MSG1) or in a request to establish a radio resource control connection (e.g., RRCSetupRequest (MSG3)), the base station may decide to reject the RRC connection request by sending an RRCReject message in its contention resolution response (MSG4). Further, if the user equipment does not transmit an early indication of the number of RX branches but transmits the UE capability of the supported number of RX branches in a subsequent UECapabilityInformation RRC message, the base station may decide to release or suspend the RRC connection using an RRCRelease message, thereby causing the user equipment to enter the IDLE state and initiate a cell selection procedure, or the base station may decide to initiate a handover procedure for the user equipment using an RRCReconfiguration message. In each of the three examples above, when the request of the user equipment is vetoed before receiving an indication of whether the request is for emergency service access, the base station may reject the request for emergency services, which are otherwise required by Federal Communications Commission (FCC) guidelines to be completed by network providers.

[0030] Under FCC governance, FCC guidelines specify how base stations should handle requests from user equipment for access to emergency services. For example, base stations may be required to grant user equipment access to requests for emergency service access under Title 47 C.F.R. Part 9 of the FCC, where Section 9.10 specifies the requirements for commercial mobile radio services. The RRC specifications further define emergency service handling operations. For example, 3GPP's Technical Specification 38.331 (TS38.331) defines information elements related to when a user equipment will identify a request as being for emergency services, and Technical Specification 38.00 (TS38.00) defines network behavior related to requests for emergency services. Specifically, TS38.00 defines that base stations are used to classify access attempts associated with emergency requests having a relatively higher priority and to reject these access attempts under relatively extreme network load conditions that may endanger the stability of the base station itself.

[0031] Embodiments of the present disclosure relate to complying with FCC guidelines for emergency service access requests and complying with 3GPP standard changes for supporting RedCap devices and cell barring. To comply with both, the base station may deny access to the user equipment based on the preferred number of RX branches after confirming that the request from the user equipment is not for emergency service access.

[0032] For example, the base station may receive a first indication of whether an emergency service access is requested and a second indication of the number of RX branches from the user equipment. To this end, the first indication may indicate whether the RRC connection is established due to a connection reason that may include an emergency service access request or has a relatively elevated fulfillment priority or urgency (such as an emergency connection reason (e.g., for an emergency call user), an mps-PriorityAccess connection reason (e.g., for a multimedia priority service user), or an mcs-PriorityAccess connection reason (e.g., for a mission-critical service user)). Based on these indications, the base station may grant or deny access to the network for the user equipment.

[0033] In many use cases, it may be beneficial to use these indications. For example, a jogger carrying a RedCap "smart" watch (e.g., a watch that supports the Internet or a cellular network) may use the watch to make a 5G NR network connection to stream music, maps, health apps, etc., and may benefit from the smart watch, which may have only one RX branch, so as not to be denied access to the network when an emergency request is made, even if the smart watch is not communicatively coupled to a smart phone. As another example, an emergency responder (e.g., a police officer, a firefighter, a physician) may request emergency service access via a RedCap wearable device (e.g., a smart watch, a cellular-connected headset) in the absence of a nearby or connected cellular phone.

[0034] Different systems and methods can be used to improve the way the base station responds to the first and second indications and reduce the likelihood that the base station prematurely rejects an emergency service access request from a Reduced Capability (RedCap) device. In one case, the random access preamble (MSG1) message can include a first indication of whether the RRC connection is established for an emergency service access request or has a relatively elevated fulfillment priority or urgency, and a second indication of the number of RX branches, both of which can be appended to other network setup information (e.g., random access preamble information). In some cases, the first and second indications can be included in the RRCSetupRequest (MSG3) message information or the UECapabilityInformation message. As a second example, the user equipment can transmit the first indication using the random access preamble (MSG1) and transmit the second indication as part of the RRCSetupRequest (MSG3). In the second example, the base station can have a limited response to the random access preamble (MSG1) while waiting for the second indication in the RRCSetupRequest (MSG3) to arrive, so as to avoid premature termination of the emergency request. As a third example, the user equipment can connect to the base station on a frequency layer not allowed for RedCap devices. However, in this case, the base station can allow the user equipment to use this frequency layer for emergency calls and ignore the prohibition.

[0035] In addition, as a fourth example, when a RedCap device moves from a first coverage area supported by a first base station to a second coverage area supported by a second base station, the first base station can attempt to hand over the network coverage of the user equipment to the second base station. If the first base station can provide emergency services to the RedCap device, the first base station can confirm that the second base station can also provide emergency services to the RedCap device. Specifically, when performing the handover procedure, the first base station can receive a System Information Block (SIB) (e.g., ims-EmergencySupport message) from the second base station that can indicate whether the second base station supports emergency services. The first base station can hand over the RedCap device to the second base station only if the second base station supports emergency services, thus ensuring that the RedCap device will not be disconnected from the network due to having an insufficient number of RX branches and ensuring that the communication of the RedCap devices receives a higher priority due to their emergency nature.

[0036] With this in mind, Figure 1is a block diagram of an electronic device 10. Among other things, the electronic device 10 can include one or more processors 12 (collectively referred to herein as a single processor for convenience, which can be implemented in any suitable form of processing circuitry), a memory 14, a non-volatile storage device 16, a display 18, an input structure 22, an input / output (I / O) interface 24, a network interface 26, and a power supply 29. Figure 1 The various functional blocks shown in can include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware elements and software elements. The processor 12, the memory 14, the non-volatile storage device 16, the display 18, the input structure 22, the input / output (I / O) interface 24, the network interface 26, and / or the power supply 29 can each be communicatively coupled directly or indirectly to one another (e.g., through or via another component, a communication bus, a network) to transmit and / or receive data between each other. It should be noted that Figure 1 is only an example of a particular specific implementation and is intended to illustrate the types of components that can be present in the electronic device 10.

[0037] For example, the electronic device 10 can represent a block diagram of any suitable computing device, including a desktop computer or a laptop computer (e.g., in the form of a Pro, MacBook mini or Mac form), a portable electronic device or a handheld electronic device such as a wireless electronic device or a smartphone (e.g., in the form of a model available from Apple Inc., Cupertino, California), a tablet computer (e.g., in the form of a model available from Apple Inc., Cupertino, California), a wearable electronic device (e.g., in the form of an Apple available from Apple Inc., Cupertino, California), a cellular network-enabled watch device, a cellular device, and other similar devices. It should be noted that Figure 1 the processor 12 and other related items in can be generally referred to herein as "data processing circuitry". Such data processing circuitry can be implemented in whole or in part as software, software, hardware, or any combination thereof. In addition, the processor 12 and Figure 1Other related items therein may be a single independent processing module or may be incorporated, in whole or in part, into any one of the other elements within the electronic device 10. The processor 12 may be implemented as a combination of a general-purpose microprocessor, a microcontroller, a digital signal processor (DSP), a field-programmable gate array (FPGA), a programmable logic device (PLD), a controller, a state machine, gated logic, discrete hardware components, a dedicated hardware finite state machine, or any other suitable entity capable of performing computations or other manipulations of information. The processor 12 may perform the various functions described herein and below.

[0038] In Figure 1 In the electronic device 10, the processor 12 may be operatively coupled to the memory 14 and the non-volatile storage device 16 to execute various algorithms. Such programs or instructions executed by the processor 12 may be stored in any suitable article of manufacture comprising one or more tangible computer-readable media. The tangible computer-readable media may include the memory 14 and / or the non-volatile storage device 16, either alone or in combination, to store instructions or routines. The memory 14 and the non-volatile storage device 16 may include any suitable article of manufacture for storing data and executable instructions, such as random access memory, read-only memory, rewritable flash memory, hard disk drives, and optical discs. In addition, programs encoded on such computer program products (e.g., operating systems) may also include instructions executable by the processor 12 to enable the electronic device 10 to provide various functions.

[0039] In certain embodiments, the display 18 may facilitate a user's viewing of images generated on the electronic device 10. In some embodiments, the display 18 may include a touch screen that may facilitate a user's interaction with the user interface of the electronic device 10. In addition, it should be understood that in some embodiments, the display 18 may include one or more liquid crystal displays (LCDs), light-emitting diode (LED) displays, organic light-emitting diode (OLED) displays, active matrix organic light-emitting diode (AMOLED) displays, or some combination of these and / or other display technologies.

[0040] The input structure 22 of the electronic device 10 may enable a user to interact with the electronic device 10 (e.g., press a button to increase or decrease the volume level). Similar to the network interface 26, the I / O interface 24 may enable the electronic device 10 to interact with various other electronic devices. In some embodiments, the I / O interface 24 may include I / O ports for hardwired connections for charging and / or content manipulation using standard connectors and protocols such as the Lightning connector, Universal Serial Bus (USB), or other similar connectors and protocols provided by Apple Inc. of Cupertino, California. The network interface 26 may include, for example, one or more interfaces for: a personal area network (PAN) such as a network, a local area network (LAN), or a wireless local area network (WLAN) such as a network that employs one of the IEEE 802.11x series of protocols (e.g., ) and / or a wide area network (WAN) such as any standard associated with the 3rd Generation Partnership Project (3GPP) including, for example, a 3rd generation (3G) cellular network, Universal Mobile Telecommunications System (UMTS), 4th generation (4G) cellular network, Long Term Evolution cellular network, Long Term Evolution Licensed-Assisted Access (LTE-LAA) cellular network, 5th generation (5G) cellular network, and / or New Radio (NR) cellular network, satellite network, etc. Specifically, the network interface 26 may include, for example, one or more interfaces for using the Release-15 cellular communication standard of the 5G specification that includes the millimeter wave (mmWave) frequency range (e.g., 24.25 - 300 gigahertz (GHz)). The network interface 26 of the electronic device 10 may allow communication over the aforementioned networks (e.g., 5G, Wi-Fi, LTE-LAA, etc.).

[0041] The network interface 26 may also include, for example, one or more interfaces for: a broadband fixed wireless access network (e.g., )、a mobile broadband wireless network (mobile )、asynchronous digital subscriber line (e.g., ADSL, VDSL), digital video terrestrial broadcast network and its extension DVB Handheld network, ultra-wideband (UWB) network, alternating current (AC) power line, etc.

[0042] As shown, network interface 26 may include transceiver 30. In some embodiments, all or part of transceiver 30 may be disposed within processor 12. Transceiver 30 may support transmitting and receiving various wireless signals via one or more antennas. Power supply 29 of electronic device 10 may include any suitable power supply, such as a rechargeable lithium polymer (Li-poly) battery and / or an alternating current (AC) power converter. In certain embodiments, electronic device 10 may take the form of a computer, a portable electronic device, a wearable electronic device, or other types of electronic devices.

[0043] Figure 2 is a functional block diagram of electronic device 10 according to an embodiment of the present disclosure, which may implement the components shown Figure 1 and / or the circuits and / or components described in the following figures as a reduced-capability (RedCap) device. As shown, processor 12, memory 14, transceiver 30, transmitter 52, receiver 54, and / or antenna 55 may be communicatively coupled to each other directly or indirectly (e.g., through or via another component, a communication bus, a network) to transmit and / or receive data between each other.

[0044] Electronic device 10 may include transmitter 52 and / or receiver 54, which respectively enable transmitting and receiving data between electronic device 10 and a remote location via, for example, a network associated with electronic device 10 or a direct connection and an external transceiver (e.g., in the form of a cell, an eNB (E-UTRAN Node B or evolved Node B), a base station, etc.). As shown, transmitter 52 and receiver 54 may be combined into transceiver 30. Electronic device 10 may also have antenna 55, which is electrically coupled to transceiver 30. Antenna 55 may be configured in an omnidirectional or directional configuration, a single-beam, dual-beam, or multi-beam arrangement, etc. Antenna 55 may be associated with beams and various configurations. In some embodiments, the beam corresponds to transceiver 30. In a non-reduced-capability device (e.g., a non-RedCap or baseline device), electronic device 10 may include multiple transmitters, multiple receivers, multiple transceivers, and / or multiple antennas suitable for various communication standards.

[0045] Transmitter 52 may wirelessly transmit packets having different packet types or functions. For example, transmitter 52 may transmit different types of packets generated by processor 12. Receiver 54 may wirelessly receive packets having different packet types. In some examples, receiver 54 may detect the type of packet used and process the packet accordingly. In some embodiments, transmitter 52 and receiver 54 may transmit and receive information via other wired or cable systems or devices.

[0046] As shown in the figure, various components of the electronic device 10 can be coupled together through a bus system 56. The bus system 56 can include, for example, a data bus and power buses, control signal buses, and status signal buses in addition to the data bus. The components of the electronic device 10 can be coupled together or use some other mechanism to accept or provide inputs to each other.

[0047] As described above, a RedCap device can include a reduced number (e.g., one, two) of receiver (RX) chains or branches, including one antenna 55 and one receiver 54. A RedCap device can be defined based on 3GPP standards, where Rel-17 defines a RedCap device based on the number of RX branches of a full-capability or "baseline" device. According to Rel-17, for bands where a baseline NR device requires at least two RX branches (e.g., FR2, certain bands in FR1), a RedCap device only needs to have one or two RX branches. For bands where a baseline NR device requires at least four RX branches (e.g., certain bands in FR1), a RedCap device needs to have one or two RX branches. Table 1 above provides more details of a RedCap device when compared to a baseline NR device as specified in Rel-17.

[0048] As mentioned herein, a receive chain or branch can refer to a cascade of electronic components and subunits used by and / or including the receiver 54 to receive wireless signals, and the cascade can include amplifiers, filters, mixers, attenuators, etc. Specifically, Figure 3FIG. 0 is a schematic diagram of a receiver 54 (e.g., a receiving circuit) according to an embodiment of the present disclosure. As shown, the receiver 54 may receive received data 58 from an antenna 55 in the form of an analog signal. A low-noise amplifier (LNA) 60 may amplify the received analog signal to a suitable level for processing by the receiver 54. A filter 62 (e.g., a filter circuit and / or software) may remove unwanted noise, such as cross-channel interference, from the received signal. The filter 62 may also remove additional signals received by the antenna 55 that have frequencies different from the desired signal. The filter 62 may include any one or more suitable filters for removing unwanted noise or signals from the received signal, such as a band-pass filter, a band-stop filter, a low-pass filter, a high-pass filter, and / or a decimation filter. A demodulator 64 may remove the radio-frequency envelope and / or extract a demodulated signal from the filtered signal for processing. An analog-to-digital converter (ADC) 66 may receive the demodulated analog signal and convert the signal to a digital signal of incoming data 68 to be further processed by the electronic device 10. Additionally, the receiver 54 may include any suitable additional components not shown, or may not include some of the components shown, such that the receiver 54 may receive the received data 58 via the antenna 55. For example, the receiver 54 may include a mixer and / or a digital downconverter. At least some of the components of the receiver 54 may be referred to as a “receive chain” or a “receive branch”. Similarly, at least some of the components of a transmitter 52 (e.g., a digital-to-analog converter (DAC), a modulator, a power amplifier, a filter, a mixer, a digital upconverter, etc.) may be referred to as a “transmit chain” or a “transmit branch”.

[0049] As previously mentioned, the 3GPP may extend the standard to allow network providers to support RedCap devices. The following systems and methods may be desirable in order to comply with FCC guidelines, which reduce the likelihood that a network provider may deny an emergency service access request from a RedCap device without a preferred configuration. In view of the foregoing, Figure 4 FIG. 5 is an illustration of a wireless communication network 70 supported by base stations 72A, 72B, and user equipment (UE) 74 (e.g., such as the electronic device 10) according to an embodiment of the present disclosure. The base station 72A may provide coverage of the network 70 (e.g., a cellular network) to devices (e.g., including the UE 74) in a geographical area or cell 76A, and the base station 72B may provide coverage of the network 70 to devices in a geographical area or cell 76B.

[0050] Base stations 72A, 72B (collectively referred to as 72) and / or user equipment 74 may have one or more components similar to those of the electronic device 10 and may thus include control circuitry (such as the processor 12), the memory 14, and / or the non-volatile storage device 16, which may operate together to cause the base station 72 and / or the user equipment 74 to perform corresponding operations. Specifically, the processor 12 of the base station 72A and the processor 12 of the base station 72B may perform the operations of the network 70. Note that the user equipment 74 may include any one of various types of computer systems or computing devices that may communicate with the base station 72A or the base station 72B. Examples of the user equipment 74 are any suitable portable electronic device, mobile phone, smartphone, portable gaming device, laptop computer, wearable device, etc. As mentioned herein, the user equipment 74 may include a RedCap device as described above.

[0051] To establish a connection with the network 70, the user equipment 74 may establish a Radio Resource Control (RRC) session with the network 70 via the transmitter 52 and / or the receiver 54 after being accepted by the network 70. The network 70 and the base station (e.g., 72A) may implement any suitable network technology or standard, such as Long Term Evolution (LTE) or 4th Generation (4G) cellular network via an eNodeB (eNB) base station, New Radio (NR) or 5th Generation (5G) cellular network via a next-generation node B (gNB) base station, etc.

[0052] The network 70 may generate a schedule, including time periods for performing uplink (UL) and downlink (DL) operations. In some embodiments, the base station 72A may then instruct the user equipment 74 to configure its transmitter 52 and / or receiver 54 according to the schedule. It should be understood that uplink data or signals refer to the transmission from the transmitter 52 of the user equipment 74 to the base station 72A of the network 70, and downlink data or signals refer to the transmission from the base station 72A of the network 70 to the receiver 54 of the user equipment 74.

[0053] As described above, the user equipment 74 can be accepted by the network 70. However, the network 70 can alternatively reject the user equipment 74 (e.g., when the user equipment operates according to a configuration that is incompatible or not preferred by the network 70A). For example, the network 70A can have frequency communication preferences, RX branch preferences, geospatial preferences, etc., and based on these preferences, the network 70A accepts, rejects the user equipment 74 or hands over the user equipment to another network 70. However, FCC guidelines can limit when the network 70A can reject requests from the user equipment 74, such as by prohibiting the rejection of emergency service access requests from RedCap devices. While complying with 3GPP standards and FCC guidelines, including a first indication of whether an emergency service access is requested and a second indication of the number of RX branches in a message from the user equipment 74 can provide the network 70A with an appropriate amount of information for accepting or rejecting the user equipment 74.

[0054] Additionally, the user equipment 74 can sometimes move or will move from a first coverage area (e.g., 76A) supported by a first base station (e.g., 72A) to a second coverage area (e.g., 76B) supported by a second base station (e.g., 72B). Thus, the first base station 72A can attempt to hand over the network coverage of the user equipment 74 to the second base station 72B so that the user equipment 74 can have continuous and uninterrupted access to the network 70. Such handover events can occur when the user equipment 74 moves between the cells 76 of the respective base stations 72, when overload on one base station (e.g., 72A) triggers offloading of the user equipment 74 to another base station (e.g., 72B), etc. If the first base station 72A can provide emergency services to the user equipment 74, the first base station 72A can confirm that the second base station 72B can also provide emergency services to the user equipment 74. Specifically, when performing the handover procedure, the first base station 72A can receive a system information block (SIB) from the second base station 72B, and this system information block can indicate whether the second base station 72B supports emergency services (e.g., the ims-EmergencySupport message). The first base station 72A can hand over the user equipment 74 to the second base station 72B only when the second base station 72B supports emergency services, thereby ensuring that the user equipment 74 may not be disconnected from the network 70 due to having an insufficient number of RX branches and ensuring that the communication of the user equipment 74 receives higher priority due to their emergency nature.

[0055] To elaborate on the above-described improved request handling operations, FIG. 5 is a flowchart of a method 78 according to an embodiment of the present disclosure for providing an indication of the number of RX branches of user equipment 74 and an indication of an emergency in a random access preamble and for preventing a base station (e.g., 72A) from disconnecting the user equipment when the user equipment 74 connects for emergency purposes. Any suitable device (e.g., a controller) that can control components of the user equipment 74, the base station 74A, and / or the network 70 (such as the processor 12 in each of these devices or systems) can execute the method 78. In some embodiments, the method 78 can be implemented by using the processor 12 to execute instructions stored in a tangible non-transitory computer-readable medium such as the memory 14 or the storage device 16. For example, the method 78 can be executed at least in part by one or more software components of the user equipment 74, the base station 72A, and / or the base station 72B and / or the network 70 such as an operating system, one or more software applications, etc. In this way, the method 78 is described with respect to the user equipment 74 communicating with the base station 72A. However, it should be understood that these methods are applicable to any suitable user equipment or electronic device 10 communicating with any suitable base station 72. Although the method 78 is described using steps in a particular order, it should be understood that the present disclosure contemplates that the described steps can be executed in an order different from the shown order and that certain described steps can be skipped or not executed at all. Note that each transmit or receive operation described herein can involve encoding and / or decoding, such as to wirelessly transmit data more efficiently, and thus the operations are generally referred to in FIGS. 5- Figure 8 The description of these operations is omitted.

[0056] At block 80, the user equipment 74 transmits a request for a system information block message (SIB) to the base station 72A, and at block 82, the base station 72A receives the SIB request. Specifically, when the user equipment 74 enters the coverage area or cell 76A of the base station 72A, the user equipment 74 can detect the base station 72A by receiving a radio frequency (RF) signal. The RF signal can include timing alignment information and other information. Before requesting the SIB, the user equipment 74 can synchronize with the base station 72A by aligning its timing with the timing alignment information of the base station 72A. The transmission of the request for the SIB can be completed in response to a user input interacting with a control feature of the user equipment 74, such as a graphical or physical button (e.g., an emergency button, a call button) on the display 18 and / or the touch screen, which when pressed causes the user equipment 74 to make an emergency call and thus trigger the operations of FIGS. 5 and 6. Thus, the user equipment 74 can present an image of a button that can trigger the processor 12 to generate a random access preamble in response to the user input.

[0057] At block 84, base station 72A transmits the SIB to user equipment 74, and at block 86, user equipment 74 receives the SIB. The SIB may include system information indicating a frequency sub-range supported by base station 72A. The SIB may also indicate whether base station 72A is capable of handling or disposing of emergency service access requests, such as whether base station 72A prohibits certain frequency ranges or types of communication requests, whether base station 72A has the authority or access to emergency service frequencies, or whether base station 72A is capable of handling emergency service access requests urgently relative to normal non-emergency access requests. The system information conveyed in the SIB may additionally include timing specifications, power specifications, Global Positioning System (GPS) coordinates, and / or any other available information. In some embodiments, user equipment 74 may store the system information in memory 14 for future use.

[0058] At block 88, user equipment 74 may transmit a random access preamble (MSG1) having an indication of the number of RX branches and an indication of an emergency, such as an indication of an emergency establishment cause, an mps-PriorityAccess establishment cause, and / or an indication of an mcs-PriorityAccess establishment cause (e.g., as defined in 3GPP Technical Specification 38.331 (TS38.331)). The indication of the emergency may indicate to base station 72A that the request is for urgent or prioritized service fulfillment, and thus may itself be considered an indication of urgent service fulfillment or an indication of a state corresponding to an urgent service fulfillment operation. After determining to communicate with user equipment 74, base station 72A may prioritize the transmission of emergency-related or high-urgency requests relative to normal requests, less urgent requests, or non-emergency requests by fulfilling the communication related to the indication of the emergency in the queue in advance, using a dedicated frequency range, increasing the channel throughput or bandwidth, reducing the traffic on the channel with user equipment 74, etc. Note that the random access preamble (MSG1), UL scheduling information (MSG2) message, RRCSetupRequest (MSG3) message, and RRCSetup (MSG4) message may correspond to messages transmitted during a contention-based random access procedure; the RRCSetupRequest (MSG3), RRCSetup message (MSG4), and RRCSetupComplete (MSG5) messages may correspond to messages used as an RRC connection establishment procedure; and the UECapabilityInformation (MSG7) may correspond to a UE capability transfer procedure, as may be appreciated.

[0059] At block 90, base station 72A may receive a random access preamble (MSG1) from user equipment 74. The indication of an emergency situation may include a flag, additional data, a signal, etc. included in the message (in this case, the random access preamble (MSG1)) to indicate that the connection request has an emergency or relatively high urgency establishment reason. Different message types or signals may be used to indicate the emergency nature or urgency of the request. In the random access preamble (MSG1), user equipment 74 may transmit a request for specific resources from base station 72A to convey the first indication and the second indication to base station 72A over network 70. Thus, the random access preamble (MSG1) includes in the message a request for the random access preamble, a first indication of whether an emergency service access is requested, and a second indication of the number of RX branches, where the number of RX branches may be equal to the number of antennas in user equipment 74 (e.g., RedCap electronic device 10). The random access preamble (MSG1) may be considered an early warning or early indication of the desired configuration requested by user equipment 74. Base station 72A may receive the early notification because the first indication indicates whether the scheduled communication from user equipment 74 before full communication establishment with network 70A is an emergency service access request.

[0060] After receiving a random access preamble (MSG1), base station 72A determines the compatibility between the request, network 70 preferences, and / or network 70 conditions. To elaborate, at block 92, base station 72A determines whether an indication transmitted with the random access preamble (MSG1) indicates that the user equipment 74 has a reduced number of RX branches (e.g., 1 RX branch reduction for a RedCap NR device compared to 2 or 4 RX branches of a baseline NR device). Base station 72A may compare the number of RX branches indicated by user equipment 74 with a threshold number of RX branches (e.g., corresponding to the non-reduced number of RX branches of a baseline NR device). When base station 72A determines that user equipment 74 has a reduced number of RX branches (e.g., the number of RX branches is less than or equal to the threshold number of RX branches), base station 72A may delay rejecting any access to user equipment 74 and proceed to block 94. When base station 72A determines that user equipment 74 does not have a reduced number of RX branches, base station 72A may continue to perform default operations, such as determining at block 96 whether it is desired to end the connection with user equipment 74. This may include base station 72A determining whether user equipment 74 is requesting via random access preamble (MSG1) communication that meets the communication preferences of base station 72A. When base station 72A determines to maintain the connection with user equipment 74, at block 98, base station 72A may continue to perform operations to continue establishing a connection with user equipment 74. However, when base station 72A determines to end the connection, at block 100, base station 72A may end the connection. For example, base station 72A may reject user equipment 74 or hand over the user equipment to another base station 72 or frequency layer compatible with the random access preamble (MSG1). Base station 72A may reject user equipment 74 by transmitting an RRCReject message.

[0061] As described above, after base station 72A determines that user equipment 74 indicates a reduced number of RX branches, base station 72A proceeds to determine at block 94 whether the random access preamble (MSG1) indicates the cause of the connection request establishment as an emergency or relatively high urgency. The random access preamble (MSG1) may include an indication of an emergency. When no emergency is indicated, at block 96, base station 72A proceeds to determine whether it is desired to end the connection with user equipment 74. However, when an emergency is indicated, base station 72A may be prohibited from rejecting the request of user equipment 74 and the request is to be fulfilled. Accordingly, base station 72A may proceed to block 98 to prepare for communication with user equipment 74 via network 70A.

[0062] At block 98, base station 72A responds to the random access preamble message transmitted by user equipment 74 with UL scheduling information (MSG2), and at block 102, user equipment receives the UL scheduling information (MSG2). By doing so, base station 72A determines to accept the request from user equipment 74 and may configure its resources according to the settings provided by user equipment 74 in the random access preamble message. For example, base station 72A may configure one or more resources according to the frequency sub-ranges supported by user equipment 74 and base station 72A. Once the resources are configured and a connection is established between user equipment 74 and base station 72A, base station 72A responds with the UL scheduling information (MSG2). The UL scheduling information (MSG2) may include a random access response message and the duration or communication interval that user equipment 74 is to observe when transmitting data to base station 72A and network 70. If user equipment 74 has downlink (DL) capabilities, the same or a separate message from base station 72A may include DL scheduling information for defining the duration or communication interval that user equipment 74 is to observe when receiving data from base station 72A and network 70.

[0063] At block 104, user equipment 74 reads the UL scheduling information (MSG2) and transmits an RRCSetupRequest (MSG3) to base station 72A, and at block 106, base station 72A receives the RRCSetupRequest (MSG3). The RRCSetupRequest (MSG3) may confirm to base station 72A the receipt of the UL scheduling information (MSG2). The RRCSetupRequest (MSG3) may also include an indication of any timing adjustment made by user equipment 74 to the proposed communication interval from the UL scheduling information (MSG2).

[0064] At block 108, after receiving the RRCSetupRequest (MSG3) from user equipment 74, base station 72A transmits a contention resolution message with an RRCSetup message (MSG4), and the user equipment receives the RRCSetup message (MSG4) at block 110. The contention resolution message may indicate to user equipment 74 that base station 72A accepts the timing adjustment requested in the RRCSetupRequest (MSG3).

[0065] At block 112, user equipment 74 may transmit an RRCSetupComplete (MSG5) message after preparing the transceiver 30 to communicate according to the communication interval indicated in the RRCSetupRequest (MSG3) and / or UL scheduling information (MSG2). At block 114, base station 72A may receive the RRCSetupComplete (MSG5). The RRCSetupComplete (MSG5) message indicates to base station 72A that user equipment 74 is ready to communicate on network 70a. In response to the exchange of the RRCSetupComplete (MSG5) message, at block 116, base station 72A may initiate and perform one or more access stratum security activation operations. These operations may be used by the network-provided or spectrum access entity to authenticate user equipment 74, the communication between base station 72A and / or network 70. The access stratum security activation operations may involve base station 72A confirming communication with user equipment 74 through network 70 such as a spectrum access entity by, for example, confirming a user account, a hardware identifier (ID), a subscriber identity module (SIM) card, etc.

[0066] Upon confirmation of the RRCSetupComplete message (MSG5) and completion of the activation operation at block 116, at block 118, base station 72A may transmit a UECapabilityEnquiry (MSG6) message received at block 120 to user equipment 74. The UECapabilityEnquiry (MSG6) message requests additional configuration information from user equipment 74 and confirms permission for base station 72A to communicate with user equipment 74. In response to the UECapabilityEnquiry (MSG6) message, at block 122, user equipment 74 transmits a message including UECapabilityInformation (MSG7) to provide the requested additional configuration information received at block 124 to base station 72A. After base station 72A receives the message including UECapabilityInformation (MSG7), base station 72A continues to fulfill the request of user equipment 74 and communicates with user equipment 74 at block 126. In this way, method 78 may enable user equipment 74 to provide an indication of the number of its RX branches and an indication of an emergency in a random access preamble, and prevent base station 72A from disconnecting the user equipment when user equipment 74 connects for emergency purposes, even when user equipment 74 is a RedCap device with a reduced number (e.g., only one) of RX branches.

[0067] In view of the foregoing, FIG. 6 is a flowchart of method 132 according to an embodiment of the present disclosure, which modifies method 78 of FIG. 5 to include the first indication and the second indication in different messages during the setup operation. In fact, FIG. 6 is a flowchart of method 132 according to an embodiment of the present disclosure, which is used to provide an indication of the number of RX branches of user equipment 74 in a random access preamble (MSG1) and an indication of an emergency situation in an RRCSetupRequest (MSG3), and prevent Figure 4 a base station (e.g., 72A) from disconnecting user equipment 74 when the user equipment 74 connects for emergency purposes. Any suitable device (e.g., a controller) that can control components of user equipment 74, base station 74A, and / or network 70 (such as the processor 12 in each of these devices or systems) can execute method 132. In some embodiments, method 132 can be implemented by executing instructions stored in a tangible non-transitory computer-readable medium such as memory 14 or storage device 16 using processor 12. For example, method 132 can be executed at least in part by one or more software components of user equipment 74, base station 72A, and / or network 70 such as an operating system, one or more software applications, etc. In this way, method 132 is described with respect to user equipment 74 communicating with base station 72A. However, it should be understood that these methods are applicable to any suitable user equipment or electronic device 10 communicating with any suitable base station 72. Although method 132 is described using steps in a particular order, it should be understood that the present disclosure contemplates that the described steps can be executed in an order different from the shown order, and certain described steps can be skipped or not executed at all. In addition, certain operations of method 78 are similarly performed for method 132, and thus those descriptions apply here.

[0068] Execute blocks 80 - 84 as described in method 78 of FIG. 5. At block 134, in response to receiving the SIB, user equipment 74 may transmit a random access preamble (MSG1), which includes information similar to the random access preamble (MSG1) of block 84 of method 78, but does not include a first indication of whether an emergency service access is requested. At block 90, base station 72A may receive the random access preamble (MSG1), and at block 92, base station 72A may determine whether a reduced number of RX branches is indicated in the random access preamble (MSG1), similar to the operation of method 78. If, at block 96, it is desired to end the connection with user equipment 74, then at block 100, base station 72A may end the connection. However, if, at block 96, it is not desired to end the connection with user equipment 74, and user equipment 74 has a full or non - reduced number of RX branches (e.g., user equipment 74 is a non - RedCap or baseline device), or if user equipment 74 has a reduced number of RX branches (e.g., user equipment 74 is a RedCap device) and thus should not prematurely reject the connection before learning of the emergency situation, then base station 72A may proceed to block 98. At block 98, base station 72A may transmit UL scheduling information (MSG2), similar to method 78 of FIG. 5. In response to receiving the UL scheduling information (MSG2) at block 102, at block 136, user equipment may transmit an RRCSetupRequest (MSG3) message with an indication that the request is for an access service request for emergency service to base station 72A, which receives the MSG3 at block 106. In response to the RRCSetupRequest (MSG3), at block 94, base station 72A may determine whether user equipment 74 indicates an emergency situation (e.g., indicates a request associated with a request for emergency service access). In method 78, base station 72A refers to the random access preamble (MSG1) to indicate an emergency situation. However, in method 132, base station 72A refers to the RRCSetupRequest (MSG3) to indicate an emergency situation. In fact, method 132 shows an example of a situation where it may be desirable or necessary to transmit an indication of an emergency situation separately from an indication of the number of RX branches.

[0069] When an emergency is indicated, at block 108, base station 92A may fulfill the request of user equipment 74 and continue by transmitting a contention resolution response via the RRCSetup Message (MSG4) described earlier with method 78. However, when an emergency is not indicated, base station 72A may choose to deny access of user equipment 74 to network 70A and / or hand over user equipment 74 to another network 70. Accordingly, base station 72A repeats the operation of block 96 at block 138 to determine whether to end the connection with user equipment 74. When desired, at block 100, base station 72A may end the connection with user equipment 74 by handing over user equipment 74 or timing out the request of user equipment 74 without a response. When it is not desired to end the connection, method 132 continues to block 108, where base station 72A may continue operations to maintain the connection with user equipment 74. The description of blocks 108 - 126 of method 78 from FIG. 5 applies here and is thus skipped. In this manner, method 132 may enable user equipment 74 to provide an indication of the number of RX branches of user equipment 74 in the random access preamble (MSG1) and an indication of an emergency in the RRCSetupRequest (MSG3), and prevent base station 72A from prematurely disconnecting the user equipment when user equipment 74 is connecting for emergency purposes.

[0070] During active communication, base station 72A may determine to hand over user equipment 74 to another base station (e.g., 72B). To elaborate, Figure 7 is a flowchart of method 150 according to an embodiment of the present disclosure for ensuring that user equipment (e.g., 74) connecting for emergency purposes is handed over to a base station (e.g., 72B) that can support the emergency. Any suitable device (e.g., a controller) that can control user equipment 74, base station 74A, and components of the terrestrial network (such as processors 12 of each of these devices or systems) may execute method 150. In some embodiments, method 150 may be implemented by executing instructions stored in a tangible non - transitory computer - readable medium such as memory 14 or storage device 16 using processor 12. For example, method 150 may be executed at least in part by one or more software components of user equipment 74, base station 72A, and / or base station 72B and the terrestrial network, such as an operating system, one or more software applications, etc. In this manner, method 150 is described with respect to user equipment 74 communicating with base station 72A. However, it should be understood that these methods are applicable to any suitable user equipment or electronic device 10 communicating with any suitable base station 72. Although method 150 is described using steps in a particular order, it should be understood that the present disclosure contemplates that the described steps may be executed in an order different from the shown order and that certain described steps may be skipped or not executed at all.

[0071] At block 126, user equipment 74 and base station 72A may communicate actively (e.g., as described in FIGS. 5 and / or 6). During active communication, base station 72A may receive an indication or determine to handover user equipment 74 at block 154. For example, it may be desirable to perform a handover when user equipment 74 is outside the coverage area (76A) or when network conditions such as load or current demand change.

[0072] At block 160, base station 72A may determine whether user equipment 74 indicates an emergency or whether user equipment 74 is communicating to receive emergency support. When not indicated, at block 162, base station 72A may handover the connection to a target base station (e.g., 72B). However, when an emergency is indicated, base station 72A may not handover user equipment 74 until it confirms that the target base station (e.g., 72B) supports emergency services. Thus, at block 164, base station 72A may determine whether target base station 72B indicates that it can support emergency-related or high-urgency requests in its SIB. To determine this, base station 72A may request and receive the SIB from target base station 72B and determine whether the SIB includes data, markers, indications, etc. to convey its ability to handle emergency situations, high-urgency or high-priority requests. This indication may be the ims-EmergencySupport data field.

[0073] When target base station 72B does not handle emergency requests, at block 158, base station 72A may maintain the connection with user equipment 74. However, when target base station 72B does handle emergency requests, at block 166, base station 72A may handover user equipment 74 to target base station 72B. Base station 72A may transmit an indication of the emergency request to target base station 72B when handing over user equipment 74 so that the indication of the emergency situation is not lost during the handover. After the handover, target base station 72B satisfies the connection request of user equipment 74, even though it is a new random access preamble (MSG1). Once fulfilled, user equipment 74 may receive an acknowledgment message from base station 72B. The acknowledgment message may trigger user equipment 74 to communicate on the network 70B of base station 72B and / or perform some of the operations in FIGS. 5 and 6 to verify the connection with base station 72B. Thus, method 150 may ensure that user equipment 74 connected for emergency purposes is handed over to a base station (e.g., 72B) that can support emergency situations.

[0074] In some cases, a network provider may wish to prohibit RedCap devices from accessing a certain frequency layer. The network provider may indicate such a prohibition in the SIB of one or more corresponding base stations 72. However, Figure 8 A method is provided to override this preference when a RedCap device makes an emergency call or request, which may prevent base station 72A from rejecting a request for connection for emergency purposes. In fact, Figure 8FIG. 0 is a flowchart of a method 188 according to an embodiment of the present disclosure for enabling user equipment 74, even a RedCap device, to operate on a non-preferred or prohibited frequency layer for emergency purposes. Any suitable device (e.g., a controller) that can control components of the user equipment 74, the base station 74A, and the network 70, such as the processor 12 in each of these devices or systems, can execute the method 188. In some embodiments, the method 188 can be implemented by executing instructions stored in a tangible non-transitory computer-readable medium such as the memory 14 or the storage device 16 using the processor 12. For example, the method 188 can be executed at least in part by one or more software components of the user equipment 74, the base station 72A, and / or the base station 72B and / or the network 70, such as an operating system, one or more software applications, etc. In this way, the method 188 is described with respect to the user equipment 74 communicating with the base station 72A. However, it should be understood that these methods are applicable to any suitable user equipment or electronic device 10 communicating with any suitable base station 72. Although the method 188 is described using steps in a particular order, it should be understood that the present disclosure contemplates that the described steps can be executed in an order different from the shown order, and certain described steps can be skipped or not executed at all.

[0075] At block 190, the base station 72A can receive an indication to establish communication over a desired frequency range from the user equipment 74. The indication can be part of an ongoing communication between the base station 72A and the user equipment 74. The desired frequency range can correspond to the frequency range used by the antenna 55 of the user equipment 74 (e.g., a RedCap device) to transmit or receive wireless signals. The desired frequency range of a RedCap device can be defined by 3GPP standards in RP-210918 as those frequency ranges in the NR FR1 and / or FR2 bands (e.g., as shown in Table 1 above). In some embodiments, the user equipment 74 can transmit a request in response to being disconnected from its preferred frequency layer but having discovered or determined that another frequency layer is not allowed for a RedCap device with respect to the base station 72A. For example, the user equipment 74 can transmit a request in response to being redirected to a certain frequency layer (e.g., due to load balancing). The user equipment 74 can also or alternatively transmit a request in response to being operated in a limited service mode, where the user equipment 74 may have discovered another cell 76 from the same or a different network 70 through which a connection can potentially be established.

[0076] At block 192, base station 72A may determine whether the desired frequency range of user equipment 74 is within the preferred frequency range of base station 72A and / or network 70. To do so, base station 72A may access its memory 14 or storage device 16 to access stored indications of the communication preferences of network 70 that base station 72A is to comply with. Base station 72A may compare the stored indications with the desired frequency range indicated by user equipment 74 to determine whether the desired frequency range of user equipment 74 is compatible with the stored indications corresponding to the preferences of network 70A.

[0077] When the desired frequency range falls within the frequency range preferences of network 70, at block 194, base station 72A may establish communication with user equipment 74 over the desired frequency range. To do so, base station 72A may follow some of the operations in the operation of FIG. 5- Figure 7 (e.g., at least blocks 98-126 of FIG. 5). However, when the desired frequency range falls outside the frequency range preferences of network 70A, then at block 196, base station 72A may determine whether an indication of an emergency situation is received from user equipment 74 (e.g., as part of a random access preamble (MSG1), RRCSetupRequest (MSG3), RRCResumeRequest, UECapabilityInformation (mMSG7), etc.). If an indication of an emergency situation has been received, then base station 72A continues to fulfill the request from user equipment 74 regardless of its frequency range preferences (e.g., as long as it is able to fulfill the request). And thus, the operation of method 188 continues at block 194, where base station 72A establishes communication with user equipment 74 over the desired frequency range of user equipment 74. If an indication of an emergency situation has not been received, then at block 198, base station 72A may determine to redirect the request of user equipment 74 to its preferred frequency range (e.g., if user equipment 74 is capable of communicating using the preferred frequency range). Alternatively, base station 72A may hand over the request of user equipment 74 to another base station (e.g., 72B) that prefers to communicate using the desired frequency range of user equipment 74.

[0078] In any of these cases, the RedCap user equipment 74 may end up on a frequency layer that is not permitted for RedCap devices. These prohibited rules regarding the frequency layer can organize network requirements and help to silo user equipment 74 with a varying number of RX branches onto different frequency layers. For example, when the user equipment 74 loses its preferred frequency layer and cannot find another frequency layer that is permitted for its multiple RX branches, the user equipment 74 may request to connect to a frequency layer that is not permitted for its multiple RX branches (e.g., the RedCap device attempts to connect to a frequency range designated for a device with 2 RX branches). Alternatively, the user equipment 74 may request to connect to a frequency layer that is not permitted for its multiple RX branches when redirected to a different frequency layer by the base station 72A, such as due to a load balancing operation. In addition, the user equipment 74 may land on a frequency layer that is not permitted for its multiple RX branches when operating in a limited service mode and when it attempts to connect to an incompatible base station 72. For example, the RedCap user equipment 74 may request a connection to a cell 76 that does not support RedCap devices, but may still attempt to establish its emergency-related communication with the base station 72 corresponding to the cell 76.

[0079] If the user equipment 74 continues to attempt an emergency service access request for a prohibited frequency layer, the base station 72 may override the prohibition on the frequency layer and use the frequency layer to fulfill the emergency service access request. As Figure 8 shown in block 198 of, if the user equipment 74 is not attempting an emergency service access request, the user equipment 74 remains prohibited from accessing the frequency layer. This can be done in TS38.300 by defining that a RedCap user device initiating an emergency call or transmitting an emergency service access request may ignore the prohibited rules for the frequency layer, or in TS38.304 by defining that the RedCap user equipment 74 may select any cell 76 as an illustration or annotation when making an emergency call or emergency request. In addition, TS38.331 may define additional procedures to clarify that the user equipment 74 may ignore the cell 76 prohibition once it transmits an emergency service access request (e.g., initiates an emergency call).

[0080] Note that, as described above, the base station 72A receives or transfers requests from the user equipment 74. However, it should also be noted that when the base station 72A determines that a request from the user equipment 74 is incompatible with its preferred operation or operational configuration, the base station 72A may deny access to the user equipment 74, provided that the request is not for an emergency service. The base station 72A may deny access in several different ways. For example, at block 86, the base station 72A may deny access by not transmitting UL scheduling information (MSG2). In this way, when receiving and decoding the extended MSG1, the network may ignore the random access request from the user equipment 74 and not transmit a random access response (MSG2), thereby causing the user equipment 74 to time out and attempt to access another cell 76. Additionally or alternatively, the base station 72A may deny the request by sending an RRCReject message in its contention resolution response MSG4 when receiving and decoding the extended MSG3 RRCSetupRequest. Further, the base station 72A may also reject the message after receiving and decoding the UE Capability Information message. In fact, the base station 72A may decide to release or suspend the RRC connection using an RRCRelease message, thereby causing the user equipment 74 to enter the idle state and initiate a cell selection procedure.

[0081] Some of the described operations may apply to different received messages. In this way, a first electronic device may follow the operation of the base station 72A of FIG. 5, while a second electronic device follows the operation of the base station 72A of FIG. 6. The same applies to the operations of FIGS. 5 - Figure 8 6. Additionally, the electronic device may operate to communicate with the base station according to the operation for a first request of FIG. 5 and according to the operation for a later request of FIG. 6, and vice versa. In this way, the transceiver 30 may receive a subsequent connection request for establishing communication from another electronic device 10. In response to receiving the subsequent connection request, the base station 72 may determine that the subsequent connection request does not correspond to an urgent service fulfillment (e.g., an emergency request), and may redirect the subsequent connection request to the desired frequency range used by the transceiver 30, even if the ongoing or previous communication from the electronic device 10 or a different electronic device 10 is for or not for an urgent service fulfillment.

[0082] The technical effects of the present disclosure include reducing or eliminating the likelihood of a base station rejecting a request from a user equipment before considering whether the request from the user equipment is for emergency service access based on the number of RX branches used by the user equipment. Several systems and methods can improve the handling of emergency requests from user equipment by the base station. In one case, the user equipment can transmit a first indication and a second indication using a random access preamble (MSG1). In another case, the user equipment can transmit the first indication using RRCSetupRequest (MSG3) and transmit the second indication using a random access preamble (MSG1). In a third case, the base station can transmit the first indication to the target base station when handing over a user equipment requesting emergency access so as not to lose the first indication when transferring the user equipment. And, in a fourth case, even when a request is made to a less desirable or prohibited frequency layer of the base station's network, the base station can fulfill the emergency request of the user equipment. By operating in any of these ways, the base station completely prevents the possibility that a request for network access to emergency services from the user equipment is prematurely rejected, thereby improving network operation.

[0083] The above specific embodiments have been shown by way of example, and it should be understood that these embodiments are susceptible to various modifications and alternative forms. It should also be understood that the claims are not intended to be limited to the specific forms disclosed, but are intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure.

[0084] The technologies described herein and claimed are cited and applied to specific examples of a physical and practical nature, which significantly improve the art, and are thus not abstract, intangible, or purely theoretical. Additionally, if any claim appended to the end of this specification includes one or more elements designated as "means for [performing][function]..." or "steps for [performing][function]...", those elements will be construed in accordance with 35 U.S.C. 112(f). However, for any claim that includes elements designated in any other way, those elements will not be construed in accordance with 35 U.S.C. 112(f).

[0085] It is well known that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of inadvertent or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

Claims

1. A method for communication, comprising: Receiving a connection request from a user equipment, the connection request including a random access preamble, the random access preamble including a first indication of the number of receiving branches associated with the user equipment; Receiving from the user equipment a second indication indicating that the connection request is associated with an emergency situation, the second indication being appended as one or more bits to the random access preamble; Determining to fulfill the connection request based on the first indication and the second indication; And Transmitting a contention resolution response based on determining to fulfill the connection request.

2. The method according to claim 1, comprising: Determining that the first indication indicates one receiving branch based on receiving the connection request; And Transmitting scheduling information to the user equipment based on determining that the first indication indicates the one receiving branch and receiving the second indication indicating that the connection request is associated with the emergency situation.

3. The method according to claim 1, comprising: Determining that the first indication indicates one receiving branch based on receiving the connection request; Transmitting scheduling information to the user equipment based on determining that the first indication indicates the one receiving branch; Receiving a setup request including the second indication based on transmitting the scheduling information to the user equipment; Determining that the connection request of the second indication is associated with the emergency situation based on receiving the second indication; And Generating the contention resolution response to fulfill the connection request based on determining that the connection request of the second indication is associated with the emergency situation.

4. The method according to claim 1, wherein the connection request is associated with a connection to the user equipment using a frequency between 0.41 gigahertz (GHz) and 7.125 GHz.

5. The method according to claim 1, comprising: Determining to hand over the user equipment to a target base station; Determining that the connection request is associated with the emergency situation based on the second indication and determining to hand over the user equipment; Determining that the target base station supports emergency services based on determining that the connection request is associated with the emergency situation; And Handing over the user equipment to the target base station based on determining that the target base station supports the emergency services.

6. The method according to claim 1, comprising: Determining to hand over the user equipment to a target base station; Determining that the connection request of the second indication is associated with the emergency situation based on determining to hand over the user equipment; Determining that the target base station does not support emergency services based on determining that the connection request of the second indication is associated with the emergency situation; And Continuing the connection with the user equipment based on determining that the target base station does not support the emergency services.

7. The method according to claim 1, wherein the connection request is associated with a connection to the user equipment using a frequency between 24.25 gigahertz (GHz) and 52.6 GHz.

8. A user equipment with reduced capabilities, comprising: One or more antennas; Transmitting branches, the transmitting branches being coupled to the one or more antennas; Only one receiving branch, the only one receiving branch being coupled to the one or more antennas; And Processing circuitry configured to: Transmit a connection request to a base station using the transmitting branch, the connection request including a random access preamble, the random access preamble including one or more additional bits of a first indication of the only one receiving branch and a second indication of a request for access to an emergency service, and Receive a contention resolution response from the base station using the only one receiving branch to establish a connection with the base station based on the base station accepting the request for access to the emergency service.

9. The user equipment with reduced capabilities according to claim 8, wherein the transmitting branch is configured to transmit a wireless signal to the base station using the connection, or the only one receiving branch is configured to receive a wireless signal from the base station using the connection at a frequency between 0.41 gigahertz (GHz) and 7.125 GHz.

10. The user equipment with reduced capabilities according to claim 8, wherein the transmitting branch is configured to transmit a wireless signal to the base station using the connection, or the only one receiving branch is configured to receive a wireless signal from the base station using the connection at a frequency between 24.25 gigahertz (GHz) and 52.6 GHz.

11. A base station comprising: A transceiver; And Processing circuitry configured to: Receive, via the transceiver, a connection request from an electronic device to establish communication through a desired frequency range used by the transceiver, Determine that the desired frequency range indicated in the connection request is outside a first frequency range, Determine that the connection request corresponds to urgent service fulfillment based on determining that the desired frequency range is outside the first frequency range, and Establish communication with the electronic device through the desired frequency range based on determining that the connection request corresponds to the urgent service fulfillment.

12. The base station according to claim 11, comprising a memory configured to store an indication of the first frequency range of the transceiver, the first frequency range of the transceiver corresponding to the frequency range assigned to the transceiver by a network provider.

13. The base station according to claim 11, wherein the first frequency range is associated with an electronic device having a reduced number of receiving branches.

14. The base station according to claim 13, wherein the processing circuitry is configured to determine that the connection request corresponds to the urgent service fulfillment based on an indication transmitted with the connection request, the connection request including a random access preamble.

15. The base station according to claim 13, wherein the processing circuitry is configured to determine that the connection request corresponds to the urgent service fulfillment based on an indication received from the electronic device after transmitting scheduling information to the electronic device as part of a request to establish a radio resource control connection.

16. The base station according to claim 11, wherein the processing circuitry is configured to: Receive a subsequent connection request to establish communication from another electronic device via the transceiver, determine that the subsequent connection request does not correspond to the urgent service fulfillment based on receiving the subsequent connection request, and Redirect the subsequent connection request to use the desired frequency range used by the transceiver.

17. The base station according to claim 11, wherein the urgent service fulfillment includes an indication of: an emergency establishment reason, a multimedia priority service establishment reason, a mission-critical service establishment reason, or any combination thereof.

18. The base station according to claim 11, wherein the indication of the urgent service fulfillment is appended to the connection request in response to receiving a selection input by an input device, a touch screen, or both.

19. The base station according to claim 11, wherein the electronic device includes a watch device supporting a cellular network.

20. The base station according to claim 11, wherein the processing circuit is configured to: Determine to hand over the electronic device to an additional base station, After determining to hand over the electronic device to another base station, determine that the additional base station is configured to support the urgent service fulfillment, and Based on determining that the additional base station is configured to support the urgent service fulfillment, hand over the electronic device to the additional base station.

Images