WO2021233980A1

WO2021233980A1 - Handling ue-provided cell id in large cell sizes

Info

Publication number: WO2021233980A1
Application number: PCT/EP2021/063256
Authority: WO
Inventors: Stefan Rommer; Paul Schliwa-Bertling; Helka-Liina MÄÄTTÄNEN
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2020-05-19
Filing date: 2021-05-19
Publication date: 2021-11-25

Abstract

Disclosed herein is a method performed by a radio access network, RAN, node 302 of a cellular communications system 302. The method comprises: obtaining 600 (Fig. 7, step 1) a cell identity, ID, of a particular wireless communication device 306; and providing 602 (Fig. 7, step 1), to a network function, NF, of a core network of the cellular communications system 300, the cell ID of the particular wireless communication device 306 and information that indicates whether the cell ID is provided by the particular wireless communication device 306 or network determined. Also, disclosed herein is a method performed by a network function, NF, of a core network 304 of a cellular communications system 302. The method comprises: receiving 602; 606; 610; 614 (Fig. 7, step 1 or step 3), from another network node, a cell identity, ID, of a particular wireless communication device 306 and information that indicates whether the cell ID is provided by the particular wireless communication device 306 or network determined.

Description

HANDLING UE- PROVIDED CELL ID IN LARGE CELL SIZES

BACKGROUND

[0001] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features, and advantages of the enclosed embodiments will be apparent from the following description. [0002] The Third Generation Partnership Project (3GPP) is currently performing a study on how satellite access can be included into the Fifth Generation (5G) System (5GS). This covers both radio and core network related work, e.g. how New Radio (NR) can be adjusted to work over satellite links, i.e. with base station onboard the satellite, or with a base station on the ground but with a “bent pipe” radio link via the satellite and back to earth. [0003] A few example configurations are shown in Figures 1 A through 1C.

[0004] One problem faced in the study is how to handle the large cell sizes of a satellite. A cell is built up by either a single satellite beam, or by multiple satellite beams. This means that the satellite cell will have at least the same size as a satellite beam. Typical beam coverage (footprint size) is shown in the table below.

Table 1 : Types of NTN platforms

[0005] This is much larger than the typical cell size of terrestrial networks, which may range from a few tens to a few thousands of meters.

[0006] A problem arises when such satellite access is connected to the core network and the usual applications and services are used, such as support for emergency calls, broadcasting of warning messages, location-based charging, etc. Many of these services make use of knowing the current Cell ID of the user. For example, when a User Equipment (UE) makes an emergency call, the call is routed to the closest emergency call center (PSAP) based on the reported Cell ID. Or when a public warning message is broadcasted, it is broadcast only in those cells that cover the affected area (e.g. a part of a city). If the cell sizes now are very big, it is difficult to use the Cell ID for these purposes. The cell coverage is just too large.

[0007] One solution to address this problem has been included in 3GPP Technical Report (TR) 23.737 (Solution #12 in TR 23.737, see, e.g., V16.0.0). It is based on a solution where the “physical” cell of a satellite beam is split into a number of smaller “virtual cells” or “geographical zones.” These “virtual cellsTgeographical zones” should have roughly the same size as regular terrestrial cells. The “virtual cellsTgeographical zones” are assigned separate Cell IDs, and they are grouped into Tracking Areas with different Tracking Area IDs.

Figure 2

[0008] See Figure 2 for an illustration of a subdivision into virtual cells (i.e., virtual cells defined by a rectangular array of grid points).

[0009] The solution is based on the following principles: • The satellite Radio Access Network (RAN) sends the virtual cell description (e.g. grid points) to the UE, together with a specific Cell ID, Tracking Area ID, etc. for each virtual cell.

• The UE uses some positioning technique (e.g. GPS or GNSS) to determine its position.

• The UE then compares its position to the virtual cell description and finds the closest virtual cell, and its associated Cell ID, Tracking Area ID, etc.

• The UE sends the Cell ID and Tracking Area ID to the RAN.

• The RAN provides the Cell ID and Tracking Area ID to the core network in the same way as for terrestrial cells. Therefore, in principle, the core network does not need to worry about the large satellite “physical” cell size as the core network will see the Cell ID of the virtual cell instead, and provide it to e.g. emergency call centers, Policy and Control Function (PCF), charging systems, and other functions/systems that make use of Cell ID today. Since the area associated to such (virtual) Cell ID is roughly the same size as a terrestrial cell, there is no impact to the core network or the services.

SUMMARY

[0010] There currently exist certain challenge(s). A problem with Solution #12 in TR 23.737 as described above is that the Cell ID is provided by the UE. This is different from current terrestrial networks (e.g., Long Term Evolution (LTE), NR, etc.) where Cell ID is determined by the RAN to be the cell serving the UE by using radio resources configured in that cell. Hence, when the Cell ID is determined by the RAN, it is information that can be trusted by the core network and service layers. However, if the Cell ID is UE- provided, the information cannot be trusted since a malicious UE can cheat and e.g. indicate that it is located in a different virtual cell. If the satellite coverage is very large, covering multiple countries, the UE can even cheat and indicate that it is located in a different country.

[0011] The RAN may position the UE to verify that the UE has provided the correct Cell ID. This is however a resource consuming operation for the RAN and will only be done when really needed. In many cases, the network would thus have to accept the UE provided cell ID. The problem is however that if the UE-provided Cell ID is sent to the core network in the same was as a “normal” Cell ID, the core network (and other systems) does not know whether it is UE-provided or determined by RAN. There is thus no way for core network or other systems to make a conscious decision on whether to use the Cell ID for charging, lawful intercept, etc., or disregard the Cell ID as unreliable information. [0012] Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. Embodiments of a solution are described herein for distinction between information generated in a trusted domain versus information generated in a non-trusted domain that can be relevant for consumer functions, e.g., as exemplified herein.

[0013] In one embodiment, a RAN (e.g., a RAN node such as, e.g., a base station such as, e.g., a gNB) will include an indication to a core network that indicates whether a Cell ID provided from the RAN to the core network for a particular UE is UE-provided or not. This allows the core network and other systems (e.g. Internet Protocol (IP) Multimedia System (IMS), emergency call centers, Lawful Interception (LI) systems, etc.) to know whether a Cell ID is reliable information or not.

[0014] There are different ways for how to pass this information from the RAN to the core network. Some example embodiments for how to pass this information (i.e., the indication of whether a Cell ID is UE- provided or not) from the RAN to the core network are:

• adding a new flag (e.g., in the UE Location Information (ULI)) to indicate that Cell ID is UE- provided,

• using a completely different Information Element (IE) for UE-provided Cell ID compared to today’s IE where Cell ID is included, or

• using a special range of Cell ID values to encode virtual cells. This range can be predefined (e.g., standardized) to allow interoperability across domains (e.g., RAN, CN, IMS, LI, etc.).

[0015] In one embodiment, an Access and Mobility Management Function (AMF) receives the Cell ID from the RAN as part of the UE Location Information (ULI). The AMF forwards the Cell ID to a Session Management Function (SMF) and one or more other Network Functions (NFs) in the different procedures, as described in 3GPP TS 23.502 (see, e.g., V16.4.0) and the protocol specifications. The SMF will forward the Cell ID to a PCF. The PCF forwards the Cell ID to an Application Function (AF) / Proxy Call Session Control Function (P-CSCF), etc. So, the solution proposed herein impacts several interfaces within the 5GC.

[0016] In one embodiment, NFs that receive the ULI (e.g., AMF, SMF, PCF, P-CSCF) process the ULI that the Cell ID is UE-provided and determine whether to use the information or not.

[0017] The solution described herein can be generalized to support types of location information other than Cell IDs, e.g. geo coordinates, geographical zone id, etc. In some cases, that information may be determined by the UE and sent to the network or determined by the network itself. In all those cases, it is important for the receiver of the information (e.g. CN, service layer) to know whether the information was UE-provided or network-determined.

[0018] There are, proposed herein, various embodiments which address one or more of the issues disclosed herein. [0019] Certain embodiments may provide one or more of the following technical advantage(s).

[0020] Embodiments of the solution described herein allow the core network and other systems (e.g. IMS, emergency call centers, LI systems, etc.) to know whether a Cell ID is reliable information or not.

BRIEF DESCRIPTION OF THE DRAWINGS

Figures 1A-1C illustrate examples of satellite-based RAN nodes;

Figure 2 illustrate an exemplifying split of the "physical cell” of a satellite beam into a number of smaller virtual cells, here defined by a rectangular array of grid points;

Figure 3 illustrates one example of a cellular communications system 300 in which embodiments of the present disclosure may be implemented

Figure 4 illustrates a wireless communication system represented as a 5GS network architecture, wherein interaction between any two NFs is represented by a point-to-point reference point/interface;

Figure 5 illustrates a wireless communication system represented as a 5GS network architecture, wherein interaction between any two NFs is represented by a service-based interface;

Figure 6 illustrates the operation of the system 300 in accordance with some embodiments of the present disclosure;

Figure 7 illustrates a UE-requested PDU Session Establishment for non-roaming and roaming with local breakout;

Figure 8 is a schematic block diagram of a network node 800 according to some embodiments of the present disclosure;

Figure 9 is a schematic block diagram that illustrates a virtualized embodiment of the network node 800 according to some embodiments of the present disclosure;

Figure 10 is a schematic block diagram of the network node 800 according to some other embodiments of the present disclosure;

Figure 11 is a schematic block diagram of a wireless communication device 1100 according to some embodiments of the present disclosure;

Figure 12 is a schematic block diagram of the wireless communication device 1100 according to some other embodiments of the present disclosure. DETAILED DESCRIPTION

[0021] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. Additional information may also be found in the document(s) provided in the Appendix.

[0022] Radio Node: As used herein, a “radio node” is either a radio access node or a wireless communication device.

[0023] Radio Access Node: As used herein, a “radio access node” or “radio network node” or “radio access network node” or “RAN node” is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station (e.g., a network node that implements a gNB Central Unit (gNB-CU) or a network node that implements a gNB Distributed Unit (gNB- DU)) or a network node that implements part of the functionality of some other type of radio access node. [0024] Core Network Node: As used herein, a “core network node” is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing a Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like. [0025] Communication Device: As used herein, a “communication device” is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection.

[0026] Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (loT) device. Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless connection.

[0027] Network Node: As used herein, a “network node” is any node that is either part of the RAN or the core network of a cellular communications network/system.

[0028] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

[0029] Note that, in the description herein, reference may be made to the term “cell”; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

Figure 3

[0030] Figure 3 illustrates one example of a cellular communications system 300 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 300 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) that includes, in this example, a satellite-based RAN node 302 and a core network 304. In the case of the 5GS, the core network 302 is a 5G Core (5GC). The satellite-based RAN node 302 is, for example, any one of the satellite-based RAN nodes illustrated in Figures 1 A through 1C. The satellite-based RAN node 302 may include one or more sub-components, which may each itself be a RAN node (e.g., a gNB-DU, a gNB-CU, a Radio Remote Unit (RRU, a.k.a. Remote Radio Head (RRH)), or the like). Figures 1A-1C

