Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TR 23.700-01  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…

 

4  Key issuesp. 10

4.1  Key issue #1: Usage of satellite access characteristics for the application enablementp. 10

4.1.1  Descriptionp. 10

3GPP SA1 has specified the service requirements for 5G for satellite access in TS 22.261 which including supporting 5G system with satellite access, suitable QoS parameters for traffic over a satellite backhaul, etc. And 3GPP SA2 has also specified the architecture and solutions in Rel-17 and Rel-18 to support these services requirements identified in SA1.
Service enablers defined by SA6 should also considering to take advantage of the output from SA1 and SA2 to ensure that application enablers support the satellite access, and should utilize the satellite access characteristics (e.g. QoS parameters for traffic over a satellite access) to optimise application layer enablement behaviour to provide a better service experience. Also investigate the need of any new analytics related to satellite access characteristics that need to be supported as part of the ADAE service (TS 23.436) which can be utilized by the application servers and application enablement layers in order to provide a better service experience over satellite access.
Up

4.1.2  Open issuesp. 11

To support the satellite access in application enablers, the following aspects need to be studied:
  • What are the satellite access characteristics that can be utilized by the application enablers?
  • Whether and how to use the satellite access characteristics (e.g., QoS parameters for traffic over a satellite access) to optimise the application enablement behaviour for the existing application enablers.
  • Whether and what new analytics required for the satellite access for providing a better service experience by the existing application enablement servers or application servers.
Up

4.2  Key issue #2: Edge computing on satellitep. 11

4.2.1  Descriptionp. 11

UPF and Edge in the backhaul part of a 5GS (i.e. on board a GEO satellite) facilitates reduction of latency and faster service provisioning to end users. TS 23.558 (SA6) defines Architectures for enabling Edge applications including the procedures for EAS discovery. Although TS 23.558 specification is created to cover the most generic EDGEAPP cases- it would be beneficial to study whether the placement of Edge on board satellite requires some enhancements of application enablers. The motivation for this is to explore whether EDGEAPP enhancements could reduce latency in cases when Edge has been placed on board GEO satellite. Besides, the interest is to investigate whether EDGEAPP enhancements could reduce data load in the feeder link (the link between 5GC on the ground and GEO satellites).
Up

4.2.2  Open issuesp. 11

Deployment of Edge computing on board GEO satellites might impact the latency of application control and data information exchange. To assess the impacts of using Edge on board GEO satellites it would be benefitial to study the following aspects with the aim to reduce latency and data exchange over satellite feeder link:
  1. Investigate different deployment options for EDGEAPP when EASs are deployed on board GEO satellites?
  2. When/how could EAS discovery by the EEC in EDGEAPP be optimized?
  3. Whether and how the service continuity procedures are impacted while the UE is only connected with NTN?
Up

4.3  Key issue #3: Satellite access with discontinuous coveragep. 11

4.3.1  Descriptionp. 11

