Patent Description:
A communication system can be seen as a facility that enables communication sessions between two or more entities such as user terminals, base stations/access points and/or other nodes by providing carriers between the various entities involved in the communications path. A communication system can be provided, for example, by means of a communication network and one or more compatible communication devices. The communication sessions may comprise, for example, communication of data for carrying communications such as voice, electronic mail (email), text message, multimedia and/or content data and so on. Non-limiting examples of services provided comprise two-way or multi-way calls, data communication or multimedia services and access to a data network system, such as the Internet.

The document "<NPL> describes services of the Network repository Function.

In general, the following disclosure relates to an example architecture, with associated apparatus, for a communication system. In particular, the following relates to an architecture and associated apparatus for a service based architecture.

A core network architecture may be service-based architecture (SBA), allowing some network functions (NFs), called NF service producers, to expose services to other authorized NFs, called NF service consumers, through a service-based interface.

Before explaining in detail the examples, certain general principles of a wireless communication system and mobile communication devices are briefly explained with reference to <FIG> to assist in understanding the technology underlying the described examples.

In a wireless communication system <NUM>, such as that shown in <FIG>, mobile communication devices or user apparatus (UE) <NUM>, <NUM> are provided wireless access via at least one base station or similar wireless transmitting and/or receiving node or point. A user can access the communication system by means of an appropriate communication device or terminal. A communication device of a user is may be a user equipment (UE) or a machine type terminal or any other suitable device. A communication device is provided with an appropriate signal receiving and transmitting apparatus for enabling communications, for example enabling access to a communication network or communications directly with other users. The communication device may access a carrier provided by a station or access point, and transmit and/or receive communications on the carrier.

The communication system and associated devices typically operate in accordance with a given standard or specification which sets out what the various entities associated with the system are permitted to do and how that should be achieved.

A base station may be referred to more generally as simply a network apparatus or a network access point. Base stations are typically controlled by at least one appropriate controller apparatus, so as to enable operation thereof and management of mobile communication devices in communication with the base stations. The controller apparatus may be located in a radio access network (e.g. wireless communication system <NUM>) or in a core network (CN) (not shown) and may be implemented as one central apparatus or its functionality may be distributed over several apparatus. The controller apparatus may be part of the base station and/or provided by a separate entity such as a Radio Network Controller. In <FIG> control apparatus <NUM> and <NUM> are shown to control the respective macro level base stations <NUM> and <NUM>. In some systems, the control apparatus may additionally or alternatively be provided in a radio network controller.

There may be smaller base stations or cells (not shown) in some networks. These may be pico or femto level base stations or the like.

A possible communication device will now be described in more detail with reference to <FIG> showing a schematic, partially sectioned view of a communication device <NUM>. Such a communication device may be a user equipment (UE) or terminal. An appropriate communication device may be provided by any device capable of sending and receiving radio signals. Non-limiting examples comprise a mobile station (MS) or mobile device such as a mobile phone or what is known as a 'smart phone', a computer provided with a wireless interface card or other wireless interface facility (e.g., USB dongle), personal data assistant (PDA) or a tablet provided with wireless communication capabilities, a machine type device or any combinations of these or the like.

The device <NUM> may receive signals over an air or radio interface <NUM> via appropriate apparatus for receiving and may transmit signals via appropriate apparatus for transmitting radio signals. In <FIG> transceiver apparatus is designated schematically by block <NUM>. The transceiver apparatus <NUM> may be provided for example by means of a radio part and associated antenna arrangement. The antenna arrangement may be arranged internally or externally to the mobile device.

A device is typically provided with at least one data processing entity <NUM>, at least one memory <NUM> and other possible components <NUM> for use in software and hardware aided execution of tasks it is designed to perform, including control of access to and communications with access systems and other communication devices. The data processing, storage and other relevant control apparatus can be provided on an appropriate circuit board and/or in chipsets. This feature is denoted by reference <NUM>. The user may control the operation of the mobile device by means of a suitable user interface such as key pad <NUM>, voice commands, touch sensitive screen or pad, combinations thereof or the like. This may be optional in some embodiments.

A display <NUM>, a speaker and a microphone can be also provided. One or more of these may be optional in some embodiments.

A communication device may comprise appropriate connectors (either wired or wireless) to other devices and/or for connecting external accessories, for example hands-free equipment, thereto. One or more of these may be optional.

The communication devices may access the communication system based on various access techniques.

