Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
CONTROLLING PAGING OF A TERMINAL DEVICE
Document Type and Number:
WIPO Patent Application WO/2023/027614
Kind Code:
A1
Abstract:
A method in a mobility management node of controlling paging of a first terminal device, the method comprising: sending (701) a paging request message relating to the first terminal device to a set of access network nodes; if the paging request message is unsuccessful, determining (702) whether the paging request message should be resent to one or more of the set of access network nodes, wherein the determining is based on: (a) historical data relating to previous paging request messages, and (b) one or both of (i) the first terminal device, and (ii) the access network nodes in the set of access network nodes; and if it is determined to resend the paging request message, resending (703) the paging request message to the one or more access network nodes.

Inventors:
JOHANSSON ÅKE (SE)
DEREHAG JESPER (SE)
HE LIYE (SE)
NIZAMANI RAHIM (SE)
LARSSON RIKARD (SE)
Application Number:
PCT/SE2021/050818
Publication Date:
March 02, 2023
Filing Date:
August 23, 2021
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
ERICSSON TELEFON AB L M (SE)
International Classes:
H04W68/02; H04W68/04; H04W88/14
Foreign References:
US20140155109A12014-06-05
US20100128621A12010-05-27
US20170374644A12017-12-28
Attorney, Agent or Firm:
ERICSSON AB (SE)
Download PDF:
Claims:
CLAIMS

1. A method in a mobility management node of controlling paging of a first terminal device, the method comprising: sending (701) a paging request message relating to the first terminal device to a set of access network nodes; if the paging request message is unsuccessful, determining (702) whether the paging request message should be resent to one or more of the set of access network nodes, wherein the determining is based on: (a) historical data relating to previous paging request messages, and (b) one or both of (I) the first terminal device, and (ii) the access network nodes in the set of access network nodes; and if it is determined to resend the paging request message, resending (703) the paging request message to the one or more access network nodes.

2. A method as claimed in claim 1, wherein the historical data indicates whether resending paging request messages will be successful.

3. A method as claimed in any of claims 1-2, wherein the historical data relates to previous paging request messages for paging a plurality of terminal devices, and/or to previous paging request messages sent to a plurality of access network nodes.

4. A method as claimed in claim 3, wherein the plurality of terminal devices include one or more of: different terminal device models, terminal devices with different subscribers, and terminal devices with different software and/or firmware versions.

5. A method as claimed in any of claims 1-4, wherein the historical data relates to previous paging request messages sent at different times of day.

6. A method as claimed in any of claims 1 -5, wherein the historical data further comprises an indication of a time period between sending a paging request message and a successful response to the paging request message.

7. A method as claimed in any of claims 1-6, wherein the method further comprises: if the paging request message relating to the first terminal device is resent, waiting for a response from the first terminal device for a time period that is determined based on the historical data.

8. A method as claimed in any of claims 1-7, wherein the historical data is in the form of probabilities, derived from previous paging request messages, that resending paging request messages will be successful.

9. A method as claimed in claim 8, wherein determining whether a paging request message relating to the first terminal device should be resent comprises determining that the paging request message should be resent if the probability that resending will be successful is greater than a threshold.

10. A method as claimed in any of claims 1-9, wherein the method further comprises: if it is determined to resend the paging request message to one or more of the set of access network nodes, updating the historical data to include an outcome of the resent paging request message.

11. A method as claimed in any of claims 1-10, wherein the method further comprises: if it is determined not to resend the paging request message to any of the set of access network nodes, selecting a second set of access network nodes; and sending a paging request message for the first terminal device to the second set of access network nodes.

12. A method as claimed in any of claims 1-10, wherein the method further comprises: if it is determined not to resend the paging request message to any of the set of access network nodes, selecting a second set of access network nodes; and determining whether the paging request message should be resent to one or more of the second set of access network nodes, wherein the determining is based on: (a) historical data relating to previous paging request messages, and (b) one or both of (I) the first terminal device, and (ii) the access network nodes in the second set of access network nodes.

13. A method as claimed in any of claims 11-12, wherein the second set of access network nodes is one of: a set of access network nodes that the first terminal device has previously been connected to; a set of access network nodes in a tracking area in which the first terminal device has previously been located; and a set of access network nodes in a set of tracking areas in which the first terminal device has previously been located.

14. A mobility management node, MMN, (208, 300) for controlling paging of a first terminal device, the MMN (208, 300) configured to: send a paging request message relating to the first terminal device to a set of access network nodes; if the paging request message is unsuccessful, determine whether the paging request message should be resent to one or more of the set of access network nodes, wherein the determining is based on: (a) historical data relating to previous paging request messages, and (b) one or both of (I) the first terminal device, and (ii) the access network nodes in the set of access network nodes; and if it is determined to resend the paging request message, resend the paging request message to the one or more access network nodes.

15. A MMN (208, 300) as claimed in claim 14, wherein the historical data indicates whether resending paging request messages will be successful.

