WO2017202448A1 - Instanciation dans des réseaux virtualisés - Google Patents

Instanciation dans des réseaux virtualisés Download PDF

Info

Publication number
WO2017202448A1
WO2017202448A1 PCT/EP2016/061635 EP2016061635W WO2017202448A1 WO 2017202448 A1 WO2017202448 A1 WO 2017202448A1 EP 2016061635 W EP2016061635 W EP 2016061635W WO 2017202448 A1 WO2017202448 A1 WO 2017202448A1
Authority
WO
WIPO (PCT)
Prior art keywords
host
connection
service
function
property
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2016/061635
Other languages
English (en)
Inventor
Olaf Renner
Klaus Hoffmann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks Oy
Original Assignee
Nokia Solutions and Networks Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Solutions and Networks Oy filed Critical Nokia Solutions and Networks Oy
Priority to PCT/EP2016/061635 priority Critical patent/WO2017202448A1/fr
Publication of WO2017202448A1 publication Critical patent/WO2017202448A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0823—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
    • H04L41/083—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability for increasing network speed
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H04L41/0897—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities by horizontal or vertical scaling of resources, or by migrating entities, e.g. virtual resources or entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H04L41/122—Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H04L41/5025—Ensuring fulfilment of SLA by proactively reacting to service quality change, e.g. by reconfiguration after service quality degradation or upgrade
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components

