Methods and apparatus for handling in-device coexistence issue when performing position measurements for synchronization

Abstract

The disclosure relates to a 5G or 6G communication system for supporting higher data transmission rates and satisfying various service requirements. According to an example of the disclosure, a method performed by a UE in a wireless communication system is provided. The method may include determining to transition from an RRC idle state or an RRC inactive state to an RRC connected state for accessing a cell of a base station in a NTN system; identifying whether a first condition for performing a preventive action is satisfied, wherein the preventive action includes measuring a position of the UE before attempting to access the cell; and in case that the first condition is satisfied, performing the preventive action.

Description

METHODS AND APPARATUS FOR HANDLING IN-DEVICE COEXISTENCE　ISSUE WHEN PERFORMING POSITION MEASUREMENTS FOR SYNCHRONIZATION

[0001] The disclosure is related to the field of wireless communication networks. More particularly, the disclosure is related to a method and apparatus relating to in device co-existence when performing position measurements for synchronization, for example within non-terrestrial networks (NTNs) and future NTNs.

[0002] 5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in “Sub 6GHz” bands such as 3.5GHz, but also in “Above 6GHz” bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

[0003] At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

[0004] Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

[0005] Moreover, there has been ongoing standardization in air interface architecture / protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step RACH for NR). There also has been ongoing standardization in system architecture / service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

[0006] As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

[0007] Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI (Artificial Intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

[0008] As described above and with the development of wireless communication systems, various services have become available, and methods for providing these services smoothly are required.

[0009] The disclosure is related to a method and apparatus relating to in-device co-existence (IDC) when performing position measurements for synchronization.

[0010] Accordingly, an aspect of the disclosure is to provide methods and apparatus for avoid IDC issue between measuring a position of the UE and accessing to a cell of a NTN system.

[0011] In addition, an aspect of the disclosure is to provide methods and apparatus for supporting UE to perform appropriate actions based on a result of handling IDC issues.

[0012] It is an aim of certain examples of the disclosure to address, solve and / or mitigate, at least partly, at least one of the problems and / or disadvantages associated with the related art, for example at least one of the problems and / or disadvantages described herein. It is an aim of certain examples of the disclosure to provide at least one advantage over the related art, for example at least one of the advantages described herein.

[0013] According to an example of the disclosure, a method performed by a UE in a wireless communication system is provided. The method may include determining to transition from an RRC idle state or an RRC inactive state to an RRC connected state for accessing a cell of a base station in a NTN system; identifying whether a first condition for performing a preventive action is satisfied, wherein the preventive action includes measuring a position of the UE before attempting to access the cell; and in case that the first condition is satisfied, performing the preventive action.

[0014] According to an aspect of the disclosure, a user equipment (UE) in a wireless communication system is provided. The UE may include at least one transceiver; at least one processor coupled to the at least one transceiver; and memory coupled to the at least one processor storing instructions executable by the at least one processor; wherein the instructions cause the UE to: determine to transition from a radio resource control (RRC) idle state or an RRC inactive state to an RRC connected state for accessing a cell of a base station in a non-terrestrial network (NTN) system, identify whether a first condition for performing a preventive action is satisfied, wherein the preventive action includes measuring a position of the UE before attempting to access the cell, and in case that the first condition is satisfied, perform the preventive action.

[0015] Embodiments or examples disclosed in the description and / or figures falling outside the scope of the claims are to be understood as examples useful for understanding the disclosure.

[0016] According to examples of the disclosure, the UE may perform preventive action in advance to prevent a decrease in communication efficiency due to an occurrence of an IDC issue, before accessing cell of the NTN system.

[0017] Furthermore, according to examples of the disclosure, the UE may measure a positon of the UE while avoiding the IDC issue by requesting the release of the RRC conneection to the cell of the NTN system, in case that there is a possibility the IDC issue may occur after connecting to the cell.

[0018] The effects that can be obtained from the disclosure are not limited to the effects mentioned in the various examples, and other effects that are not mentioned can be clearly understood by a person having ordinary skill in the art to which the disclosure belongs from the description below.

[0019] These and other features, aspects, and advantages of the examples are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The examples herein will be better understood from the following description with reference to the drawings, in which:

[0020] Figure 1 illustrates an NTN Release 17 architecture and scenario;

[0021] Figure 2 illustrates a schematic diagram for receiving a timing advance command during the random access procedure;

[0022] Figure 3 illustrates a schematic diagram for detecting a large timing offset during a random access procedure in a non-terrestrial network;

[0023] Figure 4 illustrates a schematic diagram for GNSS-based time and frequency pre-compensation for synchronization in a non-terrestrial network;

[0024] Figure 5 illustrates a schematic diagram of ephemeris synchronization operation in a non-terrestrial network;

[0025] Figure 6 illustrates a schematic diagram of an IoT NTN GNSS validity operation in a non-terrestrial network;

[0026] Figure 7 illustrates an schematic diagram for maintaining UE synchronization without a valid GNSS position using timer T390 in an IoT NTN system;

[0027] Figure 8 illustrates an example of cross link interference between co-existing wireless systems within a single device;

[0028] Figure 9 illustrates a schematic diagram for reporting potential IDC issues in an NTN cell;

[0029] Figure 10 illustrates a schematic diagram for preventive UE position measurement based on network support of IDC in an NTN system, as an example of the disclosure;

[0030] Figure 11 illustrates a method for avoiding IDC issues related to performing a position measurement for synchronization purposes in a NTN in accordance with an example of the disclosure;

[0031] Figure 12 illustrates a method for avoiding IDC issues related to performing a position measurement for synchronization purposes in a NTN in accordance with an example of the disclosure;

[0032] Figure 13 illustrates a Figure 13 illustrates schematic diagram for UE indication of a release preference from an RRC connected state due to IDC issues related to position measurement, as an example of the disclosure;

[0033] Figure 14 illustrates a schematic diagram for indicating IDC issues related to GNSS-based synchronization in a non-terrestrial network, as an example of the disclosure;

[0034] Figure 15 illustrates a method for avoiding IDC issues related to performing a position measurement for synchronization purposes in a NTN in accordance with an example of the disclosure;

[0035] Figure 16 illustrates an example device in accordance with an example of the disclosure.

[0036] Other aspects, advantages, and salient features of the invention will become apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings.

[0037] The following description of examples of the disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of the disclosure, as defined by the claims.　 The description includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the examples described herein can be made.

[0038] The same or similar components may be designated by the same or similar reference numerals, although they may be illustrated in different drawings.

[0039] Detailed descriptions of techniques, structures, constructions, functions or processes known in the art may be omitted for clarity and conciseness, and to avoid obscuring the subject matter of the disclosure.

[0040] The terms and words used herein are not limited to the bibliographical or standard meanings, but, are merely used to enable a clear and consistent understanding of the examples disclosed herein.

[0041] Throughout the description and claims, the words "comprise", "contain" and "include", and variations thereof, for example "comprising", "containing" and "including", means "including but not limited to", and is not intended to (and does not) exclude other features, elements, components, integers, steps, processes, functions, characteristics, and the like.

[0042] Throughout the description and claims, the singular form, for example "a", "an" and "the", encompasses the plural unless the context otherwise requires. For example, reference to "an object" includes reference to one or more of such objects.

[0043] Throughout the description and claims, language in the general form of "X for Y" (where Y is some action, process, function, activity or step and X is some means for carrying out that action, process, function, activity or step) encompasses means X adapted, configured or arranged specifically, but not necessarily exclusively, to do Y.

[0044] Features, elements, components, integers, steps, processes, functions, characteristics, and the like, described in conjunction with a particular aspect, embodiment, example or claim are to be understood to be applicable to any other aspect, embodiment, example or claim disclosed herein unless incompatible therewith.

[0045] The following examples are applicable to, and use terminology associated with, 3GPP 5G.　However, the skilled person will appreciate that the techniques disclosed herein are not limited to these examples or to 3GPP 5G, and may be applied in any suitable system or standard, for example one or more existing and / or future generation wireless communication systems or standards. The skilled person will appreciate that the techniques disclosed herein may be applied in any existing or future releases of　3GPP 5G NR or any other relevant standard.

[0046] For example, the functionality of the various network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in other　communication systems or standards. Corresponding or equivalent entities or features may be regarded as entities or features that perform the same or similar role, function, operation or purpose within the network.

[0047] The skilled person will appreciate that certain examples of the disclosure may not be directly related to standardization but rather proprietary implementation of some of the functions of NR Rel-17 and beyond networks.

[0048] The skilled person will appreciate that the disclosure is not limited to the specific examples disclosed herein. For example:

[0049] The techniques disclosed herein are not limited to 3GPP 5G.

[0050] The techniques disclosed herein are not limited to NTN.

[0051] One or more entities in the examples disclosed herein may be replaced with one or more alternative entities performing equivalent or corresponding functions, processes or operations.

[0052] One or more of the messages in the examples disclosed herein may be replaced with one or more alternative messages, signals or other type of information carriers that communicate equivalent or corresponding information.

[0053] One or more further elements, entities and / or messages may be added to the examples disclosed herein.

[0054] One or more non-essential elements, entities and / or messages may be omitted in certain examples.

[0055] The functions, processes or operations of a particular entity in one example may be divided between two or more separate entities in an alternative example.

[0056] The functions, processes or operations of two or more separate entities in one example may be performed by a single entity in an alternative example.

[0057] Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example.

[0058] Information carried by two or more separate messages in one example may be carried by a single message in an alternative example.

[0059] The order in which operations are performed may be modified, if possible, in alternative examples.

[0060] The transmission of information between network entities is not limited to the specific form, type and / or order of messages described in relation to the examples disclosed herein.

[0061] Certain examples of the disclosure may be provided in the form of an apparatus / device / network entity configured to perform one or more defined network functions and / or a method therefor.　Such an apparatus / device / network entity may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and / or method steps for implementing the techniques described herein. For example, an operation / function of X may be performed by a module configured to perform X (or an X-module).　Certain examples of the disclosure may be provided in the form of a system (e.g. a network) comprising one or more such apparatuses / devices / network entities, and / or a method therefor.

[0062] It will be appreciated that examples of the disclosure may be realized in the form of hardware, software or a combination of hardware and software.　Certain examples of the disclosure may provide a computer program comprising instructions or code which, when executed, implement a method, system and / or apparatus in accordance with any aspect, claim, example and / or embodiment disclosed herein. Certain embodiments of the disclosure provide a machine-readable storage storing such a program.

[0063] [5GNR]

[0064] 5G NR is the latest cellular generation. 5G NR features several new innovations that allow for higher throughput, lower latency and extreme flexibility. Some of these important innovations that are relevant to the disclosure are:

[0065] - Beam-based procedures. The device will take in to account the beams in a cell in several procedures to better accommodate the advancements in MIMO and beamforming seen over the last decade.

[0066] - Ultra-lean carriers: Reduction in the number of "always-on" signals where the network may broadcast reference signals a lot more infrequently compared to previous generations, and allow a network to reduce the amount of system information broadcasted.

[0067] - More efficient state transitions: A new RRC state is introduced, RRC_INACTIVE. In RRC_INACTIVE, the UE performs similar actions as in RRC_IDLE, i.e measuring and performing the cell reselection procedure to ensure that the UE is camping on the best cell. The network will save the UE context in the gNB and the UE will save the RRC configuration. This ensures that the state transition from RRC_INACTIVE and RRC_CONNECTED can be completed in a much smaller number of steps compared to moving from RRC_IDLE to RRC_CONNECTED. In a network where there are a lot of state transitions, this can reduce latency and improve capacity as there is a lot less need for control signals to occupy capacity and resources.

[0068] [5GNRprocedures]

[0069] Below some relevant 5G NR procedures are explained that are relevant to the disclosure.

[0070] Random access and state transitions

[0071] In 5G NR there are three different RRC states: RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED.

[0072] To move to RRC_CONNECTED, a UE must first synchronize and connect to a cell, which it does through the random access procedure.

[0073] The 4-step random access procedure, which is the procedure introduced for the first release of 5G NR, the procedure would include a Msg1 and a Msg2. Msg1 consist of a preamble sent on the Random Access Channel (RACH), which is signals a number from 1 to 64 identifying the UE. Msg2 is the Random Access Response which contains a timing advance to synchronize the UE, as well as an uplink grant to send Msg3. Msg3 contains an RRC message and Msg4 contains the reply to the first RRC message as well as a contention resolution MAC CE to resolve any contention. For 2-step random access the MsgA consists of both the preamble and the first RRC message. MsgB consist of the random access response to synchronize the UE, the reply to the first RRC message as well as contention resolution.

[0074] To move to RRC_CONNECTED from RRC_IDLE, the RRC Setup procedure is triggered. RRC Setup procedures establishes an SRB1 connection along with basic radio configurations. This means that the RRC message RRCSetupRequest will be included in Msg3 and the RRC message RRCSetup may be included in Msg4. After the RRC Setup procedures the network may also have to acquire capabilities, establish AS security before data can transmitted.

[0075] To move to RRC_CONNECTED from RRC_INACTIVE, the RRC Resume procedure is triggered. These procedures allow for the re-establishment of the full RRC connection, as well as resuming the AS security. This means that the RRC message RRCResumeRequest will be included in Msg3 and the RRC message RRCResume may be included in Msg4.

[0076] It should be noted that MAC random access procedures are often independent of the RRC procedures, which means that the random access procedures may in general be the same for RRC Setup, RRC Resume, RRC Re-establishment and RRC reconfiguration with sync.

[0077] RRC Release

[0078] One way to enter RRC idle or RRC inactive mode is by the network releasing the UE through the RRC release procedures. The RRC release procedures are initiated when the UE receives a RRCRelease message from the gNB.

[0079] The RRCRelease message sent from the gNB may in turn have been triggered by the either the gNB or the AMF. This can for instance be due to any of the following reasons:

[0080] - Load balancing

[0081] - Re-direction (both in RRC idle and RRC inactive) to other frequencies or RATs

[0082] - UE context release triggered by the AMF (CN)

[0083] - Suspend indication to send the UE to RRC inactive

[0084] - Failure to retrieve UE context when UE resumes RRC connection from RRC inactive

[0085] System information

[0086] System information is information that is broadcasted by a cell for a wide range of purposes. System information is divided into a set of System Information Blocks (SIB). Some system information is required for a UE to access a cell. Without having acquired these system information blocks the UE may not be allowed to access a cell. In example of such a SIB is SIB1 which contains access information, for instance the PLMN of the cell, the cell identity, the tracking area code as well as cell selection information. SIB1 also contains the serving cell radio configuration.

[0087] Another set of SIBs contain information on other frequencies and RATs for the purpose of idle and inactive mode cell reselection as well as related parameters. These are for instance in SIB2-SIB5.

[0088] [Non-Terrestrial Network]

[0089] NR NTN (NR_NTN_solutions-Core) [RP-211557] was a 3GPP Work Item in 3GPP Release 17 to define solution to enable 5G New Radio (NR) and NG-RAN support Non-Terrestrial Networks. It addressed solution for Transparent payload for both Geostationary and non-Geostationary network scenarios, with the UE having GNSS capability and the satellite beams being both earth-fixed or earth-moving.

[0090] Figure 1 illustrates NTN Release 17 architecture and scenario.

[0091] IoT NTN was a 3GPP study and work item in 3GPP release 17 to provide Non-Terrestrial Network access for E-UTRAN IoT devices (NB-IoT and LTE-M / eMTC) [RP-202689]. And NR NTN was a work item in Rel-17 to specify adaptation to allow NR to function over NTN [RP-211557]. Non-Terrestrial Network access may be through Lower Earth Orbit (LEO), Medium Earth Orbit (MEO) and Geostationary Orbit (GEO), as well as through High-Altitude Platform Systems (HAPS).

[0092] Following the Work items in Release 17 there were work items to enhance NR NTN [RP-220953] and IoT NTN [RP-220979] in Release 18.

[0093] NR NTN phase 3 [RP-234078] is a 3GPP Work Item in 3GPP Release 19 aiming to enhance NR NTN with a range of enhancements:

[0094] - Downlink coverage enhancements

[0095] - Uplink capacity and throughput enhancements by using Orthogonal Coverage Codes

[0096] - MBS broadcast over NTN

[0097] - Introduction of regenerative payload

[0098] - Redcap and NTN enhancements

[0099] - Terrestrial E-UTRAN to NR NTN mobility

[0100] Air-to-Ground

[0101] Air-To-Ground was a 3GPP work item in 3GPP Release 18 to define solutions to enable 5G NR support in Air-to-Ground scenario.

[0102] [NTNSynchronization]

[0103] Figure 2 illustrates a reception of timing advance command during the random access procedure.

[0104] One of the key aspects of OFDMA wireless is to ensure that a UE is well-synchronized before accessing the system. For this, both 4G and 5G relies on random access to ensure that the UE is well-synchronized. During the random access procedure the UE receives a timing advance command for the UE to compensate for its propagation delay with a cell. The frequency offset is generally compensated by the UE adjusting its frequency according to the downlink frequency. This method works for networks which have a cell radius of up to around 10 kilometers. This can be seen in Figure 2.

[0105] NTNSynchronization Release 16

[0106] Figure 3 illustrates schematic diagram for detecting a large timing offset during a random access procedure in a non-terrestrial network.

[0107] During the NTN Release 16 work item, it was discussed how a 5G UE is to synchronize in an NTN cell, considering how synchronization in a 5G terrestrial network is performed. The issue of synchronization in a non-terrestrial network can be said to have 3 components:

[0108] 1) distance between UE and the satellite is several times larger than a terrestrial network from 300 km to 35000 km which means that if the same methods as used for terrestrial networks, the timing advance would potentially have to be very large. The UE may be able to synchronize the downlink, but the uplink cannot so easily synchronized.

