GB2605499A - Improvements in and relating to localisation in telecommunication networks - Google Patents

Abstract

Performing localisation of an external User Equipment, UE 3, in a Non-Public Network, NPN 1, wherein the NPN, utilises an at least partially coextensive Public Land Mobile Network, PLMN 2, with which the UE is registered, to perform the localisation. The NPN may be an Industrial Internet of Things network, IIoT, operating closed subscriber groups, CSG, deployed in factories, warehouses, etc, wherein a visiting UE is not registered or able to register with the NPN via 3GPP access, yet localisation of external people/devices is required. A Gateway Mobile Location Centre, GMLC 11, of the NPN initiates the localisation by means of a request towards a GMLC 12 of the PLMN, wherein if the GMLC of the PLMN approves the request, the PLMN performs the localisation. The UE registers with the NPN via non-3GPP access while retaining PLMN access, wherein Location Privacy Indication, LPI, is provided by the UE and directed to a Unified Data Management, UDM, function of the NPN. The GMLC of the NPN obtains privacy consent from the UDM together with related UE context information and forwards this to a GMLC of the PLMN. The NPN may be situated entirely within a coverage area of the PLMN.

Description

Intellectual Property Office Application No G132201510.1 RTM Date:13 July 2022 The following terms are registered trade marks and should be read as such wherever they occur in this document: 3GPP, WiFi Intellectual Property Office is an operating name of the Patent Office www.gov.uk/ipo Improvements in and relating to localisation in Telecommunication Networks The present invention relates to localisation of a device in a telecommunication network.

Localisation is a process by which a network, which may be serving a particular device is able to determine to a suitable degree of accuracy where the device is within the coverage area of the network. Embodiments of the invention relate, in particular, to issues arising when a mobile device or User Equipment, UE, enters the coverage area of a non-public (or private) network, since this poses issues with the localisation process.

Private or non-public networks (NPN) are often established in industrial Internet of Things, lloT, settings, covering factories, warehouses, depots and other industrial areas. These private networks operate tightly controlled closed subscriber groups, CSG, for safeguarding the security of sensitive data. However, there will sometimes be external visitors, contractors and sensor devices fitted to external vehicles, like lorries and forklifts, regularly entering such lloT network premises. These will be outside the CSG and cannot be localised using the private network. Yet, to ensure health and safety and security of the factory assets, the localisation of these external people/devices will often be vital.

The problem associated with such scenarios are not properly addressed in the prior art. In terms of providing localisation services from a second network to a UE registered with a first network, only a roaming solution -with Visitor Gateway Mobile Location Centre (V-GMLC) and Home Gateway Mobile Location Centre (H-GMLC) -is currently supported and is not generally found useful.

Embodiments of the present invention aim to address shortcomings in the prior and to provide a means by which a UE entering a NPN may be localised as required.

According to the present invention there is provided an apparatus and method as set forth in the appended claims. Other features of the invention will be apparent from the dependent claims, and the description which follows.

According to a first aspect of the present invention, there is provided a method of performing localisation of a User Equipment, UE, in a Non-Public Network, NPN, wherein the NPN, utilises an at least partially coextensive Public Land Mobile Network, PLMN, with which the UE is registered, to perform the localisation.

In an embodiment, the UE is not registered or able to register with the NPN.

In an embodiment, the NPN determines that localisation via the PLMN is more efficient in terms of energy and/or resource considerations.

In an embodiment, a Gateway Mobile Location Centre, GMLC, of the NPN initiates the localisation by means of a request towards a GMLC of the PLMN.

In an embodiment, if the GMLC of the PLMN approves the request, the PLMN performs the localisation.

In an embodiment, the NPN is an Industrial Internet of Things network.

In an embodiment, the UE registers with the NPN via non-3GPP access while retaining PLMN 15 access.

In an embodiment, Location Privacy Indication, LPI, is provided by the UE and directed to a Unified Data Management, UDM, function of the NPN.

In an embodiment, an Application Function, AF, of the NPN or an external client makes a Location Deferred Request, LDR, to a Gateway Mobile Location Centre, GMLC, of the NPN for either an area-triggered or periodic location request.