In a network with satellite access, a UE may experience a situation of discontinuous coverage, due to e.g., a sparse NGSO satellite constellation deployment. An illustration of a discontinuous coverage pattern for a given UE location and a single example LEO satellite at a nominal 600 km altitude is represented in Figure 4.3.1-1 (reproduced from R2-2107453 [16]). The figure shows the flyovers where the satellite passes above 30 degrees elevation as seen from the UE location. The rise time of the satellite is plotted on the x axis against the visibility duration on the y axis. The results do not consider link budget aspects, only geometrical visibility above the given elevation angle. In the provided example, the satellite is visible from the UE location twice on most days, and occasionally three times, and the interval between passes varies between ~9 to 13.3 hours, with a mean of 11.9 hours. The median duration of the visibility window lasts around 220 seconds (3.6 minutes), with 90% of flyovers longer than 110 seconds.
This sort of discontinuous coverage pattern between the UE and a satellite can be predicted ahead of time for periods of days or even a few weeks with good accuracy (e.g. time errors of a few tens of seconds in estimating the starting time of the satellite pass when considering prediction windows of up to a few tens of days) by means of orbit propagation models and satellite ephemeris information (see R2-2206115 [17] for prediction estimation errors using TLE and SGP4 propagator).
Copy of original 3GPP image for 3GPP TS 23.700-01, Fig. 4.3.1-1: Flyovers and duration of visibility (≥ 30 degrees elevation) for a single LEO-600 km satellite (source: R2-2107453 [16])
Up
From a network perspective, support to cope with the discontinuous coverage nature of the service link in sparse constellations has been specified in Rel-17 and Rel-18. This support includes optional enhancements within the radio access network (e.g., satellite ephemeris parameters are broadcast in SIBs for satellite pass predictions for IoT NTN access) and within the core network (e.g., mobility management and power saving optimization, coverage availability information provisioning, paging, overload control). Coverage availability information provisioning to the UE and to the MME/AF entities have been also been identified, though no specific protocol or format have been defined in the specifications. All these enhancements help the UE and the network to gracefully operate under a discontinuous coverage pattern.
However, regardless of these enhancements at the network level, the discontinuous coverage nature of the service link results into an intermittent connectivity pattern between the UE and the Application Server (AS)/Application Function (AF) that has also a direct impact on the behaviour of the application.
Supplying information on the discontinuous coverage pattern or related services to the application layer will help applications to design themselves for handling discontinuity accordingly. For instance, if the discontinuous /intermittent connectivity pattern can be predicted in advance and exposed to the application layer in the network side, the application layer could use this information to properly schedule data transfers between the UE and the AS/AF (e.g. some information flows can be given precedence during short connectivity intervals, bulky data exchanges can be deferred and planned during longer connectivity intervals, notifications on expected data delivery times can be provided, etc.).
Once the discontinuous coverage patterns provided by different satellite operators are retrieved by an application enabler on the network side, specific information exposure policies can be enforced. For example, a certain vertical application may be allowed to access such discontinuous coverage patterns in specific times of the day and under specific circumstances, for example when the UE is located in a certain geographical area.
It is therefore necessary to study if some support to handle discontinuous coverage at application layer should be introduced in existing or a new application enabler.
Up

4.3.2  Open issuesp. 12

To support the discontinuous satellite coverage in application enabler, the following aspects need to be studied:
  • Whether and how the information on discontinuous satellite coverage needs to be exposed to the application layer (e.g. semantics, service-based interfaces, etc.) on the AS/AF side.
  • Whether and how the application enabler enforces policies (e.g., based on the time of the day, the UE location, etc.) on the discontinuous coverage information exposure towards the vertical applications.

4.4  Key issue #4: Satellite access support for MC servicesp. 13

4.4.1  Descriptionp. 13

To ensure reliable MC services with larger coverage area, MC systems can benefit from satellite access, especially when the connectivity provided by the terrestrial networks faces limitations, e.g., bad coverage at remote areas. Hence, MC service UEs can be able to connect to MC system via satellite access to ensure service continuity.
There are different satellite systems, based on altitude, roundtrip time and coverage such as; Low Earth Orbit (LEO), Medium Earth Orbit (MEO), and Geostationary Equatorial Orbit (GEO). Among these different systems, LEO offers low latency, and large area capacity density.
In this study, it is worth understanding the deployment scenarios to utilize satellite access for MC services, and understanding how the MC KPIs (e.g., latency requirement) can be met when MC service users are connecting to the MC system via satellite access.
Location reporting aspects for MC service clients is to be considered and understand whether location reports provided by MC service users over satellite access may or may not be different from MC service users over terrestrial access.
Up

4.4.2  Open issuesp. 13

There are several aspects that need to be considered and studied to support satellite access for MC services, including but not limited to:
  1. Identify the different deployment scenarios for MC services using satellite access to result in a better MC service user experience.

4.5  Key issue #5: Edge on board NGSO Satellitep. 13

4.5.1  Descriptionp. 13

NGSO satellites are satellites moving with respect to the earth surface and they can be deployed in MEO (8,000 km - 20,000 km ) or LEO (400 km - 2000 km) orbits. This will reduce the one way latency. To utilize these reduced latencies UPFs as well as gNBs can be deployed on the NGSO.

4.5.2  Open issuesp. 13

This key issue studies how to deploy EAS(s) and EES(s) on NGSO satellite and whether and how the corresponding discovery, service provisioning and service continuity are impacted.
  • How the EES(s) are placed on board the Satellite.
  • How the EAS(s) are placed on board the Satellite.
  • Whether and how the discovery and the service provisioning are impacted.
  • Whether and how the service continuity procedures are impacted while the UE is only connected with NTN.
  • Whether and how the EAS can be relocated while the UE can be connected with NTN/TN.
Up

4.6  Key issue #6: Support of UE-Satellite-UE communication for IMS services via Satellite accessp. 13

4.6.1  Descriptionp. 13