[0109] 2) the distance between UE and the gNB changes several times faster than in a terrestrial network, leading to the constant need of adjusting the timing advance.

[0110] 3) the rapid movement of the satellite causes very high doppler frequency offset in the range of 10s of kHz, which the UE needs to track. This is compared to a maximum of 100s of Hz of doppler frequency offset in a terrestrial scenario.

[0111] The two options were either that the UE uses UE location acquired via GNSS to synchronize in time and frequency, or that UE is synchronized in a similar manner to terrestrial network, but increasing the size of the Timing Advance. Using GNSS to synchronize has the drawback that the system becomes reliant on GNSS and that the network has to trust that the UE is capable of self-synchronizing. Increasing the size of Timing Advance would for instance mean that the RACH would become a lot more complicated as the network would be required to detect very large timing offset, which 4G and 5G RACH is not designed to do, as seen in Figure 3.

[0112] NTNSynchronization Release 17

[0113] Figure 4 illustrates a schematic diagram for GNSS-based time and frequency pre-compensation for synchronization in a non-terrestrial network.

[0114] Early on in the NTN standardization phase it was agreed that the UE should rely on GNSS and the satellite / gNB location in order to synchronize. The reason for this is that this allows for the physical layer design of the random access procedures to be reused to a great degree, thereby allowing faster implementations. The UE thus acquires the UE location via GNSS, the location of the satellite and the delay from satellite to gNB on the ground. The doppler frequency offset is pre-compensated by using the UE location and the location of the satellite. The timing advance is pre-compensated by using the UE location, the location of the satellite as well as the delay from the satellite to the gNB, since the Release 17 NTN operates as transparent payload. This can be seen in Figure 4.

