Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TR 23.700-59  Word version:  19.0.0

Top   Top   None   None   Next
1…   5…

 

1  Scopep. 8

The present document is to investigate and identify potential architecture and system level enhancements to support additional scenarios and requirements for UAV (Uncrewed Aerial Vehicle) and UAM (Urban Air Mobility) including:
  • Enhancement of NEF services to support service exposure and interactions between MNOs and UTM functions for i.e. pre-mission flight planning, in-mission flight monitoring, C2 communication reliability, interfacing with UTM (e.g. supporting the scenario of multiple USS serving the geographical areas corresponding to UAV flight path).
  • Support of network-assisted/ground-based mechanism for DAA (Detect And Avoid).
  • Support of no-transmit zones for UAVs.
Up

2  Referencesp. 8

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TS 23.256: "Support of Uncrewed Aerial Systems (UAS) connectivity, identification and tracking; Stage 2".
[3]
ECC Decision (22)07 (cept.org) https://docdb.cept.org/download/4240: "Harmonised technical conditions for the usage of aerial UE for communications based on LTE and 5G NR in the bands 703-733 MHz, 832-862 MHz, 880-915 MHz, 1710- 1785 MHz, 1920-1980 MHz, 2500-2570 MHz and 2570- 2620 MHz harmonised for MFCN".
[4]
TS 23.502: "Procedures for the 5G System; Stage 2".
[5]
TS 23.501: "System Architecture for the 5G System; Stage 2".
[6]
TS 23.288: "Architecture enhancements for 5G System (5GS) to support network data analytics services".
[7]
TS 23.273: "5G System (5GS) Location Services (LCS); Stage 2".
[8]
TS 23.287: "Architecture enhancements for 5G System (5GS) to support Vehicle-to-Everything (V2X) services".
[9]
TS 38.300: "NR; NR and NG-RAN Overall description; Stage-2".
[10]
TS 24.501: "Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3".
Up

3  Definitions of terms and abbreviationsp. 9

3.1  Termsp. 9

For the purposes of the present document, the terms given in TR 21.905 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.
No-transmit zones:
Geographical area where aerial UE are not allowed to operate in a certain frequency band. The purpose and requirements of NTZ is described in ECC Decision (22)07 [3].
Up

3.2  Abbreviationsp. 9

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
DAA
Detect and Avoid
LDS
Localized DAA Server
NTZ
No-Transmit Zone
NWDAA
Network-Based/Assisted DAA
RTA
Restricted Transmission Area

4  Architectural Assumptions and Requirementsp. 9

4.1  Architectural Assumptionsp. 9

The following architectural assumptions apply:
  • For solutions to enable network-assisted/ground-based mechanism for DAA (Detect And Avoid),
    • co-existence with and leveraging, to the extent possible, Direct DAA solutions specified in TS 23.256 shall be considered.
    • sensing related information is out of scope of this study.
  • Regarding C2 communication reliability aspects in KI#1, only C2 over the Uu interface is considered in this study, and UAV using multiple-PLMN connectivity to support C2 communication reliability will not be considered in this release.
The following assumptions apply to the support of NTZ:
  • NTZ may be defined according to regional/national requirements;
  • an NTZ may map to one or more cells or a fraction of a cell, or overlap different cells in a mobile operator network.
  • Replanning of existing tracking areas and cells based on the presence of NTZs is not assumed.
Up

4.2  Architectural Requirementsp. 9

  • The existing procedures specified in TS 23.256 should be reused as much as possible for solutions.
  • Service exposure mechanisms defined in TS 23.256 should be reused as much as possible.
The following architectural requirements apply to support NTZ:
  • No transmissions in the restricted frequency bands are allowed from an aerial UE located in the NTZ, regardless of the service type, according to local regulations. Aerial UEs supporting NTZ are configured with NTZ information.
  • Reception of downlink data from the network by the aerial UE located in the NTZ is allowed given the regulatory requirements are not violated.
Up

Up   Top   ToC