In an embodiment, the GMLC of the NPN obtains privacy consent from the UDM together with related UE context information and forwards this to a GMLC of the PLMN.

In an embodiment, the GMLC of the PLMN makes a positioning request to an Access and Mobility Management Function, AMF, of the PLMN and the AMF allocates a Location Management Function, LMF, to carry out the LDR positioning.

In an embodiment, the NPN determines if the UE is present in a coverage area of the NPN and if it is so determined the LMF of the PLMN updates the AMF of the PLMN with the location information which is then sent to the GMLC of the PLMN.

In an embodiment, the GMLC of the PLMN passes the location information to the GMLC of the NPN which then notifies the Application Function, AF, of the NPN or the external client with the location information.

In an embodiment, the NPN is situated entirely within a coverage area of the PLMN.

According to a second aspect pf the present invention, there is provided an Apparatus arranged to perform the method of the first aspect Embodiments of the invention provide a solution whereby an NPN can request the services of the public PLMN network (which is at least partially coextensive with the private lloT network) to effectively acquire the location information of such external entities. This cooperation between the private and public networks is an importance feature of the present invention.

Embodiments relate to lloT network based solutions but may be applicable in many other scenarios where a private network with a CSG has to localise external entities that enter the private network premises.

Embodiments of the invention provide call flows and service messages to support lloT based positioning in a 3GPP architecture. A distinction is made, in general, between public PLMN wide area cellular networks and private small cell networks (which are suited to 11oT). Furthermore, improvements in relation to UE registration are provided.

Embodiments of the invention provide solutions in relation to the issue of localizing external UEs and Devices within a private network area, which are shadowed from the closed subscriber group (CSG) of the private network. These UEs can belong to visitors, contractors coming to the site or embedded devices in lorries, trucks, forklifts, all of which typically have public PLMN connectivity. By enabling the GMLC of the private lloT network to identify the correct GMLC (of a public PLMN) for the said UE or device to communicate this localisation request, these shadowed UEs/loT devices can be effectively localized. This helps to ensure health and safety rules are followed and also protects the asset security within the private lloT network premises.

Embodiments of the invention provide details of architectural updates (in terms of registration in a new network and service message modifications in the call flow) to enable a private lloT network to localize shadowed UEs/Devices that do not fall within its CSG, but are still accessing the premises. Embodiments are provided for registering and obtaining localisation privacy indication (LPI) from these devices through standardized procedures and using the public PLMN network to carry out the actual localisation. Prior art LDR (Location Deferred Request) procedures are modified so that the consent through privacy settings of such UEs/devices is obtained only once. Also, the INudm_SDM_Get and Nudm_UECM_Get service messages between the GMLC and Unified Data Management (UDM) are updated to reflect that the GMLC of the private lloT network can request the services from the correct serving GMLC of the respective shadowed UE or loT device.

Although a few preferred embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes and modifications might be made without departing from the scope of the invention, as defined in the appended claims.

For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example only, to the accompanying diagrammatic drawings in which: Figure 1 shows a representation of a NPN situated within the coverage area of a PLMN according to an embodiment of the invention; Figure 2 shows a representation of standardised architecture option for trusted non-3GPP access registration in roaming according to an embodiment of the invention; Figure 3 shows a UE-initiated privacy setting procedure according to an embodiment of the invention Figure 4 shows a call flow, according to an embodiment of the invention, for the area triggered MT-LR for localising a PLMN UE within an lloT network; and Figure 5 shows a flow chart for the execution of LDR localisation according to an embodiment of the invention Industry loT (1IoT) networks are increasingly utilised as highly secure, private or Non-public Networks (NPN) with closed subscriber groups (CSG) which allow only authorized UEs and loT devices to access their services. These lloT networks have strict requirements on the accuracy and latency in positioning UEs and loT devices. However, there will be UEs and loT devices which enter such I loT premises, but will be out of the CSG. These UEs can belong to visitors, contractors or support staff and the loT devices can be embedded in lorries, trucks, forklifts which frequent the lloT premises. Due to health and safety and security reasons, these UEs and loT devices generally need to be accurately located within the lloT private network premises, although they are 'shadowed' from the lloT network i.e. they are not permitted to directly connect to the NPN.

