Patent Description:
The communications industry is rapidly changing to adjust to emerging technologies and ever-increasing customer demand. This customer demand for new applications and increased performance of existing applications is driving communications network and system providers to employ networks and systems having greater speed and capacity (e.g., greater bandwidth). In trying to achieve these goals, a common approach taken by many communications providers is to use packet switching technology. Packets are typically forwarded in a network based on one or more values representing network nodes or paths.

<CIT> is directed to a method performed by a network device functioning as a Broadband Network Gateway (BNG) to enable dynamic service chaining for subscribers. The method includes receiving a first sign of life packet from a subscriber device associated with a subscriber, transmitting, to an authentication, authorization, and accounting (AAA) server, a request to authenticate the subscriber in response to receiving the first sign of life packet from the subscriber device associated with the subscriber, receiving information pertaining to a service chain associated with the subscriber upon successful authentication of the subscriber by the AAA server, generating a routing header to be added to packets belonging to the subscriber based on the information pertaining to the service chain associated with the subscriber, where the routing header includes an indication of the service chain associated with the subscriber.

<CIT> is directed to a method for a dataplane signaled bidirectional/symmetric service chain instantiation for efficient load balancing. The method includes configuring a policy that refers to multiple service function paths that could be used for load balancing network traffic. The method also includes selecting one of the multiple service function paths to send the network traffic in a forward direction. An encapsulation header includes service path identification information identifying the service function path selected for use in the forward direction and an indicator to indicate that that the network traffic is to be sent in a reverse direction using a same service function path selected used for the forward direction. The method includes encapsulating network traffic with the encapsulation header to causes a reverse classifier to program the same service function path for the reverse direction.

In one embodiment, a network apparatus of a core network domain performs mobile packet core mechanism using segment routing (SR) in an in-band manner. The network apparatus may receive one or more packets from an access network, where the packets include accounting information of the packets. The network apparatus may determine a type of traffic for the packets based on the accounting information by classifying whether the packets are originated from a mobile device or machine device. The network apparatus may select a policy configuration from a plurality of policy confirmation for processing the packets based on the classification of the packets. That network apparatus may determine SR policies for the type of traffic for the packets by differently configuring segment identifiers for each traffic type of the packet such that the network apparatus steers the packets to be routed through a network functions of each network slice. The network apparatus may encapsulate the packets with one or more segment identifiers in accordance with the selected policy configuration. The network apparatus may then send the encapsulated packets to a network slice in a second domain network (e.g., GiLAN domain network) based on the one or more segment identifiers.

A service provider provides subscribers' devices (e.g., mobile devices of subscribers) and machine devices (e.g., devices used for internet of thing (IoT)) with communication services in a communication network. The service provider operates an access network and a core network, both of which are included in the communication network to serve traffic flows of the mobile devices and/or the machine devices. The access network of the service provider is a type of telecommunication (e.g., GERAN, UTRAN, E-UTRAN, CMMA <NUM>, GSM, UMTS, WiFi, etc.), which connects subscribers to their immediate service provider via the core network. That is, the access network of the service provider is shared by mobile traffic (i.e., a traffic flow originated by a mobile device used by a user or a subscriber) and IoT traffic (i.e., a traffic flow originated by a machine device). The mobile traffic and the IoT traffic are then connected to the core network through the access network. The access network may use separate sets of antennas respectively dedicated to receiving and transmitting packets related to the mobile traffic and the IoT traffic. The separated sets of antennae are configured to prevent interference therebetween by using separately independent channels and enhancing network function virtualization and quality of service (QoS) for efficient and seamless communication. That is, the service provider assigns each access point naming (APN) to the mobile traffic and the IoT traffic. In other words, the APN may be used to identify if a traffic flow is the mobile traffic or the IoT traffic. The core network, for example virtual evolved packet core (vEPC), may have its common infrastructure including, for example, virtual serving gateway (vSGW) and virtual packet data node gateway (vPGW). The core network may connect to software defined network functions (e.g., software defined network (SDN)), for example, GiLAN, which may deploy at ingress of packet data network (PDN). GiLAN may perform separate sets of functions that are dedicated to either of the mobile traffic and the IoT traffic. GiLAN may perform network service functions (i.e., service function chaining) such as, for example, firewalls, DPI, video optimization, TCP optimization, HTTP header enrichment, NAT, load balancers, caching, etc. That is, GiLAN may support virtualized service functions to make it possible to dynamically configure user plane traffic (e.g., a mobile traffic and IoT traffic in <FIG> and <FIG>) to be routed through a chain of network components which provide value-added service. As an example, traffic of a certain customer (e.g., mobile traffic in <FIG>) may be passed through a protocol optimization component (e.g., for video) or a security function (e.g., firewall in <FIG>) such as a parental control.

