Patent Description:
The network architecture of the Fifth Generation, <NUM>, telecommunication networks is defined in the new Third Generation Partnership Project, 3GPP, Release <NUM>. An aspect in which the 3GPP networks will differ starting from Release <NUM> is that the Core Network, CN, architecture is mostly built around the Service Based Architecture, SBA, paradigm. That is, there will be a network domain, basically the core network, CN, in which the different functional components are defined as Services, which are self-contained functionalities that can be changed and modified in an isolated manner without affecting the others.

The architecture proposed for 3GPP Release <NUM> comprises logical Network Functions, NFs, within the CN, wherein most of them are built of one or more Services to form an SBA domain. The study phase for the Release <NUM> network is ongoing, according to which the <NUM> Core, 5GC, network will preserve the NFs as the main network constructs. However, it introduces a new concept of Set of instances, which is a Set of NF service instances of the same service type that can access the same data storage.

The inventors have found that the NF defined in the SBA architecture in Rel-<NUM> represents certain limitations in how the vendors could implement them. The internal communication and data layer of the services within the NF may be proprietary but they must provide the standardized Service Based Interfaces, SBIs, when communicating with other NF services. This precludes the deployment of larger constructs, i.e. constructs including more functionality than what is included in a certain NF, where the internal 'services', i.e. the internal functional implementation within such larger constructs may be proprietary and interfaces when communicating within the construct could also be proprietary.

