Mechanism to coordinate end to end quality of service between network nodes and service provider core

Information

  • Patent Grant
  • 11658912
  • Patent Number
    11,658,912
  • Date Filed
    Wednesday, May 19, 2021
    3 years ago
  • Date Issued
    Tuesday, May 23, 2023
    a year ago
Abstract
Systems, methods, and devices are disclosed for providing a quality of service between nodes. A service provider can receive, from a first node of a customer network to an ingress node of a service provider network, packets bound for a second node on the customer network that is remote from the first node. The packets are mapped to a network segment according to a traffic type based on an identifier associated with the packets that identifies the traffic type of the packets. The packets are sent via their mapped network segment to an egress node with connectivity to the second node of the customer network according to a quality of service associated with the traffic type identified by the identifier.
Description
TECHNICAL FIELD

The present disclosure relates generally to traffic routing over a service provider network, and in particular to quality of service implementation cutting across service provider and user networks.


BACKGROUND

With the advent of 5G networks, network operators will be able to orchestrate specific capabilities across their networks. Network slicing is the ability to deliver multiple network occurrences over one shared infrastructure, while also improving flexibility and agility across the network. This means that different “slices” of the network, or network segments, can be created and customized depending on a system's needs. For example, within a shared network infrastructure, a slice or segment can be used for a specific industry, for a specific need, and/or even at a specific time.


The concept of end to end network slicing introduced by 5G opens up the potential for service providers to offer value added services to their customers. These service providers provide fixed broadband to their customers according to their customer network's quality of service (QoS), which in turn affects the quality of experience (QoE) for the user. However, while service provider operators may have control over the logical segmentation of the network in their own core, they lack any QoS control between nodes in the customer network itself. If there is a remote node in a customer network, for example, the QoS may differ between the remote node and a node on the customer's local network. Hence there is a need to come up with a mechanism to provide coordinated segmentation and QoE between customer networks and service provider networks. Here, a solution is provided that uses segment routing to route traffic in the service provider core that supports differentiated QoS for business-critical applications and traffic types at all nodes.





BRIEF DESCRIPTION OF THE DRAWINGS

The above-recited and other advantages and features of the present technology will become apparent by reference to specific implementations illustrated in the appended drawings. A person of ordinary skill in the art will understand that these drawings only show some examples of the present technology and would not limit the scope of the present technology to these examples. Furthermore, the skilled artisan will appreciate the principles of the present technology as described and explained with additional specificity and detail through the use of the accompanying drawings in which:



FIG. 1 shows an example schematic diagram of a framework for mapping traffic to network segments in accordance with some embodiments;



FIG. 2 is a flowchart representation of providing a quality of service between nodes via dynamic mapping of traffic to network segments in accordance with some embodiments;



FIG. 3 shows an example of a system for implementing certain aspects of the present technology.





DESCRIPTION OF EXAMPLE EMBODIMENTS

Various examples of the present technology are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the present technology.


Overview

Systems, methods, and devices are disclosed for providing a quality of service between nodes. A service provider can receive, from a first node of a customer network to an ingress node of a service provider network, packets bound for a second node on the customer network that is remote from the first node. The packets are mapped to a network segment according to a traffic type based on an identifier associated with the packets that identifies the traffic type of the packets. The packets are sent via their mapped network segment to an egress node with connectivity to the second node of the customer network according to a quality of service associated with the traffic type identified by the identifier.


Example Embodiments

The disclosed technology addresses the need in the art for coordinated segmentation and QoE between service provider networks and nodes in a customer network. The disclosure herein provides endpoint to endpoint network slicing capabilities to introduce a dynamic, on demand coordinated QoS policy exchange between nodes on a customer network and a service provider network that provides connectivity between the customer nodes. Differentiated quality of service (QoS) for various traffic types or applications between different customer nodes, even nodes remote from the local customer network, can be accomplished through the following network slicing techniques.


Network slicing involves the logical segmentation of network infrastructure resources in a network. The concept of slicing spans across many types of networks, including Radio, RAN, and Mobile Packet Core networks. Network slicing also enables segmentation and micro-segmentation services supported in customer networks, which provides a mechanism for service providers to offer value added services for their customers by offering different QoS service level agreements (SLA) for different types of traffic.


Segment routing is a mechanism available to logically segment a network, such as a service provider's core network. In segment routing, traffic flows can be steered towards different paths in the network based on network element characteristics (such as throughput delay, reliability, load etc.). Service providers can perform path calculations for various segments and then signal their network devices or other nodes with a policy configuration to provide an ordered list of segments (e.g., through an MPLS stack of labels for IPv4 and/or routing extension headers for IPv6).