Definitions

  • the present invention relates to an apparatus, a method, and a computer program product related to network virtualization. More particularly, the present invention relates to an apparatus, a method, and a computer program product related to instantiation in virtualized networks.
  • PGW PDN Packet Data Network
  • ETSI GS NFV-MAN 001 V1 .1 .1 http://www.etsi.org/deliver/etsi_gs/NFV- M AN/001_099/001/01 .01 .01 _60/gs_nfv-man001 v010101 p.pdf] describes the management and orchestration of Telco networks in a network function virtualisation environment.
  • the agreed architecture is shown in Fig. 1 .
  • NFV decouples software implementations of Network Functions from the computation, storage, and networking resources they use.
  • the virtualisation insulates the Network Functions from those resources through a virtualisation layer.
  • the Network Functions Virtualisation Management and Orchestration (NFV-MANO) architectural framework has the role to manage the NFVI and orchestrate the allocation of resources needed by the NSs (Network Service) and VNFs.
  • the Network Service Orchestration performs its services by using the VNF Management services and by orchestrating the NFV Infrastructure that supports the interconnection between VNFs functionality, and its functions are exposed in an open, well known abstracted manner as services to other functions.
  • the NFV Orchestrator has two main responsibilities:
  • the VNF Manager is responsible for the lifecycle management of VNF instances.
  • the Virtualised Infrastructure Manager (VIM) is responsible for controlling and managing the NFVI compute, storage and network resources.
  • the NS Catalogue represents the repository of all of the on-boarded Network Services.
  • the VNF Catalogue represents the repository of all of the on-boarded VNF Packages.
  • the NFV Instances repository holds information of all VNF instances and Network Service instances.
  • the NFVI Resources repository holds information about available/reserved/allocated NFVI resources as abstracted by the VIM across operator's Infrastructure Domains, thus supporting information useful for resources reservation, allocation and monitoring purposes.
  • the NFVI encompasses all the hardware (e.g. compute, storage, and networking) and software (e.g. hypervisors) components that together provide the infrastructure resources where VNFs are deployed.
  • hardware e.g. compute, storage, and networking
  • software e.g. hypervisors
  • a service may consume a function. However, since the function might consume another function, the former function acts as a service, too. Therefore, unless otherwise noted or made clear from the context, the terms “function” and “service” are used synonymously throughout the present application. Also, the terms “cloud”, “data center”, and “cloud center” are used synonymously unless otherwise noted or made clear from the context.
  • a connection between two entities may comprise one or more links, wherein a link is a direct connection from one entity to another one without intermediate entities (nodes).
  • the connection may comprise plural paths, wherein each path may comprise one or more links.
  • ETSI GS NFV-EVE 005 a requirement recommendation REC#18 is formulated to address proximity of available resources, delay and in REC#17 to enable low latency traffic.
  • 3GPP architecture is described in detail in 3GPP TS 23.401 .
  • an apparatus comprising monitoring means adapted to monitor if a service requires a function, wherein a service host hosts the service; identifying means adapted to identify, if the service requires the function, plural function hosts, wherein each of the function hosts is known to host a respective instance of the function; determining means adapted to determine for each of the identified function hosts in how far a property of a respective connection between the service host and the respective function host fulfills a requirement, wherein the requirement is predetermined or set by the service, and the determining is based on received connection property indications for the connections, wherein each connection property indication indicates the property of the respective connection; selecting means adapted to select a selected function host out of the plural function hosts, wherein at least one of the following conditions is fulfilled: the property of the connection to the selected function host fulfills the requirement; and the property of the connection to the selected function host matches the requirement best among the plural connections; requesting means adapted to request the function from the selected function host.
  • the selecting means may be adapted to select the selected function host such that the selected function host is the same as the service host.
  • an apparatus comprising monitoring means adapted to monitor if a service requires a function, wherein a function host hosts the function; identifying means adapted to identify, if the service requires the function, plural service hosts, wherein each of the service hosts is known to host a respective instance of the service; determining means adapted to determine for each of the identified service hosts in how far a property of a respective connection between the respective service host and the function host fulfills a requirement, wherein the requirement is predetermined or set by the service, and the determining is based on received connection property indications for the connections, wherein each connection property indication indicates the property of the respective connection; selecting means adapted to select a selected service host out of the plural service hosts, wherein at least one of the following conditions is fulfilled: the property of the connection from the selected service host fulfills the requirement; and the property of the connection from the selected service host matches the requirement best among
  • the selecting means may be adapted to select the selected service host such that the selected service host is the same as the function host.
  • the apparatus may further comprise inquiring means adapted to inquire the connection property indications from a traffic optimization server.
  • the apparatus may further comprise providing means adapted to provide an identifier of the service host and an identifier of the respective function host to the traffic optimization server when inquiring the connection property indication for the connection between the service host and the respective function host.
  • the apparatus may further comprise providing means adapted to provide an identifier of the respective service host and an identifier of the function host to the traffic optimization server when inquiring the connection property indication for the connection between the respective service host and the function host.
  • the property may be at least one of a physical distance between the service host and the respective function host, a delay on the respective connection, a jitter on the respective connection, an availability of the respective connection, and a packet loss on the respective connection.
  • an apparatus comprising monitoring means adapted to monitor if an inquiry for a connection property indication of a connection is received, wherein the inquiry comprises a first identification related to a first host and a second identification related to a second host, the connection is between the first host and the second host, and the connection property indication indicates a property of the connection; providing means adapted to provide, in response to the inquiry, the connection property indication.
  • At least one of the first identification and the second identification may be a respective higher layer address of a protocol on a layer higher than the physical layer, and the apparatus may further comprise converting means adapted to convert the at least one higher layer address into a respective host identification of the respective host on the physical layer; retrieving means adapted to retrieve the connection property indication based on the host identification of the first host and the host identification of the second host.
  • the higher layer address may be of an address of an internet protocol or of an ethernet protocol.
  • the property may be at least one of a physical distance between the first host and the second host, a delay on the connection, a jitter on the connection, an availability of the connection, and a packet loss on the connection.
  • an apparatus comprising monitoring circuitry configured to monitor if a service requires a function, wherein a service host hosts the service; identifying circuitry configured to identify, if the service requires the function, plural function hosts, wherein each of the function hosts is known to host a respective instance of the function; determining circuitry configured to determine for each of the identified function hosts in how far a property of a respective connection between the service host and the respective function host fulfills a requirement, wherein the requirement is predetermined or set by the service, and the determining is based on received connection property indications for the connections, wherein each connection property indication indicates the property of the respective connection; selecting circuitry configured to select a selected function host out of the plural function hosts, wherein at least one of the following conditions is fulfilled: t e property of the connection to the selected function host fulfills the requirement; and the property of the connection to the selected function host matches the requirement best among the plural connections; requesting circuitry configured to request the function from the selected function host.
  • the selecting circuitry may be configured to select the selected function host such that the selected function host is the same as the service host.
  • an apparatus comprising monitoring circuitry configured to monitor if a service requires a function, wherein a function host hosts the function; identifying circuitry configured to identify, if the service requires the function, plural service hosts, wherein each of the service hosts is known to host a respective instance of the service; determining circuitry configured to determine for each of the identified service hosts in how far a property of a respective connection between the respective service host and the function host fulfills a requirement, wherein the requirement is predetermined or set by the service, and the determining is based on received connection property indications for the connections, wherein each connection property indication indicates the property of the respective connection; selecting circuitry configured to select a selected service host out of the plural service hosts, wherein at least one of the following conditions is fulfilled: the property of the connection from the selected service host fulfills the requirement; and the property of the connection from the selected service host matches the requirement best among the plural connections; locating circuitry configured to locate the service on the selected service host.
  • the selecting circuitry may be configured to select the selected service host such that the selected service host is the same as the function host.
  • the apparatus may further comprise inquiring circuitry configured to inquire the connection property indications from a traffic optimization server.
  • the apparatus may further comprise providing circuitry configured to provide an identifier of the service host and an identifier of the respective function host to the traffic optimization server when inquiring the connection property indication for the connection between the service host and the respective function host.
  • the apparatus may further comprise providing circuitry configured to provide an identifier of the respective service host and an identifier of the function host to the traffic optimization server when inquiring the connection property indication for the connection between the respective service host and the function host.
  • the property may be at least one of a physical distance between the service host and the respective function host, a delay on the respective connection, a jitter on the respective connection, an availability of the respective connection, and a packet loss on the respective connection.
  • an apparatus comprising monitoring circuitry configured to monitor if an inquiry for a connection property indication of a connection is received, wherein the inquiry comprises a first identification related to a first host and a second identification related to a second host, the connection is between the first host and the second host, and the connection property indication indicates a property of the connection; providing circuitry configured to provide, in response to the inquiry, the connection property indication.
  • At least one of the first identification and the second identification may be a respective higher layer address of a protocol on a layer higher than the physical layer, and the apparatus may further comprise converting circuitry configured to convert the at least one higher layer address into a respective host identification of the respective host on the physical layer; retrieving circuitry configured to retrieve the connection property indication based on the host identification of the first host and the host identification of the second host.
  • the higher layer address may be an address of an internet protocol or of an ethernet protocol.
  • the property may be at least one of a physical distance between the first host and the second host, a delay on the connection, a jitter on the connection, an availability of the connection, and a packet loss on the connection.
  • a method comprising monitoring if a service requires a function, wherein a service host hosts the service; identifying, if the service requires the function, plural function hosts, wherein each of the function hosts is known to host a respective instance of the function; determining for each of the identified function hosts in how far a property of a respective connection between the service host and the respective function host fulfills a requirement, wherein the requirement is predetermined or set by the service, and the determining is based on received connection property indications for the connections, wherein each connection property indication indicates the property of the respective connection; selecting a selected function host out of the plural function hosts, wherein at least one of the following conditions is fulfilled: the property of the connection to the selected function host fulfills the requirement; and the property of the connection to the selected function host matches the requirement best among the plural connections; requesting the function from the selected function host.
  • the selecting of the selected function host may be performed such that the selected function host is the same as the service host.
  • a method comprising monitoring if a service requires a function, wherein a function host hosts the function; identifying, if the service requires the function, plural service hosts, wherein each of the service hosts is known to host a respective instance of the service; determining for each of the identified service hosts in how far a property of a respective connection between the respective service host and the function host fulfills a requirement, wherein the requirement is predetermined or set by the service, and the determining is based on received connection property indications for the connections, wherein each connection property indication indicates the property of the respective connection; selecting a selected service host out of the plural service hosts, wherein at least one of the following conditions is fulfilled: the property of the connection from the selected service host fulfills the requirement; and the property of the connection from the selected service host matches the requirement best among the plural connections; locating the service on the selected service host.
  • the selecting of the selected service host may be performed such that the selected service host is the same as the function host.
  • the method according to any of the seventh and eighth aspects may further comprise inquiring the connection property indications from a traffic optimization server.
  • the method of the seventh aspect may further comprise providing an identifier of the service host and an identifier of the respective function host to the traffic optimization server when inquiring the connection property indication for the connection between the service host and the respective function host.
  • the method of the eighth aspect may further comprise providing an identifier of the respective service host and an identifier of the function host to the traffic optimization server when inquiring the connection property indication for the connection between the respective service host and the function host.
  • the property may be at least one of a physical distance between the service host and the respective function host, a delay on the respective connection, a jitter on the respective connection, an availability of the respective connection, and a packet loss on the respective connection.
  • a ninth aspect of the invention comprising monitoring if an inquiry for a connection property indication of a connection is received, wherein the inquiry comprises a first identification related to a first host and a second identification related to a second host, the connection is between the first host and the second host, and the connection property indication indicates a property of the connection; providing, in response to the inquiry, the connection property indication.
  • At least one of the first identification and the second identification may be a respective higher layer address of a protocol on a layer higher than the physical layer, and the method may further comprise converting the at least one higher layer address into a respective host identification of the respective host on the physical layer; retrieving the connection property indication based on the host identification of the first host and the host identification of the second host.
  • the higher layer address may be an address of an internet protocol or of an ethernet protocol.
  • the property may be at least one of a physical distance between the first host and the second host, a delay on the connection, a jitter on the connection, an availability of the connection, and a packet loss on the connection.
  • Each of the methods of the seventh to ninth aspects ay be a method of instantiation in virtualized networks.
  • an apparatus comprising at least one processor, at least one memory including computer program code, and the at least one processor, with the at least one memory and the computer program code, being arranged to cause the apparatus to at least perform at least one of the methods according to the seventh to ninth aspects.
  • a computer program product comprising a set of instructions which, when executed on an apparatus, is configured to cause the apparatus to carry out the method according to any of the seventh to ninth aspects.
  • the computer program product may be embodied as a computer-readable medium or directly loadable into a computer.
  • Fig.1 shows a network function virtualization environment according to ETSI GS NFV-MAN 001 V1 .1 .1 ;
  • Fig. 2 shows a basic ALTO architecture according to RFC 7285
  • Fig. 3 shows a network function virtualization environment with two operators
  • Fig. 4 shows a network function virtualization environment with two operators according to an embodiment of the invention related to EPC (Evolved Packet Core);
  • EPC Evolved Packet Core
  • Fig. 5 show a message flow for S-CSCF selection procedure according to an embodiment of the invention
  • Fig. 6 shows a message flow for AS selection procedure according to an embodiment of the invention
  • Fig. 7 shows an apparatus according to an example embodiment of the invention
  • Fig. 8 shows a method according to an example embodiment of the invention
  • Fig. 9 shows an apparatus according to an example embodiment of the invention.
  • Fig. 10 shows a method according to an example embodiment of the invention
  • Fig. 1 1 shows an apparatus according to an example embodiment of the invention
  • Fig. 12 shows a method according to an example embodiment of the invention.
  • Fig. 13 shows an apparatus according to an example embodiment of the invention.
  • the apparatus is configured to perform the corresponding method, although in some cases only the apparatus or only the method are described.
  • the MME of an operator X needs to select the PGW of the operator Y
  • the MME not only need to know the pure existence of the PGWs owned by the Operator Y, but the MME should also select the "best" PGW even in case of NFV. Since the SGW of the Operator X and the PGW of the Operator Y may or may not be hosted on the same cloud (without knowledge thereof to the applications), the MME is not able to select SGW and PGW in a carrier grade manner, i.e. in a deterministic manner in order to meet certain QoS requirements as expected within legacy networks already.
  • Network virtualization will allow fast and dynamical placement of network functions globally.
  • a case is considered where, due to a mass event in South America (e.g. soccer/football), temporarily a very huge number of Asian subscribers travel to South America (or vice versa) to attend the World championship games. In that case it would be much more efficient to select for these Asian subscribers a PGW placed in South America than arbitrarily selecting the PGW located in Asia. Note that the PGW belongs to the home network of the subscriber.
  • South America e.g. soccer/football
  • Some embodiments of the invention remedy one or more of these deficiencies.
  • a respective Global Cloud ID is assigned to each cloud (data center).
  • At least one of the MANO NFV Orchestrator interfaces Vi-Vnfm, Or-Vnfm, Or-Vi, and OS-Ma-nfvo is enabled to forward this information element such that the remote service provider gets this information about the Global Cloud ID for the VNF being instantiated locally;
  • the MANO VNF Manager interfaces Ve-Vnfm-em and/or Ve-Vnfm-vnf are enabled to forward this information element to the EM and/or to the VNF being instantiated such that the locally instantiated VNF or the related EM gets this information to know its own Global Cloud ID.
  • this information may be taken into account when a particular virtualized network function is to be selected by the service provider.
  • a MME of a service provider X selects or may select a certain SGW being hosted in the cloud center A
  • a PGW of the provider Y shall be selected which is also hosted by the cloud center A (if available). This is an example where the distance between SGW and PGW is minimized based on the GloD.
  • the MME of the provider X consults a specialized ALTO server with the input parameters of global cloud Ids (for source and one or more destinations, e.g. for the source SGW and the possible PGWs), and the ALTO server returns a list of IP addresses with corresponding latency between the source (e.g. SGW) and the possible destinations (e.g. PGW). Then, the PGW selection process (e.g. at the MME) selects that PGW which is hosted by the cloud center which matches best the latency requirement of the requested service, for instance minimal latency.
  • Embodiments of the invention are not restricted to minimal latency. Since there are services which require medium latency or higher latency, the PGW may select a PGW which matches the particular latency requirement best (i.e. an absolute delay selection).
  • Delay (latency) is just an example.
  • Other properties of the connection between the data centers such as the jitter, availability of the connection, and a packet loss on the connection may be handled in the same way.
  • the first two attributes are examples for QoS and SLA requirements.
  • “Matching best” means that a difference of the requirement (e.g. required latency) and the provided property (latency in this case) is minimized.
  • the term “difference” may mean an absolute value of the arithmetic difference between the property and the provided property, but it may also include other ways to express how much the provided property is different from the requirement.
  • “matching best” means that the ratio of the requirement and the property is closest to 1 among the connections, or that the logarithm of this ratio is closest to 0.
  • the requirements may be set by the service, or they may be predefined.
  • the selection function (such as a PGW selection function) may always (i.e. as a predefined requirement) select the PGW function located at the same data center as the SGW, but if an appropriate PGW function of the home operator is not implemented on that data center, it may select a PGW according to one or more of the requirements set by the service.
  • TS 29.303 allows today only to infer some closeness in the sense: something is closer than something different, but it does not provide absolute latency values.
  • the Global Cloud ID is used to get the for instance global delay between the Clouds and, therefore, between the VNF in those clouds.
  • the IGP interior gateway protocols
  • OSPF operating protocol
  • other routing protocols like e.g. BGP
  • each of the data centers may inject the Global Cloud ID, as part of a new PID (Provider-Defined Identifier) together with its corresponding IP addresses to the ALTO server.
  • PID Public-Defined Identifier
  • OSPF is a routing protocol.
  • the ALTO server is specified in "ALTO Protocol" available at http://tools.ietf.org/html/rfc7285. According to chapter 3.1 and Figure 1 thereof, the e.g. augmented OSPF shall inject the corresponding information into the ALTO server.
  • the interface to the ALTO server is going to be specified in "ALTO Protocol” available at http://tools.ietf.org/html/rfc7285.
  • the "cost Map” provides the path cost for each Source PID (Provider-defined Identifier) and Destination PID.
  • the invention is not restricted to the ALTO protocol.
  • Other protocols such as DNS are feasible to carry information on a connection property such as path costs, too, if accordingly adapted.
  • the MME may act as an ALTO client connected to the ALTO server (potentially being operated by a Third Party).
  • the different Cloud Operators are participating in the routing protocol level (OSPF, IS IS, etc) to inject their corresponding Global Cloud IDs and corresponding correlated IP Addresses.
  • OSPF routing protocol level
  • IS IS IS IS
  • the ALTO Server is enabled to have a global view of the Cloud connectivity.
  • PCE and PCEP may be used instead or in addition (if some of the functionality is split) to the ALTO server.
  • the usage of the ALTO server/ PCE is an optimized generalized solution of the scenario described in the beginning, namely that e.g. a MME can identify the SGW and PGW to be selected such that they reside on the same cloud.
  • connection properties such as latency, jitter, etc.
  • these values may reflect some average value (or some minimum value or some maximum value, depending on the specific property and the implementation) of the respective property which was obtained beforehand.
  • the indicated connection property may be different from the actual connection property.
  • ALTO server may request from time to time or event-based (e.g. if the property indication is requested) to determine the actual value of the property. However, if such a determination is performed when the property indication is requested it may result in inacceptable long delays for the response to the request. Therefore, this option is typically not preferred.
  • the Global Cloud ID allows engineering the selection process in a carrier grade way, such that "same cloud" is only one of a lot of requirements each of which may be put on the connection between datacenters on which a service and a function consumed by the service reside.
  • the above description is just an example. There may be other information elements, which may be exchanged between the different service providers.
  • an operator may decide to move a virtualized network function to another location (e.g. due to policy, service requirements, business needs, or whatever reasons).
  • the original latency requirement may or may not be met anymore for the established relationship between service and its consumed function.
  • the actual Global Cloud ID is updated and the actual location is taken into a account for a selection).
  • latency between possibly candidate peers for the initial selection is known.
  • the same selection process may run again in order to decide if another function instantiation is to be selected.
  • the original selection process if it is notified about the fact of the relocation (e.g. by recognizing the new Global Cloud ID) it shall check whether the original requirement for the latency is still met. If it is still met there is no need to act. However, if latency was increased beyond or below the QoS limit, the (re)-selection process may try to initiate relocation of the local instance in accordance with operators business needs, policy rules and/or service requirements of the subscribers, or may terminate the service.
  • Fig. 3 shows an example for a roaming scenario in a NFV environment, where the operator Y hosts at least one PGW and the operator X hosts at least one MME/SGW.
  • Each of operators X and Y may be a "real" operator or a "virtual” operator which does not operate a network but uses one or more networks operated by (a) "real" operator(s).
  • Each of operators X and Y may provide an end-to-end service.
  • the global Cloud ID is allocated/reported by the VNFM and sent to the NFVO through the VNFM via Or-Vnfm.
  • the exact entity assigning the CloudID may depend on implementation and may be different from VNFM (e.g. it can be assigned by some entity of a cloud management system like OpenStack).
  • the CloudID of VNFs is then exchanged through interface Z * across multiple sites and can be complemented with ALTO latency information between VNFs to help the selection process of multi-site service VNFs.
  • VNF NFVO - VNFM
  • the Global cloud ID is assigned and stored in NFVO database along with other VNF information.
  • interface Z * There might not be a direct interface between the two separated NVFOs, but an enabled interface between the two OSS/BSS systems, which is summarized here as interface Z * .
  • interface Z * There might not be a direct interface between the two separated NVFOs, but an enabled interface between the two OSS/BSS systems, which is summarized here as interface Z * .
  • a multi-site management references point and interface between OSS-OSS or NFVO-NFVO is currently not specified, but a new work item proposal NFV(16)000059 has been submitted to ETSI NVF which may be subject to the here mentioned interface Z * .
  • the Cloud ID and the name of the instantiated VNF may be signalled between the two NFVOs, but also the originating and destination Operator (fixed or mobile operator) may be signalled, in particular for a case of a multi-tenant scenario wherein any NFVO (e.g. a third party) may host several different network operators. In that case the one service provider may receive the GloD of a VNF via that interface when needed.
  • the originating and destination Operator fixed or mobile operator
  • the two operators may have instantiated their own NFV networks independently from each other. However at a later stage they may wish to interwork and need to exchange their mutual EPC network interfaces for successful interworking.
  • the GloD and the PGW information may be exchanged, e.g. by a query request.
  • the operator Y may inform the DNS/MME about the GloD of the peer PGW, such that the selection process at the MME of operator X shall preferably select a PGW instance of the peer operator, which resides in the same global cloud depending on the needs of the requested service.
  • the DNS query and responses is augmented with the GloD so that the S/PGW selection process is able to recognise and evaluate the Global Cloud ID.
  • the cloud ID is added to the DNS response.
  • MME may issue an additional DNS query which retrieves the Global Cloud ID, but such additional DNS query might not be optimal.
  • the Global Cloud ID is introduced because in today's processes the location of the PGW and SGW (as well as that of the MME and other NEs) is static. With the introduction of NFV applications, the locations are not static anymore.
  • the Global Cloud ID allows to express the floating location of a SGW and PGW.
  • the Global Cloud ID structure may be mapped to the same structure of the SGW PGW structure as of today (for instance via DNS query), but this does not provide any indication of the delay between NFV instances.
  • the IP address of the VNF is maintained.
  • GloD is an identifier of the physical layer (1 st layer of the OSI model).
  • the IP address is an identifier on the network layer (3 rd layer of the OSI model).
  • the ALTO server is consulted for the candidate Global Cloud IDs pairs. Based on operator policies and service requirements the pair with e.g. suitable delay is selected. That is, the ALTO provides an indication of the delay for several pairs of Global Cloud IDs, and MME selects one PGW (the other member of the pair is SGW which cannot be selected) which fulfils the required delay best.
  • the Global Cloud ID could consist of a Country code (CC), where the cloud physically resides and an operator ID (identifying the Operator within that country) and a sub-identifier allocated by the operator in order to differentiate different data centers of the operator. Only those data center operators which want to participate in hosting telco cloud physical network functions and/or VNFs (virtual network functions) may be required to register a Global cloud ID in order to serve the optimized selection of MME, SGW, PGW, HSS , CSCF etc.
  • CC Country code
  • VNFs virtual network functions
  • the GloD may be implemented as a "Constraint" in a VNF Descriptor to manage policies as described in 5.4.1 and 5.4.2 of ETSI GS NFV-MAN 001 , or it may be stored and queried in an NFVO database, e,g, the VNF catalogue. Further the Global cloud ID may be either implicitly encoded in the DNS response or explicitly in a new parameter.
  • topoff.vipl .gw01. nodes one may code the Cloud ID into it like the following: “topoff.vipl .GICIID001 .gw01 .nodes”.
  • GloD may have a form like: country. city. datacenter.
  • the form of the GloD is standardized, or (at least) bilaterally or even multilaterally agreed between those players participating in this new service.
  • the same process may be established as for the Cell ID already in place for the Global cell ID of mobile networks today.
  • ITU-T or 3GPP may operate a registration service where the Cloud Operator can apply for and register their Global Cloud IDs. This can be done on a registration process which may be based per country (see above) or based on companies.
  • the NFV-MANO system of the operator X is also augmented with the new capability such that the SGW/MME(/DNS) know its own Global Cloud ID. This may be performed in accordance to b) hereinabove. Therefore the selection process has knowledge about the Global Cloud ID of those virtualised network functions in question.
  • each Cloud center injects its Global Cloud ID and its relevant IP addresses to the ALTO server for the Global virtualized service.
  • the latency associated with IP addresses are assumed to be carried e.g. via OSPF normally hosted by the router connected to the cloud centers. Or alternatively e.g the OSPF is augmented with the GloD such that both the latency and the Global Cloud ID is signalled via OSPF (to the ALTO Server).
  • the MME when performing the new SGW/PGW selection process in the virtualised network consults the ALTO server with a query carrying the GloD of the SGWs and the GloD of the PGWs (as received via the NFV-MANO interfaces, which was previously described)
  • the ALTO server returns the latency between the possible source data centers and destination datacenter for each IP address of the data center.
  • the MME on receipt of the response from the ALTO server selects the pair of SGW and PGW in those clouds which meets best the requirement of the service (or a predetermined requirement such as "same location").
  • the MME will get the geometry information to the SGW for each of the IP addresses of a PGW in a particular data center. Then, if minimum delay is required, the MME may order the PGWs according to their (maximum) delay and select that PGW with the lowest (maximum) delay. Now the PGW in the nearest cloud is selected.
  • IP addresses and delays this information can be leveraged to select delay optimized VNF forwarding graphs.
  • MME may provide IP addresses of potential PGWs to ALTO server.
  • ALTO server may determine the corresponding GloD and then determine the delays as above. It may return the IP addresses and respective delays to MME. This option may be useful in particular if the IP address of PGW with the NS and the IP address of the cloud hosting the NS belong to the same layer.
  • SGW/PGW selection process in a virtualised environment is just an example.
  • Other examples may be the MME selection performed by the eNB, or the selection of an incoming IBCF done by the outgoing IBCF in case of IMS.
  • the IBCF knows its own Global Cloud ID.
  • the IBCF acting as an exit point retrieves the list of potential entry points (e.g. IBCF or l-CSCF) either via DNS (RFC3262) or from local provision.
  • DNS RFC3262
  • the DNS response returns the Global Cloud ID for each potential entry point (IBCF or l-CSCF) or the provisioned local configuration returns the Global Cloud ID with each potential entry point (e.g. IBCF or l-CSCF).
  • the exit IBCF consults the ALTO server to retrieve, for instance, the delay (or another connection property) between the own Global Cloud ID and the Global Cloud ID of the list of potential entry points.
  • the exit IBCF selects the entry point (IBCF/I-CSCF) depending on the connection property requested by the service or on a predetermined connection property.
  • IMS IP Multimedia System
  • S-CSCF Serving - Call Session control Function
  • the terminating S-CSCF selection process at the terminating l-CSCF is further enhanced and supported by the following additional procedure (see Fig. 5, based on a call flow of 3GPP TS 23.228).
  • the originating (calling party) subscriber belongs to operator A, whereas the destination subscriber (called party) belongs to operator B. Since the operator A recognized that the called party does belong to Operator B the IMS call initiation message SIP INVITE is forwarded to the l-CSCF (Interrogating - Call Session Control Function) of the operator B (steps 1 to 3).
  • the l-CSCF task is it to query the HSS for the appropriate terminating S-CSCF to host the SIP session of the B-party via the Cx Interface.
  • the l-CSCF shall provide the ID of the originating S-CSCF to the HSS (Home Subscriber Server) in step 4.
  • the HSS having access to its own list of S-CSCF of Operator B, in turn queries the ALTO server for instance for the delay between the originating S-CSCF of the operator A and the (terminating) S-CSCFs of own Operator B in step 4a.
  • the ALTO server provides e.g. the delay between the originating S-CSCF and the terminating S-CSCF candidates.
  • the HSS on receipt of the message 5 selects the S-CSCF based on the delay information (i.e.
  • step 6 SIP INVITE is sent via the P-CSCF (Serving - Call Session control Function) towards the B-Party.
  • P-CSCF Serving - Call Session control Function
  • the origination S-CSCF may have already signalled the Global Cloud ID of the originating S-CSCF to the terminating l-CSCF as an additional SIP information element. Consequently the Global Cloud ID may have been inserted additionally already into the query to the HSS.
  • the origination l-CSCF may perform the HSS query and the ALTO interrogation instead of splitting this across the l-CSCF and the HSS.
  • the Global Cloud ID possibly may be incorporated/coded into the Domain Name the originating S-CSCF instead of having/defining an explicit new information element.
  • the delay mentioned above is just an example. In general any other attribute like jitter, availability, packet loss, etc. may be subject of the optimisation and selection procedure.
  • the terminating AS selection process at the terminating l-CSCF is further enhanced and supported by the following additional procedure (see Fig. 6, based on another call flow of 3GPP TS 23.228).
  • the originating (calling party) subscriber belongs to operator A, whereas the destination service belongs to operator B. Since the operator A recognized that the called service does belong to Operator B the IMS call initiation message SIP INVITE is forwarded to the l-CSCF (Interrogating - Call Session control Function) of the operator B (step 1 ).
  • the l-CSCF task is it to query the DNS for the appropriate terminating AS to host the service via the DNS Interface.
  • the l-CSCF provides the ID of the originating S-CSCF to the DNS (Domain Name Service) in step 4.
  • the l-CSCF does not provide the ID of the originating S-CSCF to the DNS and is therefore written in bold in the figure to highlight that this is a new information element to be sent up to the DNS.
  • the DNS having access to its own list of AS (Application Servers) of Operator B, in turn returns Global Cloud ID to the l-CSCF.
  • AS Application Servers
  • the l-CSCF queries the ALTO server for instance for the delay between the originating S-CSCF of the operator A and the (terminating) service of own Operator B in step 5a.
  • the ALTO server provides e.g. the delay between the originating S-CSCF and the potential terminating application Server (AS) hosting the requested service candidates.
  • AS application Server
  • the l-CSCF on receipt of the flow 5b selects the AS based on the delay information (Application Server which matches best of the pairs of originating S-CSCF and plural AS) which matches best, and the call set up continues with flow 7 where the SIP INVITE is sent towards the selected AS.
  • Note 1 Alternatively, t e origination S-CSCF may have already signalled the Global Cloud ID of the originating S-CSCF to the terminating l-CSCF as an additional SIP information element.
  • Global Cloud ID possibly may be incorporated/coded into the Domain Name the originating S-CSCF instead of having/defining an explicit new information element.
  • the delay mentioned above is just an example. In general any other attribute like jitter, availability, packet loss, etc. may be subject of the optimisation and selection procedure.
  • the MME selection procedure takes into account the eNB ID for which the Global Cloud ID is retrieved.
  • the eNB selects the MME
  • the eNB is provided with the Global Cloud ID via the MANO interface.
  • the old MME queries the DNS server at first to get the Global Cloud ID of the eNB in question.
  • the selection function is aware of the Global Cloud ID of the eNB.
  • the selection function retrieves from the list of potential MME the Global Cloud ID of the MMEs from the DNS.
  • the selection function consults the ALTO server with each pair of eNB ID with its corresponding Global Cloud ID and the MME with it Global Cloud IDs to retrieve e.g. the corresponding delay for each pair.
  • the MME selection function selects the MME which matches best the delay requirement. Again, delay is only an example requirement.
  • Fig. 7 shows an apparatus according to an example embodiment of the invention.
  • the apparatus may be a network function such as a MME, or an element thereof.
  • Fig. 8 shows a method according to an example embodiment of the invention.
  • the apparatus according to Fig. 7 may perform the method of Fig. 8 but is not limited to this method.
  • the method of Fig. 8 may be performed by the apparatus of Fig. 7 but is not limited to being performed by this apparatus.
  • the apparatus comprises monitoring means 10, identifying means 20, determining means 30, selecting means 40, and requesting means 50.
  • the monitoring means 10, identifying means 20, determining means 30, selecting means 40, and requesting means 50 may be a monitoring circuitry, identifying circuitry, determining circuitry, selecting circuitry, and requesting circuitry, respectively.
  • the monitoring means 10 monitors if a service requires a function, wherein a service host hosts the service (S10).
  • a service host hosts the service (S10).
  • the "function" may be providing network connectivity, which is provided by a PGW and which is requested from a SGW providing the "service”.
  • the identifying means 20 identifies plural function hosts (S20). Each of the function hosts is known to host a respective instance of the function. For example, the plural function hosts may be indicated as hosting the function in a received message.
  • the determining means 30 determines for each of the identified function hosts in how far a property of a respective connection between the service host and the respective function host fulfills a requirement (S30).
  • the requirement is predetermined or set by the service.
  • the determining S30 by the determining means 30 is based on received connection property indications for the connections.
  • Each connection property indication indicates the property of the respective connection.
  • the property may be at least one of a distance between the service host and the respective function host, a delay on the respective connection, a jitter on the respective connection, an availability of the respective connection, and a packet loss on the respective connection. If the physical distance is 0, the function host and the service host are hosted by the same data center.
  • the selecting means 40 selects a selected function host out of the plural function hosts (S40).
  • the selected function host is selected such that at least one of the following conditions is fulfilled:
  • connection to the selected function host matches the requirement best among the plural connections.
  • the requesting means 50 requests the function from the selected function host (S50).
  • Fig. 9 shows an apparatus according to an example embodiment of the invention.
  • the apparatus may be a network function such as a MME, or an element thereof.
  • Fig. 10 shows a method according to an example embodiment of the invention.
  • the apparatus according to Fig. 9 may perform the method of Fig. 10 but is not limited to this method.
  • the method of Fig. 10 may be performed by the apparatus of Fig. 9 but is not limited to being performed by this apparatus.
  • the apparatus comprises monitoring means 210, identifying means 220, determining means 230, selecting means 240, and locating means 250.
  • the monitoring means 210, identifying means 220, determining means 230, selecting means 240, and locating means 250 may be a monitoring circuitry, identifying circuitry, determining circuitry, selecting circuitry, and locating circuitry, respectively.
  • the monitoring means 210 monitors if a service requires a function, wherein a function host hosts the function (S210).
  • a function host hosts the function (S210).
  • the "function” may be providing network connectivity, which is provided by a PGW and which is requested from a SGW providing the "service”.
  • the identifying means 220 identifies plural service hosts (S220). Each of the service hosts is known to host a respective instance of the service. For example, the plural service hosts may be indicated as hosting the service in a received message.
  • the determining means 230 determines for each of the identified service hosts in how far a property of a respective connection between the respective service host and the function host fulfills a requirement (S230).
  • the requirement is predetermined or set by the service.
  • the determining S230 by the determining means 230 is based on received connection property indications for the connections.
  • Each connection property indication indicates the property of the respective connection.
  • the property may be at least one of a physical distance between the service host and the respective function host, a delay on the respective connection, a jitter on the respective connection, an availability of the respective connection, and a packet loss on the respective connection. If the physical distance is 0, the function host and the service host are hosted by the same data center.
  • the selecting means 240 selects a selected service host out of the plural service hosts (S240).
  • the selected service host is selected such that at least one of the following conditions is fulfilled: - the property of the connection from the selected service host fulfills the requirement; and
  • the property of the connection from the selected service host matches the requirement best among the plural connections.
  • the locating means 250 locates the service on the selected service host (S250).
  • Fig. 1 1 shows an apparatus according to an example embodiment of the invention.
  • the apparatus may be an ALTO server, or an element thereof.
  • Fig. 12 shows a method according to an example embodiment of the invention.
  • the apparatus according to Fig. 1 1 may perform the method of Fig. 12 but is not limited to this method.
  • the method of Fig. 12 may be performed by the apparatus of Fig. 1 1 but is not limited to being performed by this apparatus.
  • the apparatus comprises monitoring means 1 10 and providing means 120.
  • the monitoring means 1 10 and providing means 120 may be a monitoring circuitry and providing circuitry, respectively.
  • the monitoring means 1 10 monitors if an inquiry for a connection property indication of a connection is received (S1 10).
  • the inquiry comprises a first identification related to a first host and a second identification related to a second host.
  • each of the first and second identifications may be an IP address, or each of the first and second identifications may be a GloD.
  • the connection is between the first host and the second host.
  • the connection property indication indicates a property of the connection.
  • the property is at least one of a distance between the first host and the second host, a delay on the connection, a jitter on the connection, an availability of the connection, and a packet loss on the connection.
  • the providing means 120 provides, in response to the inquiry, the connection property indication (S120).
  • Fig. 13 shows an apparatus according to an example embodiment of the invention.
  • the apparatus comprises at least one processor 610, at least one memory 620 including computer program code, and the at least one processor 610, with the at least one memory 620 and the computer program code, being arranged to cause the apparatus to at least perform at least one of the methods according to Figs. 8, 10, and 12 and related description.
  • the IP address is mapped to the GloD (identifier of the physical layer).
  • the IP address instead of or in addition to the IP address
  • another identifier of a layer higher than the physical layer may be mapped to the GloD.
  • such a higher layer identifier may be a MAC address of the Ethernet protocol.
  • Internet protocol e.g. IPv4, IPv6
  • Ethernet protocol are just examples of higher layer protocols.
  • an ALTO server provides a connection property.
  • the invention is not restricted to an ALTO server.
  • a DNS server may provide the corresponding functionality.
  • another server may provide this functionality.
  • the server may be dedicated to providing this functionality or may provide other functionality, too.
  • the MME selects one of several function hosts (e.g. PGWs) based on a connection property while the corresponding service host (e.g. SGW) is fixed. Furthermore, some embodiments of the invention are described where the MME selects one of several service hosts (e.g. SGWs) based on a connection property while the corresponding function host (e.g. PGW) is fixed. In some embodiments of the invention, these selections may be performed iteratively: E.g., for each of plural service hosts, the respective "best matching" function host is determined. Then, the "very best matching" pair among these best matching pairs of service host and function host is selected. Alternatively, for each of plural function hosts, the respective "best matching" service host is determined. Then, the "very best matching" pair among these best matching pairs of service host and function host is selected.
  • One piece of information may be transmitted in one or plural messages from one entity to another entity. Each of these messages may comprise further (different) pieces of information.
  • Names of network elements, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and/or protocols and/or methods may be different, as long as they provide a corresponding functionality.
  • each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware. It does not necessarily mean that they are based on different software. That is, each of the entities described in the present description may be based on different software, or some or all of the entities may be based on the same software.
  • Embodiments of the invention may be employed fully or partly in the cloud, wherein a resource (e.g. processor, software, memory, network) for the respective task may be shared with other applications.
  • a resource e.g. processor, software, memory, network
  • example embodiments of the present invention provide, for example a virtualized network function, a datacenter running the virtualized network function, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).
  • example embodiments of the present invention provide, for example a traffic optimization server such as a ALTO server or a corresponding function, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).
  • a traffic optimization server such as a ALTO server or a corresponding function, or a component thereof
  • an apparatus embodying the same a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).
  • Implementations of any of the above described blocks, apparatuses, systems, techniques, means, entities, units, devices, or methods include, as non-limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, a virtual machine, or some combination thereof.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé comprenant les étapes consistant à : surveiller si un service nécessite une fonction, un hôte de service hébergeant le service; identifier plusieurs hôtes de fonction, chacun des hôtes de fonction étant connu pour héberger une instance respective de la fonction; déterminer, pour chacun des hôtes de fonction identifiés, dans quelle mesure une propriété d'une connexion respective entre l'hôte de service et l'hôte de fonction respectif satisfait une exigence, la détermination étant basée sur des indications des propriétés des connexions reçues relatives aux connexions, chaque indication de propriété de connexion indiquant la propriété de la connexion respective; sélectionner un hôte de fonction sélectionné parmi lesdits plusieurs hôtes de fonction, la propriété de la connexion à l'hôte de fonction sélectionné correspondant au mieux à l'exigence parmi lesdites plusieurs connexions; et demander la fonction à partir de l'hôte de fonction sélectionné.