For example, it is found that it could be beneficial to design a larger network logic including both the Access & Mobility management Function AMF and Session Management Function, SMF, NFs. This would enable that the communication between internal 'AMF' and `SMF' 'services' is proprietary and also these internal services may implement specific functionality optimizing AMF and SMF interaction, respectively.

Besides, as an NF is a large collection of functionality, it was found that it could be as well beneficial to define a construct that is a subset of the included functionality/services. The technical challenge that such constructs represent is to ensure that internal services can use the proprietary communication and functionality when communicating with each other, while retaining a subset of standard functionality and SBIs when communicating with the external services. Besides, in the case when there is overlapping functionality of a SC and external SBA services, there should be a means to control which internal or external services or even service operations are selected for a specific case.

The <NPL>" discloses in §<NUM> grouping internal service instances into service sets that are grouped into units, each unit having a framework function for providing functions like registration/discovery of internal service instances, registration/discovery with NRF for outside communication and communication between internal service instances. If the service instance does not expose to services outside of the unit, it only register to the framework function. If the service instance wants to expose to services outside of the unit, besides the registration to the framework function, the service instance is also registered to the NRF via the standardized interface. When the service instance is registered to NRF, depending on whether or not it wants to be accessed directly, the information registered in NRF is different. If the service instance is hidden towards the outside, the set ID of the service instance and the unit address pointing to the framework function are registered to NRF. On the contrary, if the service instance is directly registered to the NRF, i.e. no service instance hiding, the service instance and the unit address pointing to the service instance itself are registered to NRF.

It is an object of the present disclosure to overcome the drawback as mentioned above.

The present application is directed to the concept that a Collection Controller is introduced that acts on behalf of the internal consumers. The Collection Controller, CoC, may be arranged to control the internal and the external communication. The CoC may thus receive and respond to registration messages and discovery message from internal services within a service collection, and may send registration and discovery messages towards the SBA domain of the telecommunication network.

One of the advantages of using a CoC is related to the interfaces that are to be used. If multiple services are combined into a service collection, it may no longer be necessary to implement the interfaces between these services as defined in any standard. The interface between these multiple services may be made proprietary as a single vendor may deploy the service collection. There is no need to assure that other parties are able to interface with the services, the services are only access by components made by the same vendor.

One of the advantages of the proposed method is thus that it enables deploying constructs, i.e. service collections, in an SBA domain where the services within a SC may implement proprietary functionality and interfaces when communicating within the SC.

In the context of the present disclosure, a service collection may be viewed, but not limited to, as a packaging of SBA services with proprietary internal structure and providing a subset of external standard Application Programming Interfaces, API's. A service collection may have the following characteristics.

The services within a collection may implement proprietary functionality and interfaces when communicating within the collection.

Services that are offered externally by the service collection may be compliant to the respective standard. A service collection may not expose the services offered by the services it includes. Some services/operations that may be offered externally may be accessed internally, i.e. within the service collection, by other means.

It is noted that the functionality/external SBI's on a service collection may overlap with the functionality of other NF's in the SBA domain.

In other words, there is suggested to include a CoC in the telecommunication network which is to operate next to an NRF. Typically, services are registered in an NRF and any consumer may discover the registered services using discovery messages towards the NRF. The present application defines a CoC which acts as a function in between the service collection and the NRF. The CoC may thus receive a registration message for registering a particular service within the service collection. The CoC may determine whether the particular service to be registered is to be provided within the service collection only, or whether the service may also be provided within the SBA domain of the telecommunication network. In this particular scenario, it is assumed that the particular service is to be provided within the service collection only. In that particular case, the CoC refrains from forwarding the registration message to the NRF, as there is no need to register that particular service in the NRF. Finally, the CoC registers the service in the CoC itself such that that particular service may be discovered within said Service Collection Function.

The above mentioned and other features and advantages of the disclosure will be best understood from the following description referring to the attached drawings. In the drawings, like reference numerals denote identical parts or parts performing an identical or comparable function or operation.

<FIG> schematically illustrates part of the reference architecture <NUM> of a fifth generation, <NUM>, Service Based Architecture, SBA, telecommunication network, according to the prior art. The <NUM> system architecture comprises the following Network Functions, NFs in the core network <NUM>:.

The <NUM> system architecture may further comprise a User Equipment, UE, <NUM>, a Radio Access network, RAN, <NUM>, a User Plane Function, UPF, <NUM> and a Data Network, DN, <NUM>.

A functional description of these network functions is specified in clause <NUM> of the Third Generation Partnership Project, 3GPP, standard <NUM>, "System Architecture for the <NUM> system".

<FIG> discloses an example <NUM> of a schematic representation <NUM> of a Service Collection.

Here, it is noted that the functionality/external SBI's on a particular service collection <NUM> may overlap with the functionality of other Network Functions, NF's, in the SBA domain. For example, in this particular scenario, the service collection <NUM> implements the functionality of NF A <NUM>, NF B <NUM>, a subset of services of NF C, i.e. C1 <NUM> and C2 <NUM>, as well as internal services x <NUM> which is not addressable by other SBA services.

Further, in this example, it is considered that in the SBA domain NF B <NUM> and NF C <NUM> are also deployed with thus overlapping functionality, for example, from different vendors. The selection of a particular service, i.e. SC internal or external, for a certain operation may then depend on its features and characteristics.

<FIG> discloses an example <NUM> of a schematic representation of a Service Collection <NUM> in combination with a Collection Controller, CoC, <NUM> in accordance with the present disclosure.

The CoC <NUM> may achieve transparent and smooth operation on a Service Collection <NUM> by participating into the registration and discovery signalling. In accordance with the present disclosure, the internal services, i.e. the services as indicated with reference numerals <NUM>, <NUM> and <NUM> are to be registered in the CoC <NUM>. The service collection may be provided by a single vendor such that the communication between the CoC <NUM> and each of the services <NUM>, <NUM> and <NUM> may be standardized or proprietary.

In case the internal services, i.e. the services as indicated with reference numerals <NUM>, <NUM> and <NUM>, may also be reachable from the outside world, these internal services may also be registered in a Network Repository Function, NRF, <NUM>. In that particular scenario, the CoC <NUM> may forward any registration message originating from any of the internal services <NUM>, <NUM>, <NUM> to the NRF <NUM> as indicated with a solid line.

An internal to the CoC <NUM> consumer may send discovery messages, either standardized or proprietary, to the CoC <NUM>. If external SBA services are targeted, for example NF A <NUM> NF B <NUM> or NF E <NUM>, then the CoC <NUM> may send standardized discovery messages to the NRF <NUM>. Otherwise, the CoC <NUM> may respond internally to a discovery message for discovering a particular service.

Following the explanation above, the dashed lines provided in <FIG> may be proprietary while the solid lines may be standardized. The dashed lines in <FIG> may be implemented in a proprietary manner as the service collection may be provided by a single vendor.

<FIG> discloses an example of a flow chart <NUM> illustrating registration of services from within the service collection.

In this particular example, the service collection comprises the internal service A <NUM>, the internal service B <NUM> and the internal service C <NUM>. In a first step, as indicate with reference numeral <NUM>, the CoC <NUM> may receive, from an internal service A <NUM>, a registration message for registering a service. The registration message is directed to register that particular service for internal use only, so for use within the service collection only.

The CoC <NUM> determines <NUM> that the service is to be provided within the service collection only. The CoC <NUM> may determine <NUM> that the service is to be provided within the service collection only based on the Uniform Resource Identifier, URI, in the registration message.

Then, the CoC <NUM> may refrain from forwarding the registration message to the NRF <NUM>. Finally, the CoC <NUM> registers the service in the CoC <NUM> for discovering the service any of the plurality of internal services within the service collection.

Next, a further registration message is sent as indicated with reference numeral <NUM>. Here, The Internal service instance B sends <NUM> a registration message to the CoC <NUM> specifying its reachability which is, for example, Set <NUM> SPoA URI for the SBA service B <NUM>.

Since B <NUM> is an SBA service that may be reachable by external services, the CoC <NUM> may forward <NUM> the registration message to the NRF, by offering the Set <NUM> SPoA URI as its reachability information. It is noted that the CoC <NUM> may perform conversion techniques for converting the internal communication between the CoC <NUM> and the internal service B <NUM> to the external, standardized, communication between the CoC <NUM> and the NRF <NUM>.

Another example is discussed with reference to internal service C <NUM>. Here, the internal service C <NUM> sends <NUM> a service registration message to the CoC <NUM>, wherein the service registration message comprises two different addresses. A first address is used for the internal service C and an external address is used as external service D. As such, the CoC <NUM> will register <NUM> the internal service having the internal service address in the CoC <NUM> for internal purposes, and will forward the registration message to the NRF <NUM> for the service having the external service address.

<FIG> discloses examples <NUM> of service discovery in accordance with the present disclosure.

Here, reference numeral <NUM> denotes an external consumer. Reference numeral <NUM> denotes the NRF. Reference numeral <NUM> denotes the CoC. Reference numeral <NUM> denotes a service Set <NUM> (SPoA). Reference numeral <NUM> denotes service B (within Set <NUM>). Reference numeral <NUM> denotes Set <NUM> (SPoA). Reference numeral <NUM> discloses service C (within Set <NUM>). It is noted that the services B and C of <FIG> correspond to the services B and C of <FIG>.

In a step <NUM>, the NRF <NUM> receives a service discovery message for discovering service B. As mentioned with respect to the explanation accompanying <FIG>, the service B is to be reachable from the SBA domain and is, as such, registered in the NRF <NUM>. As such, the NRF <NUM> is able to reply to the service discovery message by sending <NUM> a discovery response message comprising the address at which the service B is to be reached.

The external consumer <NUM> may then send <NUM> a Service B operation request to the Set <NUM> (SPoA), which is sent to the internal service B <NUM>.

The above described example is thus directed to the concept that the service provided from within the service collection is also reachable from the SBA domain.

Another example is described here below. Here, a discovery message is sent <NUM> to the NRF <NUM> for discovering the service D. Here, the service D is reachable over a proprietary interfaces and is accessed <NUM> through the CoC that performs protocol conversion <NUM>. The CoC <NUM> thus performs protocol conversion and communicates <NUM> to the corresponding service. A response message is received <NUM> from the NRF5.

Besides protocol conversion, the CoC <NUM> could be also configured of certain service operations to be allowed for a given service. That is, the CoC <NUM> could have a list of the accessible services/operations from the outside, e.g., by O&M configuration. This could differ from what is registered by the CoC <NUM> to the NRF <NUM>. Thus, if an external service sent a service operation request that is not allowed then the CoC <NUM> could reply with a corresponding error message.

<FIG> discloses an example <NUM> of the discovery of internal services by an internal consumer in accordance with the present disclosure.

Here, reference numeral denotes an internal consumer. Reference numeral <NUM> denotes the CoC. Reference numerals <NUM> and <NUM> denote the Set <NUM> (SPoA) and the internal service C within Set <NUM>, respectively.

First, a service discovery message is sent <NUM>, from the internal consumer <NUM> to the CoC <NUM> for requesting the discovery of a service C. The CoC <NUM> determines that the service C is an internal service which is accessible for the internal user <NUM>, and responds <NUM> to the internal user <NUM> with the Set3 SPoA URI. Finally, the internal consumer <NUM> is able to use the retrieved Set <NUM> SPoA URI to sent <NUM> a Service C operation request towards the internal service C.

<FIG> discloses an example <NUM> of the discovery of an external service by an internal consumer in accordance with the present disclosure.

Here, the CoC <NUM> may first receive 111a service discovery message from an internal consumer <NUM>. The CoC <NUM> may determine <NUM> that the requested service is not registered internally within the CoC <NUM>. As such, the CoC <NUM> forwards <NUM> the discovery request message to the NRF <NUM>, which provides for the response message <NUM> in accordance with the prior art. It is noted that the communication between the CoC <NUM> and the internal consumer may still be proprietary as is indicated with the dashed line. The internal consumer <NUM> is then able to reach <NUM> the requested service <NUM> using the response message.

<FIG> discloses an example <NUM> of multiple sets of the same SC internal service.

Here, reference numeral <NUM> denotes internal service B instances <NUM> to N within Set <NUM> and reference numeral <NUM> denotes internal service B instances M to Q within Set <NUM>.

This scenario indicates that there are two or more service sets of the same service. This may be required in order to increase the service availability, for example because there is no common shared database for the two sets, or to offer geo-redundancy, i.e. different sets distributed across different datacenters around the network.

When there is a single set of Service B, the CoC <NUM> could register the SPoA of Service B, i.e. reference numerals <NUM> and <NUM>, that enables direct communication with the external consumers. However, when a new set is registered, i.e. reference numeral <NUM>, then the CoC <NUM> may realize that there are multiple Sets to control, i.e. reference numeral <NUM>, thus it may issue a registration update for Service B offering the CoC URI instead of the Set <NUM> SPoA, i.e. reference numeral <NUM>. Reference numeral <NUM> indicates the NRF in this flow chart diagram.

<FIG> discloses an example <NUM> of multiple sets from both the SC and the external SBA domain.

Here, reference numeral <NUM> denotes an external service B instances <NUM> to N within Set <NUM>, and reference numeral <NUM> denotes internal service B instances M to Q within Set <NUM>.

This scenario assumes that two or more sets of the same service can be found both within an SC and outside the SC. In this case there may be a need to manage the different sets both from the bindings perspective, i.e. to find the set where a given UE/context is stored, but in addition there could be also an additional need to select an SC internal or external service, depending on a certain factor.

For example, one could like to control how much eMBB traffic a certain vendor equipment handles, e.g., Vendor A: <NUM>% Vendor B <NUM>% of traffic; or, alternatively, one Vendor equipment should take all the traffic as long as there are no special conditions like planned upgrades, failures etc..

<FIG> shows an example of handling such control, i.e. reference numerals <NUM>, <NUM>, <NUM>, <NUM> and <NUM>, when the new service control functionality is included in the CoC <NUM> or is separated, respectively. In the latter case, the Service Controller acts as front-end to the CoC and also to the other NFs or other CoC offering identical services. Note that in the case when there are multiple internal sets and at least one external to the SC, if there is a separate Service Controller then the communication involving an external consumer and an internal producer should pass both Service Controller and CoC, thus an integrated CoC_Service Controller solution for such cases is a more reasonable approach.

In the case when the services in the collection have definite operations offered for the other SC-internal services, and other operations for the external services, then the internal SBls may be proprietary as they will only be used for other SC-internal services.

When the collection services offer the same service operation for both internal and external consumers, then it needs special consideration and functionality to use the proper interface by the proper operation. Alternatives:.

Along the present disclosure, we have described the invention considering Service instance and Service instance sets. In 3GPP there is now the tendency to retain the NF concept, that is, that services may be deployed as part of an NF, like it is done in Rel-<NUM>. This will imply the possibility that multiple NF instances could be deployed in pools/sets as well, in the same way as we have considered for service instance sets.

The two concepts are in fact very related, since an NF instance includes one or multiple service types, that are instantiated in normally pools of instances, (i.e. service instances sets). Even, the smallest NF instance Set may be just one single NF instance, since the NF instance may be considered on itself a container of a multiplicity of Service instances.

Claim 1:
A method of registering a service in a telecommunication network having a Service Based Architecture, SBA, wherein said telecommunication network having a Service Collection Function, SCF, comprising a plurality of distinct SBA services and comprising a Collection Controller, CoC, (<NUM>) for registering and discovering of said plurality of distinct SBA services within said SCF, wherein said telecommunication network further comprises a Network Repository Function, NRF, (<NUM>) for registering and discovering services within said telecommunication network, said method comprises the steps of:
- receiving (<NUM>), by said CoC, from one (A <NUM>) of said distinct SBA services, a registration message for registering a service;
- determining (<NUM>), by said CoC, that said service is to be provided within said SCF only;
- refraining, by said CoC, from forwarding said registration message to said NRF based on said determination;
- registering, by said CoC, said service in said CoC for discovering said service by any of said plurality of distinct SBA services within said SCF, wherein said method further comprises the steps of:
- receiving (<NUM>), by said CoC from one (B <NUM>) of said distinct SBA services, a registration message for registering a further service;
- determining, by said CoC, that said further service is to be provided within said telecommunication network;
- forwarding (<NUM>), by said CoC, said registration message to said NRF for registering and discovering said further service in said NRF.