[0031] For example, in one embodiment (see, e.g., Figure 1 A), the satellite-based RAN node 302 includes a radio frequency remote unit (e.g., implemented as or as part of a satellite), a RRU (ground- based), and a gNB (ground-based). As another example (see, e.g., Figure 1B), the satellite-based RAN node 302 includes a satellite-based gNB Distributed Unit (gNB-DU), a RRU (ground-based), and a gNB Central Unit (gNB-CU) (ground based). As yet another example (see, e.g., Figure 1C), the satellite-based RAN node 302 includes a satellite-based gNB and a RRU (ground-based). Note that while the embodiments described herein focus on 5GS, the embodiments described herein are not limited to 5GS and, instead, can be used for any type of cellular communications system (e.g., Evolved Packet System (EPS), or the like). Further, while the discussion herein focuses on the satellite-based RAN node 302, the embodiments of the solution described herein are equally applicable to non-satellite-based RAN nodes (e.g., conventional base stations such as, e.g., conventional gNBs). As such, the satellite-based RAN node 302 is sometimes referred to more generally as a RAN node 302.

[0032] The satellite-based RAN node 302 provides radio access to a wireless communication device(s) 306. In the following description, the wireless communication device(s) 312 is(are) oftentimes a UE(s) and, as such, is(are) sometimes referred to herein as UE(s) 312.

Figure 4

[0033] Figure 4 illustrates a wireless communication system represented as a 5GS network architecture composed of a RAN and a core network including core Network Functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point/interface. Figure 4 can be viewed as one particular implementation of the system 300 of Figure 3 in which the core NFs of Figure 4 are part of the core network 304.

[0034] Seen from the access side the 5G network architecture shown in Figure 4 comprises a plurality of UEs 106 connected to either a RAN node 302 (which in the example of Figure 3 is the satellite-based RAN node 302) as well as an AMF 400. Seen from the core network side, the 5GC NFs shown in Figure 4 include a NSSF 402, an AUSF 404, a UDM 406, the AMF 400, a SMF 408, a PCF 410, and an Application Function (AF) 412.

[0035] Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between the UE 106 and AMF 400. The reference points for connecting between the AN 302 and AMF 400 and between the AN 302 and UPF 414 are defined as N2 and N3, respectively. There is a reference point, N11, between the AMF 400 and SMF 408, which implies that the SMF 408 is at least partly controlled by the AMF 400. N4 is used by the SMF 408 and UPF 414 so that the UPF 414 can be set using the control signal generated by the SMF 408, and the UPF 414 can report its state to the SMF 408. N9 is the reference point for the connection between different UPFs 414, and N14 is the reference point connecting between different AMFs 400, respectively. N15 and N7 are defined since the PCF 410 applies policy to the AMF 400 and SMF 408, respectively. N12 is required for the AMF 400 to perform authentication of the UE 106. N8 and N10 are defined because the subscription data of the UE 106 is required for the AMF 400 and SMF 408. [0036] The 5GC network aims at separating UP and CP. The UP carries user traffic while the CP carries signaling in the network. In Figure 4, the UPF 414 is in the UP and all other NFs, i.e., the AMF 400, SMF 408, PCF 410, AF 412, NSSF 402, AUSF 404, and UDM 406, are in the CP. Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.

[0037] The core 5G network architecture is composed of modularized functions. For example, the AMF 400 and SMF 408 are independent functions in the CP. Separated AMF 400 and SMF 408 allow independent evolution and scaling. Other CP functions like the PCF 410 and AUSF 404 can be separated as shown in Figure 4. Modularized function design enables the 5GC network to support various services flexibly.

[0038] Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF. In the CP, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity. The UP supports interactions such as forwarding operations between different UPFs. [0039] Figure 5 illustrates a 5G network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points/interfaces used in the 5G network architecture of Figure 4.

Figure 5

[0040] Flowever, the NFs described above with reference to Figure 4 correspond to the NFs shown in Figure 5. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In Figure 5 the service based interfaces are indicated by the letter “N” followed by the name of the NF, e.g. Namf for the service based interface of the AMF 400 and Nsmf for the service based interface of the SMF 408, etc. The NEF 500 and the NRF 502 in Figure 5 are not shown in Figure 4 discussed above. Flowever, it should be clarified that all NFs depicted in Figure 4 can interact with the NEF 500 and the NRF 502 of Figure 5 as necessary, though not explicitly indicated in Figure 4. [0041] Some properties of the NFs shown in Figures 4 and 5 may be described in the following manner. The AMF 400 provides UE-based authentication, authorization, mobility management, etc. A UE 106 even using multiple access technologies is basically connected to a single AMF 400 because the AMF 400 is independent of the access technologies. The SMF 408 is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF 414 for data transfer. If a UE 106 has multiple sessions, different SMFs 408 may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF 412 provides information on the packet flow to the PCF 410 responsible for policy control in order to support QoS. Based on the information, the PCF 410 determines policies about mobility and session management to make the AMF 400 and SMF 408 operate properly. The AUSF 404 supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM 406 stores subscription data of the UE 106. The Data Network (DN), not part of the 5GC network, provides Internet access or operator services and similar.

[0042] An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

[0043] Embodiments of a solution are described herein for distinction between information generated in a trusted domain versus information generated in a non-trusted domain that can be relevant for consumer functions, e.g., as exemplified herein. [0044] In one embodiment, that the RAN node 302 (e.g., the satellite-based RAN node 302 or some component of the satellite-based RAN node 302 (e.g., gNB, gNB-DU, or gNB-CU)) will include an indication to the core network 304 that indicates whether a Cell ID provided from the RAN node 302 to the core network 304 for a particular UE 306 is UE-provided or not. This allows the core network 304 and other systems (e.g. Internet Protocol (IP) Multimedia System (IMS), emergency call centers, Lawful Interception (LI) systems, etc.) to know whether a Cell ID is reliable information or not.

[0045] There are different ways for how to pass this information from the RAN node 302 to the core network 304. Some example embodiments for how to pass this information (i.e., the indication of whether a Cell ID is UE-provided or not) from the RAN node 302 to the core network 304 are:

