Service requirement handling

Abstract

There is provided a computer-implemented method for handling service requirements for a telecommunications network. The method comprises receiving a request for an end-to-end (E2E) service to be delivered using the telecommunications network, and determining requirements for the E2E service based on the received request. The requirements for the E2E service comprise a resiliency for the E2E service and an availability for the E2E service. The method further comprises determining one or more requirements of a transport network based on the determined requirements for the E2E service. Based on the one or more requirements of the transport network, a plurality of resources of the transport network and one or more demarcation points of the transport network to be configured to support the E2E service are determined (102).

Description

[0001] SERVICE REQUIREMENT HANDLING

[0002] Technical Field

[0003] The disclosure relates to methods for handling service requirements for a telecommunications network, and entities configured to operate in accordance with those methods.

[0004] Background

[0005] There currently exists a demand for network reliability, availability and resilience (NRAR) from network operators and verticals. This demand is increasing and is expected to continue growing in the coming years, driven by critical industrial applications and society-critical services.

[0006] The concept of NRAR refers to service requirements, and enables availability and reliability (e.g. requirements) to be defined for end-to-end (E2E) services (e.g. at an application level). For example, a specific “five-nines” (i.e. 99.999%) availability requirement can be ensured for a service requiring a high level of availability. Such a service may correspond, for example, to a service that “connects” an actuator in a robot with a corresponding remote controller. In another example, a service requiring specific NRAR could be a remote control of a factory production line. In this example, the service could involve a plurality of sensors of the production line components. Another example of a service could be a smart ambulance moving in a city. In this example, UEs associated with such a service could be all the sensors providing information about a sick person in the ambulance, and the machine providing an echocardiogram to an expert doctor who drives the operation in the field remotely.

[0007] To support E2E service requirements at different NRAR levels, the underlying network requires a certain level of overprovisioning for redundancy to provide timely failure recovery and to maintain an agreed service quality in the presence of undesirable network events (e.g. disruptions affecting normal operation of the network).

[0008] According to the NRAR concept, resiliency is required for an overall sequence of technological domains involved in service provisioning and assurance. Specifically, the resiliency requirements posed to a transport network can be inferred from the NRAR requirements. For example, for a particular E2E service, the E2E service and / or the network (e.g. radio access network (RAN) and / or core network (CN)) may impose NRAR requirements on the transport network at its demarcation points. If an entity which is involved in the service (e.g. link or node) encounters a fault, a corresponding redundant entity may continue operating to prevent an E2E service failure.

[0009] NRAR is commonly characterized by a set of NRAR requirements associated with a service. The service could, for example, be related to a set of user equipments (UEs) in a specific geographical area (e.g. as defined in Ericsson Technology Review (ETR) “E2E Network slicing orchestration”). The NRAR requirements are assumed to be also associated with an E2E network slice, that supports the specific services in its development area.

[0010] A challenging aspect associated with providing E2E services is that different services are expected to have different E2E requirements and associated NRAR levels (e.g. depending on service realisation, agreements between service providers and communication providers, etc.). Therefore, in the future, it is expected that overall resilience should be handled in a more granular (e.g. service-specific) way and in an E2E fashion. Achieving these goals can be difficult with approaches where resilience is applied to single interfaces (links) to mitigate failures to such interfaces, as providing resilience on a set of interfaces (links) does not necessarily mean that E2E service failures are prevented.

[0011] Summary

[0012] As described earlier, handling E2E requirements, such as NRAR levels, can be challenging. This is especially true in transport infrastructure scenarios (e.g. based on beyond fifth generation (Beyond5G) and / or sixth generation (6G)) where the transport network provides the connections among network (e.g. Radio Access Network (RAN) / Core Network (CN)) functions located in sites in geographical areas (commonly referred to as “RAN / CN domains”). An E2E service can be deployed as a chain of heterogenous network functions operating (e.g. located and / or running) in network domains (e.g. RAN / CN domains) which are connected by transport networks (e.g. transport domains). Herein, the network and transport domains can be referred to as technological domains. Hence, an E2E service can cross multiple technological domains in order to be provided.

[0013] As previously mentioned, the transport network provides connectivity to network (e.g. RAN / CN) functions, and heterogeneous technologies can be used based on the operator's needs. However, while resilience methods in transport networks are established, existing techniques struggle to map E2E service requirements to transport requirements. That is, there exists a challenge with current techniques in that they lack the ability to perform automatic and dynamic mapping of E2E service (e.g. NRAR) requirements. As such, current transport technology cannot dynamically manage the association of E2E service requirements with corresponding transport connections (flows). Moreover, automatic and dynamic mapping of demarcation points for transport in one or more slices is not yet addressed in existing techniques.

[0014] It is an object of the disclosure to obviate or eliminate at least some of the abovedescribed disadvantages associated with existing techniques.

[0015] Therefore, according to an aspect of the disclosure, there is provided a first method for handling service requirements for a telecommunications network. The first method is computer-implemented. The first method comprises receiving a request for an end-to- end (E2E) service to be delivered using the telecommunications network. The first method also comprises determining requirements for the E2E service based on the received request. The requirements for the E2E service comprise a resiliency for the E2E service and an availability for the E2E service. The first method also comprises determining one or more requirements of a transport network based on the determined requirements for the E2E service, and determining, based on the one or more requirements of the transport network, a plurality of resources of a transport network and one or more demarcation points of the transport network to be configured to support the E2E service.

[0016] According to another aspect of the disclosure, there is provided a second method for handling service requirements for a telecommunications network. The second method is computer-implemented. The second method comprises determining, based on first information, at least one network slice of a transport network to be used to support an E2E service of the telecommunications network. The first information is indicative of a plurality of resources of the transport network and one or more demarcation points of the transport network configured to support the E2E service.

[0017] According to another aspect of the disclosure, there is provided a method performed by a system. The method performed by the system comprises the first method described earlier and the second method described earlier. According to another aspect of the disclosure, there is provided a first entity configured to operate in accordance with the first method described earlier. In some embodiments, the first entity may comprise processing circuitry, and at least one memory for storing instructions which, when executed by the processing circuitry, cause the first entity to operate in accordance with the first method described earlier.

[0018] According to another aspect of the disclosure, there is provided a second entity configured to operate in accordance with the second method described earlier. In some embodiments, the second entity may comprise processing circuitry, and at least one memory for storing instructions which, when executed by the processing circuitry, cause the second entity to operate in accordance with the second method described earlier.

[0019] According to another aspect of the disclosure, there is provided a system. The system comprises the first entity described earlier and the second entity described earlier.

[0020] According to another aspect of the disclosure, there is provided a computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the first method described earlier and / or the second method described earlier.

[0021] According to another aspect of the disclosure, there is provided a computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry to cause the processing circuitry to perform the first method described earlier and / or the second method described earlier.

[0022] Thus, in the manner described above, improved techniques for handling service requirements for a telecommunications network are provided. Advantageously, E2E service requirements are mapped onto (e.g. a chain of) network resources (e.g. network functions (NFs)) and one or more demarcation points in the transport network (e.g. based on NRAR levels). As such, the techniques described herein improve the efficiency and effectiveness of the transport network, regardless of the underlying technology. Brief description of the drawings

[0023] For a better understanding of the techniques, and to show how they may be put into effect, reference will now be made, by way of example, to the accompanying drawings, in which:

[0024] Figure 1 is a block diagram illustrating a first entity according to an embodiment;

[0025] Figure 2 is a flow chart illustrating a first method according to an embodiment;

[0026] Figure 3 is a block diagram illustrating a second entity according to an embodiment;

[0027] Figure 4 is a flow chart illustrating a second method according to an embodiment;

[0028] Figure 5 is a block diagram illustrating a network architecture for providing an E2E service; and

[0029] Figures 6-10 are block diagrams illustrating operations of a system according to some embodiments.

[0030] Detailed

[0031] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

[0032] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject-matter disclosed herein, the disclosed subject-matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject-matter to those skilled in the art.