According to various embodiments, a service provider can receive, from a first node of a customer network to an ingress node of a service provider network, packets bound for a second node on the customer network. The second node of the customer network can be remote from the first node of the customer network according to some examples. For instance, the first node can be a device that is local to the customer (e.g., for an enterprise customer, a device or an IP address that is located on site at the enterprise's main premise), and the second node can be remote (e.g., a device or IP address associated with a branch office of the enterprise, or a connection to the enterprise network from an employee's mobile device). Packets can be mapped to a network segment according to a traffic type. The mapping can be based on an identifier associated with the packets that identifies the traffic type of the packets. The packets are sent via their mapped network segment to an egress node with connectivity to the second node of the customer network according to a quality of service associated with the traffic type identified by the identifier.



FIG. 1 shows an example schematic diagram of a framework for mapping traffic to network segments in accordance with some embodiments. System 100 can include multiple nodes within a customer network, such as node A 110 and node B 112 (although the customer network can include any number of nodes, both on premise and remote). Node A 110 and node B 112 are in communication with each other through service provider 114, which provides Internet connectivity between nodes A and B 110, 112. The customer network supports multiple types of traffic, including, but not limited to, alternate reality/virtual reality (AV/VR) 116, high definition (HD) video 118, and Voice over IP (Voice) 120. These types of traffic can share portions of bandwidth with varying priority levels for each traffic type over the customer network according to a QoS that is associated with one or more parameters of an SLA. For example, the QoS parameters can include, but are not limited to, parameters associated with delay, throughput, bandwidth, latency, and loss characteristics associated with each traffic type.


Node B 112 may be remote from node A 110, but supports the same types of traffic as node A 110 since it is part of the customer's network. For example, in system 100, node B 112 also supports AV/VR 116, HD video 118, and Voice 120 traffic types. However, although traffic needs to travel or be routed through service provider 114, the QoS needs to be consistent across all nodes on the customer network, such that the QoE between node A 110 remains consistent for node B 112. For example, the quality of latency for Voice 120 at node A 110 should not drop below its SLA at node B 112.


Accordingly, in order to provide consistency between the nodes, service provider 114 can map the traffic packets to one or more network segments according to the traffic type using one or more network slicing techniques. For example, service provider 114 can slice their network into segment A 122, which routes traffic of type HD Video. Similarly, segment B 124 routes traffic type AR/VR, and segment C 126 routes traffic type Voice. Each segment is a route consisting of a set of devices on the service provider's network that routes traffic from ingress node 130 to egress node 132.


Mapping the traffic type to a specific segment can, according to some embodiments, be based on identifiers (e.g., HD Video ID, AR/VR ID, and Voice ID) associated with the packets that identifies the packet's traffic type and/or QoS parameters associated with the traffic type (e.g., as specified for each traffic type through an SLA, for example). The identifier can be included in the packet's header, for example, which can be used by service provider 114 to match the identifier with an appropriate segment. In some embodiments, service provider 114 can use the identifiers to create a segment by defining a path through devices in the service provider's network that are consistent with the QoS parameters associated with the traffic type's identifiers.


According to some embodiments, the customer network can define one or more software defined access (SDA) parameters, which may specify the security level associated with each traffic type. Service provider 114 can receive the SDA parameters and then use them to implement segmentation overlay. In an SDA enabled network, for example, VXLAN Network identifiers (VNIs) are used to represent a desired logical overlay segment. SDA may also support an additional identifier termed as scalable group tags (SGT). SGT can be used to further apply granular policies such as QoS and traffic steering for specific application flow types and/or security needs. In order to extend the QoS implementation in the service provider core, the SGT can be mapped from the customer's network fabric to segment routing segment identifiers in the service provider core network. These segment identifiers (SIDs) will be used to steer the traffic to the appropriate network slice in the service provider core.


In this manner, each traffic type runs the same on any node within the customer network, regardless of whether the node is remote or not. Therefore, the quality of experience for a user can be differentiated across traffic types and/or specific applications.