PCT/EP2016/061635 2016-05-24 2016-05-24 Instanciation dans des réseaux virtualisés Ceased WO2017202448A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2016/061635 WO2017202448A1 (fr) 2016-05-24 2016-05-24 Instanciation dans des réseaux virtualisés

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2016/061635 WO2017202448A1 (fr) 2016-05-24 2016-05-24 Instanciation dans des réseaux virtualisés

Publications (1)

Publication Number Publication Date
WO2017202448A1 true WO2017202448A1 (fr) 2017-11-30

Family

ID=56068912

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2016/061635 Ceased WO2017202448A1 (fr) 2016-05-24 2016-05-24 Instanciation dans des réseaux virtualisés

Country Status (1)

Country Link
WO (1) WO2017202448A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110912722A (zh) * 2018-09-17 2020-03-24 中兴通讯股份有限公司 业务资源管理方法、装置、网络设备和可读存储介质
WO2021001842A1 (fr) 2019-07-01 2021-01-07 Telefonaktiebolaget Lm Ericsson (Publ) Disponibilité de ressource de réseau dynamique pour événements planifiés
EP4529120A4 (fr) * 2022-05-31 2025-05-07 Huawei Technologies Co., Ltd. Procédé de communication basé sur un protocole alto et appareil associé

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015082013A1 (fr) * 2013-12-06 2015-06-11 Nokia Solutions And Networks Oy Gestion de la sélection d'un élément de réseau
US20150288767A1 (en) * 2014-04-03 2015-10-08 Centurylink Intellectual Property Llc Network Functions Virtualization Interconnection Hub
WO2016071736A1 (fr) * 2014-11-04 2016-05-12 Telefonaktiebolaget L M Ericsson (Publ) Chaînage de service de virtualisation de fonction réseau

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015082013A1 (fr) * 2013-12-06 2015-06-11 Nokia Solutions And Networks Oy Gestion de la sélection d'un élément de réseau
US20150288767A1 (en) * 2014-04-03 2015-10-08 Centurylink Intellectual Property Llc Network Functions Virtualization Interconnection Hub
WO2016071736A1 (fr) * 2014-11-04 2016-05-12 Telefonaktiebolaget L M Ericsson (Publ) Chaînage de service de virtualisation de fonction réseau

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110912722A (zh) * 2018-09-17 2020-03-24 中兴通讯股份有限公司 业务资源管理方法、装置、网络设备和可读存储介质
CN110912722B (zh) * 2018-09-17 2022-08-09 中兴通讯股份有限公司 业务资源管理方法、装置、网络设备和可读存储介质
WO2021001842A1 (fr) 2019-07-01 2021-01-07 Telefonaktiebolaget Lm Ericsson (Publ) Disponibilité de ressource de réseau dynamique pour événements planifiés
EP3994854A4 (fr) * 2019-07-01 2022-06-29 Telefonaktiebolaget LM Ericsson (publ) Disponibilité de ressource de réseau dynamique pour événements planifiés
US11924118B2 (en) 2019-07-01 2024-03-05 Telefonaktiebolaget Lm Ericsson (Publ) Dynamic network resource availability for planned events
EP4529120A4 (fr) * 2022-05-31 2025-05-07 Huawei Technologies Co., Ltd. Procédé de communication basé sur un protocole alto et appareil associé