[0033] In some instances, detailed descriptions of well-known methods, entities, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more entities using hardware circuitry (e.g., analogue and / or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and / or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Entities that communicate using the air interface also have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

[0034] As described earlier, there are described herein improved techniques for handling service requirements for a telecommunications network.

[0035] The telecommunications network referred to herein can be any type of telecommunications network. For example, the telecommunications network referred to herein can be a mobile network, such as a fifth generation (5G) mobile network or any other generation mobile network. In some embodiments, the telecommunications network referred to herein can be or comprise one or both of a core network (CN) (e.g. fifth generation core (5GC)) or a radio access network (RAN). In some embodiments, the telecommunications network referred to herein can be a virtual network or an at least partially virtual network. Although some examples have been provided for the type of telecommunications network referred to herein, it will be understood that the telecommunications network referred to herein can be any other type of telecommunications network.

[0036] The techniques described herein involve one or more demarcation points. A demarcation point can be defined herein as a logical and / or a physical interface point of a network. For example, a demarcation point can correspond to an interface point between network domains (e.g. between a radio domain and a transport domain). In some embodiments, a demarcation point may coincide with a physical interface (e.g. a border node) of a network. For example, a demarcation point can be associated with one or more user plane (UP) paths associated with a service. In a particular example, a demarcation point may be associated with a UP path between antenna sites and other site(s) hosting user plane function(s) (UPF(s)) (e.g. in a 5G system) associated with a user plane session. Alternatively, or in addition, a demarcation point may be related to control plane traffic which is required to support a user plane. For example, a demarcation point may be related to control plane traffic between antenna sites and sites hosting core NFs (e.g. Access and Mobility Management Function (AMF) in a 5G system), and / or between sites hosting CN-related functionalities (e.g., taking a 5G system as an example, between AMF(s) and Session Management Functions, SMF(s), and / or between SMF(s) and UPF(s)).

[0037] The techniques described herein also involve an E2E service. An E2E service can be considered to be a data stream. An E2E service can have specific desired performance parameters (e.g. one or more quality of service (QoS) requirements) and / or resiliency requirements. As such, an E2E service can be associated with requirements for (e.g. for providing and / or supporting) the E2E service. In some embodiments, an E2E service is configured to pass through a sequence of network resources (e.g. network functions (NFs)). Herein, configuring a sequence of network resources to support an E2E service may be referred to as “chaining”. The sequence of network resources can be hosted in a number of (e.g. network) sites that are connected through a transport infrastructure.

[0038] An NF, as referred to herein, is a third generation partnership project (3GPP) adopted, or 3GPP defined, processing function in a network, which has defined functional behaviour and 3GPP defined interfaces. An NF can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure. For example, by using cloud-native technology, NFs can be virtualized and deployed as microservices in containers, making them easier to manage and scale. Herein, the term “NF” will be understood to cover each of these scenarios. For example, an NF may be an NF instance according to some embodiments and thus any features relating to an “NF” may equally apply to an “NF instance”. That is, the terms “NF” and “NF instance” used herein are interchangeable. Any references herein to a plurality of NFs may refer to a plurality of (e.g. functionally equivalent) NF instances. Some of the techniques described herein involve at least one network slice of a transport network. A network slice of a transport network can be referred to herein as a “transport slice”. A transport slice can be defined herein as a group of connections in the transport network that connect various endpoints. In some embodiments, a transport slice may be identified by an identifier (e.g. a transport slice identifier (ID)). In an example, a (e.g. transport) controller may provide an (e.g. abstract) interface to an E2E resource orchestrator, enabling the automation and programming of the delivery, optimisation, and monitoring of transport slices (e.g. throughout a fronthaul / backhaul and / or overlay network connectivity). In this way, a transport slice can be "exposed" to an E2E slice as an abstract network link with appropriate isolation and specific performance guarantees (e.g. service level agreements (SLAs)) described in terms of shared and / or dedicated network resources. More generally, a transport slice associated with an (e.g. E2E) service can comprise multiple transport connections. Proper identification of the demarcation points associated with the transport slice, and suitable management of said demarcation points, can be beneficial for meeting NRAR requirements. Furthermore, certain telecommunications network (e.g. RAN and / or CN) features may require additional transport connections to be implemented in addition to those associated with a final (e.g. E2E) service. For example, multi-connectivity solutions may require the use of multiple transport connections. Therefore, a final service in a deployment area, and its associated network functions, can require more transport connections associated with the same slice and (e.g. NRAR) service requirement.

[0039] An E2E network slice, as described herein, can itself comprise one or more slices. For example, an E2E slice can comprise one or more telecommunications network slices (e.g. a RAN slice and / or a CN slice), and / or one or more transport slices, as defined herein. The one or more slices comprised in an E2E slice can be coordinated, stitched, and / or mapped to each other to enable E2E service delivery and management. In some embodiments, an E2E network slice may be identified by an identifier (e.g. a slice ID). In some embodiments, an E2E orchestrator may coordinate one or more domain controllers responsible for the one or more slices (e.g. RAN slice(s), CN slice(s), and / or transport slice(s)) comprised in the E2E network slice.

[0040] Figure 1 illustrates a first entity 10 in accordance with some embodiments. The first entity 10 is for handling service requirements for a telecommunications network. The first entity 10 referred to herein can refer to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with the second entity referred to herein, and / or with other nodes or equipment to enable and / or to perform the functionality described herein. The first entity 10 referred to herein can, for example, be a physical node (e.g. a physical machine or server) or a virtual node (e.g. a virtual machine, VM). The first entity 10 may be referred to herein as an “NRAR transport resource handler” (NTRH) and / or a “NRAR handler” (NH). The first entity 10 can be configured to operate independently (e.g. outside of) the telecommunications network, as referred to herein, and / or the transport network, as referred to herein.

[0041] As illustrated in Figure 1 , the first entity 10 comprises processing circuitry (or logic) 12. The processing circuitry 12 controls the operation of the first entity 10 and can implement the method described herein in respect of the first entity 10. The processing circuitry 12 can be configured or programmed to control the first entity 10 in the manner described herein. The processing circuitry 12 can comprise one or more hardware components, such as one or more processors, one or more processing units, one or more multi-core processors and / or one or more modules. In particular implementations, each of the one or more hardware components can be configured to perform, or is for performing, individual or multiple steps of the method described herein in respect of the first entity 10. The processing circuitry 12 can be configured to run software to perform the method described herein in respect of the first entity 10. The software may be containerised. In this case, the processing circuitry 12 may be configured to run a container to perform the method described herein in respect of the first entity 10.

[0042] Briefly, the processing circuitry 12 of the first entity 10 is configured to receive a request for an end-to-end (E2E) service to be delivered using the telecommunications network, and determine requirements for the E2E service based on the received request. The requirements for the E2E service comprise a resiliency for the E2E service and an availability for the E2E service. The processing circuitry 12 of the first entity 10 is further configured to determine one or more requirements of a transport network based on the determined requirements for the E2E service, and determine, based on the one or more requirements of the transport network, a plurality of resources of the transport network and one or more demarcation points of the transport network to be configured to support the E2E service.

[0043] As illustrated in Figure 1 , the first entity 10 may optionally comprise a memory 14. The memory 14 of the first entity 10 can comprise a volatile memory or a non-volatile memory. The memory 14 of the first entity 10 may comprise a non-transitory media. Examples of the memory 14 of the first entity 10 include, but are not limited to, a random access memory (RAM), a read only memory (ROM), a mass storage media such as a hard disk, a removable storage media such as a compact disk (CD) or a digital versatile disk (DVD), and / or any other memory.

[0044] The processing circuitry 12 of the first entity 10 can be communicatively coupled (e.g. connected) to the memory 14 of the first entity 10. The memory 14 of the first entity 10 may be for storing program code or instructions which, when executed by the processing circuitry 12 of the first entity 10, cause the first entity 10 to operate in the manner described herein in respect of the first entity 10. For example, the memory 14 of the first entity 10 may be configured to store program code or instructions that can be executed by the processing circuitry 12 of the first entity 10 to cause the first entity 10 to operate in accordance with the method described herein in respect of the first entity 10. Alternatively or in addition, the memory 14 of the first entity 10 can be configured to store any information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry 12 of the first entity 10 may be configured to control the memory 14 of the first entity 10 to store any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0045] As illustrated in Figure 1 , the first entity 10 may optionally comprise a communications interface 16. The communications interface 16 of the first entity 10 can be communicatively coupled (e.g. connected) to the processing circuitry 12 of the first entity 10 and / or the memory 14 of the first entity 10. The communications interface 16 of the first entity 10 may be operable to allow the processing circuitry 12 of the first entity 10 to communicate with the memory 14 of the first entity 10 and / or vice versa. Similarly, the communications interface 16 of the first entity 10 may be operable to allow the processing circuitry 12 of the first entity 10 to communicate with any one or more nodes (e.g. the second entity) referred to herein and / or any other node. The communications interface 16 of the first entity 10 can be configured to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry 12 of the first entity 10 may be configured to control the communications interface 16 of the first entity 10 to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. Although the first entity 10 is illustrated in Figure 1 as comprising a single memory 14, it will be appreciated that the first entity 10 may comprise at least one memory (i.e. a single memory or a plurality of memories) 14 that operate in the manner described herein. Similarly, although the first entity 10 is illustrated in Figure 1 as comprising a single communications interface 16, it will be appreciated that the first entity 10 may comprise at least one communications interface (i.e. a single communications interface or a plurality of communications interfaces) 16 that operate in the manner described herein. It will also be appreciated that Figure 1 only shows the components required to illustrate an embodiment of the first entity 10 and, in practical implementations, the first entity 10 may comprise additional or alternative components to those shown.