Typically, the lloT network area is embedded within a wider 5G PLMN coverage and the lloT network has some VViFi coverage. Such WiFi connections can be used to register the UEs, with their consent, to be localized within the lloT network premises and the PLMN can carry out the actual Radio Access Network, RAN, positioning steps.

Figure 1 shows a representation of the coverage area 1 of an lloT network which sits within the coverage area 2 of a larger PLMN. The PLMN network has a network core 21, in which is located GMLC1 22. The lloT network has its own core 11, in which is located GMLC2 12. A UE 3, registered with the PLMN, enters the coverage area 1 of the lloT.

Embodiments of the invention provide a framework for the private lloT network being deployed as a Stand-alone Non-Pubic Network (S-NPN), within the wider coverage area of the public PLMN. The private S-NPN and public PLMN have their separate access and core network components and can communicate only through standard network interfaces (typically through a firewall). Section 5.30.2.7 of TS 23.501 specifies how a S-NPN can request services from a PLMN using a standard interface. Interactions between the I loT network and the wider PLMN will occur accordingly.

The lloT network has an external client or an internal network function to handle localisation for all the UEs and Devices within the premises of this Industry network. Use is made of the MT-LR (Mobile Terminated Location Request) procedure for periodic, event triggered and UE available localisation call flow specified in Figure 6.3.1-1 of TS 23.273 as a basis for embodiments of the invention.

Embodiments of the invention provide adaptation of the non-3GPP based registration procedures and modifications in initial service message flow to enable the GMLC2 11 of lloT network to identify the correct PLMN for localisation of respective UEs/devices, 3, shadowed from the lloT network 1. After this registration and PLMN identification, GMLC2 11 can communicate with this PLMN's GMLC1 21 and can use the standardized call flows (as in TS 23.273) to execute the localisation service requests.

In order to execute the localisation of the PLMN UEs/devices 3 by service requests from Locations Services (LCS) client/Application Function (AF) 4 attached to the 11oT network 1, these UEs/devices 3 should be registered in the I loT network. Additionally, as specified in TS 23.273, any UE subjected to a commercial localisation request should have given explicit privacy consent for this. The UE privacy consent needs to be registered in the User Data Repository (UDR) and accessed by the Unified Data Management (UDM) of the lloT network 1 and for this the UE/device 3 registration in the lloT 1 network is essential. This is so that unscrupulous parties are not able to perform localisation on a device which has not given its explicit consent for this to happen.

Embodiments of the invention use a non-3GPP access technology, such as WiFi, to register the UE/device 3 in the lloT network 1. As this is provided in the secure lloT network, the UE/device 3 can treat this as a trusted non-3GPP access mode, but embodiments also work with un-trusted non-3GPP access. As per section 4.2.2.2.2 Registration procedures in TS 23.502, the UE 3 can initiate a registration procedure under the following conditions, which match relate well to the scenario herein described: "when the UE needs to update its capabilities or protocol parameters that are negotiated in Registration procedure with or without changing to a new Tracking Area (TA)".

The UE/device 3 can be prompted to register with the 11oT network 1 without changing to a new tracking area, as it would continue to be served by the PLMN 2. In addition to enabling UE/device localisation, this registration can provide some other services to the UE 3 through WiFi access, such as notifying the safety procedures and emergency exit routes.

Along with this UE/device registration process, the privacy consent for localisation can be obtained from the user. This can be done by filling an on-line form from the device, with trusted WiFi connectivity, for example. This procedure is set out in more detail below.

The UE registration process via non-3GPP access, while maintaining the connectivity to the home PLMN, is new and provides some advantages as set out below. This can be best described by reference to an existing registration architecture in TS 23.501.