FIG. 2 is a flowchart representation of an example process for providing a consistent quality of service between nodes via dynamic mapping of traffic to network segments in accordance with some embodiments. Coordinating QoS between node A 110 and node B 112, for example, can begin by receiving, from node A 110 of a customer network to an ingress node 130 of a service provider network, packets bound for node B 112 on the customer network that is remote from the node A 110 (step 210). As discussed above, node A 110 and node B 112 are in communication with each other through service provider 114, and node B 112 may be remote from node A 110. For example, node A 110 can include a campus or on premise site, and node B 112 can include a remote site.


Service provider 114 can include multiple segments, or slices, of the service provider's network. For example, each segment of the service provider's network is comprised of a path of nodes that are selected to comply with the quality of service associated with the traffic type. For example, while service provider 114 offers a range of devices on a shared physical network infrastructure, certain devices may be added or assigned to a virtual network representing a segment based on the device's quality, capabilities, performance history, etc. Thus, if there are three traffic flow types with three different QoS policies, three different segments will be mapped to the traffic. For example, in system 100, the QoS may have a first policy for AR/VR 116 end points, a second policy for HD video 118 end points, and a third policy for voice 120 end points.


Packets are mapped according to a traffic type to a network segment, where the mapping is based on an identifier associated with the packets that identifies the traffic type of the packets (step 212). These can be mapped based on QoS policies differentiated around traffic types. The traffic type can be associated with a type or quality of service, where the type or quality of service include parameters that can be mapped to logical resources within the network segment.


The identifier can be included within a header of the packets that identifies the traffic type and QoS parameters for the packets. For example, within the customer network, types of traffic flows can be mapped to three overlay segments represented by SGTs. The objective is to dynamically map the QoS policies between the customer network and the service provider core. To do so, a WAN circuit may be using one of the many tunnel encapsulation types between the customer's WAN router and the service provider's Aggregation router. Regardless of encapsulation type, an NSH header can be inserted to carry the SGT information. To map the SGT to the right set of segment identifiers, an Application Specific Interface (API) between a controller in the service provider, such as a service provider's path calculation service that is part of a software defined networking (SDN) controller, and the customer network can enable the customer network to convey the mapping information for various QoS SLAB to a service provider's path calculation service via the SDN controller interface. The service provider 114, after performing traffic engineering path computations by service provider's path calculation service, will have an ordered list of segments which needs to be added to the packets to steer the traffic through the right network slice. This can be accomplished by the service provider's path calculation service by signaling routing information to the Aggregation router, which forwards traffic to the correct segment.


The packets can then be sent via the network segment to egress node 132 with connectivity to node B 112 according to a quality of service associated with the traffic type identified by the identifier (step 214). Egress node 132 forwards the traffic to node B 112, which will route traffic to specific devices within node B's network.


While embodiments have shown node B 112 to be a node within a customer's remote branch office, other embodiments can apply the same technique if node B 112 is within a mobile radio network. Any node endpoints that represent nodes communicating via a service provider network is therefore contemplated by the disclosure above.



FIG. 3 shows an example of computing system 300 in which the components of the system in FIGS. 1 and 2 are in communication with each other using connection 305. Connection 305 can be a physical connection via a bus, or a direct connection into processor 310, such as in a chipset architecture. Connection 305 can also be a virtual connection, networked connection, or logical connection.


In some embodiments computing system 300 is a distributed system in which the functions described in this disclosure can be distributed within a datacenter, multiple datacenters, a peer network, etc. In some embodiments, one or more of the described system components represents many such components each performing some or all of the function for which the component is described. In some embodiments, the components can be physical or virtual devices.


Example system 300 includes at least one processing unit (CPU or processor) 310 and connection 305 that couples various system components including system memory 315, such as read only memory (ROM) and random access memory (RAM) to processor 310. Computing system 300 can include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of processor 310.


Processor 310 can include any general purpose processor and a hardware service or software service, such as services 332, 334, and 336 stored in storage device 330, configured to control processor 310 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. Processor 310 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.


To enable user interaction, computing system 300 includes an input device 345, which can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech, etc. Computing system 300 can also include output device 335, which can be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input/output to communicate with computing system 300. Computing system 300 can include communications interface 340, which can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.


Storage device 330 can be a non-volatile memory device and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs), read only memory (ROM), and/or some combination of these devices.


The storage device 330 can include software services, servers, services, etc., that when the code that defines such software is executed by the processor 310, it causes the system to perform a function. In some embodiments, a hardware service that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as processor 310, connection 305, output device 335, etc., to carry out the function.


For clarity of explanation, in some instances the present technology may be presented as including individual functional blocks including functional blocks comprising devices, device components, steps or routines in a method embodied in software, or combinations of hardware and software.