[0115] The location of the satellite can be computed based on the ephemeris of the satellite. Ephemeris may be either a PVT vector, which is a vector that gives the position and the velocity of an object, or it may be an information element that containing parameters that define an orbit of an object. This is broadcasted in the system information of the cell along with the common TA which is used to compute the timing advance between the satellite and the gNB on the ground in a transparent payload setting.

[0116] Thus whenever UE connected to an eNB or gNB, the UE needs to read the system information. There is furthermore a timer (T317 in IoT NTN and T430 in 5G NTN) associated with the ephemeris element that is started everytime the system information containing the ephemeris (SIB31 in IoT NTN and SIB19 in NR NTN) is read. In IoT NTN, when T317 expires, the UE is no longer considered synchronized and it will have to re-acquire SIB31 in order to stay synchronized. In NR NTN upon T430 expiry, the UE shall ensure that it has a recent ephemeris by reading the SIB in time by UE implementation. In IoT NTN, since an IoT UE (LTE-M and NB-IoT UE) is not expected to be able to acquire system information in connected mode, the UE tunes away and is likely unreachable while reading SIB31. If the IoT NTN UE is unable to read the SIB31 within a timer (T318) with a configured duration, the UE performs RLF similar to other cases where Radio Link Failure (RLF) is performed.

[0117] The NR NTN and IoT NTN operation can be seen in Figure 5.

[0118] Figure 5 illustrates a schematic diagram of ephemeris synchronization operation in a non-terrestrial network.

[0119] Referring to the Figure 5, where in a) an IoT NTN UE successfully acquires the SIB31, b) where IoT NTN UE fails to read SIB31 during T318 which then expires and triggers RLF and c) where NR NTN UE acquires SIB19 before end of T430 timer.

[0120] The T317 and T430 timers are different compared to a normal timer in RRC as it is not started at having received the LTE SIB31 or NR SIB19. This is because the ephemeris has an epoch time, which is the reference point in time of when the ephemeris is defined. Thus the T317 is started from the epoch time, which may be in the past or in the future relative to have received SIB31. This means that in a UE implementation, the timer may be started with a different value with what was signaled according to what was signaled in the fieldul-SyncValidityDurationin SIB31.

[0121] In both IoT NTN and NR NTN, when a handover is performed to another cell, the handover command will contain ephmeris information so that the UE may synchronize without having to acquire the system information from the target cell.

[0122] The other part of synchronizing is acquiring the GNSS position. It is specified as a requirement that the UE shall have a recent and precise enough GNSS position before the UE attempts to connect to a cell. For instance the UE is required to have determined its own position to be used for time and frequency-synchronization before any RRC procedure is started. In NR NTN, the UE is considered capable of acquiring GNSS position while in connected mode. In IoT NTN, the UE is not considered to be as capable of a device and cannot operate in connected mode and acquire GNSS at the same time. If the GNSS is deemed to be invalid and the UE is in connected mode, the UE shall move to idle mode to ensure that it does not cause interference and it also reduces the requirement for a network to communicate with a UE that might have poor synchronization. In order for the network to know when the UE can be expected to move to idle mode, the UE is required to report its GNSS validity duration in certain RRC messages. This operation can be seen in Figure 6, (a) UE is released (i.e. moved to RRC Idle mode) by eNB, (b) UE releases itself [36.331 v17.3.0].

[0123] Figure 6 illustrates a schematic diagram of an IoT NTN GNSS validity operation in a non-terrestrial network.

[0124] Referring to the Figure 6, in a) is the expected network-controlled operation where the network releases the UE to ensure that eNB knows the state of the UE and in b) the UE releases itself autonomously according to the specification.

[0125] IoTNTNSynchronization Release 18

[0126] Figure 7 illustrates an schematic diagram for maintaining UE synchronization without a valid GNSS position using timer T390 in an IoT NTN system.

[0127] For IoT NTN Release 18, it was realized that the UE may in certain conditions not need to have a recent GNSS position in order to remain synchronized if the UE has previously acquired the GNSS position. It was specified that the conditions for this is that the UE is in connected mode and have previously acquired the GNSS position either before entering connected mode, or when the UE is in connected mode, and the network has configured the feature. A timer (timer T390) is started when the UE GNSS position is invalid which gives how long the UE may stay in connected mode. A newly introduced MAC CE, the UL Transmission Extension Update MAC CE, may be used to re-start the timer. Once the timer expires and the UE has not acquired a new GNSS position, the UE will move to RRC idle. This operation can be seen in Figure 7.

[0128] Redcap UE is a type of UE based on 5G NR designed to have lower implementation complexity compared to a normal 5G UE. It is not intended to replace LPWA and mMTC devices such as LTE-based eMTC or NB-IoT, but rather be somewhere in between those devices and a fully fledged 5G NR device. The target data rates are up to DL / UL 50 Mb / s and 5 Mb / s with acceptable latency and high availability rates. The use cases are from wearables such as intelligent watches, to surveillance cameras and industrial sensors.

[0129] One of the main differences of a Redcap device and a normal 5G NR device is the support of reduced bandwidth and smaller number of receiver branches. A normal 5G NR device supports supports 1600 MHz bandwidth and minimum of 2 or 4 receiver branches while Redcap supports 20 MHz and a minimum of 1 receiver branch. A normal 5G device shall also support maximum DL modulation order of 256QAM and minimum of 2 to 4 DL MIMO layers while redcap supports up to 64QAM and only minimum of 1 DL MIMO layer. This is calculated to allow for device cost reduction of roughly 65%. Redcap does not support other advanced features such as Carrier Aggregation, Multi-Radio Dual Connectivity or advanced mobility features. Redcap also has other set of requirement relaxation such as measurement relaxation.

[0130] To support increased battery lifetime, redcap also supports extended DRX, which allows a UE to sleep for a long time by not requiring the UE to monitor paging while RRC idle and RRC inactive.

[0131] [In-Device co-existence]

[0132] Figure 8 illustrates an example of cross link interference between co-existing wireless systems within a single device.

[0133] Methods for In-Device Co-existence (IDC) have been specified for both LTE (Release 11) and NR (Release 16).

[0134] The core problem that IDC solutions attempt to resolve has to do with Cross Link Interference from different systems within the same device. For instance, a first system in the wireless device transmits in the uplink on a first frequency while a second system in the wireless device receives in the downlink on a second frequency. Ideally, the fact that the two systems use different frequency should mean that there is no interference caused to one another. However, in reality many systems are unable to fully suppress the interference, especially given the large difference in received power in the downlink compared to the uplink transmit power. The uplink transmit power in several types of wireless connectivity solutions can be up 20-23 dBm, while a received signal can be in the range of -90 dBm or even lower. This would mean that the combined band filters of the output signal and the filter that separates transmit and receive chains would need to suppress the uplink transmission by upwards of 1610 dB. If the frequency separation is large enough, then it is expected that both the band filter of the output signal as well as the filter between transmit and receive chains would be able to suppress the interference. However if the frequency separation is not large, then this likely to generate interference to the victim system. An example of this can be seen in Figure 8.

[0135] Figure 9 illustrates a schematic diagram for reporting potential IDC issues in an NTN cell.

[0136] In the 3GPP Technical Report 36.816 V11.2.0, Study on signalling and procedure for interference avoidance for in-device coexistence, the issues and potential solutions are explained.

[0137] Solutions to support IDC problem has been introduced for both LTE and NR. The solutions can largely be divided in to FDM and TDM solutions.

[0138] In FDM solutions, the network attempts to configure frequencies of the UEs in the such a manner as to increase the frequency separation between the victim system and the aggressor system, for instance in the case of in-device interference to GNSS - the network configures the transmissions away from the GNSS signal.

[0139] The assist the network, the UE may signal the affected carrier frequencies, the victim system type, uplink carrier aggregation assistance information. The victim system type that can be signalled can for instance be GPS, GLONASS, BDS, Galileo or NavIC for GNSS and short range communication types such as WLAN and Bluetooth. The UE may also indicate IDC issues related to Multi-Radio Dual Connectivity (MR-DC)

[0140] In TDM solutions, the network configures the UE to momentarily shutdown its cellular TX and RX circuits, for instance via DRX or via measurement gaps.

[0141] The UE may signal TDM assistance information which gives the time when the expected interference is supposed to occur.

[0142] In LTE this can all be sent in an RRC messageInDeviceCoexIndication, while in NR it is sent in the RRC messageUEAssistanceInformationas seen in Figure 9 which shows indicating IDC information A) in LTE, and B) in NR.　In LTE, the UE is configured to send the indication in the information element OtherConfig in RRCConnectionReconfiguration, where the UE may configure the UE to report IDC, whether to indicate UL CA issues as well as IDC issues with MR-DC. In NR the UE is configured via the information element OtherConfig in the RRC message RRCReconfiguration, which configures the IDC assistance configuration. This may configure the UE to either report FDM or TDM assistance information and may also configure the UE to report which serving frequencies that the UE shall report IDC issues on.

[0143] The above information is presented as background information only to assist with an understanding of the disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with regard to the disclosure.

[0144] For both NR NTN and IoT NTN a UE needs to have a valid GNSS position in order to synchronize to a cell. The UE uses GNSS to acquire its position and the UE acquires the position of the satellite via ephemeris and some more assistance information in order to synchronize to a non-terrestrial network.

[0145] Several types of GNSS techniques operate in bands that are adjacent to 3GPP bands. As such, 3GPP has for instance identified that any type of GNSS operating in the frequency range 1559 to 1610 MHz will have difficulty to simultaneously operate with band n255. Band n255 defines an uplink operating band of frequencies 1626.5 - 1660.5 MHz and downlink operating band of frequencies 1525 to 1559 MHz.