16. A MMN (208, 300) as claimed in any of claims 14-15, wherein the historical data relates to previous paging request messages for paging a plurality of terminal devices, and/or to previous paging request messages to a plurality of access network nodes.

17. A MMN (208, 300) as claimed in claim 16, wherein the plurality of terminal devices include one or more of: different terminal device models, terminal devices with different subscribers, and terminal devices with different software and/or firmware versions.

18. A MMN (208, 300) as claimed in any of claims 14-1 , wherein the historical data relates to previous paging request messages sent at different times of day.

19. A MMN (208, 300) as claimed in any of claims 14-18, wherein the historical data further comprises an indication of a time period between sending a paging request message and a successful response to the paging request message.

20. A MMN (208, 300) as claimed in any of claims 14-19, wherein the MMN (208, 300) is further configured to: if the paging request message relating to the first terminal device is resent, wait for a response from the first terminal device for a time period that is determined based on the historical data.

21. A MMN (208, 300) as claimed in any of claims 14-20, wherein the historical data is in the form of probabilities, derived from previous paging request messages, that resending paging request messages will be successful.

22. A MMN (208, 300) as claimed in claim 21 , wherein the MMN (208, 300) is further configured to determine whether a paging request message relating to the first terminal device should be resent by determining that the paging request message should be resent if the probability that resending will be successful is greater than a threshold.

23. A MMN (208, 300) as claimed in any of claims 14-22, wherein the MMN (208, 300) is further configured to: if it is determined to resend the paging request message to one or more of the set of access network nodes, update the historical data to include an outcome of the resent paging request message.

24. A MMN (208, 300) as claimed in any of claims 14-23, wherein the MMN (208, 300) is further configured to:

17 if it is determined not to resend the paging request message to any of the set of access network nodes, select a second set of access network nodes; and send a paging request message for the first terminal device to the second set of access network nodes. A MMN (208, 300) as claimed in any of claims 14-23, wherein the MMN (208, 300) is further configured to: if it is determined not to resend the paging request message to any of the set of access network nodes, select a second set of access network nodes; and determine whether the paging request message should be resent to one or more of the second set of access network nodes, wherein the determining is based on: (a) historical data relating to previous paging request messages, and (b) one or both of (I) the first terminal device, and (ii) the access network nodes in the second set of access network nodes. A MMN (208, 300) as claimed in any of claims 24-25, wherein the second set of access network nodes is one of: a set of access network nodes that the first terminal device has previously been connected to; a set of access network nodes in a tracking area in which the first terminal device has previously been located; and a set of access network nodes in a set of tracking areas in which the first terminal device has previously been located. A mobility management node, MMN, for controlling paging of a first terminal device, the MMN comprising a processor and a memory, the memory containing instructions executable by the processor whereby the MMN is operative to: send a paging request message relating to the first terminal device to a set of access network nodes; if the paging request message is unsuccessful, determine whether the paging request message should be resent to one or more of the set of access network nodes, wherein the determining is based on: (a) historical data relating to previous paging request messages, and (b) one or both of (I) the first terminal device, and (ii) the access network nodes in the set of access network nodes; and if it is determined to resend the paging request message, resend the paging request message to the one or more access network nodes. A MMN as claimed in claim 27, wherein the historical data indicates whether resending paging request messages will be successful. A MMN as claimed in any of claims 27-28, wherein the historical data relates to previous paging request messages for paging a plurality of terminal devices, and/or to previous paging request messages to a plurality of access network nodes.

18

30. A MMN as claimed in claim 29, wherein the plurality of terminal devices include one or more of: different terminal device models, terminal devices with different subscribers, and terminal devices with different software and/or firmware versions.

31. A MMN as claimed in any of claims 27-30, wherein the historical data relates to previous paging request messages sent at different times of day.

32. A MMN as claimed in any of claims 27-31 , wherein the historical data further comprises an indication of a time period between sending a paging request message and a successful response to the paging request message.

33. A MMN as claimed in any of claims 27-32, wherein the MMN is further operative to: if the paging request message relating to the first terminal device is resent, wait for a response from the first terminal device for a time period that is determined based on the historical data.

34. A MMN as claimed in any of claims 27-33, wherein the historical data is in the form of probabilities, derived from previous paging request messages, that resending paging request messages will be successful.

35. A MMN as claimed in claim 34, wherein the MMN is further operative to determine whether a paging request message relating to the first terminal device should be resent by determining that the paging request message should be resent if the probability that resending will be successful is greater than a threshold.

36. A MMN as claimed in any of claims 27-35, wherein the MMN is further operative to: if it is determined to resend the paging request message to one or more of the set of access network nodes, update the historical data to include an outcome of the resent paging request message.

37. A MMN as claimed in any of claims 27-36, wherein the MMN is further operative to: if it is determined not to resend the paging request message to any of the set of access network nodes, select a second set of access network nodes; and send a paging request message for the first terminal device to the second set of access network nodes.

38. A MMN as claimed in any of claims 27-36, wherein the MMN is further operative to: if it is determined not to resend the paging request message to any of the set of access network nodes, select a second set of access network nodes; and determine whether the paging request message should be resent to one or more of the second set of access network nodes, wherein the determining is based on: (a) historical data relating to previous paging