The registration process as of TS 23.501, Figure 4.2.8.2.2-4, reproduced here as Figure 2, depicts the LBO roaming architecture with trusted non-3GPP access using a different PLMN than the 3GPP access. Embodiments of the invention provide that this architecture is modified to accommodate the non-roaming scenario set out. Here the UE or device 3 is connected to the home PLMN and registered with the different NPN ( the lloT network) using trusted non3GPP access. This registration process can be carried out with untrusted non-3GPP access as well.

Figure 2 shows the UE 3 and various components in the H-PLMN and the V-PLMN.

Embodiments of the invention modify the configuration shown in Figure 2 such that the VPLMN1 (as labelled in Figure 2) becomes the home PLMN or PLMN1, which is the PLMN the UE or device is connected to. The VPLMN2 or HPLMN (as labelled in Figure 2) is the NPN (1IoT network), which is shadowed from the UE or device because it is a CSG. The trusted non-3GPP access (eg: WiFi) is the access means to register these UEs/devices with this lloT network and it also gives the UEs connection to the Access and Mobility Management Function, AMF, of the lloT network. Thus (as in the TS 23.501 architecture solution) the UE/device is concurrently connected to two AMFs from the two networks. Because the lloT network is a secure closed network, the VViFi (or other radio access), can be categorized as trusted non-3GPP access. A similar solution is provided with un-trusted non-3GPP access, where a relevant diagram is provided in Figure 4.2.8.2.2-2 of TS 23.501 (not shown herein).

In this case, registration via non-3GPP access in the lloT network, embodiments provide that the UE/device includes its SUPI (Subscriber Permanent Identifier). With this information, the UDM of lloT network can work out that the UE is subscribed to a certain PLMN.

A compulsory feature for any commercial localisation service is that explicit UE privacy consent should be obtained to execute that service. In the present scenario, the UDM2 of the lloT network shall have recorded this privacy consent (or Location Privacy Indication, LPI, as this is termed in TS 23.273) before the service request is initiated by the LOS client 4 or the AF/NF of the lloT network.

This LPI can be obtained at the time of the UE registration, via the trusted non-3GPP access. The registration process for the UE can contain a mandatory clause for the UE (user) to give consent for its location to be obtained within the lloT network premises by this network. The UE giving consent to this clause can initiate a UE Location Privacy Setting procedure as indicated by Figure 6.12.1-1 of TS 23.273. The AMF2 co-ordinates this procedure. However the radio access will happen through the trusted non-3GPP access (as for the registration process) and hence the above referenced figure will be updated as shown in Figure 3. Again, this process can also happen through un-trusted non 3GPP access.

The procedure can start with the lloT Network Function subscribing to receive updates from the UDM on user privacy indication updates. This NF can be: (a) GMLC2 11, the gateway Mobile Location Centre of the lloT network. In this case, the GMLC2 will be updated with the privacy consent within this privacy setting procedure. Step S12 of the Location Deferred Request, LDR, procedure in Figure 4 (see later for details) will not be needed in this case.

(b) NEF2, the network exposure function of lloT network. The NEF2 can then in turn update the external LOS client or the application function in-charge of handling localisation processes in the lloT network. The full set of steps of the LDR procedure in Figure 4 is applicable in this case.

For the present scenario, the trusted non-3GPP access interworking procedure provides the access to the lloT network AMF (or AMF2), and this enables steps Si 52 and 53 of the call

B

flow in Figure 3 to be executed. The AMF will update the UDM about the LPI for this UE. If a Network Function (eg: GMLC) is subscribed to receive updates from the UDM, this NF will be notified of this LPI update of the UE, and the NF can optionally take steps to unsubscribe from further updates from this UE in a case where the LDR localisation request is cancelled, for

example.

The actual UE/device localisation in this scenario is triggered by the area event of the UE/device 3 entering the lloT network 1 premises. It can happen in the first instance (after the UE/device registration and privacy consent) and at any subsequent point when the UE/device re-visits the lloT site. In the current specifications of TS 23.273, section 5.4.6, the privacy consent from the UE for the LDR service should be obtained both at the point of initiating the LDR request and at the point of making the actual localisation. The relevant excerpt states: "5.4.6 LOS service authorization for a Deferred UE Location Support of UE LOS privacy for a deferred UE location is the same as that described in clause 5.4.5 for an immediate UE location with the differences and qualifications described in this clause.