[0146] Certain devices, which have more advanced techniques shall be able to handle perfoming GNSS synchronization at the same time as operating in a non-terrestrial network. Certain other devices, such as 4G / 5G cellular IoT devices based on NB-IoT and eMTC are on the other hand strictly not able to perform GNSS acquisition and NTN operation simultaneously, regardless of the frequency separation. However certain cheaper devices such as Redcap devices may have the ability in principle to perform GNSS acquisition and NTN operation, but with reduced performance depending on how close the GNSS signal and the NTN operation is in frequency.

[0147] For this purpose, 3GPP RAN4 requested 3GPP RAN2 to introduce enhancements to IDC to support in-device co-existence solutions in R4-2419898:

[0148] RAN4reach consensus that simultaneousGNSSandNR-NTNoperation for (e)RedcapUEand non-(e)RedcapUEis required, however it cannot be guaranteed　in some occasion for some implementations for someNTNbands.

[0149] For someUEswith limited form factor, e.g. handheldUE,RAN4has identified that simultaneous operation betweenNRNTNtransmission andGNSSreception cannot be guaranteed due to theGNSSreceiver blocking effects and Tx leakage toGNSSreceiver, the problem being worst when the nearby frequency band is transmittinguplink(UL) signal. To avoid any field performance issues both forNRNTNRedCapas well asNRNTNnon-RedCapUEs, a reliable in-device co-existence solution needs to be available in real deployments.

[0150] RAN4respectfully ask to introduce improvements, if necessary, to existing IDC solution(s) and related IDC capabilities to address this in-device coexistence issue betweenGNSSreception andNRNTNtransmission.

[0151] In order to support this requirement and address related problems in similar fields, the disclosure sets out methods to report and avoid IDC issues related to synchronization (for example, NTN-synchronization). IDC related to GNSS in a non-terrestrial network would be a more serious issue compared to a terrestrial network, as the access to the non-terrestrial network is entirely dependent on GNSS. In a terrestrial network, the GNSS would most likely be used for applications, which are not vital to ensure the terrestrial connectivity.

[0152] Aspects of the disclosure include methods for a UE to avoid and report in-device coexistence issues related to a UE performing a position measurement (e.g. position measurement (e.g. GNSS measurement)) for synchronization purposes, for example in NTN.

[0153] Although aspects of the disclosure are described with reference to NTNs, it will be understood that the techniques disclosed herein are not limited to use with NTNs. For example, the ephemeris is not only applicable for satellite payloads, but can also apply to other platforms such as HAPS (high altitude platform systems) or to other types of networks such as Air-To-Ground networks. Thus any mention of "satellite ephemeris" or "satellite" herein may also be applied to other platforms and / or payloads above the earth surface. That is, it will be understood that the techniques disclosed herein may also be applied to such Air-To-Ground networks or High Altitude Platforms, and when reference is made to NTN and / or satellite it may encompass also such other platforms / payloads above the earth surface. Furthermore, the techniques disclosed herein could be applied to terrestrial networks. The techniques may for instance be useful in a terrestrial network if a UE needs to acquire GNSS position in order to allow for measuring an NTN cell.

[0154] "Terrestrial network", when it is used herein, may not only be a land mobile network (e.g. IMT), but may also encompass other terrestrial telecommunication services.

[0155] In the description below, the wording "RRC connected", "connected mode" or "RRC_CONNECTED" may be used interchangeably. It will be understood that the disclosure is not limited to the connected mode being RRC_CONNECTED, and that the techniques described herein may be applied to equivalent or similar connected modes in other communication systems or standards. Similarly, "idle mode", "RRC idle" or "RRC_IDLE" may be used. Sometimes, when methods related to "idle mode" is mentioned, this may also encompass "inactive mode", "RRC inactive" or "RRC_INACTIVE" as the actions performed in those two states in general are the same. It will be understood that the disclosure is not limited to the non-connected modes being RRC_IDLE and RRC_INACTIVE, and that the techniques described herein may be applied to equivalent or similar non-connected modes in other communication systems or standards.

[0156] While this invention is mostly described in terms of 5G NR, all proposals, embodiments, and examples in this invention may also apply for eNBs, NG-eNBs (eNBs connected via 5GC) or 6G NBs. And all related, newly defined and / or existing: RRC signaling and / or messages, X2, Xn, S1, NG, and / or F1 signaling and messages, and / or related network entities (e.g. MME, AMF, other).

[0157] Concepts from 4G and 5G and potential equivalents in a 6G system:

[0158] - 4G and 5G RRC connected state - UE having established a connection with a RAN, i.e a cell, gNB or similar identity.

[0159] - Cell - This may be also be a different concept in a 6G system. For instance in a cell-less case a UE may attach, connect and be associated with a beam or other similar identity.

[0160] - RRC idle - UE not in a RRC connected state, i.e. not having established a connection. RRC idle also means that UE will be camping on a cell or similar identity and then performing measurements and evaluating to find a better cell or similar identity.

[0161] - 5G RRC inactive - UE in a state similar to RRC idle where the UE stores the RRC configuration and resumes the RRC connection using the configuration. The network also stores the UE context and uses it to restore the UE connection.

[0162] - 5G RRC procedures (RRC Setup, RRC Resume, RRC Re-establishment, RRC Reconfiguration) - Any procedures that aims to establish a connection with a cell, a gNB or similar identity. For instance a procedure that aims to establish a 5G-6G Dual Connectivity setting with a 5G and 6G cell.

[0163] - Random access - The process of synchronizing the MAC layer via sending a preamble and receiving a message that synchronizes the uplink, as well as following messages to resolve any contention.

[0164] - Radio Link Failure - Failure of the radio link, which may be a failure based on measured radio signals, or based on operation in the cell, such as a number of retransmissions, random access failures, the radio beams failing etc. After the radio link failure the UE may try to reselect to another cell and re-establish the RRC connection.

[0165] - Handover - Performing active mobility to another cell, gNB or similar identity. May also be termed a 'reconfiguration with synch'.

[0166] - Releasing RRC connection - The UE is released via a messages such as RRC Release that releases the RRC connection the UE has to one or more cells.

[0167] The UE position and position measurements mentioned below may be derived based on GNSS, which may be based on GPS, Galileo, Beidou or GLONASS. The UE position and position measurements mentioned below may also be based on a 3GPP-based position determination such as Downlink Angle of Departure (DL AoD) or Downlink Time Difference of Arrival (DL TDOA) or any other suitable technique to determine the UE position or an estimate of the UE position.

[0168] A 'GNSS measurement' and a 'GNSS position fix' may be considered equivalent for the purposes of the disclosure.

[0169] Although the disclosure mentions GNSS IDC, there may also be issues with IDC when the UE performs positioning, which is used for UE synchronization in a non-terrestrial network. Thus if the UE perform positioning for UE synchronization in an NTN, then these methods for preventing IDC to the positioning may also be used.

[0170] [Methods to avoid IDC issues]

[0171] Figure 10 illustrates a schematic diagram for preventive UE position measurement based on network support of IDC in an NTN system, as an example of the disclosure.

[0172] In one aspect of the disclosure, the network indicates whether it supports handling In-Device Coexistence. This may, for instance, include resolving IDC issues and may include being capable of indication from UE of potential IDC issues.

[0173] This can include, for instance, indicating that the network supports handling IDC issues in a non-terrestrial network. It may also indicate that the network supports handling IDC issues related to position measurement (e.g. GNSS), which may be related to performing GNSS positioning fixes (or other positioning) needed for the UE to synchronize.

[0174] The network indication may be sent in a broadcasted fashion, such as in system information, or in a dedicated fashion.

[0175] In one aspect of the invention, the network support of IDC solutions, which may indicate that the network is capable of supporting to handle IDC issues related to position measurements (e.g. GNSS measurements), may cause certain preventive actions by the UE. This action may be depend on whether the UE is expected to perform position measurements (e.g. GNSS measurements) in the near future, or whether the UE is expected to often need to perform position measurements (e.g. GNSS measurements). This can, for instance, be related to high-speed UEs, as this would increase frequency of performing position measurements (e.g. GNSS measurements)

[0176] If the UE receives information about the network not supporting IDC solutions, then the UE may not expect to be able to perform a position measurement (e.g. GNSS measurement) in connected mode reliably. This may configure or cause the UE to perform position measurements (e.g. GNSS measurements) before connecting to a cell. The scenario may be such that the UE is well-synchronized, but performs a preventive position measurement (e.g. GNSS measurement) to lessen the likelihood of IDC issues occurring due to position measurements (e.g. GNSS measurements). This can be seen in Figure 10. This can be performed during a number of procedures. For instance for RRC setup, RRC resume or RRC re-establishment procedure. For instance, the UE may be configured to perform a position measurement (e.g. GNSS measurement) for preventive measure if a radio link failure occurs which triggers RRC re-establishment procedure. This may mean that the UE is configured to perform a position measurement (e.g. GNSS measurement) if the target cell does not support any IDC handling. This can be specific to redcap UEs.

[0177] This could, for instance, mean that a position measurement (e.g. GNSS measurement) (or any other related action / s) is triggered , for instance before making a connection attempt to a cell if any or any of the combinations of the following conditions (which may be called advance position measurement conditions) are fulfilled:

[0178] The UE has an IDC issue with performing a position measurement (e.g. GNSS measurement), the UE expects an IDC issue with position measurements (e.g. GNSS measurements), or the UE has experienced an IDC issue with position measurements (e.g. GNSS measurements)