<FIG> illustrates an example of a signal flow simplified for mobile traffic and IoT traffic based on a classifier of the GiLAN in a mobile packet network. <FIG> illustrates a simplified block diagram for end-to-end mobile network architecture <NUM> that comprises access network <NUM>, core network <NUM>, GiLAN <NUM> and P router <NUM>. The end-to-end mobile network architecture <NUM> may be represented as several different domains. For one example, GiLAN <NUM> is a domain to perform service function chaining (SFC) and present a software defined network (SDN). For another example, a packet core may be another domain to represent vSGW (not shown in <FIG> for purpose of concise descriptions) and vPGW <NUM> of the core network <NUM>. A traffic flow (e.g., <NUM> or <NUM> in <FIG>) may originate from a mobile device or a machine device through each APN (e.g., <NUM> or <NUM> in <FIG>).

Referring to <FIG>, "APN mobile" <NUM> indicates an APN used for transmitting the mobile traffic <NUM>, and "APN IoT" <NUM> indicates an APN used for transmitting the IoT traffic <NUM>. The traffic flow may be classified as mobile traffic <NUM> or IoT traffic <NUM> according to which device the traffic flow originates from. Each traffic flow (the mobile traffic and IoT traffic) is transmitted from each APN to vPGW <NUM> of a core network <NUM> through the access network <NUM>. Each traffic flow may include information of APN, and the information of APN is used to identify whether the traffic flow is originated from a mobile device or a machine device (i.e., IoT). Each traffic flow from APN mobile <NUM> or APN IoT <NUM> is transmitted to vPGW <NUM> via each GTP tunnel, established between access network <NUM> and core network <NUM>, according to a type (or characteristic) of the traffic flow. The GTP tunnels are initiated by the packet core and used in the packet core for delivering traffic (i.e., IP packets) between one entity (e.g., APN) and the other (e.g., vPGW <NUM>). A packet transmitted via GTP tunnel may be denoted as a GTP packet. Each GTP packet may include a Tunnel Endpoint Identifier (TEID) that identifies a particular GTP session. A GTP Session is a single session established between a user endpoint (e.g., a mobile device or an IoT device) and the packet core. That is, mobile traffic <NUM> is transmitted to vPGW <NUM> of core network <NUM> via GTP tunnel <NUM>'. The IoT traffic <NUM> is transmitted to vPGW <NUM> of core network <NUM> via GTP tunnel <NUM>'. When the vPGW <NUM> receives each traffic flow (e.g., the mobile flow <NUM> and the IoT flow <NUM>), vPGW <NUM> may steer all the traffic flows into a Generic Routing Encapsulation (GRE) tunnel to classifier <NUM> at an ingress of GiLAN <NUM>. In other words, vPGW <NUM> may know which packet belongs to the mobile traffic <NUM> or the IoT traffic <NUM>. However, when the GTP tunnel <NUM>' or <NUM>' is finished at vPGW <NUM>, information related to whether a type of the received traffic flow is mobile flow <NUM> or IoT flow <NUM> is lost. When vPGW <NUM> receives the GTP packet and the GTP tunnel <NUM>' or <NUM>' is terminated at vPGW <NUM>, vPGW <NUM> may establish the GRE tunnel <NUM> to send IP packets originated from the mobile device or the machine device (i.e., IoT device). The GRE tunnel <NUM> is a single tunnel commonly used for both the mobile traffic <NUM> and the IoT traffic <NUM> such that the GRE tunnel <NUM> is established to deliver the IP packets from the core network <NUM> to GiLAN <NUM> and is not used to deliver the information about the type of the IP packets. That is, the information related to whether a type of the received traffic flow is mobile flow <NUM> or IoT flow <NUM> is not sent by vPGW <NUM> through the GRE tunnel <NUM>. vPGW <NUM> may just perform functions for encapsulating IP packets, which are related to the traffic flow, in order to route the encapsulated IP packets to be sent from one network to another network. In view of GiLAN domain, GiLAN <NUM> is not able to identify if the IP packets themselves, received through the GRE tunnel, are a type of the mobile traffic <NUM> or the IoT traffic <NUM>. GiLAN <NUM> therefore needs a classifier <NUM> to classify that the IP packets come from the mobile traffic or the IoT traffic.