19 request messages, and (b) one or both of (i) the first terminal device, and (ii) the access network nodes in the second set of access network nodes. A MMN as claimed in any of claims 37-38, wherein the second set of access network nodes is one of: a set of access network nodes that the first terminal device has previously been connected to; a set of access network nodes in a tracking area in which the first terminal device has previously been located; and a set of access network nodes in a set of tracking areas in which the first terminal device has previously been located. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of claims 1 -13.

20

Description:
of a terminal device

Technical Field

This disclosure relates to techniques in a mobility management node for controlling paging of a terminal device.

A terminal device (also referred to herein as a user equipment (UE) or wireless device) that does not send or receive data enters idle mode to save resources. While the UE is in idle mode it listens to incoming signalling but does not actively announce its whereabouts unless it leaves its current Tracking Area (TA) list. Therefore, when a UE is in idle mode, its location is unknown. When the UE must be reached, for example due to incoming traffic, a procedure called paging can be used to find the UE. The mobility management node (MMN) (e.g. Mobility Management Entity (MME) or Access and Mobility Management function (AMF)) is responsible for initiating the paging. The MMN sends signals to network node(s) (e.g. eNodeB, gNodeB, and other base station types) and the network node(s) will attempt to contact the UE. The signals sent by the MMN are referred to herein as paging request messages, and the signals sent by the network nodes to page a UE are referred to herein as paging signals. If the paging fails, the MMN tries more and more network nodes in stages until the UE replies. The stages that are tried are typically in the order: last known network node, a network node list (or alternatively probabilistic paging), a last TA and the TA List. A successful paging outcome is achieved when the UE responds to a paging signal.

Fig. 1 depicts a UE in a communication network with six network nodes (labelled in this example as eNodeBs (eNBs)) including the last known eNodeB (the last network node that the UE was connected to - eNB 2), the current eNodeB (the network node that the UE is currently connected to - eNB 3), and the eNodeB list (which includes eNB 0, eNB 1 and eNB 2). The circled regions show two tracking areas, TA1 (which includes eNB 1 and eNB 2) and TA2 (which includes eNB 3, eNB 4 and eNB 5), and a TA list (which includes TA1 and TA2). Fig. 1 also shows the MMN (in this example a MME).

The number of network nodes to which the paging request messages are sent is called the paging width. Paging stages that have a wider scope, i.e. those that have a larger number of network nodes, typically include the network nodes from the stages with narrower scope. It is also possible to configure resending within each stage, i.e. multiple attempts (e.g. 0-4) may be made to the network nodes within a stage before moving to the next stage. There is also a waiting time between each attempt (i.e. how long from sending the paging request message to wait for a reply from the UE before determining that the paging attempt has failed), which can be configured, for example to a value in the range of 320-15000 milliseconds (ms)). The order in which network nodes are attempted (the paging stages) together with the number of attempts at each stage is referred to as the paging configuration (also sometimes referred to as a paging profile). The number of attempts that are made at each stage of the paging configuration is a trade-off between signalling load (i.e. the signalling resources required) and the time taken (i.e. latency) to find a UE. The paging configuration to use can be determined based on any one or more of: access point name (APN), address resolution protocol (ARP), QoS class identifier (QCI), international mobile subscriber identity (IMSI), international mobile equipment identity (IMEI), geographical area, etc. Currently, all network nodes are treated in the same way with regard to resending paging request messages. However, this approach does not make the best use of time and signalling resources since it does not account for the differing quality of the coverage between different network nodes. Some network nodes never need the paging request messages to be resent to it because, if a UE is in the coverage area of that network node, the network node will reliably obtain a response from the UE on the first attempt. For these network nodes, resending the paging signal when no response is received is unnecessary because if the UE was present, there would have been a response. On the other hand, other network nodes occasionally need to resend the paging signal, and so it is a good idea for the MMN to resend the paging request message to that/those network nodes when there has been no response. This may be because, for example, the network node is poorly configured, or the coverage area of the network node includes ‘blindspots' where UEs may temporarily be located (such as behind a building, in a tunnel, etc.). The same holds for different UE models, UEs with software/firmware versions, etc. which can be identified using the UE's I MEI, since some models and/or software/firmware versions are more likely to benefit from a resending than others. Also, different individual UEs, e.g. as identified by I MSI , may behave differently, for example, due to how the phone is carried by the subscriber. There are further attributes that could be applicable to resending, e.g. the time of day, interference on the air interface, etc. Some attributes, e.g. IMEI or IMSI, can be selected by the paging configuration but this requires a lot of work and does not adapt to new circumstances. Therefore, current approaches to paging can cause unnecessary high signalling load and latency.