[0046] Figure 2 illustrates a method in accordance with some embodiments. The method is for handling service requirements for a telecommunications network. The first entity 10 described earlier with reference to Figure 1 can be configured to operate in accordance with the method of Figure 2. The method can be performed by or under the control of the processing circuitry 12 of the first entity 10.

[0047] With reference to Figure 2, as illustrated by step 102, a request for an E2E service to be delivered using the telecommunications network is received. The first entity (e.g., the processing circuitry 12 of the first entity 10) may perform receipt of the request (e.g., via the communications interface 16 of the first entity 10).

[0048] As illustrated by step 104 of Figure 2, requirements for the E2E service are determined based on the received request. The first entity (e.g., the processing circuitry 12 of the first entity 10) may perform the determination of the requirements for the E2E service. The requirements for the E2E service comprise a resiliency for the E2E service and an availability for the E2E service. The received request may comprise the requirements for the E2E service (e.g. explicitly). For example, the request for the E2E service to be delivered may be detailed and have the requirements for the E2E service specified therein. In some cases, the request may comprise information indicative of the E2E service (e.g. an E2E service identity) for which the requirements for the E2E service are to be determined (e.g. as described with reference to step 106 of Figure 2 below).

[0049] As illustrated by step 106 of Figure 2, one or more requirements of a transport network are determined based on the determined requirements for the E2E service. The first entity (e.g., the processing circuitry 12 of the first entity 10) may perform the determination of the requirements of the transport network. As illustrated by step 108 of Figure 2, a plurality of resources of the transport network and one or more demarcation points of the transport network to be configured to support the E2E service are determined based on the one or more service requirements of the transport network. The first entity 10 (e.g., the processing circuitry 12 of the first entity 10) may perform the determination of the plurality of resources of the transport network and one or more demarcation points of the transport network. Herein, determining the plurality of resources of the transport network and the one or more demarcation points of the transport network can be referred to as a “translation” or “mapping” of the requirements for the E2E service into transport resources (e.g. the plurality of resources of the transport network). As such, the determination as described with reference to block 108 of Figure 2 can be referred to herein as a “translation” or “mapping”. Thus, in the manner described above with reference to Figure 2, NRAR requirements for the E2E service can be mapped to a plurality of network resources (e.g. a slice domain of the transport network).

[0050] Determining the plurality of resources in step 108 may comprise determining a first resource and a second resource. The second resource may be, for example, to be configured to support the E2E service if the first resource is unavailable. Therefore, the second resource may be referred to herein as a “recovery resource” and / or “backup resource”, and the first resource may be referred to herein as a “primary resource”. As such, recovery resources may be automatically determined (e.g. marked) for supporting the E2E service. A recovery resource can be shared with one or more primary resources. The sharing of the recovery resource can be performed, for example, according to a technology transport domain requirement and / or the one or more service requirements (e.g. NRAR requirements).

[0051] Determining the one or more demarcation points in step 108 may comprise determining a first ingress demarcation point and a second ingress demarcation point. The second ingress demarcation point may be, for example, configured to support the E2E service if the first ingress demarcation point is unavailable. Herein, an ingress demarcation point of a transport network can be defined as a demarcation point through which the E2E service accesses (e.g. enters) the transport network. An ingress demarcation point may be referred to herein as an “ingress point”. An egress demarcation point can be defined as a demarcation point through which the E2E service leaves (e.g. exits) the transport network. An egress demarcation point may be referred to herein as an “egress point”. As such, in some examples, an E2E service may be conveyed across the transport network(s) by traversing a series of ingress points and egress points (e.g. at a border of the transport network(s) (domains)). Herein, demarcation points of a transport network (domain) can be referred to as “transport demarcation points”. When mapping resiliency requirements (e.g. from an E2E slice dimension to a transport slice dimension), there may be many demarcation points that can potentially be involved in supporting the construction of E2E paths. In some examples, some of these demarcation points may be associated with E2E service recovery.

[0052] Although not illustrated in Figure 2, the method may comprise configuring the plurality of resources and the one or more demarcation points to support the E2E service. The first entity 10 (e.g., the processing circuitry 12 of the first entity 10) may perform the configuration. Configuring the plurality of resources and the one or more demarcation points may comprise initiating transmission of first information indicative of the plurality of resources and the one or more demarcation points towards a node (e.g. the second entity referred to herein) of the telecommunications network. The first entity 10 (e.g., the processing circuitry 12 of the first entity 10) may initiate transmission of the first information (e.g. via the communications interface 16 of the first entity 10). Herein, the term “initiate” can mean, for example, cause or establish. Thus, the first entity 10 (e.g., the processing circuitry 12 of the first entity 10) can be configured to itself transmit the first information (e.g. via the communications interface 16 of the first entity 10) or can be configured to cause another entity or node to transmit the first information.

[0053] The requirements determined for the E2E service may comprise a parameter indicative of the resiliency for the E2E service and a parameter indicative of the availability for the E2E service. The parameter indicative of the resiliency for the E2E service may comprise a shared risk link group (SRLG) parameter. The requirements determined for the E2E service may also comprise a reliability for the E2E service. The requirements determined for the E2E service may specify a parameter indicative of the reliability for the E2E service. In some examples, the requirements for the E2E service may be dynamically specified (e.g. in the received request) with any one or more of the parameter indicative of resiliency for the E2E service, the parameter indicative of availability for the E2E service, and the parameter indicative of reliability for the E2E service. The request may comprise information indicative of a requirement to provide the E2E service via a set of network functions (NFs) of the telecommunications network, and / or a requirement to provide the E2E service via one or more demarcation points of the telecommunications network. The set of NFs can be an ordered sequence (e.g. chain) of NFs to be used to provide the E2E service.

[0054] Although not illustrated in Figure 2, based on the determined requirements for the E2E service, one or more demarcation points of the telecommunications network, to be configured to support the E2E service, may be determined. Although also not illustrated in Figure 2, the request for the E2E service may be received at an application level (e.g. from a vertical network service, an over-the-top network service, etc.). In some examples, the request for the E2E service to be delivered may be from a network provider that acts as a broker towards the application level. The E2E service may be associated with an identifier (e.g. an E2E service ID).

[0055] Although not illustrated in Figure 2, the method may comprise receiving second information indicative of a capability of the transport network to provide the one or more service requirements. Thus, the first entity 10 (e.g., the processing circuitry 12 of the first entity 10) may receive the second information (e.g. via the communications interface 16 of the first entity 10). The second information can be received from the transport network. Therefore, in an example, the first entity 10 can be provided with an exposition view of the (e.g. resiliency and / or availability) capability of the transport network. The first entity 10 (e.g. NTRH) can handle the determination of resources and one or more demarcation points of the transport network according to the second information.