[0046] In one embodiment, the AMF 400 receives the Cell ID and an indication of whether the Cell ID is UE-provided or not from the RAN node 302 as part of the UE Location Information (ULI). The AMF 400 forward the Cell ID and the indication of whether the Cell ID is UE-provided or not to the SMF 408 and one or more other NFs in the different procedures, e.g., as described in 3GPP TS 23.502 (see, e.g., V16.4.0) and the protocol specifications. The SMF 408 forwards the Cell ID and the indication of whether the Cell ID is UE-provided or not to the PCF 410. The PCF 400 forwards the Cell ID and the indication of whether the Cell ID is UE-provided or not to the AF 412, Proxy Call Session Control Function (P-CSCF), etc. So, the solution proposed herein impacts several interfaces within the core network 404.

[0047] In one embodiment, NFs that receive the Cell ID and the indication of whether the Cell ID is UE-provided or not (e.g., AMF 400, SMF 408, PCF 410, and/or P-CSCF) process this information to determine whether the Cell ID is UE-provided or not. The NF(s) may then decide whether or not to use the Cell ID based on whether the Cell ID is UE-provided or not.

[0048] The solution described herein can be generalized to support types of location information other than Cell IDs, e.g. geo coordinates, geographical zone id, etc. In some cases, that information may be determined by the UE 306 and sent to the RAN node 302 or determined by the RAN node 302 itself. In all those cases, it is important for the receiver of the information (e.g. core network NF, service layer) to know whether the information was UE-provided or network-determined.

Figure 6

[0049] Figure 6 illustrates the operation of the system 300 in accordance with some embodiments of the present disclosure. Note that optional steps are represented by dashed lines/boxes. As illustrated, the RAN node 302 obtains a cell ID of the UE 306 (step 600). In one particular embodiment, the cell ID is UE- provided and, as such, the RAN node 302 receives the cell ID from the UE 306 (step 600A). For example, in one embodiment, the RAN node 302 is a satellite-based RAN node 302 having a respective spotbeam that is divided into multiple virtual cells, as described above. In this case, the UE 306 determines the virtual cell in which the UE 306 is located (e.g., based on its position and known boundaries of the virtual cells), and the UE 306 provides the cell ID of the determined virtual cell to the RAN node 302.

[0050] The RAN node 302 provides the cell ID and information that indicates whether or not the cell ID is UE-provided (i.e., whether the cell ID is provided by the UE 306 or determined by the network (e.g., determined by the RAN node 302)) to the AMF 400 (step 602). As discussed above, if the cell ID is provided by the UE 306, the information indicates that the cell ID is UE-provided (i.e., that a source of the cell ID is the UE 306). In one embodiment, the cell ID and the information that indicates whether the cell ID is UE-provided or not are included in ULI. In one embodiment, the information that indicates whether the cell ID is UE-provided or not is a flag, e.g., included in the ULI along with the cell ID. In one embodiment, the cell ID and the information that indicates whether the cell ID is UE-provided or not are included in the same IE. In another embodiment, the cell ID and the information that indicates whether the cell ID is UE- provided or not are included in separate lEs. In another embodiment, the information that indicates whether the cell ID is UE-provided or not is implicit information provided by the cell ID. For example, in one embodiment, a set of cell IDs used for virtual cells (i.e., virtual cells defined within a spotbeam of a satellite- based RAN node) is predefined (e.g., by a standard) or preconfigured, and the cell ID indicates that the cell ID is UE-provided if the cell ID is one of the set of cell IDs used for virtual cells and otherwise indicates that the cell ID is network determined.

[0051] The AMF 400 may determine whether or not to use the cell ID (e.g., determine whether the cell ID is trusted or not) based on the information that indicates whether the cell ID is UE-provided or not (step 604). The AMF 400 provides the cell ID and the information that indicates whether the cell ID is UE- provided or not to the SCF 408 (step 606). The SCF 408 may determine whether or not to use the cell ID (e.g., determine whether the cell ID is trusted or not) based on the information that indicates whether the cell ID is UE-provided or not (step 608). The SCF 408 provides the cell ID and the information that indicates whether the cell ID is UE-provided or not to the PCF 410 (step 610). The PCF 410 may determine whether or not to use the cell ID (e.g., determine whether the cell ID is trusted or not) based on the information that indicates whether the cell ID is UE-provided or not (step 612). The PCF 410 provides the cell ID and the information that indicates whether the cell ID is UE-provided or not to the AF 412 or S-CSCF (step 614). The AF 412 or S-CSCF may determine whether or not to use the cell ID (e.g., determine whether the cell ID is trusted or not) based on the information that indicates whether the cell ID is UE- provided or not (step 616).

[0052] Now some example embodiments will be provided. These examples are shown for:

• TS 23.502, PDU Session Establishment, where the RAN node 302 sends ULI to the AMF 400, and the AMF 400 sends the ULI to the SMF 408.

• TS 38.413 (NGAP protocol specification) for an example encoding in the NGAP protocol between the RAN node 302 and the AMF 400.

However, other protocols and interfaces will also be impacted, as described above.

[0053] Example #1: PDU Session Establishment

[0054] The description of this example is provided as a modified version of Clause 4.3.2.2.1 of 3GPP TS 23.502. Changes are underlined.

***********START MODIFIED VERSION OF CLAUSE 4.3.2.2.1 OF TS 23.502***********

4.3.2.2.1 Non-roaming and Roaming with Local Breakout

Clause 4.3.2.2.1 specifies PDU Session establishment in the non-roaming and roaming with local breakout cases.

The procedure is used to:

- Establish a new PDU Session;

- Handover a PDN Connection in EPS to PDU Session in 5GS without N26 interface;

- Switching an existing PDU Session between non-3GPP access and 3 GPP access. The specific system behaviour in this case is further defined in clause 4.9.2; or

- Request a PDU Session for Emergency services.

In case of roaming, the AMF determines if a PDU Session is to be established in LBO or Home Routing. In the case of LBO, the procedure is as in the case of non-roaming with the difference that the AMF, the SMF, the UPF and the PCF are located in the visited network. PDU Sessions for Emergency services are never established in Home Routed mode. In the case of LBO, the NEF is not used. NOTE 1 : UE provides both the S-NSSAIs of the Home PLMN and Visited PLMN to the network as described in clause 5.15.5.3 of TS 23.501 [2]

[SEE FIGURE 7]

Figure 4.3.2.2.1-1: UE-requested PDU Session Establishment for non-roaming and roaming with local breakout

The procedure assumes that the UE has already registered on the AMF thus unless the UE is Emergency Registered the AMF has already retrieved the user subscription data from the UDM.

1. From UE to AMF: NAS Message (S-NSSAI(s), UE Requested DNN, PDU Session ID, Request type, Old PDU Session ID, N1 SM container (PDU Session Establishment Request, [Port Management Information Container])).

In order to establish a new PDU Session, the UE generates a new PDU Session ID.

The UE initiates the UE Requested PDU Session Establishment procedure by the transmission of a NAS message containing a PDU Session Establishment Request within the N1 SM container. The PDU Session Establishment Request includes a PDU session ID, Requested PDU Session Type, a Requested SSC mode, 5GSM Capability, PCO, SM PDU DN Request Container, [Number Of Packet Filters], [Header Compression Configuration], UE Integrity Protection Maximum Data Rate, and [Always-on PDU Session Requested].

The Request Type indicates "Initial request" if the PDU Session Establishment is a request to establish a new PDU Session and indicates "Existing PDU Session" if the request refers to an existing PDU Session switching between 3 GPP access and non-3GPP access or to a PDU Session handover from an existing PDN connection in EPC. If the request refers to an existing PDN connection in EPC, the S-NSSAI is set as described in TS 23.501 [2] clause 5.15.7.2

When Emergency service is required and an Emergency PDU Session is not already established, a UE shall initiate the UE Requested PDU Session Establishment procedure with a Request Type indicating "Emergency Request".

The Request Type indicates "Emergency Request" if the PDU Session Establishment is a request to establish a PDU Session for Emergency services. The Request Type indicates "Existing Emergency PDU Session" if the request refers to an existing PDU Session for Emergency services switching between 3GPP access and non-3GPP access or to a PDU Session handover from an existing PDN connection for Emergency services in EPC.

The 5GSM Core Network Capability is provided by the UE and handled by SMF as defined in TS 23.501 [2] clause 5.4.4b.

The Number Of Packet Filters indicates the number of supported packet filters for signalled QoS rules for the PDU Session that is being established. The number of packet filters indicated by the UE is valid for the lifetime of the PDU Session. For presence condition, see TS 24.501 [25]

