METHOD AND SYSTEM FOR PACKET DATA NETWORK SERVICE SLICING OVER A NETWORK INFRASTRUCTURE FOR REAL-TIME IP SERVICES

Abstract

A method and an orchestration server for packet data network service slicing over a network infrastructure for real-time IP services are provided. The method comprises providing an orchestration server that has knowledge of a whole connectivity status of a network infrastructure and that is configured to manage service nodes. The server receives a session request for a real-time IP service from a UE device located in a given region and requests to one or more service nodes of said given region whether it has/they have network resources. Each of the one or more service nodes compute a QoS measurement thereof in terms of KPIs including latency, jitter and bandwidth, the QoS measurement being computed by a software module that is implemented on a virtual machine deployed on the service node; and tag a plurality of interfaces. The orchestration server selects a given service node in view of said QoS measurement.

Claims

1. A method for packet data network service slicing over a network infrastructure for real-time IP services, said network infrastructure comprising a plurality of regions (101, 102) linked via a transportation network (100), each region of the plurality of regions (101, 102) having a plurality of service nodes (111, 112), the method comprising: providing an orchestration server (120) at a given location where a service provider is located, the orchestration server (120) having knowledge of a whole connectivity status of the network infrastructure, and being configured to manage the plurality of service nodes (111, 112); receiving, by the orchestration server (120), a session request for a real-time Internet Protocol, IP, service from a user equipment, UE, device located in a given region of said plurality of regions (101, 102); upon reception of said session request, requesting, by the orchestration server (120), to one or more service nodes of the plurality of service nodes (111, 112) of said given region whether it has/they have network resources; each of the one or more service nodes upon reception of said request: computing a Quality of Service, QoS, measurement thereof in terms of Key Performance Indicators, KPI, including latency, jitter and bandwidth, the QoS measurement being computed by a software module that is implemented on a virtual machine deployed on the service node; and tagging a plurality of interfaces, the tagging being performed by the virtual machine; and selecting, by the orchestration server (120), a given service node of the one or more service nodes in view of said QoS measurement.

2. The method of claim 1, wherein the plurality of interfaces comprise three interfaces, a first one for IP management, a second one for international IP traffic and a third one for IP services.

3. The method of claim 2, wherein the software module further computes which route through the IP services interface has to be used for the session request.

4. The method claim 1, wherein the one or more service nodes besides computing the QoS measurement further compute a set of metrics including IP metrics, User Datagram Protocol, UDP, metrics, Transmission Control Protocol, TCP, metrics and/or Internet Control Message Protocol, ICMP, metrics.

5. The method of claim 3, wherein the selecting step further comprises discarding the service nodes of said one or more service nodes with an available capacity metric, ACMG, less than a threshold.

6. The method of claim 3, wherein the selecting step further comprises discarding the service nodes of the one or more service nodes with a Health Node Indicator, HHNI, less than a threshold, the HHNI being based on the IP, UDP, TCP and/or ICMP metrics.

7. The method of claim 1, wherein the real-time IP service comprises at least one of video conference, gaming, remote video production, remote health.

8. An orchestration server for packet data network service slicing over a network infrastructure for real-time IP services, said network infrastructure comprising a plurality of regions (101, 102) linked via a transportation network (100), each region of the plurality of regions (101, 102) having a plurality of service nodes (111, 112), wherein the orchestration server (120) is located at a given location where a service node is located, has knowledge of a whole connectivity status of the network infrastructure, and is configured to: receive a session request for a real-time Internet Protocol, IP, service from a user equipment, UE, device located in a given region of said plurality of regions (101, 102); request to one or more service nodes of the plurality of service nodes (111, 112) of said given region whether it has/they have network resources; and select a given service node of the one or more service nodes (111, 112) in view of a Quality of Service, QoS, measure of the one or more service nodes in terms of Key Performance Indicators, KPI, including latency, jitter and bandwidth, the QoS measure being computed by a software module implemented on a virtual machine deployed on each one of the one or more service nodes, the virtual machine being further configured to tag a plurality of interfaces.