[0056] Figure 3 illustrates a second entity 20 in accordance with some embodiments. The second entity 20 is for handling service requirements for a telecommunications network. The second entity 20 referred to herein can refer to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with the first entity 10 referred to herein, and / or with other nodes or equipment to enable and / or to perform the functionality described herein. The second entity 20 referred to herein can, for example, be a physical node (e.g. a physical machine or server) or a virtual node (e.g. a virtual machine, VM). The second entity 20 may be referred to herein as an “NRAR transport slice manager” (NTSM). The second entity 20 can be configured to operate independently (e.g. outside of) the telecommunications network, as referred to herein, and / or the transport network, as referred to herein. As illustrated in Figure 3, the second entity 20 comprises processing circuitry (or logic) 22. The processing circuitry 22 controls the operation of the second entity 20 and can implement the method described herein in respect of the second entity 20. The processing circuitry 22 can be configured or programmed to control the second entity 20 in the manner described herein. The processing circuitry 22 can comprise one or more hardware components, such as one or more processors, one or more processing units, one or more multi-core processors and / or one or more modules. In particular implementations, each of the one or more hardware components can be configured to perform, or is for performing, individual or multiple steps of the method described herein in respect of the second entity 20. The processing circuitry 22 can be configured to run software to perform the method described herein in respect of the second entity 20. The software may be containerised according to some embodiments. Thus, the processing circuitry 22 may be configured to run a container to perform the method described herein in respect of the second entity 20.

[0057] Briefly, the processing circuitry 22 of the second entity 20 is configured to determine, based on first information, at least one network slice of a transport network to be used to support an end-to-end (E2E) service of the telecommunications network. The first information is indicative of a plurality of resources of the transport network and one or more demarcation points of the transport network configured to support the E2E service.

[0058] As illustrated in Figure 3, the second entity 20 may optionally comprise a memory 24. The memory 24 of the second entity 20 can comprise a volatile memory or a non-volatile memory. The memory 24 of the second entity 20 may comprise a non-transitory media. Examples of the memory 24 of the second entity 20 include, but are not limited to, a random access memory (RAM), a read only memory (ROM), a mass storage media such as a hard disk, a removable storage media such as a compact disk (CD) or a digital versatile disk (DVD), and / or any other memory.

[0059] The processing circuitry 22 of the second entity 20 can be communicatively coupled (e.g. connected) to the memory 24 of the second entity 20. The memory 24 of the second entity 20 may be for storing program code or instructions which, when executed by the processing circuitry 22 of the second entity 20, cause the second entity 20 to operate in the manner described herein in respect of the second entity 20. For example, the memory 24 of the second entity 20 may be configured to store program code or instructions that can be executed by the processing circuitry 22 of the second entity 20 to cause the second entity 20 to operate in accordance with the method described herein in respect of the second entity 20. Alternatively or in addition, the memory 24 of the second entity 20 can be configured to store any information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry 22 of the second entity 20 may be configured to control the memory 24 of the second entity 20 to store any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0060] As illustrated in Figure 3, the second entity 20 may optionally comprise a communications interface 26. The communications interface 26 of the second entity 20 can be communicatively coupled (e.g. connected) to the processing circuitry 22 of the second entity 20 and / or the memory 24 of the second entity 20. The communications interface 26 of the second entity 20 may be operable to allow the processing circuitry 22 of the second entity 20 to communicate with the memory 24 of the second entity 20 and / or vice versa. Similarly, the communications interface 26 of the second entity 20 may be operable to allow the processing circuitry 22 of the second entity 20 to communicate with any one or more nodes (e.g. the first entity 10) referred to herein and / or any other node. The communications interface 26 of the second entity 20 can be configured to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry 22 of the second entity 20 may be configured to control the communications interface 26 of the second entity 20 to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0061] Although the second entity 20 is illustrated in Figure 3 as comprising a single memory 24, it will be appreciated that the second entity 20 may comprise at least one memory (i.e. a single memory or a plurality of memories) 24 that operate in the manner described herein. Similarly, although the second entity 20 is illustrated in Figure 3 as comprising a single communications interface 26, it will be appreciated that the second entity 20 may comprise at least one communications interface (i.e. a single communications interface or a plurality of communications interfaces) 26 that operate in the manner described herein. It will also be appreciated that Figure 3 only shows the components required to illustrate an embodiment of the second entity 20 and, in practical implementations, the second entity 20 may comprise additional or alternative components to those shown. Figure 4 illustrates a method in accordance with some embodiments. The method is for handling service requirements for a telecommunications network. The second entity 20 described earlier with reference to Figure 3 can be configured to operate in accordance with the method of Figure 4. The method can be performed by or under the control of the processing circuitry 22 of the second entity 20.

[0062] With reference to Figure 4, as illustrated by step 202, at least one network slice of a transport network to be used to support an E2E service of the telecommunications network is determined. The second entity 20 (e.g., the processing circuitry 22 of the second entity 20) may perform the determination. The first information is indicative of a plurality of resources of the transport network and one or more demarcation points of the transport network configured to support the E2E service.

[0063] The first information can be based on requirements for the E2E service. The requirements for the E2E service may comprise a resiliency for the E2E service and an availability for the E2E service, as described herein. Alternatively, or in addition, the first information can be based on one or more requirements of the transport network, as described herein. The requirements for the E2E service may comprise a reliability for the E2E service.

[0064] The plurality of resources may comprise a first resource and a second resource, as described herein. The one or more demarcation points may comprise a first ingress demarcation point and a second ingress demarcation point, as described herein.

[0065] The at least one network slice may comprise the plurality of resources and the one or more demarcation points. As such, the at least one network slice can comprise the plurality of resources and the one or more demarcation points to be configured to support the E2E service. The at least one network slice may comprise a plurality of network slices of the transport network. In general, certain transport technologies (e.g. of a transport network) may allow lower priority traffic and / or services to use secondary (e.g. recovery) resources of an E2E service when primary resources are operating normally for the E2E service. Thus, in embodiments in which the at least one network slice comprises a plurality of network slices, each of the plurality of network slices may be identified as (e.g. mutually) correlated. In this way, the E2E service can be supported with improved resiliency. Although not illustrated in Figure 4, the method may comprise generating an identifier for the at least one network slice. Thus, the second entity 20 (e.g., the processing circuitry 22 of the second entity 20) may perform the generation. The identifier for the at least one network slice may be referred to herein as a “transport slice ID”.

[0066] Step 202 may comprise determining a first network slice and a second network slice. The second network slice can be configured to be used if the first network slice is unavailable. The first network slice and the second network slice may be referred to herein as “cross correlated slices”. Alternatively, or in addition, the first network slice may be referred to herein as a “primary slice”, and the second network slice may be referred to herein as a “recovery slice”. Thus, multiple network slices of the transport network can include resources for supporting the E2E service. The second network slice, in some examples, can include recovery resources, as defined herein, and / or recovery paths for supporting the E2E service. The method may comprise determining a plurality of second network slices. The second network slices(s) may be correlated to the (e.g. same) first network slice (primary slice). In the event of a fault occurring at the first network slice, the slice containing the recovery resources can be updated accordingly.

[0067] Although not illustrated in Figure 4, the method may comprise receiving the first information, as described herein. Thus, the second entity 20 (e.g., the processing circuitry 22 of the second entity 20) may receive the first information (e.g. via the communications interface 26 of the second entity 20). The first information may be received from the first entity 10, as described herein. The E2E service can be associated with a service identifier as described herein. The first information may be determined as described with reference to Figure 2.

[0068] Thus, in the manner described herein, it is possible to automate the determination of resources and demarcation points of a transport network based on E2E service requirements. For example, a resiliency requirement (e.g. and other NRAR requirements) for the E2E service can be automatically mapped to the transport network. In the manner described herein, information can be shared information about an E2E slice and its corresponding transport flows at both the E2E level and in transport control and transport slice management. Transport resources can also be mapped with service requests for an E2E service (e.g. once the requirements for the E2E service are translated into transport resources). In some examples, in order to account for resiliency requirements, resources of the transport network can be associated with primary and backup resources for (e.g. flows of) the E2E service. Moreover, the primary and backup resources can be correlated such that backup resources can be effectively utilised to support the E2E service, if required (e.g. in the event of a failure of the primary resources).

[0069] There is also provided a system comprising the first entity 10 described herein and the second entity 20 described herein. A method performed by the system can comprise the method described herein in respect of Figure 2 and the method described herein in respect of Figure 4.