The techniques proposed herein address these and other challenges. It is proposed to make use of historic behaviour regarding resending, e.g. for different network nodes and/or UE models, and to use this data to provide an estimation of whether resending will be beneficial (e.g. will lead to a successful paging outcome). This information is then used to tailor the paging behaviour for each paging. For example, if historical data indicates that all network nodes in the network node list in combination with the current UE model rarely need resending, the paging request messages will not be resent to these network nodes. Instead, if the UE was not found on the first attempt of the network node list, it is better to go directly to the next paging stage, for example network nodes in the TA. This approach will reduce latency and save signalling resources. Another example is if the network nodes in the current list or TA differ a lot regarding resending success, it may be a good idea to only resend to some network nodes to reduce the number of signalling messages. Furthermore, the time between attempts could be reduced since fewer signals cause less stress on the system. This approach will improve the latency, on average.

According to a first specific aspect, there is provided a method in a mobility management node of controlling paging of a first terminal device. The method comprises sending a paging request message relating to the first terminal device to a set of access network nodes. If the paging request message is unsuccessful, the method comprises determining whether the paging request message should be resent to one or more of the set of access network nodes, wherein the determining is based on: (a) historical data relating to previous paging request messages, and (b) one or both of (i) the first terminal device, and (ii) the access network nodes in the set of access network nodes. If it is determined to resend the paging request message, the method comprises resending the paging request message to the one or more access network nodes.

According to a second specific aspect, there is provided a MMN for controlling paging of a first terminal device. The MMN is configured to send a paging request message relating to the first terminal device to a set of access network nodes. If the paging request message is unsuccessful, the MMN is configured to determine whether the paging request message should be resent to one or more of the set of access network nodes, wherein the determining is based on: (a) historical data relating to previous paging request messages, and (b) one or both of (I) the first terminal device, and (ii) the access network nodes in the set of access network nodes. If it is determined to resend the paging request message, the MMN in configured to resend the paging request message to the one or more access network nodes.

According to a third specific aspect, there is provided a MMN for controlling paging of a first terminal device. The MMN comprises a processor and a memory, the memory containing instructions executable by the processor whereby the MMN is operative to send a paging request message relating to the first terminal device to a set of access network nodes. If the paging request message is unsuccessful, the MMN is operative to determine whether the paging request message should be resent to one or more of the set of access network nodes, wherein the determining is based on: (a) historical data relating to previous paging request messages, and (b) one or both of (I) the first terminal device, and (ii) the access network nodes in the set of access network nodes. If it is determined to resend the paging request message, the MMN is operative to resend the paging request message to the one or more access network nodes.

According to a fourth specific aspect, there is provided a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of the first embodiment.

The techniques disclosed herein provide a better mechanism for paging by adapting the resending behaviour based on historical resending data. The proposed method can reduce the number of signals needed during paging to find the UE whilst also reducing the time it takes to find a UE during paging. This is because paging request messages are not resent when previous paging requests demonstrate that resending is unlikely to be successful, and paging request messages are resent when previous paging requests demonstrate that resending is likely to be successful.

Brief of the

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, in which:

Fig. 1 illustrates a communication network;

Fig. 2 is an example of a communication system in accordance with some embodiments;

Fig. 3 is a mobility management node in accordance with some embodiments;

Fig. 4 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized;

Fig. 5 is a signalling diagram illustrating embodiments of the techniques described herein; Fig. 6 is a flow chart illustrating embodiments of the techniques described herein; and

Fig. 7 is a flow chart illustrating a method performed by a mobility management node in accordance with the techniques described herein.

Detailed

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

Fig. 2 shows an example of a communication system 200 in accordance with some embodiments.

In the example, the communication system 200 includes a telecommunication network 202 that includes an access network 204, such as a radio access network (RAN), and a core network 206, which includes one or more core network nodes, including a mobility management node (MMN) 208, such as a MME or an AMF. The access network 204 includes one or more access network nodes, such as access network nodes 210a and 210b (one or more of which may be generally referred to as access network nodes 210), or any other similar 3 rd Generation Partnership Project (3GPP) access node or non-3GPP access point. The access network nodes 210 facilitate direct or indirect connection of wireless devices (also referred to interchangeably herein as user equipment (UE)), such as by connecting UEs 212a, 212b (one or more of which may be generally referred to as UEs 212) to the core network 206 over one or more wireless connections. The access network nodes 210 may be, for example, access points (APs) (e.g. radio access points), base stations (BSs) (e.g. radio base stations, Node Bs, evolved Node Bs (eNodeBs /eNBs) and New Radio (NR) NodeBs (gNodeBs /gNBs)).

Example wireless communications over a wireless connection include transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 200 may include any number of wired or wireless networks, network nodes, UEs, and/or any other components or systems that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections. The communication system 200 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.

The wireless devices/UEs 212 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and/or operable to communicate wirelessly with the access network nodes 210 and other communication devices. Similarly, the access network nodes 210 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 212 and/or with other network nodes or equipment in the telecommunication network 202 to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in the telecommunication network 202.

As a whole, the communication system 200 of Fig. 2 enables connectivity between the wireless devices/UEs, network nodes. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g. 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and/or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