An (H)GMLC or NEF shall subscribe to notification of a change in the UE LOS privacy profile from the UDM at the start of a deferred 5GC-MT-LR procedure and shall verify UE privacy both at the start of the deferred 5GC-MT-LR procedure and for each location result returned to an LOS client or AF based on the most recent UE LCS privacy profile received from the UDM." In the case of localisation within lloT networks, embodiments of the invention provide that this second privacy verification before each of the location results is omitted. Many of the localisation applications in lloT need results with low latency. A second privacy verification can be time consuming and also the user can deny the permission at a second verification point. While a second verification is justifiable if the user is in a public area or his own private space, the lloT network may need to localise UEs at all times due to health and safety reasons. Also since these industry premises are secure areas and visitors are agreeing to entry conditions at registration, this can include a clause to say 'agree to localisation now and at any future occasion when present within the industry premises' or similar. This privacy consent can be recorded in the UDR and accessed via UDM when the LDR location request is made. Thus a modification for TS 23.273, section 5.4.6, shown above may read: "In case of a deferred location request is made by a network function or an external client connected to an Industry loT network, a single privacy verification at the start of the deferred 5G0-MT-LR procedure is sufficient to execute the localisation at any time in future, when the localisation conditions are met." The call flow for a localisation procedure according to an embodiment of the invention follows similar steps to an area-triggered (deferred) MT-LR service. The call flow shown in Fig. 6.3.1-1 of TS 23.273 is used as a baseline. In this modified call flow (shown in Figure 4 below), the same (or similar) network entities are used and the message sequence is similar to that shown in Fig. 6.3.1-1 of TS 23.273. The main differences in terms of the functionality of the entities are that the H-GMLC in Fig. 6.3.1-1 is termed as GMLC2 11, referring to the lloT network 1. The V-GMLC in Fig. 6.3.1-1 is termed as GMLC1 22, this has PLMN UE connectivity throughout and can be requested by GMLC2 11 to carry out the localisation procedure on behalf of GMLC2 11. It is assumed that the service agreements between the PLMN 2 and lloT 1 networks are in place, in order to conduct such localisation services.

It is also assumes that the UE registration and localisation privacy indication (LPI) procedures have been conducted as discussed above. These steps in the call flow are shown as steps SlOa and S1013, as some of the options executed in these steps have a bearing on the call flow. Presented is the option of an application function (AF) 45 handling localisation related processes in the lloT network. This AF 45 communicates with the GMLC2 11 through the network exposure function (NEF2) 44. Equally, an external LCS client can handle localisation processes and this client can directly communicate with GMLC2. This option is not shown in Figure 4, but the skilled person will readily understand how this may be implemented.

As noted above, the pre-requisites for the execution of the call flow of Figure 4 is that the UE 3 is registered (step SlOa) in the lloT network (through non-3GPP access) while keeping the PLMN registration and the LPI is obtained from the UE (step SlOb). This LPI can be notified to the GMLC2 11 and/or NEF2 44. In any case the LPI information is kept in the UDM2 43.

Another option is to store the LPI (with UE registration information) in the UDR (not shown) and this can be retrieved by the UDM2 43 when a service request is made.

In a first option, the UE subscription and the LPI can be notified to the AF 45 by the NEF2 44 in step Slla. Then an event exposure subscription request from the AF 45 to the NEF2 44 can be made, with regards to deferred localisation of a given subscriber in step 811 b. The NEF2 44 then forwards this as a location request to the GMLC2 11 of the lloT network in step Silo. Step 812 and subsequent steps are then followed in the call flow for this option.