[0070] Figure 5 illustrates an example of a system showing a network architecture configured to provide an E2E service. The system may comprise a plurality of sites (“Radio”) 304, 306, 308 and one or more transport networks 310, 312. In Figure 5, the telecommunications network, as described herein, comprises the plurality of sites 304, 306, 308. Although the sites 304, 306, 308 are illustrated as radio networks in Figure 5, it will be understood that the this is merely an example and that sites 304, 306, 308 could be any type of domain (e.g. of a telecommunications network). The transport networks 310, 312 provide a connection between the sites 304, 306, 308. Although Figure 5 illustrates separate transport networks 310, 312, it will be understood that this is merely an example and that the system may comprise any number of transport networks. In particular, the radio sites 304, 306, 308 can be interconnected via a single (i.e. the same) transport network 310. Furthermore, although Figure 5 illustrates three separate sites 304, 306, 308, it will be understood that, in some examples, as described herein, the system may comprise any number of sites. Although the plurality of sites 304, 306, 308 illustrated in Figure 5 may correspond to a plurality of (e.g. radio) networks, it will be understood that the sites 304, 306, 308 may be described herein as comprised in a (e.g. single) telecommunications network. As also illustrated in Figure 5, the system may comprise an orchestrator node (“E2E Orchestrator / NMS”) 302.

[0071] A site, as referred to herein, can comprise one or more servers and / or nodes. The one or more servers and / or nodes can support one or more virtual and / or physical (e.g. network) functions. For example, the one or more virtual and / or physical functions may comprise a cloud native function (CNF) (e.g., a container), a virtual network function (VNF), and / or a physical network function (PNF). A (e.g. radio) site can comprise any type of site, for example an antenna site, a radio processing site (e.g. baseband site), and / or any other type of site. For example, a site may comprise (e.g. host) both RAN and CN functions.

[0072] As illustrated in Figure 5, transport (e.g. transport technology) can connect resources (e.g. functions) both inside radio sites (“intra-site transport”) and between different (e.g. radio) sites (“inter-site transport”). Redundancy can operate at a resource (e.g. function) level and / or at a connection level. For example, providing redundancy at the resource level may involve duplicating NFs. Alternatively, or in addition, providing redundancy at the connection level may involve generating alternative paths (e.g. for the E2E service). Intra-site recovery can be useful for protecting the system from internal faults, whereas inter-site recovery can be useful for protecting the system from faults among radio sites (e.g. by duplicating the entities to be protected). In an example, network entities can be protected by duplicating specific functions (e.g. rather than an entire (e.g. physical and / or virtual) node and / or server).

[0073] In Figure 5, the system includes one or more demarcation points 314, 316, 318, 320. For an E2E service, a demarcation point may be associated with, for example, an antenna site and / or a core system. However, the configuration / association of the demarcation points may vary depending on deployment of radio and / or core functions. The system can comprise a plurality of (e.g. different) demarcation points. The E2E service can be conveyed across the transport network(s) via the demarcation points. As noted above, the demarcation points can be described as “ingress points” and / or “egress points”. As such, the E2E service can “traverse” a series of points (i.e. ingress points and egress points) at the border of the transport domains. Such points at the border of transport domains can be referred to herein as “transport demarcation points”.

[0074] A demarcation point may be a point at which one network domain (e.g., Transport domain) ends and connects to another network domain (e.g. RAN / Core network) delimiting borders between domains in terms of responsibility and specific functions realised in (or by) the domain. Such demarcation points may correspond to a node, one or more physical interfaces of a node, and / or one or more virtual interfaces of a node. A demarcation point may be described as an E2E demarcation point or an internal demarcation point. Herein, an E2E demarcation point can be defined as a demarcation point configured and / or located between a transport network and a domain of the telecommunications network (e.g. a radio site and / or a core network site, for example). Herein, an internal demarcation point can be defined as specific to the transport network. For example, an internal demarcation point may be configured and / or located between domains and / or autonomous systems (e.g. border gateway protocol (BGP)) in the transport network.

[0075] Figure 6 illustrates a system according to some embodiments. In more detail, Figure 6 illustrates a network system architecture for providing an E2E service.

[0076] As illustrated in Figure 6, the system may comprise the first entity (“NRAR Transport Resource Handler (NTSM)”) 10 and the second entity (“NRAR Transport Slice Manager (NTSM)”) 20, as described above. In Figure 6, the first entity 10 and the second entity 20 are shown as separate entities. However, it will be understood that this is merely an example and that, in some embodiments, the first entity 10 and the second entity 20 may be the same entity and / or at the same location (e.g. comprised in the same entity).

[0077] The system in Figure 6 may comprise a telecommunications network, and a transport network 414. In Figure 6, the telecommunications network comprises a plurality of (e.g. radio) sites (“Radio”) 412, 416, as defined herein. Although not illustrated in Figure 6, the plurality of sites 412, 416 may comprise a RAN site (e.g. site 412) and / or a CN site (e.g. site 416). In Figure 6 the sites 412, 416 can comprise primary and backup resources (e.g. of the telecommunications network). In Figure 6, the primary and backup resources comprise NFs (“CNF”, “VNF”, “PNF”) as described herein.

[0078] As also illustrated in Figure 6, the system comprises one or more radio control nodes (“Radio Control”) 406, 410. The one or more radio control nodes 406, 410 can be configured to control the respective sites 412, 416 of the telecommunications network. In Figure 6, the system may comprise a transport control node (“Transport Control (SDN)”) 408. The transport control node 408 may be configured to act as a controller of the transport network 414. The transport control node 408 may control the transport network 414 based on software defined networking (SDN). Similar to other entities described herein, the transport control node 408 may be enriched by NRAR specific functionalities (e.g. related to resilience).

[0079] As illustrated in Figure 6, the second entity 20 may be comprised in a manager node (“Transports Slice Manager (TSM)”) 402. However, this is merely an example and it will be understood that the second entity 20 may alternatively be comprised in another type of node, or may be a standalone entity. The manager node 402 may be a functional entity (e.g. block) for managing transport slice instances throughout their lifecycle. An (e.g. primary) objective of the manager node 402 can be to ensure that network slices in the transport network 414 meet certain (e.g. service) requirements. These requirements may be expressed by service requesters by selecting appropriate transport resources to fit desired E2E service requirements (e.g. QoS).

[0080] As also illustrated in Figure 6, the system may comprise an orchestrator node (“E2E Orchestrator / NMS”) 404. The orchestrator node 404 may be configured (e.g. through an embedded E2E slice management function) to initiate transmission of (e.g. send) E2E service requirements to other entities / nodes in the system. For example, the orchestrator node 404 may initiate transmission of service requirements to the radio control nodes 406, 410, the manager node 402, and / or any other entity / node in the system. As illustrated in Figure 6, the orchestrator node 404 may comprise a network management system (NMS).

[0081] As described herein with reference to Figure 2, the first entity 10 can be configured to determine, based on one or more requirements of the transport network, a plurality of resources of the transport network 414 and one or more demarcation points 418, 420, 422, 424 of the transport network 414 to be configured to support the E2E service. As such, the first entity 10 (“NTRH”) can be configured to translate service requirements (e.g. comprised in a service request) into transport technology. The determination (e.g. translation) can be performed according to specific transport technology (e.g. comprised in the transport network 414). The first entity 10 can initiate transmission of first information, as described herein. As such, the first entity 10 can expose a transport capability (e.g. of the transport network 414) to facilitate management of service requirements (e.g. NRAR requirements). Although illustrated as a separate entity in Figure 6, the first entity 10 can alternatively be integrated with the orchestrator node 404. Alternatively, or in addition, the first entity 10 (e.g. functionality) may be comprised in a service orchestrator and / or an NMS. The first entity 10 can receive E2E service requirements as input. In Figure 6, the first entity 10 is configured to communicate with the manager node 402 and the second entity 20 through the orchestrator node 404. However, it will be understood that this is merely an example system architecture and that the functionality and the communication between the nodes and entities of the system (e.g. the first entity 10 and / or the second entity 20) can also apply to different types of (e.g. network) system architecture. An orchestrator (e.g. orchestrator node 404) and / or slice manager (e.g. manager node 402) may map E2E service requirements onto (e.g. a chain of) NFs as described herein. The NFs can include functions dedicated to intra-site recovery as defined herein.