[0179] - The UE supports indicating IDC issues with position measurements (e.g. GNSS measurements)

[0180] - The UE determines that a network does not support handling IDC related to position measurements (e.g. GNSS measurements)

[0181] - The UE is a redcap UE

[0182] - The cell is an NTN cell

[0183] The UE performing a position measurement (e.g. GNSS measurement) in advance may also have some further conditions (which may be called non-advance position measurement conditions) that, if fulfilled, cause the UE to attempt to connect to the cell without performing an advance position measurement (e.g. GNSS measurement). That is, if at least one of the non-advance position measurement conditions applies, the UE may not perform a position measurement before attempting to connect to the cell. For example, these conditions may be related to if connecting to the cell is urgent or similar. These conditions can be related to whether the reason for connecting is related to an emergency call. It can be related to whether the amount of data to transmit is very low. For instance, if the UE only has a small buffer, then it may not be expected for any IDC issues to occur because the UE will only be connected for a very short period for which there would be no position measurement (e.g. GNSS measurement) needed.

[0184] The above may for instance be useful for a network to manage devices that have IDC issues with position measurements (e.g. GNSS measurements), i.e. by having UEs perform position measurements (e.g. GNSS measurements) in advance before any IDC issues may occur while the UE is in connected mode.

[0185] During a handover, the network may also indicate to a UE before performing the handover or a reconfiguration with sync that the target cell does or does not support handling position measurement-related (e.g. GNSS-related) IDC. This can for instance be indicated in a handover command, which may be configured by the target cell. This may for instance trigger the UE to perform a position measurement (e.g. GNSS measurement) during the handover execution.

[0186] If the UE receives information about the network not supporting IDC solutions, the cell may be deprioritized or the UE may not attempt to connect to the cell. There may be cases where there are NTN cells on multiple frequencies, where one of the frequencies are close to one or more position measurement signals (e.g. GNSS signals). In this case, if the cell does not support IDC solutions, the UE may deprioritize those cells. The UE may also consider the cell to be barred if the cell does not support an IDC solutions.

[0187] Figure 11 illustrates an example method for avoiding IDC issues related to performing a position measurement for synchronization purposes, for example in an NTN.

[0188] In step 1102, the method comprises determining, by a UE, whether the position measurement should be performed before attempting to connect to a cell.

[0189] In step 1104, the method comprises performing, by the UE in response to determining that the position measurement should be performed before attempting to connect to a cell, the position measurement before attempting to connect to the cell.

[0190] Figure 12 illustrates another example method for avoiding IDC issues related to performing a position measurement for synchronization purposes, for example in an NTN.

[0191] In step 1202, the method comprises determining, by a UE based on an indication received from the network of a cell, whether the network supports handling IDC.

[0192] In step 1204, the method comprises performing, by the UE in response to determining that the network of a cell does not support handling IDC, a preventive action.

[0193] Figure 13 illustrates a schematic diagram for UE indication of a release preference from an RRC connected state due to IDC issues related to position measurement, as an example of the disclosure.

[0194] In one aspect of the disclosure, the UE may indicate a need to be released from RRC connected state with a cell to RRC idle, RRC inactive or any other RRC non-connected state, due to IDC issues related to position measurement (e.g. GNSS) synchronization. This may be configured by the network that UE is allowed or that the UE shall report it. This may be configured together with any type of reported IDC assistance information. This may for instance be triggered if the UE previously reported IDC issues related to position measurement (e.g. GNSS), but it was not resolved. The UE may further include an indication that indicates when the IDC issue is expected to occur for which the UE indicates the release preference for. An example may be seen in Figure 13.

[0195] In one aspect of the disclosure, if the UE indicates IDC assistance information, the release preference may also be indicated, which can be interpreted by the network as the UE preference is to be released if the IDC issue is not attempted to be resolved, or if the network determines that the IDC cannot be efficiently resolved.

[0196] The network may also be required to release the UE if the network determines that the IDC cannot be resolved. This may for instance depend on whether the UE is a redcap UE, or if the UE has for instance indicated a capability which indicates that the UE may have IDC issues related to NTN GNSS (or other position measurement) synchronization.

[0197] The above can be configured or the above can have as a condition that when the UE is operating on frequency bands that are close to position measurement (e.g. GNSS) signals. For instance, the UE can be configured to perform any of the above actions when operating on frequency bands that are close to position measurement (e.g. GNSS) signals. It may also apply if the UE has experienced IDC issues with position measurements (e.g. GNSS measurements) for NTN synchronization in the past. This can for instance be configured if the UE is configured to operate on a band which is within a certain configured bandwidth of the band the UE is performing position measurements (e.g. GNSS measurements) on.

[0198] The UE may report capabilities related to any of the actions above. This can for instance be reported per band.

[0199] Reporting IDC

[0200] Figure 14 illustrates a schematic diagram for indicating IDC issues related to GNSS-based synchronization in a non-terrestrial network, as an example of the disclosure;

[0201] In current IDC solution, it is possible to indicate within the IDC signaling which system is being the victim of the in-device interference. For instance different types of GNSS can be indicated to be the victim system. Although this gives the system information about issues, this may not always be considered crucial and can thus be ignored.

[0202] In a 5G NR and IoT non-terrestrial network, GNSS is considered absolutely crucial for the system, because GNSS is used for synchronization and 4G / 5G-based OFDM requires tight synchronization to operate succesfully. This means that it may not be enough to, for instance, indicate that there are IDC issues with GNSS (e.g. GPS) in order for the network to fully start to compensate for it. Similarly, if the network indicates IDC issues for position measurement (e.g. GNSS) for the purpose of positioning, it may not be suitable for the network to react as if there is an issue with the position measurement-based (e.g. GNSS-based) synchronization. In other words, depending on the use of performing the position measurement (e.g. GNSS), the network action may need to be different. For instance, if the result of indicating issues with position measurement (e.g. GNSS) IDC is that the UE is released, then it may be very important for the network to know the purpose of the position measurement (e.g. GNSS measurement).

[0203] To address this and related issues, in one aspect of the disclosure, the UE indicates there is an issue or if there are expected issues with IDC for the purpose of NTN GNSS-based (or other position measurement-based) synchronization, for example as illustrated in Figure 14. This can be indicated by a flag in the IDC report, or it may be indicated in an information element that indicates the victim system type (victimSystemType), sent by the UE to the network. It can be indicated as part of IDC assistance information or as part of FDM or TDM IDC assistance information.

[0204] If indicated as part of IDC victim system type, then the position measurement type can be indicated (e.g. GNSS type, such as GPS, GLONASS, BDS, Galileo or nav IC) as well. This means that a flag NTN GNSS (or other position measurement) synch IDC and the specific position measurement (e.g. GNSS) type may be indicated, which gives the specific positioning method as well as that the measurement is performed for synchronization purposes . This can be a flag that just indicates TRUE and if the position measurement (e.g. GNSS measurement) is not performed for synchronization purposes, then the flag is not present. It may also be a flag that indicates TRUE or FALSE, but the indication may always need to be present in a non-terrestrial network.

[0205] The UE may also indicate the specific purpose of the position measurement (e.g. GNSS measurement). If the purpose of the position measurement (e.g. GNSS measurement) is for NTN synchronization purposes, then the UE may indicate this in the IDC indication. This can for instance be a bitntn-Synchronization.

[0206] In one aspect of the disclosure, the specific frequency of the position measurement system (e.g. GNSS system) may be indicated. This can be useful for position meansurement systems (e.g. GNSS systems) that may have multiple frequencies.

[0207] In one aspect of the disclosure, the UE indicates information to the network about future expected position measurements (e.g. GNSS measurements), which may also indicate that the UE expects in-device coexistence issues during the measurement. This may take several different forms. This may be an indication that the UE expects future position measurements (e.g. GNSS measurements) to take place. This may be within a specific time frame, which can be hardcoded, say within 10 seconds, or it may be configurable by a network. It may also be an indication that indicates when the next position measurement (e.g. GNSS measurement) will occur, such as for instance an indication that a position measurement (e.g. GNSS measurement) will occur within 10 seconds or a configurable time frame. It may also signal the time the next position measurement (e.g. GNSS measurement) will occur, such as the number of seconds from the message that the position measurement (e.g. GNSS measurement) will occur. It may also be signalled by absolute time. The occurrence of subsequent position measurement (e.g. GNSS measurement), i.e. periodicity of the position measurements (e.g. GNSS measurements) may also be indicated. For instance the periodicity of position measurements (e.g. GNSS measurements) may be every 100 seconds.

[0208] The UE reporting the future position measurements (e.g. GNSS measurements), which may indicate expected IDC issues, can be configurable by the network. This can be configured by system information or using dedicated signaling. The configuration may be considered default to be reported in some cases, such as for a non-terrestrial network that supports redcap, or a non-terrestrial network that supports in-device co-existence handling. The reporting may be signalled in an RRC message, such as a message that completes an RRC procedure (RRCSetupComplete,RRCResumeComplete,RRCReestablishmentComplete,RRCReconfigurationCompleteor similar) - this can be seen in Specification example #4. It may also be signalled in an UEAssistanceInformation message, or any other message that indicates UE information. If　reported in a -Complete message, i.e in a Msg5, such as RRCSetupComplete, RRCResumeComplete or RRCReconfigurationComplete then this can be report in a single bit for instance of potential issues with IDC, or it may be an explicit indication (TRUE / FALSE) whether an issue is expected. Thus the UE may have to be configured before the access attempt, for instance via a broadcasted configuration that the UE shall indicate whether there are any potential IDC issues related to performing GNSS position fix (or other positioning) for the purpose of synchronizing with the NTN cell.