The UE Integrity Protection Maximum Data Rate indicates the maximum data rate up to which the UE can support UP integrity protection. The UE shall provide the UE Integrity Protection Data Rate capability independently of the Access Type over which the UE sends the PDU Session Establishment Request.

If the use of header compression for Control Plane CIoT 5GS optimisation was negotiated successfully between the UE and the network in the previous registration procedure, the UE shall include the Header Compression Configuration, unless "Unstructured" or "Ethernet" PDU Session Type is indicated. The NAS message sent by the UE is encapsulated by the AN in a N2 message towards the AMF that should include User location information and Access Type Information. The AN also indicates if the User location information (Cell ID included in the ULI) is UE -provided.

The PDU Session Establishment Request message may contain SM PDU DN Request Container containing information for the PDU Session authorization by the external DN.

The UE includes the S-NSSAI from the Allowed NSSAI of the current access type. If the Mapping of Allowed NSSAI was provided to the UE, the UE shall provide both the S-NSSAI of the VPLMN from the Allowed NSSAI and the corresponding S-NSSAI of the HPLMN from the Mapping Of Allowed NSSAI.

If the procedure is triggered for SSC mode 3 operation, the UE shall also include the Old PDU Session ID which indicates the PDU Session ID of the on-going PDU Session to be released, in NAS message. The Old PDU Session ID is included only in this case.

The AMF receives from the AN the NAS SM message (built in step 1) together with User Location Information (e.g. Cell Id in case of the NG-RAN and possibly an indication that Cell ID is UE-provided).

The UE shall not trigger a PDU Session establishment for a PDU Session corresponding to a LADN when the UE is outside the area of availability of the LADN.

If the UE is establishing a PDU session for IMS, and the UE is configured to discover the P-CSCF address during connectivity establishment, the UE shall include an indicator that it requests a P-CSCF IP address(es) within the SM container.

The PS Data Off status is included in the PCO in the PDU Session Establishment Request message.

The UE capability to support Reliable Data Service is included in the PCO in the PDU Session Establishment Request message.

If the UE has indicated that it supports transfer of Port Management Information Containers as per UE 5 GSM Core Network Capability, then the UE shall include the MAC address of the DS-TT Ethernet port used for this PDU session. If the UE is aware of the UE -DS-TT Residence Time, then the UE shall additionally include the UE-DS-TT Residence Time.

If the UE requests to establish always-on PDU session, the UE includes an Always-on PDU Session Requested indication in the PDU Session Establishment Request message.

Port Management Information Container is received from DS-TT and includes port management capabilities, i.e. information indicating which standardized and deployment-specific port management information is supported by DS-TT as defined in TS 23.501 [2] clause 5.28.3. The AMF determines that the message corresponds to a request for a new PDU Session based on that Request Type indicates "initial request" and that the PDU Session ID is not used for any existing PDU Session(s) of the UE. If the NAS message does not contain an S-NSSAI, the AMF determines a default S-NSSAI of the HPLMN for the requested PDU Session either according to the UE subscription, if it contains only one default S-NSSAI, or based on operator policy and, in the case of LBO, an S-NSSAI of the Serving PLMN which matches the S-NSSAI of the HPLMN. When the NAS Message contains an S-NSSAI of the Serving PLMN but it does not contain a DNN, the AMF determines the DNN for the requested PDU Session by selecting the default DNN for this S-NSSAI if the default DNN is present in the UE's Subscription Information (or for the corresponding S-NSSAI of the HPLMN, in the case of LBO); otherwise the serving AMF selects a locally configured DNN for this S-NSSAI of the Serving PLMN. If the AMF cannot select an SMF (e.g. the UE requested DNN is not supported by the network, or the UE requested DNN is not in the Subscribed DNN List for the S-NSSAI (or its mapped value for the HPLMN in the case of LBO) and wildcard DNN is not included in the Subscribed DNN list), the AMF shall, based on operator policies received from PCF, either reject the NAS Message containing PDU Session Establishment Request from the UE with an appropriate cause or request PCF to replace the UE requested DNN by a selected DNN. If the DNN requested by the UE is present in the UE subscription information but indicated for replacement in the operator policies received from PCF, the AMF shall request the PCF to perform a DNN replacement to a selected DNN. AMF requests DNN replacement as as specified in clause 4.16.2.1.1. If the DNN requested by the UE is present in the UE subscription information but not supported by the network and not indicated for replacement in the operator policies received from PCF, the AMF shall reject the NAS Message containing PDU Session Establishment Request from the UE with an appropriate cause value.

The AMF selects an SMF as described in clause 6.3.2 of TS 23.501 [2] and clause 4.3.2.2.3. If the Request Type indicates "Initial request" or the request is due to handover from EPS or from non-3GPP access serving by a different AMF, the AMF stores an association of the S-NSSAI(s), the DNN, the PDU Session ID, the SMF ID as well as the Access Type of the PDU Session.

During registration procedures, the AMF determines the use of the Control Plane CIoT 5GS Optimisation or User Plane CIoT 5GS Optimisation based on UEs indications in the 5 G Preferred Network Behaviour, the serving operator policies and the network support of CIoT 5GS optimisations. The AMF selects an SMF that supports Control Plane CIoT 5GS optimisation or User Plane CIoT 5GS Optimisation as described in clause 6.3.2 of TS 23.501 [2]

If the Request Type is "initial request" and if the Old PDU Session ID indicating the existing PDU Session is also contained in the message, the AMF selects an SMF as described in clause 4.3.5.2 and stores an association of the new PDU Session ID, the S-NSSAI(s), the selected SMF ID as well as Access Type of the PDU Session.

If the Request Type indicates "Existing PDU Session", the AMF selects the SMF based on SMF-ID received from UDM. The case where the Request Type indicates "Existing PDU Session", and either the AMF does not recognize the PDU Session ID or the subscription context that the AMF received from UDM during the Registration or Subscription Profile Update Notification procedure does not contain an SMF ID corresponding to the PDU Session ID constitutes an error case. The AMF updates the Access Type stored for the PDU Session.

If the Request Type indicates "Existing PDU Session" referring to an existing PDU Session moved between 3GPP access and non-3GPP access, then if the Serving PLMN S-NSSAI of the PDU Session is present in the Allowed NSSAI of the target access type, the PDU Session Establishment procedure can be performed in the following cases:

- the SMF ID corresponding to the PDU Session ID and the AMF belong to the same PLMN;

- the SMF ID corresponding to the PDU Session ID belongs to the HPLMN;

Otherwise the AMF shall reject the PDU Session Establishment Request with an appropriate reject cause.

NOTE 2: The SMF ID includes the PLMN ID that the SMF belongs to.

The AMF shall reject a request coming from an Emergency Registered UE and the Request Type indicates neither "Emergency Request" nor "Existing Emergency PDU Session". When the Request Type indicates "Emergency Request", the AMF is not expecting any S-NSSAI and DNN value provided by the UE and uses locally configured values instead. The AMF stores the Access Type of the PDU Session.

If the Request Type indicates "Emergency Request" or "Existing Emergency PDU Session", the AMF selects the SMF as described in TS 23.501 [2], clause 5.16.4. From AMF to SMF: Either Nsmf PDUSession CreateSMContext Request (SUPI, selected DNN, UE requested DNN, S-NSSAI(s), PDU Session ID, AMF ID, Request Type, PCF ID, Priority Access, [Small Data Rate Control Status], N1 SM container (PDU Session Establishment Request), User location information, Access Type, RAT Type, PEI, GPSI, UE presence in LADN service area, Subscription For PDU Session Status Notification, DNN Selection Mode, Trace Requirements, Control Plane CIoT 5GS Optimisation indication, or Control Plane Only indicator) or Nsmf PDUSession UpdateSMContext Request (SUPI, DNN, S-NSSAI(s), SM Context ID, AMF ID, Request Type, N1 SM container (PDU Session Establishment Request), User location information, Access Type, RAT type, PEI). If the AMF does not have an association with an SMF for the PDU Session ID provided by the UE (e.g. when Request Type indicates "initial request"), the AMF invokes the Nsmf PDUSession CreateSMContext Request, but if the AMF already has an association with an SMF for the PDU Session ID provided by the UE (e.g. when Request Type indicates "existing PDU Session"), the AMF invokes the Nsmf PDUSession UpdateSMContext Request.

The AMF sends the S-NSSAI of the Serving PLMN from the Allowed NSSAI to the SMF. For roaming scenario in local breakout (LBO), the AMF also sends the corresponding S-NSSAI of the HPLMN from the Mapping Of Allowed NSSAI to the SMF.

