PROGRESSIVE DISCOVERY FOR ROUTING TO A GROUP OF NETWORK FUNCTIONS

An access and mobility management function, AMF, entity receives an initial registration request from a communication device and transmits, responsive thereto, a network function, NF, discovery request to a network function repository function, NRF, entity, the NF discovery request including a communication device identifier and an NF type identifier. The NRF entity matches the communication device identifier with one of a plurality of communication device identifier ranges configured by the NRF entity, extracts a group identifier, groupId, configured for the one of the plurality of communication device identifier ranges, builds a list of registered NF profiles matching the NF type identifier and registered with the groupId, and transmits the list of registered NF profiles including the groupId and a NRF mapping indication to the AMF entity.

TECHNICAL FIELD

The present disclosure relates generally to communications, and more particularly to communication methods and related devices and nodes supporting wireless communications.

BACKGROUND

NRF (Network Function Repository Function) is a 3GPP entity which stores the information for the different network function (NF) types in the 5GC (5th Generation Core) network (e.g. unified data management network function (UDM NF), access and mobility management function network function (AMF NF), user and data repository network function (UDR NF).

Each NF type is instanced based on the deployment type/needs. Each NF instance (e.g. UDR-instance-1, UDR-instance-2, UDM-instance-1, etc.) registers/stores its own NF information in NRF, which information is called a NF profile. This NF profile may include the ranges of users being served by the NF instance. Users are identified in the 5GC network with the SUPI (Subscription Permanent Identifier), which is unique per user.

This way, if an NF instance registers information about SUPI ranges being served, e.g.UDM-instance-1 registers in NRF SUPI-range-1-> from 111111110 to 111111114, SUPI-range-2-> from 211111115 to 211111119UDM-instance-2 registers in NRF SUPI-range-1-> from 111111115 to 111111119, SUPI-range-2-> from 211111110 to 211111114)

This NF information is read/discovered by an NF consumer of the services offered by a given NF type (e.g. UDM) so that the service request is sent to the proper NF service producer serving the related SUPI, e.g. an AMF may contact the NRF to read/discover all NFs of type UDM, and the NRF will return the NF profiles registered by each UDM instance. If the AMF receives a request from user-1 (SUPI-1=1111111101234), AMF will perform a lookup against the UDM profiles received from the NRF and it will select the proper UDM instance (in this case, UDM-instance-1, since SUPI-1 matches its SUPI-range-1).

Accordingly, the AMF will store each NF service producer profile discovered (e.g. UDM, AUSF) in its cache, each profile containing the SUPI ranges being served by each NF type/instance. Note that there might be several (or many) instances serving the same set of users (i.e. same SUPI ranges) for load sharing and failover purposes. Each NF profile is to be stored separately per instance, no matter whether or not they serve the same users.

Another alternative for this SUPI-based routing from an NF service consumer is that the NF service producers, instead of registering the SUPI ranges they are serving, they simply register/store in NRF a Group Identifier as part of its NF profile (e.g. UDM registers “udm-group-id-1”, UDR registers “udr-group-id-1”). The association between the SUPI ranges and the Group ID is then configured in NRF, e.g.UDM-instance-1 registers in NRF “udm-group-id-1”UDM-instance-2 registers in NRF “udm-group-id-2”NRF has this information configured:“udm-group-id-1” serves SUPI-range-1-> from 111111110 to 111111114, SUPI-range-2-> from 211111115 to 211111119“udm-group-id-2” serves SUPI-range-1-> from 111111115 to 111111119, SUPI-range-2-> from 211111110 to 211111114)

In this second alternative, the AMF will query NRF to discover the NF instances of a given type (e.g. UDM) for a given SUPI (e.g. SUPI-2=2111111101234). NRF will match the SUPI received to SUPI-range-2 in “udm-group-id-2” and it will respond AMF by including UDM-instance-2 (since it is the NF of type UDM which has registered the related Group ID). The AMF will then store, as part of the user-2 context, the GroupID and the list of UDM instances associated to the GroupId. That is, the AMF stores in its cache that “udm-group-id-2” is composed by UDM-instance-2. Additionally, while user-2 is registered, AMF stores, as part of the UE context/SUPI, the GroupId (“udm-group-id-2”), so that it is associated to the SUPI for subsequent requests.

This second alternative is supposed to be used by many operators since there is only a single point of configuration for the SUPI ranges, which is NRF. That is, instead of configuring the same information (i.e. the same SUPI ranges) in each NF profile for several (or many) NF instances of a given type, the information is just configured once in NRF and the related NF instances are simply configured with a Group ID which points at a list of SUPI ranges configured locally in NRF. This alternative also avoids sending and registering a large (in terms of size) NF profile per instance when the number of SUPI ranges being served by the NF instance is quite high.

In short: although both alternatives will be used, it is foreseen that the second one will be preferable in many deployments for the reasons described above.

SUMMARY

Problems with NRF Mapping

As can be seen inFIG.1, the NRF is contacted each and every time by the consumer NF (e.g., UDM) to fetch the list of target instances (service producers) for each and every SUPI. Even for stateful NFs (e.g., an AMF) storing the GroupId for the SUPI, if the wireless device (e.g., UE) is de-registered, then NRF is contacted again when the wireless device registers again in the network to discover the NF instances serving the SUPI. The contacting of the NRF each and every time makes the signaling complex and non-efficient since the NRF is forced to perform SUPI ranges lookup/matching for any NF consumer discovering the NF instances per every request. This is done for each and every SUPI in the network.

Problems for NF Profile Lookups

The size of the NF profiles to be registered can be dramatically large if there are a lot of SUPI ranges. For example, some operators like China Mobile are known to have around 5,000 SUPI ranges per UDM/UDR groups. For each and every request, the NF consumer (e.g. AMF, UDM) is forced to perform SUPI ranges lookup against each and every NF profile discovered, to build a list of selectable target NFs (NF service producers). This is done on a per request received basis. Overall, this requires a lot of storage in NRF, a lot of cache memory in AMF to host all NF instances including all the SUPI ranges registered by each NF. Moreover, the impacts in performance/computing when it comes to performing lookups with thousands of ranges can be dramatic. If there are, e.g. 20 NF instances, each registering 5.000 SUPI ranges in its profile, that makes 100.000 SUPI ranges to lookup before deciding the target NF instance to send the request. This is done for each and every request to be sent.

According to the invention, there is provided a method performed by a network function repository function, NRF, entity, the method comprising receiving a network function, NF, discovery request from an access and mobility management function, AMF, entity, the NF discovery request having a communication device identifier and a NF type identifier, matching the communication device identifier with one of a plurality of communication device identifier ranges configured by the NRF entity, extracting a group identifier, groupId, configured for the one of the plurality of communication device identifier ranges, building a list of registered NF profiles matching the NF type identifier and registered with the groupId, and transmitting the list of registered NF profiles including the groupId and a NRF mapping indication to the AMF entity.

There is further provided a network function repository entity configured to perform operations according to this method.

There is further provided a method performed by an access and mobility management function, AMF, entity, the method comprising transmitting, responsive to receiving an initial registration request from a communication device, a network function, NF, discovery request to a network function repository function, NRF, entity, the NF discovery request comprising a communication device identifier and a NF type identifier, and receiving a list of registered NF profiles including the groupId and a NRF mapping indication indicating that the mapping of communication device identifier ranges to the groupId is performed by the NRF entity.

There is further provided an access and mobility management function entity configured to perform operations according to this method.

There is further provided a method performed by a unified data management, UDM, entity, the method comprising receiving, from an access and mobility management function, AMF, entity, a communication device initial registration having a communication device identifier, selecting, regardless of the communication device identifier, one of one or more user and data repository, UDR, entities registered in a network function repository function, NRF, entity having a same group identifier, groupId, as the groupId of the UDM entity, and transmitting to the AMF entity a registration acknowledgement having the groupId and an indication of the one of the one or more UDR entities.

There is further provided a unified data management entity configured to perform operations according to this method.

Further, there are provided computer programs comprising instructions which, when performed by a processor or processing circuitry of one of these entities, cause the respective entity to perform operations according to the respective method.

It is noted that the term “entity” refers to any embodiment in which the respective functionality is implemented. This may for example be in a localized manner, wherein the functionality resides in a specific place and/or is tied to specific hardware, such as one or more processors, memory and the like. In such case, it may also be denoted a “node”. In another example, it may be implemented in a virtualized manner, as known by the skilled person, wherein the functionality resides in an unspecific place, like on an arbitrary server or even virtual machine, and/or is not tied to specific hardware. In such case, the functionality may also be distributed over different places, e.g. several servers, virtual machines or the like. In this case, it may also be denoted a virtual network function.