[0209] The condition to report the IDC issue in any -Complete message may, for instance, be that the UE expects to perform a GNSS position fix (or other positioning) within in the near future, for instance within 10 seconds, or a configured threshold. This can be useful in the case where the UE may not have time to perform the procedure as seen in Figure 9, i.e. to wait for the network to configure the UE to report any IDC issues.

[0210] The above UE reporting may be specifically configured for NTN. In other words, the UE may be configured to report issues with IDC specifically for NTN synchronization related issues.

[0211] The UE may also be configured to report IDC assistance information related to NTN GNSS (or other position measurement) synchronization regardless of any configured frequencies, or regardless of any uplink carrier aggregation or dual connectivity issues.

[0212] The UE may also be allowed to transmit an indication of IDC, even if it has previously reported IDC issues. This can for instance be in response due to a new IDC issue, or for instance if the IDC issue is deemed more serious compared to last time it was reported. This is important as currently for IDC, the UE is only allowed to under some specific circumstances, normally just once.

[0213] Figure 15 illustrates an example method for avoiding IDC issues related to performing a position measurement for synchronization purposes in a NTN.

[0214] In step 1502 the method comprises receiving, at a network (e.g. a base station) from a UE, an indication of an IDC issue, wherein the indication comprises information indicating that the IDC issue is related to performing a position measurement for synchronization purposes in a NTN.

[0215] In step 1504, the method comprises performing, by the network in response to receiving the indication, an action for handling the IDC issue.

[0216] [Handling IDC issues]

[0217] Handling IDC issues may involve a number of actions on the part of the network:

[0218] ● Allocating UE with frequency away from the victim of IDC

[0219] ○ Scheduling - the network may schedule the UE with frequency allocations that are further away in frequency (within the frequency band of the cell) from the victim of the IDC.

[0220] ○ BWP allocation - the network may configure the UE with a Bandwidth Part, which is a sub-frequency band of the cell which can be further away from the victim of the IDC

[0221] ○ Carrier aggregation configuration

[0222] ■ The network may configure the UE with secondary cells that are further away in frequency from the victim of the IDC.

[0223] ○ Lowering the network / cell or UE transmit power

[0224] ○ Avoid scheduling the UE or transmitting during certain times when IDC is expected

[0225] ● Performing a handover to a cell on a more suitable frequency

[0226] ○ A source cell that receives information on IDC from a UE may be configured to indicate to a target cell that the UE needs to be handed over to the cell due to position measurement (e.g. GNSS) IDC issues. Then the source cell hands over the UE to another cell, which may be on another frequency.

[0227] ● Performing handover to another Radio Access Technology

[0228] ○ The UE may be handed over to another cell with another RAT that may be able to handle the UE in a better way, or the other RAT may not require GNSS (or the particular position measurement system) to operate.

[0229] ● Configure the UE with measurement gaps. Measurement gaps allow for a UE to not transmit (and receive) cellular signals in order to receive GNSS.

[0230] ● The UE may be configured to perform a different type of positioning, for example UE positioning without using GNSS. This can, for instance, be network-based positioning. Examples of this includes Observed Time Difference of Arrival (OTDOA), where the UE performs measurements to determine the timing between different nodes, which is used by a network to determine the position of the UE. Other examples include Multi-RTT (Multi-Round Trip Time), which uses receive and transmit time difference, or Downlink Angle of Departure (DL AoD) etc. If the UE is configured to perform positioning using network-based techniques, the UE may be configured to cancel its GNSS position fix measurements. Other techniques may also be DL TDOA, UL TDOA or UL AoA.

[0231] The UE may for instance re-configure certain radio channels to other frequencies, in particular uplink radio channels. For instance, the UE may reconfigure the PUCCH channel on to other frequency channels.

[0232] If the network is able to control how the UE performs its position measurement (e.g. GNSS measurement) rather than the UE performing the position measurement (e.g. GNSS measurement) autonomously, the UE may be configured or commanded by the network to perform a position measurement (e.g. GNSS measurement) in connected mode or in idle / inactive mode. The UE may be able to indicate in a message, for instance in the IDC report or any other message, that the UE can rely on the network to order the UE to perform position measurements (e.g. GNSS measurements). Or the UE can alternatively indicate its preference for the network to indicate when to perform a position measurement (e.g. GNSS measurement).

[0233] [Other]

[0234] The UE may also report IDC issues related to position measurement (e.g. GNSS) in NTN occurring in a failure report sent to a gNB. For instance, if the UE reports a failure and indicates that inability to acquire position measurement (e.g. GNSS) to synchronize, or inability to synchronize, the UE may further indicate that the failure to synchronize may have been due to IDC issues.

[0235] This means that a UE may be configured to report IDC issues related to when a failure occurs due to a UE being unable to perform a GNSS position fix (or other position measurement), or being unable to synchronize. Later when the UE is able to connect, and a network requests for information regarding past failure, for instance via a UEInformationRequest, the UE may then indicate that a failure occurred due to this reason.

[0236] The failure report may for instance be sent after a radio link failure occuring, a failed handover or a cell group failure (MCG or SCG failure). This can be sent in a RLF-Report in a UEInformationResponse message, sent in a MCGFailureInformation message or in a SCGFailureInformation message.

[0237] For the purpose of potentially dealing with the IDC issue, a redcap UE may be configured to report the GNSS (or other position measurement) validity duration, i.e. how long a UE expects that the position measurement (e.g. GNSS position fix) shall be valid and potentially when the next position measurement (e.g. GNSS position fix) needs to be performed.

[0238] The UE may for instance be able to indicate that it is capable of performing a position measurement (e.g. GNSS position fix) during DRX.

[0239] Figure 16 is a block diagram of an exemplary device (e.g. UE or network entity, such as a base station) that may be used in examples of the disclosure. The skilled person will appreciate that the device illustrated in Figure 16 may be implemented, for example, as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure.

[0240] The device 1600 comprises a processor 1601 (or controller), a transmitter 1603 and a receiver 1605. The receiver 1605 is configured for receiving one or more messages from one or more other devices. The transmitter 1603 is configured for transmitting one or more messages to one or more other devices. The processor 1601 is configured for performing operations as described above.

[0241] In an example, there is provided a method for avoiding IDC issues related to performing a position measurement for synchronization purposes in a NTN, the method comprising: determining, by a UE, whether the position measurement should be performed before attempting to connect to a cell; and in response to determining that the position measurement should be performed before attempting to connect to a cell, performing, by the UE, the position measurement before attempting to connect to the cell.

[0242] In an example, there is provided the method of the first example, wherein determining if a position measurement should be performed before attempting to connect to a cell comprises determining that a position measurement should be performed before attempting to connect to the cell if at least one advance position measurement condition applies, wherein the advance position measurement condition comprises at least one of: the UE expects an IDC issue with position measurements, the UE has experienced an IDC issue with position measurements, the UE supports indicating IDC issues with position measurements, the UE determines that the network of the cell does not support handling IDC related to position measurements, and the UE is a redcap UE.

[0243] In an example, there is provided the method of the first or second example, wherein determining if a position measurement should be performed before attempting to connect to a cell comprises determining that a position measurement should not be performed before attempting to connect to the cell if at least one non-advance position measurement condition applies, wherein the non-advance position measurement condition comprises at least one of: the UE expects to perform a position measurement within a time threshold, the UE expects to perform position measurement at a frequency greater than a threshold, the cell is an NTN cell, connection to the cell is urgent, connection to the cell is related to performing an emergency call, an amount of data to be transmitted to the cell is below a threshold, and the UE has a buffer size below a threshold.

[0244] In an example, there is provided the method of any one of the first to third examples, wherein determining whether a position measurement should be performed before attempting to connect to a cell comprises: determining, based on an indication from the network of the cell, whether the network supports handling IDC; in response to determining that the network does not support handling IDC, determining that a position measurement should be performed before attempting to connect to the cell; and in response to determining that the network supports handling IDC, determining that a position measurement should not be performed before attempting to connect to the cell.

[0245] In an example, there is provided the method of any one of the first to fourth examples, further comprising: in response to determining that a position measurement should not be performed before attempting to connect to a cell, performing, by the UE, the position measurement after connecting to the cell.

[0246] In an example, there is provided a method for avoiding IDC issues related to performing a position measurement for synchronization purposes in a NTN, the method comprising: determining, by a UE based on an indication received from the network of a cell, whether the network supports handling IDC; and in response to determining that the network of a cell does not support handling IDC, performing, by the UE, a preventive action.

[0247] In an example, there is provided the method of the sixth example, wherein the preventive action comprises at least one of: performing a position measurement before attempting to connect to the cell, deprioritizing the cell, determining not to connect to the cell, and considering the cell to be barred.

[0248] In an example, there is provided the method of the seventh example, wherein performing a position measurement before attempting to connect to the cell comprises determining, by the UE, whether the position measurement should be performed before attempting to connect to a cell, and in response to determining that the position measurement should be performed before attempting to connect to a cell, performing, by the UE, the position measurement before attempting to connect to the cell.

[0249] In an example, there is provided the method of the eighth example, further comprising the method of any one of the second to fifth examples.

[0250] In an example, there is provided the method of any one of the first to ninth examples, wherein the method is performed during at least one of: a handover procedure, a RRC setup procedure, an RRC resume procedure, and an RRC re-establishment procedure.

[0251] In an example, there is provided a method for avoiding IDC issues related to performing a position measurement for synchronization purposes in a NTN, the method comprising: receiving, at a network from a UE, an indication of an IDC issue, wherein the indication comprises information indicating that the IDC issue is related to performing a position measurement for synchronization purposes in a NTN; and in response to receiving the indication, performing, by the network, an action for handling the IDC issue.

[0252] In an example, there is provided the method of the eleventh example, further comprising: receiving, at the network from the UE, information indicating a release preference of the UE; wherein performing, by the network, the action for handling the IDC issue comprises performing the action based on the release preference.