In a second option, the GMLC2 11 can obtain the LPI information from UDM2 43 in the UE initiated privacy setting procedure (as shown in Figure 3) and the steps 311 a, 311 b and 311 c can be skipped. The GMLC2 11 can also skip step S12 in this call flow and move onto step S13. If, however, the GMLC2 11 does not have this LPI, it would move onto step S12 to obtain the LPI from the UDM2 43. Thus, step 312 is an optional step. The remaining steps are followed in the same manner as in the first option.

An embodiment of the invention makes changes to the configuration of this service message, as indicated below.

a) 1Nudm_SDM_Get message: an embodiment makes changes compared to the original message.

The GMLC2 11 forwards this message to the UDM2 43, with the SUPI of the UE/Device 3 and the LDR type localisation request indicator as input parameters. The UDM2 43 will have an entry for this UE/Device 3 (within this scenario context) as an external party to the CSG and the LPI. The UDM2 43 will return (as outputs) the LPI for this UE 3 (default message). As new additions to the outputs, the UDM2 43 may include that privacy consent is only needed once for this particular service and all the UE access types (VViFi, PLMN, ...) that the UE is capable of This service output message can also include that the UE is not in the CSG.

With the LPI information available within GMLC2 11 (through LPI notification in Figure 3) or provided through the optional step 312, the GMLC2 11 can now move onto acquire the context information for this UE 3. This is done in step S13 service message. The changes to this original message are detailed below: b) 'Nudm_UECM_Get message: an embodiment makes changes compared to the original message.

Once the GMLC2 11 has the privacy consent for localisation from the UDM2 43 and new outputs from the UDM2 43 in the above Nudm_SDM_Get message (set out above), the GMLC2 11 can work out that the localisation has to be handled by an external access network. Based on the Quality of Service (QoS) level needed, the GMLC2 11 can decide that PLMN access based localisation will be needed. The UE 3 is also capable of WiFi access in the lloT network 1, but GMLC2 11 can compare the QoS levels of localisation and can decide to go for the PLMN option. The GMLC2 11 will input the UE ID, NF Type, Access Type (as PLMN) in this 'Nudm_UECM_Get message. These messages are already defined in TS23.502.

However, this embodiment treats lloT and PLMN as two separate access types and indicates PLMN receiving inputs from lloT network (or S-NPN). The PLMN and lloT access types can be mutually exclusive for some UEs and devices in 5G-NR. With this input, the UDM2 43 will recognize that the PLMN network 2 has to be used for this localisation service and will return the related context information for this UE 3. This will include returning the GMLC address (or more accurately the GMLC1 of PLMN) in the output message. There are similar indications in TS 23.273, section 6.1.2, for the roaming scenario, where the UDM returns the VGMLC address for the roaming UE. With the UE's SUPI, the UDM2 43 can determine the correct PLMN and can provide the correct GMLC address related to this PLMN. All the UEs/devices entering the lloT network premises can have different PLMNs as their subscribed networks. By GMLC2 11 requesting PLMN access type and with the SUPI, the UDM2 43 can determine the correct PLMN.

With this information, the GMLC2 11 can forward the "ProvideLocation_request" to the correct GMLC1 22. The remainder of the call flow (as in Figure 2) does not need to change from IS 23.273. The GMLC1 22 will execute this LDR with the help of PLMN network's AMF 41 and Location Management Function, LMF, 42, acquire the localisation event results and notify the GMLC2 11. GMLC2 11 will, in turn, notify the NEF2 44 and onwards to AF 45 of the localisation event. The AF 45 can select if it needs a one-off notification, or needs periodic updates of the UE location, in its original service request. The resulting notifications at the end of the call flow will match the request type.

Figure 5 shows a flow chart including the steps included in a localisation process according to an embodiment of the invention.