An example of wireless communication systems are architectures standardized by the 3rd Generation Partnership Project (3GPP). A latest 3GPP based development is often referred to as <NUM>. Other examples of radio access system comprise those provided by base stations of systems that are based on technologies such as wireless local area network (WLAN) and/or WiMAX (Worldwide Interoperability for Microwave Access). It should be appreciate that although some embodiments are described in the context of a <NUM> system, other embodiments may be provided in any other suitable system including but not limited to subsequent systems or similar protocols defined outside the 3GPP forum.

An example apparatus is shown in <FIG> shows an example of an apparatus <NUM> for a network function such as a network repository function (NRF) or an access node or any other suitable function. The apparatus <NUM> comprises at least one memory <NUM>, at least one data processing unit <NUM>, <NUM> and an input/output interface <NUM>. For example the apparatus <NUM> can be configured to execute an appropriate software code to provide functions. The apparatus <NUM> may be included in a chipset apparatus.

The proposed <NUM> system supports a service based architecture. A service based architecture utilises a service based framework for a variety of communications-related processes, such as service registration, deregistration, discovery, selection, routing, etc. A service-based architecture is characterised by, instead of having predefined interfaces between network elements, using a services model in which components query a network function repository function (NRF) to discover and communicate with each other over application programming interfaces (APIs). An API is a function and/or procedure that allows the creation of application which access the features or data of an operating system, application or other service.

To support this service architecture, there are described/provided a plurality of functional entities (also known as network functions, NFs). Aside from the above-mentioned NRF, other network functions may comprise one or more of:.

Some embodiments may be supported by one or more of the above functions. In some embodiments, one or more of these functions may be as set out in sub clause <NUM> of 3GPP TS <NUM>.

In Rel-<NUM> of the <NUM> architecture, some network functions (NFs), called NF service producers, expose services to other authorized NFs, called NF service consumers, through a service-based interface.

An example architecture for such a services-based architecture is depicted in <FIG>.

The architecture shows a user equipment (UE) <NUM> connected to a (radio) access network ((R) AN or <NUM>-AN) <NUM> at the access stratum, as well as an access and mobility management function (AMF) <NUM> at the non-access stratum. The RAN represents a base station using so-called "new" RAT (radio access technology) and evolved LTE, for example a gNodeB (gNB). An AN (access node) is a general base station including non-3GPP access, e.g., Wi-Fi. A <NUM>-AN may be a <NUM> Access Network comprising a NG (next generation)-RAN and/or non-3GPP AN connecting to a <NUM> Core Network, e.g. a N3IWF (Non 3GPP Interworking Function).

It has been proposed that the fixed access may be integrated into the same <NUM> core network (5GC). Some embodiments may be applied in this context alternatively or additionally.

The <NUM> core network (5GC) consists of various network functions (NFs) as discussed previously. In <FIG> there are ten <NUM> core NFs. An access and mobility management function (AMF) <NUM>, a session management function (SMF) <NUM>, a policy control function (PCF) <NUM>, an application function (AF) <NUM>, an authentication server function (AUSF) <NUM>, a user plane function (UPF) <NUM>, unified data management (UDM) <NUM>, a NF repository function (NRF) <NUM>, a network exposure function (NEF) <NUM> and a network slice selection function (NSSF) <NUM>. A data network (DN) <NUM> is shown.

In <FIG> we see the following interfaces or references connecting the NFs:.

Reference is made to <FIG> which shows a registration procedure between a NF service producer <NUM> and a NRF <NUM>.

In step A1, upon instantiation or activation, a NF service producer <NUM> registers its profile into an NRF <NUM>. This may be performed by sending a request with a NF profile. This request may be a Nnrf_NFManagement_NFRegister_request or any suitable request. The NF profile may comprise one or more of:.

In step A2, the NF profile is stored by the NRF <NUM>.

In step A3, the NRF <NUM> will provide a response. This response will indicate that the profile has been stored. This response may be a Nnrf_NFManagement_NFRegister_response or any suitable response.

This registration step allows these NFs and their supported services to be visible to other NFs. When an NF service consumer needs to call a specific service or to contact a specific NF or NF type, it triggers a discovery request towards the NRF <NUM> and the NRF <NUM> returns the NFs and the NF services which are registered, and which match the request from the NF service consumer. An example of this will now be described with reference to <FIG> which shows a NF/NF service discovery procedure.