The AMF ID is the UE's GUAM! which uniquely identifies the AMF serving the UE. The AMF forwards the PDU Session ID together with the N1 SM container containing the PDU Session Establishment Request received from the UE. The GPSI shall be included if available at AMF.

The AMF determines Access Type and RAT Type, see clause 4.2.2.2.I.

The AMF provides the PEI instead of the SUPI when the UE in limited service state has registered for Emergency services (i.e. Emergency Registered) without providing a SUPI. The PEI is defined in TS 23.501 [2] clause 5.9.3. In case the UE in limited service state has registered for Emergency services (i.e. Emergency Registered) with a SUPI but has not been authenticated the AMF indicates that the SUPI has not been authenticated. The SMF determines that the UE has not been authenticated when it does not receive a SUPI for the UE or when the AMF indicates that the SUPI has not been authenticated.

If the AMF determines that the selected DNN corresponds to an LADN then the AMF provides the "UE presence in LADN service area" that indicates if the UE is IN or OUT of the LADN service area.

If the Old PDU Session ID is included in step 1, and if the SMF is not to be reallocated, the AMF also includes Old PDU Session ID in the Nsmf PDUSession CreateSMContext Request.

DNN Selection Mode is determined by the AMF. It indicates whether an explicitly subscribed DNN has been provided by the UE in its PDU Session Establishment Request.

The ULI provided by the AMF to SMF may contain an indication that the Cell Id is UE -provided

The SMF may use DNN Selection Mode when deciding whether to accept or reject the UE request.

When the Establishment cause received as part of AN parameters during the Registration procedure or Service Request procedure is associated with priority services (e.g. MPS, MCS), the AMF includes a Message Priority header to indicate priority information. The SMF uses the Message Priority header to determine if the UE request is subject to exemption from NAS level congestion control. Other NFs relay the priority information by including the Message Priority header in service-based interfaces, as specified in TS 29.500 [17]

In the local breakout case, if the SMF (in the VPLMN) is not able to process some part of the N1 SM information that Home Routed Roaming is required, and the SMF responds to the AMF that it is not the right SMF to handle the N1 SM message by invoking Nsmf PDUSession CreateSMContext Response service operation. The SMF includes a proper N11 cause code triggering the AMF to proceed with home routed case. The procedure starts again at step 2 of clause 4.3.2.2.2.

The AMF may include a PCF ID in the Nsmf PDUSession CreateSMContext Request. This PCF ID identifies the H-PCF in the non-roaming case and the V-PCF in the local breakout roaming case.

The AMF includes Trace Requirements if Trace Requirements have been received in subscription data.

If the AMF decides to use the Control Plane CIoT 5GS Optimisation or User Plane CIoT 5GS Optimisation as specified in step 2 or to only use Control Plane CIoT 5GS Optimisation for the PDU session as described in clause 5.31.4 of TS 23.501 [2], the AMF sends the Control Plane CIoT 5GS Optimisation indication or Control Plane Only indicator to the SMF. If the AMF determines that the RAT type is NB-IoT and the UE has already 2 PDU Sessions with user plane resources activated, the AMF may either reject the PDU Session Establishment Request or continue with the PDU Session establishment and include the Control Plane CIoT 5GS Optimisation indication or Control Plane Only indicator to the SMF. The AMF includes the latest Small Data Rate Control Status if it has stored it for the PDU Session.

If the RAT type was included in the message, then the SMF stores the RAT type in SM Context.

If the UE supports CE mode B and and use of CE mode B is not restricted according to the Enhanced Coverage Restriction information in the UE context in the AMF, then the AMF shall include the extended NAS-SM timer indication. Based on the extended NAS-SM timer indication, the SMF shall use the extended NAS-SM timer setting for the UE as specified in TS 24.501 [25]

************END MODIFIED VERSION OF CLAUSE 4.3.2.2.1 OF TS 23.502************

[0055] Example #2: Encoding in the NGAP Protocol between RAN and AMF

[0056] The description of this example is provided as a modified version of Clause 9.3.1.16 and a new Clause 9.3.1.X of 3GPPTS 38.413. Changes are underlined.

**START MODIFIED VERSION OF CLAUSE 9.3.1.16 and New Clause 9.3.1.x OF TS 38.413*

9.3.1.16 User Location Information

This IE is used to provide location information of the UE.

9.3.1.x Cell ID Source

This IE indicates to the CN whether the Cell ID was determined by RAN or provided by the UE.

***END MODIFIED VERSION OF CLAUSE 9.3.1.16 and New Clause 9.3.1.x OF TS 38.413** Figure 8

[0057] Figure 8 is a schematic block diagram of a network node 800 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. In one embodiment, the network node 800 is a radio access node such as, for example, the RAN node 302 or a RAN node (e.g., a component of the satellite-based RAN node 302) that implements all or part of the functionality of the satellite-based RAN node 302 described herein. In another embodiment, the network node 800 is a network node that implements all or part of the functionality of a core NF (e.g., the AMF 400, the SMF 408, the PCF 410, the AF 112, or S-CSCF) as described herein. As illustrated, the network node 800 includes a control system 802 that includes one or more processors 804 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 806, and a network interface 808. The one or more processors 804 are also referred to herein as processing circuitry. In addition, if the network node 800 is a radio access node, the network node 800 may include one or more radio units 810 that each includes one or more transmitters 812 and one or more receivers 814 coupled to one or more antennas 816. The radio units 810 may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) 810 is external to the control system 802 and connected to the control system 802 via, e.g., a wired connection (e.g., an optical cable). Flowever, in some other embodiments, the radio unit(s) 810 and potentially the antenna(s) 816 are integrated together with the control system 802. The one or more processors 804 operate to provide one or more functions of the network node 800 as described herein (e.g., one or more functions of the RAN node 302 or a RAN node that implements all or part of the functionality of the RAN node 302 or one or more functions of a core NF (e.g., the AMF 400, the SMF 408, the PCF 410, the AF 112, or S-CSCF) as described herein). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 806 and executed by the one or more processors 804.

Figure 9

[0058] Figure 9 is a schematic block diagram that illustrates a virtualized embodiment of the network node 800 according to some embodiments of the present disclosure. As used herein, a “virtualized” network node is an implementation of the network node 800 in which at least a portion of the functionality of the network node 800 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the network node 800 includes one or more processing nodes 900 coupled to or included as part of a network(s) 902. Each processing node 900 includes one or more processors 904 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 906, and a network interface 908. Optionally, the network node 800 may include the control system 802 and/or the one or more radio units 810, as described above. If present, the control system 802 or the radio unit(s) are connected to the processing node(s) 900 via the network 902.

[0059] In this example, functions 910 of the network node 800 described herein (e.g., one or more functions of the RAN node 302 or a RAN node that implements all or part of the functionality of the RAN node 302 or one or more functions of a core NF (e.g., the AMF 400, the SMF 408, the PCF 410, the AF 112, or S-CSCF) as described herein) are implemented at the one or more processing nodes 900 or distributed across the one or more processing nodes 900 and the control system 802 and/or the radio unit(s) 810 in any desired manner. In some particular embodiments, some or all of the functions 910 of the network node 800 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 900. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 900 and the control system 802 is used in order to carry out at least some of the desired functions 910. Notably, in some embodiments, the control system 802 may not be included, in which case the radio unit(s) 810 communicate directly with the processing node(s) 900 via an appropriate network interface(s). [0060] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node 800 or a node (e.g., a processing node 900) implementing one or more of the functions 910 of the network node 800 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

Figure 10

[0061] Figure 10 is a schematic block diagram of the network node 800 according to some other embodiments of the present disclosure. The network node 800 includes one or more modules 1000, each of which is implemented in software. The module(s) 1000 provide the functionality of the network node 800 described herein (e.g., one or more functions of the RAN node 302 or a RAN node that implements all or part of the functionality of the RAN node 302 or one or more functions of a core NF (e.g., the AMF 400, the SMF 408, the PCF 410, the AF 112, or S-CSCF) as described herein). This discussion is equally applicable to the processing node 900 of Figure 9 where the modules 1000 may be implemented at one of the processing nodes 900 or distributed across multiple processing nodes 900 and/or distributed across the processing node(s) 900 and the control system 802.

