Exit conditions and beam-based mobility state estimation for conditional handover
By introducing mobility state estimation threshold and counter into user equipment, combining beam switching and number of sending and receiving point switching, the mobility state is dynamically determined, which solves the problem of handover failure in the prior art and achieves higher handover Performance and communication stability.
Patent Information
- Application Number
- CN202210638503.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2017-03-03
- Filing Date
- 2018-02-22
- Publication Date
- 2025-02-11
- Estimated Expiration
- 2038-02-22
AI Technical Summary
In the process of conditional handover, it is difficult to effectively deal with the situation where the user equipment does not meet the handover conditions during the movement process, resulting in handover failure.
By introducing a mobility state estimation (MSE) threshold and mobility counter into the user equipment, the mobility state of the user equipment is dynamically determined by combining the number of beam switching and the number of sending and receiving point switching, thereby optimizing the conditions and processes of handover.
Improve the failure performance of handover, reduce unnecessary handover operations, and improve the communication stability of mobile devices in a fast mobile environment.
Smart Images

Figure CN114900867B_ABST
Abstract
Description
[0001] Division Statement
[0002] This application is a divisional application of the Chinese invention patent application with the application date of February 22, 2018, the invention name of "Exit conditions and beam-based mobility state estimation for conditional handover", and the application number: 201880013609.9.
[0003] Related Applications
[0004] This application claims priority under 35 U.S.C. §119 to U.S. Provisional Application No. 62 / 463,894, filed on February 27, 2017, and U.S. Provisional Application No. 62 / 466,873, filed on March 3, 2017, the contents of each of which are incorporated herein by reference in their entirety. Technical Field
[0005] Various embodiments of the present application relate generally to the field of wireless communications, and more particularly, to conditional handover and mobility state estimation. Background Art
[0006] Future implementations of the 3rd Generation Partnership Project (3GPP) New Radio (NR) system may support conditional handover to support strict latency requirements and fast-moving user equipment (UE). Conditional handover may involve the UE sending a measurement report to the source cell and then receiving a conditional handover command from the network. The conditional handover command may indicate the conditions for the UE to perform a handover procedure. In this case, the UE must wait until the conditions are met before performing a handover. When compared to the legacy handover procedure, conditional handover may result in better handover failure performance. However, when the handover conditions are not met, for example, when the UE moves close to a cell edge or border and then stops, a handover failure may occur. Summary of the invention
[0007] Some embodiments of the present application provide a user equipment (UE), comprising: a transceiver; and a processing circuit, the processing circuit being communicatively coupled to the transceiver and configured to: identify multiple mobility state estimation (MSE) thresholds from a received configuration message, and determine the mobility state of the UE based on the value of a mobility counter and the multiple MSE thresholds.
[0008] Some embodiments of the present application provide a non-transitory computer-readable medium (CRM), comprising instructions, which, when executed by one or more processors of a user equipment (UE), cause the UE to perform operations, the operations comprising: identifying multiple mobility state estimation (MSE) thresholds from a received configuration message, and determining the mobility state of the UE based on the value of a mobility counter and the multiple MSE thresholds.
[0009] Some embodiments of the present application provide a base station (BS), comprising: a transceiver; and a processing circuit, the processing circuit being communicatively coupled to the transceiver and configured to: determine multiple mobility state estimation (MSE) thresholds; generate a configuration message to indicate the multiple MSE thresholds; and send control signaling including the configuration message to a user equipment (UE). BRIEF DESCRIPTION OF THE DRAWINGS
[0010] The embodiments will be easily understood by the following detailed description in conjunction with the accompanying drawings. For ease of description, the same reference numerals represent the same structural elements. The embodiments are shown in the figures of the accompanying drawings by way of example and not limitation.
[0011] Figure 1A An example system architecture of a network according to various embodiments is shown.
[0012] Figure 1B-1E Various channel quality graphs are shown according to various embodiments.
[0013] Figure 2 Another example system architecture of a network according to various embodiments is shown.
[0014] Figure 3 Examples of infrastructure equipment in accordance with various embodiments are depicted.
[0015] Figure 4 Depicted are example components of a computer platform in accordance with various embodiments.
[0016] Figure 5 Depicted are example components of baseband circuitry and radio frequency circuitry in accordance with various embodiments.
[0017] Figure 6 Depicted are example interfaces of baseband circuitry according to various embodiments.
[0018] Figure 7 Depicted are example components capable of performing any one or more of the methodologies discussed herein according to various example embodiments.
[0019] Figure 8 is a diagram of various protocol functions according to various embodiments.
[0020] Fig. 9 An example conditional handoff procedure is shown in accordance with various embodiments.
[0021] Fig.10 An example conditional handoff (CHO) procedure that may be performed by a user equipment according to various embodiments is shown.
[0022] Fig.11 An example CHO procedure that may be performed by a source radio access network node is shown in accordance with various embodiments.
[0023] Fig.12 An example CHO procedure that may be performed by a target radio access network node according to various embodiments is shown.
[0024] Fig.13 An example mobility state estimation process in accordance with various embodiments is shown. DETAILED DESCRIPTION
[0025] Embodiments discussed herein relate to conditional handover and mobility state estimation. In an embodiment, a conditional handover (CHO) command may indicate a first condition and a second condition. The first condition may indicate a condition for performing a handover (HO) of CHO, and the second condition may indicate a condition for not performing HO or discarding the CHO command. When the first condition is met before the second condition is met, the user equipment (UE) may perform the HO process; when the second condition is met and the first condition is not met, the CHO command may be discarded. In addition, the UE may identify multiple mobility state estimation (MSE) thresholds from a configuration message. Each MSE threshold may correspond to an MSE value. When the value of the mobility counter is less than or equal to the MSE threshold corresponding to a single MSE value, the UE may determine the MSE of the UE as the single MSE value. In addition, the UE may count the number of beam switches and / or the number of transmit receive point (TRP) switches that occur within a time period, and may estimate the current mobility state based on the number of beam switches and / or the number of TRP switches. Other embodiments may be described and / or required.
[0026] The following specific embodiments refer to the accompanying drawings. The same figure numbers may be used in different figures to identify the same or similar elements. In the following description, specific details such as specific structures, architectures, interfaces, technologies, etc. are set forth for the purpose of explanation rather than limitation, so as to provide a thorough understanding of various aspects of the claimed invention. However, it is obvious to those skilled in the art who benefit from this disclosure that various aspects of the claimed invention can be implemented in other examples that depart from these specific details. In some cases, descriptions of well-known devices, circuits, and methods are omitted to avoid unnecessary details obscuring the description of the present invention.
[0027] The various aspects of the illustrative embodiments will be described using terms commonly used by those skilled in the art to convey the essence of their work to other persons skilled in the art. However, it will be apparent to those skilled in the art that alternative embodiments may be practiced utilizing only some of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to those skilled in the art that alternative embodiments may be practiced without these specific details. In other cases, well-known features have been omitted or simplified to avoid obscuring the illustrative embodiments.
[0028] In addition, various operations will be described as multiple discrete operations in sequence in a manner that is most helpful for understanding the illustrative embodiments; however, the order of description should not be interpreted as implying that these operations must be order-dependent. In particular, these operations do not need to be performed in the order presented.
[0029] The phrases "in various embodiments," "in some embodiments," etc. are used repeatedly. The phrases generally do not refer to the same embodiment; however, they may refer to the same embodiment. Unless the context dictates otherwise, the terms "comprising," "having," and "including" are synonymous. The phrase "A and / or B" means (A), (B), or (A and B). The phrases "A / B" and "A or B" mean (A), (B), or (A and B), similar to the phrase "A and / or B." For the purposes of this disclosure, the phrase "at least one of A and B" means (A), (B), or (A and B). The specification may use the phrases "in one embodiment," "in an embodiment," "in some embodiments," and / or "in various embodiments," which may each refer to one or more of the same or different embodiments. In addition, the terms "comprising," "including," "having," etc. used with respect to the embodiments of the present disclosure are synonymous.
[0030] Example embodiments may be described as a process, which is depicted as a flow chart, a flow chart, a data flow chart, a structure diagram, or a block diagram. Although a flow chart may describe the operations as a sequential process, many operations may be performed in parallel, concurrently, or simultaneously. In addition, the order of the operations may be rearranged. A process may terminate when its operations are completed, but may also have additional steps not included in the accompanying drawings. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to the function returning to the calling function and / or the main function.
[0031] Example embodiments may be described in the general context of computer executable instructions (e.g., program codes, software modules, and / or functional processes) executed by one or more of the aforementioned circuits. Program codes, software modules, and / or functional processes may include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific data types. The program codes, software modules, and / or functional processes discussed herein may be implemented using existing hardware in existing communication networks. For example, the program codes, software modules, and / or functional processes discussed herein may be implemented using existing hardware at existing network elements or control nodes.
[0032] Figure 1A The architecture of a system 100A of a network according to various embodiments is shown. The following description is provided for an example system 100A operating in conjunction with a fifth generation (5G) or new radio (NR) system standard provided by the third generation partnership project (3GPP) technical specification (TS). However, the example embodiments are not limited thereto, and the described embodiments may be applicable to other networks that benefit from the principles described herein, such as long term evolution (LTE), future (e.g., sixth generation (6G)) systems, etc.
[0033] like Figure 1AAs shown, system 100A may include user equipment (UE) 101 and UE 102. As used herein, the term "user equipment" or "UE" may refer to a device with radio communication capabilities and may describe a remote user of network resources in a communication network. The term "user equipment" or "UE" may be considered synonymous with the following terms and may be referred to as them: client, mobile station, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, wireless device, reconfigurable radio device, reconfigurable mobile device, etc. In addition, the term "user equipment" or "UE" may include any type of wireless / wired device or any computing device that includes a wireless communication interface. In this example, UEs 101 and 102 are shown as smart phones (e.g., handheld touch screen mobile computing devices that can connect to one or more cellular networks), but may also include any mobile or non-mobile computing devices, such as consumer electronic devices, cellular phones, smart phones, feature phones, tablet computers, wearable computer devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptop computers, in-vehicle infotainment systems (IVI), in-car entertainment (ICE) devices, instrument clusters (ICs), heads-up display (HUD) devices, on-board diagnostics (OBD) devices, dashboard mobile equipment (DME), mobile data terminals (MDTs), electronic engine management systems (EEMS), electronic / engine control units (ECUs), electronic / engine control modules (ECMs), embedded systems, microcontrollers, control modules, engine management systems (EMS), networked or "smart" appliances, machine type communication (MTC) devices, machine to machine (M2M), Internet of Things (IoT) devices, etc.
[0034] In some embodiments, any of UEs 101 and 102 may include an Internet of Things (IoT) UE, which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. The IoT UE may utilize technologies such as M2M or MTC to exchange data with an MTC server or device via a public land mobile network (PLMN), proximity services (ProSe) or device-to-device (D2D) communication, a sensor network, or an IoT network. The M2M or MTC data exchange may be a machine-initiated data exchange. The IoT network describes interconnecting IoT UEs (which may include uniquely identifiable embedded computing devices (within the Internet infrastructure)) with short-term connections. The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connectivity to the IoT network.
[0035] UEs 101 and 102 may be configured to connect (e.g., be communicatively coupled) to an access network (AN) or radio access network (RAN) 110. In an embodiment, RAN 110 may be a next generation (NG) RAN or 5G RAN, an evolved universal mobile telecommunications system (UMTS) terrestrial radio access network (E-UTRAN), or a legacy RAN (e.g., UTRAN (UMTS terrestrial radio access network) or GERAN (GSM (Global System for Mobile Communications or Groupe Spécial Mobile) EDGE (GSM Evolution) Radio Access Network)). As used herein, the term "NG RAN" or the like may refer to a RAN 110 operating in an NR or 5G system 100A, and the term "E-UTRAN" or the like may refer to a RAN 110 operating in an LTE or 4G system 100A. UEs 101 and 102 utilize connections (or channels) 103 and 104, respectively, each of which includes a physical communication interface or layer (discussed in further detail below). As used herein, the term "channel" may refer to any tangible or intangible transmission medium for transferring data or data streams. The term "channel" may be synonymous and / or equivalent to the following terms: "communication channel", "data communication channel", "transmission channel", "data transmission channel", "access channel", "data access channel", "link", "data link", "carrier", "radio frequency carrier" and / or any other similar terms representing a path or medium through which data is transferred. In addition, the term "link" may refer to a connection between two devices over a radio access technology (RAT) for the purpose of sending and receiving information.
[0036] In this example, connections 103 and 104 are shown as air interfaces for achieving communication coupling, and may conform to a cellular communication protocol, such as a Global System for Mobile Communications (GSM) protocol, a Code Division Multiple Access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a Fifth Generation (5G) protocol, a New Radio (NR) protocol, and / or any other communication protocol discussed herein. In an embodiment, UEs 101 and 102 may also exchange communication data directly via a ProSe interface 105. The ProSe interface 105 may alternatively be referred to as a sidelink interface, and may include one or more logical channels, including but not limited to a physical sidelink control channel (PSCCH), a physical sidelink shared channel (PSSCH), a physical sidelink discovery channel (PSDCH), and a physical sidelink broadcast channel (PSBCH).
[0037] UE 102 is shown as being configured to access access point (AP) 106 (also referred to as "WLAN node 106," "WLAN 106," "WLAN terminal 106," "WT 106," etc.) via connection 107. Connection 107 may include a local wireless connection, such as a connection compliant with any IEEE 802.11 protocol, wherein AP 106 would include Wireless Fidelity router. In this example, AP 106 is shown as being connected to the Internet without being connected to the core network of the wireless system (described in further detail below). In various embodiments, UE 102, RAN 110, and AP 106 may be configured to utilize LTE-WLAN aggregation (LWA) operation and / or WLAN LTE / WLAN wireless level integration (LWIP) operation with IPsec tunnel. LWA operation may involve: UE 102 in RRC_CONNECTED is configured by RAN nodes 111, 112 to utilize radio resources of LTE and WLAN. LWIP operation may involve: UE 102 uses WLAN radio resources (e.g., connection 107) via an Internet Protocol Security (IPsec) protocol tunnel to authenticate and encrypt packets (e.g., Internet Protocol (IP) packets) sent over connection 107. The IPsec tunnel may include: encapsulating the entire original IP packet and adding a new packet header, thereby protecting the original header of the IP packet.
[0038] The RAN 110 may include one or more AN nodes or RAN nodes 111 and 112 that enable connections 103 and 104. As used herein, "access node", "access point", etc. may be described as a device that provides radio baseband functionality for data and / or voice connectivity between a network and one or more users. These access nodes may be referred to as base stations (BS), next generation NodeBs (gNBs), RAN nodes, evolved NodeBs (eNBs), NodeBs, road side units (RSUs), transmit receive points (TRxPs or TRPs), etc., and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). The term "road side unit" or "RSU" may refer to any transport infrastructure entity implemented in or by a gNB / eNB / RAN node or a fixed (or relatively stationary) UE, wherein an RSU implemented in or by a UE may be referred to as a "UE-type RSU" and an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU". As used herein, the term "NG RAN node" or the like may refer to a RAN node 111 / 112 operating in an NR or 5G system 100A (e.g., a gNB), and the term "E-UTRAN node" or the like may refer to a RAN node 111 / 112 operating in an LTE or 4G system 100A (e.g., an eNB). According to various embodiments, the RAN nodes 111 and / or 112 may be implemented as one or more dedicated physical devices such as macrocell base stations and / or low power (LP) base stations for providing femtocells, picocells, or other similar cells having a smaller coverage area, smaller user capacity, or higher bandwidth than a macrocell. In other embodiments, the RAN nodes 111 and / or 112 may be implemented as one or more software entities running on a server computer as part of a virtual network, which may be referred to as a cloud radio access network (CRAN). In other embodiments, the RAN nodes 111 and 112 may represent a network connected to the RAN via an F1 interface ( Figure 1A Each gNB distributed unit (DU) (not shown) is connected to the gNB centralized unit (CU).
[0039] Either of the RAN nodes 111 and 112 may terminate the air interface protocol and may be the first point of contact for the UEs 101 and 102. In some embodiments, either of the RAN nodes 111 and 112 may perform various logical functions of the RAN 110, including but not limited to radio network controller (RNC) functions, such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.
[0040] In some embodiments, UEs 101 and 102 may be configured to communicate with each other or with any one of RAN nodes 111 and 112 using orthogonal frequency division multiplexing (OFDM) communication signals on a multi-carrier communication channel according to various communication techniques, such as, but not limited to, orthogonal frequency division multiple access (OFDMA) communication techniques (e.g., for downlink communication) or single carrier frequency division multiple access (SC-FDMA) communication techniques (e.g., for uplink and ProSe or sidelink communication), but the scope of the embodiments is not limited thereto. The OFDM signal may include multiple orthogonal subcarriers.
[0041] In some embodiments, a downlink resource grid may be used for downlink transmissions from either of the RAN nodes 111 and 112 to the UEs 101 and 102, while uplink transmissions may utilize similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or a time-frequency resource grid, which is a physical resource in each time slot in the downlink. This time-frequency plane representation is common practice for OFDM systems, which makes radio resource allocation intuitive. Each column and row of the resource grid corresponds to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to a time slot in a radio frame. The smallest time-frequency unit in the resource grid is called a resource element. Each resource grid includes a plurality of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block includes a set of resource elements; in the frequency domain, this may represent the minimum amount of resources that can currently be allocated. There are several different physical downlink channels that are transmitted using such resource blocks.
[0042] The physical downlink shared channel (PDSCH) may carry user data and higher layer signaling to the UEs 101 and 102. The physical downlink control channel (PDCCH) may carry information about the transport format and resource allocation related to the PDSCH channel, among other things. It may also inform the UEs 101 and 102 of the transport format, resource allocation, and H-ARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel. Typically, downlink scheduling (allocation of control channel resource blocks and shared channel resource blocks to the UEs 102 within the cell) may be performed at either of the RAN nodes 111 and 112 based on channel quality information fed back from either of the UEs 101 and 102. Downlink resource allocation information may be sent on the PDCCH for (e.g., allocated to) each of the UEs 101 and 102.
[0043] PDCCH can use control channel elements (CCE) to transmit control information. Before being mapped to resource elements, PDCCH complex symbols can first be organized into quadruplets, which can then be arranged using a sub-block interleaver for rate matching. Each PDCCH can be sent using one or more of these CCEs, where each CCE can correspond to nine groups of four physical resource elements called resource element groups (REGs). Four quadrature phase shift keying (QPSK) symbols can be mapped to each REG. PDCCH can be sent using one or more CCEs, depending on the size of the downlink control information (DCI) and the channel conditions. Four or more different PDCCH formats with different numbers of CCEs (e.g., aggregation levels, L=1, 2, 4, or 8) can be defined in LTE.
[0044] Some embodiments may use a concept that is an extension of the above concept for resource allocation for control channel information. For example, some embodiments may utilize an enhanced physical downlink control channel (EPDCCH), which uses PDSCH resources for control information transmission. One or more enhanced control channel elements (ECCEs) may be used to send EPDCCH. Similar to the above, each ECCE may correspond to nine groups of four physical resource elements called enhanced resource element groups (EREGs). In some cases, ECCEs may have other numbers of EREGs.
[0045] In addition, the UE 101, 102 can measure various channel, link and / or cell related criteria, such as channel conditions, signal and / or beam strength or quality (e.g., reference signal received power (RSRP), reference signal received quality (RSRQ), signal to noise ratio (SNR), signal to noise interference (SINR), etc.), and provide a measurement report (MR) containing this information to the RAN node 111, 112. In many deployment scenarios, the UE 101, 102 may undergo a handover (HO) operation when moving between cells. For example, when the UE 101, 102 moves from a cell of the RAN node 111 to a cell of the RAN node 112, the RAN node 111 may handover the UE 101, 102 to the RAN node 112. In this case, the RAN node 111 may be regarded as a "source cell", "source RAN node" or "source eNB", and the RAN node 112 may be regarded as a "target cell", "target RAN node" or "target eNB". Typically, the source RAN node 111 may send a measurement configuration to the UE 101, 102 to request a measurement report from the UE 101, 102 when certain configured events are triggered, and the UE 101, 102 may perform signal quality measurements or cell power measurements on channels or links of the target RAN node 112 and / or other neighboring cells (not shown).
[0046] Based on the measurement results, some configured events may trigger the UE to send a measurement report to the source RAN node 111. The source RAN node 111 may decide to handover the UE 101, 102 to the target RAN node 112 by initiating a HO operation. To initiate the HO operation, the source RAN node 111 may send a HO request message to the target RAN node 112, and in response, the source RAN node 111 may receive a HO request acknowledgement (ACK) from the target RAN node 112. Upon receiving the HO request ACK, the source RAN node 111 may send a HO command to the UE to start an attach procedure with the target RAN node 112. At this point, the source RAN node 111 stops data transmission to the UE because the UE detaches from the source RAN node 111 and starts synchronizing with the target RAN node 112. If the source RAN node 111 still has data for the UE, the source RAN node 111 may send a sequence number (SN) state transfer to the target RAN node 112 and forward the data to the target RAN node 112 so that the target RAN node 112 may send such data to the UE 101, 102 once the HO operation is completed.
[0047] Conditional handover (CHO) may be used in embodiments where system 100A is an NR system. In these embodiments, UE 101, 102 may be triggered to generate and send an early measurement report (MR) to a source cell, and then receive a CHO command from the network (e.g., source / serving cell). The CHO command may include a threshold or other condition (which indicates when UE 101, 102 may perform or initiate a HO to the indicated target cell), and UE 101, 102 must wait until the condition is met before performing the HO. Using CHO may result in better HO failure performance compared to legacy system HO failure performance. However, as Figure 1B As shown, problems may arise when the conditions indicated by the CHO command do not occur or are not detected by the UE 101, 102.
[0048] Reference Figure 1B, which shows a channel quality diagram 100B for a scenario where CHO is not triggered. Figure 100B shows that when the UE 101, 102 detects that the signal strength / quality of the source cell or beam 011 (also referred to as "source 011", etc.) decreases, and the signal strength / quality of the target cell or beam 012 (also referred to as "target 012", etc.) increases, the UE 101, 102 may be triggered to send an MR at the node 140. The source 011 and the target 012 may be provided by the same or different RAN nodes 111, 112, or by different TRxPs of the same RAN node 111, 112. In this scenario, after the MR is sent at the node 140, the UE 101, 102 continues to detect that the signal strength of the source 011 is lower than the signal strength of the target 012, but the signal strength of the target 012 does not reach the threshold indicated by the CHO command. Therefore, the UE 101, 102 in this scenario does not trigger CHO at the node 141. This scenario may occur, for example, when a UE 101, 102 moves close to a cell border and then stops.
[0049] Using the two-step CHO scheme as described above in NR relies on: the UE 101 / 102 evaluating the source 011 and target cell / beam 012 strength / quality and comparing the evaluated cell / beam strength / quality with different thresholds, such as a maximum threshold X High (indicated by the CHO command) and the minimum threshold X Low (Indicated by the MR sent at node 140). Due to the NR channel characteristics and UE mobility patterns, there may potentially be a variety of following scenarios: UE 101 / 102 Low Send MR, then wait for CHO condition to occur (this may potentially take a long time to occur, e.g. Figure 1B ), which may result in poor HO performance. Figure 1C-1E The embodiments shown and described may alleviate these problems.
[0050] Figure 1C A channel quality diagram 100C is shown for a scenario where a timer-based CHO exit condition is used according to various embodiments. In these embodiments, the validity timer may be associated with the CHO command of the source 011. In such an embodiment, the UE 101 / 102 may start the timer at node 143 in response to receiving a CHO command for a particular target cell / beam 112. At node 144, the UE 101 / 102 may periodically or continuously check the HO execution condition indicated by the CHO command for the duration of the validity period (e.g., by comparing the difference between the quality of the source 011 and the target cell / beam 012 with the value of X). HighIf the condition is met before the timer expires, the UE 101 / 102 may perform a HO with the target cell / beam 112. However, if at node 145 the timer expires before the CHO condition occurs, the UE 101 / 102 may discard the CHO command and operate as if the CHO command had never been received.
[0051] The validity timer can be configured in different ways based on various criteria. In a first example, the validity timer can be configured for each CHO command, wherein a single validity timer duration can be indicated in the configuration for one or more target / candidate cells or beams. In a second example, the validity timer can be configured for each target or candidate entity, wherein a CHO command or configuration can indicate multiple target / candidate cells or beams with separate configurations, and each target / candidate cell or beam can be associated with a corresponding timer duration. In addition, each timer (or timer duration) can be different from each other. In an embodiment, the CHO command or configuration can indicate the start time or start condition for starting the timer. For example, the CHO command or configuration can indicate that the timer is started in the following cases: when the UE 101 / 102 receives the CHO command; when the UE 101 / 102 detects or estimates that the serving cell / beam signal strength / quality is lower than a configured or determined threshold; and / or when the UE 101 / 102 detects or estimates that the target cell or beam is less than a certain signal strength / quality (e.g., X dB) compared to the source 012 cell or beam. In addition, when the HO operation is performed or triggered to be performed (e.g., when a CHO condition is detected), the timer can be reset. In addition, once the timer for the previous CHO command has expired or reset, the UE 101 / 102 can generate and send a new MR for the same target cell / beam. Table 1 shows an example configuration or CHO command (which can be included in an RRC message) to be used for an exit condition embodiment based on a validity timer. The example of Table 1 is based on the current LTE standard, but can also be applied to NR implementations.
[0052]
[0053]
[0054] Table 1
[0055] In the example of Table 1, the MobilityControlInfo information element (IE) may include a conditional HO release field (conditionalHORelease-r15) including the validity timer duration in milliseconds (ms). In this example, the value "ms50" may refer to 50ms, "ms100" may refer to 100ms, etc. In the case where multiple timers are to be set / configured for individual cells or beams, the MobilityControlInfo IE may include multiple conditionalHORelease-r15 fields, each of which may include their own validity timer value.
[0056] Figure 1D A channel quality diagram 100D is shown for a scenario using event-based CHO exit conditions according to various embodiments. In these embodiments, in response to detecting an indicated or configured event, the CHO command may be discarded. The event may be a measured / detected drop in target or serving cell strength / quality below a threshold, a difference between source 011 and target 012 cell or beam strength / quality, or some other event. Figure 1D In the example of FIG. 1 , the event-based exit condition may be that the difference between the source 011 and target 012 cell or beam SINR drops below the MR threshold value X. Low .like Figure 1D As shown, UE 101 / 102 may send MR at node 140, and over time, the signal strength / quality of the target cell / beam 012 may decrease. In this case, since the difference between the source 011 and target 012 cell / beam SINR becomes less than X Low (MR threshold), therefore, UE 101 / 102 may determine that target cell / beam 012 is no longer better than source cell / beam 011. Therefore, UE 101 / 102 in this scenario may discard the CHO command at node 147. After discarding the CHO command, UE 101 / 102 may send a new MR for any potential new target 012 cell / beam ( Figure 1D not shown).
[0057] In various embodiments, a certain decibel (dB) threshold may be used to define an event-based exit condition. For example, a CHO command or configuration may indicate that the event is when the target cell / beam SINR is less than or equal to (<=) 1 dB higher than the source cell / beam 011 SINR.
[0058] In some embodiments, the exit condition may be added directly in the event configuration, as shown in Table 2. Table 2 shows an example RRC message IE for event A3 according to the current LTE standard, where additions or changes are made to include the CHO exit condition. However, the example of Table 2 may also be applicable to other LTE event configurations and / or to NR implementations.
[0059]
[0060]
[0061]
[0062]
[0063] Table 2
[0064] In the example of Table 2, the ReportConfigEUTRA IE may include an event A3 exit condition (a3-OffsetLeave) in the eventId IE / field, where the a3-OffsetLeave element will include an integer value. In the case where multiple event-based exit conditions are to be set / configured for individual cells or beams, the ReportConfigEUTRA IE may include multiple OffsetLeave elements in one or more of the listed eventId fields (e.g., event1, eventA2, eventA3, etc.), each of which may include its own value independent of other OffsetLeave elements. Additionally, each eventId field may include multiple OffsetLeave elements. In some embodiments, a hysteresis element / value may be used to indicate an event-based exit condition, or a new hysteresis element / value may be added to each eventId for which an exit condition is to be included.
[0065] Figure 1EA channel quality diagram "100E" is shown of a situation where the UE 101 / 102 detects another target cell or beam 013 (also referred to as a new target "013") according to various embodiments. In these embodiments, the UE 101 / 102 may monitor multiple cells / beams at a given time, and one of these cells / beams may evolve to have a better cell / beam signal strength / quality than the initially desired target 012. This situation may occur while the UE 101 / 102 is evaluating the CHO execution conditions for performing the HO of the target 012 as indicated by the CHO command. In these embodiments, the UE 101 / 102 may send an MR at node 140 as previously described, and the UE 101 / 102 may determine at node 148 that the signal strength / quality of the new target 013 satisfies the MR criteria for performing the CHO operation. At node 149, the UE 101 / 102 may determine that the CHO conditions are satisfied for the new target 013. Since this indicates that the new target 013 is a potentially better cell or beam to which the UE 101 / 102 should switch, the UE 101 / 102 may discard the CHO command for the old target 012, send a new MR for the new target cell, and wait for the network (e.g., source RAN node 111, 112) to send a new / updated HO (or CHO) command for the new target 013. Figure 100E illustrates this situation, where the new target 013 improves in quality while the CHO execution conditions for target 012 were never met. These embodiments may require some network coordination, but may help avoid unnecessary intermediate HOs that may result if the UE 101 / 102 switches to target 012 and then subsequently repeats the entire HO process to switch to the new target 013.
[0066] In addition to about Figure 1C-1E In addition to the discussed scenarios, in various embodiments, some or all conditions may also be released when the UE 101 / 102 performs a HO (or CHO). In some embodiments, some or all conditions may be released when one of the previously discussed conditions is triggered. In some embodiments, some or all conditions may be released when the UE 101 / 102 declares a radio link failure (RLF) (e.g., when timers T310 and / or T312 have expired).
[0067] In some embodiments, if the CHO condition is not met and one of the previously discussed exit conditions is met, the UE 101 / 102 may have no choice but to connect or reconnect to the source cell or beam, because the legacy process specifies that once the HO command is sent to the UE 101 / 102, the source cell should interrupt any data transmission to the UE 101 / 102. In order for the UE to connect / reconnect with the source cell / beam when the exit condition is not met, the UE 101 / 102 may perform one or more of a scheduling request (SR) procedure, a random access (RA) procedure, and / or an RRC connection reestablishment procedure. In an embodiment, if there are no valid physical uplink control channel (PUCCH) resources available, the UE 101 / 102 may perform a RA procedure through the source cell / beam. In some embodiments, the UE 101 / 102 may perform an RRC connection reestablishment procedure when the source RAN node 111 / 112 still has a valid UE context. Therefore, the network (e.g., the source RAN node 111 / 112) may need to provide some coordination to ensure that the source RAN node 111 / 112 does not discard the UE context after sending the HO (or CHO) command, at least until the source RAN node 111 / 112 receives an indication that the UE 101 / 102 has been successfully handed over to the target RAN node 111 / 112.
[0068] In an embodiment, UE 101 / 102 may perform an SR process, a RA process, and / or an RRC connection reestablishment process according to a predetermined or configured priority or order. In one example, UE 101 / 102 may be configured to perform an RA process as a first or main process when RA resources are allocated to UE 101 / 102, and may perform an RRC connection reestablishment process as a secondary process when RA resources are not allocated to UE 101 / 102. In another example, UE 101 / 102 may be configured to perform an SR process as a main process when PUCCH resources are available or allocated to UE 101 / 102, and may perform an RA process and / or an RRC connection reestablishment process as a secondary process discussed with respect to the previous example. In yet another example, UE 101 / 102 may perform an SR process, a RA process, and an RRC connection reestablishment process in sequence until a (re)connection with the source cell / beam is (re)established.
[0069] Furthermore, in various embodiments, when the UE 101 / 102 successfully performs a HO to the target cell or beam, the UE 101 / 102 may send a notification of the successfully performed HO to the source RAN node 111 / 112. In these embodiments, the UE 101 / 102 may send the indication before the initiation of the HO procedure, during the execution of the HO procedure, or after the HO procedure has been completed. Additionally or alternatively, once the UE has completed the HO, the target RAN node 111 / 112 may send a HO completion indication to the source RAN node 111 / 112 (if different from the target RAN node 111 / 112). The source RAN node 111 / 112 may use the indication to release the UE 101 / 102 and / or the UE context.
[0070] According to various embodiments, several options may be used to enable the CHO command. In a first option, a new event for CHO may be created. In a second option, a new field in the HO command may be created to indicate that the HO is CHO or that CHO is enabled, and the field may also include or indicate a CHO condition. In this option, the new field and / or the CHO condition may be included in the RRC container generated by the target RAN node 111 / 112. In a third option, a new field may be created in the RRCConnectionReconfiguration message sent by the source RAN node 111 / 112 to the UE 101 / 102, which may also include the mobilityControlInfo IE. In this option, the RRCConnectionReconfiguration message may be generated by the source RAN node 111 / 112 together with the CHO condition and the exit condition.
[0071] In addition, the source RAN node 111 / 112 may signal the occurrence of CHO to the target RAN node 111 / 112. In the case where the source RAN node 111 / 112 is different or separate from the target RAN node 111 / 112, the signaling may be accomplished using an X2 or Xn interface, or in the case where the source and target RAN nodes 111 / 112 are the same device or equipment, the signaling may be accomplished using an internal interface (e.g., using an F1 interface between a gNB centralized unit (CU) and a gNB distributed unit (DU) in an NR implementation). In some embodiments, the source RAN node 111 / 112 may include an indication in the HO request message to indicate that the HO is a CHO. In this way, the target RAN node 111 / 112 may be informed that the CHO may not occur immediately. Additionally, in these embodiments, the target RAN node 111 / 112 may accept CHO if it is supported (e.g., by sending a HO confirmation (ACK) message to the source RAN node 111 / 112), or may reject CHO if it is not supported (e.g., by sending a HO negative ACK (NACK) message to the source RAN node 111 / 112). In other embodiments, the target RAN node 111 / 112 may determine that CHO may be triggered, and may provide an indication of the determination to the source RAN node 111 / 112.
[0072] In addition, the communication between the source and target RAN nodes 111 / 112 may include: when the CHO exit condition has been met, and / or when CHO has failed, the source RAN node 111 / 112 indicates to the target RAN node 111 / 112 to release the RACH resources. The source RAN node 111 / 112 may send the indication in response to receiving a new MR from the UE 101 / 102 as described above or when the exit condition timer at the source RAN node 111 / 112 expires. In some embodiments, the source RAN node 111 / 112 may send the CHO condition and the CHO exit condition to the target RAN node 111 / 112, so that the target RAN node 111 / 112 can determine whether the CHO exit condition has occurred, and when the CHO exit condition occurs, the target RAN node 111 / 112 can release the RACH resources. These embodiments may be used in the case of using a timer-based exit condition.
[0073] Additionally, in some embodiments, the UE capability information may also be modified or altered to accommodate CHO. For example, a one (1) bit field may be added to the UE Capability IE to indicate that the UE 101 / 102 supports conditional handover. In other embodiments, CHO support may be a mandatory feature, and therefore, the network element may assume that CHO is supported by the UE 101 / 102 or for a particular class or type of UE 101 / 102.
[0074] Return to reference Figure 1A , the UE 101, 102 may perform measurements on cell selection and cell reselection and on handover operations. When the UE 101, 102 is camped on a cell provided by the RAN node 111, 112, the UE 101, 102 may periodically or periodically search for a better cell or beam according to the cell reselection criteria. If a better cell or beam is found, the cell or beam may be selected, and the UE 101, 102 may tune to the control channel of the cell or (anchor channel of the beam), so that the UE 101, 102 may receive system information, registration area information (e.g., tracking area information), other access layer (AS) and / or non-access layer (NAS) information and / or paging and notification messages (if registered), and transition to connected mode (if registered).
[0075] In some embodiments, the cell selection or reselection process may be speed-dependent, wherein the UE 101, 102 may be limited to the number of reselections they can perform based on the rate or speed at which the UE 101, 102 is traveling. In these embodiments, the UE 101, 102 may be able to estimate their respective mobility states. The mobility state of the UE may be used to avoid frequent cell (re)selection and HO, and may be used to enhance other features. The UE 101, 102 may estimate their respective mobility states by counting handovers and / or cell (re)selections within a selected time period or time window. In this regard, the UE 101, 102 may receive an indication or configuration of a time window and a counting threshold for determining the respective mobility states from the network. In some embodiments, the network may implement mobility state estimation by tracking the previous history of handovers or (re)selections of the UE 101, 102. The process or procedure by which the UE 101, 102 (or the network) estimates or determines their respective mobility states may be referred to as mobility state estimation (MSE).
[0076] The mobility state may include a normal mobility state, a medium mobility state, and a high mobility state. The UE's mobility state may be classified into one of the above categories based on the T state transmitted in the system information broadcast of the serving cell. CRmax 、N CR_H 、NCR_M and T CRmaxHyst Mobility state parameters. CRmax N is the duration used to evaluate the criteria for entering the mobility state (eg, the time period or time window discussed previously); CR_H is the threshold number of cell (re)selections for entering the high mobility state; N CR_M is the number of cell (re)selections for entering the medium mobility state; and T CRmaxHyst is an additional duration (time period, time window, etc.) used to evaluate the criteria for entering the normal mobility state. CRmax The number of cell reselections during this period exceeds N CR_M But no more than N CR_H , UE 101, 102 may estimate its mobility state as medium mobility. CRmax The number of cell reselections during this period exceeds N CR_H When the UE 101 / 102 has a reselection state, the UE 101 / 102 may estimate its mobility state as a high mobility state. When none of the UE's mobility states is one of the medium or high mobility states, the UE 101, 102 may estimate its mobility state as a normal mobility state. If the same cell is reselected right after another reselection, the UE 101, 102 may not count consecutive reselections between the same two cells into the mobility state detection criteria.
[0077] If the UE 101, 102 detects criteria for a high mobility state, the UE 101, 102 may enter or transition to the high mobility state. If the UE 101, 102 detects criteria for a medium mobility state, the UE 101, 102 may enter or transition to the medium mobility state. Otherwise, if during the time period T CRmaxHyst If no criteria for medium or high mobility state are detected during this period, the UE 101, 102 may enter or transition to a normal mobility state. When the UE 101, 102 operates in an NR system, the UE 101, 102 may experience high frequency beamforming to be used, which may make MSE more challenging.
[0078] Various NR implementations may include high frequency or relatively high rate beamforming, which may introduce complexity into the MSE process. This is because the NR RAN node 111 / 112 may include multiple TRPs, and each of the multiple TRPs may be used to provide a separate cell or form a separate beam. Therefore, the NR cell size may be relatively large compared to the cell size provided by the typical LTE RAN node 111 / 112.
[0079] According to various embodiments, when HO and / or cell reselection occurs, regardless of TRxP and / or beam switching, the NR-capable UE 101 / 102 can count each cell based on the corresponding cell identifier (cell ID), and the UE 101 / 102 can use the cell count and the configured mobility state threshold set to determine whether the UE 101 / 102 is in a high, medium or low mobility state. In an embodiment, the UE 101 / 102 can also count the number of TRxP, beam and / or cell reselection or switching, which can be used to determine the UE mobility state.
[0080] In a first example, all NR cells in a given area or network may have the same cell size regardless of the number of TRxPs per cell. In this example, the UE 101 / 102 may determine the UE mobility state based on the HO / reselection count and the configured mobility state threshold, determine the UE mobility state based on the beam and / or TRxP switching count and the configured mobility state threshold, or a combination thereof.
[0081] In a second example, various NR cells in a given area or network may have different cell sizes. In this example, UE 101 / 102 may determine the UE mobility state in the same or similar manner as in the first example. Additionally or alternatively, UE 101 / 102 may use cell counts, beam switching counts, and / or TRxP switching counts to estimate the cell size of the current serving cell, and use the estimated cell size for the previously discussed MSE process of the first example. In some embodiments, the network (e.g., RAN node 111 / 112) may broadcast or otherwise indicate the number of TRPs for a cell set, and UE 101 / 102 may use this information to estimate the cell size for MSE.
[0082] In various embodiments, the UE 101 / 102 may also be configured with a scaling factor for the beam switch count, and the weighted sum may be determined using the scaling factor. In these embodiments, the weighted cell count may be based on the TRP and / or the number of beam switches within the individual cell, and the scaling factor may be used to take the beam / TRP switches into account for the cell size. For example, Table 3 shows example UE 101 / 102 count information indicating the number of beam switches and TRP switches for an individual cell.
[0083] Cell ID Beam switching times TRP switching times 1 10 3 3 5 5 5 100 10 10 20 2 5 80 8
[0084] Table 3
[0085] In Table 3, individual cells may be identified by the Cell ID field. From the example of Table 3, cell 5 may have a larger cell size than cell 3, or UE 101 / 102 may have moved along the cell edge of cell 3. According to the previously discussed embodiments, UE 101 / 102 may add the number of beam switches and the number of TRP switches, and may compare the sum to the configured mobility state threshold. However, since, for example, UE 101 / 102 may be blocked in a single cell (which causes UE 101 / 102 to perform a relatively large number of beam / TRP switches while UE 101 / 102 is in a low mobility state), using the above-mentioned scaling factor may provide a more accurate MSE.
[0086] In some embodiments, the network (e.g., RAN node 111 / 112) may signal one or more tuples, attribute-value pairs (AVPs), or other similar data structures to indicate individual scaling factors and threshold associations for beam switching for individual cells only. For example, the network may signal a tuple of the form (S, T), where the first number S in the tuple may be the scaling factor and the second number T in the tuple may be the corresponding threshold. In these embodiments, the UE 101 / 102 may use this information to apply a weighted sum. For example, the network may signal the following tuple for cell 5 in Table 3: (0.5, 10), (0.3, 20), (0.1, 50); and the weighted sum may be calculated as follows: 10*0.5+20*0.3+50*0.1=5+6+5=17. In this example, the UE 101 / 102 may use the configured threshold to determine the MSE. In some embodiments, the network may signal the same or similar tuples, AVPs, etc. to be used only for TRP switching. In some embodiments, the network may signal a first set of tuples, AVPs, etc. to be used for beam switching and a second set of tuples, AVPs, etc. to be used for TRP switching, and UE 101 / 102 may perform MSE using these two sets of tuples, AVPs, etc.
[0087] For connected mode, the above beam and TRP related actions / operations may be applied. However, for idle mode, UE 101 / 102 may not be able to perform or learn beam related information. In these cases, UE 101 / 102 may learn the change in the highest signal value in each block within L blocks, and may use the L index change as a change in the beam, and apply the above information. Alternatives may include using the UE beam as the beam count, regardless of the network beam.
[0088] Return to reference Figure 1A, the RAN nodes 111, 112 may be configured to communicate with each other via an interface 113X. In an embodiment where the system 100A is an LTE system, the interface 113X may be an X2 interface 113X. The X2 interface may be defined between two or more RAN nodes 111, 112 (e.g., two or more eNBs, etc.) connected to the EPC 120 and / or between two eNBs connected to the EPC 120. In some implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U may provide a flow control mechanism for user data packets transmitted over the X2 interface, and may be used to transfer information about the delivery of user data between eNBs. For example, X2-U may provide specific sequence number information about user data transmitted from the master eNB (MeNB) to the secondary eNB (SeNB), information about the PDCP PDUs that are successfully delivered from the SeNB to the UE 101 / 102 in sequence for the user data, information about the PDCP PDUs that are not delivered to the UE 101 / 102, information about the current minimum expected buffer size at the SeNB for user data sent to the UE, etc. X2-C may provide: intra-LTE access mobility functions including context transfer from the source to the target eNB, user plane transfer control, etc.; load management functions; and inter-cell interference coordination functions.
[0089] In an embodiment where the system 100A is a 5G or NR system, the interface 113X may be an Xn interface 113X. The Xn interface is defined between two or more RAN nodes 111, 112 (e.g., two or more gNBs, etc.) connected to the 5GC 120, between the RAN nodes 111, 112 (e.g., gNBs) connected to the 5GC 120 and an eNB, and / or between two eNBs connected to the 5GC 120. In some implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U may provide non-guaranteed delivery of user plane PDUs and support / provide data forwarding and flow control functions. The Xn-C may provide management and error handling functions, functions for managing the Xn-C interface; mobility support for UE 101 / 102 in a connected mode (e.g., CM-CONNECTED), including functions for managing UE mobility in a connected mode between one or more RAN nodes 211. Mobility support may include: context transfer from the old (source) service RAN node 111, 112 to the new (target) service RAN node 111, 112; and control of the user plane tunnel between the old (source) service RAN node 111, 112 and the new (target) service RAN node 111, 112. The protocol stack of Xn-U may include a transport network layer built on the Internet Protocol (IP) transport layer and a GTP-U layer on top of the UDP and / or IP layer for carrying user plane PDUs. The Xn-C protocol stack may include an application layer signaling protocol (referred to as the Xn Application Protocol (Xn-AP)) and a transport network layer built on SCTP. SCTP may be on top of the IP layer and may provide guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transport is used to transmit signaling PDUs. In other implementations, the Xn-U protocol stack and / or the Xn-C protocol stack may be the same or similar to the user plane and / or control plane protocol stacks shown and described herein.
[0090] The RAN 110 is shown as being communicatively coupled to a core network - in this embodiment, a core network (CN) 120. The CN 120 may include a plurality of network elements 122 configured to provide various data and telecommunication services to customers / subscribers (e.g., users of UEs 101, 102) connected to the CN 120 via the RAN 110. The term "network element" may describe a physical or virtualized device used to provide wired or wireless communication network services. The term "network element" may be considered synonymous with, and / or may be referred to as, a networked computer, networking hardware, network equipment, routers, switches, hubs, bridges, radio network controllers, radio access network equipment, gateways, servers, virtualized network functions (VNFs), network function virtualization infrastructures (NFVIs), etc. The components of the CN 120 may be implemented in one physical node or in separate physical nodes including components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some embodiments, network function virtualization (NFV) may be utilized to virtualize any or all of the above network node functions via executable instructions stored in one or more computer-readable storage media (described in further detail below). A logical instantiation of CN 120 may be referred to as a network slice, and a logical instantiation of a portion of CN 120 may be referred to as a network sub-slice. NFV architecture and infrastructure may be used to virtualize one or more network functions that are otherwise performed by proprietary hardware onto physical resources that include a combination of industry-standard server hardware, storage hardware, or switches. In other words, the NFV system may be used to perform a virtual or reconfigurable implementation of one or more EPC components / functions.
[0091] In an embodiment, CN 120 may be a 5G CN (referred to as "5GC 120", etc.), while in other embodiments, CN 120 may be an evolved packet core (EPC). In the case where CN 120 is an EPC (referred to as "EPC" 120, etc.), RAN 110 may be connected to CN 120 via an S1 interface 113A. In an embodiment, S1 interface 113A may be divided into two parts: an S1 user plane (S1-U) interface 114, which carries service data between RAN nodes 111 and 112 and a serving gateway (S-GW); and an S1-mobility management entity (MME) interface 115, which is a signaling interface between RAN nodes 111 and 112 and the MME.
[0092] In an embodiment, the EPC 120 includes an MME, an S-GW, a packet data network (PDN) gateway (P-GW), and a home subscriber server (HSS). The MME 121 may be functionally similar to the control plane of a legacy serving general packet radio service (GPRS) support node (SGSN). The MME may perform various mobility management (MM) procedures to manage mobility aspects in access (e.g., gateway selection and tracking area list management). MM (also referred to as "EPS MM" or "EMM" in the E-UTRAN system) may refer to all applicable procedures, methods, data storage, etc. for maintaining knowledge of the current location of the UE 101, 102, and providing services such as user identity confidentiality to the user / subscriber. Each UE 101, 102 and the MME 121 may include an MM or EMM sublayer, and when the attach procedure is successfully completed, an MM context may be established in the UE 101, 102 and the MME 121. The MM context may be a data structure or database object that stores MM-related information of the UE 101, 102.
[0093] The HSS may include a database for network users that includes subscription-related information for supporting network entities in handling communication sessions. Depending on the number of mobile users, the capacity of the devices, the organization of the network, etc., the EPC network 120 may include one or more HSSs 124. For example, the HSS may provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, etc.
[0094] The S-GW may terminate the S1 interface 113A towards the RAN 110 and route data packets between the RAN 110 and the EPC 120. In addition, the S-GW may be a local mobility anchor point for inter-RAN node handovers and may also provide anchoring for inter-3GPP mobility. Other responsibilities may include legal interception, billing, and certain policy enforcement. The P-GW may terminate the SGi interface towards the PDN. The P-GW may route data packets between the EPC network 123 and an external network, such as a network including an application server 130 (alternatively referred to as an application function (AF)), via an Internet Protocol (IP) interface 125. Typically, the application server 130 may be an element that provides applications that use IP bearer resources in the context of a core network (e.g., a UMTS packet service (PS) domain, LTE PS data services, etc.). In this embodiment, the P-GW is shown as being communicatively coupled to an application server 130 via an IP communication interface 125. The application server 130 may also be configured to support one or more communication services (e.g., voice over Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for UEs 101 and 102 via EPC 120.
[0095] The P-GW may also be a node for policy enforcement and charging data collection. The Policy and Charging Enforcement Function (PCRF) is a policy and charging control element of the EPC 120. In a non-roaming scenario, there may be a single PCRF associated with the Internet Protocol Connectivity Access Network (IP-CAN) session of the RE in the Home Public Land Mobile Network (HPLMN). In a roaming scenario with local detachment of the service, there may be two PCRFs associated with the IP-CAN session of the RE: the Home PCRF (H-PCRF) in the HPLMN and the Visited PCRF (V-PCRF) in the Visited Public Land Mobile Network (VPLMN). The PCRF may be communicatively coupled to the application server 130 via the P-GW. The application server 130 may signal the PCRF to indicate a new service flow and select appropriate quality of service (QoS) and charging parameters. The PCRF 126 may specify the rule as a Policy and Charging Enforcement Function (PCEF) (not shown) through an appropriate service flow template (TFT) and QoS identifier class (QCI) (which starts the QoS and charging specified by the application server 130).
[0096] In the case where CN 120 is a 5GC (referred to as "5GC 120" or the like), RAN 110 may be connected to CN 120 via an NG interface 113A. In an embodiment, NG interface 113A may be divided into two parts: an NG user plane (NG-U) interface 114, which carries service data between RAN nodes 111 and 112 and a user plane function (UPF); and an S1 control plane (NG-C) interface 115, which is a signaling interface between RAN nodes 111 and 112 and an access and mobility function (AMF). About Figure 2 Discussed in more detail, CN 120 is an embodiment of 5GC 120.
[0097] Figure 2 The architecture of a system 200 of a 5G network according to some embodiments is shown. The system 200 is shown to include the previously discussed UE 101 and 102 (collectively referred to as "UE 101 / UE 102" or "UE 101 / 102"); the previously discussed RAN 110, which may include the previously discussed RAN nodes 111 and 112; a data network (DN) 203, which may be, for example, an operator service, Internet access, or a 3rd party service; and a 5G core network (5GC or CN) 120.
[0098] In addition to being able to perform handover and MSE as previously discussed, 5GC-capable UEs 101, 102 may also perform beam management operations / processes. In NR implementations, beam management may refer to a set of layer 1 (L1) and / or layer 2 (L2) processes for acquiring and maintaining a set of transmit / receive points (TRP or TRxP) and / or UE beams that may be used for downlink (DL) and uplink (UL) transmission and / or reception, which may include: beam determination, which may refer to a TRxP or UE capability for selecting its own transmit (Tx) / receive (Rx) beam; beam measurement, which may refer to a TRxP or UE capability for measuring the characteristics of a received beamformed signal; beam reporting, which may refer to a UE capability for reporting information about a beamformed signal based on beam measurement; beam scanning, which may refer to an operation covering a spatial area, wherein beams are transmitted and / or received during time intervals in a predetermined manner.
[0099] The Tx / Rx beam correspondence at the TRxP holds if at least one of the following conditions is met: the TRxP is capable of determining the TRxP Rx beam for uplink reception based on the downlink measurement of the UE on one or more Tx beams of the TRxP; and the TRxP is capable of determining the TRxP Tx beam for downlink transmission based on the uplink measurement of the TRxP on one or more Rx beams of the TRxP. The Tx / Rx beam correspondence at the UE holds if at least one of the following conditions is met: the UE is capable of determining the UE Tx beam for uplink transmission based on the downlink measurement of the UE on one or more Rx beams of the UE; the UE is capable of determining the UE Rx beam for downlink reception based on the indication of the TRxP based on the uplink measurement on one or more Tx beams of the UE; and the capability indication of information related to the UE beam correspondence of the TRxP is supported.
[0100] In some implementations, DL beam management may include processes P-1, P-2, and P-3. Process P-1 may be used to enable UE measurements on different TRxP Tx beams to support selection of TRxP Tx beams / UE Rx beams. For beamforming at TRxP, process P-1 typically includes intra / inter Tx beam scanning of TRxP from different beam sets. For beamforming at UE, process P-1 typically includes UE Rx beam scanning from different beam sets.
[0101] Procedure P-2 can be used to enable UE measurements on different TRxP Tx beams to possibly change the Tx beams between / within TRxPs. Procedure P-2 can be a special case of Procedure P-1, where Procedure P-2 can be used for a possibly smaller beam set for beam refinement than Procedure P-1. In the case where the UE uses beamforming, Procedure P-3 can be used to enable UE measurements on the same TRxP Tx beam to change the UE Rx beam. Procedures P-1, P-2, and P-3 can be used for aperiodic beam reporting.
[0102] UE measurements based on RSs (at least CSI-RS) for beam management include K beams (where K is the total number of configured beams), and the UE can report the measurement results of N selected Tx beams (where N may or may not be a fixed number). Procedures based on RSs for mobility purposes are not excluded. If N < K, the beam information to be reported may include the measurement parameters for the N beams and the information indicating the N DL Tx beams. Other information or data may be included in or include the beam information. When the UE is configured with K'> 1 non-zero power (NZP) CSI-RS resources, the UE may report N' CSI-RS resource indicators (CRIs).
[0103] In some NR implementations, the UE can trigger a mechanism to recover from a beam failure, which can be referred to as "beam recovery", "beam failure recovery request procedure", etc. A beam failure event may occur when the quality of the beam pair link of the associated control channel drops below a threshold, when the timeout of the associated timer occurs, etc. When a beam failure occurs, the beam recovery mechanism can be triggered. For recovery purposes, the network can explicitly configure resources for UL transmission of signals for the UE. The configuration of resources is supported, where the base station (e.g., TRP, gNB, etc.) is listening from all or some directions (e.g., the random access area). The UL transmission / resources for reporting beam failure can be in the same time instance as the physical random access channel (PRACH) or in a time instance different from (configurable for the UE) the PRACH and orthogonal to the PRACH resources. The transmission of DL signals is supported to allow the UE to monitor beams to identify new potential beams.
[0104] For beam failure recovery, if all serving PDCCH beams fail, a beam failure shall be declared. When a beam failure is declared, a beam failure recovery request procedure can be initiated. For example, when a beam failure is detected on the serving SSB / CSI-RS, the beam failure recovery request procedure can be used to indicate a new SSB or CSI-RS to the serving gNB (or TRP). The beam failure can be detected by the lower layer and indicated to the medium access control (MAC) entity of the UE.
[0105] In some implementations, beam management may include providing or not providing beam-related indications. When beam-related indications are provided, information about the UE-side beamforming / reception process for CSI-RS-based measurements may be indicated to the UE via QCL. The same or different beams on the control channel and corresponding data channel transmissions may be supported.
[0106] Downlink (DL) beam indication can be based on a transmission configuration indication (TCI) state. The TCI state can be indicated in a TCI list configured by a radio resource control (RRC) and / or a media access control (MAC) control element (CE). In some implementations, the UE can be configured by higher layer signaling to up to M TCI states to decode the PDSCH based on the detected PDCCH, where the downlink control information (DCI) is intended for the UE and a given serving cell, where M depends on the UE capabilities. Each configured TCI state includes a reference signal (RS) set TCI-RS-SetConfig. Each TCI-RS-SetConfig may include parameters for configuring a quasi-co-location relationship between the RS in the RS set and the demodulation reference signal (DM-RS) port group of the PDSCH. For each DL RS configured by the higher layer parameter QCL type, the RS set may include a reference to one or two DL RSs and an associated quasi-co-location type (QCL type). For the case of two DL RSs, the QCL type should not be the same regardless of whether the reference is for the same DL RS or different DL RSs. The quasi-co-positioning type indicated to the UE is based on the higher-layer parameter QCL-Type and can adopt one or a combination of the following types: QCL-TypeA: {Doppler shift, Doppler spread, average delay, delay spread}; QCL-TypeB: {Doppler shift, Doppler spread}; QCL-TypeC: {average delay, Doppler shift}; QCL-TypeD: {spatial Rx parameters}.
[0107] The UE may receive (e.g., in a MAC CE) a selection command that may be used to map up to 8 TCI states to code points of the DCI field TCI-STATE. Until the UE receives a higher layer configuration of the TCI state and before receiving an activation command, the UE may assume that the antenna port of one DM-RS port group of the PDSCH of the serving cell is spatially quasi-co-located with the SSB determined during the initial access process. When the number of TCI states in TCI-STATE is less than or equal to 8, the DCI field TCI-STATE directly indicates the TCI state.
[0108] The beam failure recovery request may be transmitted via a dedicated PRACH or physical uplink control channel (PUCCH) resource. For example, the UE may be configured with a set of periodic CSI-RS resource configuration indices for the serving cell via a higher layer parameter Beam-Failure-Detection-RS-ResourceConfig And is configured with a set of CSI-RS resource configuration index and / or SS / PBCH block index through a higher layer parameter Candidate-Beam-RS-List For radio link quality measurement on the serving cell. If no configuration is present, beam failure detection can be based on CSI-RS or SSB, which is quasi-co-located (QCL) in space with the PDCCH demodulation reference signal (DMRS). For example, if the UE is not provided with the higher layer parameter Beam-Failure-Detection-RS-ResourceConfig, the UE may determine Includes SS / PBCH blocks and periodic CSI-RS configurations with the same value for the higher layer parameter TCI-StatesPDCCH as the control resource set (CORESET) that the UE is configured to monitor PDCCH.
[0109] The physical layer of the UE can be set to the threshold Q out,LR According to the resource configuration collection Evaluate the quality of the wireless link. Threshold Q out,LR Corresponding to the default values of the higher layer parameters RLM-IS-OOS-thresholdConfig and beam-failure-candidate-beam-threshold, respectively. The UE can evaluate the radio link quality based only on the periodic CSI-RS resource configuration or SS / PBCH block that is quasi-co-located with the DM-RS of the PDCCH reception DM-RS monitored by the UE. The UE applies the configured Q in,LR After scaling the SS / PBCH block transmit power by the value provided by the higher layer parameter Pc_SS, the UE applies Q out,LR Threshold.
[0110] In some implementations, if the MAC entity has received a beam failure indication from a lower layer, the MAC entity may start a beam failure recovery timer (beamFailureRecoveryTimer) and initiate a random access procedure. If the beamFailureRecoveryTimer expires, the MAC entity may indicate a beam failure recovery request failure to the upper layer. If a downlink assignment or uplink approval has been received (e.g., on a PDCCH addressed with respect to a cell radio network temporary identifier (C-RNTI)), the MAC entity may stop and reset the beamFailureRecoveryTimer and consider the beam failure recovery request procedure to be successfully completed.
[0111] Return to reference Figure 2 , CN 120 may include an authentication server function (AUSF) 222; an access and mobility management function (AMF) 221; a session management function (SMF) 224; a network exposure function (NEF) 223; a policy control function (PCF) 226; a network function (NF) repository function (NRF) 225; a unified data management (UDM) 227; an application function (AF) 228; a user plane function (UPF) 202; and a network slice selection function (NSSF) 229.
[0112] UPF 202 can act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point for interconnection to DN 203, and a branch point for supporting multi-homing PDU sessions. UPF 202 can also perform packet routing and forwarding, packet inspection, user plane portion of mandatory policy rules, legal interception packets (UP sets); service usage reporting, QoS processing for the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), uplink service verification (e.g., SDF to QoS flow mapping), transmission level packet marking in uplink and downlink, and downlink packet buffering and downlink data notification triggering. UPF 202 may include an uplink classifier to support routing of service flows to data networks. DN 203 may represent various network operator services, Internet access, or third-party services. NY 203 may include or be similar to the application server 130 discussed previously. UPF 202 may interact with SMF224 via the N4 reference point between SMF 224 and UPF 202.
[0113] AUSF 222 may store data for authentication of UE 101 / 102 and handle authentication related functions. AUSF 222 may facilitate a common authentication framework for various access types. AUSF 222 may communicate with AMF 221 via the N12 reference point between AMF 221 and AUSF 222; and may communicate with UDM 227 via the N13 reference point between UDM 227 and AUSF 222. Additionally, AUSF 222 may expose an interface based on Nausf services.
[0114] The AMF 221 may be responsible for registration management (e.g., for registering UE 101 / 102, etc.), connection management, reachability management, mobility management, and legal interception of AMF-related events, as well as access authentication and authorization. The AMF 221 may be a termination point for the N11 reference point between the AMF 221 and the SMF 224. The AMF 221 may provide for the transmission of session management (SM) messages between the UE 101 / 102 and the SMF 224, and act as a transparent proxy for routing SM messages. The AMF 221 may also provide for communication between the UE 101 / 102 and the Short Message Service (SMS) Function (SMSF) ( Figure 2 The AMF 221 may include a security context management (SCM) function, which receives keys from the SEA for deriving access network-specific keys. In addition, the AMF 221 may be a termination point for the RAN CP interface, which may include or may be an N2 reference point between the (R)AN 211 and the AMF 221; and the AMF 221 may be a termination point for NAS (N1) signaling, and perform NAS encryption and integrity protection.
[0115] The AMF 221 may also support NAS signaling with the UE 101 / 102 through the N3 interworking function (IWF) interface. The N3IWF may be used to provide access to untrusted entities. The N3IWF may be the termination point for the N2 interface between the (R)AN 211 and the AMF 221 for the control plane, and may be the termination point for the N3 reference point between the (R)AN 211 and the UPF 202 for the user plane. Thus, the AMF 221 may process N2 signaling from the SMF 224 and the AMF 221 regarding PDU sessions and QoS, encapsulate / decapsulate packets for IPSec and N3 tunnels, mark N3 user plane packets in the uplink, and enforce QoS corresponding to the marking taking into account the QoS requirements associated with the marking of the N3 packets received over N2. The N3IWF may also relay uplink and downlink control plane NAS signaling between the UE 101 / 102 and the AMF 221 via the N1 reference point between the UE 101 / 102 and the AMF 221, and relay uplink and downlink user plane packets between the UE 101 / 102 and the UPF 202. The N3IWF also provides a mechanism for IPsec tunnel establishment with the UE 101 / 102. The AMF 221 may expose an interface based on Namf services and may be an N14 reference point between two AMFs 221 and between the AMF 221 and the 5G-Device Identity Registrar (5G-EIR) ( Figure 2 The termination point of the N17 reference point between the two (not shown).
[0116] UE 101 / 102 may need to register with AMF 221 to receive network services. Registration Management (RM) is used to register or deregister UE 221 with the network (e.g., AMF 221) and establish a UE context in the network (e.g., AMF 221). UE 101 / 102 can operate in the RM-REGISTERED state or the RM-DEREGISTERED state. In the RM-DEREGISTERED state, UE 101 / 102 is not registered with the network, and the UE context in AMF 221 does not save valid location or routing information about UE 101 / 102, so UE 101 / 102 is not reachable by AMF 221. In the RM-REGISTERED state, UE 101 / 102 is registered with the network, and the UE context in AMF 221 can save valid location or routing information about UE 101 / 102, so UE 101 / 102 is reachable by AMF 221. In the RM-REGISTERED state, UE 101 / 102 can perform a mobility registration update procedure, perform a periodic registration update procedure triggered by the expiration of a periodic update timer (for example, to notify the network that UE 101 / 102 is still active), and perform a registration update procedure to update UE capability information or renegotiate protocol parameters with the network, etc.
[0117] AMF 221 may store one or more RM contexts for UE 101 / 102, wherein each RM context is associated with a specific access to the network. The RM context may be a data structure, a database object, or the like that indicates or stores, among other things, the registration status and periodic update timer for each access type. AMF 221 may also store a 5GC MM context that may be the same or similar to the (E)MM context discussed previously. In various embodiments, AMF 221 may store the CE mode B restriction parameters of UE 101 / 102 in an associated MM context or RM context. When necessary, AMF 221 may also derive the value from the UE's usage setting parameters {possible values: "Data Centric", "VoiceCentric"} already stored in the UE context (and / or MM / RM context).
[0118] Connection management (CM) may be used to establish and release a signaling connection between the UE 101 / 102 and the AMF 221 over the N1 interface. The signaling connection is used to enable NAS signaling exchange between the UE 101 / 102 and the CN 120, and includes an AN signaling connection between the UE and the access network (AN) (e.g., an RRC connection or a UE-N3IWF connection for non-3GPP access) and an N2 connection for the UE 101 / 102 between the AN (e.g., RAN 211) and the AMF 221. The UE 101 / 102 may operate in one of two CM states (CM-IDLE mode or CM-CONNECTED mode). When the UE 101 / 102 operates in the CM-IDLE state / mode, the UE 101 / 102 may not have a NAS signaling connection established with the AMF 221 through the N1 interface, and there may be a (R)AN 211 signaling connection (e.g., N2 and / or N3 connection) for the UE 101 / 102. When the UE 101 / 102 operates in the CM-CONNECTED state / mode, the UE 101 / 102 may establish a NAS signaling connection with the AMF 221 through the N1 interface, and there may be a (R)AN 211 signaling connection (e.g., N2 and / or N3 connection) for the UE 101 / 102. Establishing an N2 connection between (R)AN 211 and AMF 221 may enable UE 101 / 102 to transition from CM-IDLE mode to CM-CONNECTED mode, and when N2 signaling between (R)AN 211 and AMF 221 is released, UE 101 / 102 may transition from CM-CONNECTED mode to CM-IDLE mode.
[0119] SMF 224 may be responsible for session management (e.g., session establishment, modification, and release, including tunnel maintenance between UPF and AN nodes); UE IP address allocation & management (including optional authorization); selection and control of UP functions; configuring service steering at UPF to route services to the correct destination; termination of interfaces toward policy control functions; control portion of policy enforcement and QoS; legal interception (for SM events and interface to LI system); termination of the SM portion of NAS messages; downlink data notification; initiator of AN-specific SM information sent to AN via AMF over N2; determining the SSC mode of the session. SMF224 may include the following roaming functions: handling local enforcement to apply QoS SLA (VPLMN); charging data collection and charging interface (VPLMN); legal interception (in VPLMN, for SM events and interface to LI system); supporting interaction with external DNs for signaling for PDU session authorization / authentication via external DNs. An N16 reference point between two SMFs 224 may be included in the system 200, which in a roaming scenario may be between another SMF 224 in a visited network and an SMF 224 in a home network. Additionally, the SMF 224 may expose an Nsmf service based interface.
[0120] NEF 223 can provide a means for 3GPP network functions to safely open the services and capabilities provided by third parties, internal opening / reopening, application functions (e.g., AF 228), edge computing or fog computing systems, etc. In these embodiments, NEF 223 can authenticate, authorize and / or throttle AF. NEF 223 can also translate information exchanged with AF 228 and information exchanged with internal network functions. For example, NEF 223 can translate between AF service identifiers and internal 5GC information. NEF 223 can also receive information from other network functions (NFs) based on the capabilities opened by other network functions. The information can be stored at NEF 223 as structured data, or stored at a data storage NF using a standardized interface. The stored information can then be reopened by NEF 223 to other NFs and AFs, and / or used for other purposes (e.g., analysis). Additionally, NEF 223 can display an interface based on Nnef services.
[0121] NRF 225 may support service discovery functionality, receive NF discovery requests from NF instances, and provide information of discovered NF instances to NF instances. NRF 225 also maintains information of available NF instances and the services they support. As used herein, the terms "instantiate", "instantiate", etc. may refer to the creation of an instance, and "instance" may refer to the specific generation of an object that may be generated, for example, during the execution of a program code. Additionally, NRF 225 may expose an interface based on Nnrf services.
[0122] The PCF 226 may provide policy rules to control plane functions to enforce them, and may also support a unified policy framework to govern network behavior. The PCF 226 may also implement a front end (FE) to access subscription information related to policy decisions in the UDR of the UDM 227. The PCF 226 may communicate with the AMF 221 (which may include the PCF 226 and AMF 221 in the visited network in the case of roaming) via the N15 reference point between the PCF 226 and the AMF 221. The PCF 226 may communicate with the AF 228 via the N5 reference point between the PCF 226 and the AF 228; and communicate with the SMF 224 via the N7 reference point between the PCF 226 and the SMF 224. The system 200 and / or the CN 120 may also include an N24 reference point between the PCF 226 (in the home network) and the PCF 226 in the visited network. Additionally, PCF 226 may expose an interface based on Npcf services.
[0123] The UDM 227 may process subscription-related information to support network entities in handling communication sessions, and may store subscription data for the UE 101 / 102. For example, the subscription data may be transferred between the UDM 227 and the AMF 221 via an N8 reference point between the UDM 227 and the AMF 221 ( Figure 2 The UDM 227 may include two parts: application FE and user data repository (UDR) ( Figure 2FE and UDR are not shown). The UDR may store subscription data and policy data for UDM 227 and PCF 226 and / or structured data for opening and application data for NEF 223 (including packet flow description (PFD) for application detection, application request information for multiple UEs 201). The UDR 221 may expose an interface based on Nudr services to allow the UDM 227, PCF 226, and NEF 223 to access a specific set of stored data, as well as read, update (e.g., add, modify), delete, and subscribe to notifications about data changes in the UDR. The UDM may include a UDM FE, which is responsible for certificate processing, location management, subscription management, etc. Several different front ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR, and performs authentication and certificate processing, user identification processing, access authorization, registration / mobility management, and subscription management. The UDR may interact with the SMF 224 via the N10 reference point between the UDM 227 and the SMF 224. UDM 227 may also support SMS management, where SMS-FE implements similar application logic as described above. Additionally, UDM 227 may expose Nudm service-based interfaces.
[0124] AF 228 can provide application impact on service routing, access to network capability exposure (NCE), and interact with the policy framework for policy control. NCE can be a mechanism that allows 5GC and AF 228 to provide information to each other via NEF 223, which can be used for edge computing implementations. In these implementations, network operators and third-party services can be managed close to UE 101 / 102 access attachment points to achieve efficient service delivery through reduced end-to-end delay and load on the transmission network. For edge computing implementations, 5GC can select UPF 202 close to UE 101 / 102 and perform service steering from UPF 202 to DN 203 via the N6 interface. This operation can be based on UE subscription data, UE location and information provided by AF228. In this way, AF 228 can affect UPF (re) selection and service routing. Based on operator deployment, when AF 228 is considered a trusted entity, the network operator can allow AF 228 to interact directly with the relevant NF. Additionally, AF 228 may expose an interface based on Naf services.
[0125] NSSF 229 may select a set of network slice instances to serve UE 101 / 102. If necessary, NSSF 229 may also determine the allowed network slice selection assistance information (NSSAI) and the mapping to the subscribed single NSSAI (S-NSSAI). NSSF 229 may also determine a set of AMFs or a list of candidate AMFs 221 to be used to serve UE 101 / 102 based on appropriate configuration and possibly by querying NRF 225. The AMF 221 to which UE 101 / 102 is registered may trigger the selection of a set of network slice instances for UE 101 / 102 by interacting with NSSF 229, which may result in a change of AMF 221. NSSF 229 may interact with AMF 221 via the N22 reference point between AMF 221 and NSSF 229; and may communicate with AMF 221 via the N31 reference point ( Figure 2 The NSSF 229 may communicate with another NSSF 229 in the visited network (not shown). Additionally, the NSSF 229 may expose an interface based on the Nnssf service.
[0126] As previously described, CN 120 may include SMSF, which may be responsible for SMS subscription checking and verification, and relaying SM messages to / from UE 101 / 102 to / from other entities (e.g., SMS-GMSC / IWMSC / SMS-Router). SMS may also interact with AMF 221 and UDM 227 for notification procedures: UE 101 / 102 is available for SMS delivery (e.g., setting a UE unreachable flag, and notifying UDM 227 when UE 101 / 102 is available for SMS).
[0127] CN 120 may also include Figure 2 Other elements not shown (e.g., data storage system / architecture, 5G-Equipment ID Identity Register (5G-EIR), Security Edge Protection Proxy (SEPP), etc.) The data storage system may include a structured data storage network function (SDSF), an unstructured data storage network function (UDSF), etc. Any NF may communicate with the UDSF via the N18 reference point ( Figure 2 The UDSF may be used to store / retrieve unstructured data (e.g., UE context) in / from the UDSF (not shown). Individual NFs may share a UDSF for storing their respective unstructured data, or the individual NFs may each have their own UDSF located at or near the individual NF. Additionally, the UDSF may expose an interface based on Nudsf services ( Figure 2(not shown). The 5G-EIR may be a NF that checks the status of a Permanent Equipment Identifier (PEI) for determining whether a specific device / entity is blacklisted from the network; and the SEPP may be a non-transparent proxy that performs topology hiding, message filtering, and policing on the inter-PLMN control plane interface.
[0128] Additionally, there may be many more reference points and / or service-based interfaces between NF services in a NF; however, for clarity, Figure 2 These interfaces and reference points are omitted. In one example, CN 120 may include an Nx interface, which is an inter-CN interface between an MME (e.g., MME 121) and AMF 221 to enable intercommunication between CN 120 and CN 120. Other example interfaces / reference points may include an interface based on N5g-eir services presented by 5G-EIR, an N27 reference point between an NRF in a visited network and an NRF in a home network; and an N31 reference point between an NSSF in a visited network and an NSSF in a home network.
[0129] Figure 3 An example of an infrastructure device 300 according to various embodiments is shown. The infrastructure device 300 (or "system 300") can be implemented as a base station, a radio head, a RAN node, etc. (e.g., the RAN nodes 111 and 112 and / or the AP 106 shown and described previously). In other examples, the system 300 can be implemented in a UE or a core network node / entity (e.g., as described with respect to FIG. 1- Figure 2 300 may include one or more of the following: application circuitry 305, baseband circuitry 304, one or more radio front-end modules 315, memory 320, power management integrated circuit (PMIC) 325, power connector circuitry 330, network controller 335, network interface connector 340, satellite positioning circuitry 345, and user interface 350. In some embodiments, device 400 may include additional elements (e.g., memory / storage, display, camera, sensor, or input / output (I / O) interface). In other embodiments, the components described below may be included in more than one device (e.g., for Cloud-RAN (C-RAN) implementations, the circuitry may be separately included in more than one device).
[0130] As used herein, the term "circuit" may refer to, be part of, or include hardware components (e.g., electronic circuits, logic circuits, processors (shared, dedicated, or group) and / or memories (shared, dedicated, or group), 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 systems on chip (SoCs)), digital signal processors (DSPs), etc.) configured to provide the described functions. In some embodiments, the circuit may execute one or more software or firmware programs to provide at least some of the described functions. Additionally, the term "circuit" may also refer to a combination of one or more hardware elements and a program code for executing the functions of the program code (or a combination of circuits used in an electrical or electronic system). In these embodiments, the combination of hardware elements and program code may be referred to as a specific type of circuit.
[0131] The terms "application circuit" and / or "baseband circuit" may be considered synonymous with "processor circuit" and may be referred to as "processor circuit". As used herein, the term "processor circuit" may refer to, be part of, or include a circuit that is capable of sequentially and automatically performing a series of arithmetic or logical operations, recording, storing and / or transmitting digital data. The term "processor circuit" may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and / or any other device capable of executing or otherwise operating computer-executable instructions (e.g., program code, software modules and / or functional processes).
[0132] The application circuit 305 may include one or more central processing unit (CPU) cores and one or more of the following: cache memory, a low dropout voltage regulator (LDO), an interrupt controller, a serial interface (e.g., SPI, I 2 C or general programmable serial interface module), a real-time clock (RTC), a timer-counter including an interval and watchdog timer, a general input / output (I / O or IO), a memory card controller (e.g., a secure digital (SD / ) multimedia card (MMC) or the like), a universal serial bus (USB) interface, a mobile industry processor interface (MIPI) interface, and a joint test access group (JTAG) test access port. As an example, the application circuit 305 may include one or more Intel or Processor: Advanced Micro Devices (AMD) Processor, Accelerated Processing Unit (APU) or processor; etc. In some embodiments, for example, system 300 may not utilize application circuit 305, but may include a dedicated processor / controller to process IP data received from the EPC or 5GC.
[0133] Additionally or alternatively, the application circuit 305 may include circuits such as, but not limited to, the following: one or more field programmable devices (FPDs) (e.g., field programmable gate arrays (FPGAs), etc.); programmable logic devices (PLDs) (e.g., complex PLDs (CPLDs), high capacity PLDs (HCPLDs), etc.); ASICs (e.g., structured ASICs, etc.); programmable SoCs (PSoCs); etc. In these embodiments, the circuits of the application circuit 305 may include logic blocks or logic arrangements containing and other interconnected resources that can be programmed to perform various functions (e.g., the processes, methods, functions, etc. of the various embodiments discussed herein). In these embodiments, the circuits of the application circuit 305 may include memory cells (e.g., erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), flash memories, static memories (e.g., static random access memories (SRAMs), antifuses, etc.)) for storing logic blocks, logic arrangements, data, etc. in lookup tables (LUTs), etc.
[0134] The baseband circuit 304 can be implemented as, for example, a soldered substrate including one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module containing two or more integrated circuits. Although not shown, the baseband circuit 304 may include one or more digital baseband systems, which may be coupled to the CPU subsystem, the audio subsystem, and the interface subsystem via an interconnect subsystem. The digital baseband subsystem may also be coupled to a digital baseband interface and a mixed signal baseband subsystem via other interconnect subsystems. Each of the interconnect subsystems may include a bus system, a point-to-point connection, a network on a core (NOC) structure, and / or some other suitable bus or interconnect technology (such as those discussed herein). The audio subsystem may include a digital signal processing circuit, a buffer memory, a program memory, a voice processing accelerator circuit, a data converter circuit (such as an analog-to-digital converter and a digital-to-analog converter circuit), an analog circuit including one or more amplifiers and filters, and / or other similar components. In one aspect of the present disclosure, the baseband circuit 304 may include a protocol processing circuit having one or more instances of a control circuit (not shown) to provide control functions for a digital baseband circuit and / or a radio frequency circuit (e.g., a radio front end module 315).
[0135] The user interface circuit 350 may include one or more user interfaces designed to enable user interaction with the system 300 or peripheral component interfaces designed to enable interaction with peripheral components of the system 300. The user interface may include, but is not limited to, one or more physical or virtual buttons (e.g., a reset button), one or more indicators (e.g., light emitting diodes (LEDs)), a physical keyboard or keypad, a mouse, a touch pad, a touch screen, a speaker or other audio transmitting device, a microphone, a printer, a scanner, a headset, a display screen or display device, etc. The peripheral component interface may include, but is not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power interface, etc.
[0136] The wireless front end module (RFEM) 315 may include a millimeter wave RFEM and one or more sub-millimeter wave radio frequency integrated circuits (RFICs). In some implementations, the one or more sub-millimeter wave RFICs may be physically separated from the millimeter wave RFEM. The RFIC may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In an alternative implementation, the millimeter wave and sub-millimeter wave radio functions may be implemented in the same physical radio front end module 315. The RFEM 315 may include both millimeter wave antennas and sub-millimeter wave antennas.
[0137] The memory circuit 320 may include one or more of a volatile memory (including a dynamic random access memory (DRAM) and / or a synchronous dynamic random access memory (SDRAM)) and a non-volatile memory (NVM) (including a high-speed electrically erasable memory (commonly referred to as a flash memory), a phase change random access memory (PRAM), a magnetoresistive random access memory (MRAM), etc.), and may include a plurality of memory elements from the memory circuit 320. and The memory circuit 320 may be implemented as one or more of a solder packaged integrated circuit, a socketed memory module, and a plug-in memory card.
[0138] The PMIC 325 may include a voltage regulator, a surge protector, a power alarm detection circuit, and one or more backup power sources (e.g., a battery or capacitor). The power alarm detection circuit may detect one or more of a brownout (undervoltage) and a surge (overvoltage) condition. The power tap circuit 330 may provide electrical power drawn from a network cable to provide both power and data connectivity to the infrastructure device 300 using a single cable.
[0139] The network controller circuitry 335 may provide connectivity to a network using a standard network interface protocol (e.g., Ethernet, Ethernet over a GRE tunnel, Multi-Protocol Label Switching (MPLS), or some other suitable protocol). Network connectivity may be provided to / from the infrastructure device 300 via the network interface connector 340 using a physical connection that may be electrical (commonly referred to as a "copper interconnect"), optical, or wireless. The network controller circuitry 335 may include one or more dedicated processors and / or FPGAs to communicate using one or more of the above-described protocols. In some implementations, the network controller circuitry 335 may include multiple controllers to provide connectivity to other networks using the same or different protocols.
[0140] Positioning circuit 345, which may include circuits for receiving and decoding signals sent by one or more navigation satellite constellations of a global navigation satellite system (GNSS). Examples of navigation satellite constellations (or GNSS) may include the United States' Global Positioning System (GPS), Russia's Global Navigation System (GLONASS), the European Union's Galileo system, China's Beidou Navigation Satellite System, regional navigation systems or GNSS augmentation systems (e.g., Indian Constellation Navigation (NAVIC), Japan's Quasi-Zenith Satellite System (QZSS), France's Doppler Orbit Radio Positioning (DORIS), etc.), etc. Positioning circuit 345 may include various hardware elements (e.g., including hardware devices (e.g., switches, filters, amplifiers, antenna elements, etc.) to facilitate communication over the air (OTA) communication) to communicate with components of a positioning network (e.g., navigation satellite constellation nodes).
[0141] A node or satellite of a navigation satellite constellation ("GNSS node") may provide positioning services by continuously transmitting or broadcasting GNSS signals along a line of sight, which may be used by a GNSS receiver (e.g., a positioning circuit implemented by positioning circuitry 345 and / or UE 101, 102, etc.) to determine their GNSS position. The GNSS signal may include a pseudo-random code (e.g., a sequence of 1s and 0s) known to the GNSS receiver and a message including a transmission time (ToT) of a code epoch (e.g., a defined point in a pseudo-random code sequence) and the position of the GNSS node at the ToT. The GNSS receiver may monitor / measure GNSS signals transmitted / broadcasted by multiple GNSS nodes (e.g., four or more satellites) and solve various equations to determine the corresponding GNSS position (e.g., spatial coordinates). The GNSS receiver also implements a clock that is typically less stable and less accurate than the atomic clock of the GNSS node, and the GNSS receiver may use the measured GNSS signal to determine the deviation of the GNSS receiver from the true time (e.g., the offset of the GNSS receiver clock relative to the GNSS node time). In some embodiments, the positioning circuit 345 may include a Micro-Technology for Positioning, Navigation, and Timing (Micro-PNT) IC that uses a master timing clock to perform position tracking / estimation without GNSS assistance.
[0142] The GNSS receiver can measure the time of arrival (ToA) of GNSS signals from multiple GNSS nodes based on its own clock. The GNSS receiver can determine the ToF value for each received GNSS signal from the ToA and ToT, and can then determine the three-dimensional (3D) position and clock bias from the ToF. The 3D position can then be converted to latitude, longitude, and altitude. The positioning circuit 345 can provide data to the application circuit 305, which may include one or more of position data or time data. The application circuit 305 can use the time data to synchronize operations with other wireless base stations (e.g., RAN nodes 111, 112, 211, etc.).
[0143] Figure 3The components shown can communicate with other components using interface circuits. As used herein, the term "interface circuit" may refer to, be part of, or include an exchange circuit for providing information between two or more components or devices. The term "interface circuit" may refer to one or more hardware interfaces (e.g., a bus, an input / output (I / O) interface, a peripheral component interface, a network interface card, etc.). Any suitable bus technology may be used in various implementations, which may include any number of technologies, including Industry Standard Architecture (ISA), Extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI Express (PCIe), or any number of other technologies. The bus may be, for example, a proprietary bus used in a SoC-based system. Other bus systems (e.g., I 2 C interface, SPI interface, point-to-point interface and power bus, etc.).
[0144] Figure 4 An example of a platform 400 (or "device 400") according to various embodiments is shown. In an embodiment, the computer platform 400 may be suitable for use as a UE 101, 102, 201, an application server 130, and / or any other element / device discussed herein. The platform 400 may include any combination of components shown in the example. The components of the platform 400 may be implemented as an integrated circuit (IC), a portion thereof, a discrete electronic device, or other modules, logic, hardware, software, firmware, or a combination thereof adapted in the computer platform 400, or as other components incorporated within the chassis of a larger system. Figure 4 The block diagram is intended to illustrate a high-level view of the components of computer platform 400. However, in other implementations, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur.
[0145] The application circuit 405 may include the following circuits, such as but not limited to: a single-core or multi-core processor and a cache memory, a low dropout regulator (LDO), an interrupt controller, a serial interface (such as a serial peripheral interface (SPI)), an integrated circuit bus (IC bus), and a plurality of other circuits. 2C) or general programmable serial interface circuit, real-time clock (RTC), timer counter (including interval and watchdog timer), general input output (IO), memory card controller (e.g., secure digital / multimedia card (SD / MMC)), universal serial bus (USB) interface, mobile industry processor interface (MIPI) interface and joint test access group (JTAG) test access port. One or more of the test access port. The processor may include any combination of general-purpose processors and / or special-purpose processors (e.g., graphics processors, application processors, etc.). The processor (or core) may be coupled to or may include memory / storage and may be configured to execute instructions stored in memory / storage to enable various applications or operating systems to run on the platform 400. In some embodiments, the processor of the application circuit 305 / 405 may process IP data packets received from the EPC or 5GC.
[0146] The application circuit 405 is or includes a microprocessor, a multi-core processor, a multi-threaded processor, an ultra-low voltage processor, an embedded processor, or other known processing elements. In one example, the application circuit 405 may include a processor based on Architecture Core TM Processors such as Quark TM 、Atom TM , i3, i5, i7 or MCU-class processors, or can be obtained from Another such processor is available from Intel Corporation, Santa Clara, CA. The processor of application circuit 405 may also be one or more of the following: Advanced Micro Devices (AMD) Processor or Accelerated Processing Unit (APU); Inc.’s A5-A9 processors; Snapdragon by Technologies, Inc. TM Processor; Texas Instruments, Open Multimedia Application Platform (OMAP) TM processor; MIPS-based designs from MIPS Technologies, Inc.; ARM-based designs licensed from ARM Holdings, Ltd.; etc. In some implementations, application circuit 405 may be part of a system on a chip (SoC), where application circuit 405 and other components are formed as a single integrated circuit or a single package, such as Edison Corporation TM or Galileo TM SoC board.
[0147] Additionally or alternatively, the application circuit 405 may include the following circuits, such as, but not limited to, one or more of the following: a field programmable device (FPD) such as an FPGA; a programmable logic device (PLD) such as a complex PLD (CPLD), a high capacity PLD (HCPLD); an ASIC such as a structured ASIC; a programmable SoC (PSoC); etc. In such an embodiment, the circuits of the application circuit 405 may include logic blocks or logic structures including other interconnected resources, which may be programmed to perform various functions, such as the processes, methods, functions, etc. of the various embodiments discussed herein. In such an embodiment, the circuits of the application circuit 405 may include memory cells (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), anti-fuse, etc.)) for storing logic blocks, logic structures, data, etc. in a lookup table (LUT) or the like.
[0148] The baseband circuit 404 can be implemented as, for example, a solder-in substrate including one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module containing two or more integrated circuits. Although not shown, the baseband circuit 404 can include one or more digital baseband systems, which can be coupled to the CPU subsystem, the audio subsystem, and the interface subsystem via an interconnect subsystem. The digital baseband subsystem can also be coupled to the digital baseband interface and the mixed signal baseband subsystem via another interconnect subsystem. Each interconnect subsystem can include a bus system, a point-to-point connection, a network on chip (NOC) structure, and / or some other suitable bus or interconnect technology, such as those discussed herein. The audio subsystem can include a digital signal processing circuit, a buffer memory, a program memory, a voice processing accelerator circuit, a data converter circuit such as an analog-to-digital converter and a digital-to-analog converter circuit, an analog circuit including one or more of an amplifier and a filter, and / or other similar components. In one aspect of the present disclosure, the baseband circuit 404 can include a protocol processing circuit with one or more instances of a control circuit (not shown) to provide control functions for a digital baseband circuit and / or a radio frequency circuit (e.g., a radio front-end module 415).
[0149] The radio front end module (RFEM) 415 may include a millimeter wave RFEM and one or more sub-millimeter wave radio frequency integrated circuits (RFICs). In some implementations, the one or more sub-millimeter wave RFICs may be physically separated from the millimeter wave RFEM. The RFIC may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In alternative implementations, both millimeter wave and sub-millimeter wave radio functions may be implemented in the same physical radio front end module 415. The RFEM 415 may incorporate both millimeter wave antennas and sub-millimeter wave antennas.
[0150] The memory circuit 420 may include any number and type of memory devices for providing a quantitative system memory. As an example, the memory circuit 420 may include one or more of the following: volatile memory, including random access memory (RAM), dynamic RAM (DRAM) and / or synchronous dynamic RAM (SDRAM); and non-volatile memory (NVM), including high-speed electrically erasable memory (commonly referred to as flash memory), phase change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc. The memory circuit 420 may be developed according to the design based on low power double data rate (LPDDR) of the Joint Electron Device Engineering Council (JEDEC), such as LPDDR2, LPDDR3, LPDDR4, etc. The memory circuit 320 may be implemented as one or more of the following: an integrated circuit in a solder-in package, a single die package (SDP), a dual die package (DDP) or a quad die package (Q17P), a socket memory module, a dual in-line memory module (DIMM) (including microDIMM or MiniDIMM), and / or soldered to a motherboard via a ball grid array (BGA). In a low-power implementation, the storage 108 of the memory circuit 420 may be on-die memory or registers associated with the application circuit 405. To provide persistent storage of information such as data, applications, operating systems, etc., the memory circuit 420 may include one or more mass storage devices, which may include a solid-state disk drive (SSDD), a hard disk drive (HDD), a micro HDD, a resistive memory, a phase change memory, a holographic memory, or a chemical memory, etc. For example, the computer platform 400 may incorporate and Three-dimensional (3D) cross-point (XPOINT) memory.
[0151] Removable memory circuitry 423 may include devices, circuits, housings / casings, ports or receptacles, etc., for coupling portable data storage devices to platform 400. These portable data storage devices may be used for mass storage purposes and may include, for example, flash memory cards (e.g., Secure Digital (SD) cards, microSD cards, xD graphics cards, etc.) as well as USB flash drives, optical disks, external HDDs, etc.
[0152] The platform 400 may also include an interface circuit (not shown) for connecting an external device to the platform 400. The external device connected to the platform 400 via the interface circuit may include a sensor 421, such as an accelerometer, a level sensor, a flow sensor, a temperature sensor, a pressure sensor, a barometric pressure sensor, etc. The interface circuit may be used to connect the platform 400 to an electromechanical component (EMC) 422, which may allow the platform 400 to change its state, position, and / or orientation, or to move or control a mechanism or system. The EMC 422 may include one or more power switches, relays (including electromechanical relays (EMRs) and / or solid-state relays (SSRs)), actuators (e.g., valve actuators, etc.), audible sound generators, visual warning devices, motors (e.g., DC motors, stepper motors, etc.), wheels, thrusters, propellers, claws, clamps, hooks, and / or other similar electromechanical components. In an embodiment, the platform 400 may be configured to operate one or more EMCs 422 based on one or more captured events and / or instructions or control signals received from a service provider and / or various clients.
[0153] In some implementations, the interface circuit can connect the platform 400 to the positioning circuit 445, which can communicate with the relevant Figure 3 The positioning circuit 445 discussed is the same or similar.
[0154] In some implementations, the interface circuit can connect the platform 400 with a near field communication (NFC) circuit 440, which can include an NFC controller coupled with an antenna element and a processing device. The NFC circuit 440 can be configured to read an electronic tag and / or connect with another NFC-enabled device.
[0155] Driver circuitry 446 may include software and hardware elements that operate to control specific devices embedded in, attached to, or communicatively coupled to platform 400. Driver circuitry 446 may include various drivers that allow other components of platform 400 to interact or control various input / output (I / O) devices that may be present within or connected to platform 400. For example, driver circuitry 446 may include: a display driver for controlling and allowing access to a display device; a touch screen driver for controlling and allowing access to a touch screen interface of platform 400; a sensor driver for obtaining sensor readings of sensor 421 and controlling and allowing access to sensor 421; an EMC driver for obtaining actuator positions of EMC 422 and / or controlling and allowing access to EMC 422; 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.
[0156] A power management integrated circuit (PMIC) 425 (also referred to as "power management circuit 425," etc.) can manage power provided to various components of the platform 400. In particular, with respect to the baseband circuit 404, the PMIC 425 can control power selection, voltage scaling, battery charging, or DC-DC conversion. When the platform 400 is capable of being powered by a battery 430, such as when the device is included in a UE 101, 102, 201, a PMIC 425 can often be included.
[0157] In some embodiments, the PMIC 425 may control or be part of various power saving mechanisms of the platform 400. For example, if the platform 400 is in the RRC_Connected state (in which it is still connected to the RAN node because it expects to receive traffic soon), it may enter a state called discontinuous reception mode (DRX) after a period of inactivity. During this state, the platform 400 may be powered off for a brief time interval, thereby saving power. If there is no data traffic activity for an extended period of time, the platform 400 may transition to the RRC_Idle state, in which it is disconnected from the network and does not perform operations such as channel quality feedback, switching, etc. The platform 400 enters a very low power state and it performs paging, in which it wakes up again periodically to listen to the network and then powers off again. The platform 400 cannot receive data in this state, and in order to receive data, it must transition back to the RRC_Connected state. Additional power saving modes may allow the device to be unavailable to the network for a period longer than the paging interval (ranging from a few seconds to a few hours). During this time, the device is completely unavailable to the network and may be completely powered off. Any data sent during this time will incur significant latency, and it is assumed that this latency is acceptable.
[0158] The battery 430 can power the platform 400, but in some examples, the platform 400 can be installed and deployed in a fixed location and can have a power source coupled to the power grid. The battery 430 can be a lithium-ion battery, a metal-air battery (e.g., a zinc-air battery, an aluminum-air battery, a lithium-air battery), etc. In some implementations, such as in V2X applications, the battery 430 can be a typical lead-acid car battery.
[0159] In some implementations, the battery 430 may be a "smart battery" that includes, or is coupled to, a battery management system (BMS) or a battery monitoring integrated circuit. The BMS may be included in the platform 400 to track the state of charge (SoCh) of the battery 430. The BMS may be used to monitor other parameters of the battery 430 to provide fault predictions, such as the state of health (SoH) and state of function (SoF) of the battery 430. The BMS may communicate information about the battery 430 to the application circuit 405 or other components of the platform 400. The BMS may also include an analog-to-digital (ADC) converter that allows the application circuit 405 to directly monitor the voltage of the battery 430 or the current from the battery 430. The battery parameters may be used to determine actions that the platform 400 may perform, such as transmission frequency, network operation, sensing frequency, and the like.
[0160] A power block or other power source coupled to the grid can be coupled to the BMS to charge the battery 430. In some examples, the power block 128 can be replaced with a wireless power receiver to obtain power wirelessly, for example, through a loop antenna in the computer platform 400. In these examples, a wireless battery charging circuit can be included in the BMS. The specific charging circuit selected can depend on the size of the battery 430 and therefore the current required. Charging can be performed using the Airfuel standard promulgated by the Airfuel Alliance, the Qi wireless charging standard promulgated by the Wireless Power Consortium, or the Rezence charging standard promulgated by the Alliance for Wireless Power, etc.
[0161] Although not shown, the components of platform 400 can communicate with each other using a suitable bus technology, which can include any number of technologies, including Industry Standard Architecture (ISA), Extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI Express (PCIe), Time Triggered Protocol (TTP) system or FlexRay system, or any number of other technologies. The bus can be a dedicated bus used in SoC-based systems, for example. Other bus systems, such as I 2C interface, SPI interface, point-to-point interface and power bus, etc.
[0162] Figure 5 Example components of baseband circuitry 304 / 404 and radio frequency front end module (RFEM) 315 / 415 are shown in accordance with some embodiments. As shown, RFEM 315 / 415 may include radio frequency (RF) circuitry 506, front end module (FEM) circuitry 508, one or more antennas 510, coupled together at least as shown.
[0163] The baseband circuit 304 / 404 may include circuits such as, but not limited to, one or more single-core or multi-core processors. The baseband circuit 304 / 404 may include one or more baseband processors or control logic to process baseband signals received from the receive signal path of the RF circuit 506 and generate baseband signals for the transmit signal path of the RF circuit 506. The baseband circuit 304 / 404 may interface with the application circuit 305 / 405 to generate and process baseband signals and control the operation of the RF circuit 506. For example, in some embodiments, the baseband circuit 304 / 404 may include a third generation (3G) baseband processor 504A, a fourth generation (4G) baseband processor 504B, a fifth generation (5G) baseband processor 504C, or other baseband processors 504D for other existing generations, generations under development, or generations to be developed in the future (e.g., second generation (2G), sixth generation (6G), etc.). The baseband circuitry 304 / 404 (e.g., one or more of the baseband processors 504A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 506. In other embodiments, some or all of the functions of the baseband processors 504A-D may be included in a module stored in the memory 504G and executed via the central processing unit (CPU) 504E. The radio control functions may include, but are not limited to, signal modulation / demodulation, encoding / decoding, radio frequency shifting, etc. In some embodiments, the modulation / demodulation circuitry of the baseband circuitry 304 / 404 may include fast Fourier transform (FFT), precoding, or constellation mapping / demapping functions. In some embodiments, the encoding / decoding circuitry of the baseband circuitry 304 / 404 may include convolution, tail-biting convolution, turbo, Viterbi, or low-density parity check (LDPC) encoder / decoder functions. The embodiments of the modulation / demodulation and encoder / decoder functions are not limited to these examples, and may include other suitable functions in other embodiments.
[0164] In some embodiments, the baseband circuit 304 / 404 may include one or more audio digital signal processors (DSPs) 504F. The audio DSP 504F may include elements for compression / decompression and echo cancellation, and may include other suitable processing elements in other embodiments. In some embodiments, the components of the baseband circuit may be suitably combined in a single chip, a single chipset, or arranged on the same circuit board. In some embodiments, some or all of the constituent components of the baseband circuit 304 / 404 and the application circuit 305 / 405 may be implemented together, for example, on a system on a chip (SOC).
[0165] In some embodiments, the baseband circuitry 304 / 404 may provide communications compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 304 / 404 may support communications with an Evolved Universal Terrestrial Radio Access Network (EUTRAN) or other wireless metropolitan area network (WMAN), wireless local area network (WLAN), or wireless personal area network (WPAN). Embodiments in which the baseband circuitry 304 / 404 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.
[0166] The RF circuit 506 may enable communication with a wireless network using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuit 506 may include switches, filters, amplifiers, etc. to facilitate communication with a wireless network. The RF circuit 506 may include a receive signal path, which may include circuits for down-converting RF signals received from the FEM circuit 508 and providing baseband signals to the baseband circuit 304 / 404. The RF circuit 506 may also include a transmit signal path, which may include circuits for up-converting baseband signals provided by the baseband circuit 304 / 404 and providing RF output signals to the FEM circuit 508 for transmission.
[0167] In some embodiments, the receive signal path of the RF circuit 506 may include a mixer circuit 506a, an amplifier circuit 506b, and a filter circuit 506c. In some embodiments, the transmit signal path of the RF circuit 506 may include a filter circuit 506c and the mixer circuit 506a. The RF circuit 506 may also include a synthesizer circuit 506d for synthesizing the frequencies used by the mixer circuit 506a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuit 506a of the receive signal path may be configured to down-convert the RF signal received from the FEM circuit 508 based on the synthesized frequency provided by the synthesizer circuit 506d. The amplifier circuit 506b may be configured to amplify the down-converted signal, and the filter circuit 506c may be a low pass filter (LPF) or a band pass filter (BPF) configured to remove unwanted signals from the down-converted signal to generate an output baseband signal. The output baseband signal may be provided to the baseband circuit 304 / 404 for further processing. In some embodiments, the output baseband signal may be a zero frequency baseband signal, but this is not a requirement. In some embodiments, the mixer circuit 506a of the receive signal path may include a passive mixer, but the scope of the embodiments is not limited in this regard.
[0168] In some embodiments, mixer circuit 506a of the transmit signal path may be configured to up-convert an input baseband signal based on a synthesized frequency provided by synthesizer circuit 506d to generate an RF output signal for FEM circuit 508. The baseband signal may be provided by baseband circuit 304 / 404 and may be filtered by filter circuit 506c.
[0169] In some embodiments, the mixer circuit 506a of the receive signal path and the mixer circuit 506a of the transmit signal path may include two or more mixers and may be arranged for orthogonal down-conversion and up-conversion, respectively. In some embodiments, the mixer circuit 506a of the receive signal path and the mixer circuit 506a of the transmit signal path may include two or more mixers and may be arranged for image suppression (e.g., Hartley image suppression). In some embodiments, the mixer circuit 506a of the receive signal path and the mixer circuit 506a of the transmit signal path may be arranged for direct down-conversion and direct up-conversion, respectively. In some embodiments, the mixer circuit 506a of the receive signal path and the mixer circuit 506a of the transmit signal path may be configured for superheterodyne operation.
[0170] In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, but the scope of the embodiments is not limited thereto. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, the RF circuit 506 may include an analog-to-digital converter (ADC) and a digital-to-analog converter (DAC) circuit, and the baseband circuit 304 / 404 may include a digital baseband interface to communicate with the RF circuit 506.
[0171] In some dual-mode embodiments, separate radio IC circuits may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this regard.
[0172] In some embodiments, synthesizer circuit 506d may be a fractional-N synthesizer or a fractional-N / N+1 synthesizer, but the scope of the embodiments is not limited in this regard, as other types of frequency synthesizers may be suitable. For example, synthesizer circuit 506d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase-locked loop with a frequency divider.
[0173] Synthesizer circuit 506d may be configured to synthesize an output frequency based on the frequency input and the divider control input for use by mixer circuit 506a of RF circuit 506. In some embodiments, synthesizer circuit 506d may be a fractional-N / N+1 synthesizer.
[0174] In some embodiments, the frequency input may be provided by a voltage controlled oscillator (VCO), but this is not a requirement. The divider control input may be provided by the baseband circuitry 304 / 404 or the application processor 305 / 405 according to the desired output frequency. In some embodiments, the divider control input (e.g., N) may be determined from a lookup table based on the channel indicated by the application processor 305 / 405.
[0175] The synthesizer circuit 506d of the RF circuit 506 may include a divider, a delay locked loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the divider may be a dual-mode divider (DMD), and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by N or N+1 (e.g., based on a carry) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded tunable delay elements, a phase detector, a charge pump, and a D-type flip-flop. In these embodiments, the delay element may be configured to decompose the VCO cycle into Nd equal phase groups, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.
[0176] In some embodiments, the synthesizer circuit 506d can be configured to generate a carrier frequency as an output frequency, while in other embodiments, the output frequency can be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with the quadrature generator and divider circuits to generate multiple signals with multiple different phases relative to each other at the carrier frequency. In some embodiments, the output frequency can be an LO frequency (fLO). In some embodiments, the RF circuit 506 can include an IQ / polar converter.
[0177] The FEM circuitry 508 may include a receive signal path, which may include circuitry configured to operate on RF signals received from one or more antennas 510, amplify the received signals, and provide an amplified version of the received signals to the RF circuitry 506 for further processing. The FEM circuitry 508 may also include a transmit signal path, which may include circuitry configured to amplify signals provided by the RF circuitry 506 for transmission by one or more of the one or more antennas 510. In various embodiments, amplification by the transmit signal path or the receive signal path may be accomplished only in the RF circuitry 506, only in the FEM 508, or in both the RF circuitry 506 and the FEM 508.
[0178] In some embodiments, the FEM circuit 508 may include a TX / RX switch to switch between transmit mode and receive mode operation. The FEM circuit may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuit may include an LNA for amplifying a received RF signal and providing the amplified received RF signal as an output (e.g., to the RF circuit 506). The transmit signal path of the FEM circuit 508 may include: a power amplifier (PA) for amplifying an input RF signal (e.g., provided by the RF circuit 506); and one or more filters for generating an RF signal for subsequent transmission (e.g., by one or more of the one or more antennas 510).
[0179] The processors of the application circuits 305 / 405 and the processors of the baseband circuits 304 / 404 can be used to execute elements of one or more instances of the protocol stack. For example, the processors of the baseband circuits 304 / 404 (alone or in combination) can be used to perform layer 3, layer 2, or layer 1 functions, and the processors of the baseband circuits 304 / 404 can utilize data received from these layers (e.g., packet data) and further perform layer 4 functions (e.g., transport communication protocol (TCP) and user datagram protocol (UDP) layers). As mentioned herein, layer 3 may include a radio resource control (RRC) layer, which will be described in further detail below. As mentioned herein, layer 2 may include a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, which will be described in further detail below. As mentioned herein, layer 1 may include a physical (PHY) layer of a UE / RAN node, which will be described in further detail below.
[0180] Figure 6 1 shows an example interface of a baseband circuit according to some embodiments. As discussed above, Figure 3-4 The baseband circuit 304 / 404 may include processors 504A-504E and a memory 504G used by the processors. Each of the processors 504A-504E may include a memory interface 604A-604E, respectively, to send / receive data to / from the memory 504G.
[0181] The baseband circuit 304 / 404 may also include one or more interfaces for communicatively coupling to other circuits / devices, such as a memory interface 612 (e.g., an interface for sending / receiving data to / from a memory external to the baseband circuit 304 / 404), an application circuit interface 614 (e.g., an interface for sending / receiving data to / from a memory external to the baseband circuit 304 / 404), and an application circuit interface 615 (e.g., an interface for sending / receiving data to / from a memory external to the baseband circuit 304 / 404). Figure 3-4 an interface for sending / receiving data to / from the application circuit 305 / 405), an RF circuit interface 616 (for example, an interface for sending / receiving data to / from the application circuit 305 / 405); Figure 5 an interface for sending / receiving data to / from the RF circuit 506), a wireless hardware connection interface 618 (e.g., for sending / receiving data to / from a near field communication (NFC) component, Components (e.g., low power ), components and other communication components to send / receive data) and a power management interface 620 (eg, an interface for sending / receiving power or control signals to / from the PMIC 425).
[0182] Figure 7 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and executing any one or more of the methods discussed herein, according to some example embodiments. Specifically, Figure 7 A graphical representation of hardware resources 700 is shown, including one or more processors (or processor cores) 710, one or more memory / storage devices 720, and one or more communication resources 730, each of which may be communicatively coupled via a bus 740. As used herein, the terms "computing resources," "hardware resources," and the like may refer to physical or virtual devices, physical or virtual components within a computing environment, and / or physical or virtual components within a particular device, such as computer equipment, mechanical equipment, storage space, processor / CPU time and / or processor / CPU usage, processor and accelerator load, hardware time or usage, power, input / output operations, ports or network slots, channel / link allocation, throughput, memory usage, storage, network, database, and applications, etc. For embodiments utilizing node virtualization (e.g., NFV), a hypervisor 702 may be executed to provide an execution environment for one or more network slices / subslices to utilize hardware resources 700. "Virtualized resources" may refer to computing, storage, and / or network resources provided by a virtualization infrastructure to applications, devices, systems, and the like.
[0183] Processor 710 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP), such as a baseband processor, an application specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 712 and processor 714.
[0184] The memory / storage device 720 may include main memory, disk storage, or any suitable combination thereof. The memory / storage device 720 may include, but is not limited to, any type of volatile or non-volatile memory, such as 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 storage, etc.
[0185] The communication resources 730 may include an interconnect or network interface component or other suitable device to communicate with one or more peripheral devices 704 or one or more databases 706 via the network 708. For example, the communication resources 730 may include a wired communication component (e.g., for coupling via a universal serial bus (USB)), a cellular communication component, an NFC component, Components (e.g., low power ), components and other communication components. As used herein, the term "network resource" or "communication resource" may refer to a computing resource accessible to a computer device via a communication network. The term "system resource" may refer to any type of shared entity used to provide a service, and may include computing and / or network resources. System resources may be considered to be a set of coherent functions, network data objects, or services that are accessible through a server, where such system resources reside on a single host or multiple hosts and are clearly identifiable.
[0186] The instructions 750 may include software, programs, applications, applet programs, apps, or other executable code for causing at least any processor 710 to perform any one or more of the methods discussed herein. The instructions 750 may reside in whole or in part in at least one of the processor 710 (e.g., in a cache of the processor), the memory / storage device 720, or any suitable combination thereof. In addition, any portion of the instructions 750 may be transmitted to the hardware resources 700 from any combination of the peripheral device 704 or the database 706. Therefore, the memory of the processor 710, the memory / storage device 720, the peripheral device 704, and the database 706 are examples of computer-readable and machine-readable media.
[0187] Figure 8 Various protocol functions that can be implemented in a wireless communication device according to various embodiments are shown. In particular, Figure 8 The following is an arrangement 800 showing the interconnections between various protocol layers / entities. Figure 8 Descriptions are provided for various protocol layers / entities operating in conjunction with fifth generation (5G) or new radio (NR) system standards, but Figure 8 Some or all of these aspects may also apply to LTE implementations.
[0188] The protocol layers of arrangement 800 may include one or more of a physical layer (PHY) 810, a medium access control layer (MAC) 820, a radio link control layer (RLC) 830, a packet data convergence protocol layer (PDCP) 840, a service data adaptation protocol layer (SDAP) 847, a radio resource control layer (RRC) 855, and a non-access stratum (NAS) layer 857, as well as other higher layer functions not shown. The protocol layers may include one or more service access points (e.g., Figure 8 Items 859, 856, 849, 845, 835, 825 and 815), which can provide communication between two or more protocol layers.
[0189] PHY 810 can send and receive physical layer signals 805, which can be received from or sent to one or more other communication devices. Physical layer signals 805 may include one or more physical channels, such as those discussed herein. PHY 810 may also perform link adaptation or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and switching purposes) and other measurements used by higher layers such as RRC 855. PHY 810 may also perform error detection, forward error correction (FEC) encoding / decoding of transmission channels, modulation / demodulation of physical channels, interleaving, rate matching, mapping to physical channels, and multiple input multiple output (MIMO) antenna processing on transmission channels. In an embodiment, an instance of PHY 810 may process a request from an instance of MAC 820 via one or more physical layer service access points (PHY-SAPs) 815, and provide instructions thereto via one or more PHY-SAPs 815. According to some embodiments, the request and instruction transmitted via PHY-SAP 815 may include one or more transmission channels.
[0190] An instance of MAC 820 may process requests from an instance of RLC 830 via one or more medium access control service access points (MAC-SAPs) 825 and provide instructions thereto via one or more MAC-SAPs 825. These requests and instructions delivered via MAC-SAPs 825 may include one or more logical channels. MAC 820 may perform mapping between logical channels and transport channels, multiplexing MAC service data units (SDUs) from one or more logical channels onto transport blocks (TBs) for delivery to PHY 810 via transport channels, demultiplexing MAC SDUs from TBs delivered from PHY 810 via transport channels to one or more logical channels, multiplexing MAC SDUs to TBs, scheduling information reporting, error correction via hybrid automatic repeat request (HARQ), and logical channel prioritization.
[0191] An instance of RLC 830 may process requests from an instance of PDCP 840 via one or more radio link control service access points (RLC-SAPs) 835 and provide indications thereto via one or more RLC-SAPs 835. These requests and indications delivered via RLC-SAPs 835 may include one or more RLC channels. RLC 830 may operate in a variety of operating modes, including: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). RLC 830 may perform transmission of upper layer protocol data units (PDUs), error correction through automatic repeat request (ARQ) for AM data transmission, and concatenation, segmentation, and reassembly of RLC SDUs for UM and AM data transmissions. RLC 830 may also perform re-segmentation of RLC data PDUs for AM data transmissions, reordering of RLC data PDUs for UM and AM data transmissions, detection of duplicate data for UM and AM data transmissions, discarding of RLC SDUs for UM and AM data transmissions, detection of protocol errors for AM data transmissions, and RLC reconstruction.
[0192] An instance of PDCP 840 may process requests from an instance of RRC 855 and / or an instance of SDAP 847 via one or more Packet Data Convergence Protocol Service Access Points (PDCP-SAPs) 845 and provide instructions thereto via one or more PDCP-SAPs 845. These requests and instructions delivered via PDCP-SAPs 845 may include one or more radio bearers. The PDCP layer 804 may perform header compression and decompression of IP data, maintain PDCP sequence numbers (SNs), perform in-order delivery of upper layer PDUs when reestablishing lower layers, eliminate duplication of lower layer SDUs when reestablishing lower layers for radio bearers mapped on RLC AM, encrypt and decrypt control plane data, perform integrity protection and integrity verification of control plane data, control timer-based data discard, and perform security operations (e.g., encryption, decryption, integrity protection, integrity verification, etc.).
[0193] An instance of SDAP 847 may process requests from one or more higher layer protocol entities via one or more Service Data Adaptation Protocol Service Access Points (SDAP-SAPs) 849 and provide indications thereto via one or more SDAP-SAPs 849. These requests and indications delivered via SDAP-SAPs 849 may include one or more Quality of Service (QoS) flows. SDAP 847 may map QoS flows to data radio bearers (DRBs) and vice versa, and may also mark QoS flow IDs (QFIs) in DL and UL packets. A single SDAP entity 847 may be configured for a single PDU session. In the UL direction, NG-RAN 110 may control the mapping of QoS flows to DRBs in two different ways, reflective mapping or explicit mapping. For reflective mapping, the SDAP 847 of UE101 / 102 may monitor the QoS flow ID of the DL packets for each DRB, and may apply the same mapping to packets flowing in the UL direction. For a DRB, the SDAP 847 of the UE 101 / 102 may map the UL packets belonging to the PDU session observed in the QoS flow corresponding to the QoS flow ID and the DL packets for that DRB. To achieve reflective mapping, the NG-RAN may mark the DL packets on the Uu interface using the QoS flow ID. The explicit mapping may involve the RRC 855 configuring the SDAP 847 with the explicit QoS flow to the DRB mapping rules, which may be stored and followed by the SDAP 847.
[0194] The RRC 855 may configure aspects of one or more protocol layers via one or more management service access points (M-SAPs), which may include one or more instances of PHY 810, MAC 820, RLC 830, PDCP 840, and SDAP 847. In an embodiment, an instance of the RRC 855 may process requests from one or more NAS entities 857 via one or more RRC service access points (RRC-SAPs) 856 and provide instructions thereto via one or more RRC-SAPs 856. The main services and functions of RRC 855 may include: broadcasting system information (e.g., included in a master information block (MIB) or system information block (SIB) related to NAS), broadcasting system information related to the access layer (AS), paging, establishing, maintaining and releasing the RRC connection between UE 101 / 102 and RAN 110 (e.g., RRC connection paging, RRC connection establishment, RRC connection modification and RRC connection release), establishment, configuration, maintenance and release of point-to-point radio bearers, security functions including key management, inter-radio access technology (RAT) mobility, and measurement configuration for UE measurement reporting. MIB and SIB may include one or more information elements (IEs), each of which may include a separate data field or data structure.
[0195] NAS 857 may form the highest layer of the control plane between UE 101 / 102 and AMF 221. NAS 857 may support mobility and session management procedures of UE 101 / 102 to establish and maintain IP connectivity between UE 101 and the P-GW in the LTE system.
[0196] According to various embodiments, one or more protocol entities of the arrangement 800 may be implemented in the UE 101 / 102, the RAN node 111 / 112, the AMF 221 (or the MME in the LTE implementation), the UPF 202 (or the S-GW and the P-GW in the LTE implementation), etc., for control plane or user plane communication protocol stacks between the above devices. In such an embodiment, one or more protocol entities that may be implemented in one or more of the UE 101 / 102, the gNB 111 / 112, the AMF 221, etc. may communicate with corresponding peer protocol entities that may be implemented in or on another device to perform such communication using the services of corresponding lower layer protocol entities. In some embodiments, a gNB centralized unit (gNB-CU) of gNB 111 / 112 may host the RRC 855, SDAP 847, and PDCP 840 of the gNB that controls the operation of one or more gNB distributed units (DUs), and the gNB-DUs of gNB 111 / 112 may each host the RLC 830, MAC 820, and PHY 810 of gNB 111 / 112.
[0197] In a first example, the control plane protocol stack may include, in order from the highest layer to the lowest layer, NAS 857, RRC 855, PDCP 840, RLC 830, MAC 820, and PHY 810. In this example, an upper layer 860 may be built on top of NAS 857, including an Internet Protocol layer (IP) 861, a stream control transmission protocol layer (SCTP) 862, and an application layer signaling protocol (AP) 863.
[0198] In the NR implementation, AP 863 can be an NG application protocol layer (NGAP or NG-AP) 863 of the NG interface 113A defined between the NG-RAN node 111 / 112 and the AMF 221, or AP 863 can be an Xn application protocol layer (XnAP or Xn-AP) 863 of the Xn interface 113X defined between two or more RAN nodes 111, 112.
[0199] The NG-AP 863 may support the functionality of the NG interface 113A and may include an elementary procedure (EP). The NG-AP EP may be an interaction unit between the NG-RAN nodes 111, 112 and the AMF 221. The NG-AP 863 services may include two groups: UE-associated services (e.g., services related to the UE 101, 102) and non-UE-associated services (e.g., services related to the entire NG interface instance between the NG-RAN nodes 111, 112 and the AMF 221). These services may include the following functions, including but not limited to: paging function for sending paging requests to NG-RAN nodes 111, 112 involved in a specific paging area; UE context management function for allowing AMF 221 to establish, modify and / or release UE context in AMF 221 and NG-RAN node 111 / 112; mobility function for UE 101 / 102 in ECM-CONNECTED mode for same-system HO to support mobility within NG-RAN and heterogeneous system HO to support mobility from / to EPS system; NAS signaling transmission function for transmitting or rerouting NAS messages between UE 101 / 102 and AMF 221; NAS node selection function for determining the association between AMF 221 and UE101 / 102; NG interface management function for establishing NG interface and monitoring errors on NG interface; warning message transmission function, which provides a means to transmit warning messages via NG interface or cancel the warning messages being broadcast; configuration transmission function for transmitting warning messages via CN 120 requests and transmits RAN configuration information (eg, Self-Organizing Network (SON) information, Performance Measurement (PM) data, etc.) between the two RAN nodes 111 , 112 ; and / or other similar functions.
[0200] XnAP 863 may support the functionality of the Xn interface 113X and may include XnAP basic mobility procedures and XnAP global procedures. The XnAP basic mobility procedures may include procedures for handling UE mobility within the NG RAN 110 (or E-UTRAN 110), such as handover preparation and cancellation procedures, SN state transfer procedures, UE context acquisition and UE context release procedures, RAN paging procedures, dual connectivity related procedures, etc. The XnAP global procedures may include procedures that are not related to a specific UE 101 / 102, such as Xn interface establishment and reset procedures, NG-RAN update procedures, cell activation procedures, etc.
[0201] In an LTE implementation, AP 863 may be an S1 application protocol layer (S1-AP) 863 for an S1 interface 113A defined between an E-UTRAN node 111 / 112 and an MME, or AP 863 may be an X2 application protocol layer (X2AP or X2-AP) 863 for an X2 interface 113X defined between two or more E-UTRAN nodes 111, 112.
[0202] The S1 application protocol layer (S1-AP) 863 may support the functionality of the S1 interface, and similar to the NG-AP discussed previously, the S1-AP may include an S1-AP EP. The S1-AP EP may be an interaction unit between the E-UTRAN node 111 / 112 and the MME within the LTE CN 120. The S1-AP 863 services may include two groups: UE-associated services and non-UE-associated services. These services perform the following functions, including but not limited to: E-UTRAN radio access bearer (E-RAB) management, UE capability indication, mobility, NAS signaling transmission, RAN information management (RIM) and configuration transmission.
[0203] The X2AP 863 may support the functions of the X2 interface 113X and may include an X2AP basic mobility procedure and an X2AP global procedure. The X2AP basic mobility procedure may include a procedure for handling UE mobility within the E-UTRAN 110, such as a handover preparation and cancellation procedure, an SN state transfer procedure, a UE context acquisition and a UE context release procedure, a RAN paging procedure, a dual connectivity related procedure, etc. The X2AP global procedure may include a procedure that is not related to a specific UE 101 / 102, such as an X2 interface establishment and reset procedure, a load indication procedure, an error indication procedure, a cell activation procedure, etc.
[0204] The SCTP layer (alternatively referred to as the SCTP / IP layer) 862 can provide guaranteed delivery of application layer messages (e.g., NGAP or XnAP messages in NR implementations, or S1-AP or X2AP messages in LTE implementations). SCTP 863 can ensure reliable delivery of signaling messages between the RAN node 111 and the AMF / MME based in part on the IP protocol supported by IP 861. The Internet Protocol layer (IP) 861 can be used to perform packet addressing and routing functions. In some implementations, the IP layer 861 can use point-to-point transport to transmit PDUs. In this regard, the RAN node 111 / 112 can include L2 and L1 layer communication links (e.g., wired or wireless) with the MME / AMF to exchange information.
[0205] In the second example, the user plane protocol stack may include SDAP 847, PDCP 840, RLC 830, MAC 820, and PHY 810 in order from the highest layer to the lowest layer. The user plane protocol stack may be used for communication between UE 101 / 102, RAN node 111 / 112, and UPF 202 in an NR implementation, or communication between S-GW and P-GW in an LTE implementation. In this example, an upper layer 851 may be built on top of SDAP 847 and may include a user datagram protocol (UDP) and IP security layer (UDP / IP) 852, a general packet radio service (GPRS) tunneling protocol-user plane layer (GTP-U) 853, and a user plane protocol data unit layer (UP PDU) 863.
[0206] The transport network layer 854 (also referred to as the "transport layer") may be built on an IP transport, and the GTP-U 851 may be used on the UDP / IP layer 703 (including the UDP layer and the IP layer) to carry the user plane PDU (UP-PDU). The IP layer (also referred to as the "Internet layer") may be used to perform packet addressing and routing functions. For example, the IP layer may assign IP addresses to user data packets in any of the IPv4, IPv6, or PPP formats.
[0207] GTP-U 853 can be used to carry user data within the GPRS core network and between the radio access network and the core network. For example, the transmitted user data can be a packet in any of the IPv4, IPv6 or PPP formats. UDP / IP 852 can provide a checksum for data integrity, a port number for addressing different functions at the source and destination, and encryption and authentication of the selected data stream. The RAN node 111 and the S-GW can utilize the S1-U interface to exchange user plane data via a protocol stack including the L1 layer 811, the L2 layer, the UDP / IP layer 852 and the GTP-U 853. The S-GW and the P-GW can utilize the S5 / S8a interface to exchange user plane data via a protocol stack including the L1 layer, the L2 layer, the UDP / IP layer 852 and the GTP-U 853. As previously described, the NAS protocol can support the mobility and session management procedures of the UE 101 / 102 to establish and maintain IP connectivity between the UE 101 and the P-GW.
[0208] In addition, despite Figure 8863 and / or the transport network layer 854. The application layer may be the layer at which a user of the UE 101 / 102 interacts with, for example, a software application being executed by the application circuitry 305 / 405. The application layer may also provide one or more interfaces for the software application to interact with the communication system of the UE 101 / 102, such as the baseband circuitry 304 / 404. In some implementations, the IP layer and / or the application layer may provide the same or similar functionality as layers 5-7 or portions thereof of the Open Systems Interconnection (OSI) model (e.g., OSI layer 7—application layer, OSI layer 6—presentation layer, OSI layer 5—session layer).
[0209] Figure 9-13 1-1300 are respectively shown for providing update UE radio capabilities or indicating the use settings of UE according to various embodiments. For the purpose of illustration, the operations of the processes 900-1300 are described as being described with respect to FIG. Figure 7 Some of the processes 900-1300 may include communications between various devices, and it should be understood that the various devices discussed may be used. Figure 8 The various messages / frames, protocols, entities, layers, etc. discussed are described in detail in relation to FIG. Figure 7 The various circuits described facilitate these communications. Figure 9-13 Specific examples and operation orders are shown in the present disclosure, but the described operation order should not be understood as limiting the scope of the embodiments in any way. On the contrary, the described operations can be reordered, decomposed into additional operations, combined, and / or omitted altogether while remaining within the spirit and scope of the present disclosure.
[0210] Fig. 9 An example conditional handover process 900 is shown in accordance with various embodiments. Process 900 depicts an example where UE 101 may perform a conditional handover (CHO) from a single server or source RAN node 111 and a single target RAN node 112 may communicate with UE 101; however, in many scenarios, there may be many cells or beams that UE 101 reports as possible candidates based on its previous RRM measurements.
[0211] The process 900 may begin at operation 902 where the UE 101 receives user plane (UP) data from the source RAN node 111, and at operation 904, the UE 101 may send a measurement report (MR) to the source RAN node 111. In an embodiment, the UE 101 may be configured with a "low" threshold to trigger the generation and transmission of an early MR to increase the reliability of a handover (HO) command to be sent at operation 914. At operation 906, the source RAN node 111 may determine whether the UE 101 should perform a HO based on the early MR obtained at operation 904. At operation 908, the source RAN node 111 may send an early HO request to the target RAN node 112, which may include or indicate that the HO will be a conditional HO (CHO) and may also include an exit condition for discarding the HO request. At operation 912, the target RAN node 112 may indicate acceptance of the CHO by sending a CHO confirmation (ACK) message to the source RAN node 111. In some embodiments, the CHO ACK message may be or may include a pre-built RRC configuration message to be sent to the UE 101.
[0212] At operation 914, the source RAN node 111 may send a CHO command to the UE 101, which may be included in an RRC message (e.g., an RRC connection reconfiguration message). In some embodiments, the source RAN node 111 may send a pre-constructed RRC message obtained from the target RAN node 112 at operation 912. In various embodiments, the CHO command may include or indicate a "high" threshold condition, such that when the condition is met, the UE 101 will trigger or initiate a HO procedure with the target RAN node 112 (e.g., by performing synchronization with the target RAN node 112, a random access procedure, etc.). In various embodiments, the CHO command may include or indicate a CHO exit condition, such that when the exit condition is met, the UE 101 will discard the CHO command and, in some embodiments, send a new MR to the source RAN node 111.
[0213] At operation 916, the UE 101 may determine whether the exit condition has been met. If the exit condition has been met (or alternatively, the CHO condition has not been met), the UE 101 may discard the CHO command at operation 918, and in some embodiments, the UE 101 may send a new MR to the source RAN node 111 at operation 920. If the exit condition has not been met (or alternatively, the CHO condition has been met), the UE 101 may proceed to operation 922 to trigger a HO to the target RAN node 111 by performing a synchronization and random access procedure with the target RAN node 112 at operation 924. At operation 926, the UE 101 may receive a HO confirmation from the target RAN node 112, and may start receiving UP data from the target RAN node 112 at operation 930. At the same time, at operation 928, the target RAN node 112 may send a confirmation to the source RAN node 111 that the HO has occurred, so that the RAN node 111 may, for example, release resources allocated to the UE 101.
[0214] Fig.10 An example conditional handover (CHO) process 1000 is shown in accordance with various embodiments. By way of example, process 1000 is discussed as being performed by UE 101 with respect to CHO from source RAN node 111 to target RAN node 112; however, other similar devices / entities may also perform process 1000.
[0215] Process 1000 may begin at operation 1005, where a communication circuit of UE 101 (see, e.g., Figure 4 RFEM 415 of UE 101) may receive a first radio resource control (RRC) message from source RAN node 111. At operation 1010, a processor circuit (see, e.g. Figure 4 The baseband circuit 404) may identify a configuration in the first RRC message, wherein the configuration may indicate a threshold signal strength / quality for performing measurement reporting.
[0216] At operation 1015, the processor circuit of UE 101 may determine whether a threshold has been reached. If at operation 1015, the processor circuit determines that the threshold has not been reached, the processor circuit may loop back to estimate the signal strength / quality. If at operation 1015, the processor circuit determines that the threshold has been reached, the processor circuit may proceed to operation 1020 to measure and / or estimate the signal strength / quality of the configured measurement object (e.g., the cell or beam indicated by the configuration in the first RRC message). At operation 1020, the processor circuit may generate a measurement report, and the communication circuit may send a measurement report (MR) to the source RAN node 111.
[0217] At operation 1025, the communication circuit of UE 101 may receive the second RRC message, and at operation 1030, the processor circuit of UE 101 may identify a CHO command in the second RRC message, wherein the CHO command may indicate a CHO condition for performing handover and an exit condition for exiting handover. The specific CHO condition and / or exit condition included in the CHO command may determine how long the network should reserve resources for UE 101 based on consideration of the handover execution situation.
[0218] At operation 1035, the processor circuit of the UE 101 may determine whether an exit condition has been met. If at operation 1035, the processor circuit determines that the exit condition has been met, the processor circuit may proceed to operation 1040 to discard the CHO command. If at operation 1035, the processor circuit determines that the exit condition has not been met, the processor circuit may proceed to operation 1045 to determine whether the CHO condition has been met. If at operation 1045, the processor circuit of the UE 101 determines that the CHO condition has not been met, the processor circuit may loop back to operation 1035 to determine whether the exit condition has been met. If at operation 1045, the processor circuit determines that the CHO condition has been met, the processor circuit may proceed to operation 1050 to perform a handover to the target RAN node 112 (or target beam) as indicated by the CHO command. After performing operation 1040 or 1050, the process 900 may end or repeat as needed.
[0219] In an embodiment, after UE 101 receives the CHO command, UE 101 may be considered to have entered the CHO condition. After entering the CHO condition, UE 101 may wait for the target RAN node 112 (or target beam) to satisfy the CHO condition to trigger a handover with the target RAN node 112 (or target beam). However, when the CHO condition is not satisfied, the exit condition may be considered to have been satisfied, and the network may be able to release the resources allocated to UE 101 for handover.
[0220] In some embodiments, the exit condition indicated by the CHO command may be a timer-based exit condition, and the processor circuit of the UE 101 may start the timer in response to receiving the CHO command at operation 1035. When the timer expires before the CHO condition is met, the processor circuit of the UE 101 may deem the exit condition to be met and may proceed to discard the CHO command at operation 1040. The specific timer value for the exit condition may be based on a tradeoff between the time required to reserve resources for HO and providing a sufficient amount of time so that the UE 101 can properly perform the HO to avoid a radio link failure (RLF).
[0221] In some embodiments, the exit condition may be event based, where the target cell or beam is offset below the serving cell or beam and / or is less than a threshold. The exit condition may be used by the UE 101 at operation 1035 to determine whether a handover to the target cell or beam is still desired, and if not, the CHO command may be discarded at operation 1040. These embodiments may allow for the release of reserved resources only when the target channel quality or signal strength is no longer optimal.
[0222] Fig.11 An example CHO process 1100 that may be performed by a source RAN node according to various embodiments is shown. By way of example, the process 1100 is discussed as being performed by the RAN node 111 acting as a serving node with respect to the CHO of the UE 101 from the source RAN node 111 to the target RAN node 112; however, other similar devices / entities may also perform the process 1100.
[0223] Process 1100 may begin at operation 1105, where a communication circuit of a source RAN node 111 (see, e.g., Figure 3 RFEM 315 of source RAN node 111 may receive a measurement report (MR) from UE 101. At operation 1110, a processor circuit (see e.g. Figure 3 The baseband circuit 304 or application circuit 305 of the source RAN node 111 may determine whether the UE 101 should be handed over to the target RAN node 112 (or target beam). At operation 1115, the communication circuit of the source RAN node 111 (see, e.g. Figure 3 The network controller circuit 335 of the source RAN node 111 may send a CHO request to the target RAN node 112, and at operation 1120, the communication circuit of the source RAN node 111 may obtain a CHO confirmation message from the target RAN node 112. In an embodiment, the CHO confirmation message may be or may include an RRC message to be sent to the UE 101. At operation 1125, the communication circuit of the source RAN node 111 (see, e.g., Figure 3 The RFEM 315 of the embodiment may send an RRC message to the UE. In an embodiment, the RRC message may include a CHO command to indicate a CHO condition for performing a handover with the target RAN node 112 and an exit condition for exiting the handover.
[0224] At operation 1130, the processor circuit of the source RAN node 111 may determine whether CHO has been exited. If at operation 1130, the processor circuit determines that CHO has been exited, the processor circuit may proceed to operation 1135 to control or instruct the communication circuit of the source RAN node 111 to signal to the target RAN node 112 an indication for releasing resources reserved for the UE 101. If at operation 1130, the processor circuit determines that CHO has not been exited, the processor circuit may proceed to operation 1140 to release resources that have been used to send user plane data to the UE 101. In some embodiments, the execution of operation 1140 may be based on receiving an indication from the UE 101 or the target RAN node 112 that CHO has been successfully completed.
[0225] Fig.12 An example CHO process 1200 that may be performed by a source RAN node according to various embodiments is shown. By way of example, process 1200 is discussed as being performed by RAN node 112 with respect to CHO of UE 101 from source RAN node 111 to target RAN node 112; however, other similar devices / entities may also perform process 1200.
[0226] Process 1200 may begin at operation 1205, wherein a communication circuit of a target RAN node 112 (see, e.g., Figure 3 The network controller circuit 335 of the source RAN node 111 may receive a CHO request (see e.g. Fig.11 In an embodiment, the CHO request message may indicate that the UE 101 is to be handed over to the target RAN node 112. At operation 1210, if / when the processor circuit of the target RAN node 112 (see, e.g. Figure 3 When the processor circuit of the target RAN node 112 (or the baseband circuit 304 or the application circuit 305) accepts the CHO request, the processor circuit of the target RAN node 112 may construct an RRC message to be sent to the UE 101. The processor circuit of the target RAN node 112 may accept or reject the CHO request based on whether the target RAN node 112 and / or the UE 101 support conditional handover. Assuming that the processor circuit of the target RAN node 112 accepts the CHO request at operation 1210, the communication circuit of the target RAN node 112 may send a CHO confirmation message to the source RAN node 111 at operation 1215. In an embodiment, the CHO confirmation message may include or may contain the constructed RRC message.
[0227] At operation 1220, the processor circuit of the source RAN node 112 may determine whether CHO has been exited. If at operation 1220, the processor circuit determines that CHO has been exited, the processor circuit may proceed to operation 1225 to release the operation 1225 resources (e.g., random access channel resources) reserved for the UE 101. If at operation 1220, the processor circuit determines that CHO has not been exited, the processor circuit may proceed to operation 1230 to perform various handover operations (e.g., synchronization and random access procedures) with the UE 101. In some embodiments, after successfully completing the handover, the communication circuit of the target RAN node 112 may signal to the source RAN node 111 an indication that CHO has been successfully completed.
[0228] In some embodiments, at operations 1220-1225, the source RAN node 111 may instruct the target RAN node 112 to release the target resources (e.g., RACH resources) when the exit condition is met or when the CHO condition is not met. In these embodiments, the source RAN node 111 may signal the instruction to the target RAN node 112 using an appropriate X2 / Xn message. In some embodiments, a timer may be set by the target RAN node 112, and when the timer expires, the resources may be released autonomously. The timer may be set in response to receiving an early CHO request at operation 1145 or after sending a CHO confirmation at operation 1215. In the event that the timer has expired before the UE 101 performs or initiates a handover, the source RAN node 111 may send another message to the target RAN node 112 to reserve the resources again. In other embodiments, the source RAN node 111 may explicitly signal an indication to the target RAN node 112 to release the resources reserved for the UE 101.
[0229] Fig.13 An example mobility state estimation (MSE) process 1300 is shown in accordance with various embodiments. By way of example, process 1300 is discussed as being performed by UE 101; however, other similar devices / entities may also perform process 1300.
[0230] Process 1300 may begin at operation 1305, where communication circuitry of UE 101 may receive a configuration message including mobility state estimation (MSE) parameters, and at operation 1310, processor circuitry of UE 101 may determine a plurality of MSE thresholds, where each of the MSE thresholds corresponds to an MSE value. In some implementations, the MSE parameters may be included in system information broadcast by serving RAN node 111 / 112. In some implementations, the configuration message may be included in an RRC message. In one example, the configuration message may be a system information block type 3 (SIB3) IE including a speedStateReselectionPars field, and the speedStateReselectionPars field may include a mobilityStateParameters IE. In another example, a measurement configuration (MeasConfig) IE may include a speedStatePars IE, and speedStatePars may include a mobilityStateParameters IE. In yet another example, the speedStatePars IE may be included in a variable measurement configuration (VarMeasConfig) IE. Table 3(a) shows an example of the mobilityStateParameters IE, and the mobility state parameters of the mobilityStateParameters IE are described in Table 3(b).
[0231]
[0232] Table 3(a)
[0233]
[0234]
[0235] Table 3(b)
[0236] In addition, the SIB3 IE, MeasConfig IE, or VarMeasConfig IE may also include a SpeedStateScaleFactors IE in the timeToTrigger-SF field, which may relate to or include factors (e.g., scaling factors) to be applied when the UE 101 is in a medium or high speed state. These scaling factors may be used to scale one or more mobility control related parameters. Table 4(a) shows an example of the SpeedStateScaleFactors IE, and Table 4(b) describes the scaling factor (SF) parameters of the SpeedStateScaleFactors IE.
[0237]
[0238] Table 4(a)
[0239]
[0240]
[0241] Table 4(b)
[0242] In other embodiments, additional or alternative scaling factors may be configured where a weighted cell count based on the number of TRP / beam switches within a cell is used. These scaling factors may be used so that cell size may be considered with respect to mobility state estimation. Considering cell size with respect to mobility state estimation may be useful for networks or deployment areas with multiple cells with different cell sizes. Using a cell size estimate may also be useful since the number of beam or TRP switches may not accurately reflect the actual mobility state of the UE 101.
[0243] In these embodiments, the network may configure individual beam switching MSE thresholds and / or individual TRP switching MSE thresholds for each cell and individual scaling factors for the individual beam / TRP switching MSE thresholds. The scaling factors may be based on the network's knowledge of the cell size of the individual cells, the threshold number of times that a beam switch across an individual cell may (or should) be required, and / or the known or estimated location of the UE 101 within a particular cell.
[0244] For example, the network may know that a particular cell is relatively large, and since the UE is likely to experience a large number of beam switches as it traverses the cell, a relatively large beam switching threshold may be set for the cell. However, a UE in a particular cell may switch a large number of times for reasons other than traversing the cell (e.g., due to poor channel conditions, coverage holes, etc.). In this regard, a scaling factor may be used to adjust (e.g., increase or decrease) the TRP or beam switching threshold. Additionally, the specific scaling factor used may be based on the location of the UE 101 within the cell, e.g., a scaling factor for a UE at the edge of the cell may be greater than a scaling factor for a UE closer to the center of the cell. Table 5(a) shows an example of the mobilityStateParameters IE for these embodiments, and the mobility state parameters of this version of the mobilityStateParameters IE are described in Table 5(b). Additionally, Table 6(b) describes an example of the SpeedStateScaleFactors IE for these embodiments shown in Table 6(a) and an example of the SF parameters for the SpeedStateScaleFactors IE for these embodiments.
[0245]
[0246] Table 5(a)
[0247]
[0248] Table 5(b)
[0249]
[0250] Table 6(a)
[0251]
[0252] Table 6(b)
[0253] In the examples of Table 5(a) and Table 6(a), some information included in the mobilityStateParameters IE and / or SpeedStateScaleFactors IE may be omitted based on a particular MSE embodiment for performing MSE. These MSE embodiments are discussed in more detail below with respect to operation 1325.
[0254] At operation 1315, the processor circuit of the UE 101 may increment a mobility counter for each handover or cell reselection that occurs, for each transmit-receive point (TRP) switch that occurs, and / or for each beam switch that occurs. In an embodiment, the processor circuit 101 may implement separate counters for each handover / cell reselection, TRP switch, and beam switch.
[0255] In the first MSE embodiment, the mobility counter may be used only to count the number of handovers or cell reselections, and the processor circuit of the UE 101 may increment the mobility counter when a new cell ID is obtained during the attach procedure.
[0256] In the second MSE embodiment, the mobility counter may be used only to count the number of TRP switching times, and the processor circuit of UE 101 may increment the mobility counter when a TRP identifier is obtained during the TRP switching process or after a successful completion of the TRP switching process.
[0257] In a third MSE embodiment, a first mobility counter may be used to count the number of cell reselection / handovers, and a second mobility counter may be used to count the number of beam switches that occurred. In these embodiments, a processor circuit of UE 101 may increment the first mobility counter when a new cell ID is obtained during an attach procedure or after a successful handover or cell reselection procedure, and may increment the second mobility counter after a successful beam switch or beam recovery procedure.
[0258] In a fourth MSE embodiment, a first mobility counter may be used to count the number of cell reselection / handovers, and a second mobility counter may be used to count the number of TRP switches that occur. In these embodiments, a processor circuit of UE 101 may increment a first mobility counter when a new cell ID is obtained during an attachment procedure or after a successful handover or cell reselection procedure, and may increment a second mobility counter after a successful TRP switch procedure.
[0259] In a fifth MSE embodiment, a first mobility counter may be used to count the number of cell reselection / handovers, a second mobility counter may be used to count the number of TRP switches generated, and a third mobility counter may be used to count the number of beam switches generated. In these embodiments, when a new cell ID is obtained during an attachment process or after a successful handover or cell reselection process, the processor circuit of the UE 101 may increment the first mobility counter; after a successful completion of a TRP switch process, the processor circuit may increment the second mobility counter; and after a successful completion of a beam switch or beam recovery process, the processor circuit may increment the third mobility counter.
[0260] Return to reference Fig.13 At operation 1320, the processor circuit of UE 101 may determine whether the MSE time period has expired, which may be based on the values of the t-Evaluation and / or t-HystNormal parameters discussed previously. If at operation 1320, the processor circuit determines that the time period has not expired, the processor circuit may loop back to operation 1315 to increment the mobility counter based on the cell, TRP, and / or beam switching. If at operation 1320, the processor circuit determines that the time period has not expired, the processor circuit may proceed to operation 1325 to estimate the current mobility state based on the MSE threshold, the value of the mobility state counter, and / or the estimated cell size.
[0261] According to the first MSE embodiment, the processor circuit may estimate the mobility state in a manner similar to that in the LTE implementation, except that the cell reselection is based on the number of cell IDs obtained by the UE 101. For example, the processor circuit may estimate the mobility state as medium mobility when the number of cell reselections during the time period of t-Evaluation exceeds the value of n-CellChangeMedium but does not exceed the value of n-CellChangeHigh; and may estimate the mobility state as high mobility when the number of cell reselections during the time period of t-Evaluation exceeds the value of n-CellChangeHigh. When neither medium nor high mobility state is determined (e.g., when the number of cell reselections during the time period of t-Evaluation is less than or equal to n-CellChangeMedium), the processor circuit may estimate the mobility state as normal mobility state. In the first MSE embodiment, operation 1325 may be omitted.
[0262] According to a second MSE embodiment, the processor circuit may estimate the mobility state in a manner similar to the first MSE example, except that the mobility state may be based on the number of TRP switching times. The processor circuit may estimate the mobility state as estimated medium mobility when the number of cell reselections during the time period t-Evaluation exceeds the value of n-TRPChangeMedium but does not exceed the value of n-TRPChangeHigh; and may estimate the mobility state as a high mobility state when the number of cell reselections during the time period t-Evaluation exceeds the value of n-TRPChangeHigh. When neither medium nor high mobility states are determined (e.g., when the number of cell reselections during the time period t-Evaluation is less than or equal to the value of n-TRPChangeMedium), the processor circuit may estimate the mobility state as a normal mobility state. In the second MSE embodiment, operation 1325 may be omitted.
[0263] According to a third MSE embodiment, the processor circuit may estimate the mobility state based on the beam switching count of the current serving cell. In these embodiments, the processor circuit may apply sf-BeamChange-High and sf-BeamChange-Medium to the beam switching count of the beam mobility counter, and may compare these values with the n-BeamChange-High and n-BeamChange-Medium values, respectively. For example, when the number of beam switches adjusted using sf-BeamChange-Medium during the time period t-Evaluation exceeds the value of n-BeamChange-Medium but does not exceed the value of n-BeamChange-High (which may or may not be adjusted using sf-BeamChange-High), the processor circuit may estimate the mobility state as medium mobility. When the number of beam switches adjusted using sf-BeamChange-High during the time period t-Evaluation exceeds the value of n-BeamChange-High, the processor circuit may estimate the mobility state as a high mobility state. When neither the medium nor the high mobility state is determined (e.g., when the number of beam switches during the time period of t-Evaluation is less than or equal to the adjusted value of n-BeamChange-Medium), the processor circuit may estimate the mobility state as the normal mobility state. In the third MSE embodiment, since the individual scaling factors are based on the cell size, operation 1325 may be omitted. Additionally, in the third embodiment, the TRP-related thresholds and scaling factors may be omitted from the mobilityStateParameters IE and / or SpeedStateScaleFactors IE.
[0264] According to the fourth MSE embodiment, the processor circuit may estimate the mobility state based on the TRP switching count of the current serving cell. In these embodiments, the processor circuit may apply sf-TRPChange-High and sf-TRPChange-Medium to the TRP switching count of the TRP mobility counter, and may compare these values with the n-TRPChange-High and n-TRPChange-Medium values, respectively. For example, when the number of TRP switching times adjusted using sf-TRPChange-Medium during the time period t-Evaluation exceeds the value of n-TRPChange-Medium but does not exceed the value of n-TRPChange-High (which may or may not be adjusted using sf-TRPChange-High), the processor circuit may estimate the mobility state as medium mobility. When the number of TRP switching times adjusted using sf-TRPChange-High during the time period t-Evaluation exceeds the value of n-TRPChange-High, the processor circuit may estimate the mobility state as a high mobility state. When neither the medium nor the high mobility state is determined (e.g., when the number of beam switches during the time period of t-Evaluation is less than or equal to the value of the adjusted n-TRPChange-Medium), the processor circuit may estimate the mobility state as the normal mobility state. In the fourth MSE embodiment, since the individual scaling factors are based on the cell size, operation 1325 may be omitted. Additionally, in the third embodiment, the beam-related thresholds and scaling factors may be omitted from the mobilityStateParameters IE and / or SpeedStateScaleFactors IE.
[0265] The fifth MSE embodiment may include a combination of the third and fourth MSE embodiments discussed previously. In the fifth embodiment, the processor circuit may apply sf-BeamChange-High and sf-BeamChange-Medium to the beam switching count of the beam mobility counter, wherein the adjusted values may be compared with the n-BeamChange-High and n-BeamChange-Medium values, respectively; and the processor circuit may apply sf-TRPChange-High and sf-TRPChange-Medium to the TRP switching count of the TRP mobility counter, wherein the adjusted values may be compared with the n-TRPChange-High and n-TRPChange-Medium values, respectively.
[0266] In these embodiments, when the adjusted number of TRP switches and the adjusted number of beam switches during the time period t-Evaluation both exceed the value of n-TRPChange-Medium and the value of n-BeamChange-Medium, respectively, and do not exceed the (adjusted or unadjusted) value of n-TRPChange-High and the (adjusted or unadjusted) value of n-BeamChange-High, respectively, the processor circuit may estimate the mobility state as medium mobility. Additionally, when the adjusted number of TRP switches and the adjusted number of beam switches during the time period t-Evaluation both exceed the adjusted value of n-TRPChange-High and the adjusted value of n-BeamChange-High, respectively, the processor circuit may estimate the mobility state as a high mobility state. Similar to other MSE embodiments, when it is determined that it is neither a high mobility state nor a medium mobility state, the processor circuit may estimate the mobility state as a normal mobility state.
[0267] According to the sixth MSE embodiment, the processor circuit may estimate the cell size at operation 1325, which may be used to adjust the mobility state estimation. In these embodiments, the processor circuit may estimate the cell size based on the number of TRPs and / or the number of beam switching times for a particular cell counted at operation 1315. In an embodiment, the configuration message may indicate the number of TRPs for a corresponding cell ID or measurement object. The number of TRPs per cell ID may be included in a MeasConfig IE, a mobilityStateParameters IE, or some other suitable IE or data structure.
[0268] As previously discussed, the cell size estimate at operation 1325 may be based on the number of TRPs within the cell and / or the number of beam switches that occur within the cell. In some cases, when a large number of beam switches occur within a particular cell, the UE may estimate that the cell is relatively large. In other words, in some embodiments, the estimated cell size may increase as the number of beam switches counted increases. In other cases, the UE may count relatively few beam or TRP switches that may be attributed to the UE moving along the edge of the cell. These cases may exist where the RAN nodes are deployed in such a way that the trajectory for the UE's handover to the cell is at the edge of the cell, which may indicate a relatively small cell.
[0269] In addition to the above cases, the above beam and TRP related embodiments can be performed by UE 101 when UE 101 is in a connected mode (e.g., RRC_CONNECTED mode, etc.). However, when UE 101 is in an idle mode (e.g., RRC_IDLE mode, etc.), UE 101 may not be able to perform or have knowledge of TRP or beam related information. In these cases, UE 101 can be aware of the change in the highest signal value in each block within L blocks, and can use the L index change as a beam change, or use the switch as the beam information discussed previously. In an alternative embodiment, the processor circuit can use the beam switch count regardless of the current network beam.
[0270] Some non-limiting examples are provided below. The following examples pertain to other embodiments. The details in the examples may be used anywhere in one or more embodiments discussed previously. All optional features of the apparatus described herein may also be implemented with respect to one or more methods or processes, and vice versa.
[0271] Example 1 may include one or more computer-readable storage media ("CRSM") having instructions, which, when executed by one or more processors of a user equipment ("UE"), are used to cause the UE to: identify a conditional handover ("CHO") command from a received radio resource control ("RRC") message, wherein the CHO is used to indicate a first condition and a second condition, wherein the first condition is used to indicate a condition for performing a handover ("HO") of the CHO, and the second condition is used to indicate a condition for not performing the HO; and when the first condition is met before the second condition is met, perform a HO process; and when the second condition is met and the first condition is not met, discard the CHO.
[0272] Example 2 may include one or more CRSMs described in Example 1 and / or some other examples herein, wherein execution of the instruction causes the UE to: initiate a validity timer; and perform the HO process when the first condition is met before expiration of the validity timer, wherein the second condition includes expiration of the validity timer.
[0273] Example 3 may include one or more CRSMs described in Example 2 and / or some other examples herein, wherein the validity timer corresponds to a separate target cell or a separate target beam, and execution of the instruction causes the UE to: perform the HO process with the separate target cell or the separate target beam when the first condition is met before expiration of the validity timer.
[0274] Example 4 may include one or more CRSMs described in Example 2 and / or some other examples herein, wherein the validity timer corresponds to multiple target cells or multiple target beams, and execution of the instruction causes the UE to: perform the HO process with a target cell among the multiple target cells or a target beam among the multiple target beams when the first condition is satisfied with respect to the target cell or the target beam before expiration of the validity timer.
[0275] Example 5 may include one or more CRSMs described in any one of Examples 2-4 and / or some other examples herein, wherein execution of the instructions causes the UE to: initiate the validity timer in response to receiving the CHO; initiate the validity timer when the serving cell signal strength or the serving beam signal strength is less than a threshold indicated by the RRC message; or initiate the validity timer when the difference between the serving cell signal strength and the target cell signal or the difference between the serving beam signal strength and the target beam signal strength is within the range indicated by the RRC message.
[0276] Example 6 may include one or more CRSMs described in Example 1 and / or some other examples herein, wherein the second condition is met when the difference between the source cell signal-to-noise interference ("SINR") and the target cell SINR becomes less than a measurement reporting threshold, or when the difference between the source beam SINR and the target beam SINR becomes less than another measurement reporting threshold.
[0277] Example 7 may include one or more CRSMs described in Example 1 and / or some other examples herein, wherein the second condition is satisfied when the target cell SINR is less than or equal to the source cell SINR, or when the target beam SING is less than or equal to the source beam SINR.
[0278] Example 8 may include one or more CRSMs described in Example 1, 6 or 7 and / or some other examples herein, wherein, when the second condition is met, execution of the instruction causes the UE to: control the radio control circuit to perform one or more measurements of one or more cells or one or more beams; and control the transmission of a measurement report to indicate the signal strength of the one or more cells or the one or more beams.
[0279] Example 9 may include one or more CRSMs described in Example 8 and / or some other examples herein, wherein execution of the instructions causes the UE to: detect a new cell that is not among the one or more cells or a new beam that is not among the one or more beams based on the one or more measurements; and when the signal strength or signal quality of the new cell or the new beam is greater than or equal to the signal strength or signal quality of the serving cell or the serving beam, discard the CHO and control the transmission of another measurement report to indicate the signal strength or the signal quality of the new cell or the new beam.
[0280] Example 10 may include one or more CRSMs described in any one of Examples 1-9, wherein execution of the instruction causes the UE to: control the transmission of a scheduling request, a random access response, or an RRC connection reestablishment message when the second condition is met.
[0281] Example 11 may include one or more CRSMs described in Example 10 and / or some other examples herein, wherein, when the first condition is met, execution of the instruction causes the UE to: send a control message to a source cell or a transmit-receive point for providing a source beam after performing the HO process, wherein the message is used to indicate successful execution of the HO process.
[0282] Example 12 may include an apparatus to be employed as a user equipment ("UE"), the apparatus comprising: a processing component for: identifying multiple mobility state estimation ("MSE") thresholds from a received configuration message, wherein each of the multiple MSE thresholds corresponds to an MSE value, and when the value of a mobility counter is less than or equal to the MSE threshold corresponding to an individual MSE value, determining the MSE of the UE as the individual MSE value; and a communication component for: receiving the configuration message.
[0283] Example 13 may include the apparatus described in Example 12 and / or some other examples herein, wherein the processing component is used to: increment the mobility counter when a handover or cell reselection to a cell having a cell identifier (cell ID) different from a cell ID of a current serving cell is about to occur.
[0284] Example 14 may include the apparatus described in Example 12 and / or some other examples herein, wherein the processing component is configured to: increment the mobility counter when beam selection or beam switching occurs.
[0285] Example 15 may include the apparatus described in Example 12 and / or some other examples herein, wherein the processing component is used to: increment the mobility counter in response to receiving another one or more beams from a transmit-receive point ("TRP") different from a TRP from which the UE received the one or more beams.
[0286] Example 16 may include the apparatus described in Example 15 and / or some other examples herein, wherein the processing component is used to: identify the number of beam switches or the number of TRP switches for each of a plurality of cells from a received configuration message; and identify a scaling factor associated with a corresponding cell among the plurality of cells from the received configuration message, wherein the scaling factor is to be applied to the MSE threshold associated with the corresponding cell, and wherein the scaling factor for each cell is based on the number of beam switches generated in each cell or the number of TRP switches for each cell.
[0287] Example 17 may include the apparatus described in any one of Examples 13-16 and / or some other examples herein, wherein the processing component is used to: identify the number of TRPs for each of a plurality of cells from a received RRC message; estimate the cell size for each cell based on the number of TRPs for each cell; and determine the MSE of the UE based on the estimated cell size.
[0288] Example 18 may include an apparatus to be employed as a wireless access network node, the apparatus comprising: a processing component for: determining a plurality of mobility state estimation ("MSE") thresholds, wherein each of the plurality of MSE thresholds corresponds to an MSE value, and generating a configuration message to indicate the plurality of MSE thresholds; and a communication component for: transmitting the configuration message to a user equipment in the form of a signal.
[0289] Example 19 may include the apparatus described in Example 18 and / or some other examples herein, wherein the processing component is used to: determine the number of transmit-receive points ("TRPs") for each of a plurality of cells, wherein the number of TRPs for each cell is to be used to estimate the size of each cell; and generate the configuration message to indicate the number of TRPs for each cell.
[0290] Example 20 may include the apparatus described in Example 18 or 19 and / or some other examples herein, wherein the processing component is used to: determine a threshold number of beam switching times or a threshold number of TRP switching times for each cell in a plurality of cells based on the size of each cell; and generate the configuration message to indicate the threshold number of beam switching times or the threshold number of TRP switching times.
[0291] Example 21 may include the apparatus described in Example 20 and / or some other examples herein, wherein the processing component is used to: determine multiple scaling factors associated with a corresponding cell among the multiple cells, wherein each of the multiple scaling factors is to be applied to the threshold number of beam switching times or the threshold number of TRP switching times of the corresponding cell; and generate the configuration message to indicate the multiple scaling factors.
[0292] Example 22 may include an apparatus to be employed as a wireless access network node, the apparatus comprising: a radio control circuit for receiving a measurement report from a user equipment ("UE"); and a processor circuit communicatively coupled to the radio control circuit, the processor circuit for generating a conditional handover ("CHO") request message when the UE is to be handed over to a target wireless access network node; and a network controller circuit communicatively coupled to the processor circuit, the network controller circuit for: sending the CHO request message to the target wireless access network node, and obtaining a wireless resource control ("RRC") message to be sent to the UE from the target wireless access network node, wherein the RRC message is used to include a CHO command, and wherein the CHO command is used to indicate a CHO condition and an exit condition, wherein the CHO condition is used to indicate a condition that, when implemented, causes the UE to initiate a handover ("HO") with the target wireless access network node, and the exit condition is used to indicate a condition that, when implemented, causes the UE to discard the CHO command.
[0293] Example 23 may include the apparatus described in Example 22 and / or some other examples herein, wherein the radio control circuit is used to: send the RRC message to the UE in response to the network controller circuit receiving the RRC message.
[0294] Example 24 may include the apparatus described in Example 22 and / or some other examples herein, wherein the radio control circuit is used to: receive a message from the UE to indicate successful completion of the HO with the target radio access network node, or the network controller circuit is used to: obtain a message from the target radio access network node to indicate successful completion of the HO with the UE.
[0295] Example 25 may include the apparatus described in any one of Examples 22-24 and / or some other examples herein, wherein the processor circuit is used to determine that the UE is to be handed over to the target wireless access network node based on a signal strength or signal quality measurement included in the measurement report.
[0296] Example 26 may include a method to be performed by a user equipment ("UE"), the method comprising: identifying or causing identification of a conditional handover ("CHO") command from a received radio resource control ("RRC") message, wherein the CHO is used to indicate a first condition and a second condition, wherein the first condition is used to indicate a condition for performing a handover ("HO") of the CHO, and the second condition is used to indicate a condition for not performing the HO; when the first condition is met before the second condition is met, performing or causing the HO process to be performed; and when the second condition is met and the first condition is not met, discarding or causing the CHO to be discarded.
[0297] Example 27 may include the method described in Example 26 and / or some other examples herein, further including: initiating or causing initiation of a validity timer; and when the first condition is met before expiration of the validity timer, performing or causing performance of the HO process, wherein the second condition includes expiration of the validity timer.
[0298] Example 28 may include the method described in Example 27 and / or some other examples herein, wherein the validity timer corresponds to a separate target cell or a separate target beam, and the method includes: when the first condition is met before expiration of the validity timer, performing or causing the HO process with the separate target cell or the separate target beam to be performed.
[0299] Example 29 may include the method described in Example 27 and / or some other examples herein, wherein the validity timer corresponds to multiple target cells or multiple target beams, and the method includes: when the first condition is satisfied with respect to the target cell or the target beam before expiration of the validity timer, performing or causing execution of the HO process with a target cell among the multiple target cells or a target beam among the multiple target beams.
[0300] Example 30 may include the method described in any one of Examples 27-29 and / or some other examples herein, further including: in response to receiving the CHO, initiating or causing the validity timer to be initiated; when the serving cell signal strength or the serving beam signal strength is less than a threshold indicated by the RRC message, initiating or causing the validity timer to be initiated; or when the difference between the serving cell signal strength and the target cell signal or the difference between the service beam signal strength and the target beam signal strength is within the range indicated by the RRC message, initiating or causing the validity timer to be initiated.
[0301] Example 31 may include the method described in Example 26 and / or some other examples herein, wherein the second condition is met when the difference between the source cell signal-to-noise interference ("SINR") and the target cell SINR becomes less than a measurement reporting threshold, or when the difference between the source beam SINR and the target beam SINR becomes less than another measurement reporting threshold.
[0302] Example 32 may include the method described in Example 26 and / or some other examples herein, wherein the second condition is satisfied when the target cell SINR is less than or equal to the source cell SINR, or when the target beam SING is less than or equal to the source beam SINR.
[0303] Example 33 may include the method described in Examples 26-32 and / or some other examples herein, wherein, when the second condition is met, and the method includes: performing or causing one or more measurements of one or more cells or one or more beams to be performed; and sending or causing a measurement report to be sent to indicate the signal strength of the one or more cells or the one or more beams.
[0304] Example 34 may include the method described in Example 33 and / or some other examples herein, further including: detecting or causing detection of a new cell that is not among the one or more cells or a new beam that is not among the one or more beams based on the one or more measurements; and when the signal strength or signal quality of the new cell or the new beam is greater than or equal to the signal strength or signal quality of the serving cell or the serving beam, discarding or causing discarding the CHO, and sending or causing sending another measurement report to indicate the signal strength or the signal quality of the new cell or the new beam.
[0305] Example 35 may include the method described in any one of Examples 26-24, further comprising: sending or causing sending of a scheduling request, a random access response, or an RRC connection reestablishment message when the second condition is met.
[0306] Example 36 may include the method described in Example 35 and / or some other examples herein, wherein, when the first condition is met, the method includes: sending or causing a message to be sent to a source cell or a transmitting-receiving point for providing a source beam after performing the HO process, wherein the message is used to indicate successful execution of the HO process.
[0307] Example 37 may include a method to be performed by a user equipment ("UE"), the device comprising: identifying or causing identification of multiple mobility state estimation ("MSE") thresholds from a received configuration message, wherein each of the multiple MSE thresholds corresponds to an MSE value; when the value of a mobility counter is less than or equal to the MSE threshold corresponding to a separate MSE value, determining or causing determination of the MSE of the UE as the separate MSE value; and receiving or causing receipt of the configuration message.
[0308] Example 38 may include the method described in Example 37 and / or some other examples herein, wherein the method includes: incrementing or causing the mobility counter to be incremented when a handover or cell reselection to a cell having a cell identifier (cell ID) different from a cell identifier (cell ID) of a current serving cell is about to occur.
[0309] Example 39 may include the method described in Example 38 and / or some other examples herein, wherein the method includes: incrementing or causing the mobility counter to be incremented when beam selection or beam switching occurs.
[0310] Example 40 may include the method described in Example 38 and / or some other examples herein, wherein the method includes: in response to receiving another one or more beams from a transmit-receive point ("TRP") different from a TRP from which the UE received the one or more beams, incrementing or causing the mobility counter to be incremented.
[0311] Example 41 may include the method described in Example 40 and / or some other examples herein, wherein the method further includes: identifying or enabling identification of the number of beam switching times or the number of TRP switching times for each of a plurality of cells from a received configuration message; and identifying or enabling identification of a scaling factor associated with a corresponding cell among the plurality of cells from the received configuration message, wherein the scaling factor is to be applied to the MSE threshold associated with the corresponding cell, and wherein the scaling factor for each cell is based on the number of beam switching times or the number of TRP switching times generated in each cell.
[0312] Example 42 may include the method of any one of Examples 38-41 and / or some other examples herein, wherein the method includes: identifying or causing identification of the number of TRPs for each of a plurality of cells from a received RRC message; estimating or causing estimation of the cell size for each cell based on the number of TRPs for each cell; and determining or causing determination of the MSE of the UE based on the estimated cell size.
[0313] Example 43 may include a method to be performed by a wireless access network node, the method comprising: determining or causing determination of a plurality of mobility state estimation (“MSE”) thresholds, wherein each of the plurality of MSE thresholds corresponds to an MSE value; generating or causing generation of a configuration message to indicate the plurality of MSE thresholds; and signaling or causing the configuration message to be signaled to a user equipment.
[0314] Example 44 may include the method described in Example 43 and / or some other examples herein, further comprising: determining or causing determination of a number of transmit-receive points (“TRPs”) for each of a plurality of cells, wherein the number of TRPs for each cell is to be used to estimate the size of each cell; and generating or causing generation of the configuration message to indicate the number of TRPs for each cell.
[0315] Example 45 may include the method described in Example 43 or 44 and / or some other examples herein, further including: determining or causing determination of a threshold number of beam switching times or a threshold number of TRP switching times for each cell in a plurality of cells based on the size of each cell; and generating or causing generation of the configuration message to indicate the threshold number of beam switching times or the threshold number of TRP switching times.
[0316] Example 46 may include the method described in Example 45 and / or some other examples herein, further comprising: determining or causing determination of multiple scaling factors associated with a corresponding cell among the multiple cells, wherein each of the multiple scaling factors is to be applied to the threshold number of beam switching times or the threshold number of TRP switching times of the corresponding cell; and generating or causing generation of the configuration message to indicate the multiple scaling factors.
[0317] Example 47 may include a device including a component for performing one or more elements of a method described in or related to any of Examples 1-46 or any other method or process described herein. Example 48 may include one or more non-transitory computer-readable media including instructions to cause the electronic device to perform one or more elements of a method described in or related to any of Examples 1-46 or any other method or process described herein when one or more processors of an electronic device execute the instructions. Example 49 may include a device including a logic, module, or circuit for performing one or more elements of a component for performing a method described in or related to any of Examples 1-46 or any other method or process described herein. Example 50 may include a method, technique, or process described in or related to any of Examples 1-46 or a portion or section thereof. Example 51 may include a device including: 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 the method, technique, or process described in or related to any of Examples 1-46 or a portion thereof. Example 52 may include a signal described in or related to any of Examples 1-46 or a portion or section thereof. Example 53 may include a signal in a wireless network shown and described herein. Example 54 may include a method of communicating in a wireless network shown and described herein. Example 55 may include a system for providing wireless communications shown and described herein. Example 56 may include an apparatus for providing wireless communications shown and described herein.
[0318] The foregoing description of the above examples provides illustration and description of the example embodiments disclosed herein, but the above examples are not intended to encompass or limit the scope of the present invention to the precise forms disclosed. Modifications and variations are possible in light of the above teachings, and / or may be acquired from practice of the various implementations of the embodiments discussed herein.
Claims
1. A user equipment UE, comprising: Transceiver; and a processor circuit communicatively coupled to the transceiver and configured to: Identify, from the received configuration message, a number of transmission / reception point TRP switching times and a plurality of mobility state estimation MSE thresholds for each of a plurality of cells; Based on the number of TRP switching times for each cell, estimate the cell size of each cell; as well as A mobility state of the UE is determined based on a value of a mobility counter, the estimated cell size, and the plurality of MSE thresholds.
2. The UE according to claim 1, wherein: The processor circuit is further configured to: When handover or cell reselection is to occur to a cell having a cell identifier cellID different from the cellID of the current serving cell, the mobility counter is incremented.
3. The UE according to claim 1, wherein: The processor circuit is further configured to: When beam selection or beam switching occurs, the mobility counter is incremented.
4. The UE according to claim 1, wherein: The processor circuit is further configured to: In response to receiving one or more other beams from a TRP different from the TRP at which the UE received the one or more beams, the mobility counter is incremented.
5. The UE according to claim 4, wherein: The processor circuit is further configured to: Identifying a beam switching number or a TRP switching number for each of the plurality of cells from the received configuration message; and Identify a scaling factor associated with a corresponding cell among the multiple cells from a received configuration message, wherein the scaling factor is to be applied to an MSE threshold associated with the corresponding cell, and wherein the scaling factor for each cell is based on a number of beam switches that occur in each cell or a number of TRP switches for each cell.
6. The UE according to claim 1, wherein: The mobility state of the UE is a normal mobility state, a medium mobility state or a high mobility state.
7. A non-transitory computer readable medium (CRM), comprising instructions, which, when executed by one or more processors of a user equipment (UE), cause the UE to perform operations, the operations comprising: Identify, from the received configuration message, a number of transmission / reception point TRP switching times and a plurality of mobility state estimation MSE thresholds for each of a plurality of cells; Based on the number of TRP switching times for each cell, estimate the cell size of each cell; as well as A mobility state of the UE is determined based on a value of a mobility counter, the estimated cell size, and the plurality of MSE thresholds.
8. The non-transitory CRM of claim 7, wherein: The operations also include: When handover or cell reselection is to occur to a cell having a cell identifier cellID different from the cellID of the current serving cell, the mobility counter is incremented.
9. The non-transitory CRM of claim 7, wherein: The operations also include: When beam selection or beam switching occurs, the mobility counter is incremented.
10. The non-transitory CRM of claim 7, wherein: The operations also include: In response to receiving one or more other beams from a TRP different from the TRP at which the UE received the one or more beams, the mobility counter is incremented.
11. The non-transitory CRM of claim 10, wherein: The operations also include: Identifying a beam switching number or a TRP switching number for each of the plurality of cells from the received configuration message; and Identify a scaling factor associated with a corresponding cell among the multiple cells from a received configuration message, wherein the scaling factor is to be applied to an MSE threshold associated with the corresponding cell, and wherein the scaling factor for each cell is based on a number of beam switches that occur in each cell or a number of TRP switches for each cell.
12. The non-transitory CRM of claim 7, wherein: The mobility state of the UE is a normal mobility state, a medium mobility state or a high mobility state.
13. A base station BS, comprising: Transceiver; and a processor circuit communicatively coupled to the transceiver and configured to: Determine a number of TRP switching times of each of the plurality of cells and a plurality of mobility state estimation MSE thresholds, wherein the number of TRP switching times of each cell is used to estimate the size of each cell; generating a configuration message to indicate the number of TRP switching times for each cell and the plurality of MSE thresholds; and Sending control signaling including the configuration message to user equipment UE.
14. The BS according to claim 13, wherein: The processor circuit is further configured to: Determining a beam switching threshold number or a TRP switching threshold number for each of the plurality of cells based on a size of each cell; and Generate the configuration message to indicate the beam switching threshold number or the TRP switching threshold number.
15. The BS according to claim 13, wherein: The processor circuit is further configured to: Determining a plurality of scaling factors associated with a corresponding cell among the plurality of cells, wherein each scaling factor of the plurality of scaling factors is to be applied to a beam switching threshold number of times or a TRP switching threshold number of times of the corresponding cell; and The configuration message is generated to indicate the plurality of scaling factors.
16. The BS according to claim 13, wherein: The processor circuit is further configured to: determining a duration for evaluating criteria for entering a mobility state; and The configuration message is generated to indicate the duration for evaluating criteria for entering a mobility state.
17. The BS according to claim 13, wherein: The plurality of MSE thresholds include a threshold number of cell changes for entering a high mobility state and a threshold number of cell changes for entering a medium mobility state.
Citation Information
Patent Citations
Signaling for mobility and mobility state estimation
CN105684480A
Cell positioning in cellular network
US20160057697A1