Similar Documents

Publication Publication Date Title
JP6509219B2 (ja) ソフトウェア定義ネットワーク（ＳＤＮ）機能性を使用したＤｉａｍｅｔｅｒルーティングのための方法、システム、およびコンピュータ読取可能媒体
CN109565472B (zh) 虚拟网络中基于切片/服务的路由方法和设备
CN108712516B (zh) 获取sip服务器地址的方法、装置、设备和存储介质
US8340670B2 (en) Registering with SIP servers for IMS using a fully qualified domain name
US9876863B2 (en) Method, device, network entity and computer program product for providing an IP service application
US11399005B2 (en) Method and apparatus for expedited domain name system query resolution
US20130272253A1 (en) Dynamic Assignment of a Serving Network Node
US8676977B2 (en) Method and apparatus for controlling traffic entry in a managed packet network
US20120203864A1 (en) Method and Arrangement in a Communication Network for Selecting Network Elements
CN101505472A (zh) 一种用户数据服务器系统和装置
US11456989B2 (en) Systems and methods for virtualized network function (“VNF”) selection in a wireless telecommunications network
US20190110207A1 (en) Method for Auto-Discovery in Networks Implementing Network Slicing
US9100415B2 (en) On-net direct access to voicemail
WO2017202448A1 (fr) Instanciation dans des réseaux virtualisés
JP2010514049A (ja) マルチメディア・ネットワークにおいてサービス要求を処理するための方法及び装置
US9762621B2 (en) Call routing for IP multimedia subsystem users
US10084923B2 (en) Method and system for dynamic trunk group based call routing
US12010154B2 (en) Support for IMS virtual clients in multi-operator environment
CN107257331B (zh) 用于提供ip服务应用的方法、设备和存储介质
US10111038B2 (en) Inter-network connection control device, and connection control method
US20260121980A1 (en) Ip address mobility in a host-routing network
CN103825914B (zh) 一种sn信息上报方法、dsn p2p网络与ims网络通信方法及设备
WO2016050033A1 (fr) Procédé, dispositif, et système de traitement d'appel de terminal<0}
Lundqvist et al. Service program mobility—Dynamic service roaming
WO2025008944A1 (fr) Procédé et système de manipulation de messages dans réseau de communication

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16724427

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 16724427

Country of ref document: EP

Kind code of ref document: A1