Further, when vPGW <NUM> receives the GTP packet, vPGW <NUM> may identify whether the IP packet comes from APN mobile <NUM> or APN IoT <NUM> based on the GTP TEID included in the GTP packet. vPGW <NUM> may send, to police and charging rules function (PCRF) <NUM>, accounting information of each traffic flow through authentication, authorization and accounting (AAA) proxy <NUM> via RADIUS protocol. Herein the accounting information may include information related to a specific device (e.g., the mobile device or the machine device) and IP characteristics of the IP packet (e.g., source IP, destination IP, ports, etc.). AAA proxy <NUM> may receive the accounting information of each traffic flow and forward it to PCRF <NUM>. AAA proxy <NUM> may further duplicate the accounting information and forward the duplicated accounting information to Light PCRF <NUM>. Light PCRF <NUM> may leverage the accounting information to configure rules on classifier <NUM> of GiLAN <NUM>. In view of GiLAN domain, classifier <NUM> of GiLAN <NUM> may receive the IP packet of all the traffic flow from vPGW <NUM> in an in-band manner, i.e., via GRE tunnel <NUM>, and receive the accounting information of each traffic flow from Light PCRF <NUM> in an out-of-band manner. As used herein, in-band may indicate a channel (or session) directly established between vPGW <NUM> of the core network and GiLAN130. Out-of-band may indicate another channel (or session) additionally established between another network entity (e.g., Light PCRF <NUM>) of the core network and GiLAN130. That is, in out-of-band manner, establishing another session is required to receive the accounting information beside in-band session directly established between vPGW <NUM> and GiLAN <NUM>.

Classifier <NUM> may identify whether the IP packet, which is received from vPGW <NUM> in the in-band manner, is mobile traffic or IoT traffic using the account information received from Light PCRF <NUM> in the out-of-band manner. Classifier <NUM> may steer each traffic flow (i.e., the mobile traffic or the IoT traffic) to be routed through a chain of network components. In <FIG>, firewall functions <NUM> and <NUM> are only presented as an example and for purpose of concise descriptions. The number of network components (or network functions) in GiLAN <NUM> is not limited to firewall functions <NUM> and <NUM> and may be scalable and configured as many as the network's operation and policy. When classifier <NUM> receives the accounting information of the mobile traffic flow from Light PCRF <NUM>, classifier <NUM> may identify which network slice is used for routing the IP packet, received via the GRE tunnel <NUM>, to network functions in GiLAN <NUM>. In <FIG>, the network slice may indicate, for example, VLAN <NUM>' for firewall mobile <NUM> and VLAN <NUM>' for firewall IoT <NUM>. That is, classifier <NUM> may classify if a type of the IP packet is mobile traffic or IoT traffic using the accounting information received from Light PCRF <NUM>. When the type of the IP packet is determined to be classified as mobile traffic, classifier <NUM> may steer (or forward) the IP packet into P router <NUM> of another network (i.e., a destination network) through a first route that comprises firewall mobile <NUM> of a first network slice via VLAN <NUM>'. Herein, the first route may be configured to be dedicated to delivering the mobile traffic. When the type of the IP packet is determined to be classified as the IoT traffic, classifier <NUM> may steer (or forward) the IP packet into P router <NUM> through a second route that comprises firewall IoT <NUM> of a second network slice via VLAN <NUM>'. Herein, the second route may be configured to be dedicated to delivering the IoT traffic.

In one embodiment presented in <FIG>, vPGW <NUM> may identify whether the traffic comes from a mobile traffic or IoT traffic using TEID. However, when vPGW <NUM> terminates the GTP tunnels <NUM>' and <NUM>', the information about the APN is lost and is not available at classifier <NUM>. When the IP packet sent from vPGW <NUM> arrives at GiLAN <NUM>, GiLAN <NUM> cannot use the information of the APN anymore. GiLAN <NUM> may then need to build a complex, non-scalable setup that requires hacks and also reclassify the traffic to be able to retrieve the information about a type of each traffic flow. Further, in the embodiment presented in <FIG>, classifier <NUM> cannot obtain the information about a type of the traffic flow in the in-band manner. Classifier <NUM> is required to establish another session to receive the information about a type of the traffic flow in the out-of-band manner with which AAA proxy <NUM> and Light PCRF <NUM> are associated. In other words, <FIG> requires network entities, i.e., AAA proxy <NUM>, Light PCRF <NUM> and classifier <NUM>, such that GiLAN <NUM> can perform network service functions for network slices that are assigned to each traffic flow (i.e., the mobile traffic or the IoT traffic) and steer the mobile traffic or the IoT traffic to predetermined network service functions. The particular embodiments of the present disclosure provide technical solutions to send the information about a type of the traffic in such an in-band manner that a core network domain (e.g., vPGW <NUM>) directly sends the information about a type of the traffic to GiLAN domain. In the in-band manner, the core network domain may encapsulate the IP packet with the information about a type of the traffic using a segment routing protocol (e.g., SRv6).