9. The orchestration server of claim 8, wherein it is further configured to discard the service nodes of said one or more service nodes (111, 112) with an available capacity metric, ACMG, less than a threshold.

10. The orchestration server of claim 8, wherein it is further configured to discard the service nodes of the one or more service nodes (111, 112) with a Health Node Indicator, HHNI, less than a threshold, the HHNI being based on a set of metrics computed by the one or more service nodes (111, 112) and including IP metrics, User Datagram Protocol, UDP, metrics, Transmission Control Protocol, TCP, metrics and/or Internet Control Message Protocol, ICMP, metric.

11. The orchestration server of claim 8, wherein the real-time IP service comprises at least one of video conference, gaming, remote video production, remote health.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The previous and other advantages and features will be more fully understood from the following detailed description of embodiments, with reference to the attached figures, which must be considered in an illustrative and non-limiting manner, in which:

[0021] FIG. 1 schematically illustrates a network infrastructure with the proposed network elements for implementing the present invention.

[0022] FIG. 2 is a flow chart illustrating the proposed method, according to an embodiment.

[0023] FIG. 3 schematically illustrates the design of a Hanzo Service Node or Hanzo Turn Server, according to an embodiment of the present invention.

[0024] FIG. 4 illustrates the network QoS configuration scheme, according to an embodiment of the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0025] Present invention proposes a network infrastructure based on the combination of the most standard protocols for NAT traversal and programmable network QoS stack to provide network slices for any real-time application. In the following the invention is sometimes referred as Hanzo.

[0026] FIG. 1 shows an embodiment of the network infrastructure for deployment of the present invention. The overall architecture is based on an orchestration server (or Global platform or Hanzo Global) 120, that is operated and managed from a single location. This allows a greater ease of operation and maintenance. In addition, the network infrastructure comprises different regions 101, 102, each one having a specific number of service nodes (or Hanzo nodes) 111, 112, depending on the size of the territory and the volume of traffic received.

[0027] The relationship between each region and country will be 1:1, except in the case of the international transportation region 100, which will be used as a link between regions 101, 102. The architecture will be like as a usual hub and spoke type.

[0028] With regard to FIG. 2, therein an embodiment of a method for packet data network service slicing over a network infrastructure for real-time IP services is Illustrated. According to this embodiment, at step 201, an orchestration server 120 receives a session request for a real-time IP service from a UE device located in a given region of the regions 101, 102.

[0029] At step 202 the orchestration server 120 requests to one or more service nodes of said given region whether it has/they have network resources. At step 203 each of the one or more service nodes upon reception of said request compute a QoS measurement thereof in terms of KPIs including latency, jitter and bandwidth, and tag a plurality of interfaces. At step 204 the orchestration server 120 selects a given service node of the one or more service nodes In view of the QoS measurement.

[0030] FIG. 3 illustrates the design of the Hanzo Service Node or Hanzo Turn Server 300, according to an embodiment, illustrating the different components/modules/units implemented on the orchestration server 120 and on the services nodes 111, 112. A virtual machine (or Hanzo VM), is deployed on each service node 111, 112 to provide full isolation between the whole process. At this level the virtual machine can use/perform the following: [0031] Control bandwidth. Adjust bandwidth at virtual machine level using wondershaper and/or TC opensource software. [0032] Network tagging between three interfaces, first one for management, second one for international traffic, and the last one for service purposes. [0033] DNS SRV. A bind server with the DNS SRV entries. [0034] Process stat. For monitoring purposes it collects information from standard proc pseudo-filesystem of Linux operating system which provides an interface to kernel data structures. [0035] Redis Database. As required for Hanzo Service Node or Hanzo Turn Server 300 Redis Database will store detailed information about the use of Hanzo Service Node or Hanzo Turn Server 300.