Any of the steps, operations, functions, or processes described herein may be performed or implemented by a combination of hardware and software services or services, alone or in combination with other devices. In some embodiments, a service can be software that resides in memory of a client device and/or one or more servers of a content management system and perform one or more functions when a processor executes the software associated with the service. In some embodiments, a service is a program, or a collection of programs that carry out a specific function. In some embodiments, a service can be considered a server. The memory can be a non-transitory computer-readable medium.


In some embodiments the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bit stream and the like. However, when mentioned, non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.


Methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer readable media. Such instructions can comprise, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, solid state memory devices, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.


Devices implementing methods according to these disclosures can comprise hardware, firmware and/or software, and can take any of a variety of form factors. Typical examples of such form factors include servers, laptops, smart phones, small form factor personal computers, personal digital assistants, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.


The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures.


Although a variety of examples and other information was used to explain aspects within the scope of the appended claims, no limitation of the claims should be implied based on particular features or arrangements in such examples, as one of ordinary skill would be able to use these examples to derive a wide variety of implementations. Further and although some subject matter may have been described in language specific to examples of structural features and/or method steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or acts. For example, such functionality can be distributed differently or performed in components other than those identified herein. Rather, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims.

Claims
  • 1. A computer implemented method for ensuring a minimum quality of service between two network nodes, the method comprising: receiving, from a first node of a customer network to an ingress node of a service provider network, packets bound for a second node on the customer network that is remote from the first node, wherein the packets include an identifier associated with a traffic type of a plurality of traffic types configured on the customer network;mapping the packets to a set of segment routing identifiers corresponding to a network path according to the traffic type, the mapping based on the identifier associated with the packets that identifies the traffic type of the packets, wherein the network path is a virtual network within a shared physical network infrastructure of the service provider network and defines a path to the second node through devices in the service provider network that are consistent with one or more quality-of-service (QoS) parameters associated with the identifier corresponding to the traffic type; andsending the packets via the network path to an egress node with connectivity to the second node according to a quality of service associated with the traffic type identified by the identifier.
  • 2. The method of claim 1, further comprising: determining, by a path computation element, the collection of nodes defining the network path through the shared physical network infrastructure calculating the paths through the network; andcombining the segment routing identifiers associated with the nodes of the collection to create the set of segment routing identifiers for the network path.
  • 3. The method of claim 1, wherein the packets further include an identifier associated with a virtual network overlay associated with the customer network.
  • 4. The method of claim 1, further comprising: providing to the customer network an application programming interface adapted to receive a set of identifiers each corresponding to a traffic type of a plurality of traffic types and a mapping of each traffic type identifier to one or more Quality of Service (QoS) service levels.
  • 5. The method of claim 4, further comprising: determining, by a path computation element and based on the mapping received from the customer network, a collection of nodes defining the network path through the shared physical network infrastructure calculating the paths through the network; andcombining the segment routing identifiers associated with the nodes of the collection to create the set of segment routing identifiers for the network path.
  • 6. The method of claim 1, wherein the identifier is a scalable group tag included within a network service header (NSH) of the packets that identifies the traffic type and quality of service parameters for the packets.
  • 7. The method of claim 1, wherein the quality of service comprises one or more parameters associated with delay, throughput, bandwidth, latency, or loss characteristics associated with the traffic type.
  • 8. The method of claim 1, wherein the quality of service is associated with one or more parameters of a service level agreement, and wherein a segmentation overlay comprising the network path is based on the one or more parameters of the service level agreement and the network path is a desired logical overlay path associated with a VXLAN Network identifier (VNI).
  • 9. A non-transitory computer-readable medium comprising instructions stored thereon, the instructions executable by one or more processors to perform a computer implemented method for ensuring a minimum quality of service between two network nodes, the instructions to: receive, from a first node of a customer network to an ingress node of a service provider network, packets bound for a second node on the customer network that is remote from the first node, wherein the packets include an identifier associated with a traffic type of a plurality of traffic types configured on the customer network;map the packets to a set of segment routing identifiers corresponding to a network path according to the traffic type, the mapping based on the identifier associated with the packets that identifies the traffic type of the packets, wherein the network path is a virtual network within a shared physical network infrastructure of the service provider network and defines a path to the second node through devices in the service provider network that are consistent with one or more quality-of-service (QoS) parameters associated with the identifier corresponding to the traffic type; andsend the packets via the network path to an egress node with connectivity to the second node according to a quality of service associated with the traffic type identified by the identifier.
  • 10. The non-transitory computer-readable medium of claim 9, wherein the instructions are further operative to: receive from a path computation engine the set of segment routing identifiers created by determining, by the path computation element, a collection of nodes defining the network path through the shared physical network infrastructure calculating the paths through the network; andcombine the segment routing identifiers associated with the nodes of the collection to create the set of segment routing identifiers for the network path.
  • 11. The non-transitory computer-readable medium of claim 9, wherein the packets further include an identifier associated with a virtual network overlay associated with the customer network.
  • 12. The non-transitory computer-readable medium of claim 9, wherein the identifier is a scalable group tag included within a network service header (NSH) of the packets that identifies the traffic type and quality of service parameters for the packets.
  • 13. The non-transitory computer-readable medium of claim 9, wherein the quality of service comprises one or more parameters associated with delay, throughput, bandwidth, latency, or loss characteristics associated with the traffic type.
  • 14. The non-transitory computer-readable medium of claim 9, wherein the quality of service is associated with one or more parameters of a service level agreement, and wherein a segmentation overlay comprising the network path is based on the one or more parameters of the service level agreement and the network path is a desired logical overlay path associated with a VXLAN Network identifier (VNI).
  • 15. A system for ensuring a minimum quality of service between two network nodes, the system comprising: one or more processors; anda communication interface coupled to the one or more processors, wherein the communication interface is configured to communicate with a local node and a remote node on a customer network, and wherein the one or more processors are configured to perform operations comprising:receiving, from a first node of a customer network to an ingress node of a service provider network, packets bound for a second node on the customer network that is remote from the first node, wherein the packets include an identifier associated with a traffic type of a plurality of traffic types configured on the customer network;mapping the packets to a set of segment routing identifiers corresponding to a network path according to the traffic type, the mapping based on the identifier associated with the packets that identifies the traffic type of the packets, wherein the network path is a virtual network within a shared physical network infrastructure of the service provider network and defines a path to the second node through devices in the service provider network that are consistent with one or more quality-of-service (QoS) parameters associated with the identifier corresponding to the traffic type; andsending the packets via the network path to an egress node with connectivity to the second node according to a quality of service associated with the traffic type identified by the identifier.
  • 16. The system of claim 15, wherein the one or more processors are further configured to: receive from a path computation engine the set of segment routing identifiers created by determining, by the path computation element, a collection of nodes defining the network path through the shared physical network infrastructure calculating the paths through the network; andcombine the segment routing identifiers associated with the nodes of the collection to create the set of segment routing identifiers for the network path.
  • 17. The system of claim 15, wherein the packets further include an identifier associated with a virtual network overlay associated with the customer network.
  • 18. The system of claim 15, wherein the identifier is a scalable group tag included within a network service header (NSH) of the packets that identifies the traffic type and quality of service parameters for the packets.
  • 19. The system of claim 15, wherein the quality of service comprises one or more parameters associated with delay, throughput, bandwidth, latency, or loss characteristics associated with the traffic type.
  • 20. The system of claim 15, wherein the quality of service is associated with one or more parameters of a service level agreement, and wherein a segmentation overlay comprising the network path is based on the one or more parameters of the service level agreement and the network pati is a desired logical overlay path associated with a VXLAN Network identifier (VPN).
CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No. 16/788,652, filed on Feb. 12, 2020, which in turn, is a continuation of U.S. patent application Ser. No. 16/111,074 filed on Aug. 23, 2018, the contents of which is incorporated by reference in its entirety.

US Referenced Citations (168)
Number Name Date Kind
4236068 Walton Nov 1980 A
5642303 Small et al. Jun 1997 A
5751223 Turner May 1998 A
6812824 Goldinger et al. Nov 2004 B1
D552603 Tierney Oct 2007 S
7573862 Chambers et al. Aug 2009 B2
D637569 Desai et al. May 2011 S
7975262 Cozmei Jul 2011 B2
8010079 Mia et al. Aug 2011 B2
8102814 Rahman et al. Jan 2012 B2
8260320 Herz Sep 2012 B2
8284748 Borghei Oct 2012 B2
8300594 Bernier et al. Oct 2012 B1
8325626 Tóth et al. Dec 2012 B2
8396485 Grainger et al. Mar 2013 B2
8446899 Lei et al. May 2013 B2
8458184 Dorogusker et al. Jun 2013 B2
D691636 Bunton Oct 2013 S
8549638 Aziz Oct 2013 B2
8644301 Tamhankar et al. Feb 2014 B2
8650279 Mehta et al. Feb 2014 B2
8669902 Pandey et al. Mar 2014 B2
8676182 Bell et al. Mar 2014 B2
8682279 Rudolf et al. Mar 2014 B2
8693367 Chowdhury et al. Apr 2014 B2
8718644 Thomas et al. May 2014 B2
8761174 Jing et al. Jun 2014 B2
8768389 Nenner et al. Jul 2014 B2
8849283 Rudolf et al. Sep 2014 B2
8909698 Parmar et al. Dec 2014 B2
8958318 Hastwell et al. Feb 2015 B1
9060352 Chan et al. Jun 2015 B2
9130859 Knappe Sep 2015 B1
9173084 Foskett Oct 2015 B1
9173158 Varma Oct 2015 B2
D744464 Snyder et al. Dec 2015 S
9270709 Shatzkamer et al. Feb 2016 B2
D757424 Phillips et al. May 2016 S
D759639 Moon et al. Jun 2016 S
9389992 Gataullin et al. Jul 2016 B2
9426305 De Foy et al. Aug 2016 B2
D767548 Snyder et al. Sep 2016 S
D776634 Lee et al. Jan 2017 S
9544337 Eswara et al. Jan 2017 B2
9609504 Karlqvist et al. Mar 2017 B2
9642167 Snyder et al. May 2017 B1
9654344 Chan et al. May 2017 B2
9712444 Bolshinsky et al. Jul 2017 B1
9713114 Yu Jul 2017 B2
9772927 Gounares et al. Sep 2017 B2
9820105 Snyder et al. Nov 2017 B2
D804450 Speil et al. Dec 2017 S
9858559 Raleigh et al. Jan 2018 B2
9860151 Ganichev et al. Jan 2018 B2
9933224 Dumitriu et al. Feb 2018 B2
9923780 Rao et al. Mar 2018 B2
9967906 Verkaik et al. May 2018 B2
9980220 Snyder et al. May 2018 B2
9985837 Rao et al. May 2018 B2
20030087645 Kim et al. May 2003 A1
20030116634 Tanaka Jun 2003 A1
20040203572 Aerrabotu et al. Oct 2004 A1
20050090225 Muehleisen et al. Apr 2005 A1
20050169193 Black et al. Aug 2005 A1
20050186904 Kowalski et al. Aug 2005 A1
20060022815 Fischer et al. Feb 2006 A1
20060030290 Rudolf et al. Feb 2006 A1
20060092964 Park et al. May 2006 A1
20060126882 Deng et al. Jun 2006 A1
20060187866 Werb et al. Aug 2006 A1
20070037605 Logan Feb 2007 A1
20070239854 Janakiraman et al. Oct 2007 A1
20080037715 Prozeniuk et al. Feb 2008 A1
20080084888 Yadav et al. Apr 2008 A1
20080101381 Sun et al. May 2008 A1
20080163207 Reumann et al. Jul 2008 A1
20080233969 Mergen Sep 2008 A1
20090129389 Halna DeFretay et al. May 2009 A1
20090203370 Giles et al. Aug 2009 A1
20090282048 Ransom et al. Nov 2009 A1
20090298511 Paulson Dec 2009 A1
20090307485 Weniger et al. Dec 2009 A1
20100039280 Holm et al. Feb 2010 A1
20100097969 De Kimpe et al. Apr 2010 A1
20110087799 Padhye et al. Apr 2011 A1
20110142053 Van Der Merwe et al. Jun 2011 A1
20110182295 Singh et al. Jul 2011 A1
20110194553 Sahin et al. Aug 2011 A1
20110228779 Goergen Sep 2011 A1
20110299414 Yu et al. Dec 2011 A1
20120023552 Brown et al. Jan 2012 A1
20120054367 Ramakrishnan et al. Mar 2012 A1
20120088476 Greenfield Apr 2012 A1
20120115512 Grainger et al. May 2012 A1
20120157126 Rekimoto Jun 2012 A1
20120167207 Beckley et al. Jun 2012 A1
20120182147 Forster Jul 2012 A1
20120311127 Kandula et al. Dec 2012 A1
20120324035 Cantu et al. Dec 2012 A1
20130029685 Moshfeghi Jan 2013 A1
20130039391 Skarp Feb 2013 A1
20130057435 Kim Mar 2013 A1
20130077612 Khorami Mar 2013 A1
20130088983 Pragada et al. Apr 2013 A1
20130107853 Pettus et al. May 2013 A1
20130108263 Srinivas et al. May 2013 A1
20130115916 Herz May 2013 A1
20130145008 Kannan et al. Jun 2013 A1
20130155906 Nachum et al. Jun 2013 A1
20130191567 Rofougaran et al. Jul 2013 A1
20130203445 Grainger et al. Aug 2013 A1
20130217332 Altman et al. Aug 2013 A1
20130232433 Krajec et al. Sep 2013 A1
20130273938 Ng et al. Oct 2013 A1
20130317944 Huang et al. Nov 2013 A1
20130322438 Gospodarek et al. Dec 2013 A1
20130343198 Chhabra et al. Dec 2013 A1
20130347103 Veteikis et al. Dec 2013 A1
20140007089 Bosch et al. Jan 2014 A1
20140016926 Soto et al. Jan 2014 A1
20140025770 Warfield et al. Jan 2014 A1
20140052508 Pandey et al. Feb 2014 A1
20140059655 Beckley et al. Feb 2014 A1
20140087693 Walby et al. Mar 2014 A1
20140105213 A K et al. Apr 2014 A1
20140118113 Kaushik et al. May 2014 A1
20140148196 Bassan-Eskenazi et al. May 2014 A1
20140179352 V.M. et al. Jun 2014 A1
20140191868 Ortiz et al. Jul 2014 A1
20140198808 Zhou Jul 2014 A1
20140233460 Pettus et al. Aug 2014 A1
20140269321 Kamble et al. Sep 2014 A1
20140302869 Rosenbaum et al. Oct 2014 A1
20140337824 St. John et al. Nov 2014 A1
20140341568 Zhang et al. Nov 2014 A1
20150016286 Ganichev et al. Jan 2015 A1
20150016469 Ganichev et al. Jan 2015 A1
20150030024 Venkataswami et al. Jan 2015 A1
20150043581 Devireddy et al. Feb 2015 A1
20150063166 Sif et al. Mar 2015 A1
20150065161 Ganesh et al. Mar 2015 A1
20150087330 Prechner et al. Mar 2015 A1
20150103818 Kuhn et al. Apr 2015 A1
20150163192 Jain et al. Jun 2015 A1
20150172391 Kasslin et al. Jun 2015 A1
20150223337 Steinmacher-Burow Aug 2015 A1
20150256972 Markhovsky et al. Sep 2015 A1
20150264519 Mirzaei et al. Sep 2015 A1
20150280827 Adiletta et al. Oct 2015 A1
20150281099 Banavalikar et al. Oct 2015 A1
20150288410 Adiletta et al. Oct 2015 A1
20150326704 Ko et al. Nov 2015 A1
20150358777 Gupta Dec 2015 A1
20150362581 Friedman et al. Dec 2015 A1
20160007315 Lundgreen et al. Jan 2016 A1
20160044627 Aggarwal et al. Feb 2016 A1
20160099847 Melander et al. Apr 2016 A1
20160105408 Cooper et al. Apr 2016 A1
20160127875 Zampini, II May 2016 A1
20160146495 Malve et al. May 2016 A1
20160337251 Venkataramanan et al. Nov 2016 A1
20160344641 Javidi et al. Nov 2016 A1
20170026974 Dey et al. Jan 2017 A1
20170214551 Chan et al. Jul 2017 A1
20170230299 Chorafakis et al. Aug 2017 A1
20170332421 Sternberg Nov 2017 A1
20180069311 Pallas et al. Mar 2018 A1
20180084389 Snyder et al. Mar 2018 A1
Foreign Referenced Citations (3)
Number Date Country
WO 2013020126 Feb 2013 WO
WO 2014098556 Jun 2014 WO
WO 2018009340 Jan 2018 WO
Non-Patent Literature Citations (27)
Entry
“I Love WiFi, The difference between L2 and L3 Roaming Events,” Apr. 1, 2010, 6 pages.
Afolabi, Ibrahim, et al., “Network Slicing & Softwarization: A Survey on Principles, Enabling Technologies & Solutions,” Mar. 21, 2018, pp. 1-24.
Antonioli, Roberto, et al., “Dual Connectivity for LTE-NR Cellular Networks,” Research Gate, Sep. 3-6, 2017, pp. 171-175.
Carter, Steve Sr., “E911 VoIP Essentials For Enterprise Deployments,” XO Communications, LLC, 2012, 9 pages.
Chalise, Batu K., et al., “MIMO Relaying for Multiaccess Communication in Cellular Networks,” Sensor Array and MultiChannel Signal Processing Workshop, 2008, SAM 2008, 5th IEEE, Jul. 21, 2008, pp. 146-150.
Cisco ASR 5x00 Mobility Management Entity Administration Guide, Version 15.0, Last updated Jun. 13, 2014, Cisco, 1-266.
Cisco Systems, Inc., “Wi-Fi Location-Based Services 4.1 Design Guide,” May 20, 2008, 206 pages.
Cox, Jacob H. Jr., et al., “Advancing Software-Defined Networks: A Survey,” IEEE, Oct. 12, 2017, pp. 25487-25526.
Cui, Wenzhi et al., “DiFS: Distributed Flow Scheduling for Data Center Networks,” Nanjing University, China, Jul. 28, 2013, 10 pages.
Galvan T., Carlos E., et al., “Wifi bluetooth based combined positioning algorithm,” International Meeting of Electrical Engineering Research ENIINVIE 2012, Procedia Engineering 35 (2012), pp. 101-108.
Geller, Michael, et al. , “5G Security Innovation with Cisco,” Whitepaper Cisco Public, Jun. 8, 2018, pp. 1-29.
Gesbert, David, “Advances in Multiuser MIMO Systems (Tutorial Part II) Emerging Topics in Multiuser MIMO Networks,” IEEE PIMRC Conference, Sep. 2007, 107 pages.
Halperin, Daniel, et al., “Augmenting Data Center Networks with Multi-Gigabit Wireless Links,” Aug. 15-19, 2011, SIGCOMM'11, ACM 978-1-4503-0797-0/11/08, pp. 38-49.
Ji, Philip N., et al., “Demonstration of High-Speed MIMO OFDM Flexible Bandwidth Data Center Network,” Optical Society of America, 2012, 2 pages.
Kandula, Srikanth, et al., “Flyways To De-Congest Data Center Networks,” Microsoft Research, Oct. 23, 2009, 6 pages.
Katayama, Y. et al., “MIMO Link Design Strategy for Wireless Data Center Applications,” IEEE Wireless Communications and Networking Conference: Services, Applications, and Business, 2012, 5 pages.
Leary, Jonathan, et al., “Wireless LAN Fundamentals: Mobility,” Jan. 9, 2004, Cisco Press, 15 pages.
Network Heresy, “NVGRE, VXLAN and What Microsoft is Doing Right,” Oct. 3, 2011, 5 pages.
Saraiva de Sousa, Nathan F., et al., “Network Service Orchestration: A Survey,” IEEE Communications Surveys & Tutorials, Mar. 23, 2018, pp. 1-30.
Savvides, Andreas, et al., “Dynamic Fine-Grained Localization in Ad-Hoc Networks of Sensors”, Proceeding MobiCom '01 Proceedings of the 7th annual international conference on Mobile computing and networking, Jul. 2001, pp. 166-179.
Ventre, Pier Luigi, et al., “Performance Evaluation and Tuning of Virtual Infrastructure Managers for (Micro) Virtual Network Functions,” ieee.org, Nov. 7-10, 2016, pp. 1-7.
Boglneni, Kalyani, “SND-NFV Reference Architecture”, Verizon Network Infrastructure Planning, Version 1.0, Feb. 2016, 221 pages.
Ye, Qiang, et al., “A Network Slicing Framework for End-to-End QoS Provisioning in 5G Networks”, University of Waterloo, Feb. 22, 2018, 9 pages.
International Search Report and Written Opinion from the International Searching Authority, dated Nov. 8, 2019, 13 pages, for corresponding International Patent Application No. PCT/US2019/046948.
Quality of Service Regulation Manual, ITU 2017, pp. 1-176.
“Cisco 10000 Series Router Quality of Service Configuration Guide: Chapter 20: Configuring Quality of Service for MPLS Traffic,” Cisco.com, pp. 20-34.
“3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Study on management and orchestration of network slicing for next generation network (Release 15),” 3GPP TR 28.801 V2.0.1 (Sep. 2017), Sep. 7, 2017, 78 pages.
Related Publications (1)
Number Date Country
20210320876 A1 Oct 2021 US
Continuations (2)
Number Date Country
Parent 16788652 Feb 2020 US
Child 17324910 US
Parent 16111074 Aug 2018 US
Child 16788652 US