In some examples, the telecommunication network 202 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 202 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 202. For example, the telecommunications network 202 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and/or Massive Machine Type Communication (mMTC)ZMassive loT services to yet further UEs.

In some examples, the UEs 212 are configured to transmit and/or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 204 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 204. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

Fig. 3 shows a mobility management node 300 in accordance with some embodiments. The mobility management node, a core network node, is equipment capable, configured, arranged and/or operable to communicate directly or indirectly with network nodes, UEs, and/or equipment in a telecommunication network. Examples of network nodes include, but are not limited to, access network nodes such as access points (APs) (e.g. radio access points), base stations (BSs) (e.g. radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)). Other examples of network nodes include, but are not limited to, other core network nodes such as nodes that include functions of one or more of a Mobile Switching Center (MSC), Home Subscriber Server (HSS), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF).

The MMN 300 includes processing circuitry 302, a memory 304, a communication interface 306, and a power source 308, and/or any other component, or any combination thereof. The MMN 300 may be composed of multiple physically separate components, which may each have their own respective components.

The processing circuitry 302 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other MMN 300 components, such as the memory 304, to provide MMN 300 functionality. For example, the processing circuitry 302 may be configured to cause the MMN to perform the methods as described with reference to Figs. 6 and/or 7. In some embodiments, the processing circuitry 302 includes a system on a chip (SOC).

The memory 304 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device-readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by the processing circuitry 302. The memory 304 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and/or other instructions capable of being executed by the processing circuitry 302 and utilized by the MMN 300. The memory 304 may be used to store any calculations made by the processing circuitry 302 and/or any data received via the communication interface 306. In some embodiments, the processing circuitry 302 and memory 304 is integrated.

The communication interface 306 is used in communication of signalling and/or data between core network nodes, the access network and/or access network nodes. As illustrated, the communication interface 306 comprises port(s)/terminal(s) 316 to send and receive data, for example to and from a network node over a wired connection.

The communication interface 306 and/or the processing circuitry 302 may be configured to perform any receiving operations described herein as being performed by the MMN. Any information, data and/or signals may be received from an access network node (e.g. eNB or gNB), another core network node and/or any other network node or network equipment. Similarly, the communication interface 306 and/or the processing circuitry 302 may be configured to perform any transmitting operations described herein as being performed by the MMN. Any information, data and/or signals may be transmitted to an access network node, another core network node and/or any other network node or network equipment.