Figure 11 [0062] Figure 11 is a schematic block diagram of a wireless communication device 1100 according to some embodiments of the present disclosure. As illustrated, the wireless communication device 1100 includes one or more processors 1102 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1104, and one or more transceivers 1106 each including one or more transmitters 1108 and one or more receivers 1110 coupled to one or more antennas 1112. The transceiver(s) 1106 includes radio-front end circuitry connected to the antenna(s) 1112 that is configured to condition signals communicated between the antenna(s) 1112 and the processor(s) 1102, as will be appreciated by on of ordinary skill in the art. The processors 1102 are also referred to herein as processing circuitry. The transceivers 1106 are also referred to herein as radio circuitry. In some embodiments, the functionality of the wireless communication device 1100 described above may be fully or partially implemented in software that is, e.g., stored in the memory 1104 and executed by the processor(s) 1102. Note that the wireless communication device 1100 may include additional components not illustrated in Figure 11 such as, e.g., one or more user interface components (e.g., an input/output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and/or the like and/or any other components for allowing input of information into the wireless communication device 1100 and/or allowing output of information from the wireless communication device 1100), a power supply (e.g., a battery and associated power circuitry), etc.

[0063] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the wireless communication device 1100 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

Figure 12

[0064] Figure 12 is a schematic block diagram of the wireless communication device 1100 according to some other embodiments of the present disclosure. The wireless communication device 1100 includes one or more modules 1200, each of which is implemented in software. The module(s) 1200 provide the functionality of the wireless communication device 1100 described herein.

SOME EMBODIMENTS

[0065] Some embodiments that have been described above may be summarized in the following manner:

1. A method performed by a radio access network, RAN, node (302) of a cellular communications system (302), the method comprising: obtaining (600; Fig. 7, step 1) a cell identity, ID, of a particular wireless communication device (306); and providing (602; Fig. 7, step 1), to a network function, NF, of a core network of the cellular communications system (300), the cell ID of the particular wireless communication device (306) and information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.

2. The method of embodiment 1 wherein obtaining (600; Fig. 7, step 1) the cell ID of the particular wireless communication device (306) comprises receiving (600A; Fig. 7, step 1) the cell ID of the particular wireless communication device (306).

3. The method of embodiment 2 wherein the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined is information that indicates that the cell ID is provided by the particular wireless communication device (306).

4. The method of any one of embodiments 1 to 3 wherein providing (602; Fig. 7, step 1) the cell ID of the particular wireless communication device (306) and information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined comprises providing (Fig. 7, step 1) User Location Information, ULI, to the NF, the ULI comprising the cell ID and the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined. 5. The method of any of embodiments 1 to 4 wherein the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined is a flag that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.

6. The method of any of embodiments 1 to 4 wherein the cell ID and the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined are comprised in a same information element.

7. The method of any of embodiments 1 to 4 wherein the cell ID and the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined are comprised in separate information elements.

8. The method of any of embodiments 1 to 7 wherein: the RAN node (302) is a satellite-based RAN node (302) having a respective spotbeam; and a respective cell identified by the cell ID is a virtual cell within the spotbeam.

9. The method of any of embodiments 1 to 4 wherein: the RAN node (302) is a satellite-based RAN node (302) having a respective spotbeam; a respective cell identified by the cell ID is a virtual cell within the spotbeam; and the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined is implicit information that is implied by the cell ID being one of a predefined or preconfigured set of cell IDs used for virtual cells.

10. The method of any one of embodiments 1 to 9 wherein the NF is an Access and Mobility Management Function, AMF, (400).

11. A radio access network, RAN, node (302) for a cellular communications system (302), the RAN node (302) adapted to: obtain (600; Fig. 7, step 1) a cell identity, ID, of a particular wireless communication device (306); and provide (602; Fig. 7, step 1), to a network function, NF, of a core network of the cellular communications system (300), the cell ID of the particular wireless communication device (306) and information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.

12. The RAN node (302) of embodiment 11 wherein the RAN node (302) is further adapted to perform the method of any one of embodiments 2 to 10.

13. A radio access network, RAN, node (302) for a cellular communications system (302), the RAN node (302) comprising: processing circuitry (804; 904) configured to cause the RAN node (302) to: obtain (600; Fig. 7, step 1) a cell identity, ID, of a particular wireless communication device (306); and provide (602; Fig. 7, step 1), to a network function, NF, of a core network of the cellular communications system (300), the cell ID of the particular wireless communication device (306) and information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.

14. A method performed by a network function, NF, of a core network (304) of a cellular communications system (302), the method comprising: receiving (602; 606; 610; 614; Fig. 7, step 1 or step 3), from another network node, a cell identity,

ID, of a particular wireless communication device (306) and information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.

15. The method of embodiment 14 wherein the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined is information that indicates that the cell ID is provided by the particular wireless communication device (306). 16. The method of embodiment 15 further comprising determining (604; 608; 612; 616) not to use the cell ID based on the information that indicates that the cell ID is provided by the particular wireless communication device (306).

17. The method of embodiment 14 or 15 further comprising determining (604; 608; 612; 616) whether to use the cell ID based on the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.

18. The method of any one of embodiments 14 to 17 wherein receiving (602; 606; 610; 614; Fig. 7, step 1) the cell ID of the particular wireless communication device (306) and information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined comprises receiving (602; 606; 610; 614; Fig. 7, step 1) User Location Information, ULI, to the NF, the ULI comprising the cell ID and the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.

19. The method of any of embodiments 14 to 17 wherein the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined is a flag that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.

20. The method of any of embodiments 14 to 17 wherein the cell ID and the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined are comprised in a same information element.

21. The method of any of embodiments 14 to 17 wherein the cell ID and the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined are comprised in separate information elements.

22. The method of any of embodiments 14 to 21 wherein a respective cell identified by the cell ID is a virtual cell within a spotbeam of a satellite-based Radio Access Network, RAN, node (302). 23. The method of any of embodiments 14 to 17 wherein: a respective cell identified by the cell ID is a virtual cell within a spotbeam of a satellite-based Radio Access Network, RAN, node (302); and the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined is implicit information that is implied by the cell ID being one of a predefined or preconfigured set of cell IDs used for virtual cells.

24. The method of any one of embodiments 14 to 23 wherein the NF is an Access and Mobility Management Function, AMF, (400), and the another network node is a satellite-based Radio Access Network, RAN, node (302).

25. The method of any one of embodiments 14 to 23 wherein the NF is a Session Management Function, SMF, (408).

26. The method of embodiment 25 wherein the another network node an Access and Mobility Management Function, AMF, (400).

27. The method of any one of embodiments 14 to 23 wherein the NF is a Policy Control Function, PCF, (410).

28. The method of embodiment 27 wherein the another network node a Session Management Function, SMF, (408).

29. The method of embodiment 27 wherein the another network node an Access and Mobility Management Function, AMF, (400).

30. A network node (800) that implements a network function, NF, for a core network (304) of a cellular communications system (302), the network node (800) adapted to: receive (602; 606; 610; 614; Fig. 7, step 1 or step 3), from another network node, a cell identity, ID, of a particular wireless communication device (306) and information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined. 31. The network node of embodiment 30 wherein the network node is further adapted to perform the method of any one of embodiments 15 to 29. 32. A network node (800) that implements a network function, NF, for a core network (304) of a cellular communications system (302), the network node (800) comprising processing circuitry (804; 904) configured to cause the network node (800) to: receive (602; 606; 610; 614; Fig. 7, step 1 or step 3), from another network node, a cell identity, ID, of a particular wireless communication device (306) and information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.

[0066] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure. [0067] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.). Abbreviations

At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).

• 3GPP Third Generation Partnership Project

• 5G Fifth Generation

• 5GC Fifth Generation Core

• 5GS Fifth Generation System

• AF Application Function

• AMF Access and Mobility Management Function

• AUSF Authentication Server Function

• DN Data Network

• gNB New Radio Base Station

• IP Internet Protocol

• LTE Long Term Evolution

• MTC Machine Type Communication

• NEF Network Exposure Function

• NF Network Function

• NR New Radio

• NRF Network Function Repository Function

• NSSF Network Slice Selection Function

• PCF Policy Control Function

• RAN Radio Access Network

• ROM Read Only Memory

• SCEF Service Capability Exposure Function

• SMF Session Management Function

• UDM Unified Data Management

• UE User Equipment

• UPF User Plane Function APPENDIX

3GPP TSG SA WG2 Meeting #139E S2-200XXXX

Elbonia, June 1 - 12, 2020 (Revision of S2-20xxxxx)

6.12.2.2 Emergency Calls

It is anticipated that existing "network provided UE location" functionality can be reused provided that the Cell ID sent in N2 signalling procedures is associated with a sufficiently small geographic area to allow configuration data within the core network to correctly select a PSAP. Unless the NG-RAN determines the UE position, the Core Network should be made aware that the Cell ID is UE-provided location information.