[0253] In an example, there is provided the method of the eleventh or twelfth example, further comprising: determining, by the UE, that an IDC issue is expected to occur in relation to a position measurement for synchronization purposes; and in response to determining, by the UE, that an IDC issue is expected to occur, transmitting, to the network, the indication of the IDC issue.

[0254] In an example, there is provided the method of the thirteenth example, wherein determining that the IDC issue is expected to occur comprises determining based on at least one of: identifying that a position measurement IDC issue has occurred in the past on similar frequencies, identifying that a position measurement IDC issue has occurred in the past on similar beams, identifying that a radio link failure has occurred due to UE being unable to acquire a position fix, the UE being configured to expect IDC issues with position measurements (e.g. on specific frequency bands, for specific networks, for non-terrestrial networks, based on terminal type of the UE, based on interference suppression capabilities of the UE, based on uplink buffer status), a terminal type of the UE, interference / IDC suppression capabilities of the UE, uplink buffer status, frequency, output power, position measurement receiver characteristics, and UE uplink transmission bandwidth.

[0255] In an example, there is provided the method of any one of the eleventh to fourteenth examples, wherein the indication of the IDC issue comprises at least one of: an indication that an IDC issue has occurred, an indication that an IDC issue is expected to occur, an IDC victim system type, a position measurement type, a position measurement frequency, and a position measurement purpose.

[0256] In an example, there is provided the method of any one of the eleventh to fifteenth examples, further comprising receiving, at the network from the UE, information about future expected position measurements.

[0257] In an example, there is provided the method of the sixteenth example, wherein the information about future expected position measurements comprises at least one of: an indication that the UE expects future position measurements to take place, an indication that the UE expects future position measurements to take place within a specific time frame, an indication of when the next position measurement will occur, and a periodicity of the position measurements.

[0258] In an example, there is provided the method of the sixteenth or seventeenth examples, further comprising configuring, by the network, the UE to report the information about the future expected position measurements.

[0259] In an example, there is provided the method of any one of the sixteenth to eighteenth examples, wherein the information about future expected position measurements is received in at least one of: an RRC message, a message completing an RRC procedure, a message that indicates UE information, and a UE assistance information message.

[0260] In an example, there is provided the method of any one of the eleventh to nineteenth examples, wherein performing, by the network, an action for handling the IDC issue comprises performing at least one of: releasing the UE, allocating UE a frequency further away from the victim of IDC, scheduling the UE with frequency allocations further away in frequency from the victim of the IDC, configuring the UE with a Bandwidth Part further away in frequency from the victim of the IDC, configuring the UE with secondary cells that are further away in frequency from the victim of the IDC, lowering the network / cell or UE transmit power, avoiding scheduling the UE or transmitting during certain times when IDC is expected, performing a handover to a cell on a more suitable frequency, performing handover to another Radio Access Technology, configuring the UE with at least one measurement gap, configuring the UE to perform a different type of UE positioning, configuring the UE to re-configure at least one radio channel (e.g. an uplink radio channel) to another frequency, and configuring the UE to perform the position measurement in at least one of a connected mode, an idle mode, and an inactive mode.

[0261] In an example, there is provided the method of any one of the eleventh to twentieth examples, wherein the indication of an IDC issue is received in a failure report.

[0262] In an example, there is provided the method of any one of the first to twenty-first examples, wherein the position measurement is a GNSS measurement.

[0263] In an example, there is provided the method of any one of the first to twenty-second examples, wherein the UE is a redcap UE.

[0264] In an example, there is provided a user equipment configured to operate according to a method of any of the first to twenty-third examples.

[0265] In an example, there is provided a network entity (e.g. a base station) configured to operate according to a method of any one of the first to twenty-third examples.

[0266] In an example, there is provided a network or wireless communication system comprising a UE according to the twenty-fourth example and a network entity according to the twenty-fifth example.

[0267] In an example, there is provided a computer program comprising instructions which, when the program　 is executed by a computer or processor, cause the computer or processor to carry out a method according to any one of the first to twenty-third examples.

[0268] In an example, there is provided a computer or processor-readable data carrier having stored thereon a computer program according to　the twenty-seventh example.

[0269] In an example, there is provided a method for avoiding IDC issues related to performing a position measurement for synchronization purposes in a NTN, the method comprising: determining, by a UE, whether the position measurement should be performed before attempting to connect to a cell; and in response to determining that the position measurement should be performed before attempting to connect to a cell, performing, by the UE, the position measurement before attempting to connect to the cell.

[0270] In an example, there is provided the method of the twenty-ninth example, wherein determining if a position measurement should be performed before attempting to connect to a cell comprises determining that a position measurement should be performed before attempting to connect to the cell if at least one advance position measurement condition applies, wherein the advance position measurement condition comprises at least one of: the UE expects an IDC issue with position measurements, the UE has experienced an IDC issue with position measurements, the UE supports indicating IDC issues with position measurements, the UE determines that the cell does not support handling IDC (e.g. that the cell does not support handling IDC issues related to position measurements and / or that the cell does not support handling IDC issues in a NTN), and the UE is a redcap UE.

[0271] In an example, there is provided the method of the twenty-ninth or thirtieth example, wherein determining if a position measurement should be performed before attempting to connect to a cell comprises determining that a position measurement should not be performed before attempting to connect to the cell if at least one non-advance position measurement condition applies, wherein the non-advance position measurement condition comprises at least one of: the UE expects to perform a position measurement within a time threshold, the UE expects to perform position measurement at a frequency greater than a threshold, the cell is an NTN cell, connection to the cell is urgent, connection to the cell is related to performing an emergency call, an amount of data to be transmitted to the cell is below a threshold, and the UE has a buffer size below a threshold.

[0272] In an example, there is provided the method of any one of the twenty-ninth to thirty-first examples, wherein determining whether a position measurement should be performed before attempting to connect to a cell comprises: determining, based on an indication from the cell, whether the cell supports handling IDC (e.g. whether the cell supports handling IDC issues related to position measurements and / or whether the cell supports handling IDC issues in a NTN); in response to determining that the cell does not support handling IDC, determining that a position measurement should be performed before attempting to connect to the cell; and in response to determining that the cell supports handling IDC, determining that a position measurement should not be performed before attempting to connect to the cell.

[0273] In an example, there is provided the method of the thirty-second example, wherein the indication is received via broadcasted information (e.g. in system information) or in dedicated signaling.

[0274] In an example, there is provided the method of any one of the twenty-ninth to thirty-third examples, further comprising: in response to determining that a position measurement should not be performed before attempting to connect to a cell, performing, by the UE, the position measurement after connecting to the cell.

[0275] In an example, there is provided the method of the thirty-fourth example, further comprising reporting, by the UE after connecting to the cell, IDC related issues (e.g. IDC issues related to position measurements) to the cell.

[0276] In an example, there is provided a method for avoiding IDC issues related to performing a position measurement for synchronization purposes in a NTN, the method comprising: determining, by a UE based on an indication received from the network of a cell, whether the network supports handling IDC; and in response to determining that the network of a cell does not support handling IDC, performing, by the UE, a preventive action.

[0277] In an example, there is provided the method of the thirty-sixth example, wherein determining, by a UE based on an indication received from the network of a cell, whether the network supports handling IDC, comprises at least one of: determining, by the UE based on the indication received from the cell, whether the network supports handling IDC issues related to position measurements, and determining, by the UE based on the indication received from the cell, whether the network supports handling IDC issues in a NTN.

[0278] In an example, there is provided the method of the thirty-sixth or thirty-seventh example, wherein the indication is received via broadcasted information (e.g. in system information) or in dedicated signaling.

[0279] In an example, there is provided the method of any one of the thirty-sixth to thirty-eighth examples, wherein the preventive action comprises at least one of: performing a position measurement before attempting to connect to the cell, deprioritizing the cell, determining not to connect to the cell, and considering the cell to be barred.

[0280] In an example, there is provided the method of the thirty-ninth example, wherein performing a position measurement before attempting to connect to the cell comprises determining, by the UE, whether the position measurement should be performed before attempting to connect to a cell, and in response to determining that the position measurement should be performed before attempting to connect to a cell, performing, by the UE, the position measurement before attempting to connect to the cell.

[0281] In an example, there is provided the method of the thirty-sixth example, further comprising the method of any one of the thirtieth to thirty-fifth examples

[0282] In an example, there is provided the method of any one of the twenty-ninth to thirty-seventh examples, wherein the method is performed during at least one of: a handover procedure, a RRC setup procedure, an RRC resume procedure, and an RRC re-establishment procedure.

[0283] In an example, there is provided a method for avoiding IDC issues related to performing a position measurement for synchronization purposes in a NTN, the method comprising: receiving, at a network from a UE, an indication of an IDC issue, wherein the indication comprises information indicating that the IDC issue is related to performing a position measurement for synchronization purposes in a NTN; and in response to receiving the indication, performing, by the network, an action for handling the IDC issue.

[0284] In an example, there is provided the method of the forty-third example, further comprising: receiving, at the network from the UE, information indicating a release preference of the UE; wherein performing, by the network, the action for handling the IDC issue comprises performing the action based on the release preference.

