3GPP TSG-RAN WG2 Meeting #130 R2-2504630
Malta, MT, 19–23 May, 2025
First Modified Subclause
3.2 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [1], in TS 36.300 [2] and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1] and TS 36.300 [2].
UNCHANGED PART OMITTED
eRedCap UE: a UE with enhanced reduced capabilities as specified in clause 4.2.22.1 in TS 38.306 [11].
Feeder link: wireless link between the NTN Gateway and the NTN payload.
Geosynchronous Orbit: earth-centered orbit at approximately 35786 kilometres above Earth's surface and synchronised with Earth's rotation. A geostationary orbit is a non-inclined geosynchronous orbit, i.e. in the Earth's equator plane.
UNCHANGED PART OMITTED
Inter-donor partial migration: migration of an IAB-MT to a parent node underneath a different IAB-donor-CU while the collocated IAB-DU and its descendant IAB-node(s), if any, are terminated at the initial IAB-donor-CU. The procedure renders the said IAB-node as a boundary IAB-node.
Intra-system Handover: handover that does not involve a CN change (EPC or 5GC).
UNCHANGED PART OMITTED
NTN Gateway: an earth station located at the surface of the earth, providing connectivity to the NTN payload using the feeder link. An NTN Gateway is a TNL node.
NTN payload: a network node, embarked on board a satellite or high altitude platform station, providing connectivity functions, between the service link and the feeder link. he NTN payload a TNL node.
Numerology: corresponds to one subcarrier spacing in the frequency domain. By scaling a reference subcarrier spacing by an integer N, different numerologies can be defined.
UNCHANGED PART OMITTED
Next Modified Subclause
7.3.1 Overview
System Information (SI) consists of a MIB and a number of SIBs, which are divided into Minimum SI and Other SI:
- Minimum SI comprises basic information required for initial access and information for acquiring any other SI. Minimum SI consists of:
- MIB contains cell barred status information and essential physical layer information of the cell required to receive further system information, e.g. CORESET#0 configuration. MIB is periodically broadcast on BCH.
- SIB1 defines the scheduling of other system information blocks and contains information required for initial access. SIB1 is also referred to as Remaining Minimum SI (RMSI) and is periodically broadcast on DL-SCH or sent in a dedicated manner on DL-SCH to UEs in RRC_CONNECTED.
- Other SI encompasses all SIBs not broadcast in the Minimum SI. Those SIBs can either be periodically broadcast on DL-SCH, broadcast on-demand on DL-SCH (i.e. upon request from UEs in RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED), or sent in a dedicated manner on DL-SCH to UEs in RRC_CONNECTED (i.e., upon request, if configured by the network, from UEs in RRC_CONNECTED or when the UE has an active BWP with no common search space configured or when the UE configured with inter cell beam management is receiving DL-SCH from a TRP with PCI different from serving cell's PCI). Other SI consists of:
- SIB2 contains cell re-selection information, mainly related to the serving cell;
- SIB3 contains information about the serving frequency and intra-frequency neighbouring cells relevant for cell re-selection (including cell re-selection parameters common for a frequency as well as cell specific re-selection parameters);
- SIB4 contains information about other NR frequencies and inter-frequency neighbouring cells relevant for cell re-selection (including cell re-selection parameters common for a frequency as well as cell specific re-selection parameters), which can also be used for NR idle/inactive measurements;
- SIB5 contains information about E-UTRA frequencies and E-UTRA neighbouring cells relevant for cell re-selection (including cell re-selection parameters common for a frequency as well as cell specific re-selection parameters);
- SIB6 contains an ETWS primary notification;
- SIB7 contains an ETWS secondary notification;
- SIB8 contains a CMAS warning notification;
- SIB9 contains information related to GPS time and Coordinated Universal Time (UTC);
- SIB10 contains the Human-Readable Network Names (HRNN) of the NPNs listed in SIB1;
- SIB11 contains information related to idle/inactive measurements;
- SIB15 contains information related to disaster roaming;
- SIB16 contains slice-based cell reselection information;
- SIB17 and SIB17bis contain information related to TRS configuration for UEs in RRC_IDLE/RRC_INACTIVE;
- SIBpos contains positioning assistance data as defined in TS 37.355 [43] and TS 38.331 [12];
- SIB18 contains information related to the Group IDs for Network selection (GINs) associated with SNPNs listed in SIB1.
- SIB19 in TN contains NTN-specific parameters for NTN neighbour cells as defined in TS 38.331 [12].
For sidelink, Other SI also includes:
- SIB12 contains information related to NR sidelink communication, ranging and sidelink positioning;
- SIB13 contains information related to SystemInformationBlockType21 for V2X sidelink communication as specified in TS 36.331 clause 5.2.2.28 [29];
- SIB14 contains information related to SystemInformationBlockType26 for V2X sidelink communication as specified in TS 36.331 clause 5.2.2.33 [29];
- SIB23 contains information related to ranging and sidelink positioning.
For non-terrestrial network, Other SI also includes:
- SIB19 contains NTN-specific parameters for serving cell and optionally NTN-specific parameters for neighbour cells as defined in TS 38.331 [12].
- SIB25 contains TN coverage information as defined in TS 38.331 [12].
For MBS broadcast, Other SI also includes:
- SIB20 contains MCCH configuration;
- SIB21 contains information related to service continuity for MBS broadcast reception.
For MBS multicast reception in RRC_INACTIVE state, Other SI also includes:
- SIB24 contains the information required to acquire the multicast MCCH/MTCH configuration as defined in TS 38.331 [12].
For ATG network, Other SI also includes:
- SIB22 contains ATG-specific parameters for serving cell and optionally ATG-specific parameters for neighbour cells as defined in TS 38.331 [12].
Figure 7.3.1-1 below summarises System Information provisioning.
Figure 7.3.1-1: System Information Provisioning
For a cell/frequency that is considered for camping by the UE, the UE is not required to acquire the contents of the minimum SI of that cell/frequency from another cell/frequency layer. This does not preclude the case that the UE applies stored SI from previously visited cell(s).
If the UE cannot determine the full contents of the minimum SI of a cell by receiving from that cell, the UE shall consider that cell as barred.
In case of BA, the UE only acquires SI on the active BWP.
If the UE is configured with inter cell beam management:
- the UE is not required to acquire the SI from the serving cell while it is receiving DL-SCH from a TRP with PCI different from serving cell's PCI.
Next Modified Subclause
16.14 Non-Terrestrial Networks
16.14.1 Overview
Figure 16.14.1-1 below illustrate example of a Non-Terrestrial Network (NTN) providing non-terrestrial NR access to the UE by means of an NTN payload and an NTN Gateway, depicting a service link between the NTN payload and a UE, and a feeder link between the NTN Gateway and the NTN payload.
Figure 16.14.1-1: Overall illustration of an NTN
NOTE 1: Figure 16.14.1-1 illustrate an NTN; RAN4 aspects are out of scope.
The NTN payload transparently forwards the radio protocol received from the UE (via the service link) to the NTN Gateway (via the feeder link) and vice-versa. The following connectivity is supported by the NTN payload:
- An NTN gateway may serve multiple NTN payloads;
- An NTN payload may be served by multiple NTN gateways.
NOTE 2: In this release, the NTN-payload may change the carrier frequency, before re-transmitting it on the service link, and vice versa (respectively on the feeder link).
For NTN, the following applies in addition to Network Identities as described in clause 8.2:
- A Tracking Area corresponds to a fixed geographical area. Any respective mapping is configured in the RAN;
- A Mapped Cell ID as specified in clause 16.14.5.
NTN can be deployed to provide coverage with earth-moving cell, quasi-earth-fixed cell and earth-fixed cell which are supported respectively by the following three types of service link:
- Earth-fixed: provisioned by beam(s) continuously covering the same geographical areas all the time (e.g., the case of GSO satellites);
- Quasi-Earth-fixed: provisioned by beam(s) covering one geographic area for a limited period and a different geographic area during another period (e.g., the case of NGSO satellites generating steerable beams);
- Earth-moving: provisioned by beam(s) whose coverage area slides over the Earth surface (e.g., the case of NGSO satellites generating fixed or non-steerable beams).
With NGSO satellites, the gNB can provide either quasi-Earth-fixed service link or Earth-moving service link, while gNB operating with GSO satellite can provide Earth fixed service link or quasi-Earth-fixed service link.
In this release, the UE supporting NTN is GNSS-capable.
In NTN, the distance refers to Euclidean distance.
In this release, NTN is only applicable to FDD system.
Next Modified Subclause
16.14.4 Switchover
16.14.4.1 Definitions
A feeder link switchover is the procedure where the feeder link is changed from a source NTN Gateway to a target NTN Gateway for a NTN payload. The feeder link switchover is a Transport Network Layer procedure. Service link switch refers to a change of the serving NTN payload.
Both hard and soft feeder link switchover are supported in NTN.
16.14.4.2 Assumptions
A feeder link switch over may result in transferring the established connection for the affected UEs between two gNBs.
For soft feeder link switch over, an NTN payload is able to connect to more than one NTN Gateway during a given period, i.e. a temporary overlap can be ensured during the transition between the feeder links.
For hard feeder link switch over, an NTN payload connects to only one NTN Gateway at any given time, i.e. a radio link interruption may occur during the transition between the feeder links.
16.14.4.3 Procedures
The NTN Control function (see Annex B.4) determines the point in time when the feeder link switch over is performed. The transfer of the affected UE(s) at feeder link switch over is performed by means of handover, and it depends on the gNBs' implementation and configuration information provided to the gNBs by the NTN Control function.
Next Modified Subclause
16.14.5 NG-RAN signalling
The Cell Identity, as defined in TS 38.413 [26] and TS 38.423 [50], used in following cases corresponds to a Mapped Cell ID, irrespective of the orbit of the NTN payload or the types of service links supported:
- The Cell Identity indicated by the gNB to the Core Network as part of the User Location Information;
- The Cell Identity used for Paging Optimization in NG interface;
- The Cell Identity used for Area of Interest;
- The Cell Identity used for PWS
The Cell Identity included within the target identification of the handover messages allows identifying the correct target cell. The cell identity used in the NG and Xn handover messages, Xn Setup and Xn NG-RAN Node Configuration Update procedures is expected to be Uu Cell ID.
The Cell Identities used in the RAN Paging Area during Xn RAN paging allow the identification of the correct target cells for RAN paging.
NOTE 1: The Cell Identity used for RAN Paging is assumed to typically represent a Uu Cell ID.
The mapping between Mapped Cell IDs and geographical areas is configured in the RAN and Core Network.
NOTE 2: A specific geographical location may be mapped to multiple Mapped Cell ID(s), and such Mapped Cell IDs may be configured to indicate differerent geographical areas (e.g. overlapping and/or with different dimensions).
The gNB is responsible for constructing the Mapped Cell ID based on the UE location information received from the UE, if available. The mapping may be pre-configured (e.g., up to operator's policy) or up to implementation.
NOTE 3: As described in TS 23.501 [3], the User Location Information may enable the AMF to determine whether the UE is allowed to operate at its present location. Special Mapped Cell IDs or TACs may be used to indicate areas outside the serving PLMN's country.
The gNB reports the broadcasted TAC(s) of the selected PLMN to the AMF as part of ULI. In case the gNB knows the UE's location information, the gNB may determine the TAI the UE is currently located in and provide that TAI to the AMF as part of ULI.
Next Modified Subclause
16.14.9 Support for NR NTN coverage enhancements
To improve NR uplink coverage in NTN, the following enhancements are supported:
- PUCCH repetition for Msg4 HARQ-ACK configured in system information or dynamically in DCI for Msg4 when multiple repetition factors are configured in the system information:
- UEs reports the capability of PUCCH repetition for Msg4 HARQ-ACK in Msg3 PUSCH;
- When Msg4 HARQ-ACK is repeated, PUCCH repetition is applied for all PUCCH transmission before dedicated PUCCH resource is provided.
- Improved channel estimation by NTN-specific PUSCH DMRS bundling enhancement that enables DMRS bundling in presence of timing drift, where the UE maintains phase continuity by considering effects of transmission delay variation between the UE and the uplink time synchronization reference point.
Next Modified Subclause
Next Modified Subclause
End of Changes
The following appendices shall be removed from final CR
A Appendix: RAN2 agreements for WI NR-NTN_Ph3-Core
Downlink Coverage enhancements
RAN2#125bis
1. With regard to link level enhancement, RAN2 waits for RAN1 agreement on the DL channels to enhance before starting any RAN2 work.
2. We will continue the discussion on RAN2 aspects of DL coverage enhancements (e.g. cell level / beam level DTX/DRX mechanism, etc.) in the next meetings, trying to identify questions to RAN1 for aspects where we need their input
RAN2#126
1. Based on the solution being investigated in RAN1, RAN2 will further discuss whether/how legacy UEs might operate in a cell supporting DL coverage enhancements.
2. RAN2 assumes that both EFC and EMC are supported
RAN2#127
1. From RAN2 point of view, if the SSB periodicity is no larger than 160ms, there is no RAN2 impact on SSB configuration (there might still be impacts on DTX aspects)
2. From RAN2 point of view, If the SSB periodicity is larger than 160ms, for example ssb-PeriodicityServingCell, measurement gap periodicity, SMTC configuration, ssb-Periodicity-r17 for NonCellDefiningSSB-r17 may need to be extended. And the field description of nAndPagingFrameOffset may need to be enhanced to consider the SSB periodicity higher than 160ms.
3. RAN2 can further consider SMTC impacts due to beam-hopping / larger SSB periodicity
4. If there is a need to bar pre-Rel19 NTN UEs from accessing a cell operating with DL coverage enhancement (e.g. because of extreme SSB periodicity) the existing NTN bar bit can be used. FFS about the behaviour for Rel-19 UEs not supporting DL coverage enhancement when the existing NTN bar bit is set.
RAN2#127bis
1. If it turns out that there is a need to bar UEs not supporting DL-CE, Rel-19 UEs not supporting DL-CE can be barred from accessing a cell operating with DL-CE using the existing NTN bar bit, in the same way as pre-Rel19 NTN UEs (this is an extension of the previous agreement to include also Rel-19 UE not supporting DL-CE)
2. If it turns out that there is a need to bar UEs not supporting DL-CE, then we need to introduce a barring mechanism to control access of UEs supporting Rel19 NTN DL-CE. FFS on the details. (This also implies that UEs supporting Rel19 NTN DL-CE will not consider the existing NTN barring bit)
3. (also depending on the details of the RAN1 solution) we can further consider methods to allow UEs not supporting DL CE to down-prioritize or prevent re-selection to cells operating with DL CE.
RAN2#128
If we need to bar UEs not supporting DL-CE (via legacy mechanism), we introduce a new barring in SIB1 to be able to selectively bar “UEs supporting DL-CE” (FFS if we will finally refer to “UEs supporting extended SSB periodicity” instead). FFS on the details (e.g. how many bits, etc.)
As part of the work on DL-CE, RAN2 investigates related UE power consumption impact (including legacy UEs)
RAN2 will consider whether to introduce separate signalling (e.g. new SMTC5 list) for DL CE cells SMTCs, e.g. if different periodicities need to be signalled or to prevent reselection to specific cells
For cell level DTX for NTN DL coverage enhancement, RAN2 currently understands that there will be only two states: "cell DTX On period" and "Cell DTX Off period" (FFS if the UE behaviour will be different from the NES states or the same). FFS on Cell DRX states.
RAN2#129
1. RAN2 assumes it will be possible to have different SSB periodicity among neighbour cells in the same frequency layer
2. RAN2 assumes that in a NR NTN cell, SSB beam sweeping in different spatial directions is possible as in a NR TN cell: the whole cell is covered by the different SSB beams in half-frame
3. RAN2 also assumes that, with the current status of RAN1 discussion, if one cell is defined by multiple “satellite beams”, the satellite beams are all simultaneously active or inactive (“beam hopping” applies equally to all the satellite beams of a given cell)
4. The number of SMTC/gaps a UE needs to consider at any time will not be increased further
RAN2#129bis
1. From SSB extension point of view, RAN2 assumes there is no need to introduce new barring bits
2. We wait for further progress in RAN1 on link level enhancements before further discussing the possible impacts on access barring
3. RAN2 considers to support configuring two different SMTC periodicities (with different offsets) for SMTCs in one frequency layer for idle, inactive and connected mode. We ask RAN4 whether it is feasible to support this in Rel-19 timeframe (also include previous agreement that at any time the UE will not use more SMTCs in parallel than in previous releases).
4. We support configuring more than 4 SMTCs per frequency (e.g. 6) for idle/inactive UEs. It will be up to UE implementation to select which of the SMTCs to consider (send this RAN2 decision to RAN4 for checking)
5. Network can provide assistance information (for Rel-19 UEs, not necessarily supporting DL CE) on the association between SMTC and location to help UE to perform SMTC selection for idle/inactive mode. FFS on the details of location information, e.g. serving cell SSB index, reference location, etc. In any case it is up to UE implementation on how to utilize the assistance information for SMTC selection in idle/inactive mode.
Uplink Capacity Throughput enhancement
RAN2#129bis
1. There is no need to introduce dedicated access control mechanism for OCC capable UEs
Support of Broadcast service
RAN2#125bis
1. For MBS broadcast service we don’t restrict the work to any satellite constellation type
2. We prioritize working on a solution for MBS broadcast but we don’t preclude other broadcast services, namely ETWS
3. We will cover at least the case where the indicated intended service area covers a portion of a NTN cell
4. The intended service area can cover the area of more than one NTN cells (or portions thereof)
5. Can discuss next time whether the broadcast transmission can be limited to the intended service area only (i.e. no transmission happens outside of the intended serive area)
6. At least the following geographical area formats to model service area can be further considered (the signalling of other information than the geographical information can be considered):
- Circles (like for TN coverage)
- Geographical area information, e.g. via polygons, to better approximate the intended shape of service area
RAN2#126
1. For MBS broadcast service, both EFC and EMC are supported.
2. RAN2 will not define means for the NW to prevent the reception of the content of the service outside of the intended service area.
3. MBS broadcast intended service area is provided via system information
4. For MBS broadcast RAN2 considers the following possibilities for including the service area information: SIB20/ SIB21/ MBSBroadcastConfiguration. FFS for ETWS
5. When intended service area (e.g., geographical area/TN coverage) is provided for MBS broadcast service, it needs to be associated with MBS session (FFS on the details)
RAN2#127
1. The intended broadcast service area is defined by a geographical area represented by a (set of) referenceLocation and radius or by a (set of) polygon(s).
2. RAN2 understands that the expected UE behavior is that when the UE is not in any intended service area of its interested broadcast services, the UE may not need to (re)acquire up-to-date MCCH. FFS on solutions
3. For an MBS broadcast service intended for a certain area, a R19 UE supporting the feature should not establish MRB(s) for the MBS session associated to the intended area when it is outside the intended area (capture this in Stage 2)
4. For an MBS broadcast service intended for a certain area, a R19 UE supporting the feature may initiate the broadcast MRB establishment procedure when UE is inside the intended area; the UE may initiate the broadcast MRB release procedure when UE leaves the intended area (capture this in stage 3)
RAN2#127bis
1. For each MBS service we include one or more intended service area IDs into MCCH. FFS whether the list of the intended service areas (and related IDs) is also included in MCCH or if it is provided in a new or existing SIB. We will consider possible enhancements (including enhancements left up to UE implementation) to allow UE skipping MCCH re-acquisition when UE is not within intended service area of any interested broadcast service.
RAN2#128
1. The encoding of TN coverage introduced in Rel-18 in TS38.331, including tn-ReferenceLocation-r18 and tn-DistanceRadius-r18, is reused for the geographical area of the circle.
2. The encoding of Polygon in TS37.355 is reused for the geographical area of the Polygon.
3. The IntendedServiceArea is considered as the IE name of the geographical area (we can still update the name in the CR implementation if needed)
4. A signalled intended service area for a MBS BC service may include geographic areas across the current serving cell and overlapping neighbor cell(s).
5. RAN2 understands that the geographic area information for the intended service areas can be semi-static and not cause frequent updates.
6. Introduce a new SIB to include a list of intended service areas and related pointer (FFS if we point to the intended services areas via the index in the list or with an ID or another way)
7. The legacy SIB modification procedure is applied to update the intended service area information in the new SIB.
RAN2#129
1. In the new SIB, explicit network-indicated area ID is used to label an intended service area in the list
2. It shall be possible to signal multiple service area IDs to one MBS service (we Insert a list of service area IDs in MCCH)
3. Introduce “warning area coordinates” in ETWS Primary Notification (SIB6) and in ETWS Secondary Notification (SIB7). FFS on the signalling details for “warning area coordinates” (SIB6 is not segmented)
RAN2#129bis
1. RAN2 understands the Intended service areas of all MBS broadcast services of the current serving cell that need to be geo-fenced will be included in the new SIBxx (no spec impacts)
2. If UE knows it’s not in any intended service areas of any MBS services the UE is interested into, the UE may not need to acquire MCCH
3. If no intended service area is explicitly indicated (e.g. in SIBxx) for a MBS service the UE is interested into, existing behavior applies.
4. The field warningAreaCoordinates is included in SIB6 while the field warningAreaCoordinatesSegment is included in SIB7 for ETWS primary/secondary notification to indicate Warning Area Coordinates IE.
Support of regenerative payload
RAN2#126
1. Regarding potential issues with RRC re-establishment, RAN2 will wait for RAN3 input, if any
2. Regarding potential issues with support of Inactive state, RAN2 will wait for RAN3 input, if any
3. RAN2 aims at supporting RACH-less handover for regenerative architecture. Can further discuss whether any optimization is needed
4. RAN2 assumes that network verified UE positioning is supported for regenerative architecture
5. RAN2 assumes that the typical setting for common TA and kmac would be zero in case of regenerative mode with full gNB on board. FFS whether we capture in the spec that common TA and Kmac shall/should be set to zero.
RAN2#127
1. RAN2 confirms the understanding that legacy UEs should be supported in a regenerative payload scenario.
2. Send an LS to RAN1 and RAN4 asking whether in a regenerative payload scenario it would be a problem to stick to 0 as the minimum possible value for ta-Common or whether we should e.g. introduce negative values for ta-Common. Also indicate that in any case legacy UEs would have to rely on existing signalling and then on a minimum value equal to 0.
3. RAN2 understanding is that for regenerative payload existing RACH-less HO could be applied directly, no further Uu enhancement is needed.
4. We do not optimize UE power saving for SDT procedure in regenerative payload architecture
RAN2#129bis
1. Specific configurations of common TA and Kmac in regenerative architecture are not captured in the specs.
|