R2-2503346_S&F.doc |
TDoc file reading error |
|
R2-2503354 Further Discussion on S&F Operation.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2503354
St. Julian’s, Malta, May 19th – 23rd, 2025
Agenda item: 8.9.2
Source: vivo
Title: Further Discussion on S&F Operation
Document for: Discussion and Decision
|
Conclusion
In this contribution, we have further discussed the S&F operation aspect. And we make the following observations and proposals:
Information for the normal mode to S&F mode transition:
Proposal 1: RAN2 to firstly discuss whether the S&F capable UE is required to perform the cell reselection measurement before or upon the normal mode to S&F mode transition.
Proposal 2: If S&F capable UE is required to perform the cell reselection measurement before or upon the normal mode to S&F mode transition, legacy T-service is reused. Otherwise, the new time information is introduced.
Usage of the S&F monitoring list:
Observation 1: To assist UE perform subsequent attach/TAU, the satellite ID provided by the NAS is globally unique within the PLMN.
Observation 2: The satellite ID used in the RAN is not a global ID within the PLMN, i.e., it is allocated by the eNB and it uniquely identifies a satellite within the cell.
Proposal 3: RAN2 confirms whether and how UE prioritise the frequency(ies) corresponding to the satellite(s) indicated in the MME-configured satellite listis up to UE implementation.
S&F capability:
Proposal 4: No need to introduce AS S&F UE capability, NW can rely on the NAS level S&F UE capability to decide how to handle the UE.
|
R2-2503496_892_Panasonic_IoT-NTN_SnF_Remaining_Open_Issues.docx |
3GPP TSG RAN WG2 #129-bis R2-2503496
St. Julian’s, Malta, May 19th - 23rd, 2025
Source: Panasonic
Title: Store & Forward: Remaining open issues
Agenda Item: 8.9.2 Support of Store & Forward
Document for: Discussion, decision
|
Conclusions
In this document, we discussed the remaining open issues in conjunction with Store and Forward satellite operation mode.
The following observations and proposals were made:
Observation 1: Is normal Satellite operation mode now implicitly defined as everything not being equivalent to Store and Forward Satellite operation mode? Even in that case a few explanatory words might be helpful in the RRC spec.
In the end, “normal mode” might better be replaced by “real-time mode” – to prevent any potential ambiguities.
Observation 2: Using legacy t-Service for the purpose in question – the indication of the time instance a satellite changes from normal/real-time mode operation to S&F mode operation – is inappropriate, because feeder link switches can still happen during normal/real-time mode operation. Using legacy t-Service also for the new purpose discussed here would hence introduce an unwanted ambiguity. It would also affect legacy devices in an unwanted manner.
Observation 3: So far, there is neither an a priori indication provided within the currently serving cell regarding the mode of operation of a neighbouring or remote satellite nor is there an information in advance regarding the point of time the current mode of operation of the named neighbouring/remote satellite will change.
Proposal 1: Add explanation/definition for real-time Satellite operation mode to RRC CR.
Proposal 2: RAN2 to introduce a new indication for the point of time a satellite changes from normal/real-time mode to S&F mode.
Proposal 3: Should proposal 2 above find consensus, amend the field t-ModeSwitching by an optional indication of the time period the related satellite is going to operate in real-time mode.
Proposal 4: Drop recently agreed sf-OperationIndication flag, because the indication of the points of time a satellite changes between S&F and real-time operation modes provides the S&F status explicitly.
Proposal 5: If specification impact is rated reasonable, RAN2 to adopt an indication for mode of operation and time instance of mode change for neighbouring and remote cells in SIB33(-NB) and SIB32(-NB) respectively.
Proposal 6: RAN2 to assure that during the absence periods of relevant satellites UEs are precluded from monitoring paging in vain.
|
R2-2503499 Remaining issues for S&F operation in IoT NTN.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2503499
St Julian’s, Malta, 19th – 23rd May, 2025
Source: ZTE Corporation, Sanechips
Title: Remaining issues for S&F operation in IoT NTN
Agenda Item: 8.9.2
Document for: Discussion and Decision
|
Conclusion
Based on the above discussion, the following proposals are given:
Proposal 1: It’s suggested NOT to use the agreed time information in SIB31, t-ModeSwitching for transition from S&F mode to Normal mode, for both directions of transition. It’s easy to cause confusion if let UE determine which direction it is based on whether the S&F indication is present.
Proposal 2a: The agreed time information on transition from Normal mode to S&F operation mode (e.g., t-ModeSwitchingNtoSF) can be defined based on another agreed time information on transition from S&F operation mode to Normal mode (t-ModeSwitchingSFtoN) and with a new parameter of “duration of Normal mode”, as below:
t-ModeSwitchingNtoSF = t-ModeSwitchingSFtoN + duration of Normal mode
Proposal 2b: It’s suggested to introduce a new parameter “duration of Normal mode” which is in units of millisecond or seconds.
Proposal 3a: For quasi-earth fixed cell, it can be up to network’s implementation to set the t-Service in SystemInformationBlockType3(-NB) the time when the serving satellite starts to operate in S&F mode or the time when the serving satellite stops serving the area.
Proposal 3b: The earth moving cell case can be further discussed based on the progress for quasi-earth fixed cell case.
Proposal 4a: For quasi-earth fixed cell, it can be up to network’s implementation to set the t-ServiceStartNeigh in SystemInformationBlockType33(-NB) or t-ServiceStart in SystemInformationBlockType32(-NB) either the time when the neighbor satellite starts to operate in Normal mode or the time when the neighbor satellite starts serving the area.
Proposal 4b: The earth moving cell case can be further discussed based on the progress for quasi-earth fixed cell case.
Proposal 4c: It’s suggested to introduce a new time information when a neighbor satellite transits from S&F operation mode to Normal mode for each neighbor satellite in SystemInformationBlockType33(-NB).
|
R2-2503528 - Discussion on Store & Forward satellite operation.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2503528
St.Julians, Malta, 19th – 23rd May, 2025
Agenda Item: 8.9.2
Source: OPPO
Title: Discussion on Store & Forward satellite operation
Document for: Discussion and Decision
|
Conclusion
Based on the discussion above, we made the following observations and proposals:
Transition time between S&F mode and Normal mode
[RRC-1] Use the agreed time information in SIB31 for both directions of transition time between normal mode and S&F mode, and UE determines which direction it is based on whether the S&F indication is present.
Rel-19 UEs not supporting S&F operation allow to start neighbour cell measurement for reselection before transiting to S&F operation mode, like the behaviours adopted for t-Service.
S&F operation indication
Changes of S&F operation indication should result in system information change notifications.
Rely on NW implementation to handle UE in RRC_CONNECTED mode if NW switches between S&F operation mode and normal mode, and no special AS impact is foreseen. FFS whether there is any AS impact caused by NAS layer.
MME-configured satellite list
RAN2 clarifies that the UE configured with a satellite ID list by MME is not prevented to camp on, attempt to access to and communicate with a satellite which is not included in the MME-configured satellite list. i.e., it is up to UE to find better normal mode cell at any time.
Up to UE implementation whether to prioritize the cell in MME-configured satellite list in cell reselection.
Open issue on UE capability
[UE Cap-1] Not introduce AS capability signalling for UE supporting of S&F mode, given the introduced NSA capability for this.
4. |
R2-2503598.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2503598
St Julian’s, Malta, 19th – 23th May, 2025
Agenda Item: 8.9.2
Source: TCL
Title: Discussion on Store & Forward satellite operation
Document for: Discussion and Decision
|
Conclusion
Based on the discussion above, we made the following observations and proposals:
At this stage, no need to introduce any cell-priority-related mechanisms into the cell reselection procedure.
4. |
R2-2503674_Remaining issues for IoT NTN S&F.doc |
TDoc file reading error |
|
R2-2503768 Discussion on Store and Forward.docx |
3GPP TSG-RAN WG2 #130 R2-2503768
St. Julians, Malta, May 19th – 23rd, 2025
Source: DENSO CORPORATION
Title: Discussion on Store & Forward operation
Document for: Discussion and decision
Agenda Item: 8.9.2 Support of Store & Forward
|
Summary and proposal
This paper discussed about consideration on S&F operation and proposed the following:
Proposal 1: (RRC-1) RAN2 to use the agreed time information for both directions of transition, and UE distinguishes the direction according to the S&F indication
Proposal 2: (RRC-2) S&F related information for neighbour cells (current operation mode, transition time) could be provided to UE
Proposal 2a: (RRC-2) It can be up to network implementation whether S&F related information for neighbour cells is included in system information
Proposal 3: Satellite ID list provided by MME could be used for prioritization of cell reselection
Proposal 4: RAN2 to include frequency(-es) information associated to satellite ID in SIB33
|
R2-2503798 Open issues on the S&F mode transition time.docx |
3GPP TSG-RAN WG2 Meeting#130 R2-2503798
St. Julians, Malta, May 19th – 23rd, 2025
Agenda item: 8.9.2
Source: Google
Title: Open issues on the S&F mode transition time
Document for: Discussion and Decision
|
Conclusion
In this paper, we discuss the time information on when a cell will transition from the normal to the S&F mode, and have the following observations. Based on the observations and discussion in this paper, we respectfully ask RAN2 to discuss and consider the following proposals.
Observation 1 (RRC-1) If t-Service is used to indicate when the S&F mode will start, S&F-capable UEs could trigger the neighbor cell measurement and cell reselection too early, resulting in unnecessary UE power consumption.
Observation 2 (RRC-1) Legacy UEs will still remain in the serving cell after t-Service, even if t-Service is used to indicate when the S&F mode will start.
Observation 3 (RRC-1) The best way to direct legacy UEs to other normal-mode cells is to rely on the legacy barring bit.
Proposal 1 (RRC-1) When the S&F operation indication is present, the agreed time information in SIB31 (i.e., t-ModeSwitching) indicates when the normal mode will start; otherwise, the agreed time information in SIB31 (i.e., t-ModeSwitching) indicates when the S&F mode will start.
Proposal 2 UE AS can utilize the transition time from the normal mode to S&F mode to determine: 1) when to trigger the neighbor cell measurement, and 2) whether to establish/reestablish/resume an RRC connection.
Proposal 3 (RRC-2) To prioritize the cells operating in normal mode during the cell reselection, a list of cells not operating in the S&F mode can be provided in the system information.
|
R2-2503908 Mode transition time for S&F operation (Revision of R2-2502355).docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2503908
St. Julians, Malta, May 19th – 23rd, 2025 Revision of R2-2502355
Agenda item: 8.9.2
Source: Lenovo
Title: Mode transition time for S&F operation
Document for: Discussion
|
Conclusion
In this contribution we discuss further issues and enhancements for the mode transitions in S&F operation.. The following proposal are provided:
Proposal 1: If t-Service is reused to indicate “S&F to normal” mode transition time in S&F operation, RAN2 to discuss how to identify its purpose between “S&F to normal” mode transition time and cell stop serving time.
Proposal 2: If t-Service is reused to indicate “S&F to normal” mode transition time in S&F operation, at least S&F-incapable UE is not required to trigger neighbour cell measurement for cell reselection before t-Service. FFS for S&F-capable UE.
Proposal 3: If a new indication (e.g. t-SFtoNORMAL) is introduced to indicate “S&F to normal” mode transition time in S&F operation, at least S&F-incapable UE is not required to trigger neighbour cell measurement for cell reselection before t-SFtoNORMAL. FFS for S&F-capable UE.
Proposal 4: The time information on transition from normal mode to S&F operation mode is provided in SIB31.
Proposal 5: Use absolute UTC time or relative time duration to “S&F to normal” mode transition time to broadcast the “normal to S&F” mode transition time information. When this information is broadcast and indicates a time in the future the UE can assume the NW is currently operating in normal mode (until the indicated “normal to S&F” mode transition time).
Proposal 6: A change to the “normal to S&F” mode transition time indication shall not result in system information change notification. Legacy rules for acquiring SIB31 apply.
Proposal 7: If t-Service is reused to indicate “normal to S&F” mode transition time in S&F operation, RAN2 to discuss how to identify its purpose between “normal to S&F” mode transition time and cell stop serving time.
Proposal 8: If t-Service is reused to indicate “normal to S&F” mode transition time in S&F operation, S&F-capable UE is not required to trigger neighbour cell measurement for cell reselection before t-Service. S&F-incapable UE is required to trigger neighbour cell measurement for cell reselection before t-Service.
Proposal 9: If a new indication (e.g. t-NORMALtoSF) is introduced to indicate “normal to S&F” mode transition time in S&F operation, S&F-capable UE is not required to trigger neighbour cell measurement for cell reselection before t-NORMALtoSF, and S&F-incapable UE is required to trigger neighbour cell measurement for cell reselection before t-NORMALtoSF. |
R2-2504034.docx |
3GPP TSG-RAN WG2#130 R2-2504034
Malta, MT, May 19th – 23rd, 2025
Agenda Item: 8.9.2 Support of Store & Forward
Source: NEC
Title: Remaining issues on S&F
Document for: Discussion
|
Conclusion
In summary, we would like to share our view on remaining details of S&F as follows:
UE NAS may check if the serving satellite is one of the MME-configured satellite ID(s), and to decide whether to resume S&F service
Proposal 1: Use a separate IE to indicate the transition time from the normal mode to S&F mode (i.e. not reuse or link to T-service)
Proposal 2: Broadcast the time duration of the normal mode, instead of the transition time from the normal mode to S&F mode
Proposal 3: Revisit the agreement on the dynamic “S&F operation” indication and change it into a static “S&F cell” indication (i.e., no need to update the value when feeder link is resumed for short time)
Proposal 4: UE AS sends serving satellite ID to NAS
Proposal 5: RAN2 discuss if network provides operation mode of the neighbouring satellites, and assist UE implementation to prioritize/deprioritize cell reselection to a S&F satellite within/not within MME-configured satellites
Proposal 6: UE(s) who support S&F feature, also support discontinuous coverage-like feature, i.e. upon service link becoming unavailable and there is no neighbor cell:
- For UE in RRC_IDLE, RAN2 assume the UE suspends all AS idle mode operations related to NTN.
- For UE in RRC_CONNECTED mode, either NW will release the UE, or the UE will declare RLF and enter idle mode directly.
Proposal 7: If a UE is provided with an MME-configured satellite set and PUR resources was configured by one of the MME-configured satellite cells, the UE could resume the PUR configuration once camping on any of the MME-configured satellites.
|
R2-2504046.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504046
St.Julians, Malta, May 19th–23rd, 2025
Agenda Item: 8.9.2
Source: Transsion Holdings
Title: Discussion on support of Store&Forward
Document for: Discussion and Decision
|
Conclusion
In this contribution we discussed issues related to S&F mode in IoT-NTN and made the following proposals:
Observation 1 The paging demand maybe not random anymore and the paging and downlink data needed to be send by network maybe huge in S&F mode which may cause paging congestion.
Proposal 1: When the S&F operation indication is not broadcast, the time information in SIB31 can be interpreted as the time when the current satellite operation will transit from normal mode to S&F operation, while when the S&F operation indication is broadcast, the time information in SIB31 can be interpreted as the time when the current satellite operation will transit from S&F operation to normal mode.
Proposal 2: If the remaining time from normal mode to S&F mode is not enough to finish the service, the UEs not support S&F mode may not triggered to access the network.
Proposal 3: RAN2 to consider the paging congestion issue caused by the non-randomized and huge paging demand.
Proposal 4: Two different Paging parameters can be configured for S&F mode and normal mode.
Proposal 5: UE keeps monitoring paging for some cycle or some times or some duration and if no paging for the UE is received or the UE has monitored the paging for the UE, the UE stop monitoring paging in the rest time when the current satellite is in S&F mode.
Proposal 6: When UP mode is used, the UE context can be transfered/distributed to specific satellies via the network on ground when the feederlink recovered and the UE only resumes connecton to these satellites. How the satelllites are determined is FFS.
Proposal 7: The security key used by the new eNB can be generated advance by the old eNB using the parameters(e.g. PCI、EARFCN-DL) associated with the determined satellite list and transfered to these satellties via the ground network.
|
R2-2504090 Open issues on Store and Forward operation.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504090
Malta, Malta, 19th – 23rd May, 2025
Agenda item: 8.9.2
Source: Samsung
Title: Open issues on Store and Forward operation
WID/SID: IoT_NTN_Ph3-Core
Document for: Discussion and Decision
|
Conclusion
In this contribution, we discussed issues related to S&F network:
Observation 1: It cannot be fully up to UE implementation in the AS layer how to behave during S&F when S&F monitoring list is received.
Observation 2: Paging is not only monitored for downlink data, but also for system information update.
Proposal 1: The S&F monitoring list shall allow a UE to not perform its NTN idle mode tasks if a UE only has coverage from a satellite that is not part of the S&F monitoring list. When the UE is covered by a satellite that is a part of the S&F monitoring list, the UE performs the NTN idle mode tasks.
Proposal 2: The S&F monitoring list is used in AS for UE to perform discontinuous coverage operation on the satellites indicated in the monitoring list.
Proposal 3: Do not introduce neighbour cell signalling related to Store and Forward.
Proposal 4: Do not introduce enhancements specific to paging monitoring for S&F.
|
R2-2504097.docx |
3GPP TSG RAN WG2 #130 R2-2504097
St. Julian’s, Malta, May 19th – 23rd, 2025 Resubmission of R2-2502620
Agenda Item: 8.9.2
Source: Toyota ITC
Title: Discussion on Paging and Mode Switching
Document for: Discussion and Decision
|
Conclusion
This contribution discusses uplink capacity enhancements. Observation and proposals are summarized as follows:
Proposal 1: The UE is required to monitor N paging occasions after switching from real-time to store-and-forward mode, with N configured by the network.
Proposal 2: Standardize a signaling mechanism to avoid traffic surges caused by simultaneous access when transitioning from store-and-forward to real-time operating mode.
|
R2-2504138-Store-Forward-RAN-Aspects.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504138
St Julians, Malta, 19 – 23 May 2025
Agenda item: 8.9.2
Source: Nokia, Nokia Shanghai Bell
Title: RAN impacts for IoT-NTN SF Operations
WID/SID: IoT_NTN_Ph3 - Release 19
Document for: Discussion and Decision
1 |
Conclusion
In this paper we analyse the radio signalling procedure impacts for store and forward operation. Following proposals are
made based on the analysis.
Issues for normal mode to SF mode transition
Proposal 1: RAN2 to confirm that existing system information change notification can be reused to indicate the transition from normal to SF mode.
Observation 1: The remaining time information for normal to SF mode may be useful for applications on delaying some transactions based on this information. The actual usage scenario where this information is beneficial is not clear.
Proposal 2: The transition time information introduced for SF mode to Normal is also re-used for Normal- SF mode transition.
Issues for cell reselection
Proposal 3: RAN2 to confirm that cell selection /reselection is not impacted by the satellite list provided from NAS. RAN2 to decide on the changes if any based on SA2 LS indicating RAN2 impacts based on the NAS provided information.
Proposal 4: Cell reselection when SF mode is active in current cell is up to UE implementation. No specification changes needed to enhance the cell reselection procedure for SF mode operation.
Access control and Paging Enhancements for SF operation
Proposal 5: RAN2 to consider inclusion of additional information for access control for MO or MT based on storage status in SF operation.
Proposal 6: RAN2 to consider paging enhancements in SF mode for delivering ACK for MO Traffic and MT Traffic towards IoT-NTN UE.
Proposal 7: RAN2 to consider indication of MT data unavailability in storage for paging monitoring enhancements for SF capable UE.
|
R2-2504174_Store and Forward.doc |
TDoc file reading error |
|
R2-2504179 (R19 IoT-NTN AI 8.9.2) - Support of S+F.docx |
3GPP RAN WG2 Meeting #130 R2-2504179
St.Julians, Malta, May 19th – 23rd , 2025
Agenda Item: 8.9.2
Source: InterDigital, Inc.
Title: Store and Forward open issues.
Document for: Discussion
|
Conclusion
In this contribution we discuss support of PWS and make the following proposals for discussion:
S&F Operation mode
Observation 1: The agreed behaviour for “S&F operation” is identical to “cellBarred” and feature specific “cellBArred” IEs.
Proposal 1: To align with existing IEs of the same type and behaviour, “S&F operation” IE is named “cellBarredSandF” and has the value “barred” or “not barred”.
Proposal 2: If the UE is barred due “cellBarredSandF” (or whatever the name is) = “barred” the UE uses the value of the remaining time parameter to determine how long to bar the cell. FFS the case of changing from normal to S&F mode.
Proposal 3: RAN2 assumes that the legacy t-Service will be set to S+F mode switch time in order that legacy UE interprets this as end of the service time.
Proposal 4: Introduce a one of the following options:
Option 1) A flag to indicate whether t-Service represents the remaining time of normal mode before switching to S+F mode, or whether it represents the end of service (per legacy).
Option 2) Introduce a new time IE for S+F UEs. If present, the new time value is set by the network to the service end time (similar to legacy t-Service), and legacy t-Service is interpreted by UEs supporting S+F as the S+F mode switch time.
Cell reselection prioritization
Observation 2: According to the current 36.304 the UE is not allowed to prioritize cells or carriers corresponding to the S+F monitoring list provided by NAS, therefore the note in 23.401 (“How UE behaves when receiving the S&F Monitoring List is up to UE implementation.”) appears to be meaningless without introducing changes to the cell reselection evaluation procedure in RAN2.
Proposal 5: For eMTC, if the UE is operating in S+F mode, the UE may consider frequencies associated with satellite IDs within S+F monitoring list to be the highest priority.
Proposal 6: For NB-IoT, introduce an offset to apply to the cell ranking criteria R. If the UE is operating in S+F mode, the UE applies the offset to frequencies associated with satellite IDs within S+F monitoring list to be the highest priority.
|
R2-2504202.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504202
Malta, 19-23 May 2025
Agenda item: 8.9.2
Title: Further considerations on S&F operations
Source: Continental Automotive
Document for: Discussion and Decision
|
Conclusions
The following proposals have been made in this contribution:
Proposal 1: To manage situations of constraint storage capacity and enhance quality of service, the network configures to UE which services are allowed to transmit in UL when operating in S&F mode.
Proposal 2: t-Service should not be re-used as transition time indication from normal mode to S&F mode.
Proposal 3: The network should configure different wait timers to the UEs considering the MME-configured satellite list for the transition from normal mode to S&F mode.
|
R2-2504277 Further consideration on Store and Forward.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504277
St Julian’s, Malta, 19th – 23rd May, 2025
Agenda Item: 8.9.2
Source: Huawei, HiSilicon, Turkcell
Title: Further consideration on Store and Forward
Document for: Discussion and Decision
1 |
Conclusion
This contribution discusses the store and forward operation for IoT NTN and we have the following proposals:
Remaining time of current operating mode
Observation 1: Setting t-Service to the transition time does not change the legacy principles and behaviour of the legacy UEs.
Proposal 1:(RRC-1) It is up to NW implementation to set the legacy t-Service to the transition timing from normal mode to “S&F operation” mode in some cases and a new t-ServiceSF can be introduced to indicate the stop-serving time of the SF mode.
Paging in S&F satellite operation
Proposal 2: (RRC-4) If the NW doesn’t have any MT data buffered for an area, it informs the UE so that the UE doesn’t need to monitor paging or initiate RRC connection.
Access control
Proposal 3: S&F NW should prioritize the access of the UE, if it is subsequently re-attempting the access to the NW. The re-attempt from the UE can be indicated to the network while performing RRC Connection Establishment procedure.
Issue of satellite ID
Proposal 4: When determining whether to perform measurement in IDLE, the UE should consider both NAS information (i.e., Satellite list and NAS wait timer) and the information in SIB32 (i.e., t-ServiceStart and ephemeris).
Proposal 5: If a satellite indicated in SIB32 but not included in the NAS satellite list is operating in SF operation, the UE should not access it.
4 |
R2-2504317 store and forward.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504317
St. Julians, Malta, 19 - 23 May 2025
Agenda item: 8.9.2
Source: Qualcomm Incorporated
Title: Switching of S&F mode
Document for: Discussion and Decision
|
Conclusion
Following observation and proposals are made:
Proposal 1 If t-Service is equal to switching time of S&F mode to normal mode, broadcast 1 bit indication instead of 20bits of TimeOffsetUTC.
Proposal 2 For switching time from normal mode to S&F mode, the value of existing cell stop time (t-Service) is configured to the switching time.
Proposal 3 For legacy UEs, the existing behavior of t-Service applies when normal mode is switched to S&F mode at t-Service.
Proposal 4 For new UEs, S&F indication (1 bit indication as in Proposal 2) is used to associate the existing cell stop time with the switching time from normal mode to S&F mode.
Proposal 5 Upon mode switch, discuss how to update the system information without paging if barring bit or S&F mode indication or presence of common TA is changed.
Proposal 6 When connected to S&F mode cell, it can be left to UE in RRC_IDLE to periodically search for better normal mode cell (i.e., cells with feeder link connection available).
Proposal 7 When in RRC_IDLE and waiting to connect to a S&F mode satellite, it can be left to UE to prioritize the search for better and normal mode cell (i.e., cells with feeder link connection available).
Proposal 8 Wait timer configured by MME is sufficient for UE power saving and there is no need to add enhancements for paging monitoring.
Proposal 9 Decide whether eNB needs to know the UE’s store and forward capability.
|
R2-2504351.doc |
TDoc file reading error |
|
R2-2504366 Discussion on RAN2 impacts due to the MME-configured satellite list.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504366
St. Julians, Malta, May 19th – 23rd, 2025
Agenda Item: 8.9.2
Source: CATT, Google, Sateliot, Thales
Title: Discussion on RAN2 impacts due to MME-configured satellite list
Document for: Discussion and Decision
|
Conclusion
In this contribution, some leftover issues on support of S&F operation are discussed with corresponding proposals listed as follows:
Observation 1: SA2 agreed that the MME-configured satellite list is used by the UE assist with saving power and determining which satellites to receive MT data/signalling.
Observation 2: As specified in the latest TS 23.401, SA2 intends to leave some room for the UE to decide which S&F satellite to access, with the consequence also specified that if the UE access a satellite that is not belonging to the S&F Monitoring List there is increased probability that it will not be able to complete the NAS procedure.
Observation 3: Following the current cell (re)selection procedure, the UE shall (re)select to/camp on a cell that meets related RSRP/RSRQ conditions and the NW configured priority. This leaves no room for UE implementation to further consider the MME-configured satellite list as specified in SA2 Spec, resulting in increasing UE access failure as highlighted by SA2 (in case of an access attempt to a satellite not in the MME-configured list).
On Cell reselection enhancements
Proposal 1: RAN2 agrees that the UE may not consider the cell operating in S&F mode as a suitable cell for reselection, if it is not a cell provided by the satellites included in the MME-configured satellite list.
Proposal 1a: RAN2 adopts the TP provided in the Annex A as the baseline, if Proposal 1 is agreeable.
Proposal 2: RAN2 discusses whether any new assistance information needs to be introduced into system information for the S&F operation (e.g. mapping between satellite ID(s) and {frequency(ies), PCI(s)}), if Proposal 1 is agreeable.
On IDLE Mode task relaxation
Proposal 3: When a MME-configured satellite list is configured by upper layers, the UE may stop the IDLE mode tasks (e.g. cell (re)selection, paging monitoring, etc.) if the UE determines that it is out of coverage of all target satellite(s) indicated by MME. How the UE determines being out of coverage of all target satellites is up to UE implementation.
Proposal 3a: If Proposal 3 is agreed, RAN2 further discusses whether to introduce a separate list in system information to provide the satellite assistance information for S&F operation (i.e., used by UE to predict the coverage time of the satellites indicated by MME).
|
R2-2504367 Discussion on IoT NTN Store and Forward.docx |
3GPP TSG-WG2 Meeting #130 R2-2504367
Malta, MT, 19th May 2025 - 23rd May 2025
Source: CMCC
Title: Discussion on IoT NTN Store and Forward
Agenda item: 8.9.2
Document for: Discussion
|
Conclusions
Opposite time information indication
Proposal 1: T-service can be used as the time information indication from normal mode to S&F mode.
Proposal 2: The agreed time information can be used for to indicate the end of S&F mode after UE switching from normal mode to S&F mode.
Measurement and cell reselection
Proposal 3: It is proposed to introduce operation mode of the neighbour cells as the additional assistance information.
Proposal 4: It is proposed to introduce mode transmission time of the neighbour cells as the additional assistance information.
Proposal 5: It is proposed to introduce one absolute value time information to indicate the operation mode and mode transmission time of the neighbour cells. e.g., t-serviceStartSF in SIB32 or t-serviceStartNeighSF in SIB33.
Proposal 6 During cell reselection procedure, UE may prioritize frequency(ies) corresponding to the satellite(s) indicated in the MME-configured satellite list
Proposal 7 During cell reselection procedure, compared with the satellites in S&F mode, satellites in normal mode may have a higher priority.
UE capability
Proposal 8: It is proposed to introduce a new AS capability for UE supporting S&F mode.
Paging enhancement
Proposal 9: S&F capable UE can relax the paging monitoring in the following scenarios:
UE is not within the satellite coverage area
UE is in a cell operating in S&F mode:
The network has already transmitted stored DL data and UE goes back to idle state after receiving all stored data from the satellite
The satellite never recover its feederlink
System information change notification
Proposal 10: Before mode switching, eMTC NTN UE in RRC connected mode can update changed S&F operation indication through dedicated signaling, rather than going back to idle mode and receiving paging message.
Proposal 11: Before mode switching from normal to S&F, NB-IoT NTN UE in RRC connected mode can deduce the time of operation mode switching by using operation time information based on implementation, the network does not need to release UE to idle state for the reason of changing the update system information.
|
R2-2504478 Discussion on the Store and Forward satellite operation.docx |
3GPP RAN WG2 Meeting #130 R2-2504478
St.Julians, Malta, May 19th – 23rd, 2025
Agenda Item: 8.9.2
Source: HONOR
Title: Discussion on the Store and Forward satellite operation
Document for: Discussion and Decision
1. |
Conclusions
In this contribution, we discussed the issues related to Store & Forward (S&F) satellite operation with split MME onboard. Based on the discussion, the following proposals are concluded:
Proposal 1: (issue RRC-1) An absolute UTC time can be used to indicate the time when the mode will change from normal mode to S&F mode.
Proposal 2: (issue RRC-2) The S&F timing information of neighbour cell (e.g., t-ServiceStartNeigh_s&f-r19) can be provided as satellite assistance information.
Proposal 3: (issue RRC-4) The UE can decide whether to monitor paging based on the time information about the last time the feeder link was available.
Proposal 4: Both the UE and MME can provide the eNB with the configured satellite ID list information.
4. |
R2-2504497 Discussion on time information for S&F.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504497
St. Julian’s, Malta, 19th-23rd May, 2025
Agenda Item: 8.9.2
Source: ASUSTeK
Title: Discussion on time information for S&F
Document for: Discussion and Decision
|
Conclusion
We have the following proposals for S&F transition time information:
Proposal 1: Use t-ModeSwitching to indicate both transition time on S&F operation mode to normal mode and transition time on normal mode to S&F mode.
Proposal 2: When t-ModeSwitching indicates transition time on normal mode to S&F mode, for a UE not supporting S&F, the UE performs measurements of neighbouring cells before t-ModeSwitching and considers radio link failure upon t-ModeSwitching.
|
R2-2504527 RAN2 impact on SF mode.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504527
Malta, Malta, May 19th – 23th, 2025 Revision of R2-2502769
Agenda item: 8.9.2
Source: MediaTek Inc.
Title: RAN2 impact on S&F mode
Document for: Discussion and Decision
|
Conclusion
Proposal 1: It is up to UE implementation to prioritize the cell in the monitoring list during the cell selection and cell reselection.
Proposal 2: Network ensures that the satellite IDs provided in SIB31(-NB), SIB32(-NB), and SIB33(-NB) are globally unique within PLMN.
|
R2-2504550.docx |
3GPP TSG RAN WG2 Meeting #130 R2-2504550
St. Julian’s, Malta, May. 19th - 23rd, 2025
Agenda Item: 8.9.2
Source: ETRI, Korea University
Title: Remaining issues on Store and Forward satellite operation
Document for: Discussion and Decision
1 |
Conclusion
In this paper, the following observations are made:
Observation 1 Information of the neighbour cells served by a satellite operating in S&F mode need to be delivered to only S&F-capable UEs.
In this paper, we propose the followings:
Proposal 1 To indicate the time information of transition from normal mode to S&F mode, RAN2 to choose either Option 2 (a new parameter) or Option 3 (t-ModeSwitching + absence of S&F mode indication).
Proposal 2 Additional assistance information for the neighbour cells served by a satellite operating in S&F mode is introduced.
Proposal 3 A new time indication of the earliest time when the area covered by the current serving cell is going to be covered by the neighbour cell served by the satellite operating in S&F mode is introduced.
|
R2-2504617 - “S&F Monitoring List” and “S&F Wait Timer” and potential RAN2 impacts_v02.docx |
3GPP TSG-RAN WG2 Meeting #130 R2-2504617
Malta, MT, May 19th – 23rd, 2025
Source: Sateliot, Thales, Novamint
Title: Discussion on “S&F Monitoring List” and “S&F Wait Timer” and potential RAN2 impacts
Agenda Item: 8.9.2
Document for: Discussion and Decision
|
Conclusion
A) Clarifications on the intended of the “S&F Monitoring List” and “S&F Wait Timer” in a deployment based on the split-MME architecture
Observation 1: S&F Satellite operation involving multiple satellites of the same PLMN is considered to be the general case, while the use of a single serving satellite per UE it’s just a particular case.
Observation 2: For split-MME architecture, involving multiple satellites means that the NW needs to cope with UE context synchronization between the multiple MME-onboard(s) and the associated MME-ground so that the change of serving MME-onboard across subsequent passes remains unnoticed to the UE. How UE context synchronization is performed has been left out of 3GPP specs.
Observation 3: In the split MME-architecture, involving multiple satellites does not necessarily mean that a UE is going to be served by all the satellites of the PLMN. Indeed, as indicated in TS 23.401 V19-2.0 Annex O.2: “Based on implementation, the UE context can be uploaded on a subset of MME-onboard(s) or all MME-onboard(s) associated with MME-ground.” and “An MME-onboard is associated with a Satellite ID identifier.”
Observation 4: For split-MME architecture, the “S&F Wait Timer” and “S&F Monitoring List” are two fundamental tools to cope with the issue of UE context synchronization on the NW side. In particular, “S&F Wait Timer” and “S&F Monitoring List” allow the NW to prevent a UE to access a satellite operating in S&F mode if no UE context is available in that satellite or the UE context is not yet synchronized.
B) Cell (re)selection enhancements
Observation 5: If a UE has received a “S&F Wait Timer” and/or a “S&F Monitoring List” from a MME operating in S&F mode, the UE is not expected to perform a NAS procedure:
Condition A: In any satellite operating in S&F mode of the same PLMN, as long as the S&F Wait Timer is running.
Condition B: In a satellite operating in S&F mode of the same PLMN which is not included in the S&F Monitoring List.
Proposal 1: Enhance the definition of suitable cell in 36.304 so that a UE may consider a detected cell as unsuitable and not treating it as a candidate for reselection, if the detected cell is handled by a satellite operating in S&F mode for which conditions (A) and/or (B) are met.
C) Relaxation of idle mode tasks
Observation 5: A UE that has received a “S&F Wait Timer” and/or a “S&F Monitoring List” from a satellite operating in S&F mode is not prevented from searching other suitable cells and, if found, accessing them whenever conditions (A) and/or (B) are respected.
Observation 6: As per SA2 specs: “NOTE 5: When the S&F Wait Timer is running, the power consumption optimization behaviours, if any, are left for UE implementation e.g. whether to listen to paging or deactivate its Access Stratum functions”.
Observation 7: If satellites operating in S&F mode also exhibit discontinuous coverage, existing mechanisms to handle discontinuous coverage can be leveraged (e.g. SIB32, t-service, relaxation of idle mode tasks when UE is out of coverage, etc.).
Proposal 2: In a S&F network deployment which also exhibits discontinuous coverage, existing mechanisms to handle discontinuous coverage can be leveraged (e.g. satellite assistance information, UE not needing to perform idle mode tasks when the UE determines that is out of coverage, etc.). There is no need to modify existing discontinuous coverage features due to the addition of S&F Satellite operation.
Proposal 3: Potential relaxation of idle mode tasks, if any, when “S&F Wait Timer” and/or “S&F Monitoring List” are set in the UE by upper layers is left for UE implementation. (For example, if the UE is out of coverage because of discontinuous coverage and the UE determines that next coverage window is going to be provided by satellite operating in S&F mode that it’s not included in the “S&F Monitoring List”, the UE may skip such coverage window).
D) Relating Satellite ID in SIBs and in “S&F Monitoring List”
Observation 8: Current specs include different definitions and uses of satellite identifiers (“satelliteId-r17”, “satelliteId-r18”) in different SIBs (SIB31/32/33/3/5). Relation, if any, between the use of these identifiers is not explicitly stated. How the UE is expected to determine a single/unique satellite identifier for the serving satellite that can be used in the “S&F Monitored List” could be open to different interpretations.
Proposal 4: RAN2 to clarify in the specs that the values used in “satelliteId-r17” within SIB32 are expected to correspond to the values used in “satelliteId-r18” in other SIBs (e.g. the value used to identify the serving satellite in SIB32 and SIB31 should be the same) and which is the correspondence between the “satelliteId” IE and “S&F Monitoring List”.
|
R2-2504654 - Support for store and forward in IoT NTN.docx |
3GPP TSG-RAN WG2 #130 R2-2504654
St. Julian’s, Malta, May 19th – 23rd, 2025
Agenda Item: 8.9.2
Source: Ericsson
Title: Support for store and forward in IoT NTN
Document for: Discussion, Decision
1 |
Conclusion
In the previous sections we made the following observations:
Observation 1 A UE may benefit from knowing the S&F operation status of neighbor satellites to steer mobility procedures.
Based on the discussion in the previous sections we propose the following:
Proposal 1 A UE continues executing its NTN idle mode tasks related to S&F operation (e.g., cell (re)selection, paging monitoring) even when it is not served by a satellite in the NAS monitoring list.
Proposal 2 The network informs the UE of the operation mode (S&F/non-S&F) of neighbour cells/satellites.
Proposal 3 A new condition is introduced in cell reselection to consider the satellite operation mode (S&F/non-S&F).
4 |