[0082] As described herein, an E2E service is associated with requirements for the E2E service (e.g. service requirements). As also described herein, the requirements for the E2E service can be used to map the E2E service onto a sequence of resources (e.g. NFs). In an example, an E2E service (e.g. identified by a service ID in a relevant deployment area) can have a set of requirements to be mapped onto a sequence of resources (e.g. NFs). Traffic for the E2E service can be directed through the sequence of resources (e.g. NFs). Each resource (e.g. NF) in the sequence of resources (e.g. NFs) may perform a designated task on the traffic for the E2E service before forwarding it to the next resource (e.g. NF) in the sequence. According to the techniques described herein, once the sequence of resources (e.g. NFs) is identified, the resources can be connected, for example, through a path that crosses a sequence of one or more demarcation points.

[0083] The handling of service requirements, as described herein, can involve two (e.g. distinct) phases. These two phases can be referred to herein as a “configuration” phase and an “operational” phase. The configuration phase may comprise the determination of the plurality of resources of the transport network and the one or more demarcation points to be configured to support the E2E service, as described herein. The operational phase may comprise the actual (re)configuration and / or management of the plurality of resources and the one or more demarcation points to support the E2E service. For example, the operational phase may involve actively supporting (e.g. operating) the E2E service.

[0084] Aspects of the configuration phase will now be described with reference to the system illustrated in Figure 6. For the desired E2E service, the orchestrator node 404 may determine (e.g. define and / or identify) a plurality (e.g. sequence) of demarcation points 418, 420, 422, 424 which could be used to support the E2E service. The orchestrator node 404 may initiate transmission of information identifying the determined plurality of demarcation points 418, 420, 422, 424 towards the first entity 10, the second entity 20, and / or the manager node 402. Thus, the first entity 10, the second entity 20, and / or the manager node 402 may receive the information identifying the plurality of demarcation points 418, 420, 422, 424 from the orchestrator node 404. As illustrated in Figure 6, the plurality of demarcation points 418, 420, 422, 424 can be of the transport network 414.

[0085] The orchestrator node 404 may initiate transmission of transport requirements (e.g. NRAR requirements) associated with the plurality of demarcation points 418, 420, 422, 424 towards the manager node 402 and / or the second entity 20. Thus, the manager node 402 and / or the second entity 20 may receive the transport requirements from the orchestrator node 404. The manager node 402 and / or the second entity 20 may instantiate at least one network slice of the transport network 414, as defined herein. The at least one network slice of the transport network 414 can be referred to herein as at least one “transport slice”. The second entity 20 may associate the at least one transport slice with the transport requirements.

[0086] The orchestrator node 404 may initiate transmission of the (e.g. NRAR) requirements for the E2E service (e.g. comprised in the request for the E2E service to be delivered) towards the first entity 10. Thus, the first entity 10 may receive the requirements for the E2E service from the orchestrator node 404. The information identifying the plurality of demarcation points 418, 420, 422, 424 may be received separately, by the first entity 10, from the requirements for the E2E service. However, the information identifying the plurality of demarcation points 418, 420, 422, 424 and the requirements for the E2E service may alternatively be received simultaneously (e.g. comprised in the request as described herein) by the first entity 10.

[0087] As described herein, the first entity 10 may determine, based on one or more requirements of the transport network (determined based on the determined requirements for the E2E service), a plurality of resources of the transport network 414 and one or more demarcation points 418, 420 of the transport network 414 to be configured to support the E2E service. Therefore, in an example, the first entity 10 can translate the (e.g. NRAR) requirements for the E2E service into (e.g. NRAR) transport requirements. The first entity 10 may initiate transmission of first information, as defined herein, towards the transport control node 408 and / or the second entity 20. Thus, the transport control node 408 and / or the second entity 20 may receive the first information from the first entity 10.

[0088] The transport control node 408 may receive (e.g. from the first entity 10) information (e.g. a transport slice ID) identifying the at least one network slice of the transport network 414, as defined herein. The at least one network slice of the transport network 414 may include a plurality of slices. For example, the at least one network slice of the transport network 414 may include multiple (e.g. cross-correlated) slices for primary and backup resources. The transport control node 408 may configure the plurality of (e.g. internal) resources to support the E2E service, as described herein. The transport control node 408 may define the plurality of resources of the transport network 414 as one or more several paths associated to the one or more demarcation points 418, 420. Therefore the transport control node 408 may be configured to perform the configuration of the plurality of resources and the one or more demarcation 418, 420 points of the transport network 414 (e.g. based on information received from the first entity 10 and / or the second entity 20). The transport control node 408 may perform the configuration according to a resiliency capability of the transport network 414.

[0089] According to a capability of the transport network 414 and / or the requirements for the E2E service, some of the plurality of resources (e.g., dedicated protection paths, shared path with low priority traffic, etc) of the transport network 414 (e.g. backup paths) can be used for less valuable traffic (e.g. via resource sharing). Some or all of the (e.g. shared) plurality of resources of the transport network 414 may be associated (e.g. by the transport control node) with information indicative of whether said resources are shared. In an example, a resource of the plurality of resources of the transport network 414 can be associated with the following information: whether the resource is associated with primary path(s) that share backup resources, a service ID, and / or a transport slice ID.

[0090] The transport control node 408 may communicate to the manager node 402 information (e.g. a list) indicative of a primary resource and a backup resource. Each of the resources may be identified with a corresponding ID (e.g. indicative of cross-correlated slices). The manager node 402 may store the information received from the transport control node 408. The information can be used, by the manager node 402, to manage transport slices (e.g. during the lifecycle of an E2E service).

[0091] A resiliency "level" of a (e.g. selected) transport slice can be implicitly included in the slice's performance characteristics, such as, resiliency (e.g., 1 :N), packet loss, and / or compatible service interruption time (e.g. 50 ms). Alternatively, or in addition, the resiliency level of a transport slice can be indicated by a parameter (e.g. that explicitly indicates a fault correlation among resources). For example, if two optic fibers in a transport network run in the same duct, they share a high likelihood of simultaneous failure (e.g. in the event that someone were to dig into the duct). Therefore, these two resources may be unsuitable to use as a primary resource and a backup (recovery) resource for the same network slice. Therefore, a shared risk link group (SRLG) parameter could be used to quantify a resilience of a network slice of the transport network.

[0092] After the configuration phase, as described above, E2E service traffic may enter the telecommunications network. As such, the operational phase, as mentioned above, may be initiated. The performance of the operational phase may depend on the connectivity among the one or more demarcation points of the transport network. Thus, as described with reference to Figures 7-10 below, different cases can be considered in relation to transport technology.

[0093] The plurality of resources comprised in the at least one network slice of the transport network 414 can include both primary resources and recovery (backup) resources. Each of the plurality of resources can be associated with at least one demarcation point of the one or more demarcation points 418, 420. As such, recovery resources can be dedicated and / or reserved. The association (e.g. mapping) between the one or more demarcation points 418, 420 and the plurality of resources can be used in case of a fault (e.g. in the transport network 414). In the event of a fault, the transport control node 408 may update a resource status accordingly. For example, if the fault causes a resource to become unavailable, the transport control node 408 can update the status of said resource accordingly (i.e. to indicate that said resource is unavailable). The transport control node 408 may notify the manager node 402 of the updated status.

[0094] In Figure 6, communication between the transport control node 408 and the manager node 402 is shown as being performed via the orchestrator node 404. However, it will be understood that this is merely an example communication path and that the transport control node 408 may (e.g. directly or indirectly) communicate with the manager node 402 via any other suitable communication path. For example, the transport control node 408 may communicate directly (e.g. without an intermediary node and / or entity) with the manager node 402.

[0095] Multiple network slices (e.g. including recovery resources and / or paths) can be correlated to the same primary network slice. In the event of a fault, the network slice comprising the recovery resources can be updated accordingly. In an example, if recovery resources are shared with (e.g. service) traffic which has a low priority, the transport control node 408 can manage the traffic accordingly (e.g., pre-empt a fault and / or support the lower priority traffic using alternative paths, etc.). The transport control node 408 may utilise (e.g. involve) the manager node 402 to assist in configuring an alternative (backup) option.