Advantages that may be achieved include a substantial reduction in operations administration and maintenance (OAM) and operational expenditure (OPEX) when configuring and planning the network deployment, since as soon as a range is to be added/deleted for a GroupId, it is only done in the NRF (and not in each and every NF profile instance in the network). A reduction in memory consumption and footprint in all NFs (except NRF) can be achieved by storing just Group Identifiers instead of SUPI ranges per NF profile. A further advantage is an improvement in performance/computing. The NF consumers fetch the ranges when they are needed, since for every range discovered and cache, every SUPI received must be matched against the cached ranges for each group. This makes the lookups much faster if only a subset of the ranges is cached, saving also storage in the NF consumer, since instead of storing all ranges per NF profile instance (alternative described inFIG.2), the NF consumer stores a single copy of the ranges per Group of NF instances.

DETAILED DESCRIPTION

NOTE: throughout this description, the term SUPI is used since it is the internal/private identifier (IMSI) used in the 5GC network, but other identifiers (existing or future) can be considered to use for the inventive concepts described herein. For example, NFs can also register GPSI ranges (public identities in the 5GC network), routing indicators (included in concealed identities), etc. This way, whenever SUPI is explicitly used in the descriptions of various embodiments of inventive concepts, it may refer to other identifiers associated/provisioned to users, since the inventive principles are kept unchanged when it comes to management and routing.

FIG.3is a block diagram illustrating elements of a communication device100(also referred to as a mobile terminal, a mobile communication terminal, a wireless device, a wireless communication device, a wireless terminal, mobile device, a wireless communication terminal, user equipment, UE, a user equipment node/terminal/device, etc.) configured to provide wireless communication according to embodiments of inventive concepts. (Communication device100may be provided, for example, as discussed below with respect to wireless device4110ofFIG.18.) As shown, communication device100may include an antenna307(e.g., corresponding to antenna4111ofFIG.18), and transceiver circuitry301(also referred to as a transceiver, e.g., corresponding to interface4114ofFIG.18) including a transmitter and a receiver configured to provide uplink and downlink radio communications with a base station(s) (e.g., corresponding to network node4160ofFIG.18, also referred to as a RAN node) of a radio access network. Communication device100may also include processing circuitry303(also referred to as a processor, e.g., corresponding to processing circuitry4120ofFIG.18) coupled to the transceiver circuitry, and memory circuitry305(also referred to as memory, e.g., corresponding to device readable medium4130ofFIG.18) coupled to the processing circuitry. The memory circuitry305may include computer readable program code that when executed by the processing circuitry303causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry303may be defined to include memory so that separate memory circuitry is not required. Communication device100may also include an interface (such as a user interface) coupled with processing circuitry303, and/or communication device100may be incorporated in a vehicle.

As discussed herein, operations of communication device100may be performed by processing circuitry303and/or transceiver circuitry301. For example, processing circuitry303may control transceiver circuitry301to transmit communications through transceiver circuitry301over a radio interface to a radio access network node (also referred to as a base station) and/or to receive communications through transceiver circuitry301from a RAN node over a radio interface. Moreover, modules may be stored in memory circuitry305, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry303, processing circuitry303performs respective operations (e.g., operations discussed below with respect to Example Embodiments relating to wireless communication devices). According to some embodiments, a communication device100and/or an element(s)/function(s) thereof may be embodied as a virtual node/nodes and/or a virtual machine/machines.

FIG.4is a block diagram illustrating elements of a access and mobility management function, AMF, function/node106(also referred to as a network node, base station, eNodeB/eNB, gNodeB/gNB, etc.) of a Radio Access Network (RAN) configured to provide cellular communication according to embodiments of inventive concepts. (AMF function/node106may be provided, for example, as discussed below with respect to network node4160ofFIG.18.) As shown, the AMF function/node106may include transceiver circuitry401(also referred to as a transceiver, e.g., corresponding to portions of interface4190ofFIG.18) including a transmitter and a receiver configured to provide uplink and downlink radio communications with mobile terminals. The AMF function/node106may include network interface circuitry407(also referred to as a network interface, e.g., corresponding to portions of interface4190ofFIG.18) configured to provide communications with other nodes (e.g., with other base stations) of the RAN and/or core network CN. The network node may also include processing circuitry403(also referred to as a processor, e.g., corresponding to processing circuitry4170) coupled to the transceiver circuitry, and memory circuitry405(also referred to as memory, e.g., corresponding to device readable medium4180ofFIG.18) coupled to the processing circuitry. The memory circuitry405may include computer readable program code that when executed by the processing circuitry403causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry403may be defined to include memory so that a separate memory circuitry is not required.

As discussed herein, operations of the AMF function/node106may be performed by processing circuitry403, network interface407, and/or transceiver401. For example, processing circuitry403may control transceiver401to transmit downlink communications through transceiver401over a radio interface to one or more mobile terminals UEs and/or to receive uplink communications through transceiver401from one or more mobile terminals UEs over a radio interface. Similarly, processing circuitry403may control network interface407to transmit communications through network interface407to one or more other network nodes and/or to receive communications through network interface from one or more other network nodes. Moreover, modules may be stored in memory405, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry403, processing circuitry403performs respective operations (e.g., operations discussed below with respect to Example Embodiments relating to RAN nodes). According to some embodiments, AMF function/node106and/or an element(s)/function(s) thereof may be embodied as a virtual node/nodes and/or a virtual machine/machines.

According to some other embodiments, a AMF function/node106may be implemented as a core network CN node without a transceiver. In such embodiments, transmission to a communication device may be initiated by the network node so that transmission to the communication device is provided through a network node including a transceiver (e.g., through a base station or RAN node). According to embodiments where the network node is a AMF function/node106including a transceiver, initiating transmission may include transmitting through the transceiver.

FIG.5is a block diagram illustrating elements of a unified data management, UDM function/node108(also referred to as a network node, base station, eNodeB/eNB, gNodeB/gNB, etc.) of a Radio Access Network (RAN) configured to provide cellular communication according to embodiments of inventive concepts. As shown, the UDM function/node108may include transceiver circuitry501(also referred to as a transceiver) including a transmitter and a receiver configured to provide uplink and downlink radio communications with mobile terminals. The UDM function/node108may include network interface circuitry507(also referred to as a network interface) configured to provide communications with other nodes (e.g., with other base stations) of the RAN and/or core network CN. The UDM function/node may also include processing circuitry503(also referred to as a processor) coupled to the transceiver circuitry, and memory circuitry505(also referred to as memory, e.g., a device readable medium) coupled to the processing circuitry. The memory circuitry505may include computer readable program code that when executed by the processing circuitry503causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry503may be defined to include memory so that a separate memory circuitry is not required.

As discussed herein, operations of the UDM function/node108may be performed by processing circuitry503, network interface507, and/or transceiver501. For example, processing circuitry503may control transceiver501to transmit downlink communications through transceiver501over a radio interface to one or more mobile terminals UEs and/or to receive uplink communications through transceiver501from one or more mobile terminals UEs over a radio interface. Similarly, processing circuitry503may control network interface507to transmit communications through network interface507to one or more other network nodes and/or to receive communications through network interface from one or more other network nodes. Moreover, modules may be stored in memory505, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry503, processing circuitry503performs respective operations (e.g., operations discussed below with respect to Example Embodiments relating to UDM function/nodes). According to some embodiments, UDM function/node108and/or an element(s)/function(s) thereof may be embodied as a virtual node/nodes and/or a virtual machine/machines.

FIG.6is a block diagram illustrating elements of a network function repository function, NRF, function/node112of a Radio Access Network (RAN) configured to provide cellular communication according to embodiments of inventive concepts. As shown, the NRF function/node112may include transceiver circuitry601(also referred to as a transceiver) including a transmitter and a receiver configured to provide uplink and downlink radio communications with mobile terminals. The NRF function/node112may include network interface circuitry607(also referred to as a network interface) configured to provide communications with other nodes (e.g., with other base stations) of the RAN and/or core network CN. The network node may also include processing circuitry603(also referred to as a processor) coupled to the transceiver circuitry, and memory circuitry605(also referred to as memory) coupled to the processing circuitry. The memory circuitry605may include computer readable program code that when executed by the processing circuitry603causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry603may be defined to include memory so that a separate memory circuitry is not required.