Once RRC Security has been established, other 3GPP (and/or Over The Top and/or SMS-based) positioning techniques and signalling can be used to determine the UE's position more accurately.

In addition, in case of satellite cells (whether associated with virtual cells or geographical zones), a UE would include the current satellite serving cell ID in a SIP INVITE request sent to an IMS in the serving PLMN. The IMS can use the satellite serving cell ID to route the emergency services call to a local PSAP and as an initial approximate UE location. A PLMN operator can arrange for virtual cell areas to be small enough to be normally contained within the serving area of one PSAP - thereby defining the routing.

6.12.2.3 Lawful interception by the UE's visited country

Provided that the NG-RAN/Earth Station can guarantee that the UE is always using the core network associated with the country where the UE is located, then existing LI functionality should be able to be reused. This requires that the network can verify that the UE has selected a satellite cell / zone in the country where the UE is located, e.g. by UE positioning.

As a basic approach, as intra-country, intra-Earth-Station mobility would not normally be reported to the AMF, and the Earth Station's coverage may represent a very large geographic area, it can be anticipated that extra location reporting to the core network is required. Two potential solutions are: a) The AMF uses "RAT-Type = satellite" to trigger location reporting of all cell changes (for all UEs) to the AMF; b) The Earth Station is configured to automatically send location reports for all cell changes (for all UEs) to the core network.

In the case of satellite cells (whether associated with virtual cells or geographical zones), a 5GCN can include satellite cells (whether associated with virtual cells or geographical zones), ID as part of the LI data collected for a UE which will enable an LI client to treat data collected for 5G satellite access the same as data collected for NR or LTE access. For cases where the Cell ID is not verified by the NG-RAN by UE positioning, the NG-RAN needs to inform the Core Network that the Cell ID provided via N2 is UE-provided. Triggers can also be set up for LI based on UE change of virtual serving cell ID or entry into or exit from an area of interest composed of a number of satellite cells (whether associated with virtual cells or geographical zones). For example, the NGAP Location Reporting Control procedure in TS 23.502 [3] can be used between a serving AMF and serving sNB to collect LI related location data for a UE.

6.12.2.4 Public Warning System

The NG-RAN functionality in the Earth Station is expected to need extension to operate with different geographically distinct PWS messages coming from different CN nodes. For WEA, a 5GCN can assign WEA messages that are received from a Government or other authority to one or more satellite cells (whether associated with virtual cells or geographical zones) in the same way as WEA messages are assigned to real cells for NR and LTE access. The WEA messages can then be broadcast in a SIB or SSIB in association with the assigned cells. Three options for broadcast would be possible:

- Option A: A SIB or SSIB is broadcast by a satellite for each cell in each TA within the current coverage area of the satellite. This cell associated SIB contains one or more WEA messages that have been assigned to the cell;

- Option B: A single SIB or SSIB broadcasts all WEA messages for all TAs within the current coverage area of the satellite. Each WEA message includes the specific cell IDs for which it is applicable;

- Option C: All WEA messages are broadcast one time only in a common SIB (or SSIB) with a reference ID for each WEA message. For each cell, there is a separate broadcast (e.g. SSIB) containing the WEA reference IDs applicable to that cell.

Option A is analogous to current WEA support for real cells but is inefficient. Option B is more efficient but may increase UE impacts. Option C is in between.

6.12.2.5 Charging / Customer Notifications

Incorporation of Cell ID and RAT Type on the CDRs and in signalling messages used for on-line charging may be sufficient for customer charging. For cases where the Cell ID is not verified by the NG-RAN using UE positioning, the Core Network must be made aware that the Cell ID is UE-provided location information and may not be reliable.

The use of distinct TA Codes for terrestrial and satellite-based coverage should, if needed, enable existing APIs to be used to generate appropriate SMS message to inform customers.

6.12.3 Impacts on existing nodes and functionality

In addition to the impacts highlighted above, for both approaches the following impacts are needed:

- UE:

- Satellite, cell, TA and PLMN selection for 5G satellite access based on current UE location;

- UE shall have the capability to locate itself.

NOTE: For the solution associated with geographical zones, the UE shall have the capability to store the definition of geographical zones associated with PLMNs.

- sNB:

- Handover of NGSO satellites between sNBs;

- Handover of a UE between satellites;

- Control of UL/DL satellite transmission for both ground stations and UEs;

- Dynamic assignment of TAs to NGSO satellites; - Position determination of UEs for trusted location service for some services.

- Ability to inform 5GC whether NGAP IEs where Cell ID is included (ULI) contains UE -provided or network provided information

- AMF:

- No new impacts at a NAS level for mobility management.

- 5GC general (AMF, SMF, PCF, charging system etc):

- Handling of Cell ID as a UE-provided location information.

Editor’s note:

NOTE: For the solution associated with geographical zones, the AMF shall have the capability to provide the geographical zones associated with the UE.

6.12.4 Solution evaluation

This Candidate Solution is proposed for 5G satellite access with large or moving radio coverage.

This Candidate Solution introduces the definition and usage of Satellite cells and the support needed from UEs and sNBs. Satellite Cells are defined as Virtual Cells, or standard cells in association with the use of geographical zones that are stored with UEs. In both cases the main assumption is that the UE has access to its position.

In addition, sNBs need to contain mobility management functions related to the management of satellites, particularly NGSO satellites, and the support of mobility management for UEs. While sNBs may be added to NG-RAN, procedures in TS 23.502 [3] (and TS 38.300 [9]) will need to differ from an NG-RAN and UE perspective.

The solution has the following properties:

- Mobility Management procedures are not impacted at a NAS level;

- Support for regulatory services (emergency calls, LI and WEA) is aligned with that for NR and E-UTRA connected to 5GCN from the perspective of a UE

- Cell ID provided from Satellite RAN to the 5GC is selected by the UE and thus needs to be treated as UE- provided location information, unless it can be verified or determined by NG-RAN. This has impacts on how the 5GC treats the Cell ID, how regulatory services (e.g. LI) are provided. Additional location parameter(s) are needed to achieve NW-provided UE location information;

- In order to apply Mobility Restrictions (Forbidden Area, Service Area Restrictions) to Satellite Cells/TAs, the network needs to be able to verify that the Ccll/TA selected by the UE is correct, e.g. by positioning the UE.

- Impacts to the UE and NG-RAN are restricted to managing new types of handover for NGSO satellites, mapping satellite coverage to Satellite cells and TAs and cell, TA and PLMN selection for UEs.

The solution supports and resolves key issues #1, #2 and #10.

For Key Issue #1, the solution supports 5G satellite access and mobility management with large satellite coverage areas as described above. Answers to points 1-10 in clause 5.1.1 are as follows:

1. Whether existing Connection Management mechanisms can be reused for a UE accessing 5GC via satellite 3GPP access? Answer: Yes as described above.

2. How is UE reachability (paging) handled within the large satellite coverage area?

Answer: paging is handled as for a normal terrestrial TA as described above.

3. What is the relation between satellite coverage areas and the 5G system Tracking/Registration Area?

Answer: a satellite coverage area can include all or part of new Satellite TAs or existing terrestrial TAs.

4. Whether a UE can access 5GC via satellite access and terrestrial access simultaneously? And how?

Answer: not explicitly addressed but the treatment of 5G satellite access as an extension to 3GPP NG-RAN access would allow simultaneous 5G satellite access and WLAN access. Simultaneous 5G satellite access and terrestrial NR or LTE access also seems possible - e.g. if 5G satellite access is assigned a new RAT (or RATs).

5. How does a UE select between satellite and terrestrial access within a PLMN?

Answer: not explicitly addressed, but could be similar to selection between terrestrial NR and LTE.

6. How is idle mode mobility between satellite and terrestrial access performed?

Answer: partially addressed - the UE camps on an accessible 5G satellite serving a current TA and can move to camping on a terrestrial gNB supporting the same TA. The reverse type of transfer is also supported.

7. How is connected mode mobility between satellite and terrestrial access performed?

Answer: partially addressed - a serving sNB controls handover between satellites and from an sNB to a gNB. A gNB could support handover to an sNB or to a satellite accessible from the gNB if enhanced with sNB capability.

8. Which country specific regulatory requirements affect the architecture design, and how are they enforced?

Answer: Country specific regulatory requirements can be supported in the same way as for terrestrial NR access. Verification (e.g. of a current UE location) might need to be an additional network function. As indicated in the geographical cell description, this could be performed through the sNB of the NG-RAN providing a trusted location function of UEs.