In step T1, a NF service consumer <NUM> sends a request to the NRF <NUM>. This may comprise one or more query parameters. The request may be a Nnrf_Discovery_Request.

In step T2, the NRF <NUM> may authorize the NF service discovery request.

In step T2a, the NRF <NUM> may search for NFs or NF services matching the one or more query parameters.

In step T3, a response may be sent from the NRF <NUM> to the NF service consumer <NUM>. The response may comprise NF profiles or NF services matching the one or more query parameters. In some embodiments, there may be one or more query parameters. The response will only return NF profiles or services if they match all the one or more query parameters. The response may be an Nnrf_NFDiscovery_RequestResponse or any other suitable response.

In step T4, the NF service consumer <NUM> may select a NF or a NF service.

The concept of locality information in the NF profile has been proposed. This may allow an NF service producer <NUM> to provide information about its location, e.g. geographical area or data centre information or a desired location. Later, an NF service consumer <NUM> can trigger a discovery, and based on the NF profiles received from NRF <NUM>, the NF service consumer <NUM> can select an NF service producer <NUM> which is close to the NF service consumer <NUM>, thus optimizing performance. The query parameter may comprise a locality query parameter. The NF / NF service selection based on location information may be done by the NF service consumer <NUM>, using results from discovery. There may be no control of the NF / NF service selection by the NRF <NUM>. However, this NF / NF service location information may not be necessarily part of the NF service application logic, and, in some embodiments, could be handled by a framework function, i.e. the NRF <NUM>.

The inclusion of location information in the discovery request, with the current specification of discovery procedure, may allow the NF service consumer <NUM> to request an NF service producer in a specific location. However, if the NRF <NUM> does not find any NF or NF service matching the requested location, the NRF <NUM> may indicate a failure of the discovery to the NF service consumer <NUM>. The NF service consumer <NUM> may then need to trigger another discovery request with a different location, until the NF service consumer <NUM> receives a positive service indication from the NRF <NUM>. It is desirable to mitigate the effects of this behaviour to reduce signalling.

Even if the NRF <NUM> returns NFs or NF services to the NF service consumer <NUM>, as a result of discovery, there may be no guarantee that the NF service consumer <NUM> can actually call the discovered NF / NF service. For example, the NF service consumer <NUM> may not be able to call the discovered NF / NF service in case of a failure, or heavy load of the NF service producer. Therefore, the NF service consumer <NUM> may have to trigger several discovery requests before a service is successfully called.

Hereby, a mechanism is presented that may avoid back and forth signalling between the NF service consumers <NUM> and the NRF <NUM> in case, for example, the NF service consumer <NUM> requests are too restrictive in terms of requested locality, or in case, for example, the discovered NFs / NF services cannot be contacted.

In some embodiments, a mechanism is provided that may avoid that the selection of the NF or NF service based on locality, is done at NF service consumer <NUM> side only. Instead, in some embodiments, the logic of NF / NF service selection based on locality is at least partially decoupled from the NF service consumer application logic, allowing centralized control by the NRF <NUM>.

Reference is made to <FIG> which shows a NF/NF service discovery request procedure according to some embodiments.

In some embodiments, the locality information may be provided by the NF service consumer <NUM>, in the discovery request, in the form of a preference, e.g. via a "preferred locality" parameter. This is shown in step R1 whereby the NF service consumer transmits a discovery request to NRF, containing: one or more query parameters and/or preferred locality. The preferred locality may be set to the NF service consumer's <NUM> locality or a desired target locality. In some embodiments, the preferred locality may be one of the one or more query parameters.

In step R2 the NRF <NUM> may check whether the NF service consumer <NUM> is authorized to perform discovery.

In step R2a the NRF <NUM> may search for NFs or NF services matching query parameters. The results will satisfy all of the one or more query parameters.

In step R2b the NRF <NUM> may further filter the results from step R2a using the preferred locality parameter received by the NRF <NUM> in step R1. The NRF <NUM> may, for example, only consider NFs / NF services in the same locality as the preferred locality parameter and/or in localities close to the preferred locality parameter. In some examples, the NRF <NUM> may apply some additional treatment, such as setting the priority of the fitting NFs / NF services to 'high' if they match the preferred locality parameter, or to 'medium' if they do not match the preferred locality parameter but the location is still relatively close, or to 'low' if they do not match the preferred locality parameter.