The power source 308 provides power to the various components of MMN 300 in a form suitable for the respective components (e.g. at a voltage and current level needed for each respective component). The power source 308 may further comprise, or be coupled to, power management circuitry to supply the components of the MMN 300 with power for performing the functionality described herein. For example, the MMN 300 may be connectable to an external power source (e.g. the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 308. As a further example, the power source 308 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

Embodiments of the MMN 300 may include additional components beyond those shown in Fig. 3 for providing certain aspects of the MMN's functionality, including any of the functionality described herein and/or any functionality necessary to support the subject matter described herein. For example, the MMN 300 may include user interface equipment to allow input of information into the MMN 300 and to allow output of information from the MMN 300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the MMN 300. Fig. 4 is a block diagram illustrating a virtualization environment 400 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, for example a MMN, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 400 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a MMN. Further, in some embodiments the node may be entirely virtualized.

Applications 402 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 400 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.

Hardware 404 includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 406 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 408a and 408b (one or more of which may be generally referred to as VMs 408), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer 406 may present a virtual operating platform that appears like networking hardware to the VMs 408.

The VMs 408 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 406. Different embodiments of the instance of a virtual appliance 402 may be implemented on one or more of VMs 408, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

In the context of NFV, a VM 408 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 408, and that part of hardware 404 that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 408 on top of the hardware 404 and corresponds to the application 402.

Hardware 404 may be implemented in a standalone network node with generic or specific components. Hardware 404 may implement some functions via virtualization. Alternatively, hardware 404 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 410, which, among others, oversees lifecycle management of applications 402. Although the computing devices described herein (e.g. UEs, network nodes) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and/or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and/or by end users and a wireless network generally.

As noted above, under current paging mechanisms, paging request messages are sent to access network nodes according to a preconfigured paging configuration. The disclosed techniques select the access network nodes and decide whether to resend the paging request messages based not only on the paging configuration, but also on data relating to previous sending and resending of paging request messages. This results in a more efficient paging mechanism that saves signalling resources and reduces latency.

Fig. 5 is a signalling diagram illustrating a method of paging according to various embodiments. Fig. 5 shows the signalling between four ‘nodes', a mobility management node, MMN (in this embodiment a MME), a paging algorithm (which is in practice implemented by or within the MMN), one or more access network nodes (in this embodiment, eNBs) and a UE. The specific embodiment illustrated in Fig. 5 is also applicable to other mobility management nodes, e.g. AMFs, and/or other access network nodes, e.g. gNBs or other network nodes.

At step 501 , the paging process is triggered by the MME receiving downlink data for an idle UE, being notified that there will be downlink data for the UE, or receiving a notification of an incoming call for the UE. Since the location of the UE is unknown, the MME starts the paging process (step 502). The MME uses the paging algorithm to decide which access network nodes to contact in order to locate the UE. The paging algorithm can determine the network nodes to contact based on any of the last known location of the UE, a paging configuration, and historical data (steps 503 and 504). An example paging algorithm is described with reference to Fig. 6.

The paging configuration indicates, for each paging stage, which access network nodes paging request messages should be sent to, and how many times, if any, the paging request messages should be resent to those network nodes. The number of access network nodes to be contacted is referred to as the paging width.

The historical data is data about previous paging requests. In particular, the historical data relates to the sending and/or resending of previous paging request messages and the corresponding paging outcomes (i.e. whether the UE was located or not in response to those paging request messages). This historical data can be stored in the MME and, in some embodiments, updated with recent resending data. The historical data can include data relating to many different network nodes in the communication network, and/or many different UEs, or types/models of UEs. In some embodiments, the historical data can include the identity of the network node(s) and/or UE(s) involved in particular paging requests. For example, the historical data may indicate whether or not sending or resending previous paging request messages resulted in a successful response from a particular access network node and/or how long it took for a positive response to be received from the sending of the paging request message to the network node. This information can be used to decide in steps 503/504 whether it is worth resending a paging request message to a particular access network node and/or for how long to wait for a response.

At step 505, the list of access network nodes to which paging request messages are to be sent is output by the paging algorithm and, at step 506, the MME sends paging request messages to the access network nodes on the list indicating the UE that is to be paged. When an access network node receives a paging request message from the MME, it will attempt to page the UE (step 507) by transmitting a paging signal for the UE. The MME waits for a time period for a response (step 508), and the paging is deemed a success if a response is received from an access network node before the expiry of this time period ('timeout') indicating that the UE has replied. The paging is a failure/unsuccessful if no such response is received from an access network node before the expiry of the time period (step 508). If the paging fails, the MME/paging algorithm will, at step 509, repeat the paging process and take a new decision on whether to resend the paging request message based on the historical data, and decide which network node(s) the paging request messages should be resent to, possibly widening, maintaining, or narrowing the paging area. In particular, the historical data may indicate that a certain network node is reliable or very reliable when it comes to successfully paging UEs within its coverage area. In that case, a failed paging request is likely due to the UE not being in the coverage area of that network node, and resending a paging request message to that network node may be a waste of resources. On the other hand, the historical data may indicate that a certain network node is not reliable or very unreliable when it comes to successfully paging UEs within its coverage area. In that case, a failed paging request might not be a useful indicator that the UE is not within in the coverage area of that network node, and so resending a paging request message to that network node may enable the UE to be contacted.

Thus the repetition of steps 503/504 could mean that the MME sends paging request messages to more access network nodes (i.e. if a maximum amount of resending at the current paging area has been completed and the paging area is widened), resends paging request messages to the same set of access network nodes again, or resends paging request messages to only some of the same access network nodes (for example only to access network nodes that are considered to be unreliable). Thus, the paging algorithm could decide to resend paging request messages to a subset of the access network nodes that were paged in the last attempt to save signalling if the access network nodes in the first group have very diverse resending behaviour.

Fig. 6 is a flow chart illustrating specific embodiments of the techniques described herein for paging a particular UE.

At step 601 , a set of candidate access network node(s) (denoted in Fig. 6 as eNodeB(s) or eNB(s)) are selected according to the current paging configuration and the last access network node to which the UE to be paged was known to be connected. For example, step 601 could comprise selecting all the eNBs in the eNB list, or all eNBs in the Tracking Area. This specific embodiment is also applicable to other access network nodes, e.g. gNBs.

At step 602 it is determined whether the next steps of the method constitute a resending of paging request messages for this particular UE. In some embodiments, resending (‘yes' at step 602) may mean that there has already been a paging attempt for this UE in which paging request messages were sent to all of the selected set of candidate access network node(s). This is usually because the paging configuration indicates that the previous stage should be repeated, i.e. the paging request messages should be resent to all of the access network nodes in the previous stage. However, resending (‘yes' at step 602) can also mean that the current paging stage is a new paging stage that is of wider scope than the previous stage and includes some of the same candidate network nodes as the previous paging stage. Therefore, paging request messages relating to this UE have already been sent to some, but not all, of the candidate network nodes.

At step 603, the historical data is used to determine whether a paging request message should be resent. This step can include considering the historical behaviour of the selected candidate access network node(s). It can also include considering the historical behaviour of the current UE, or other UEs that have similar properties to the current UE, such as UEs of the same device model, the same software/fi rmware version, or the same subscriber. For example, if the data indicates that all of the candidate access network nodes are known to be very reliable when paging (‘yes' at step 603), then the previous paging attempt being unsuccessful may indicate that the UE is not located at any of the candidate access network nodes and resending is not necessary. In this case, the algorithm returns to step 601 and continues at the first step with a widening of the paging scope. If, on the other hand, the historical data indicates that one or more of the candidate access network nodes are known to be unreliable ('no' at step 603), then it is possible that the UE is located at one or more of the access network nodes and resending to these access network nodes could be beneficial. In that case the method proceeds to step 604.

Based on the historical data, the algorithm may, at optional step 604, select a subset of the candidate access network nodes to which a paging request message is to be resent. The subset may correspond to those network nodes known to be unreliable. Next, the algorithm may optionally adjust the timeout at step 605. The timeout is the period of time that the MME waits after sending the paging request message before declaring the paging request unsuccessful. In step 605 the algorithm may indicate that the resending to the selected subset is performed with a shortened timeout. Alternatively, the historical data may indicate that one or more of the selected network nodes take longer than usual to respond with a paging success, and the algorithm may indicate that the resending to the selected subset is performed with a longer timeout. In some embodiments, different timeouts can be used for different access network nodes. After step 605, the method proceeds to step 606.

As noted above, if it is determined at step 602 that this is not a resending, then steps 603-605 are not performed, and the method proceeds directly to step 606.

At step 606 the paging request messages are sent to the candidate access network nodes selected in step 601 , or, if step 604 was performed, the paging request messages are sent to the subset of network nodes selected at step 604. In response to receiving a paging request message, the network node pages the UE (i.e. the network node transmits a paging signal for the UE).

At step 607 the MME waits for a response from the candidate access network nodes. If step 605 is performed, the MME can wait for the determined timeout (or determined timeouts if different timeouts are determined for different network nodes), and if step 605 is not performed, the MME can wait for a predetermined timeout period.

At step 608, if the paging fails (i.e. if no response is received and the location of the UE remains unknown), then the algorithm returns to step 601 and repeats the selection of candidate access network nodes. If the paging succeeds (i.e. a response is received from an access network node indicating that the UE has responded to the paging signal), then the historical data is updated to include details of the paging (step 609).

In further embodiments, the historical data can be used in the first attempt (i.e. in instances that do not constitute resending at step 602). For example, a shorter timeout may be selected based on the historical data indicating that the network node is unreliable, and use this shorter timeout during a first attempt. If no response is received within this shorter time period, resending may be performed only to the access network nodes that are known from the historical data to be unreliable.

The historical data can, in some embodiments, be in the form of probabilities that resending paging request messages will be successful. Each probability of success can be based, for example, on the network node to which the paging request message is sent and/or the UE to which the paging relates. These probabilities can be stored in multiple tables such that the algorithm can take into account the probabilities that are most relevant to any given stage of the paging configuration. For example, one type of table can provide a resending probability per pair of access network node and UE device type, and the paging algorithm can first look for a probability corresponding to the same network node and the same UE device type (model, software/firmware version, etc.) as those involved in the paging. Another type of table could keep track of the resending probability per access network node independent of the UE device type, and another type of table could keep track of the resending probability per UE device type independent of the specific access network nodes to which the paging request messages are sent. Therefore, if there is no probability available for a particular combination of network node and UE device type, the paging algorithm will look to identify a relevant probability based on either the particular network node(s) or the particular UE device type. If there are corresponding probabilities for both of these, an average can be used, or one of them selected. The historical data may also include a global resending probability that is applicable to any network node and any UE device type. The global value can be a measured value, e.g. determined based on all of the resending data for all access network nodes and all UE device types. Alternatively the global resending probability can be preconfigured and set to a default value, e.g. 0.001 corresponding to a 0.1 % chance that resending will be successful. The global value may be used as a last resort if there are no, more relevant, probability values available.

It will be appreciated that other probabilities can be derived from the data relating to previous paging attempts and used to determine whether paging request messages should be resent. For example, the data relating to previous paging attempts could be used to derive the probability that, for a given paging request message sent by the MMN, it will be necessary to resend the paging request message to get a reliable result. A reliable result could be either success or failure, provided the failure to receive a response is a true negative, i.e. the UE is not located near the corresponding network node. For example, if the probability that resending is necessary (i.e. that the result is unreliable) is 0.1 %, the probability that resending is not necessary (i.e. that the result is reliable) is 99.9%.

The historical data may be periodically updated or continuously updated. For example, old probability values in the table may become outdated as network node behaviour or configurations change. Thus, old probability values, and/or data relating to old paging request messages, can be deleted from the historical data, or can be ignored when determining appropriate probability values. This can be achieved using, for example, a rolling average or some version thereof.

Preferably, the sample size of the historical data must be sufficiently large for a useful probability to be derived from the resending data. In some embodiments, probabilities may be used by the paging algorithm when they are derived from historical data that is larger than a minimum threshold sample size.

It will be appreciated that the access network node to which the paging request message is sent and the UE model/device type are just examples of factors that could influence whether to resend the paging request message. There are many more properties that could be recorded as part of the historical resending data and be used to influence whether a paging request message is to be resent. These can include IMSI (i.e. the identity of the subscriber) and the time of day. The time of day may be useful to take account of as certain network nodes may be busier at particular times of the day, and this can influence the chance of a successful paging of a UE.

The notion of ‘reliable'/'unreliable' as used above with respect to a network node can, in the simplest case, be implemented as a configured threshold. For example if the probability of resending being successful (for a given access network node/UE device type/subscriber/time of day etc.) is higher than 1 %, the paging is may be considered unreliable and resending is deemed beneficial. In alternative embodiments, more advanced adaptive methods can be used, for example an algorithm with feedback that adapts to previous paging results. Machine learning models can be used to implement this adaptive approach.

Fig. 7 is a flow chart illustrating a method of controlling paging of a first terminal device in accordance with the techniques described herein. The method is performed by a mobility management node, e.g. the mobility management node 300 described with reference to Fig. 3.

The method comprises a step 701 of sending a paging request message relating to the first terminal device to a set of access network nodes (e.g. eNBs and/or gNBs). The set of access network nodes can comprise one or more network nodes. The paging request message relating to the first terminal device can be a signal instructing the set of access network nodes to page the first terminal device in order to get the first terminal device to connect to the communication network. In some embodiments, the set of access network nodes correspond to a stage of a paging configuration.

If the paging request message is unsuccessful, then in step 702 the MMN determines whether the paging request message should be resent to one or more of the set of access network nodes. The MMN does this determining based on (a) historical data relating to previous paging request messages, and (b) one or both of (I) the first terminal device, and (ii) the access network nodes in the set of access network nodes. That is, the determining is based on the specific first terminal device (e.g. the UE model , the IMEI, the software/firmware version, etc.), and/or the access network nodes that sent the paging request in step 701 .

In some embodiments, the historical data indicates whether resending paging request messages will be successful. The historical data can include the outcome of previous paging attempts. For example, the historical data can show any one or more of the following: whether or not each previous paging attempt was successful, how many times a paging request message was sent before a response was received, and how long it took for a UE to respond.

In some embodiments, the historical data relates to previous paging request messages for paging a plurality of terminal devices, and/or to previous paging request messages sent to a plurality of access network nodes in respect of the first terminal device and/or a plurality of other terminal devices. The plurality of terminal devices can include different terminal device models, terminal devices with different subscribers, and terminal devices with different software and/or firmware versions. The historical data can relate to previous paging request messages sent at different times of day. In some embodiments, the historical data that is most relevant to (i.e. similar to) the current paging scenario is considered when determining whether the paging request message should be resent to one or more of the set of access network nodes.

The historical data can further comprise an indication of a time period between sending a paging request message and a successful response to the paging request message. In some embodiments, this indication of a time period is considered when determining how long to wait after sending the paging request message in step 701 before considering that the paging request message was unsuccessful due to a lack of response.

In some embodiments, the historical data is in the form of probabilities that resending paging request messages will be successful. These probabilities are derived from previous paging request messages. In some of these embodiments, step 702 comprises determining that the paging request message should be resent if the probability that resending will be successful is greater than a threshold. In some of these embodiments, a probability is only used if the sample size (i.e. the number of the previous paging request messages from which the probability is derived) is greater than a threshold value. There are other possible approaches to ensuring that the sample size is sufficient to provide a meaningful probability. For example, whether the sample size is sufficient can be determined based on p- values, confidence intervals or the number of decimal places in the configured confidences.

If it is determined to resend the paging request message, then at step 703 the MMN resends the paging request message to the one or more access network nodes. If the paging request message is resent to the one or more access network nodes, the method can also comprise updating the historical data to include an outcome of the resent paging request message. In some embodiments, the historical data is updated to delete or remove outdated data. Deleting or removing outdated data may be performed at periodic intervals or may be triggered by a certain event, e.g. when additional data is added.

In some embodiments, the method further comprises, if the paging request message relating to the first terminal device is resent, waiting for a response from the first terminal device for a time period that is determined based on the historical data. For example, this could be based on the indication, comprised in the historical data, of the time period between sending a paging request message and a successful response to the paging request message.

If, on the other hand, it is determined not to resend the paging request message to any of the set of access network nodes, the method can, in some embodiments, comprise selecting a second set of access network nodes and sending a paging request message for the first terminal device to the second set of access network nodes. In alternative embodiments, if it is determined not to resend the paging request message to any of the set of access network nodes, the method can comprise selecting a second set of access network nodes, and determining whether the paging request message should be resent to one or more of the second set of access network nodes. This is applicable when a paging request message has already been sent to one or more of the access network nodes in the second set because those access network nodes were also present in a previous set (e.g. the first set). In these embodiments, the determining is based on: (a) historical data relating to previous paging request messages, and (b) one or both of (I) the first terminal device, and (ii) the access network nodes in the second set of access network nodes.

The second set of access network nodes may be one of: a set of access network nodes that the first terminal device has previously been connected to; a set of access network nodes in a tracking area in which the first terminal device has previously been located; and a set of access network nodes in a set of tracking areas in which the first terminal device has previously been located. As mentioned above, these sets of access network nodes can correspond to the stages of a paging configuration.

The MMN may perform the method of Fig. 7 in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the scope of the disclosure. Various exemplary embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.