[0096] A recovery resource and / or a recovery path may not be associated with a network slice. For example, resources and / or paths which are not used (e.g. for the E2E service) and / or configured (e.g. to support the E2E service) may not be associated with a network slice. Therefore, a slice (e.g. the at least one slice of the transport network 414) may comprise a primary resource and / or primary path, and a reference to a respective recovery resource and / or recovery path. When a fault occurs, the system may configure the (e.g. designed) recovery resources and / or recovery paths (e.g. for supporting the E2E service) and update the status of primary and recovery resources and / or paths. In some embodiments, (e.g. according to a guaranteed level of the E2E service) more than one recovery resource and / or recovery path may be associated to a primary resource and / or a primary path. In an example, when a new service requests (e.g. asks for) resources designated to another slice (e.g. for resiliency), the slice provided for the new service and the other slice can be designated as “correlated slices”. The system can update the status of such slices accordingly. Therefore, in some examples, network slices which comprise (e.g. share) one or more of the same resources may be referred to herein as “correlated slices”.

[0097] As described herein with reference to Figure 5, transport (e.g. transport technology) can connect resources (e.g. functions) both inside (e.g. radio) sites (“intra-site transport”) and between (e.g. different) sites (“inter-site transport”). As such, recovery (e.g. in response to unavailability of network resources) can involve intra-site recovery and / or inter-site recovery. In some examples, a resiliency requirement can affect both the recovery of intra-site and inter-site connectivity. Some examples of recovery will now be explained with reference to Figures 7-10. It will be understood that the embodiments illustrated in Figures 7-10 are merely examples implementations of the system and / or methods described herein, and that other example implementations are also possible.

[0098] Figure 7 is a block diagram illustrating operation of a system according to an embodiment that has primary and protection paths / resources for pairs of demarcation points. The system illustrated in Figure 7 is similar to the system as described with reference to Figure 5 above. The system illustrated in Figure 7 is configured to enable an E2E service to be provided. The system comprises an orchestrator node (“E2E Orchestrator / NMS”) 502, a first site (“Radio 1”) 504, a second site (“Radio 2”) 508, a transport network 506, and a plurality of demarcation points 510, 512, 514, 516 of the transport network 506. The first site 504 and the second site 508 can be comprised in a telecommunications network, as described herein. The entities and nodes shown in Figure 7 can be configured as described herein (e.g. with reference to Figures 5 and 6).

[0099] The first site 504 and the second site 508 comprise primary and backup site resources of the telecommunications network. The primary and backup site resources comprise NFs (“CNF”, “VNF”, “PNF”). In Figure 7 the backup site resources comprise duplicated versions of the primary site resources. The first site 504 connects to the second site 508 by (e.g. through) the transport network 506.

[0100] Lines 518 to 524 of Figure 7 represent a plurality of resources of the transport network 506 that have been determined (e.g. by the first entity 10) to be configured to support the E2E service. Each of the lines 518 to 524 represents a resource and / or a plurality of resources of the transport network 506. Lines 518 to 524 are referred to herein as “paths” or “resource paths”. Demarcation points 510, 512, 514, 516 of the transport network 506 have also been determined (e.g. by the first entity 10) and configured to support the E2E service. The determination of the plurality of resources and the demarcation points 510, 512, 514, 516 was based on one or more requirements of the transport network.

[0101] The plurality of resources of the transport network 506 comprise a first resource 518 (“Primary”) and a second resource 520 (“Protection”) associated with demarcation points 510, 512. The second resource 520 can be used to support the E2E service if the first resource 518 is unavailable. In the example of Figure 7, the plurality of resources also comprises another pair of resources 522, 524 that are associated with a different pair of demarcation points 514, 516. Resource 522 is a Primary resource that is used when ingress demarcation point 514 is used, and resource 524 is a Protection resource that is used when ingress demarcation point 514 is used and Primary resource 522 has failed or has a fault.

[0102] In the system illustrated in Figure 7, the Primary resource 518 and the first ingress demarcation point 510 are available, and these are used to provide the E2E service. Figure 8 is a block diagram illustrating operation of the system in Figure 7 in the event of a fault with the primary site resources of the first site 504. In particular, Figure 8 shows an example of intra-site recovery using the same demarcation points.

[0103] In the example illustrated in Figure 8, the unavailability of the primary site resources of the first site 504 is due to a server failure. However, it will be understood that this is merely an example and that other types of events could lead to the primary site resources of the first site 504 becoming unavailable.

[0104] As illustrated in Figure 8, the backup site resources of the first site 504 are used (e.g. activated) to support the E2E service in response to the unavailability of the primary site resources of the first site 504. As such, Figure 8 illustrates an example of resiliency, since the E2E service is still supported by the system even in the event of site resources (e.g. which previously supported the E2E service) becoming unavailable.

[0105] As illustrated in Figure 8, (e.g. radio) traffic associated with the E2E service from the backup site resources of the first site 504 can be routed through the same demarcation points 510, 512 of the transport network 506, and via the Primary resource 518 to reach the primary site functions of the second site 508.

[0106] Figure 9 is a block diagram illustrating alternative operation of the system in Figure 7 in the event of the fault with the primary site resources of the first site 504, e.g. a server failure. In particular, Figure 9 shows an example of intra-site recovery using different demarcation points.

[0107] In the example of Figure 9, the (e.g. radio) traffic of the E2E service from the backup site resources of the first site 504 are rerouted through different resources of the transport network 506 and different demarcation points of the transport network 506 in order to reach the (e.g. primary NFs of) second site 508. In particular, due to the failure of the primary site resources in the first site 504, the E2E service from the backup site resources is routed through demarcation points 514, 516 using Primary resource 522.

[0108] Figure 10 is a block diagram illustrating operation of the system in Figure 7 in the event of a fault / failure with the Primary resource 518 between demarcation points 510, 512. In particular, Figure 10 shows an example of inter-site recovery using the same demarcation points. As illustrated in Figure 10, the Primary resource 518 becomes unavailable (e.g. due to failure), and the Protection resource 520 is configured and used to support the E2E service. Thus, the unavailability (e.g. failure) of the first resource 520 is fully managed by the transport network 506.

[0109] Therefore, as shown in Figure 10, the (e.g. radio) traffic of the E2E service can be rerouted through a different path, relative to the path taken prior to the failure, within the transport network. It is noted that the one or more demarcation points 510, 512 used to support the E2E service are the same prior to and after the failure, which means the unavailability (e.g. failure) of the first resource 510 and recovery via the protection resource 520 is transparent with respect to the first and second (e.g. radio) sites 504, 508.

[0110] In addition to the entities 10, 20 shown in Figures 1 and 3, a computer program is also provided that comprises instructions which, when executed by processing circuitry (such as the processing circuitry 12 of the first entity 10 described herein and / or the processing circuitry 22 of the second entity 20 described herein), cause the processing circuitry to perform at least part of the methods described herein. The computer program may be embodied on a non-transitory machine-readable medium or a carrier to form a computer program product. The carrier can be any one of an electronic signal, an optical signal, an electromagnetic signal, an electrical signal, a radio signal, and a microwave signal.

[0111] The first entity functionality and / or second entity functionality described herein can be performed by hardware. Thus, the first entity 10 and / or second entity 20 described herein can be a hardware entity. However, it will also be understood that optionally at least part or all of the first entity 10 functionality and / or second entity 20 functionality described herein can be virtualised. For example, the functions performed by the first entity 10 and / or second entity 20 described herein can be implemented in software running on generic hardware that is configured to orchestrate the first entity functionality and / or second entity functionality described herein. Thus, the first entity 10 and / or second entity 20 described herein can be a virtual entity. At least part or all of the first entity 10 functionality and / or second entity 20 functionality described herein may be performed in a network enabled cloud. Thus, the method described herein can be realised as a cloud implementation. The first entity 10 functionality and / or second entity 20 functionality described herein may all be at the same location or at least some of the first entity 10 functionality and / or second entity 20 functionality may be distributed, e.g. the first entity 10 functionality and / or second entity 20 functionality may be performed by one or more different entities.