As used herein, Segment Routing (SR) allows a network node to steer a packet through a controlled set of instructions, called segments, by prepending an SR header to the packet. A segment can represent any instruction, topological or service-based. SR allows a network to enforce a flow through any path (topological or service/application based) while maintaining per-flow state only at the ingress node to the SR domain. Segments can be derived from different components: IGP, BGP, Services, Contexts, Locators, etc. The list of segments forming the path is called the Segment List and is encoded in the packet header. SR allows the use of strict and loose source-based routing paradigms without requiring any additional signaling protocols in the infrastructure, hence delivering excellent scalability properties.

As used herein Segment Routing includes using Internet Protocol version <NUM> (IPv6) addresses as Segment Identifiers (SIDs). In other words, as used herein, Segment Routing includes IPv6 Segment Routing (SRv6). As used herein, a Segment Routing node refers to a network node (e.g., router, server, appliance) that performs Segment Routing functionality, including, but not limited to, adding, updating, or removing a Segment Routing Header. The SR node performs a Segment Routing function identified by a Segment Identifier that is the IP Destination Address of an IP packet or is a Segment Identifier in a Segment Routing Header (SRH). Also, as used herein, an IP packet may or may not be a Segment Routing Packet; but a Segment Routing packet is an IP packet.

The term "SID" stands for a segment identifier, which represents a specific segment in a segment routing domain. The SID type used in this document is, for example, IPv6 address (e.g., also referenced as SRv6 Segment or SRv6 SID). A SID list is represented as <S1, S2, S3> where S1 is the first SID to visit, S2 is the second SID to visit and S3 is the last SID to visit along the SR path.

The term, "GPRS Tunneling Protocol (GTP)" is a group of IP-based communications protocols used to carry general packet radio service (GPRS) within, for example, GSM, UMTS and LTE networks. In 3GPP architectures, GTP and proxy mobile IPv6 based interfaces are specified on various interface points. The term "Generic Routing Encapsulation (GRE)", defined by RFC <NUM>, is a simple IP packet encapsulation protocol. A GRE tunnel is used when IP packets need to be sent from one network to another, without being parsed or treated like IP packets by any intervening routers. The term "flow" or "traffic flow" indicates a "packet flow," i.e., a sequence of packets from a source to a certain destination (e.g., it can be a unicast, multicast or broadcast destination, if the network protocol supports it) at a certain point in time. Also, the term "processing" when referring to processing of a packet process refers to a broad scope of operations performed in response to a packet, such as, but not limited to, forwarding/sending, dropping, manipulating/modifying/changing, receiving, duplicating, creating, applying one or more service or application functions to the packet or to the packet switching device (e.g., updating information), etc. Also, as used herein, the term processing in "parallel" is used in the general sense that at least a portion of two or more operations are performed overlapping in time.

As described herein, embodiments include various elements and limitations, with no one element or limitation contemplated as being a critical element or limitation. Each of the claims individually recites an aspect of the embodiment in its entirety. Moreover, some embodiments described may include, but are not limited to, inter alia, systems, networks, integrated circuit chips, embedded processors, ASICs, methods, and computer-readable media containing instructions. One or multiple systems, devices, components, etc., may comprise one or more embodiments, which may include some elements or limitations of a claim being performed by the same or different systems, devices, components, etc. A processing element may be a general processor, task-specific processor, a core of one or more processors, or other co-located, resource-sharing implementation for performing the corresponding processing. The embodiments described hereinafter embody various aspects and configurations, with the figures illustrating exemplary and non-limiting configurations. Computer-readable media and means for performing methods and processing block operations (e.g., a processor and memory or other apparatus configured to perform such operations) are disclosed and are in keeping with the extensible scope of the embodiments. The term "apparatus" is used consistently herein with its common definition of an appliance or device.

The steps, connections, and processing of signals and information illustrated in the figures, including, but not limited to, any block and flow diagrams and message sequence charts, may typically be performed in the same or in a different serial or parallel ordering and/or by different components and/or processes, threads, etc., and/or over different connections and be combined with other functions in other embodiments, unless this disables the embodiment or a sequence is explicitly or implicitly required (e.g., for a sequence of read the value, process said read value--the value must be obtained prior to processing it, although some of the associated processing may be performed prior to, concurrently with, and/or after the read operation). Also, nothing described or referenced in this document is admitted as prior art to this application unless explicitly so stated.