It has been described in the TS 22.261 that a 5G system with satellite access shall support UE-Satellite-UE communication regardless of whether the feeder link is available or not, and 5G system also be able to support different types of UE-Satellite-UE communication (e.g. voice, messaging, broadband, unicast, multicast, broadcast).
According to TR 23.700-29, the UE-satellite-UE communication refers to the communication between UEs under the coverage of one or more serving satellites without the user plane traffic going through the ground network.
The serving satellites may be the different types (e.g. LEO, MEO, and GEO) and the feeder link may be direct from the serving satellite to a ground gateway or through ISL (Inter-Satellite Link) to another satellite with a link to a ground gateway, etc.
Figure 4.6.1-1 is the example of scenarios for UEs-satellite-UEs communications for IMS services over LEO constellations without ISL.
Copy of original 3GPP image for 3GPP TS 23.700-01, Fig. 4.6.1-1: An example of UEs-SAT-UEs communication on LEO satellite without ISL
Up
In this study, it is worth understanding the deployment scenarios to utilize satellite access and the procedure and function impacts on the application enabler for the IMS services.

4.6.2  Open issuesp. 14

From the application enabler's perspective, the key issue will focus on how to support the IMS service via satellite access in the application enabled layer, it is proposed to study the following items:
  • Investigate different deployment options for the application enabler of IMS (i.e. eMMTEL App) to utilize satellite access.

4.7  Key issue #7: Usage of S&F events information for the application enablementp. 14

4.7.1  Descriptionp. 14

3GPP SA1 has specified the service requirements for 5G for satellite access in TS 22.261 as following which includes supporting Store and Forward (S&F) Satellite Operation. And 3GPP SA2 is studying the exposure of S&F events information to support these services requirements identified in SA1.
  • Subject to operator's policies, a 5G system with satellite access supporting S&F Satellite operation shall be able to allow the operator or a trusted 3rd party to apply, on a per UE and/or satellite basis, an S&F data retention period.
  • Subject to operator's policies, a 5G system with satellite access supporting S&F Satellite operation shall be able to allow the operator or a trusted 3rd party to apply, on a per UE and/or satellite basis, an S&F data storage quota.
  • A 5G system with satellite access shall be able to inform an authorised 3rd party whether S&F Satellite operation is applied for communication with a UE and to provide related information (e.g. estimated delivery time to the authorised UE).
SA2 is studying the following S&F events information:
  • Registration in S&F Mode
  • Feeder Link Available
  • Expected Delivery/Delay Time
Services and application enablers defined by SA6 should also consider to take advantage of the output from SA1 and SA2 related to utilizing the S&F events information. When a UE registers to the network in S&F mode and is available to send/receive data on specific occasions only (e.g. when satellites fly-over and later connect to ground station), AF can leverage S&F events information. For e.g. if the UE is registered in S&F mode, the AF may want to adjust the frequency, size of data, message acknowledgement handling, ack timers etc. Another e.g. is AF can schedule delivery based on Feeder-Link availability etc.
Hence, it is desirable to study impacts to application enablers, while supporting S&F Satellite operation and S&F events information is shared to the AF.
Up

4.7.2  Open issuesp. 15

To support utilization of S&F events information by application enablers, the following aspects need to be studied:
  • What are the S&F events information that can be utilized by the application enablers?
  • How to use the S&F events information to optimise the application enablement behaviour?
  • Whether and how the S&F Satellite operation information can be exposed to the 3rd party/VAL server.

4.8  Key issue #8: Impact of satellite access on KPIs for Mission Critical group communicationsp. 15

4.8.1  Descriptionp. 15

Satellite access may be valuable for Mission Critical communication, especially in remote areas and during disaster relief scenarios. Participants connected via satellite access may be crucial in Mission Critical group communications. Still, it should be considered that it is likely that Mission Critical group communication KPIs may be impacted for all participants if one participant is connected via Satellite access. KPIs outside the normal range can have a strong negative operational impact. Participants of MCX group communications may be confused by an unexpected drop in KPIs due to a participant being connected via Satellite access.
Hence, it is desirable to study the impact of satellite access to Mission Critical KPIs and how to mediate possible operational consequences.
Up

4.8.2  Open issuesp. 15

The following aspects need to be studied:
  • What is the actual impact of satellite access to the KPIs for Mission Critical communication?
  • Whether and how participants of group communications can be informed about reduced KPIs due to one or more participants being connected via satellite.

Up   Top   ToC