[0285] In an example, there is provided the method of the forty-third or forty-fourth example, further comprising: determining, by the UE, that an IDC issue is expected to occur in relation to a position measurement for synchronization purposes; and in response to determining, by the UE, that an IDC issue is expected to occur, transmitting, to the network, the indication of the IDC issue; wherein determining that the IDC issue is expected to occur comprises determining based on at least one of: identifying that a position measurement IDC issue has occurred in the past on similar frequencies, identifying that a position measurement IDC issue has occurred in the past on similar beams, identifying that a radio link failure has occurred due to UE being unable to acquire a position fix, the UE being configured to expect IDC issues with position measurements (e.g. on specific frequency bands, for specific networks, for non-terrestrial networks, based on terminal type of the UE, based on interference suppression capabilities of the UE, based on uplink buffer status), a terminal type of the UE, interference / IDC suppression capabilities of the UE, uplink buffer status, frequency, output power, position measurement receiver characteristics, and UE uplink transmission bandwidth.

[0286] In an example, there is provided the method of any one of the forty-third to forty-fifth examples, wherein the indication of the IDC issue comprises at least one of: an indication that an IDC issue has occurred, an indication that an IDC issue is expected to occur, an IDC victim system type, a position measurement type, a position measurement frequency, and a position measurement purpose.

[0287] In an example, there is provided the method of any one of the forty-third to forty-sixth examples, further comprising receiving, at the network from the UE, information about future expected position measurements, wherein the information about future expected position measurements comprises at least one of: an indication that the UE expects future position measurements to take place, an indication that the UE expects future position measurements to take place within a specific time frame, an indication of when the next position measurement will occur, and a periodicity of the position measurements; and further comprising configuring, by the network, the UE to report the information about the future expected position measurements, wherein the information about future expected position measurements is received in at least one of: an RRC message, a message completing an RRC procedure, a message that indicates UE information, and a UE assistance information message.

[0288] In an example, there is provided the method of any one of the forty-third to forty-seventh examples, wherein performing, by the network, an action for handling the IDC issue comprises performing at least one of: releasing the UE, allocating UE a frequency further away from the victim of IDC, scheduling the UE with frequency allocations further away in frequency from the victim of the IDC, configuring the UE with a Bandwidth Part further away in frequency from the victim of the IDC, configuring the UE with secondary cells that are further away in frequency from the victim of the IDC, lowering the network / cell or UE transmit power, avoiding scheduling the UE or transmitting during certain times when IDC is expected, performing a handover to a cell on a more suitable frequency, performing handover to another Radio Access Technology, configuring the UE with at least one measurement gap, configuring the UE to perform a different type of UE positioning, configuring the UE to re-configure at least one radio channel (e.g. an uplink radio channel) to another frequency, and configuring the UE to perform the position measurement in at least one of a connected mode, an idle mode, and an inactive mode.

[0289] In an example, there is provided the method of any one of the forty-third to forty-eighth examples, wherein the indication of an IDC issue is received in a failure report.

[0290] In an example, there is provided the method of any one of the twenty-ninth to forty-ninth examples, wherein the position measurement is a GNSS measurement.

[0291] In an example, there is provided the method of any one of the twenty-ninth to fiftieth examples, wherein the UE is a redcap UE.

[0292] In an example, there is provided a user equipment (UE) configured to operate according to a method of any of the twenty-ninth to fifty-first examples.

[0293] In an example, there is provided a network entity (e.g. a base station) configured to operate according to a method of any one of the twenty-ninth to fifty-first examples.

[0294] In an example, there is provided a network or wireless communication system comprising a UE according to the fifty-second example and a network entity according to the fifty-third example.

[0295] In an example, there is provided a computer program comprising instructions which, when the program　 is executed by a computer or processor, cause the computer or processor to carry out a method according to any one of the twenty-ninth to fifty-first example.

[0296] In an example, there is provided a computer or processor-readable data carrier having stored thereon a computer program according to　the fifty-fifth example.

[0297] While the invention has been shown and described with reference to certain examples, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the invention, as defined by the appended claims.

[0298] Certain examples of the disclosure provide one or more techniques as disclosed in the appended annex to the description. The skilled person will appreciate that any of these techniques may be applied in combination with any of the techniques described above and illustrated in the Figures.

[0299] By way of further explanation, examples of how the existing 3GPP standards might be modified in view of certain aspects of the disclosure are provided. The examples of how the existing 3GPP standards might be modified, which are associated with an implement for the examples of the disclosure, is shown as Table 1, 2, 3 and / or 4, not limited hereto.

[0300]

[0301]

[0302]

[0303]

[0304] In the disclosure, the following abbreviations and definitions may be used, as shown in Table 5.

[0305]

Claims

1.A method performed by a user equipment (UE) in a wireless communication system, the method comprising:determining to transition from a radio resource control (RRC) idle state or an RRC inactive state to an RRC connected state for accessing a cell of a base station in a non-terrestrial network (NTN) system;identifying whether a first condition for performing a preventive action is satisfied, wherein the preventive action includes measuring a position of the UE before attempting to access the cell; andin case that the first condition is satisfied, performing the preventive action.2.The method of claim 1,wherein the first condition includes at least one of:the UE expects an in-device co-existence (IDC) issue with measuring the position of the UE;the UE has experienced the IDC issue;the UE supports indicating the IDC issue;the UE determines that the cell does not support handling the IDC issue; andthe UE is a reduced-capability (RedCap) UE.3.The method of claim 1, further comprising:identifying whether a second condition is satisfied; andin case that the first condition is satisfied and the second condition is satisfied, accessing the cell before measuring the position of the UE,wherein, in case that the first condition is satisfied and the second condition is not satisfied, the position of the UE is measured before accessing the cell,wherein the second condition includes at least one of:the UE expects to measure the position of the UE within a time threshold;the UE expects to measure the position of the UE at a frequency greater than a first threshold;the cell is an NTN cell;accessing the cell is urgent;accessing the cell is related to performing an emergency call;an amount of data to be transmitted to the cell is below a second threshold; andthe UE has a buffer size below a third threshold.4.The method of claim 1,wherein the first condition includes a reception of indication information, transmitted from the base station, indicating whether the cell supports a handling of an in-device co-existence (IDC) issue associated with measuring the position of the UE,wherein, in case that the indication information indicates that the cell does not support handling of the IDC issue, the first condition is not satisfied,wherein, in case that the indication information indicates that the cell supports handling of the the IDC issue, the first condition is satisfied, andwherein the indication is received via broadcasted information.5.The method of claim 4,wherein the preventive action further includes at least one of:deprioritizing the cell;determining not to access the cell; andconsidering the cell to be barred.6.The method of claim 1, further comprising:in case that the first condition is not satisfied, measuring the position of the UE after accessing the cell; andtransmitting, to the base station, a report of an in-device co-existence (IDC) issue associated with measuring the position of the UE.7.The method of claim 1, further comprising:determining to release an RRC connection to the cell after accessing the cell;transmitting, to the base station, first information indicating a release preference of the UE for requesting handling the an in-device co-existence (IDC) issue associated with measuring the position of the UE; andreceiving, from the base station, second information indicating a release of the RRC connection,wherein the second information is received based on a failure of the handling of the IDC issue.8.The method of claim 7, further comprising:transitioning from the RRC connected state to the RRC idle state; andmeasuring the position of the UE.9.A user equipment (UE) in a wireless communication system, the UE comprising:at least one transceiver;at least one processor coupled to the at least one transceiver; andmemory coupled to the at least one processor storing instructions executable by the at least one processor;wherein the instructions cause the UE to:determine to transition from a radio resource control (RRC) idle state or an RRC inactive state to an RRC connected state for accessing a cell of a base station in a non-terrestrial network (NTN) system,identify whether a first condition for performing a preventive action is satisfied, wherein the preventive action includes measuring a position of the UE before attempting to access the cell, andin case that the first condition is satisfied, perform the preventive action.10.The UE of claim 9,wherein the first condition includes at least one of:the UE expects an in-device co-existence (IDC) issue with measuring the position of the UE;the UE has experienced the IDC issue;the UE supports indicating the IDC issue;the UE determines that the cell does not support handling the IDC issue; andthe UE is a reduced-capability (RedCap) UE.11.The UE of claim 9,wherein the instructions further cause the UE to:identify whether a second condition is satisfied, andin case that the first condition is satisfied and the second condition is satisfied, access the cell before measuring the position of the UE,wherein, in case that the first condition is satisfied and the second condition is not satisfied, the position of the UE is measured before accessing the cell,wherein the second condition includes at least one of:the UE expects to measure the position of the UE within a time threshold;the UE expects to measure the position of the UE at a frequency greater than a first threshold;the cell is an NTN cell;accessing the cell is urgent;accessing the cell is related to performing an emergency call;an amount of data to be transmitted to the cell is below a second threshold; andthe UE has a buffer size below a third threshold.12.The UE of claim 9,wherein the first condition includes a reception of indication information, transmitted from the base station, indicating whether the cell supports a handling of an in-device co-existence (IDC) issue associated with measuring the position of the UE,wherein, in case that the indication information indicates that the cell does not support handling of the IDC issue, the first condition is not satisfied,wherein, in case that the indication information indicates that the cell supports handling of the the IDC issue, the first condition is satisfied, andwherein the indication is received via broadcasted information.13.The UE of claim 12wherein the preventive action further includes at least one of:deprioritizing the cell;determining not to access the cell; andconsidering the cell to be barred.14.The UE of claim 9,wherein the instructions further cause the UE to:in case that the first condition is not satisfied, measure the position of the UE after accessing the cell, andtransmit, to the base station, a report of an in-device co-existence (IDC) issue associated with measuring the position of the UE.15.The UE of claim 9, further comprising:wherein the instructions further cause the UE to:determine to release an RRC connection to the cell after accessing the cell,transmit, to the base station, first information indicating a release preference of the UE for requesting handling the an in-device co-existence (IDC) issue associated with measuring the position of the UE,receive, from the base station, second information indicating a release of the RRC connection,transition from the RRC connected state to the RRC idle state, andmeasure the position of the UE,wherein the second information is received based on a failure of the handling of the IDC issue.

Images