The term "one embodiment" is used herein to reference a particular embodiment, wherein each reference to "one embodiment" may refer to a different embodiment, and the use of the term repeatedly herein in describing associated features, elements and/or limitations does not establish a cumulative set of associated features, elements and/or limitations that each and every embodiment must include, although an embodiment typically may include all these features, elements and/or limitations. In addition, the terms "first," "second," etc., as well as "particular" and "specific" are typically used herein to denote different units (e.g., a first widget or operation, a second widget or operation, a particular widget or operation, a specific widget or operation). The use of these terms herein does not necessarily connote an ordering such as one unit, operation or event occurring or coming before another or another characterization, but rather provides a mechanism to distinguish between elements units. Moreover, the phrases "based on x" and "in response to x" are used to indicate a minimum set of items "x" from which something is derived or caused, wherein "x" is extensible and does not necessarily describe a complete list of items on which the operation is performed, etc. Additionally, the phrase "coupled to" is used to indicate some level of direct or indirect connection between two elements or devices, with the coupling device or devices modifying or not modifying the coupled signal or communicated information. Moreover, the term "or" is used herein to identify a selection of one or more, including all, of the conjunctive items. Additionally, the transitional term "comprising," which is synonymous with "including," "containing," or "characterized by," is inclusive or open-ended and does not exclude additional, unrecited elements or method steps. Finally, the term "particular machine," when recited in a method claim for performing steps, refers to a particular machine within the <NUM> USC § <NUM> machine statutory class.

<FIG> illustrates an example of a signal flow simplified for mobile traffic and IoT traffic using SRv6 in a mobile packet network. <FIG> illustrates a simplified block diagram for end-to-end mobile network architecture <NUM> that comprises access network <NUM>, core network <NUM>, GiLAN <NUM> and P router <NUM>. The end-to-end mobile network architecture <NUM> may be represented as several different domains. For one example, GiLAN <NUM> is a domain to perform service function chaining (SFC) and present a software defined network (SDN). For another example, a packet core may be another domain that represents vSGW (not shown in <FIG> for purpose of concise descriptions) and vPGW <NUM> of the core network <NUM>. A traffic flow (i.e., <NUM> or <NUM> in <FIG>) may be originated from a mobile device or a machine device through each APN (i.e., <NUM> or <NUM> in <FIG>). The example embodiment in <FIG> may leverage SRv6 to ensure that vPGW <NUM> steers the traffic (e.g., a sequence of packets for the mobile traffic or the IoT traffic) into the GiLAN <NUM> network slice.

<FIG> provides an embodiment where vPGW <NUM> directly steers the traffic from the access network <NUM> into the network slices GiLAN <NUM> by using a configuration of two SRv6 policies (P1 and P2). vPGW <NUM> may configure two different SRv6 policies for the mobile traffic and the IoT traffic. The SRv6 policies vPGW <NUM> may include one or more segment identifiers which indicate service network functions through which the mobile traffic and the IoT traffic are routed within GiLAN domain. Herein SRv6 segment indicates an IPv6 address. vPGW <NUM> may configure policy P1 for the mobile traffic flow and policy P2 for an IoT traffic flow. That is, P1 policy may be configured when a traffic flow comes from the mobile traffic. P2 policy is configured when a traffic flow comes from the IoT traffic. Policy P1 may be configured with a list of segment identifiers (e.g., SID-list <F_mobile, P>) of SRv6 segments. Referring to <FIG>, vPGW <NUM> may configure P1 with SID-list <F _mobile, P> to route the IP packet through firewall mobile <NUM> and P router <NUM>. SID-list <F _mobile, P> of P1 may indicate two segment identifiers (SIDs) of "F_mobile" and "P" where "F_mobile" SID indicates an IPv6 address of firewall <NUM> and "P" SID indicates an IPv6 address of P router <NUM>. vPGW <NUM> may configure P2 with SID-list <F_IoT, P> to route the IP packet through firewall IoT <NUM> and P router <NUM>. SID-list <F_IoT, P> of P2 may indicate two segment identifiers of "F_IoT" and "P" where "F_IoT" SID indicates an IPv6 address of firewall <NUM> and "P" SID indicates an IPv6 address of P router <NUM>. SID-list in <FIG> presents two segment identifiers for purpose of concise descriptions only; a skilled practitioner should appreciate that any number of segment identifiers may be used as needed. The number of segment identifiers is not limited to firewall functions <NUM> and <NUM> but may be scalable and configured as many as needed.

Referring to <FIG>, when vPGW <NUM> receives IP packet (i.e., GTP packet) via GTP tunnel <NUM>' or <NUM>', vPGW <NUM> may identify whether the IP packet comes from APN mobile <NUM> or APN IoT <NUM> based on GTP TEID included in the GTP packet. vPGW <NUM> may send, to police and charging rules function (PCRF) <NUM>, accounting information of each traffic flow via RADIUS protocol. Herein the accounting information may include information related to a specific device (e.g., the mobile device or the machine device) and IP characteristics of the IP packet (e.g., source IP, destination IP, ports, etc.). Depending on whether vPGW <NUM> identifies the IP packet (i.e., GTP packet) as being mobile traffic <NUM> or IoT traffic <NUM>, vPGW <NUM> may configure P1 for the mobile traffic <NUM> or P2 for the IoT traffic <NUM> using the accounting information of the traffic flow.