As discussed herein, operations of the NRF function/node112may be performed by processing circuitry603, network interface607, and/or transceiver601. For example, processing circuitry603may control transceiver601to transmit downlink communications through transceiver601over a radio interface to one or more mobile terminals UEs and/or to receive uplink communications through transceiver601from one or more mobile terminals UEs over a radio interface. Similarly, processing circuitry603may control network interface607to transmit communications through network interface607to one or more other network nodes and/or to receive communications through network interface from one or more other network nodes. Moreover, modules may be stored in memory605, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry603, processing circuitry603performs respective operations (e.g., operations discussed below with respect to Example Embodiments relating to NRF function/nodes). According to some embodiments, AMF function/node112and/or an element(s)/function(s) thereof may be embodied as a virtual node/nodes and/or a virtual machine/machines.

As previously indicated, the NRF is contacted each and every time by the consumer NR (e.g., UDM) to fetch the list of target instances (service producers) for each and every SUPI. Even for stateful NFs (e.g., an AMF) storing the GroupId for the SUPI, if the wireless device (e.g., UE) is de-registered, then NRF is contacted again when the wireless device registers again in the network to discover the NF instances serving the SUPI. The contacting of the NRF each and every time makes the signaling complex and non-efficient since the NRF is forced to perform SUPI ranges lookup/matching for any NF consumer discovering the NF instances per every request. This is done for each and every SUPI in the network.

Additionally, the size of the NF profiles to be registered can be dramatically large if there are a lot of SUPI ranges. For example, some operators like China Mobile are known to have around 5,000 SUPI ranges per UDM/UDR groups. For each and every request, the NF consumer (e.g. AMF, UDM) is forced to perform SUPI ranges lookup against each and every NF profile discovered, to build a list of selectable target NFs (NF service producers). This is done on a per request received basis. Overall, this requires a lot of storage in NRF, a lot of cache memory in AMF to host all NF instances including all the SUPI ranges registered by each NF. Moreover, the impacts in performance/computing when it comes to performing lookups with thousands of ranges can be dramatic. If there are, e.g. 20 NF instances, each registering 5.000 SUPI ranges in its profile, that makes 100.000 SUPI ranges to lookup before deciding the target NF instance to send the request. This is done for each and every request to be sent.

Various embodiments of inventive concepts address these problems. For example, in some embodiments, an information/attribute is added in to the NF profile to indicate that NRF hosts the SUPI ranges mapping to the GroupId configured in the NF profile. This new information is registered in NRF with the corresponding API/interface update.