It should be appreciated that, while the one or more query parameters are matched, the preference may or may not be matched when providing one or more NFs or NF services.

Therefore, in some examples, when the NRF <NUM> receives a request for discovery with such a preferred locality parameter, it may not limit its search to only NF / NF services matching the query parameters, but it may consider locality as a preference only and possibly return to the NF service consumer <NUM>, NFs / NF services which are not necessarily matching the preferred locality. For an NF / NF service to be discovered in the search performed by the NRF <NUM>, the NF / NF service, in some examples, will match the one or more query parameters provided by the NF service consumer <NUM>. However, the NF / NF service may or may not match the preferred locality parameter provided by the NF service consumer <NUM>. The preferred locality parameter may represent an optional feature of the NF / NF service. The NRF <NUM> may utilize the preferred locality parameter to filter NF / NF services, or it may not.

In step R3 the NRF <NUM> returns the result of the discovery to the NF service consumer <NUM>. The results contain NFs / NF services that match the one or more query parameters but which do not necessarily match the preferred locality parameter. The returned NF profiles may contain all profile parameters, including the locality. The returned NF profiles may indicate the locality of the discovered NFs, should the NFs match the preferred locality parameter or not. This may allow the NF service consumer <NUM> to make a selection of an NF service, even if in case some of the NF services that are returned do not match the preferred locality parameter.

In other embodiments, only one or more relevant NF / NF services that match the one or more query parameters but which do not necessarily match the preferred locality parameter may be returned.

In some embodiments, the NRF <NUM> may be able to modify priority information in the returned NF profile or the returned NF service description. For example, the NRF <NUM> may set to a higher priority the NF / NF service producers which are in the preferred locality or close to the preferred locality, and set to a lower priority the NF / NF service producers which do not match the preferred locality parameter or which are far from the location of the NF service consumer. The priority may alternatively or additionally take into account the ability of the service producer to support the consumer.

In some embodiments, the preferred locality preference may, additionally, indicate what the NRF <NUM> behaviour should be when there is no NF or NF service matching the preferred locality parameter. For example, an NF service consumer <NUM> might request the NRF <NUM> to return everything fitting any other query parameters, or the NF service consumer <NUM> might request the NRF <NUM> to decide what to return among the NFs or NF services fitting the one or more query parameters (e.g. for the locality it would mean that NRF <NUM> could decide to only return NFs or NF services fitting the one or more query parameters and in a nearby locality).

In step R4, the NF service consumer selects an NF or an NF service based on the information provided by the NRF.

While, in some embodiments the NF service consumer <NUM> can provide a preferred locality parameter to address the locality parameter, the mechanism may be used for any other suitable type of preference parameter alternatively or additionally. For example, the NF service consumer <NUM> can provide "preference" parameters in the discovery request and the NRF <NUM> may then use these "preferences" as a guide for returning NF / NF service producers e.g. with distinct priorities based on the expressed preferences, but will not restrict its search to only NF service producers matching these "preferences" parameters.

In step S1 the NF service consumer <NUM> provides a discovery request to the NRF <NUM>, containing at least one of, one or more query parameters and "preferences parameters". "Preference parameters" may be, for example, preferred locality, or any other suitable preference that the NF service consumer may have. The preference parameters may indicate one or more optional preferences for an NF / NF service that the NF service consumer wants.

In some embodiments, a preference parameter may represent a single preference and in other embodiments a preference parameter may represent two or more preferences. In some embodiments more than one preference parameter may be provided. The preference parameters may be provided with different priorities in some embodiments.

In some embodiments, one or more parameters may be used either as a query parameter or a preference parameter.

In some embodiments, for step S1, the NF service consumer <NUM> may indicate, together with preferences parameters, whether the NRF <NUM> should decide on NFs / NF services returned in case the preferences parameters do not match the registered profiles, or if all NFs should be returned so that the NF service consumer <NUM> controls the NF service producer selection. This additional indication from the NF service consumer <NUM> may be provided per preference parameter in some embodiments. As an example only, locality information may be better handled centrally in NRF <NUM> while selection based on some other preference parameter may be better handled in the NF service consumer <NUM>.

In step S2 the NRF <NUM> checks whether the NF service consumer <NUM> is authorized to perform discover.

In step S2a the NRF <NUM> searches for NFs or NF services matching the one or more query parameters.