<FIG> illustrates an example of segment routing extension header (SRH). vPGW <NUM> may encapsulate the IP packet with SID-list of P1 or P2 into SRH. That is, SRH has all the SRv6 segments corresponding to P1's SID-list or P2's SID-list and encodes the segments in a SID list section. In particular embodiments, each SRv6 segment is associated with a single function (e.g., End. AN and End. D' in <FIG>). When a router (e.g., P router <NUM>) or a service network function (e.g., firewalls <NUM> and <NUM>) receives the IP packet with a particular SRv6 segment included in the SID-list of P1 or P2, the router or a service network function decapsulates the IP packet, identifies the corresponding function of each SRv6 segment, and executes instructions associated to the function. This function may be related to decapsulating the IP packet, doing a lookup in a particular virtual network function, forcing the IP packet to cross a specific link, or performing any other suitable function. In one embodiment, when vPGW <NUM> produces a SRv6 packet by encapsulating the IP packet with SRv6 segments, vPGW <NUM> may also produce metadata for the SRv6 packet and include the metadata in the SRv6 packet. The metadata may include the device's location (e.g., mobile device's location and machine device's location), PCRF policy information, link quality or 5GS slice so that the GiLAN <NUM> can leverage this information for packet processing.

<FIG> illustrates an example of a simplified interface protocol using SRv6 in a mobile packet network. In one embodiment, since vPGW <NUM> may generate SR policies P1 and P2 using the accounting information of the mobile traffic <NUM> and the IoT traffic <NUM>, vPGW <NUM> may have capability of visibility over active virtual network functions (VNFs) in GiLAN. Referring to <FIG> and <FIG>, when vPGW <NUM> identifies that the IP packet, received from access network <NUM>, is a type of the mobile traffic <NUM>, vPGW <NUM> may generate P1 policy and forward the IP packet to a virtual network function, i.e., firewall mobile <NUM> via N6 interface. The IP packet is steered to be routed to P router <NUM> through firewall mobile <NUM>, based on the generated P1 policy with SID-list <F _mobile, P>. When vPGW <NUM> identifies that the IP packet, received from access network <NUM>, is a type of the IoT traffic <NUM>, vPGW <NUM> may generate P2 policy and forward the IP packet to a virtual network function, i.e., firewall IoT <NUM> via N6 interface. The IP packet is steered be routed to P router <NUM> through firewall mobile <NUM>, based on the generated P2 policy with SID-list <F_IoT, P>. Herein firewall appliances <NUM> and <NUM> may be either SR-aware or accessed via an SRv6 proxy. When P router <NUM> receives the IP packet from firewall <NUM> or <NUM> according to P1 or P2 policy, P router <NUM> may decapsulate the IP packet and forward as appropriated. Both P1 and P2 policies may terminate on P router <NUM>, which is a destination of P1 and P2. In one embodiment of <FIG>, since vPGW <NUM> may be directly involved with producing or encapsulating information for a type of the traffic flows by including such information in the SRv6 encapsulation, the IP packet forwarded from vPGW <NUM> and GiLAN <NUM> may be self-descriptive. That is, vPGW <NUM> may send the information about a type of the traffic flows with the IP packet itself in an in-band manner, and GiLAN <NUM> does not use classifier <NUM> in <FIG> which needs to reclassify a type of the traffic flows based on the information received from Light PCRF <NUM> in an out-of-band manner.

<FIG> illustrates another example of a signal flow simplified for mobile traffic and IoT traffic using SRv6 in a mobile packet network. <FIG> illustrates another example of a simplified interface protocol using SRv6 in a mobile packet network. <FIG> provide mobile packet core mechanism for GiLAN <NUM> by using binding segment identifiers (BSIDs) and data center interconnect (DCI) router <NUM>. In <FIG>, vPGW <NUM> does not have capability of visibility over active virtual network functions (VNFs) in the GiLAN <NUM>, and DCI router <NUM> may expand each BSID into SR policy. That is, GiLAN domain may steer the IP packet to be routed into actual VNFs by producing or updating segment identifiers for each traffic flow. Descriptions related to access network <NUM> and core network domain in <FIG> are commonly applicable to <FIG>, and therefore incorporated herein to corresponding descriptions to <FIG>. Details descriptions are disclosed hereinafter.

Referring to <FIG> and <FIG>, when vPGW <NUM> receive IP packet (i.e., GTP packet) via GTP tunnel <NUM>' or <NUM>', vPGW <NUM> may identify whether the IP packet comes from APN mobile <NUM> or APN IoT <NUM> based on GTP TEID included in the GTP packet. vPGW <NUM> may send, to PCRF <NUM>, accounting information of each traffic flow via RADIUS protocol. The accounting information may include information related to a specific device (e.g., the mobile device or the machine device) and IP characteristics of the IP packet (e.g., source IP, destination IP, ports, etc.). When vPGW <NUM> identifies if the IP packet (i.e., GTP packet) is a type of the mobile traffic <NUM> or the IoT traffic <NUM>, vPGW <NUM> may configure P1 and P2 policies using binding SID (BSID). Herein P1 policy is generated with SID-list <BSID _mobile, P> for the mobile traffic <NUM> and P2 is generated SID-list with <BSID _IoT, P> for the IoT traffic <NUM> using the accounting information of each traffic flow. vPGW <NUM> may encapsulate the IP packet with SID-list of P1 or P2 into segment routing extension header (SRH). In particular, vPGW <NUM> may generate P1 and P2 policies using BSID. That is, BSID is added in each SID-list of P1 and P2. BSID is a type of an SRv6 segment. vPGW <NUM> may associate BSID to segment identifiers list (i.e., SID-list). For one example, vPGW <NUM> may generate P1 policy with BSID where BSID is associated (or binding) with virtual network functions of firewall mobile <NUM> and P router <NUM>. For another example, vPGW <NUM> may generate P2 policy with BSID where BSID is associated (or binding) with virtual network functions of firewall IoT <NUM> and P router <NUM>.

The SRH imposed at vPGW <NUM> contains a SID for P router <NUM> included in the SID-list. DCI router <NUM> may push each SID-list that steers the IP packet through a required sequence of service functions or VNFs: <F_mobile> or <F_IoT> where <F_mobile> is associated with "BSID_mobile" and <F_IoT> is associated with "BSID_IoT. " DCI router <NUM> firstly reads an active segment in SID-list and then decides an action to be performed on the IP packet based on the active segment and DCI router's own configuration. For example, the action performed by DCI router <NUM> may be to: (<NUM>) modify a current encapsulation of the IP packet; (<NUM>) add another encapsulation on top of existing encapsulation of the IP packet; or (<NUM>) remove the current encapsulation and process an inner payload of the IP packet; or any combinations of (<NUM>), (<NUM>) and (<NUM>). When vPGW <NUM> identifies that the IP packet, received from access network <NUM>, is a type of the mobile traffic <NUM>, vPGW <NUM> may generate P1 policy with SID-list <BSID _mobile, P> and forward the IP packet to DCI router <NUM> of GiLAN domain via N6 interface (see <NUM> SRv6 in <FIG>). DCI router <NUM> may inspect the IP packet, forwarded from vPGW <NUM>, and then identify BSID included in P1 policy. DCI router <NUM> may process a first SID, "BSID _mobile" such that a new SID-list, "<F_mobile>" associated to "BSID _mobile" is written in the IP packet on top of the SRH as in a separate SRH. This operation effectively pauses an original SID-list (e.g., <BSID_mobile, P>) and a new SID-list (e.g., <F_mobile>) starts being processed. DCI router <NUM> may steer the IP packet to be routed into P router <NUM> through firewall mobile <NUM> (see <NUM>' SRv6 in <FIG>). In another embodiment, when vPGW <NUM> identifies that the IP packet, received from access network <NUM>, is a type of IoT traffic <NUM>, vPGW <NUM> may generate P2 policy with SID-list <BSID_IoT, P> and forward the IP packet to DCI router <NUM> of GiLAN domain via N6 interface (see <NUM> SRv6 in <FIG>). DCI router <NUM> may inspect the IP packet, forwarded from vPGW <NUM>, and then identify BSID included in P2 policy. DCI router <NUM> may process a first SID, "BSID _IoT" such that a new SID-list, "<F_IoT>" associated to "BSID_IoT" is written in the IP packet on top of the SRH as in a separate SRH. This operation effectively pauses an original SID-list (e.g., <BSID_IoT, P>) and a new SID-list (e.g., <F_IoT>) starts being processed. DCI router <NUM> may steer the IP packet to be routed into P router <NUM> through firewall IoT <NUM> (see <NUM>' SRv6 in <FIG>). As such, in one embodiment of <FIG>, DCI router <NUM> may expand each BSID into the SR policies of P1 and P2. This means that the SR policies are not produced in a core network domain but GiLAN domain may be involved with updating or configuring the SR policies by using BSID.

<FIG> illustrates an example of a signal flow chart of mobile packet core mechanism for GiLAN network slice with segment routing. <FIG> is reproduced in view of <FIG> and <FIG> and presents the technical features of the mobile packet core mechanism that vPGW <NUM> and DCI router 231perform SR policies in an in-band manner. In one embodiment, vPGW <NUM> may receive IP packet (i.e., GTP packet) from APN mobile <NUM> or APN IoT <NUM> via a GTP tunnel (Step <NUM>). A type of the IP packet may be the mobile traffic <NUM> or the IoT traffic <NUM>. vPGW <NUM> may classify a type of the traffic type for the IP packet based on the account information and determine that the IP packet is classified as the mobile traffic or the IoT traffic (Step <NUM>). vPGW <NUM> may generate SR policies based on the classification of the IP packet. vPGW <NUM> may configure SID-list of SR policies for the IP packet to steer the IP packet to be routed through one or more virtual network functions (VNFs) within GiLAN domain (Step <NUM>). The SID-list of SR policies may be differently configured depending on whether the IP packet is a type of the mobile traffic or the IoT traffic. vPGW <NUM> may encapsulate SR policies into SRH with the IP packet (Step <NUM>) and send the encapsulated IP packet to network slices within GiLAN domain (Step <NUM>). In another embodiment, DCI router <NUM> may be deployed in GiLAN <NUM> and steer the IP packet to be routed through VNFs within GiLAN domain. When vPGW <NUM> preconfigures SR policies and sends the IP packet encapsulated with the SR polices including binding SID (BSID), DCI router <NUM> may inspect BSID from the IP packet received from vPGW <NUM>, and configure or update SR policies (Step <NUM>). DCI router <NUM> may steer the IP packet to be routed through VNFs as configured in SID-list of the configured or updated SR policies (Step <NUM>).

<FIG> illustrates an example of a simplified flow chart of mobile packet core mechanism for GiLAN network slice with segment routing. The method may be performed by a network apparatus (e.g., vPGW <NUM> in <FIG>, <FIG> and <FIG>) of a first domain network (e.g., a core network <NUM> in <FIG> and <FIG>). In one embodiment, the network apparatus may receive one or more packets from an access network, at step <NUM>. Herein the packets include accounting information of the packets. At step <NUM>, the network apparatus may determine a classification for the packets based on the accounting information. At step <NUM>, the network apparatus may determine that the packets are processed with a first policy configuration (e.g., P1 SR policy) or a second policy configuration (e.g., P1 SR policy) based on the determined classification. That is, the policy configuration may be determined based on whether a type of the packets is a mobile traffic or an IoT traffic. At step <NUM>, the network apparatus may encapsulate the packets with a first identifier (e.g., SID-list of P1 policy) of the first policy configuration or a second identifier (e.g., SID-list of P2 policy) of the second policy configuration based on the determining. At step <NUM>, the network apparatus may send the encapsulated packets to a first network slice or a second network slice included in a second domain network (e.g., GiLAN network domain in <FIG> and <FIG>).

In particular embodiments, a network apparatus comprising one or more processors may include hardware, software, or both for identifying, classifying the IP packet, and communicating with access network and GiLAN. As an example and not by way of limitation, the network apparatus may include communication interface including, for example, a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network. This disclosure contemplates any suitable network and any suitable communication interface for it. As an example and not by way of limitation, a mobile network system including the network apparatus may communicate with an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. As an example, the mobile network system may communicate with a wireless PAN (WPAN) (such as, for example, a BLUETOOTH WPAN), a WI-FI network, a WI-MAX network, a cellular telephone network (such as, for example, a Global System for Mobile Communications (GSM) network, a Long-Term Evolution (LTE) network, or a <NUM> network), or other suitable wireless network or a combination of two or more of these. The mobile network system may include any suitable communication interface for any of these networks, where appropriate. The communication interface may include one or more communication interfaces, where appropriate. Although this disclosure describes and illustrates a particular communication interface, this disclosure contemplates any suitable communication interface.

Claim 1:
A method comprising, by a network apparatus of a first domain network:
receiving (<NUM>) one or more packets from an access network, wherein the packets include accounting information of the packets;
determining (<NUM>) a classification for the packets based on the accounting information by classifying whether the packets originated from a mobile device or an IoT, Internet of thing, device;
selecting (<NUM>), based on the determined classification, a policy configuration from a plurality of policy configurations for processing the packets;
encapsulating (<NUM>) the packets with one or more segment identifiers in accordance with the selected policy configuration; and
sending (<NUM>) the encapsulated packets to a network slice in a second domain network based on the one or more segment identifiers.