[0036] In addition, a software module (or Hanzo Cotum server) is implemented on each virtual machine, particularly based on Cotum opensource software instance to control which services nodes 111, 112 are in running state in order to route traffic or not. Other tasks/features/components of the software module can be: [0037] QoS Management control to control QoS, in terms of latency, jitter and bandwidth. The algorithms and intelligence determine which interface and route must be used to achieve the service level agreement. [0038] Rest API TURN Services. Module that will respond to a request to access to the service following the standard defined in http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00. [0039] Usage tracking & logging module to keep tracking of user consumption and logging, for billing or auditing purposes. [0040] KPIs & Health checks metrics to monitor health status of the service nodes 111, 112 process and connections. KPIS can be: [0041] QoS KPIs: [0042] Bandwidth, jitter, latency. [0043] IP metrics: [0044] Total packets received, invalid head, forwarded, with unknown protocol, incoming packets discarded, incoming packets delivered, requests sent out, outgoing packets dropped, dropped because of missing route, reassembly required, and packets reassembled ok. [0045] UDP metrics: [0046] Packets received, packets to unknown port received, packet receive errors, packets sent, receive buffer errors and send buffer errors. [0047] TCP metrics: [0048] Active connection openings, passive connection openings, failed connection attempts, connection resets received, connections established, segments received, segments sent out, segments retransmitted, bad segments received and resets sent. [0049] ICMP metrics: [0050] Destination unreachable, echo requests, echo replies.

[0051] The orchestration server 120 is responsible for starting and maintaining the service nodes 111, 112 according to the needs of each tenant. This is performed based on the consumption of CPU, memory and mainly network resources, such as IP resources, among others, assigned to that tenant. This module 120 has the knowledge of the complete connectivity of the network and is the responsible of selecting the best service node 111, 112 for each connection based on location information, latency, jitter and bandwidth.

[0052] The orchestration server 120 can comprise a QoS bandwidth management unit/element (i.e. a software responsible of adapt the bandwidth to the connection), and a profile management software to keep control of users, groups of users, and tags related to users or groups, for each tenant. The orchestration server 120 can use Auth 2.0 to maintain compatibility with an industry-standard protocol for authorization. OAuth authorization framework is a protocol that allows a user to grant a third-party web site or application access to the user's protected resources, without necessarily revealing their long-term credentials or even their Identity. The orchestration server 120 can also have a Log Repository to ensure that the information of each of the connections, to which user they belong, the duration and quality is stored. In addition, the orchestration server 120 can have a KPI's Status module that ensures service KPIs SLA's compliance and previous technical KPIs.

[0053] Particularly, the invention takes into account the following: [0054] Ready service node. The node is up and running to receive traffic. [0055] Enabled service node. The node is processing network traffic and has the capacity to receive more connections. [0056] Saturated service node. The node is processing network traffic but has reached 90% of the capacity of the node. [0057] Disabled service node. The node is disabled due to any network or platform issue.

[0058] In some embodiments, the algorithm implemented by the orchestration server 120 can consider one or more of the following metrics: [0059] Users geolocation: each user or request will be mapped to a pre-established physical point in the underlay network. It should be noted that the total number of possible physical points is limited and reflects the complexity of the network. The orchestration server 120 contains network metrics between any pair of a Hanzo Turn Server 300 and a physical point. [0060] LHN (h, p): Latency between service node h and physical point p. For each service node alive table of latencies between the service node and any physical network point is maintained and stored. [0061] JHN (h, p): Jitter between service node h and physical point p. For each service node a live table of Jitter between the service node and any physical network point is maintained and stored. [0062] Each user has a weight (W) associated that indicates its importance in a multi-user application session. For instance, video traffic of the teacher should be more important than video traffic related with students in education application. [0063] ACMG or Available Capacity Metric Gbps: based on the network infrastructure capacity in each location and consumption of bandwidth an available capacity metric measured in Gbps is determined. [0064] HHNI Hanzo Health Node Indicator (0-1): Based on IP, TCP and UDP metrics a health node Indicator is measured in a percentage. These metrics determine how fast the service node is processing the traffic.