9. Whether any changes are needed for charging in roaming situations?

Answer: not addressed and can be evaluated separately.

For Key Issue #2, the solution supports 5G satellite access and mobility management with moving satellite coverage areas as described above. Answers to the points in clause 5.2.1 are as follows:

- Whether existing Connection Management mechanisms can be reused for a UE accessing 5GC via satellite 3GPP access?

Answer: yes, as described.

- What are the functional impacts on the 5 G CN when considering a satellite access with moving coverage areas and on-board gNBs?

Answer: on-board satellite gNBs are not needed and were not evaluated. Functional impacts to the 5G CN with separate sNBs can be zero or very low at a NAS level for mobility management.

- What are the impacts on the definition and on the management of Tracking Areas and Registration Areas as well as on mobility management when considering a satellite access with mobile coverage areas and on-board gNBs? Answer: existing TAs can be extended to include new Satellite cells. Alternatively, new Satellite TAs can be defined composed of Satellite cells. Management of these by the 5G CN can be the same as for existing terrestrial TAs.

- What are the requirements on the satellite access with mobile coverage areas and on-board gNBs to limit the impact on the 5 G CN and on the UE?

Answer: on-board satellite gNBs are not needed and were not evaluated. The solution limits 5G CN and UE impacts for mobility management. However, new UE impacts are needed to manage Satellite cell selection and reselection.

- How is UE reachability (paging) handled in case of moving satellite access coverage areas and on-board gNBs?

Answer: The solution supports UE reachability via paging as described above. Paging can be supported with zero (or very low) new impact to the 5 G CN.

- What are the impacts to idle mode mobility with moving satellite coverage areas and on-board gNBs?

Answer: The solution supports UE idle mode mobility as described above - which does require some new UE impacts.

- What are the impacts to connected mode mobility with moving satellite coverage areas and on-board gNBs? Answer: The solution supports UE connected mode mobility as described above - and with impacts to an sNB.

- Whether a UE can access 5GC via satellite access and terrestrial access simultaneously? And how?

Answer: Not explicitly addressed but the treatment of 5G satellite access as an extension to 3 GPP NG-RAN access would allow simultaneous 5G satellite access and WLAN access. Simultaneous 5G satellite access and terrestrial NR or LTE access also seems possible - e.g. if 5G satellite access is assigned a new RAT (or RATs).

The solution addresses Key Issue #10 by supporting regulatory services in the same way as for terrestrial NR access. Answers to the points in clause 5.10.1 are as follows: a) When required, how to ensure that the UE is using a core network of the country in which the UE is physically located?

Answer: the solution requires and enables UE access to a PLMN in the same country as the UE. This can be enforced via UE location from an sNB or PLMN on initial access, reregistration or when a regulatory service is invoked. Moreover, the cells in the different countries can use different Tracking Area Identifiers (e.g. different TA Codes and/or different PLMN IDs). b) How to select a core network when the UE is in an aeronautical or maritime location?

Answer: The solution supports access from international maritime areas. Aeronautic access was not considered but should be possible in a similar manner to terrestrial access. c) If the satellite system is using the same MCC+MNC in multiple countries, how to enable per-country, UE specific prohibition of satellite access?

Answer: the solution can provide country specific information to UEs in association with Satellite cells or TAs. Countries which prohibit satellite access could have no Satellite cells assigned to them. A UE which determines not being located in any Satellite cell would then not perform 5G satellite access. d) How to route an emergency call to the correct PSAP?

Answer: This is enabled via the serving Satellite cell as described above. e) How to handle Lawful Interception? Answer: supported as described above. f) How to address Public Warning System?

Answer: supported as described above. g) How to handle charging and tariff notifications?

Answer: not evaluated but would be possible based on serving Satellite cells and/or Satellite TAs.

Claims

CLAIMS What is claimed is:

2. The method of claim 1 wherein obtaining (600; Fig. 7, step 1) the cell ID of the particular wireless communication device (306) comprises receiving (600A; Fig. 7, step 1) the cell ID of the particular wireless communication device (306).

3. The method of claim 2 wherein the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined is information that indicates that the cell ID is provided by the particular wireless communication device (306).

4. The method of any one of claim 1 to 3 wherein providing (602; Fig. 7, step 1) the cell ID of the particular wireless communication device (306) and information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined comprises providing (Fig. 7, step 1) User Location Information, ULI, to the NF, the ULI comprising the cell ID and the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.

5. The method of any of claim 1 to 4 wherein the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined is a flag that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.

6. The method of any of claim 1 to 4 wherein the cell ID and the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined are comprised in a same information element.

7. The method of any of claim 1 to 4 wherein the cell ID and the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined are comprised in separate information elements.

8. The method of any of claim 1 to 7 wherein: the RAN node (302) is a satellite-based RAN node (302) having a respective spotbeam; and a respective cell identified by the cell ID is a virtual cell within the spotbeam.

9. The method of any of claim 1 to 4 wherein: the RAN node (302) is a satellite-based RAN node (302) having a respective spotbeam; a respective cell identified by the cell ID is a virtual cell within the spotbeam; and the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined is implicit information that is implied by the cell ID being one of a predefined or preconfigured set of cell IDs used for virtual cells.

10. The method of any one of claim 1 to 9 wherein the NF is an Access and Mobility Management Function, AMF, (400).

12. The RAN node (302) of claim 11 wherein the RAN node (302) is further adapted to perform the method of any one of claim 2 to 10.

14. A method performed by a network function, NF, of a core network (304) of a cellular communications system (302), the method comprising: receiving (602; 606; 610; 614; Fig. 7, step 1 or step 3), from another network node, a cell identity, ID, of a particular wireless communication device (306) and information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.

15. The method of claim 14 wherein the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined is information that indicates that the cell ID is provided by the particular wireless communication device (306).

16. The method of claim 15 further comprising determining (604; 608; 612; 616) not to use the cell ID based on the information that indicates that the cell ID is provided by the particular wireless communication device (306).

17. The method of claim 14 or 15 further comprising determining (604; 608; 612; 616) whether to use the cell ID based on the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.

18. The method of any one of claim 14 to 17 wherein receiving (602; 606; 610; 614; Fig. 7, step 1) the cell ID of the particular wireless communication device (306) and information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined comprises receiving (602; 606; 610; 614; Fig. 7, step 1) User Location Information, ULI, to the NF, the ULI comprising the cell ID and the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.

19. The method of any of claim 14 to 17 wherein the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined is a flag that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.

20. The method of any of claim 14 to 17 wherein the cell ID and the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined are comprised in a same information element.

21. The method of any of claim 14 to 17 wherein the cell ID and the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined are comprised in separate information elements.

22. The method of any of claim 14 to 21 wherein a respective cell identified by the cell ID is a virtual cell within a spotbeam of a satellite-based Radio Access Network, RAN, node (302).

23. The method of any of claim 14 to 17 wherein: a respective cell identified by the cell ID is a virtual cell within a spotbeam of a satellite-based Radio Access Network, RAN, node (302); and the information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined is implicit information that is implied by the cell ID being one of a predefined or preconfigured set of cell IDs used for virtual cells.

24. The method of any one of claim 14 to 23 wherein the NF is an Access and Mobility Management Function, AMF, (400), and the another network node is a satellite-based Radio Access Network, RAN, node (302).

25. The method of any one of claim 14 to 23 wherein the NF is a Session Management Function, SMF, (408).

26. The method of claim 25 wherein the another network node an Access and Mobility Management Function, AMF, (400).

27. The method of any one of claim 14 to 23 wherein the NF is a Policy Control Function, PCF, (410).

28. The method of claim 27 wherein the another network node a Session Management Function, SMF, (408).

29. The method of claim 27 wherein the another network node an Access and Mobility Management Function, AMF, (400).

30. A network node (800) that implements a network function, NF, for a core network (304) of a cellular communications system (302), the network node (800) adapted to: receive (602; 606; 610; 614; Fig. 7, step 1 or step 3), from another network node, a cell identity, ID, of a particular wireless communication device (306) and information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.

31. The network node of claim 30 wherein the network node is further adapted to perform the method of any one of claim 15 to 29.

32. A network node (800) that implements a network function, NF, for a core network (304) of a cellular communications system (302), the network node (800) comprising processing circuitry (804; 904) configured to cause the network node (800) to: receive (602; 606; 610; 614; Fig. 7, step 1 or step 3), from another network node, a cell identity, ID, of a particular wireless communication device (306) and information that indicates whether the cell ID is provided by the particular wireless communication device (306) or network determined.