In other embodiments, progressive discovery can be done in the network by adding a new application program interface (API/interface) (or, in some embodiments, by extending the existing API/interface) to be offered by NRF so that the NF consumers can discover in a progressive manner the SUPI ranges configured in NRF as soon as they are needed. This substantially decreases the signaling (to almost zero) between NF consumer and NRF when the ranges are already discovered, since the NF consumer can perform the SUPI lookups locally, without the need to contact NRF every time. The API can offer the possibility of subscribing to changes in the SUPI ranges managed by the GroupId. The corresponding subscription can indicate that both added/deleted ranges are to be notified (that is, any change in the ranges) or just the deleted ranges are to be notified (since the added ranges will be discovered progressively when needed (i.e. when a SUPI falling within the new range is received by the NF consumer)

GroupID definition and handling are performed at network level (instead of at NF level). The Group Id concept is extended to include more than one NF type, so that two different NFs (e.g. UDM and UDR) are grouped together. This solves the performance issues in purely segmented networks per SUPI ranges, since no SUPI lookup at all is perform when determining and selecting the target NF instance, e.g. UDM is selecting UDR simply based on the matching GroupId between UDM instance and UDR instances, regardless of the SUPI received.

Advantages that may be achieved using the various embodiments of inventive concepts described herein include a substantial reduction of OAM/OPEX when configuring and planning the network deployment, since as soon as a range is to be added/deleted for a GroupId, it is only done in the NRF (and not in each and every NF profile instance in the network). Such modifications are now spread in the network and all the NFs needing the information will be aware, so that the ranges are quickly known by all related NFs even though they were configured in a single NF. In short: NRF and its associated network automation is still kept in its essence. NRF is acting as a repository function for information which can be discovered, cached and used, and at the same time making sure that the cache always keeps the most up-to-date SUPI ranges.

Another advantage that may be achieved is a reduction in the size of responses from NRF, since the ranges are discovered reactively, as soon as they are needed, that is, progressively. The new API may offer the possibility to discover all ranges for the GroupId in a single request/response, but this is not recommended since the NF consumer might receive thousands of ranges, and many of them might not be needed in the short/medium/large time.

A further advantage that may be achieved is an improvement in performance/computing. The NF consumers fetch the SUPI ranges when they are needed, since for every range discovered and cache, every SUPI received must be matched against the cached ranges for each group. This results in the lookups being much faster if only a subset of the ranges is cached, saving also storage in the NF consumer, since instead of storing all ranges per NF profile instance, the NF consumer stores a single copy of the ranges per Group of NF instances.

The SUPI lookups in essential NFs like UDM, PCF, etc. in may deployments may be reduced to zero or near zero by setting the UDMs/UDRs in clusters/groups by applying the GroupId concept to a higher level than NF level.

Memory consumption and footprint may be reduces in all NFs (except NRF) by storing just Group Identifiers instead of SUPI ranges per NF profile. The inventive concepts allows this saving but at the same time gets rid of the huge cons of alternative1described above, since the NRF is not contacted to perform a SUPI lookup per each and every request received by each and every NF in the network using the inventive concepts described herein.

FIGS.7A-7Dare a signaling diagram illustrating various embodiments of inventive concepts. Turning toFIG.7A, in operations1-3, the UDM108instance registers its NF profile into the NRF112. The registering provides a GroupId associated with the NF profile. The NF profile includes a new attribute to be registered/published in the network, so NF consumers are aware that mapping of the GroupId <->SUPI ranges served by the NF instance is performed by the NRF112. That is, the NF consumer will know that progressive discovery of the ranges for the group can be performed.

In operations4-6, the UDR110instance registers its NF profile into the NRF112just as the UDM108instance registered.

In operation7, communication device100initiates a registration towards the 5GC network. This involves the AMF106. In operations8-10, the AMF106needs to contact a UDM108to manage the communication device100registration. To discover which UDM(s) can serve the request for the related SUPI, the AMF106performs a query towards NRF. The query includes the target NF type (in this case, UDM) and the SUPI. The NRF112performs a SUPI lookup, finds the associated GroupId for the SUPI range matching the SUPI, and returns all UDMs which registered the same GroupId. Each UDM instance profile returned indicates (in addition to the GroupId) that the GroupId mapping is hosted in the NRF112. This will allow the AMF106to progressively learn the network configuration to avoid continuous requests towards the NRF112for SUPIs under the same SUPI range/GroupId just managed.

Turning toFIG.7B, in operation11, the AMF stores received information (if not available in its cache), that is, the association between the GroupId and the list of UDM instances belonging to the group identified by the GroupId.

In operations12-15, since the NF profiles include the indication about the NRF112providing the mapping, the AMF106performs a new request to discover the SUPI range just matched by the NRF (instead of all SUPI ranges for the GroupId) for the SUPI/GroupId/NF type (UDM). Thus, the AMF106transmits a Group ID Discovery request to the NRF112where the Group Id Discovery request includes a GroupID, the SUPI-1 identifier, and an indication that the request is for only SUPI ranges matched. The NRF112, since the NRF112has received the indication to return only the SUPI range matching the SUPI-1 identifier instead of all SUPI ranges for the group having the GroupId, the NRF112responds in operation15and includes just the SUPI range matched to the SUPI-1.

Turning toFIG.7C, in operation16the SUPI range returned by the NRF112is stored by the AMF106locally in an AMF cache, that is, the range is added to the GroupId information (which already contains the list of UDM instances). The AMF106thus has learned that, for every SUPI within such range, it can select any UDM within the related group, without the need to contact the NRF112at all. This will be done progressively whenever is required, i.e. whenever a new SUPI lands at the AMF106, if not within the range of any UDM group stored, steps8-16are performed, since it is expected that more SUPIs within the same range will land at the AMF in a near future.NOTE 1: it must be noted that, although an extra query is required to NRF112to discover the SUPI range just matched, this is done just once. As an example, if a range contains 100K SUPIs, it is just one query out of 100K. Before inventive concepts provided herein, the NRF112was contacted 100K times to return the same GroupId for the 100K SUPIs.NOTE 2: As an optimization, the NRF112can return the SUPI range matched in step10, so that the AMF106learns from the response both the GroupId and the SUPI range in one shot. However, although it saves the query in step13, this breaks the Service Based interface (SBI) principles in 5GC, since this information is not part of an NF profile instance, but part of a Group of NFs. Note that changes in the ranges of the Group (seeFIG.7) need to be notified separately from changes in the NF profile of an NF instance.

In operation17, the AMF106transmits a UE initial registration request to the UDM108. In operation18, when the UDM108receives the registration request from the AMF106, the UDM108selects a UDR110with the same exact GroupId as the UDM108. Zero SUPI lookups are performed and the NRF112is not contacted at all. Thus, since the UDM108belongs to a GroupId, no matter the SUPI received, the UDM108selects one of the UDRs110having registered in the NRF112(as part of the UDR NF profile) with the same GroupID the UDM108belongs to. The registration data is stored in the UDR110. In operation19, the AMF106receives information on the UDR110selected by the UDM108.NOTE 3: It is assumed that UDM108performed an initial discovery of UDRs (e.g. at startup/instantiation) and, when detecting that there are UDRs profiles returned by the NRF112with the same GroupId of the UDM108, only those UDRs are stored/cached, and the rest are discarded.NOTE 4: It must be noted that the inventive concepts extends the concept of the GroupId per NF type, e.g. currently, as defined in 3GPP, the GroupId is NF level concept, e.g.UDR-instance-1 GroupId=“udr-north-region”UDR-instance-2 GroupId=“udr-north-region”UDR-instance-3 GroupId=“udr-east-region”UDR-instance-4 GroupId=“udr-east-region”UDM-instance-1 GroupId=“udm-east-region”UDM-instance-2 GroupId=“udm-east-region”UDM-instance-3 GroupId=“udm-north-region”UDM-instance-4 GroupId=“udm-north-region”

The inventive concepts enables the GroupId to be shared across different NF types (i.e. to be global), e.g.UDR-instance-1 GroupId=“north-region”UDR-instance-2 GroupId=“north-region”UDR-instance-3 GroupId=“east-region”UDR-instance-4 GroupId=“east-region”UDM-instance-1 GroupId=“east-region”UDM-instance-2 GroupId=“east-region”UDM-instance-3 GroupId=“north-region”UDM-instance-4 GroupId=“north-region”

This extended concept/behavior results in an optimal performance and grouping, since the UDM/UDR are grouped together, so that UDM always selects UDRs from the same group (e.g. UDMs in the north region only select UDRs in the north region, with no SUPI lookup involved at all).

In operation20, the AMF106stores the GroupID as associated to the SUPI-1 as part of the AMF context data for the communication device100.

In operation21, the process of operations7-15are repeated whenever a SUPI not falling within the range of cached ranges in the AMF106for the cached Group information is received. After operation21, the AMF106should have information per UDM group similar to:

The AMF106should also have information per UE context/SUPI similar to:SUPI-1->GroupId “north region”SUPI-2->GroupId “east region

Turning toFIG.7D, in operation22, the AMF106receives a registration from communication device103having SUPI-3 identification. The AMF106performs a lookup in its cache to check whether or no SUPI-3 falls within SUPI-range-1 or SUPI-range-2. Assume that a match is found with SUPI-range-2. The AMF106will select a UDM108from the Group-Id associated to SUPI-range-2. The NRF112is not contacted at all.

In operation23, the AMF106detects a change in the permanent equipment identifier (PEI) (e.g. a change in IMEISV (international mobile equipment identity software version).

In operation24, since a GroupId is found in the communication device101context stored in the AMF106, and the AMF has stored the GroupId information with the list of selectable UDMs (and the associated SUPI ranges), the AMF106selects any UDM belonging to the GroupID stored for SUPI-1. In operation25, the AMF106sends a registration other ion update to the UDM108where the registration update includes the SUPI-1 and the IMEISV. In other words, for a subsequent request of a registered SUPI, the AMF160acts as normal, that is, it fetches the stored GroupId for the SUPI.

In operation26, the UDM108selects a UDR as in operation18no matter the SUPI received. Thus, the UDM again performs zero SUPI lookups and zero NRF queries due to the shared/global GroupId concept.

Turning toFIG.7, a signaling diagram illustrating operations of an AMF and NRF according to some embodiments of inventive concepts where the AMF106subscribes to notifications about GroupId changes in the NRF11. This allows the NF consumer to subscribe to changes in the GroupId ranges in NRF, but with a particular/new option to request notifications only when ranges are removed from a GroupId. If ranges are added, there is no need to notify the NF service consumer since the new range will be learned when the time comes, i.e. when the first SUPI within the new range lands at the NF service consumer.

In operations1-2, the AMF106transmits a GroupId subscribe request to the NRF112and receives an acknowledgement. The GroupId subscribe request indicates that the AMF106only want to be notified only when ranges are removed.

In operation3, a SUPI is added to the GroupId. No notification is sent since the AMF106will discover the added range such as when the first SUPI with the added range arrives at the AMF106.

In operation4, a SUPI range is removed from a GroupID. This requires a notification since the AMF106needs to delete the SUPI range from the GroupId cached information so that the removed SUPI range is no longer associated with the group of UDMs.

In operations5-6, the AMF106receives from the NRF112and acknowledges a GroupId Notify message that provides a GroupId and the removed SUPI range.

In operation7, the AMF106removes the SUPI range from the GroupId in cached memory.

Operations of the network function repository function, NRF, function/node (112) (implemented using the structure of the block diagram ofFIG.6) will now be discussed with reference to the flow chart ofFIG.9according to some embodiments of inventive concepts. For example, modules may be stored in memory605ofFIG.6, and these modules may provide instructions so that when the instructions of a module are executed by respective NRF function/node processing circuitry603, processing circuitry603performs respective operations of the flow chart.

Turning toFIG.9, in block901, the processing circuitry603receives a network function, NF, discovery request from an access and mobility management function, AMF, function/node106, the NF discovery request having a communication device identifier and a NF type identifier. The NF type identifier identifies the type of network function. An example of NF types are UDM network functions, UDR network functions, AMF network functions, etc.

The communication device identifier in various embodiments is a subscription permanent identifier (SUPI). Other device identifiers may be used as discussed above.

In block903, the processing circuitry603matches the communication device identifier with one of a plurality of communication device identifier ranges configured by the NRF function/node112. In block905, the processing circuitry603extracts a group identifier (e.g., groupId) configured for the one of the plurality of communication device identifier ranges.

In block907, the processing circuitry603builds a list of registered NF profiles matching the NF type identifier and registered with the groupId.

The NF profiles are registered by network functions. For example, network functions such as UDM function/nodes108, UDR function/nodes110, etc.FIG.10illustrates an embodiment of registering.

Turning toFIG.10, in block1001, the processing circuitry603receives a first registration, from a first network function/node (such as UDM function/node108or UDR function/node110), for a network function, NF, profile which includes the groupId, and the NRF mapping indication that the mapping of communication device identifier ranges to the groupId is performed by the NRF function/node116.

In block1003, the processing circuitry603receives a second registration, from a second network function/node (such as UDM function/node108or UDR function/node110), for a NF profile which includes the groupId, and the NRF mapping, wherein a NF type of the first network function/node is a different NF type than the NF type of the second network function/node. For example the UDM function is a different NF type than the UDR function.

In block1005, the processing circuitry603publishes an indication towards a NF consumer indicating that further routing information can be provided related to a received communication device identifier.

Returning toFIG.9, in block909, the processing circuitry603transmits the list of registered NF profiles including the groupId and a NRF mapping indication to the AMF function/node106.

The NRF function/node112also receives group ID discovery request from network function/nodes. Turning toFIG.11, in block1101, the processing circuitry603receives a groupId discovery request from the AMF function/node (106), the groupId discovery request including the groupId, the communication device identifier, and an indication that only communication device identifier ranges having the communication device identifier is to be provided.

In block1103, the processing circuitry603provides a response to the AMF function/node106, the response including just the communication device identifier ranges matched to the communication device identifier.

The AMF function/node may want to be notified of changes to the group ID so that its memory cache stays up to date as described above. Turning toFIG.12, one way to be notified of changes is to subscribe to notifications.

In block1201, the processing circuitry603receives a groupId subscribe request from the AMF function/node106, the groupId subscribe request requesting that notifications be sent only from removed communication device ranges. This indicates that the AMF function/node106is not interested in additions as there may be no need to notify the NF service consumer since the new range will be learned when the time comes, i.e. when the first SUPI within the new range arrives at the NF service consumer. Thus, in block1203, the processing circuitry603may add a communication device range to the groupId without providing a notification to the AMF function/node106. In other embodiments, the AMF function/nodes106may want to also subscribe to notifications when a communication device range is added. In these embodiments, the processing circuitry603provides a notification to the AMF function/node when a communication device range is added to the groupId.

In block1205, responsive to removing a communication device range to the groupId, the processing circuitry603provides a notification to the AMF function/node106that includes the groupId, and an identification of the communication device range(s) removed.

Operations of an AMF function/node106(implemented using the structure ofFIG.4) will now be discussed with reference to the flow chart ofFIG.13according to some embodiments of inventive concepts. For example, modules may be stored in memory405ofFIG.4, and these modules may provide instructions so that when the instructions of a module are executed by respective AMF function/node processing circuitry403, processing circuitry403performs respective operations of the flow chart.

Turning toFIG.13, responsive to receiving an initial registration request from a communication device100, the processing circuitry403, in block1301, transmits a network function, NF, discovery request to a network function repository function, NRF, node112, the NF discovery request comprising a communication device identifier and a NF type identifier.

In block1303, the processing circuitry403receives a list of registered NF profiles including the groupId and a NRF mapping indication indicating that the mapping of communication device identifier ranges to the groupId is performed by the NRF node.

In block1305, the processing circuitry403stores the groupId associated to the communication device identifier as part of AMF context data for the communication device.

Various operations from the flow chart ofFIG.13may be optional with respect to some embodiments of RAN nodes and related methods. Regarding methods of example embodiment 10 (set forth below), for example, operations of blocks1305ofFIG.13may be optional.

As previously indicated, the AMF function/node106may want to know when a change to a groupId is made. Turning toFIG.14, an embodiment of subscribing to notifications is illustrated. In block1401, the processing circuitry403transmits a groupId subscribe request to the NRF function/node (112), the groupId subscribe request requesting that notifications be sent only from removed communication device ranges. In other embodiments, the processing circuitry403may also request notifications be sent when communication device ranges are added.

In block1403, the processing circuitry403receives a notification from the NRF function/node112that includes the groupId, and an identification of the communication device range(s) removed. In block1405, the processing circuitry403removes the communication device range (associated with the identification) from the groupId in cache memory.

Once the AMF function/node106receives the list of registered NF profiles, the AMF function/node106may not have to contact the NRF function/node112for subsequent registration of communication devices. Turning toFIG.15, in block1501, the processing circuitry403receives a registration request from a second communication device, the registration request include a second communication device identifier identifying the second communication device.

In block1503, the processing circuitry403performs a lookup in the cache memory for the second communication device identifier. Responsive to finding a match in one of one or more communication device ranges in the cache memory, the processing circuitry403in block1505selects a unified data management, UDM, function/node108belonging to the groupId for the one of the one or more communication device ranges for the second communication device. Thus, the AMF function/node selects a UDM function/node without contacting the NRF function/node112.

Operations of a unified data management, UDM, function/node108(implemented using the structure ofFIG.5) will now be discussed with reference to the flow chart ofFIG.16according to some embodiments of inventive concepts. For example, modules may be stored in memory505ofFIG.5, and these modules may provide instructions so that when the instructions of a module are executed by respective UDM function/node processing circuitry503, processing circuitry503performs respective operations of the flow chart.

Turning toFIG.16, in block1601, the processing circuitry503receives from an access and mobility management function, AMF, function/node106, a communication device initial registration having a communication device identifier.

In block1603, the processing circuitry503selects, regardless of the communication device identifier, one of one or more user and data repository, UDR, function/nodes (110) registered in the NRF function/node (112) having a same group identifier, groupId, as the groupId of the UDM. In block1605, the processing circuitry503transmits to the AMF function/node (106) a registration acknowledgement having the groupId and an indication of the one of the one or more UDR function/nodes108.

In order for the UDM function/node108to select the UDR function/node, the UDM function/node108needs to register with the NRF function/node112. Turning toFIG.17, in block1701, the processing circuitry503transmits a registration request to the NRF function/node112, the registration request for a network function, NF, profile which includes the groupId, and a NRF mapping indication that the mapping of communication device identifier ranges to the groupId is performed by the NRF function/node. In block1703, the processing circuitry503receives a registration acknowledgment from the NRF function/node.

Thus, as can be seen, a method for routing requests associated to a 5GC user by progressive discovery of the deployment has been described. Between a NF and NRF, a new attribute is published (via extended NRF API) in the NF profile indicating that mapping of SUPI ranges information is centralized in the NRF.

Between a NF consumer and NRF, an indication (extension) in the NRF API towards NF consumer indicating that further routing information can be provided related to received user (SUPI) is provided. A new/extended API offered by NRF API and consumed by all NF consumers allows the NF consumers to request for further routing information related to a user (SUPI) and its related SUPI range, process known as progressive learning only the traffic requires it.

Additionally, a new/extended API to request notification for changes in the GroupId ranges in NRF, by indicating additionally that either all modifications (addition/deletion of ranges) are to be notified, or only deleted ranges are required (to assist the progressive discovery of the newly added ranges) is provided.

Inside a NF consumer, a method in the NF consumer to cache this routing information learned and use it for all SUPIs under same SUPI range is provided. Another method in the NF consumer applies a wider concept of GroupId shared across different NF types to avoid SUPI lookups in purely segmented/clustered networks. Another method in the NF to know that same GroupId used for received SUPI is extensible for the UDR so no UDR discovery must be performed towards NRF.

Example embodiments are discussed below.

Explanations are provided below for various abbreviations/acronyms used in the present disclosure.

Additional explanation is provided below.

FIG.18illustrates a wireless network in accordance with some embodiments.

InFIG.18, network node4160includes processing circuitry4170, device readable medium4180, interface4190, auxiliary equipment4184, power source4186, power circuitry4187, and antenna4162. Although network node4160illustrated in the example wireless network ofFIG.18may represent a device that includes the illustrated combination of hardware components, other embodiments may comprise network nodes with different combinations of components. It is to be understood that a network node comprises any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Moreover, while the components of network node4160are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, a network node may comprise multiple different physical components that make up a single illustrated component (e.g., device readable medium4180may comprise multiple separate hard drives as well as multiple RAM modules).

Processing circuitry4170may 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 network node4160components, such as device readable medium4180, network node4160functionality. For example, processing circuitry4170may execute instructions stored in device readable medium4180or in memory within processing circuitry4170. Such functionality may include providing any of the various wireless features, functions, or benefits discussed herein. In some embodiments, processing circuitry4170may include a system on a chip (SOC).

In some embodiments, processing circuitry4170may include one or more of radio frequency (RF) transceiver circuitry4172and baseband processing circuitry4174. In some embodiments, radio frequency (RF) transceiver circuitry4172and baseband processing circuitry4174may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry4172and baseband processing circuitry4174may be on the same chip or set of chips, boards, or units.

In certain embodiments, some or all of the functionality described herein as being provided by a network node, base station, eNB or other such network device may be performed by processing circuitry4170executing instructions stored on device readable medium4180or memory within processing circuitry4170. In alternative embodiments, some or all of the functionality may be provided by processing circuitry4170without executing instructions stored on a separate or discrete device readable medium, such as in a hard-wired manner. In any of those embodiments, whether executing instructions stored on a device readable storage medium or not, processing circuitry4170can be configured to perform the described functionality. The benefits provided by such functionality are not limited to processing circuitry4170alone or to other components of network node4160, but are enjoyed by network node4160as a whole, and/or by end users and the wireless network generally.

Device readable medium4180may 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 processing circuitry4170. Device readable medium4180may store any suitable instructions, data or information, including a computer program, software, an application including one or more of logic, rules, code, tables, etc. and/or other instructions capable of being executed by processing circuitry4170and, utilized by network node4160. Device readable medium4180may be used to store any calculations made by processing circuitry4170and/or any data received via interface4190. In some embodiments, processing circuitry4170and device readable medium4180may be considered to be integrated.

Interface4190is used in the wired or wireless communication of signalling and/or data between network node4160, network4106, and/or WDs4110. As illustrated, interface4190comprises port(s)/terminal(s)4194to send and receive data, for example to and from network4106over a wired connection. Interface4190also includes radio front end circuitry4192that may be coupled to, or in certain embodiments a part of, antenna4162. Radio front end circuitry4192comprises filters4198and amplifiers4196. Radio front end circuitry4192may be connected to antenna4162and processing circuitry4170. Radio front end circuitry may be configured to condition signals communicated between antenna4162and processing circuitry4170. Radio front end circuitry4192may receive digital data that is to be sent out to other network nodes or WDs via a wireless connection. Radio front end circuitry4192may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters4198and/or amplifiers4196. The radio signal may then be transmitted via antenna4162. Similarly, when receiving data, antenna4162may collect radio signals which are then converted into digital data by radio front end circuitry4192. The digital data may be passed to processing circuitry4170. In other embodiments, the interface may comprise different components and/or different combinations of components.

In certain alternative embodiments, network node4160may not include separate radio front end circuitry4192, instead, processing circuitry4170may comprise radio front end circuitry and may be connected to antenna4162without separate radio front end circuitry4192. Similarly, in some embodiments, all or some of RF transceiver circuitry4172may be considered a part of interface4190. In still other embodiments, interface4190may include one or more ports or terminals4194, radio front end circuitry4192, and RF transceiver circuitry4172, as part of a radio unit (not shown), and interface4190may communicate with baseband processing circuitry4174, which is part of a digital unit (not shown).

Antenna4162, interface4190, and/or processing circuitry4170may be configured to perform any receiving operations and/or certain obtaining operations described herein as being performed by a network node. Any information, data and/or signals may be received from a wireless device, another network node and/or any other network equipment. Similarly, antenna4162, interface4190, and/or processing circuitry4170may be configured to perform any transmitting operations described herein as being performed by a network node. Any information, data and/or signals may be transmitted to a wireless device, another network node and/or any other network equipment.

Power circuitry4187may comprise, or be coupled to, power management circuitry and is configured to supply the components of network node4160with power for performing the functionality described herein. Power circuitry4187may receive power from power source4186. Power source4186and/or power circuitry4187may be configured to provide power to the various components of network node4160in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). Power source4186may either be included in, or external to, power circuitry4187and/or network node4160. For example, network node4160may be connectable to an external power source (e.g., an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry4187. As a further example, power source4186may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry4187. The battery may provide backup power should the external power source fail. Other types of power sources, such as photovoltaic devices, may also be used.

Alternative embodiments of network node4160may include additional components beyond those shown inFIG.18that may be responsible for providing certain aspects of the network node's functionality, including any of the functionality described herein and/or any functionality necessary to support the subject matter described herein. For example, network node4160may include user interface equipment to allow input of information into network node4160and to allow output of information from network node4160. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for network node4160.

As illustrated, wireless device4110includes antenna4111, interface4114, processing circuitry4120, device readable medium4130, user interface equipment4132, auxiliary equipment4134, power source4136and power circuitry4137. WD4110may include multiple sets of one or more of the illustrated components for different wireless technologies supported by WD4110, such as, for example, GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies, just to mention a few. These wireless technologies may be integrated into the same or different chips or set of chips as other components within WD4110.

Antenna4111may include one or more antennas or antenna arrays, configured to send and/or receive wireless signals, and is connected to interface4114. In certain alternative embodiments, antenna4111may be separate from WD4110and be connectable to WD4110through an interface or port. Antenna4111, interface4114, and/or processing circuitry4120may be configured to perform any receiving or transmitting operations described herein as being performed by a WD. Any information, data and/or signals may be received from a network node and/or another WD. In some embodiments, radio front end circuitry and/or antenna4111may be considered an interface.

As illustrated, interface4114comprises radio front end circuitry4112and antenna4111. Radio front end circuitry4112comprise one or more filters4118and amplifiers4116. Radio front end circuitry4112is connected to antenna4111and processing circuitry4120, and is configured to condition signals communicated between antenna4111and processing circuitry4120. Radio front end circuitry4112may be coupled to or a part of antenna4111. In some embodiments, WD4110may not include separate radio front end circuitry4112; rather, processing circuitry4120may comprise radio front end circuitry and may be connected to antenna4111. Similarly, in some embodiments, some or all of RF transceiver circuitry4122may be considered a part of interface4114. Radio front end circuitry4112may receive digital data that is to be sent out to other network nodes or WDs via a wireless connection. Radio front end circuitry4112may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters4118and/or amplifiers4116. The radio signal may then be transmitted via antenna4111. Similarly, when receiving data, antenna4111may collect radio signals which are then converted into digital data by radio front end circuitry4112. The digital data may be passed to processing circuitry4120. In other embodiments, the interface may comprise different components and/or different combinations of components.

Processing circuitry4120may 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 WD4110components, such as device readable medium4130, WD4110functionality. Such functionality may include providing any of the various wireless features or benefits discussed herein. For example, processing circuitry4120may execute instructions stored in device readable medium4130or in memory within processing circuitry4120to provide the functionality disclosed herein.

As illustrated, processing circuitry4120includes one or more of RF transceiver circuitry4122, baseband processing circuitry4124, and application processing circuitry4126. In other embodiments, the processing circuitry may comprise different components and/or different combinations of components. In certain embodiments processing circuitry4120of WD4110may comprise a SOC. In some embodiments, RF transceiver circuitry4122, baseband processing circuitry4124, and application processing circuitry4126may be on separate chips or sets of chips. In alternative embodiments, part or all of baseband processing circuitry4124and application processing circuitry4126may be combined into one chip or set of chips, and RF transceiver circuitry4122may be on a separate chip or set of chips. In still alternative embodiments, part or all of RF transceiver circuitry4122and baseband processing circuitry4124may be on the same chip or set of chips, and application processing circuitry4126may be on a separate chip or set of chips. In yet other alternative embodiments, part or all of RF transceiver circuitry4122, baseband processing circuitry4124, and application processing circuitry4126may be combined in the same chip or set of chips. In some embodiments, RF transceiver circuitry4122may be a part of interface4114. RF transceiver circuitry4122may condition RF signals for processing circuitry4120.

Processing circuitry4120may be configured to perform any determining, calculating, or similar operations (e.g., certain obtaining operations) described herein as being performed by a WD. These operations, as performed by processing circuitry4120, may include processing information obtained by processing circuitry4120by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored by WD4110, 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.

Device readable medium4130may be operable to store a computer program, software, an application including one or more of logic, rules, code, tables, etc. and/or other instructions capable of being executed by processing circuitry4120. Device readable medium4130may include computer memory (e.g., Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (e.g., a hard disk), removable storage media (e.g., 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 processing circuitry4120. In some embodiments, processing circuitry4120and device readable medium4130may be considered to be integrated.

User interface equipment4132may provide components that allow for a human user to interact with WD4110. Such interaction may be of many forms, such as visual, audial, tactile, etc. User interface equipment4132may be operable to produce output to the user and to allow the user to provide input to WD4110. The type of interaction may vary depending on the type of user interface equipment4132installed in WD4110. For example, if WD4110is a smart phone, the interaction may be via a touch screen; if WD4110is a smart meter, the interaction may be through a screen that provides usage (e.g., the number of gallons used) or a speaker that provides an audible alert (e.g., if smoke is detected). User interface equipment4132may include input interfaces, devices and circuits, and output interfaces, devices and circuits. User interface equipment4132is configured to allow input of information into WD4110, and is connected to processing circuitry4120to allow processing circuitry4120to process the input information. User interface equipment4132may include, for example, a microphone, a proximity or other sensor, keys/buttons, a touch display, one or more cameras, a USB port, or other input circuitry. User interface equipment4132is also configured to allow output of information from WD4110, and to allow processing circuitry4120to output information from WD4110. User interface equipment4132may include, for example, a speaker, a display, vibrating circuitry, a USB port, a headphone interface, or other output circuitry. Using one or more input and output interfaces, devices, and circuits, of user interface equipment4132, WD4110may communicate with end users and/or the wireless network, and allow them to benefit from the functionality described herein.

Power source4136may, in some embodiments, be in the form of a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic devices or power cells, may also be used. WD4110may further comprise power circuitry4137for delivering power from power source4136to the various parts of WD4110which need power from power source4136to carry out any functionality described or indicated herein. Power circuitry4137may in certain embodiments comprise power management circuitry. Power circuitry4137may additionally or alternatively be operable to receive power from an external power source; in which case WD4110may be connectable to the external power source (such as an electricity outlet) via input circuitry or an interface such as an electrical power cable. Power circuitry4137may also in certain embodiments be operable to deliver power from an external power source to power source4136. This may be, for example, for the charging of power source4136. Power circuitry4137may perform any formatting, converting, or other modification to the power from power source4136to make the power suitable for the respective components of WD4110to which power is supplied.

FIG.19illustrates a user Equipment in accordance with some embodiments.

InFIG.19, UE4200includes processing circuitry4201that is operatively coupled to input/output interface4205, radio frequency (RF) interface4209, network connection interface4211, memory4215including random access memory (RAM)4217, read-only memory (ROM)4219, and storage medium4221or the like, communication subsystem4231, power source4213, and/or any other component, or any combination thereof. Storage medium4221includes operating system4223, application program4225, and data4227. In other embodiments, storage medium4221may include other similar types of information. Certain UEs may utilize all of the components shown inFIG.19, or only a subset of the components. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

RAM4217may be configured to interface via bus4202to processing circuitry4201to provide storage or caching of data or computer instructions during the execution of software programs such as the operating system, application programs, and device drivers. ROM4219may be configured to provide computer instructions or data to processing circuitry4201. For example, ROM4219may be configured to store invariant low-level system code or data for basic system functions such as basic input and output (I/O), startup, or reception of keystrokes from a keyboard that are stored in a non-volatile memory. Storage medium4221may be configured to include memory such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, floppy disks, hard disks, removable cartridges, or flash drives. In one example, storage medium4221may be configured to include operating system4223, application program4225such as a web browser application, a widget or gadget engine or another application, and data file4227. Storage medium4221may store, for use by UE4200, any of a variety of various operating systems or combinations of operating systems.

InFIG.19, processing circuitry4201may be configured to communicate with network4243busing communication subsystem4231. Network4243aand network4243bmay be the same network or networks or different network or networks. Communication subsystem4231may be configured to include one or more transceivers used to communicate with network4243b. For example, communication subsystem4231may be configured to include one or more transceivers used to communicate with one or more remote transceivers of another device capable of wireless communication such as another WD, UE, or base station of a radio access network (RAN) according to one or more communication protocols, such as IEEE 802.11, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax, or the like. Each transceiver may include transmitter4233and/or receiver4235to implement transmitter or receiver functionality, respectively, appropriate to the RAN links (e.g., frequency allocations and the like). Further, transmitter4233and receiver4235of each transceiver may share circuit components, software or firmware, or alternatively may be implemented separately.

The features, benefits and/or functions described herein may be implemented in one of the components of UE4200or partitioned across multiple components of UE4200. Further, the features, benefits, and/or functions described herein may be implemented in any combination of hardware, software or firmware. In one example, communication subsystem4231may be configured to include any of the components described herein. Further, processing circuitry4201may be configured to communicate with any of such components over bus4202. In another example, any of such components may be represented by program instructions stored in memory that when executed by processing circuitry4201perform the corresponding functions described herein. In another example, the functionality of any of such components may be partitioned between processing circuitry4201and communication subsystem4231. In another example, the non-computationally intensive functions of any of such components may be implemented in software or firmware and the computationally intensive functions may be implemented in hardware.

FIG.20illustrates a virtualization environment in accordance with some embodiments.

The functions may be implemented by one or more applications4320(which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) operative to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein. Applications4320are run in virtualization environment4300which provides hardware4330comprising processing circuitry4360and memory4390. Memory4390contains instructions4395executable by processing circuitry4360whereby application4320is operative to provide one or more of the features, benefits, and/or functions disclosed herein.

Virtualization environment4300, comprises general-purpose or special-purpose network hardware devices4330comprising a set of one or more processors or processing circuitry4360, which may be commercial off-the-shelf (COTS) processors, dedicated Application Specific Integrated Circuits (ASICs), or any other type of processing circuitry including digital or analog hardware components or special purpose processors. Each hardware device may comprise memory4390-1which may be non-persistent memory for temporarily storing instructions4395or software executed by processing circuitry4360. Each hardware device may comprise one or more network interface controllers (NICs)4370, also known as network interface cards, which include physical network interface4380. Each hardware device may also include non-transitory, persistent, machine-readable storage media4390-2having stored therein software4395and/or instructions executable by processing circuitry4360. Software4395may include any type of software including software for instantiating one or more virtualization layers4350(also referred to as hypervisors), software to execute virtual machines4340as well as software allowing it to execute functions, features and/or benefits described in relation with some embodiments described herein.

Virtual machines4340comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer4350or hypervisor. Different embodiments of the instance of virtual appliance4320may be implemented on one or more of virtual machines4340, and the implementations may be made in different ways.

During operation, processing circuitry4360executes software4395to instantiate the hypervisor or virtualization layer4350, which may sometimes be referred to as a virtual machine monitor (VMM). Virtualization layer4350may present a virtual operating platform that appears like networking hardware to virtual machine4340.

As shown inFIG.20, hardware4330may be a standalone network node with generic or specific components. Hardware4330may comprise antenna43225and may implement some functions via virtualization. Alternatively, hardware4330may be part of a larger cluster of hardware (e.g. such as in a data center or customer premise equipment (CPE)) where many hardware nodes work together and are managed via management and orchestration (MANO)43100, which, among others, oversees lifecycle management of applications4320.

In the context of NFV, virtual machine4340may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of virtual machines4340, and that part of hardware4330that executes that virtual machine, be it hardware dedicated to that virtual machine and/or hardware shared by that virtual machine with others of the virtual machines4340, forms a separate virtual network elements (VNE).

Still in the context of NFV, Virtual Network Function (VNF) is responsible for handling specific network functions that run in one or more virtual machines4340on top of hardware networking infrastructure4330and corresponds to application4320inFIG.20.

In some embodiments, one or more radio units43200that each include one or more transmitters43220and one or more receivers43210may be coupled to one or more antennas43225. Radio units43200may communicate directly with hardware nodes4330via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station.

In some embodiments, some signalling can be effected with the use of control system43230which may alternatively be used for communication between the hardware nodes4330and radio units43200.

With reference toFIG.21, in accordance with an embodiment, a communication system includes telecommunication network4410, such as a 3GPP-type cellular network, which comprises access network4411, such as a radio access network, and core network4414. Access network4411comprises a plurality of base stations4412a,4412b,4412c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area4413a,4413b,4413c. Each base station4412a,4412b,4412cis connectable to core network4414over a wired or wireless connection4415. A first UE4491located in coverage area4413cis configured to wirelessly connect to, or be paged by, the corresponding base station4412c. A second UE4492in coverage area4413ais wirelessly connectable to the corresponding base station4412a. While a plurality of UEs4491,4492are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station4412.

Telecommunication network4410is itself connected to host computer4430, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. Host computer4430may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. Connections4421and4422between telecommunication network4410and host computer4430may extend directly from core network4414to host computer4430or may go via an optional intermediate network4420. Intermediate network4420may be one of, or a combination of more than one of, a public, private or hosted network; intermediate network4420, if any, may be a backbone network or the Internet; in particular, intermediate network4420may comprise two or more sub-networks (not shown).

The communication system ofFIG.21as a whole enables connectivity between the connected UEs4491,4492and host computer4430. The connectivity may be described as an over-the-top (OTT) connection4450. Host computer4430and the connected UEs4491,4492are configured to communicate data and/or signaling via OTT connection4450, using access network4411, core network4414, any intermediate network4420and possible further infrastructure (not shown) as intermediaries. OTT connection4450may be transparent in the sense that the participating communication devices through which OTT connection4450passes are unaware of routing of uplink and downlink communications. For example, base station4412may not or need not be informed about the past routing of an incoming downlink communication with data originating from host computer4430to be forwarded (e.g., handed over) to a connected UE4491. Similarly, base station4412need not be aware of the future routing of an outgoing uplink communication originating from the UE4491towards the host computer4430.

Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference toFIG.22. In communication system4500, host computer4510comprises hardware4515including communication interface4516configured to set up and maintain a wired or wireless connection with an interface of a different communication device of communication system4500. Host computer4510further comprises processing circuitry4518, which may have storage and/or processing capabilities. In particular, processing circuitry4518may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. Host computer4510further comprises software4511, which is stored in or accessible by host computer4510and executable by processing circuitry4518. Software4511includes host application4512. Host application4512may be operable to provide a service to a remote user, such as UE4530connecting via OTT connection4550terminating at UE4530and host computer4510. In providing the service to the remote user, host application4512may provide user data which is transmitted using OTT connection4550.

Communication system4500further includes base station4520provided in a telecommunication system and comprising hardware4525enabling it to communicate with host computer4510and with UE4530. Hardware4525may include communication interface4526for setting up and maintaining a wired or wireless connection with an interface of a different communication device of communication system4500, as well as radio interface4527for setting up and maintaining at least wireless connection4570with UE4530located in a coverage area (not shown inFIG.22) served by base station4520. Communication interface4526may be configured to facilitate connection4560to host computer4510. Connection4560may be direct or it may pass through a core network (not shown inFIG.22) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, hardware4525of base station4520further includes processing circuitry4528, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. Base station4520further has software4521stored internally or accessible via an external connection.

Communication system4500further includes UE4530already referred to. Its hardware4535may include radio interface4537configured to set up and maintain wireless connection4570with a base station serving a coverage area in which UE4530is currently located. Hardware4535of UE4530further includes processing circuitry4538, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. UE4530further comprises software4531, which is stored in or accessible by UE4530and executable by processing circuitry4538. Software4531includes client application4532. Client application4532may be operable to provide a service to a human or non-human user via UE4530, with the support of host computer4510. In host computer4510, an executing host application4512may communicate with the executing client application4532via OTT connection4550terminating at UE4530and host computer4510. In providing the service to the user, client application4532may receive request data from host application4512and provide user data in response to the request data. OTT connection4550may transfer both the request data and the user data. Client application4532may interact with the user to generate the user data that it provides.

It is noted that host computer4510, base station4520and UE4530illustrated inFIG.22may be similar or identical to host computer4430, one of base stations4412a,4412b,4412cand one of UEs4491,4492ofFIG.21, respectively. This is to say, the inner workings of these entities may be as shown inFIG.22and independently, the surrounding network topology may be that ofFIG.21.

InFIG.22, OTT connection4550has been drawn abstractly to illustrate the communication between host computer4510and UE4530via base station4520, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from UE4530or from the service provider operating host computer4510, or both. While OTT connection4550is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

Wireless connection4570between UE4530and base station4520is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments may improve the performance of OTT services provided to UE4530using OTT connection4550, in which wireless connection4570forms the last segment. More precisely, the teachings of these embodiments may improve the random access speed and/or reduce random access failure rates and thereby provide benefits such as faster and/or more reliable random access.

A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring OTT connection4550between host computer4510and UE4530, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring OTT connection4550may be implemented in software4511and hardware4515of host computer4510or in software4531and hardware4535of UE4530, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which OTT connection4550passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software4511,4531may compute or estimate the monitored quantities. The reconfiguring of OTT connection4550may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect base station4520, and it may be unknown or imperceptible to base station4520. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating host computer4510's measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that software4511and4531causes messages to be transmitted, in particular empty or ‘dummy’ messages, using OTT connection4550while it monitors propagation times, errors etc.

FIG.23is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference toFIGS.21and22. For simplicity of the present disclosure, only drawing references toFIG.23will be included in this section. In step4610, the host computer provides user data. In substep4611(which may be optional) of step4610, the host computer provides the user data by executing a host application. In step4620, the host computer initiates a transmission carrying the user data to the UE. In step4630(which may be optional), the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step4640(which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

FIG.25is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference toFIGS.21and22. For simplicity of the present disclosure, only drawing references toFIG.25will be included in this section. In step4810(which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step4820, the UE provides user data. In substep4821(which may be optional) of step4820, the UE provides the user data by executing a client application. In substep4811(which may be optional) of step4810, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in substep4830(which may be optional), transmission of the user data to the host computer. In step4840of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

Abbreviations

At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).1×RTT CDMA2000 1×Radio Transmission Technology3GPP 3rd Generation Partnership Project5G 5th GenerationABS Almost Blank SubframeARQ Automatic Repeat RequestAWGN Additive White Gaussian NoiseBCCH Broadcast Control ChannelBCH Broadcast ChannelCA Carrier AggregationCC Carrier ComponentCCCH SDU Common Control Channel SDUCDMA Code Division Multiplexing AccessCGI Cell Global IdentifierCIR Channel Impulse ResponseCP Cyclic PrefixCPICH Common Pilot ChannelCPICH Ec/No CPICH Received energy per chip divided by the power density in the bandCQI Channel Quality informationC-RNTI Cell RNTICSI Channel State InformationDCCH Dedicated Control ChannelDL DownlinkDM DemodulationDMRS Demodulation Reference SignalDRX Discontinuous ReceptionDTX Discontinuous TransmissionDTCH Dedicated Traffic ChannelDUT Device Under TestE-CID Enhanced Cell-ID (positioning method)E-SMLC Evolved-Serving Mobile Location CentreECGI Evolved CGIeNB E-UTRAN NodeBePDCCH enhanced Physical Downlink Control ChannelE-SMLC evolved Serving Mobile Location CenterE-UTRA Evolved UTRAE-UTRAN Evolved UTRANFDD Frequency Division DuplexFFS For Further StudyGERAN GSM EDGE Radio Access NetworkgNB Base station in NRGNSS Global Navigation Satellite SystemGSM Global System for Mobile communicationHARQ Hybrid Automatic Repeat RequestHO HandoverHSPA High Speed Packet AccessHRPD High Rate Packet DataLOS Line of SightLPP LTE Positioning ProtocolLTE Long-Term EvolutionMAC Medium Access ControlMBMS Multimedia Broadcast Multicast ServicesMBSFN Multimedia Broadcast multicast service Single Frequency NetworkMBSFN ABS MBSFN Almost Blank SubframeMDT Minimization of Drive TestsMIB Master Information BlockMME Mobility Management EntityMSC Mobile Switching CenterNPDCCH Narrowband Physical Downlink Control ChannelNR New RadioOCNG OFDMA Channel Noise GeneratorOFDM Orthogonal Frequency Division MultiplexingOFDMA Orthogonal Frequency Division Multiple AccessOSS Operations Support SystemOTDOA Observed Time Difference of ArrivalO&M Operation and MaintenancePBCH Physical Broadcast ChannelP-CCPCH Primary Common Control Physical ChannelPCell Primary CellPCFICH Physical Control Format Indicator ChannelPDCCH Physical Downlink Control ChannelPDP Profile Delay ProfilePDSCH Physical Downlink Shared ChannelPGW Packet GatewayPHICH Physical Hybrid-ARQ Indicator ChannelPLMN Public Land Mobile NetworkPMI Precoder Matrix IndicatorPRACH Physical Random Access ChannelPRS Positioning Reference SignalPSS Primary Synchronization SignalPUCCH Physical Uplink Control ChannelPUSCH Physical Uplink Shared ChannelRACH Random Access ChannelQAM Quadrature Amplitude ModulationRAN Radio Access NetworkRAT Radio Access TechnologyRLM Radio Link ManagementRNC Radio Network ControllerRNTI Radio Network Temporary IdentifierRRC Radio Resource ControlRRM Radio Resource ManagementRS Reference SignalRSCP Received Signal Code PowerRSRP Reference Symbol Received Power OR Reference Signal Received PowerRSRQ Reference Signal Received Quality OR Reference Symbol Received QualityRSSI Received Signal Strength IndicatorRSTD Reference Signal Time DifferenceSCH Synchronization ChannelSCell Secondary CellSDU Service Data UnitSFN System Frame NumberSGW Serving GatewaySI System InformationSIB System Information BlockSNR Signal to Noise RatioSON Self Optimized NetworkSS Synchronization SignalSSS Secondary Synchronization SignalTDD Time Division DuplexTDOA Time Difference of ArrivalTOA Time of ArrivalTSS Tertiary Synchronization SignalTTI Transmission Time IntervalUE User EquipmentUL UplinkUMTS Universal Mobile Telecommunication SystemUSIM Universal Subscriber Identity ModuleUTDOA Uplink Time Difference of ArrivalUTRA Universal Terrestrial Radio AccessUTRAN Universal Terrestrial Radio Access NetworkWCDMA Wide CDMAWLAN Wide Local Area Network

Further definitions and embodiments are discussed below.