At S40 a visitor UE 3 registers at the lloT or NPN using non-3GPP (e.g. WiFi access, hile keeping PLMN access. This registration information is directed to the UDM2 32 of the NPN.

At 341 LPI is provided by the UE, possibly with explicit intervention by the user. The LPI is directed to the UDM2 32 and optionally notified to the GMLC2 11 of the NPN and/or the NEF2 44.

At S42, the lloT AF (or external client) 4 makes an LDR for area-triggered or periodic location request to GMLC2 11 of the NPN.

At 343, GMLC2 11 communicates with UDM2 32 to optionally obtain privacy consent and the related UE context for the PLMN/UE device 3. GMLC2 11 forwards the positioning request to GMLC1 22.

At 344, GMLC1 22 makes a positioning request to AMF1 41 of the PLMN network. AMF1 41 allocates an LMF 42 in the PLMN to carry out the LRD request.

At 545, the NPN checks to see if the UE 3 is detected within its coverage area. This check is repeated until such time as the UE 3 is detected.

At S46, once detected, the LMF 42 updates the AMF1 41 with the location event notification and the AMF1 41 responds to GMLC1 22 with the event notification.

At 347, GMLC1 22 pushes the event information to GMLC2 11 which then notifies the LOS service response to the lloT AF (or external client) 4 which made the request in the first place.

By means of an embodiment of the invention, a UE within the coverage area of a NPN can be localised by means of a PLMN which operates in the proximity of (or overlaps with) the NPN. 10 At least some of the example embodiments described herein may be constructed, partially or wholly, using dedicated special-purpose hardware. Terms such as 'component, 'module' or 'unit used herein may include, but are not limited to, a hardware device, such as circuitry in the form of discrete or integrated components, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks or provides the associated functionality. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to execute on one or more processors. These functional elements may in some embodiments include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Although the example embodiments have been described with reference to the components, modules and units discussed herein, such functional elements may be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it will be appreciated that described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be combined with features of any other embodiment, as appropriate, except where such combinations are mutually exclusive. Throughout this specification, the term "comprising" or "comprises" means including the component(s) specified but not to the exclusion of the presence of others.

Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.

Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims (15)

1. CLAIMS1. A method of performing localisation of a User Equipment, UE, in a Non-Public Network, NPN, wherein the NPN, utilises an at least partially coextensive Public Land Mobile Network, PLMN, with which the UE is registered, to perform the localisation.
2. 2 The method of claim 1 wherein the UE is not registered or able to register with the NPN.
3. 3. The method of claim 1 wherein the NPN determines that localisation via the PLMN is more efficient in terms of energy and/or resource considerations.
4. 4. The method of any preceding claim wherein a Gateway Mobile Location Centre, GMLC, of the NPN initiates the localisation by means of a request towards a GMLC of the PLMN.
5. 5. The method of claim 4 wherein if the GMLC of the PLMN approves the request, the PLMN performs the localisation.
6. 6. The method of any preceding claim wherein the NPN is an Industrial Internet of Things network.
7. 7. The method of any preceding claim wherein the UE registers with the NPN via non- 3GPP access while retaining PLMN access.
8. 8. The method of claim 7 wherein Location Privacy Indication, LPI, is provided by the UE and directed to a Unified Data Management, UDM, function of the NPN.
9. 9. The method of claim 8 wherein an Application Function, AF, of the NPN or an external client makes a Location Deferred Request, LDR, to a Gateway Mobile Location Centre, GMLC, of the NPN for either an area-triggered or periodic location request.
10. 10. The method of claim 9 wherein the GMLC of the NPN obtains privacy consent from the UDM together with related UE context information and forwards this to a GMLC of the PLMN.
11. 11. The method of claim 10 wherein the GMLC of the PLMN makes a positioning request to an Access and Mobility Management Function, AMF, of the PLMN and the AMF allocates a Location Management Function, LMF, to carry out the LDR positioning.
12. 12. The method of claim 11 wherein the NPN determines if the UE is present in a coverage area of the NPN and if it is so determined the LMF of the PLMN updates the AMF of the PLMN with the location information which is then sent to the GMLC of the PLMN.
13. 13. The method of claim 12 wherein the GMLC of the PLMN passes the location information to the GMLC of the NPN which then notifies the Application Function, AF, of the NPN or the external client with the location information.
14. 14. The method of any preceding claim wherein the NPN is situated entirely within a coverage area of the PLMN.
15. 15. Apparatus arranged to perform the method of any preceding claim.