[0112] It will be understood that at least some or all of the method steps described herein can be automated. That is, at least some or all of the method steps described herein can be performed automatically. The method described herein is a computer-implemented method.

[0113] Therefore, as described herein, there are provided improved techniques for handling service requirements for a telecommunications network. Telecommunications networks and transport networks can take advantage of the improved techniques for the optimisation of resource usage based on service requirements of an E2E service, particularly when said service requirements comprise a resiliency requirement for the E2E service. Indeed, the improved techniques effectively handle (e.g. manage) resiliency in the transport domain, and takes into account E2E resiliency needs. Moreover, the improved techniques can be applied to any transport technology (e.g. or combination thereof), and are compatible with third-party transport domains and multidomain transport. As described with regards to some aspects of the improved techniques, automatic cross-slice management of primary and backup resources is enabled, which ensures that resiliency requirements are met without the need for complex operations.

[0114] In this way, the techniques described herein address the limitations of existing technology by providing automatic and dynamic handling of service requirements. More specifically, some of the techniques described herein provide for automatic and dynamic determination (e.g. identification) of demarcation points and / or mapping of a transport slice onto a (e.g. corresponding) E2E slice. In an example, for at least one network slice of a transport network, a set of resources associated with normal (e.g. no fault) operation and resiliency events can be determined (e.g. identified). Depending on, for example, transport domain technology and / or resiliency type, the set of resources can be shared with other slices to enable more effective handling of service requirements in telecommunications networks.

[0115] It should be noted that the above-mentioned embodiments illustrate rather than limit the techniques described herein, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

CLAIMS1. A computer-implemented method for handling service requirements for a telecommunications network, the method comprising: receiving (102) a request for an end-to-end, E2E, service to be delivered using the telecommunications network; determining (104) requirements for the E2E service based on the received request, wherein the requirements for the E2E service comprise a resiliency for the E2E service and an availability for the E2E service; determining (106) one or more requirements of a transport network (310, 312, 414, 506) based on the determined requirements for the E2E service; determining (108), based on the one or more requirements of the transport network (310, 312, 414, 506), a plurality of resources of the transport network (310, 312, 414, 506) and one or more demarcation points (314, 316, 318, 320, 418, 420, 422, 424, 510, 512, 514, 516) of the transport network (310, 312, 414, 506) to be configured to support the E2E service.

2. The method as claimed in claim 1, wherein determining the plurality of resources comprises: determining a first resource and a second resource, wherein the second resource is to be configured to support the E2E service if the first resource is unavailable.

3. The method as claimed in claim 1 or 2, wherein determining the one or more demarcation points (314, 316, 318, 320, 418, 420, 422, 424, 510, 512, 514, 516) comprises: determining a first ingress demarcation point (418, 510) and a second ingress demarcation point (422, 514), wherein the second ingress demarcation point (422, 514) is to be configured to support the E2E service if the first ingress demarcation point (418, 510) is unavailable.

4. The method as claimed in any of the preceding claims, the method comprising: configuring the plurality of resources and the one or more demarcation points(314, 316, 318, 320, 418, 420, 422, 424, 510, 512, 514, 516) to support the E2E service.

5. The method as claimed in claim 4, wherein the configuring comprises:initiating transmission of first information indicative of the plurality of resources and the one or more demarcation points (314, 316, 318, 320, 418, 420, 422, 424, 510, 512, 514, 516) towards a node of the telecommunications network.

6. The method as claimed in claim 1, wherein: the requirements determined for the E2E service comprise a parameter indicative of the resiliency for the E2E service and a parameter indicative of the availability for the E2E service.

7. The method as claimed in claim 6, wherein: the parameter indicative of the resiliency for the E2E service comprises a shared risk link group, SRLG, parameter.

8. The method as claimed in any of the preceding claims, wherein the requirements determined for the E2E service further comprise a reliability for the E2E service.

9. The method as claimed in claim 8, wherein: the requirements determined for the E2E service further comprise a parameter indicative of the reliability for the E2E service.

10. The method as claimed in any of the preceding claims, wherein the request comprises: information indicative of a requirement to provide the E2E service via a set of network functions, NFs, of the telecommunications network.

11. The method as claimed in claim 10, wherein: the set of NFs is an ordered sequence of NFs to be used to provide the E2E service.

12. The method as claimed in any of the preceding claims, wherein the method comprises: determining, based on the determined requirements for the E2E service, one or more demarcation points of the telecommunications network to be configured to support the E2E service.

13. The method as claimed in any of the preceding claims, the method comprising:receiving the request at an application level.

14. The method as claimed in any of the preceding claims, wherein: the E2E service is associated with an identifier.

15. The method as claimed in any of the preceding claims, the method comprising: receiving, from the transport network (310, 312, 414, 506), second information indicative of capabilities and / or availabilities of the transport network (310, 312, 414, 506); and wherein the step of determining the plurality of resources and one or more demarcation points (314, 316, 318, 320, 418, 420, 422, 424, 510, 512, 514, 516) of the transport network (310, 312, 414, 506) is based on the second information.

16. A computer-implemented method for handling service requirements for a telecommunications network, the method comprising: determining (202), based on first information, at least one network slice of a transport network (310, 312, 414, 506) to be used to support an end-to-end, E2E, service of the telecommunications network, wherein the first information is indicative of a plurality of resources of the transport network (310, 312, 414, 506) and one or more demarcation points (314, 316, 318, 320, 418, 420, 422, 424, 510, 512, 514, 516) of the transport network (310, 312, 414, 506) configured to support the E2E service.

17. The method as claimed in claim 16, wherein the first information is based on: requirements for the E2E service, wherein the requirements for the E2E service comprise a resiliency for the E2E service and an availability for the E2E service; and / or one or more requirements of the transport network (310, 312, 414, 506).

18. The method as claimed in claim 16 or 17, wherein: the requirements for the E2E service further comprise a reliability for the E2E service.

19. The method as claimed in any of claims 16-18, wherein the plurality of resources comprises a first resource and a second resource, wherein the second resource is configured to support the E2E service if the first resource is unavailable.

20. The method as claimed in any of claims 16-19, wherein the one or more demarcation points (314, 316, 318, 320, 418, 420, 422, 424, 510, 512, 514, 516) comprises a first ingress demarcation point (418, 510) and a second ingress demarcation point (422, 514), wherein the second ingress demarcation point (422, 514) is configured to support the E2E service if the first ingress demarcation point (418, 510) is unavailable.

21. The method as claimed in any of claims 16-20, wherein: the at least one network slice comprises the plurality of resources and the one or more demarcation points (314, 316, 318, 320, 418, 420, 422, 424, 510, 512, 514, 516).

22. The method as claimed in any of claims 16-21 , the method comprising: generating an identifier for the at least one network slice.

23. The method as claimed in any of claims 16-22, wherein determining the at least one network slice comprises: determining a first network slice and a second network slice, wherein the second network slice is configured to be used if the first network slice is unavailable.

24. The method as claimed in any of claims 16-23, the method comprising: receiving the first information.

25. The method as claimed in any of claims 16-24, wherein: the E2E service is associated with an identifier.

26. A method performed by a system, the method comprising: the method as claimed in any of claims 1 to 15; and the method as claimed in any of claims 16 to 25.

27. A first entity (10) configured to operate in accordance with any of claims 1 to 15.

28. A first entity (10) as claimed in claim 27, wherein: the first entity (10) comprises: processing circuitry (12); andat least one memory (14) for storing instructions which, when executed by the processing circuitry (12), cause the first entity (10) to operate in accordance with any of claims 1 to 15.

29. A second entity (20) configured to operate in accordance with any of claims 16 to 25.

30. A second entity (20) as claimed in claim 29, wherein: the second entity (20) comprises: processing circuitry (22); and at least one memory (24) for storing instructions which, when executed by the processing circuitry (22), cause the second entity (20) to operate in accordance with any of claims 16 to 25.

31. A system comprising: at least one first entity (10) as claimed in 27 or 28; and at least one second entity (20) as claimed in claim 29 or 30.

32. A computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the method according to any of claims 1 to 15 and / or any of claims 16 to 25.

33. A computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry to cause the processing circuitry to perform the method according to any of claims 1 to 15 and / or any of claims 16 to 25.

Images