In step S2b the NRF <NUM> may further filter the results from step 2a using preferences parameters. The NRF <NUM> may also apply some additional treatment, for example, set the priority of the NFs / NF services to high if they match the preference parameters, to medium if they partly match the preference parameters, or to low if they do not match the preference parameters. In some embodiments, step S2b may be omitted.

In step S3 the NRF <NUM> returns the result of the discovery to the NF service consumer <NUM>. The results contain NFs / NF services that match the one or more query parameters but which do not necessarily match the preferences parameters. Therefore, the results may contain NFs / NF services that contain one or more of said optional preferences. The returned NF profiles will contain all profile parameters, thus allowing the NF service consumer <NUM> to make a selection if some NFs are returned which do not match the preference parameters. For an NF / NF service to be discovered in the search performed by the NRF <NUM>, the NF / NF service will match the one or more query parameters provided by the NF service consumer <NUM>.

However, the NF / NF service may or may not match the preference parameters provided by the NF service consumer <NUM>. The preference parameter may represent an optional feature of the NF / NF service. The NRF <NUM> may utilize the preference parameters to filter NF / NF services, or it may not.

In some embodiments, the NF service consumer <NUM> may indicate to the NRF <NUM> what to provide to the NF service consumer <NUM> if none of the NFs / NF services match the preference parameters. As an example, the indication of what to provide if there is no match may be received by the NRF <NUM> in a discovery request. In another example, the NRF <NUM> may have a default of what to do when no NFs / NF services match the preference parameters. In some embodiments, if the NFs / NF services match the one or more query parameters, but there is no match to the preference parameters then the NRF <NUM> will provide all of the NFs / NF services that matched the one or more query parameters to the NF service consumer <NUM>. In another embodiment, if the NFs / NF services match the one or more query parameters, but there is no match to the preference parameters then the NRF <NUM> will decide which NFs / NF services to provide to the NF service consumer <NUM>.

In step S4, the NF service consumer selects an NF or an NF service based on the information provided by the NRF.

This mechanism may be applicable to control plane (CP) functions as well as be used for user plane (UP) functions.

Thus, there may be a reduced signalling between NF service consumers and the NRF. The NF service consumer may not need to make multiple calls to the NRF for an NF or NF service if the NRF does not initially provide a suitable NF service to the NF service consumer.

Some embodiments may provide better flexibility for deployments, with control for selection of NF services either in the NRF, or in the NF service consumer, or both. The NF service consumer may be able to indicate one or more preferences in the service discovery request.

In some embodiments, the preferences parameters may be provided in a discovery request for selecting an NF or NF service, or both. In some examples, the one or more preference parameters may be treated independently. For example, individual preference parameters can be handled by the NRF <NUM> independently, possibly with a different configuration for the individual preference parameter.

It should be understood that each block of the flowchart of the Figures and any combination thereof may be implemented by various means or their combinations, such as hardware, software, firmware, one or more processors and/or circuitry.

It is noted that whilst embodiments have been described in relation to one example of a standalone <NUM> networks, similar principles maybe applied in relation to other examples of standalone <NUM> or LTE networks. It should be noted that other embodiments may be based on other cellular technology other than <NUM> or on variants of <NUM>. Therefore, although certain embodiments were described above by way of example with reference to certain example architectures for wireless networks, technologies and standards, embodiments may be applied to any other suitable forms of communication systems than those illustrated and described herein.

It is also noted herein that while the above describes example embodiments, there are several variations and modifications which may be made to the disclosed solution without departing from the scope of the present invention.

It should be understood that the apparatuses may comprise or be coupled to other units or modules.

In general, the various embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects of the invention may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto.

The embodiments of this invention may be implemented by computer software executable by a data processor, such as in the processor entity, or by hardware, or by a combination of software and hardware. Computer software or program, also called program product, including software routines, applets and/or macros, may be stored in any apparatus-readable data storage medium and they comprise program instructions to perform particular tasks. A computer program product may comprise one or more computer-executable components which, when the program is run, are configured to carry out embodiments. The one or more computer-executable components may be at least one software code or portions of it.

Claim 1:
An apparatus comprising means for:
receiving, at a network repository function (<NUM>), from a first network function (<NUM>) location information for a second network function or network function service in a specific location, and one or more query parameters; and
causing information to be provided to said first network function (<NUM>) about one or more second network functions or network function services, said one or more second network functions or network function services being selected to match the one or more query parameters when there is no match to said location information.