A user equipment, a base station, a system, and a method for optimising a network configuration

Abstract

A user equipment, UE, is configured to collect non-terrestrial network, NTN, information for optimising a network configuration and transmit the collected NTN information to a base station. The base s

Description

The present invention relates to a user equipment (UE), a base station, a system, and a method for optimising a network configuration. Some embodiments / aspects relate to a UE configured to collect non-terrestrial network, NTN, information for optimising a network configuration, and transmit the collected NTN information to a base station. BACKGROUND Non-Terrestrial Network NR NTN (NR_NTN_solutions-Core) [RP-211557] was a 3rd generation partnership project (3GPP) Work Item in 3GPP Release 17 to define a solution to enable New Radio (NR) and next generation radio access network (NG-RAN) to support Non-Terrestrial Networks. It addressed solution for Transparent payload for both Geostationary and non-Geostationary network scenarios, with the UE having global navigation satellite system (GNSS) capability and the satellite beams being both earth-fixed or earth-moving. FIG. 1A shows NTN Release 17 architecture and scenario. FIG. 1B shows NTN release 19 regenerative architecture. Internet of Things (loT) NTN was a 3GPP study and work item in 3GPP release 17 to provide Non-Terrestrial Network access for evolved universal terrestrial radio access network (E-UTRAN) loT devices (narrowband (NB)-loT and long term evolution machine (LTE-M) / enhanced machine type communication (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 served via satellites that are in Lower Earth Orbit (LEO), Medium Earth Orbit (MEO) and Geostationary Orbit (GEO), as well as through High-Altitude Platform Systems (HAPS). Following the Work items in Release 17 there were work items to enhance NR NTN [RP-220953] and loT NTN [RP-220979] in Release 18. 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: Downlink coverage enhancements Uplink capacity and throughput enhancements by using Orthogonal Coverage Codes MBS broadcast over NTN Introduction of regenerative payload Redcap and NTN enhancements - Terrestrial E-UTRAN to NR NTN mobility 5 NTN system information As NTN has a number of NTN-specific information elements that are only required when accessing an NTN cell, and also due to the rather large information elements it was agreed that new system information blocks (SIB) was needed. 10 In NR NTN SIB19 contains the required information to access an NTN cell: ------------------------------38.331 V18.1.0 [1]------------------------------ SIB19 15 SIB19 contains satellite assistance information for NTN access. FIG.2 shows an example SIB19 information element. Table 1 shows SIB19 field descriptions. Table 2 shows NTN-CovEnh field descriptions. Table 3 shows satSwitch With ReSync field descriptions. [ S / B79 field descriptions i distanceThresh ; Distance from the serving cell reference location and is used in location-based measurement initiation in RRCJDLE and RRCJNACTIVE, as defined in TS 38.304

[20] , Each step i represents 50m. This field is only present in an NTN cell. i movingReferenceLocation Reference location of the serving cell of an NTN Earth moving system at a time reference. It is used in the evaluation of eventD2 and condEventD2 criteria for the serving cell in RRCCONNECTED, and location-based measurement initiation in RRCJDLE and RRCJNACTIVE when distanceThresh is also configured, as defined in TS 38.304

[20] , The time reference of this field is indicated by epochTime in ntn-Config of the serving cell. This field is excluded when determining changes in system information, i.e., changes to movingReferenceLocation should neither result in system information change notifications i nor in a modification of valueTag in SIB1. This field is only present in an NTN cell. ntn-Config Provides parameters needed for the UE to access NR via NTN access such as Ephemeris data, common TA parameters, k_offset, validity duration for UL sync information and epoch. In a TN cell, this field is only present in ntn-NeighCellConfigList and ntn- [ NeighCellConfigListExt. i ntn-NeighCellConfigList, ntn-NeighCellConfigListExt i Provides a list of NTN neighbour cells including their ntn-Config, carrier frequency and i PhysCellld. This set includes all elements of ntn-NeighCellConfigList and all elements of ntn-i NeighCellConfigListExt. If ntn-Config is absent for an entry in ntn-NeighCellConfigListExt, the i ntn-Config provided in the entry at the same position in ntn-NeighCellConfigList applies. i Network provides ntn-Config for the first entry of ntn-NeighCellConfigList. If the ntn-Config is i absent for any other entry in ntn-NeighCellConfigList, the ntn-Config provided in the previous i entry in ntn-NeighCellConfigList applies.______________________________________________________ i referenceLocation i Reference location of the serving cell provided via NTN quasi-Earth fixed system and is used i in location-based measurement initiation in RRCJDLE and RRCJNACTIVE, as defined in i TS 38.304

[20] , This field is only present in an NT i satSwitchWithReSync Provides parameters for the target satellite required to perform satellite switch with resynchronization. This field is only present in an NTN cell and its presence indicates that i satellite switch without PCI change is supported in the cell.____________________________________ | t-Service Indicates the time information on when a cell provided via NTN system is going to stop serving the area it is currently covering. This field applies for both service link switches in NTN quasi-Earth fixed system and feeder link switches for both NTN quasi-Earth fixed and Earth moving system. The field indicates a time in multiples of 10 ms after 00:00:00 on Gregorian calendar date 1 January, 1900 (midnight between Sunday, December 31,1899 and Monday, January 1,1900). The exact stop time is between the time indicated by the value of this field minus 1 and the time indicated by the value of this field. The reference point for t-Service is the uplink time synchronization reference point of the cell. This field is only i present in an NTN cell. Table 1 - SIB19 field descriptions NTN-CovEnh field descriptions numberOfMsg4-RepetitionsList The number of repetitions for PUCCH transmission for Msg4 HARQ-ACK, see clause 9.2.6 in TS 38.213

[13] . The value {n1} needs to be configured with another value from the list {n2, n4, n8}. If more than one value is configured, a single value from the configured values is indicated in PCI.______________________________________________________________________________________________ rsrp-ThresholdMsg4 This threshold used by the UE for determining the report of the capability of PUCCH repetition for Msg4 HARQ-ACK if numberOfMsg4-RepetitionsList is provided, as specified in TS 38.321 131___________________________________________________________________________________ Table 2 - NTN-CovEnh field descriptions satSwitchWithReSync field descriptions | ssb-TimeOffset i Indicates the time offset between the SSB from source and target satellite at the uplink time i synchronization reference point. It is given in number of subframes.____________________________ i t-ServiceStart i Indicates the time information on when the target satellite is going to start serving the area i currently covered by the serving satellite. The field indicates a time in multiples of 10 ms after i 00:00:00 on Gregorian calendar date 1st January 1900 (midnight between Sunday, December i 31,1899, and Monday, January 1,1900). The exact start time is between the time indicated by i the value of this field minus 1 and the time indicated by the value of this field. The reference point for f-Serv / ’ceStart is the uplink time synchronization reference point of the serving satellite. fable 3 - satSwitchWithReSync field descriptions 38.331 V18.1.0 [1] In loT NTN SIB31 contains the required information to access an loT NTN cell: 36.331 V18.1.0 [2] - SystemlnformationBlockType31 The IE SystemlnformationBlockType31 contains satellite assistance information for the serving cell. SystemlnformationBlockType31 is only signalled for an NTN cell. FIG.3 shows an example SystemlnformationBlockType31 information element. Table 4 shows SystemlnformationBlockType31 field descriptions. SystemlnformationBlockType31 field descriptions i distanceThresh ; Distance from the serving cell reference location and is used in location-based measurement i initiation in RRC_IDLE (as specified in TS 36.304 [4]) and RRC_CONNECTED. Each step i represents 50m. i epochTime i Epoch time of the satellite ephemeris data and common TA parameters, see TS 36.213

[23] . i This field also indicates the epoch time for the reference location of earth moving cells if i present. The reference point for epoch time of the serving satellite ephemeris and Common i TA parameters is the uplink time synchronization reference point. i epochTime is the starting time of a DL subframe indicated by startSFN and startSubframe. i For serving cell, the startSFN indicates the current SFN or the next upcoming SFN after the i frame where the message indicating the epochTime is received. i If the field is absent, the UE uses the starting time of the DL subframe corresponding to the i end of the SI window during which the SI message carrying SIB31 (-NB) is transmitted. i E-UTRAN always includes epochTime when SIB31(-NB) is provided through dedicated i signalling. i In case of handover or conditional handover, this field is based on the timing of the target cell, i i.e. the startSFN and startSubFrame number indicated in this field refers to the SFN and sub-i frame of the target cell, and UE considers the target cell epoch time (indicated by the startSFN i and startSubFrame in this field) to be the frame nearest to the frame where i RRCConnectionReconfiguration message is received. i k-Mac ; Scheduling offset used when downlink and uplink frame timing are not aligned at the eNB, i see TS 36.213

[23] . Unit in ms. | If the field if absent, the UE uses the (default) value of 0._______________________________________ | k-Offsei i Scheduling offset used in the timing relationships in NTN, see TS 36.213

[23] , Unit in ms. nta-Common Network-controlled common TA, see TS 36.213

[23] . Unit of ps. Step of 32.55208 x10 3 ps. Actual value = field value * 32.55208 x10 3. [ If the field is absent, the UE uses the (default) value of 0. i nta-CommonDrift i Drift rate of the common TA, see TS 36.213

[23] . Unit of ps / s. i Step of 0.2 x10'3 ps / s. Actual value = field value * 0.2 x10'3. i If the field is absent, the UE uses the (default) value of 0. i ntaCommonDriftVariation i Drift rate variation of the common TA, see TS 36.213

[23] . Unit of ps / s2. i Step of 0.2 xio-4 ps / s2. Actual value = field value * 0.2 xio-4. i If the field is absent, the UE uses the (default) value of 0. i orbitalParameters ; Instantaneous values of the satellite orbital parameters. The signalled values are valid at least | for the duration as defined by ul-SyncValidityDuration and epochTime.______________________ referenceLocation Reference location of the NTN (quasi-)earth fixed cell or earth moving cell, used in location-based measurement initiation in RRC_IDLE (as specified in TS 36.304 [4]) and RRC_CONNECTED if distanceThresh is also configured. If configured by an earth moving cell, the broadcast reference location corresponds to the epoch time and is also used in the evaluation of of Event D2 and CondEvent D2, and the UE derives the real-time reference i location based on the serving satellite ephemeris, see TS 36.304 [4],_______________________ stateVectors ; Instantaneous values of the satellite state vectors. The signalled values are valid at least for i the duration as defined by ul-SyncValidityDuration and epochTime. i ul-SyncValidityDuration Validity duration of the satellite ephemeris data and common TA parameters, i.e. maximum time duration (from epochTime) during which the UE can apply the satellite ephemeris without acquiring new satellite ephemeris, see TS 36.213

[23] , Unit in second. Value s5 corresponds to 5 seconds, value s10 corresponds to 10 seconds and so on. The ul-SyncValidityDuration is only updated when at least one of epochTime, nta-\ Common Parameters, ephem^ Table 4 - SystemlnformationBlockfype31 field descriptions ------------------------------36.331 V18.1.0 [2]------------------------------ The system information contains the following: Serving cell Ephemeris elements - which allows UE to calculate the satellite position for doppler and time pre-compensation. This can be of two formats: o PVT format - which describes a (X,Y,Z) position as well as a speed vector (vX, vY, vZ) o Orbital parameters - this describes the orbital movements of the satellite which is then used to infer the satellite position TA common parameters - this provides the common timing advance parameters which is introduced to compensate for the feeder link delays. The signaling consists of (in total taking up 57 bits) o Absolute TA common, taking up 23 bits o Drift of the TA common - how the TA common drifts, i.e the first derivative, taking up 19 bits o Variation of the TA common - how the TA common varies, i.e the second derivative of the TA common, taking up 15 bits Synchronization validity duration - used to define how long the ephemeris and TA common is valid Epoch time - when the synchronization validity duration should start K-Offset - scheduling offset for timing relationship in NTN K-Mac - Scheduling offset used when the downlink and uplink frame timing is not aligned NR NTN specific information also include (as part of 38.331): o T-Service (signaled in SIB3 in loT NTN) o Reference location and distance threshold - used for location-based measurement initiation in RRC IDLE and RRC Connected mode o Neighbour cell ephemeris ■ This is used for idle mode measurements NTN System information acquiry As the ephemeris constantly changes due to the movement of the NTN payload, there is a need to make sure that the UE is correctly synchronized. Thus whenever UE connected to an eNB, the UE needs to read the system information. There is furthermore a timer (T317) associated with the ephemeris element that is started everytime SIB31 is read. At expiry of T317, the UE is no longer considered synchronized and it will have to re-acquire SIB31 in order to stay synchronized. In NR NTN, the UE shall ensure that it has a recent ephemeris (SIB19 in NR) by reading the SIB in time by UE implementation. In loT NTN, since an loT UE (LTE-M and NB-loT 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 loT 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. This operation can be seen in Figure 4. Figure 4 shows an ephemeris synchronization operation, where in a) SIB31 functions as normal and b) where UE fails to read SIB31 during T318 which then expires and triggers RLF. The T317 timer is different compared to a normal timer in RRC as it is not started at having received the SIB31. 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 field ul-SyncValidityDuration in SIB31. Self-Optimizing Network Self-Optimizing Network (SON) and Minimization of Drive Tests (MDT) has been a key feature for cellular networks since they were introduced for LTE in Release 9, which has continuously been enhanced. The main idea of the feature is that the UE is configured to collect data related to a number of events for optimizing network configurations. These events are for instance connection establishment failure, Radio Link Failure, successful handover and successful PSCell (handover?). The UE may also report logged measurements, such as measurements performed in the 4G / 5G cellular network, measurements of bluetooth, measurements of WLAN (i.e Wi-Fi connections). These can be reported through the use of the UE information reporting in RRC messages UElnformationRequest and UElnformationResponse. The network indicates specific reports that the network is interested in receiving in UElnformationRequest and the UE replies with the specific report in UElnformationResponse. The network is further indicated that the UE has this information through indicating their existence in a number of RRC -Complete messages (such as RRCReestablishmentComplete, RRCReconfigurationComplete, RRCResumeComplete and RRCSetupComplete). This procedure can be seen in Figure 5. When the failure, success or the event occurs, the UE will save all the related information in UE memory. This is then used to compile the report which is sent in the UElnformationResponse. The RLF Report, Successful Handover report and Successful PSCell Change Report may all be sent over Xn to neighbour gNBs. The RLF report is sent in the Xn message FAILURE INDICATION, the Successful Handover Report and Successful PSCell Change Report are sent in the ACCESS and MOBILITY INDICATION. Connection establishment reporting The UE connection establishment failure report provides details on failed RRC setup or RRC resume attempts. The UE connection establishment failure report (ConnEstFailReport or connEstFailReportList) contains the following information: Measurements of the failed cell, i.e the cell where the connection failure occurred UE location information Measurements of neighbouring cells Number of connection establishment failures Random access information (a list of random access information) Time since the failure Radio Link Failure Reporting Radio Link Failure procedures are introduced to allow a UE to regain its radio link in case the radio link fails. After having been triggered, the UE performs RRC re-establishment, which means that the UE performs cell selection to potentially find a new cell (the same cell is a possible outcome) and connects to the cell. The Radio Link Failure can be declared in a number of cases. Some examples are: • UE out of sync o The UE measures the cell strength through Radio Link Monitoring. If the cell strength is below a certain threshold for a configurable amount of times (N310), the UE triggers a timer (T310) for the UE to recover. If it does not recover, i.e T310 expires, the UE declares a RLF. o The recover condition is that the UE receives an in-sync indication a configurable amount of times (N311) during the T310 timer duration. • RLC PDUs are re-transmitted a number of times o The network configures a number of times (maxRetxThreshold) that an RLC PDU may be attempted to be re-transmitted. • Random access problems o This can occur when the UE is in connected mode and the UE is trying to resynchronize, for instance after losing uplink synchronization. After a number of configured attempts, the UE will report the error to RRC which triggers an RLF. • Backhaul (BH) RLF (IAB related) o Failure of backhaul links. This is due to a backhaul PDU being retransmitted more than a configured number of times. • Uplink Listen Before Talk (LBT) failure o This is when the UE fails LBT when on unlicensed band. Although a handover failure does cause the UE to declare a Radio Link Failure, a handover failure is still treated as a radio link failure in some cases, thus handover failures are considered a part of the RLF report. The RLF report (RLF-Report, FailureReportSCG in SCGFailurelnformation or FailureReportMCG in MCGFailurelnformation) may consist of the following information: Measurements of serving and neighbouring cells The C-RNTI the UE used The previous Cell ID The failed Cell ID, i.e the cell ID in which the failure occurred The Reconnect cell ID Time until reconnection Reestablishment cell ID Time of connection failure Time since the failure Connection failure type - RLF or a Handover Failure. RLF cause - t310 expiry (receiving lower layer out-of-sync indications), random access problem, RLC maximum number of retransmissions, beam failure recovery, LBT, IAB backhaul radio link failure, T312 expiry Location info of the UE No suitable cell found Random access information Handover type - Conditional Handover (CHO) or Dual Active Protocol Stack (DAPS) Time since CHO reconfiguration or DAPS failure E-UTRA RLF report including E-UTRA measurement result and cell ID of E-UTRA cell. CHO information such as CHO cell ID and CHO candidate cell list MCG failure causes - T316 expiry or SCG deactivation SCG failure causes - same as RLF cause Time elapsed since SCG failure Voice fallback handover RSSI serving and neighbour cell measurement results BWP info When the RLF is for SCG, UE may include the information for SON / MDT in SCGFailurelnformation. Successful Handover report The successful handover report (SHR) gives the network awareness of information when a handover is successful. This may for instance give the network information potential information even when a handover is successful, as even though a handover is successful does not mean that it is entirely unproblematic as the handover may take a long time to complete. The successful handover report (SuccessHO-Report) contains the following information: Source and target cell info Measurement of neighbouring cells UE location information Time since CHO reconfiguration SHR cause - T304, T310, T312. This tells the network the reason why the SHR was triggered. This is because the SHR may be sent based on whether one of the timer have elapsed more then a certain percentage. Random access information User plane interruption time during the handover C-RNTI E-UTRA information such as target cell ID and E-UTRA C-RNTI Time since SHR Another type of Successful report is the Successful PSCell Change (or addition) report (SPR) with the information element SuccessPSCell-Report. It contains similar information to report when the UE performs either a successful addition of an SCG, or changing the PSCell of SCG. Random access report Random access report is provided to enable network to identify issues with random access to for instance enable the network to optimize and reconfigure its random access configuration. For instance provide more random access resources, provide more resilient random access formats, increase the number of allowed attempts or increase timers. Similarly if all random access attempts are successful the network may reduce the random access resources. The random access report list (RA-ReportList) contains the following: Cell ID with which the random access was perfomed Purpose of the random access attempt - access related, BFR, reconfiguration with sync, uplink being unsynchronized, SR failure or no uplink resources, system information request via RACH or via msg3 or listen-before-talk failure Random access Information Common - This contains more details such as frequency, subcarrier spacing, bandwidth, random access configuration, DL pathloss etc o This also contains the per-random access attempt list which contains how many preamble attempts were performed and the SSB index of the attempts. SUMMARY In the work item for Release 19 SON / MDT [RP-234038, New WID: Data Collection for SON / MDT in NR standalone and MR-DC Phase 4], there is the following objective in the work item description: - Support of SON / MDT enhancements for [RAN3, RAN2]: • Intra-NTN mobility • Network Slicing Non-terrestrial networks rely on a set of relatively new techniques that have not been used for terrestrial networks. One of the most prominent of these is that the UE will self-precompensate for the timing advance by using the UE position acquired via GNSS and using the network-provided ephemeris. This means that there are several new key procedures that could be key for the network to know when attempting to optimize the network. If for instance failures occur and the cause of the error is NTN-synchronization-related, then there is a risk that self-organizing algorithms may make the wrong assumption and optimize wrong network parameters if the NTN-related information is not reported. For instance, consider the case where there are random access issues related to NTN such as ephemeris elements that are out of date. If NTN-related issues are not signalled, the network may attempt to reconfigure the random access configuration, while the better option would be to change how the network signalings and maintains the ephemeris. Thus since NTN makes changes to very basic functionality, if the UE does not report these issues, it may render certain parts of SON MDT ineffective and network configurations non-optimal. So in this invention we provide methods for reporting NTN-related information for the network to self-optimize. According to the present invention there is provided an apparatus and method as set forth in the appended claims. Other features of the invention will be apparent from the dependent claims, and the description which follows. Some, not necessarily all, embodiments of the present invention relate to a user equipment, UE, configured to: collect non-terrestrial network, NTN, information for optimising a network configuration; and transmit the collected NTN information to a base station. Optimising the network configuration may comprise SON and / or MDT. The base station may comprise an evolved node B (eNB) and / or a next generation node B (gNB). The UE may be configured to collect the NTN information in response to detecting that a failure event, success event, or other event has occurred. The UE may be configured to: transmit one or more radio resource control, RRC, messages to the base station; and receive one or more RRC messages from the base station. The UE may be configured to: transmit an RRC complete message to the base station, and receive an information request from the base station. The UE may be configured to transmit the collected NTN information to the base station in response the received information request. The UE may be configured to: perform a GNSS position fix; and in response the received information request, transmit information of the GNSS position fix to the base station. The UE being configured to transmit the collected NTN information to a base station may comprise the UE being configured to: include the NTN information in one or more of: a radio link failure, RLF, report, secondary cell group, SCG, failure information, a successful handover report, SHR, a random access report, a successful primary secondary cell change report, SPR, and a connection establishment failure report. The NTN information may comprise one or more of: NTN failure information; NTN success information; and other NTN event information. The NTN information may comprise one or more of: information on the UE performing a global navigation satellite system, GNSS, position fix; information on self-precompensation of the UE; information on the UE acquiring NTN ephemeris; and information related to a satellite position. The information on self-precompensation of the UE may comprise a timing advance reported in a timing advance report medium access control control element, MAC CE. The timing advance report MAC CE may have been triggered during a random access procedure during a handover. The information on the UE acquiring NTN ephemeris may comprise a flag indicating whether a timer T430 had expired when RLF or a handover failure, HOF, occurred. The UE may be configured to include the NTN information in the RLF report, wherein the NTN information comprises: NTN failure information; and one or more of: the Information related to a satellite position, the timing advance reported in the timing advance report MAC CE, and the flag indicating whether the timer T430 had expired. Some, not necessarily all, embodiments of the present invention relate to a base station configured to: receive NTN information from a user equipment; and optimise a network configuration based on the received NTN information. Optimising the network configuration may comprise SON and / or MDT. The base station may comprise an eNB and / or a gNB. The base station may be configured to: receive one or more RRC messages from the UE; and transmit one or more RRC messages to the UE. The base station may be configured to: receive an RRC complete message from the UE, and transmit an information request to the UE. The base station may be configured to receive the collected NTN information from the UE (e.g., in response the received information request). The base station may be configured to receive information of a GNSS position fix from the UE. The base station may be configured to receive the NTN information when the NTN information is included in one or more of: a radio link failure, RLF, report, secondary cell group, SCG, failure information, a successful handover report, SHR, a random access report, a successful primary secondary cell change report, SPR, and a connection establishment failure report. The NTN information may comprise one or more of: NTN failure information; NTN success information; and other NTN event information. The NTN information may comprise one or more of: information on the UE performing a global navigation satellite system, GNSS, position fix; information on self-precompensation of the UE; information on the UE acquiring NTN ephemeris; and information related to a satellite position. The information on self-precompensation of the UE may comprise a timing advance reported in a timing advance report medium access control control element, MAC CE. The timing advance report MAC CE may have been triggered during a random access procedure during a handover. The information on the UE acquiring NTN ephemeris may comprise a flag indicating whether a timer T430 had expired when RLF or a handover failure, HOF, occurred. The base station may be configured to receive the NTN information in the RLF report, wherein the NTN information comprises: NTN failure information; and one or more of: the information related to a satellite position, the timing advance reported in the timing advance report MAC CE, and the flag indicating whether the timer T430 had expired. Some, not necessarily all, embodiments of the present invention relate to a system comprising the UE according to any preceding paragraph and the base station according to any preceding paragraph. Some, not necessarily all, embodiments of the present invention relate to a method for optimising a network configuration, the method comprising: collecting non-terrestrial network, NTN, information for optimising the network configuration by a user equipment, UE; and transmitting, by the UE and to a base station, the collected NTN information. Optimising the network configuration may comprise performing SON and / or MDT (e.g., by the base station). The base station may comprise an eNB and / or a gNB. The method may comprise collecting, by the UE, the NTN information in response to detecting that a failure event, success event, or other event has occurred. The method may comprise: transmitting, by the UE and to the base station, one or more radio resource control, RRC, messages to the base station; and receiving, by the UE and from the base station, one or more RRC messages. The method may comprise: transmitting, by the UE and to the base station, an RRC complete message, and receiving, by the UE and from the base station, an information request. The method may comprise transmitting, by the UE and to the base station, the collected NTN information in response the received information request. The method may comprise: performing, by the UE, a GNSS position fix; and in response the received information request, transmitting, by the UE and to the base station, information of the GNSS position fix. The UE transmitting the collected NTN information to the base station may comprise the UE including the NTN information in one or more of: a radio link failure, RLF, report, secondary cell group, SCG, failure information, a successful handover report, SHR, a random access report, a successful primary secondary cell change report, SPR, and a connection establishment failure report. The NTN information may comprise one or more of: NTN failure information; NTN success information; and other NTN event information. The NTN information may comprise one or more of: information on the UE performing a global navigation satellite system, GNSS, position fix; information on self-precompensation of the UE; information on the UE acquiring NTN ephemeris; and information related to a satellite position. The information on self-precompensation of the UE may comprise a timing advance reported in a timing advance report medium access control control element, MAC CE. The timing advance report MAC CE may have been triggered during a random access procedure during a handover. The information on the UE acquiring NTN ephemeris may comprise a flag indicating whether a timer T430 had expired when RLF or a handover failure, HOF, occurred. The method may comprise including, by the UE, the NTN information in the RLF report, wherein the NTN information comprises: NTN failure information; and one or more of: the information related to a satellite position, the timing advance reported in the timing advance report MAC CE, and the flag indicating whether the timer T430 had expired. Although a few preferred embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes and modifications might be made without departing from the scope of the invention, as defined in the appended claims. For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example only, to the accompanying diagrammatic drawings in which: FIG. 1A shows NTN Release 17 architecture and scenario; FIG. 1B shows NTN release 19 regenerative architecture; FIG.2 shows an example SIB19 information element; FIG.3 shows an example SystemlnformationBlockType31 information element; FIG. 4 shows an example ephemeris synchronization operation, where in a) SIB31 functions as normal and b) where UE fails to read SIB31 during T318 which then expires and triggers RLF; FIG. 5 shows an example RRC messaging procedure; FIG. 6 shows an example UE; FIG. 7 shows an example base station; FIG. 8 shows an example method for optimising a network configuration; FIG. 9 shows an example method for optimising a network configuration; FIG. 10 shows an example method for optimising a network configuration via a GNSS position fix; FIG. 11 shows an example RLF report in accordance with example #1; and FIG. 12 shows an example RLF report in accordance with example #2. DETAILED DESCRIPTION FIG. 6 shows an example UE 10. The UE 10 (e.g., a controller of the UE 10) is configured to collect NTN information for optimising a network configuration. The controller may comprise a processor and memory. In some examples, the UE 100 being configured to collect the NTN information comprising the UE being configured to acquire the NTN information. The UE 10 is configured to transmit (e.g., via a transmitter of the UE 10) the collected NTN information to a base station (e.g., such that the base station may optimising the network configuration). Optimising the network configuration may comprise SON and / or MDT. In some examples, the UE 10 being configured to transmit the collected NTN information comprises reporting the collected NTN information. In some aspects, the UE 10 is configured to collect the NTN information in response to detecting that a failure event, success event, or other event has occurred. In some aspects, the UE 10 is configured to: transmit (e.g., via the transmitter of the UE 10) one or more radio resource control, RRC, messages to the base station; and receive (e.g., via a receiver of the UE 10) one or more RRC messages from the base station. In some aspects, the UE 10 is configured to: transmit an RRC complete message to the base station, and receive an information request from the base station. The UE 10 may be configured to transmit the collected NTN information to the base station in response the received information request. In some aspects, the UE 10 is configured to: perform a GNSS position fix; and in response the received information request, transmit information of the GNSS position fix to the base station. In some aspects, the UE 10 being configured to transmit the collected NTN information to a base station comprises the UE being configured to: include the NTN information in one or more of: a radio link failure, RLF, report, secondary cell group, SCG, failure information, a successful handover report, SHR, a random access report, a successful primary secondary cell change report, SPR, and a connection establishment failure report. In some aspects, the NTN information may comprise one or more of: NTN failure information; NTN success information; and other NTN event information. In some aspects, the NTN information may comprise one or more of: information on the UE 10 performing a global navigation satellite system, GNSS, position fix; information on self-precompensation of the UE 10; information on the UE acquiring NTN ephemeris; and information related to a satellite position. The information on self-precompensation of the UE 10 may comprise a timing advance reported in a timing advance report medium access control convergence entity, MAC CE. The timing advance report MAC CE may have been triggered during a random access procedure during a handover. The information on the UE 10 acquiring NTN ephemeris may comprise a flag indicating whether a timer T430 had expired when RLF or a handover failure, HOF, occurred. In some aspects, the UE 10 may be configured to include the NTN information in the RLF report, wherein the NTN information comprises: NTN failure information; and one or more of: the information related to a satellite position, the timing advance reported in the timing advance report MAC CE, and the flag indicating whether the timer T430 had expired. FIG. 7 shows an example base station 20. The base station 20 may comprise the base station 20 as described in relation to FIG. 6. The base station 20 is configured to receive (e.g., via a receiver of the base station 20) NTN information from the user equipment 10. The base station 20 is configured to optimise (e.g., via a controller of the base station 20) a network configuration based on the received NTN information. The controller may comprise a processor and memory. Optimising the network configuration may comprise SON and / or MDT. The base station 20 may comprise an eNB and / or a gNB. The base station 20 may comprise a cellular base station 20 (e.g., a cell). In some aspects, the base station 20 is configured to: receive one or more RRC messages from the UE 10; and transmit (e.g., via a transmitter of the base station) one or more RRC messages to the UE 10. In some aspects, the base station 20 may be configured to: receive an RRC complete message from the UE 10, and transmit an information request to the UE 10. The base station 20 may be configured to receive the collected NTN information from the UE 10 (e.g., in response the received information request). In some aspects, the base station 20 is configured to receive information of a GNSS position fix from the UE 10. In some aspects, the base station 20 is configured to receive the NTN information when the NTN information is included in one or more of: a radio link failure, RLF, report, secondary cell group, SCG, failure information, a successful handover report, SHR, a random access report, a successful primary secondary cell change report, SPR, and a connection establishment failure report. In some aspects, the base station 20 may be configured to receive the NTN information in the RLF report, wherein the NTN information comprises: NTN failure information; and one or more of: the information related to a satellite position, the timing advance reported in the timing advance report MAC CE, and the flag indicating whether the timer T430 had expired. In some aspects, the UE 10 and the base station 20 may form a system. In other words, the system may comprise the UE 10 and the base station 20. The UE 10 and the base station 20 may form at least part of a network. Subsequent references to a UE 10 may be the UE 10 as described in relation to FIG. 6. Subsequent references to a base station 20 may be the base station 20 as described in relation to FIG. 7. FIG. 8 illustrates a flowchart of a method 800 for optimising a network configuration. The method 800 may be performed by the UE 10 and / or the base station 20 as described in relation to FIGs 6 and 7. At step 802, the method 800 comprises collecting NTN information for optimising the network configuration by a UE 10. At step 804, the method 800 comprises transmitting, by the UE 10 and to a base station 20, the collected NTN information. In some aspects, the method 800 comprises step 806. At step 806, the method comprises optimising the network configuration by the base station 20. Optimising the network may comprise performing SON and / or MDT (e.g., by the base station 20). The method 800 may comprise collecting, by the UE 10, the NTN information in response to detecting that a failure event, success event, or other event has occurred. The method 800 may comprise: transmitting, by the UE 10 and to the base station 20, one or more radio resource control, RRC, messages; and receiving, by the UE 10 and from the base station 20, one or more RRC messages. The method 800 may comprise: transmitting, by the UE 10 and to the base station 20, an RRC complete message, and receiving, by the UE 10 and from the base station 20, an information request. The method 800 may comprise transmitting, by the UE 10 and to the base station 20, the collected NTN information in response the received information request. The method 800 may comprise: performing, by the UE 10, a GNSS position fix; and in response the received information request, transmitting, by the UE 10 and to the base station 20, information of the GNSS position fix. The method 800 may comprise including, by the UE 10, the NTN information in the RLF report, wherein the NTN information comprises: NTN failure information; and one or more of: the information related to a satellite position, the timing advance reported in the timing advance report MAC CE, and the flag indicating whether the timer T430 had expired. The main idea of this invention revolves around methods for reporting NTN-related information for SON / MDT. While “terrestrial network” is used below, this may not only be a terrestrial network, but may also be considered to be any type of network that is not an NTN network. This for instance may include Air-To-Ground networks or similar, although the Air-To-Ground network may in some cases also be considered an NTN network. Another suitable name may for instance be “non-NTN” and thus a TN cell may thus be a “non-NTN cell”. In the below, the wording “RRC connected”, “connected mode” or “RRC_CONNECTED” may be used interchangably. 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. While this invention is mostly described in terms of 5G NR, all proposals, embodiments, and examples in this invention may also apply for eNBs 10, NG-eNBs 10 (eNBs 10 connected via 5GC) and also to any other technology such as 6G. 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). The aspects below may also apply to loT NTN, which would be using E-UTRA SON / MDT signaling. The below signalled information may for instance be used for Al-based optimization of the network. All of the below information reported can be included in any of the Radio Link Failure Report, SCG Failure information, in the Successful handover report (SHR), the random access report, the Successful PSCell change report (SPR) or a connection establishment failure report. The UE 10 can report the NTN-related information if the UE 10 is connected to an NTN cell, or the UE 10 can be specifically configured to report the NTN information only if requested. In an alternative, the UE 10 may only report a failure or success that occurred in a non-terrestrial network to another non-terrestrial network. This means that a failure or success in a nonterrestrial network is not reported in a terrestrial network. Similarly, terrestrial network success or failure may not be reported in a non-terrestrial network. FIG. 9 shows an example method for optimising a network configuration (e.g., using the UE 10 as described in relation to FIG. 6 and / or using the base station 20 as described in relation to FIG. 7). FIG. 9 shows an example of the method 800 for optimising the network configuration as shown in FIG. 8. The below information may be for either intra-NTN handovers, or for inter-NTN handovers (NTN->TN or TN->NTN). Alternatively, the information may be reported to any network (i.e. NTN information may be reported in a TN network and TN information may be reported to NTN network. The information may be further reported to OAM or a centralized SON / MDT module, which may be an NTN specific SON / MDT or OAM module. In an embodiment, information collected by NTN gNB 20 may be sent to TN gNB 20 also (via inter-node interfaces such as Xn or other). Similarly, information collected by TN gNB 20 which is related to NTN gNB 20 may be send to NTN gNB 20 (via inter-node interfaces such as Xn or other). Any of the reporting below can be configurable by the network. In other words, the UE 10 only provides the information if configured by the network. There may also be conditions on whether the UE 10 reports certain information. This can for instance be conditions such as: A percentage of a duration has passed. Time since an action was performed or detected has passed a threshold - If the UE 10 is capable of NTN If target cell, source cell, failed cell, reconnect cell, candidate or CHO cell is an NTN cell or any combination thereof - If the NTN cell is NGSO or GSO The below information may be sent in an RLF report in response to any event that triggers an RLF, i.e T310 expiry, random access problems, RLC maximum number of retransmissions, beam failure recovery, T312 expiry etc. Also any event that triggers an SCG RLF may be sent, which would in addition to the above also include SCG reconfiguration failure, SRB3 integrity failure, etc. Information on UE performing GNSS position fix Since NTN relies on UE 10 self-precompensating, partly via UE 10 using its own GNSS position, the network having information on when UE 10 performing GNSS can be very beneficial for network operations. FIG. 10 shows an example method for optimising a network configuration via a GNSS position fix (e.g., using the UE 10 as described in relation to FIG. 6 and / or using the base station 20 as described in relation to FIG. 7). FIG. 10 shows an example of the method 800 for optimising the network configuration as shown in FIG. 8. In one aspect of the invention, the UE 10 reports when it (last) performed a GNSS position fix in the report sent to the network. This can be useful, as it can give the network awareness that the failure, success or difficulties can be due to when the UE 10 last performed a GNSS position fix. The general concept can be seen in Figure 10. The GNSS position fix may also be considered a GNSS measurement or GNSS position. In another aspect of the invention, the UE 10 reports whether it performed a GNSS position fix during the handover or other procedures which triggered the report such as RLF or PSCell addition / change. This can be useful in both the failure case and success case of a handover, because a GNSS position fix may be required during the handover. Thus if the UE 10 attempts to perform a GNSS position fix during the handover, it will be vital to the success or failure of the handover. This can for instance be a flag, indicating that a GNSS position fix was performed. Similarly, in a similar aspect of the invention, the UE 10 reports whether a GNSS position fix has failed or succeeded in during the handover. An example of the above in an RLF report can be seen in Example #1 (below), but it may also be included in SHR or SPR or SCGFailurelnformation etc. In another aspect of the invention, the UE 10 reports the time difference between the GNSS position fix and the logging of report (such as RLF report, SHR, SPR or SCGFailurelnformation etc.). This is another way of reporting when the UE 10 last performed GNSS measurement. In another aspect of the invention, the UE 10 reports how long time the GNSS position fix took. This can be useful when there is a failure or a success, because it can tell certain issues with UEs. The UE 10 may also report the time duration of having performed (started performing or having finished the GNSS position fix) the GNSS position fix and the report being sent. The UE 10 may be configured to report the GNSS related information if the UE 10 acquired GNSS position fix a long time ago. In other words, the UE 10 reports the information if the GNSS position fix was performed more than a certain time ago. For instance, if the GNSS position fix was performed more than 20 seconds ago, the UE 10 reports the information. This threshold may be configurable. In another aspect of the invention, the UE 10 may indicate how long the UE 10 estimates the GNSS to be valid for. This can in particular be important in an loT NTN network, as the UE 10 has to signal the GNSS validity duration. This may also be signalled in an NR NTN network in any of the related reports. The UE 10 may also report the mobility of the UE 10. For instance if the UE 10 does not move and its GNSS position has stayed still for a long time, this can be reported. Similarly, if the UE 10 is highly mobile with its GNSS position often changing, this can be reported. Example network actions Network actions upon receiving the reported information on UE 10 performing GNSS measurement can be: Adjusting timers o Adjusting T304 - If a GNSS position fix occurs during a handover, this may cause issues with the timer that governs how long the UE 10 may attempt a handover (T304) before a radio link failure and re-establishment procedure occurs. This means that the network may have to re-adjust the T304 timer. o Adjust T310 / T311 - T310 controls radio link failure, by specifying how long the UE 10 has to recover from an RLF and T311 controls how long the UE 10 has to find a suitable cell during the RRC connection re-establishment. T310 can be made shorter to get UE 10 to go to RLF faster o Adjust connection access timers that govern how long the UE 10 have to access a cell. This can for instance be timers T300 (how long RRC Connection Setup can be attempted), T301 (how long RRC Re-establishment can be attempted) and T319 (how long RRC Resume can be attempted) Introducing more reliable random access parameters. For instance random access formats that increases the tolerance for errors Network may send GNSS assistance information via LPP or via RRC to provide more accurate and faster GNSS position fixes Information on self-precompensation As the UE 10 self-precompensates and calculates the timing advance and the frequency offset autonomously, there may need to be information provided on how UE 10 does this. In one aspect of the invention, the UE 10 reports in failure-related information (RLF report / SCGFailurelnformation) or other reports such as SHR / SPR / RA report, the timing advance that the UE 10 used during the failure. This reported information may for instance be the full timing advance (Tta), which includes various network-configured offsets, or it can be the timing advance that the UE 10 calculates (Nta). The information may also be an indicator which indicates whether the timing advance was above or below a certain threshold, which may be a set hardcoded threshold, or a configured threshold. The specific timing advance value that can be used is the timing advance value that is used for compiling the Timing Advance Report MAC CE, which may be configured during handovers. The timing advance related information may be also an indication that the UE 10 calculated timing advance on its own, i.e performed self-precompensation of the timing advance. While this provides lesser information than the above, it helps in optimising the amount of data sent for SON / MDT. In one aspect of the invention, if the Timing Advance Report MAC CE is triggered during a failure or during a handover, the UE may include the Timing Advance Report MAC CE encoded in RRC. In a related aspect, UE may include an information element that indicates that is has sent or triggered the Timing Advance Report MAC CE. In another aspect of the invention, the UE 10 may report the network configured timing advance offset when the failure occurred. This can be useful as it indicates that the UE 10 has been struggling with the compensation, causing the network to utilize closed-loop timing advance to maintain accurate timing. This can be the NTA,otfset, the N^^on or In another aspect of the invention, the UE 10 can report the differential Koffset. The differential Koffset consist of the cell-specific Koffset which is configured via RRC, and the UE-specific Koffset, which is configured via in MAC via MAC CEs. The UE 10 can report the full differential Koffset, the network-configured or the UE 10 specific Koffset. The UE 10 may also report whether the Koffset was above a threshold, whether the Koffset (network-configured or UE-specific) was configured at any point. The above may also be included in a random access report. It may also be triggered if a RACH-less handover or RACH-less procedure is triggered. It can be in particular useful if the network receives this information as it can indicate problems with the RACH-less handover if UEs 10 are constantly not performing accurate enough timing advance compensation. In another set of aspects of the invention, the UE 10 reports information regarding the frequency self-precompensation. This can for instance be in the form of the absolute frequency self-precompensation with some form of quantization, or it can be relative to the carrier frequency, or relative to the Subcarrier spacing. In an alternative method, it can be reported whether the frequency self-precompensation is above some threshold. This threshold can be hardcoded, i.e set by the specifications, or it can be configured. The threshold may also be relative to the carrier frequency, or to the subcarrier spacing. In concrete example, it may be such that the UE reports whether the self-precompensated frequency relative to the carrier frequency is above 5%. Or in another concrete example, the UE 10 may be configured to report if the self-precompensated frequency relative to the subcarrier spacing is larger than 30%. In another aspect of the invention, the UE 10 can indicate issues with either timing advance or frequency self-precompensation. Network actions Network actions after receiving the report containing information regarding self-precompensation may be: The network may activate closed-loop timing advance compensation, i.e. that the network controls the timing advance via Timing Advance commands, as is normally done in a terrestrial network. Information on acquiring NTN ephemeris Another important aspect that concerns NTN operation is that of acquiring the NTN ephemeris which gives the satellite position and speed, as this the other part of the UE 10 performing self-precompensating. The validity of the NTN ephemeris is governed by the timer T430 (timerT317 in loT NTN), which can be said to be started when UE 10 acquires the SIB19 (SIB31 in loT NTN) containing the NTN ephemeris. The timer is also called the uplink synchronization validity. In one aspect of the invention the UE 10 reports the status of the uplink synchronization validity, i.e. the timer T430, at the time of the event which caused the report. This can be reported by indicating whether the timer has expired or not, which would be mean that the UE 10 reports a flag indicating whether timer was still running or had expired. The status may also be reported in the form of the full remaining or elapsed duration of the T430 timer. The status may also be reported in the form of indicating whether the remaining duration is below some threshold. For instance the UE 10 indicates whether the remaining duration is below 5 seconds. This threshold may be configured or it may be set by the specifications. An example of this in RLF report can be seen in Example #2 (below). Reporting the status of the uplink synchronization can be very useful for the network as it may indicate problems with the UEs 10 acquiring the SIB19, it may indicate that the uplink synchronization timer is configured to be too long and that the UE 10 is in fact losing synchronization much earlier than what the timer may indicate. The reporting of the uplink synchronization may also be triggered if the T430 duration has passed a specific percentage of the full duration, i.e. if the timer has passed 75% of its full duration, then the UE 10 will report the information - otherwise the UE 10 does not report the information. Reporting T430 status may be mandatory in a non-terrestrial network, i.e always included in a report, to indicate that the UE 10 was connected to a non-terrestrial network. Similarly, it may be reported when the UE 10 acquired the NTN ephemeris. This can be configured as the time since the NTN ephemeris was acquired. The UE 10 may also report whether it is fully synchronized, i.e. having acquired its GNSS position as well as having a valid ephemeris, i.e. the timer T430 not having expired. This can be done via a single flag which indicates whether it is fully synchronized or not. In another aspect of the invention, for loT NTN devices the UE 10 reports whether the timer T318 is running or not. The T318 is a timer for the UE to acquire the loT NTN SIB31. So indicating whether T318 is running indicates whether the UE is attempting to acquire the loT NTN SIB31. Network actions Network actions after receiving the report containing information regarding UEs 10 acquiring NTN ephemeris: The network may for instance reduce the duration of the timer T430 so that UE 10 is considered synchronized for a shorter duration The network may attempt to provide more precise ephemeris elements, or to update the ephemeris elements more often The network may broadcast the NTN SIB19 more often to provide UEs 10 more opportunities to acquire the required information Further information signalled In one further aspect signalled, the UE 10 may report the information regarding the satellite position or ephemeris at the timer of the failure or the success. This may for instance be the satellite position, or the estimated satellite position. This can be represented by a 3D vector (X,Y,Z) in Earth-centered Earth Fixed coordinates. Alternatively whether the satellite position is further away from some threshold (configured or hardcoded) may be configured. The UE 10 may also report the height of the satellite or the distance from the UE 10 to the satellite. Alternatively the UE can report whether the satellite ephemeris corresponded to a LEO, MEO or GEO orbit. The UE 10 may report the ephemeris that the UE 10 used during the failure or successful event. This can indicate whether there are issues with the network-provided ephemeris. The UE 10 may also report the format of the network-provided ephemeris, which can be the PVT format, orbital format or any other future format. The UE 10 may indicate whether a handover was a intra-NTN handover, inter-NTN (TN -> NTN or NTN->TN). In one aspect of the invention, the UE 10 may indicate in the UE-InformationAvailable (sent in RRC -Complete messages) that the UE 10 has NTN-related information, or that the reports are associated with an NTN cell, or an NTN network. The UE 10 may indicate that the failure or success occurred in a non-terrestrial network in the specific report. If for instance an RLF occurs in an NTN, and the UE 10 performs re-establishment to a terrestrial network, the UE 10 may still provide the NTN information. In one aspect of the invention, the UE 10 reports the satellite that it was connected to. This can for instance be represented by the satellite ID. In one aspect of the invention UE 10 may report its coarse GNSS location in the report. The coarse location information is a location which has a lower accuracy to preserve the privacy of the user. This could for instance be used instead of signalling any cell IDs, since the NTN the cell IDs may move over time and that location information is a more accurate description of where the error occurred. This would mean that in NTN, or if a failure occurs where one of the cells Is an NTN cell, the UE 10 does not signal any cell ID, but rather includes its location information (may be the coarse or the locationinfo). The UE 10 may also report whether the handover was a satellite switch with resynchronization, or whether the handover was a feeder link switch. The UE 10 may also report whether the NTN cell was a quasi-earth fixed cell or an earth-moving cell. Examples Example #1 The changes in bold are highlighted. ------------------------------Based on 38.331 V18.1.0------------------------------ 5.3.10.5 RLF report content determination The UE 10 shall determine the content in the VarRLF-Report as follows: 1> clear the information included in VarRLF-Report, if any; 1> if the failure occurred where at least one of the cells (failed, target, source) involved is an NTN cell: 2> set the gnss-PositionFixPerformed if a GNSS position fix was performed during the event; 2> set the timeSinceGNSS-PositionFix according to when the GNSS position was performed, if a GNSS position fix was performed during the event; FIG. 11 shows an example RLF report in accordance with example #1. Table 5 shows example RLF report field descriptions. RLF-Report field descriptions gnss-PositionFixPerformed This field indicates whether a GNSS position fix was performed during the handover, or if RLF is reported that a GNSS position fix was performed recently._____________________________________________ timeSinceGNSS-PositionFix This field indicates the time since a GNSS position fix was performed. Table 5 - RLF-Report field descriptions Example #2 The changes in bold are highlighted. ------------------------------Based on 38.331 V18.1.0------------------------------ 5.3.10.5 RLF report content determination The UE 10 shall determine the content in the VarRLF-Report as follows: 1> clear the information included in VarRLF-Report, if any; 1 >if the failure occurred where at least one of the cells (failed, target, source) is an NTN cell: 2> set the ul-NTN-SyncExpired if T430 expired during the failure; 2> set the ul-NTN-SyncRemainingDuration to the remaining value of T430 when the failure occurred; 2> set the ul-NTN-SyncShortDuration if the duration of T430 is below 5 seconds; FIG. 12 shows an example RLF report in accordance with example #2. Table 6 shows example RLF report field descriptions. RLF-Report field descriptions ul-NTN-SyncExpired This field is used to indicate whether the uplink sync validity, i.e timer T430 was expired during the RLF or handover failure._________________________________________________________________________________ ul-NTN-SyncRemainingDuration This field is used to indicate the remaining duration of the uplink sync validity duration, i.e timer T430 when the RLF or the handover failure occurred.___________________________________________________ ul-NTN-SyncShortDuration This field is used to indicate whether the uplink sync validity, i.e timer T430 had a smaller duration than 5 seconds during the RLF of handover failure.____________________________________________________ Table 6 - RLF-Report field descriptions ------------------------------Based on 38.331 V18.1.0------------------------------ References References to [1] and [2] above relate to the following: [1] 3GPP TS 38.331 V18.1.0, “Radio Resource Control (RRC)”, Release 18. [2] 3GPP TS 36.331 V18.1.0, “Radio Resource Control (RRC)”, Release 18. At least some of the example embodiments described herein may be constructed, partially or wholly, using dedicated special-purpose hardware. Terms such as ‘component’, ‘module’ or ‘unit’ used herein may include, but are not limited to, a hardware device, such as circuitry in the form of discrete or integrated components, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks or provides the associated functionality. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to execute on one or more processors. These functional elements may in some embodiments include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Although the example embodiments have been described with reference to the components, modules and units discussed herein, such functional elements may be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it will be appreciated that described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be combined with features of any other embodiment, as appropriate, except where such combinations are mutually exclusive. Throughout this specification, the term “comprising” or “comprises” means including the component(s) specified but not to the exclusion of the presence of others. Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

1. A user equipment, UE, configured to:collect non-terrestrial network, NTN, information for optimising a network configuration; and transmit the collected NTN information to a base station;wherein the NTN information comprises one or more of:information on the UE performing a global navigation satellite system, GNSS, position fix;information on self-precompensation of the UE;information on the UE acquiring NTN ephemeris; and information related to a satellite position.

2. The UE of claim 1, wherein the information on the UE performing a GNSS position fix comprises when the UE last performed a GNSS position fix.

3. The UE of claim 1 or 2, wherein the information on the UE performing a GNSS position fix comprises whether the UE performed the GNSS position fix during a handover or other procedure.

4. The UE of claim 1,2, or 3, wherein the UE is configured to transmit the information on the UE performing a GNSS position fix if the UE acquired the GNSS position fix a threshold period of time ago.

5. The UE of any preceding claim, wherein the UE is configured to collect the NTN information in response to detecting that a failure event, success event, or other event has occurred.

6. The UE of any preceding claim, wherein the UE is configured to:transmit one or more radio resource control, RRC, messages to the base station; and receive one or more RRC messages from the base station.

7. The UE of any preceding claim, wherein the UE is configured to: transmit an RRC complete message to the base station, and receive an information request from the base station.

8. The UE of claim 7, wherein the UE is configured to transmit the collected NTN information to the base station in response the received information request.

9. The UE of any preceding claim, wherein the UE being configured to transmit the collected NTN information to a base station comprises the UE being configured to:include the NTN information in one or more of:a radio link failure, RLF, report,secondary cell group, SCG, failure information,a successful handover report, SHR,a random access report,a successful primary secondary cell change report, SPR, anda connection establishment failure report.

10. The UE of any preceding claim, wherein the NTN information comprises one or more of: NTN failure information;NTN success information; and other NTN event information.

11. The UE of any preceding claim, wherein the information on self-precompensation of the UE comprises a timing advance reported in a timing advance report medium access control control element, MAC CE.

12. The UE of claim 11, wherein the timing advance report MAC CE was triggered during a random access procedure during a handover.

13. The UE of any preceding claim, wherein the information on the UE acquiring NTN ephemeris comprises a flag indicating whether a timer T430 had expired when RLF or a handover failure, HOF, occurred.

14. The UE of any of any preceding claim, wherein the UE is configured to include the NTN information in the RLF report, wherein the NTN information comprises:NTN failure information; andone or more of:the information related to a satellite position,the timing advance reported in the timing advance report MAC CE, and the flag indicating whether the timer T430 had expired.

15. A base station configured to:receive NTN information from a user equipment, UE; andoptimise a network configuration based on the received NTN information,wherein the NTN information comprises one or more of:information on the UE performing a global navigation satellite system, GNSS, position fix;information on self-precompensation of the UE;information on the UE acquiring NTN ephemeris; andinformation related to a satellite position.

16. A system comprising the UE according to any preceding claim and the base station of claim 15.

517. A method for optimising a network configuration, the method comprising: collecting non-terrestrial network, NTN, information for optimising the network configuration by a user equipment, UE; and transmitting, by the UE and to a base station, the collected NTN information,10 wherein the NTN information comprises one or more of:information on the UE performing a global navigation satellite system, GNSS, position fix;information on self-precompensation of the UE;information on the UE acquiring NTN ephemeris; andinformation related to a satellite position.

Images