[0065] According to an embodiment, the selection rules for the best suitable service node 111, 112 is made by firstly selecting the Hanzo Service Node or Hanzo Turn servers according to their status. Only those nodes in Ready Status should be used as candidate nodes. Secondly, from these candidate nodes, all those nodes with ACMG less than a threshold will be discarded, and then, from previous candidate, all those nodes with HHNI less than a threshold will be discarded. At that point, for each node i in de candidate list, V.sub.i is computed according following function:

[00001]$V_i=\underset{j=1}{\overset{N}{.Math.}}\left(\mathrm{LHN}\left(i,j\right)\times \alpha +\mathrm{JHN}\left(i,j\right)\times \left(1-\alpha \right)\right)\times W_j,$

where α∈[0,1] indicates the relative importance of Latency and Jitter in a given service, whereas W.sub.j is the user weight of the user j in the application session. These two parameters can change according the application requirements. Finally, the service node 111, 112 that minimizes the value of V.sub.i is selected.

[0066] With reference to FIG. 4 therein an example of the network QoS configuration scheme is illustrated. The network QoS is based on several technologies including: [0067] DSCP for WiFi access between devices and home router. It's based on the IEEE 802.11e wireless QoS standard, and works with 802.11a, b, g, and n physical layer standards. At WiFi level user will interact with an APP to select and give priority to the selected service. DSCP is a process to classify and mark network packets that belong to a specific class. A limited number of classes are defined in Diffserv. [0068] 802.1p. Using the QoS and VLAN priorities technology the service nodes 111, 112 assign a priority to the outputted packets. Packets containing the specified VID are marked with the priority level configured in a packet classifier into internal network. This 802.1 priority determines the outbound port queue to which the packet is sent. [0069] For Mobile networks QCI (QoS Class Identifier) will be used to ensure that traffic is routed in their appropriate traffic type. [0070] Quality will be selected between RT traffic and no RT traffic. Both quality selections will be done using configurations of packets processing queues in each location where a service node 111, 112 will be running. Service nodes 111, 112 will be connected to two different network interfaces one for RT and other for no RT, selection of the Interface will be determined by SLA agreement. [0071] For the traffic flow, in the service provider router access a configuration for Ingress and egress is done in each router and applied in each interface for the different QoS. A VLAN is associated to each one interface type in the configuration of the router. Each marked packet will be treated and respected throughout the service provider network. Outside the service provider, this prioritization will have no effect.

[0072] Various aspects of the proposed method, as described herein, may be embodied in programming. Program aspects of the technology may be thought of as “products” or “articles of manufacture” typically in the form of executable code and/or associated data that is carried on or embodied in a type of machine readable medium. Tangible non-transitory “storage” type media include any or all of the memory or other storage for the computers, processors, or the like, or associated modules thereof, such as various semiconductor memories, tape drives, disk drives and the like, which may provide storage at any time for the software programming.

[0073] Those skilled in the art will recognize that the present teachings are amenable to a variety of modifications and/or enhancements. For example, although the implementation of various components described herein may be embodied in a hardware device, it may also be implemented as a software only solution—e.g., an installation on an existing server. In addition, image processing as disclosed herein may be implemented as a firmware, firmware/software combination, firmware/hardware combination, or a hardware/firmware/software combination.

[0074] The present disclosure and/or some other examples have been described in the above. According to descriptions above, various alterations may be achieved. The topic of the present disclosure may be achieved in various forms and embodiments, and the present disclosure may be further used in a variety of application programs. All applications, modifications and alterations required to be protected in the claims may be within the protection scope of the present disclosure.

[0075] The scope of the present invention is defined in the following set of claims.