WO2016055097A1

WO2016055097A1 - Service chaining in communications

Info

Publication number: WO2016055097A1
Application number: PCT/EP2014/071433
Authority: WO
Inventors: Jani Olavi SODERLUND
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2014-10-07
Filing date: 2014-10-07
Publication date: 2016-04-14

Abstract

A method is disclosed, comprising determining, in a network node, at least one default flow handling rule for a subscriber such that programming of subscriber-specific packet flows to a software defined network layer is avoided. If needed, the network node determines at least one specific flow handling rule such that the at least one specific flow handling rule is specific to one or more of an access point name, the subscriber, a bearer of the subscriber, and a packet flow in the bearer of the subscriber.

Description

SERVICE CHAINING IN COMMUNICATIONS

TECHNICAL FIELD

The invention relates to communications.

BACKGROUND

Network functions virtualization (NFV) is a design approach for building complex applications e.g. in the

telecommunications and service provider industries. NFV virtualizes network functions into building blocks that may be connected, i.e. chained together to create services. A virtualized network function (VNF) , may comprise one or more virtual machines (VM) running various software and processes. The same virtualized platform that supports provisioning machines into VNFs, may also support programming virtualized network devices and flows to support VNFs. The programming of virtualized network devices and flows to support VNFs is the domain of a software defined network (SDN) .

BRIEF DESCRIPTION

According to an aspect, there is provided the subject matter of the independent claims. Embodiments are defined in the dependent claims.

One or more examples of implementations are set forth in more detail in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF DRAWINGS

In the following, the invention will be described in greater detail by means of preferred embodiments with reference to the accompanying drawings, in which

Figure 1 illustrates a wireless communication system to which embodiments of the invention may be applied; Figure 2 illustrates a 3^r generation partnership project (3GPP) network;

Figure 3 illustrates service chaining in an operator network;

Figure 4 illustrates network functions virtualization (NFV) architecture;

Figure 5 illustrates IP pools and subnets in a PDN gateway (PGW) ;

Figure 6 is a signalling diagram of a procedure for service chain setup according to an embodiment of the invention; Figure 7 is a signalling diagram of a procedure for service chain setup according to an embodiment of the invention;

Figure 8 illustrates exemplary flow entries in a software defined network (SDN) switch according to an embodiment of the invention; Figures 9, 10, 11 and 12 illustrate processes for service chain setup according to some embodiments of the invention;

Figures 13 and 14 illustrate blocks diagrams of apparatuses according to some embodiments of the invention.

DETAILED DESCRIPTION OF SOME EMBODIMENTS

The following embodiments are exemplary. Although the

specification may refer to "an", "one", or "some"

embodiment ( s ) in several locations, this does not necessarily mean that each such reference is to the same embodiment ( s ) , or that the feature only applies to a single embodiment.

Single features of different embodiments may also be combined to provide other embodiments. Furthermore, words "comprising" and "including" should be understood as not limiting the described embodiments to consist of only those features that have been mentioned and such embodiments may contain also features/structures that have not been specifically

mentioned .

Figure 1 illustrates a wireless communication scenario to which embodiments of the invention may be applied. Referring to Figure 1, a cellular communication system may comprise a radio access network comprising base stations disposed to provide radio coverage in a determined geographical area. The base stations may comprise macro cell base stations (eNB) 102 arranged to provide terminal devices (UE) 106 with the radio coverage over a relatively large area spanning even over several square miles, for example. In densely populated hotspots where improved capacity is required, small area cell base stations (eNB) 100 may be deployed to provide terminal devices (UE) 104 with high data rate services. Such small area cell base stations may be called micro cell base

stations, pico cell base stations, or femto cell base

stations. The small area cell base stations typically have significantly smaller coverage area than the macro base stations 102. The cellular communication system may operate according to specifications of the 3^rd generation partnership project (3GPP) long-term evolution (LTE) advanced or its evolution version.

In a mobile network, the user sessions are established as tunnels between mobile terminals (MT) and gateways (GW) . Due to a cellular network architecture, the gateways are

aggregation points for the user sessions, providing an anchor towards services in the internet or operator service network. In a 3G system, the gateway is a GGSN element, and in an LTE system, the gateway is a SAE-GW element (see Figure 2) .

The number of gateway elements in an operator network may vary depending on the subscriber base of the operator, redundancy requirements, site strategy, and/or gateway element capacity, for example. The networks are turning towards higher aggregation capabilities, so fewer elements are expected to remain in the network. The user sessions are distributed across the gateway elements. Several operators may provide services behind the mobile gateway at a Gi/SGi interface, forming a "service chain" for user plane traffic. Services in the service chain may include (but are not limited to) e.g. deep packet inspection (DPI), content optimization, parental control, firewall (FW) and various forms of network address translation (NAT) . These services may be implemented as integrated services within the gateway (i.e. a service chain inside one product), or by using separate network elements for each service and using L2/L3 (switching and routing) traffic steering capabilities to direct the traffic to relevant services. Any change to this connectivity requires manual re-configuration of the network. An example of a service chain in an existing operator network is illustrated in Figure 3, illustrating two different paths. In Figure 3, DPI and FW services may be provided by the same elements with separately addressable service instances. Network functions virtualization (NFV) enables dynamic creating of service chains, allowing runtime selection of value-added services which certain packets go through. NFV architecture is illustrated in Figure 4, illustrating a conceptual end-to-end service forwarding graph. A fully dynamic service chain allows customers to go to an operator portal page and freely select what kind of services they want to subscribe to (e.g. parental control, specific advertising, video optimization) . When a subscriber attaches to the network, PGW (PDN-GW, packet data network gateway) as a starting point of the service chain may program switches directly or via a separate SDN controller function, so that packet flows follow a correct "forwarding graph". Service chaining is often discussed in conjunction with

virtualization and cloud technologies. However, the service chaining is an independent initiative which is going to be part of the future mobile networks. The NFV approach is mainly targeting applications running in the same cloud environment, as OpenFlow-based SDN (software defined network) systems are not yet able to expand beyond their own data centres. Standard routing may still be used between the clouds and especially in inter-domain connectivity. Flexible service chaining use cases may be realized by using SDN principles and a de-facto standard OpenFlow protocol.

OpenFlow is able to use 12-tuple information from packets in a flow for classification purposes. In the LTE networks, a PGW element controls IP address assignment to a user equipment, holds subscriber/subscription information

(received e.g. from PCRF via Gx, or from OCS via Gy) , and acts as a policy enforcement function (PCEF) . When the subscriber attaches to the network, PGW gives the subscriber an IP address by using one of the methods configured. In case of plain internet access, the IP address is mostly given based on preconfigured IP pools per APN (see Figure 5

illustrating the IP pools and subnets in PGW) . PGW receives access point information in a session creation request from MME .

PGW may implement flow tracking in an IP level in order to enable value-added services, such as header enrichment or traffic (flow) redirection, inside PGW based on packet information or subscriber information. For example, an existing PGW element may accommodate up to 12 million subscribers, and with the emergence of M2M

communications, the amount of "subscribers" with very little actual traffic increases. Also in cloud deployments the target is significantly higher. Managing the flows

efficiently in an SDN layer both in the controller and switches (there may be tens or even hundreds of switches in big data centres) is challenging, even if it is done at a subscriber level (by identifying the subscribers by means of IP addresses) instead of a flow level. Especially as in the mobile networks majority of the flows tend to be very short^¬ lived (basic HTTP transactions for web browsing or

polling/pushing updates by social media applications) , it is not efficient to program each of these to the switches individually per subscriber. Still, this is necessary in order to enable the fully dynamic service chaining based on the subscriptions.

In the existing systems, the service chaining is implemented by using the services inside the gateway (e.g. DPI, firewall, NAT) , or separate network elements are deployed between the gateway and the internet (on an SGi interface) . Also when the goal of service chaining is to have a method for directing traffic inside the operator network (e.g. to easily introduce new services) , but still have all the traffic going through this chain, then the existing methods based on VLANs or L3/L4 packet inspection (IP addresses, ports) with the aggregation on the IP pools (subnets) controlled by PGW already provide enough aggregation for SDN. There are a lot of commercial and open source SDN controllers already available. Route

aggregation in the existing solutions (L3 networks and standard routing protocols like OSPF or BGP) is an

established way of working, and an application/traffic type aware path definition is based on the standard 12-tuple available in the flow itself.

A service flow router control function has been suggested which instructs user switching plane for appropriate routing, exactly suggesting how to implement subscriber specific service chaining and to introduce the control function. This involves a possibility to do passive aggregation by selecting source/destination addresses etc. accordingly, but is very dependent on the operator's IP planning. Another service chain has been suggested which is built by extracting

relevant information out of the session packets, but that merely concentrates on the service level flow and policy information and control.

In a fully dynamic service chaining scenario, targeted by the NFV initiative, the control for the service chaining is at least on subscriber level. This means that whenever a

subscriber attaches to the mobile network and gets an IP address assigned by PGW (or GGSN in 2G/3G networks) , the SDN layer is to be programmed according to subscription

information that PGW has (e.g. from PCRF) . From a PGW or SDN controller capacity requirements point of view this may be acceptable given the fact that in LTE networks subscribers are mostly always-on (i.e. every time they are attached to the network) , and therefore the performance of programming the flows from PGW via the SDN controller to the SDN switches is not an issue (except, for example, system start-up with large amount of incoming sessions in parallel) . In case of flow level service chaining (e.g. only video traffic flows are to be sent to an optimization service, not each packet for a certain subscriber) also the performance of the SDN controller and the SDN switches becomes an issue.

Furthermore, in the SDN switch layer it results to millions of flow entries in flow tables, mostly with similar entries. In standard routing, the default routes are a kind of generalization of the longest prefix match algorithm. The default routes are manually created to the system by domain operators; the system (routing control plane) is not able to figure those out by itself.

Let us now describe an embodiment of the invention for service chaining in the SDN layer with reference to Figure 6 and Figure 7. Figures 6 and 7 illustrate signalling diagrams illustrating a method for communicating service chaining parameters between network elements of the cellular

communication system. The network element may be a network node, an access node, a base station, a terminal device, a server computer or a host computer. For example, the server computer or the host computer may generate a virtual network through which the host computer communicates with the

terminal device. In general, virtual networking may involve a process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network. In another

embodiment, the network node may be a terminal device.

Network virtualization may involve platform virtualization, often combined with resource virtualization. Network

virtualization may be categorized as external virtual networking which combines many networks, or parts of

networks, into the server computer or the host computer.

External network virtualization is targeted to optimized network sharing. Another category is internal virtual networking which provides network-like functionality to the software containers on a single system. Virtual networking may also be used for testing the terminal device. Referring to Figure 6, in step 602, static SDN layer

configuration information is provided by a network node such as a PDN gateway PGW to a service chain control function SCCF (SCCF may be e.g. a logical entity connected to PGW or integrated in PGW) . This may be carried out e.g. responsive to PGW initialization (PGW start-up or system start-up) or APN activation (block 601) . The static SDN layer

configuration information is based on system configuration and/or information received (by PGW) from external systems. Based on the static SDN layer configuration information, at least one default flow handling rule is determined for a subscriber such that programming of subscriber-specific packet flows to a software defined network layer is avoided. The determining of the default rule may be carried out in PGW (block 601), or in SCCF (block 603, "decision logic 1") . If the default rules are determined in PGW, information on the determined default flow handling rule is provided by PGW to SCCF in step 602. SCCF instructs (steps 604, 606, 608) the SDN controllers to create new service chains (e.g. service chains 1, 2, N) . The default flow handling rules are to be added to the appropriate forwarding table (s) in the SDN switches. Thus the SDN controller programs flow entries per IP pools to the SDN switches along the desired service chains (steps 605, 607, 609) (or installs the default rules to the SDN switches) .

Referring to Figure 7, in step 701, an attach message may be transmitted from the terminal device to PGW (e.g. via eNB and MME) . PGW informs SCCF on the new subscriber to be attached (step 702) . Responsive to step 702, if needed (e.g. based on system runtime information) , at least one specific flow handling rule is determined such that the at least one specific flow handling rule is specific to one or more of an access point name, the subscriber, a bearer of the

subscriber, and a packet flow in the bearer of the

subscriber. The determining of the specific flow handling rule may be carried out in PGW, or in SCCF (block 703,

"decision logic 2 " ) . If the specific rules are determined in PGW, information on the determined specific flow handling rule is provided PGW to SCCF in step 702. SCCF instructs (step 704) the SDN controller to create a new service chain. The specific flow handling rules are to be added to the appropriate forwarding table (s) in the SDN switches. Thus the SDN controller programs the flow entries per IP pools to the SDN switch along the desired service chain (step 705) (or installs the specific rules to the SDN switch) . In step 706, PGW transmits an attach response message to the terminal device (e.g. via MME and eNB) .

The terminal device may transmit user plane traffic (e.g. via eNB) to PGW (step 707) . In block 708, PGW analyses the received user plane traffic, and sets the egress port for appropriate packets (packets that need specific flow

handling) to point to the interface leading towards the required service in the service chain, e.g. a deep packet inspection service, content optimization service, parental control service, firewall service, network address

translation service, and/or some other operator service for the user plane traffic. PGW provides SCCF with information on the subscriber and traffic information (step 709). Responsive to step 709, based on additional metadata from PGW regarding the packet flow, one or more additional flow handling rules may be determined such that a packet flow is to be conveyed from a first service to a second service on a data path. The determining of the additional flow handling rule(s) may be carried out in PGW, or in SCCF (block 710, "decision logic 3") . If the additional rules are determined in PGW,

information on the determined additional flow handling rule is provided by PGW to SCCF in step 709. SCCF instructs (step 711) the SDN controller to create a new service chain. The additional flow handling rules are to be added to the

appropriate forwarding table (s) in the SDN switches. Thus the SDN controller programs the flow entries per IP pools to the SDN switch along the desired service chain (step 712) (or installs the additional rule(s) to the SDN switch) . In step 713, PGW forwards the user plane traffic to the SDN switches. In an embodiment, the system (PGW) determines the default rules according to the configuration, and the system (PGW) determines, if needed, more specific (dynamic) rules (based e.g. on traffic type, APN, subscriber, bearer of subscriber, and/or flow in a bearer of a subscriber) . The PGW element (SCCF function) provides default flow handling for the subscribers via any (integrated or external) SDN controller used in the operator data centre. The default flow handling enables avoiding the programming of any subscriber-specific flows to the SDN layer, if it is avoidable by already having a default flow in its place acting as an aggregate flow classifier .

In an embodiment, PGW/SCCF has the required information on the subscribers (e.g. their IP addresses or other appropriate information, and the services they have subscribed to) .

PGW/SCCF instructs the SDN control-plane ( s ) to configure SDN forwarding plane (s) via OpenFlow or a similar SDN control protocol. The forwarding table (s) is (are) populated with appropriate default rules during system start up as indicated by the system configuration and/or as received from external systems. The forwarding table (s) may be populated with appropriate aggregate rules as required based on the runtime information (when the same rule is applicable for many subscribers) . The forwarding table (s) may be populated with appropriate subscriber-specific rules as required based on the runtime information (e.g. PCC rules from PCRF and

detecting a certain traffic type) . The subscriber-specific rules and the aggregate rules are removed from the forwarding table (s) when no longer needed. In an embodiment, during the initialization phase, PGW (or a specific service chain control function (SCCF) that may be integrated within PGW) may instruct the SDN controller to first install so-called default rules to each SDN switch along desired service chain paths through these switches. These rules may also be further restricted to certain flows by adding any information available in the OpenFlow 12-tuple. In the PGW case the flows per IP pools may be identified, i.e. it may be possible to have separate default rules per IP pools (which are usually assigned per APN) . These flows are programmed to each SDN switch, and these flows serve as a primary data path for the packets requiring similar treatment in the same service chain. The default rule is the last one to be matched against in the switches, so this is ensured by the SDN controller. Dynamic changes introduced by VNF in the service chain are allowed. The SDN controller and the

switches do not have any logic related to a particular use case; the SDN controller and the switches remain generic in order to allow their usage in various use cases and

environments .

In an embodiment, the decision logic 1 (see Figure 6) is based on analysing APN and service information available in PGW itself. An assumption is that these chains are valid for most of the end user packet flows. During PGW start-up or APN1 (as described below) activation, PGW may program the switches such that each packet for each subscriber goes via a DPI service every time:

Vlan ID = <vlan used for PGW connectivity>

IP Src = <IP subnet assigned to APN1 (configured often in the PGW itself)

Based on the above logic, the egress port is then set

accordingly for the matching packets to point to the

interface leading towards DPI service. For a subscriber that has opted for additional service, PGW may additionally program the switches so that each HTTP packet for this subscriber only go via the optimization service every time.

Vlan ID = <vlan used for PGW connectivity> IP Src = <IP subnet assigned to APN1 (configured often in the PGW itself)

TCP port = 80

Based on the above logic, the egress port is then set

accordingly for the matching packets to point to the

interface leading towards the optimization service. The egress port may also be a tunnel interface. Each of the other packets is still conveyed via the default path. OpenFlow supports rule priority setting, so PGW/SCCF ensures that the default rule has the lowest priority. If PGW/SCCF is in full control of each forwarding graph, not only for the path between PGW and the first service, the latter rule is to be followed by an additional rule which then catches the packet from the optimization service and forwards that to the next service in the path. Actions assigned to these flows for a matching packet are then redirected towards the next service in the chain, e.g. via the outgoing port (without modifying the packet) . In an embodiment, when the subscriber requires more specific service chaining, PGW/SCCF instructs the SDN controller to install more specific rule(s) to the SDN switch (es) . These rules take precedence over the default rule by whatever means the service chaining technology allows; with OpenFlow-based chaining this may be achieved by specific rules appearing before the default rule in the flow table matching in the SDN switches, as the flow tables are ordered by the precedence. The decision logic 2 (see Figure 7 illustrating SDN layer configuration during system runtime) includes business logic for deciding whether the default rules are enough for this subscriber, or whether it is already known based on

subscription information (e.g. from PCRF during the attach operation itself) that some other service chain needs to be established (Figure 7 illustrates this latter case) . SCCF knows each chain it has established so it is able to do this decision autonomously without interaction with PGW or the SDN controller .

In an embodiment, the decision logic 3 (see Figure 7) is in principle the same as the decision logic 2, but in decision logic 3, SCCF makes the decision based on further metadata regarding the specific packet flow based on an input from PGW. The actual user packet is not transferred to SCCF. This phase may be fully optional depending on the complexity of the required service chaining in the operator's network. For example, only flows identified by PGW to contain video traffic may be sent for the optimization service, while each of the other flows may use the subscriber level service chain or even the default service chain.

In an embodiment, if the service chaining is implemented with OpenFlow, the rule entries in SDN switches may naturally include any of the available 12-tuple information, but in the PGW case the information is mainly the IP addresses. If the PGW includes an integrated SPI or DPI function, this is also very valuable information and helps to set up even more specific aggregation chains per service (shallow packet inspection (SPI) operates at layer-4 or below; deep packet inspection (DPI) operates at layers above 4) . Figure 8 shows exemplary flow entries in the (SDN) switches.

In an embodiment, if the service chaining is implemented by some other technology, the principle as described in Figure 6/Figure7 remains the same, but implementation is adapted to the possibilities offered by the technology. For example, MPLS L3 VPNs (such as OpenContrail ) may implement this by separate label switched paths (LSP) , and BGP systems (such as Calico) may use normal routing capabilities.

In an embodiment, the interface between PGW and SCCF may be based on proprietary solutions. The interface between SCCF and the SDN controller may be a standard interface. PGW, SCCF and/or the SDN controller may be integrated, or PGW, SCCF and/or the SDN controller may be separate entities. In an embodiment, the number of the flow entries is limited to a fragment of the initial situation of per-subscriber flow information. This allows the switches to be simpler with less memory and thus leads to CAPEX savings. Thus, in an embodiment, mechanisms for controlling the aggregation and creation of default flows are provided. This relates to a situation where there already is an element (such as PGW) in the mobile network with the necessary information for driving the optimization. Having a default rule and then having more specific rules on a need basis, enable providing a flexible concept. The PGW controlled subscriber flow control mechanism for performance-optimized service chaining enables protecting a specific initialization of the switching plane with default flow entries for load reduction, the switching plane being a part of the SDN infrastructure within a mobile operator's service network. Necessary information for appropriate configuring of the default flow entries in the switching plane may be extracted from the PGW. Let us now describe some embodiments with reference to

Figures 9, 10, 11 and 12. Figures 9 and 10 illustrate an embodiment for initial SDN layer configuration. Referring to Figure 9, in block 901, static SDN layer configuration information is obtained in a network node (such as PGW, SCCF and/or SDN controller) . The static SDN layer configuration information may be based on system configuration and/or information received from external systems. Based on the static SDN layer configuration information, at least one default flow handling rule is determined for a subscriber such that programming of subscriber-specific packet flows to a software defined network layer is avoided (block 902) . In block 903, new service chains (e.g. service chains 1, 2, N) are created based on the at least one default flow

handling rule. The default flow handling rules are to be added to the appropriate forwarding table (s) in the SDN switches. Thus flow entries per IP pools are programmed to the SDN switches along the desired service chains (or the default rules are installed to the SDN switches) (block 903) .

Referring to Figure 10, in block 101, information on at least one default flow handling rule for a subscriber is obtained in a network node (such as SDN switch) , such that programming of subscriber-specific packet flows to a software defined network layer is avoided. The network node adds (installs) the at least one default flow handling rule to an appropriate forwarding table (block 101) . Figures 11 and 12 illustrate an embodiment for SDN layer configuration during system runtime. Referring to Figure 11, in block 111, an attach message is obtained in a network node from the terminal device (e.g. via eNB and MME) . If needed (e.g. based on system runtime information), at least one specific flow handling rule may be determined (block 112) such that the at least one specific flow handling rule is specific to one or more of an access point name, the

subscriber, a bearer of the subscriber, and a packet flow in the bearer of the subscriber. In block 113, a new service chain is created based on the specific flow handling rule. The specific flow handling rules are to be added to the appropriate forwarding table (s) in the SDN switches. Thus flow entries per IP pools are programmed to the SDN switch along the desired service chain (or the specific rules are installed to the SDN switch) . In block 114, an attach

response message is transmitted to the terminal device (e.g. via MME and eNB) .

The terminal device may transmit user plane traffic (e.g. via eNB and MME) . In block 115, the network node receives the user plane traffic and analyses it, and sets the egress port for appropriate packets (packets that need specific flow handling) to point to the interface leading towards the required service in the service chain, e.g. a deep packet inspection service, content optimization service, parental control service, firewall service, network address

translation service, and/or some other operator service for the user plane traffic. In block 116, (e.g. based on

additional metadata regarding the packet flow) at least one additional flow handling rule may be determined such that a packet flow is to be conveyed from a first service to a second service on a data path. In block 117, a new service chain is created based on the additional flow handling rule. The additional flow handling rules are to be added to the appropriate forwarding table (s) in the SDN switches. Thus flow entries per IP pools are programmed to the SDN switch along the desired service chain (or the additional rules installed to the SDN switch) . In block 118, the user plane traffic is forwarded to the SDN switches.

Referring to Figure 12, in block 121, information on the at least one specific flow handling rule for the subscriber is obtained in a network node (such as SDN switch) . The network node adds (installs) the at least one specific flow handling rule to an appropriate forwarding table (block 121) . In block 122, information on the at least one additional flow handling rule for the subscriber is obtained in the network node. The network node adds (installs) the at least one additional flow handling rule to an appropriate forwarding table (block 122) . In block 123, the user plane traffic is received in the network node.

An embodiment provides an apparatus comprising at least one processor and at least one memory including a computer program code, wherein the at least one memory and the

computer program code are configured, with the at least one processor, to cause the apparatus to carry out the procedures of the above-described network element or the network node. The at least one processor, the at least one memory, and the computer program code may thus be considered as an embodiment of means for executing the above-described procedures of the network element or the network node. Figure 13 illustrates a block diagram of a structure of such an apparatus. The apparatus may be comprised the network element or in the network node, e.g. the apparatus may form a chipset or a circuitry the network element or in the network node. In some embodiments, the apparatus is the network element or the network node. The apparatus comprises a processing circuitry 10 comprising the at least one processor. The processing circuitry 10 may comprise a default rule determination circuitry 16 configured to determine at least one default flow handling rule for a subscriber such that programming of subscriber-specific packet flows to a software defined network layer is avoided. The default rule determination circuitry 16 may be configured to determine the at least one default flow handling rule, as described above, and output the at least one default flow handling rule to a service chain generator 12. The apparatus may further comprise a specific rule determination circuitry 18 configured to determine, if needed, at least one specific flow handling rule such that the at least one specific flow handling rule is specific to one or more of an access point name, the subscriber, a bearer of the subscriber, and a packet flow in the bearer of the subscriber. The specific rule determination circuitry 18 may output to the service chain generator 12 information on the determined at least one specific flow handling rule, and the service chain generator 12 may create a service chain based on the (default and/or specific) flow handling rule, the service chain identifying which packet flows for which subscribers are to be conveyed via the service chain.

The processing circuitry 10 may comprise the circuitries 12 to 18 as sub-circuitries, or they may be considered as computer program modules executed by the same physical processing circuitry. The memory 20 may store one or more computer program products 24 comprising program instructions that specify the operation of the circuitries 12 to 18. The memory 20 may further store a database 26 comprising

definitions for the selection of the link adaptation scheme, for example. The apparatus may further comprise a

communication interface 22 providing the apparatus with radio communication capability with the terminal devices. The communication interface 22 may comprise a radio communication circuitry enabling wireless communications and comprise a radio frequency signal processing circuitry and a baseband signal processing circuitry. The baseband signal processing circuitry may be configured to carry out the functions of a transmitter and/or a receiver. In some embodiments, the communication interface may be connected to a remote radio head comprising at least an antenna and, in some embodiments, radio frequency signal processing in a remote location with respect to the base station. In such embodiments, the

communication interface 22 may carry out only some of radio frequency signal processing or no radio frequency signal processing at all. The connection between the communication interface 22 and the remote radio head may be an analogue connection or a digital connection. In some embodiments, the communication interface 22 may comprise a fixed communication circuitry enabling wired communications.

An embodiment provides another apparatus comprising at least one processor and at least one memory including a computer program code, wherein the at least one memory and the

computer program code are configured, with the at least one processor, to cause the apparatus to carry out the procedures of the above-described terminal device. The at least one processor, the at least one memory, and the computer program code may thus be considered as an embodiment of means for executing the above-described procedures of the software defined network switch. Figure 14 illustrates a block diagram of a structure of such an apparatus. The apparatus may be comprised in the software defined network switch, e.g. it may form a chipset or a circuitry in the software defined network switch. In some embodiments, the apparatus is the software defined network switch. The apparatus comprises a processing circuitry 50 comprising the at least one processor. The processing circuitry 50 may comprise a default rule handling circuitry 54 configured to obtain information on at least one default flow handling rule for a subscriber such that

programming of subscriber-specific packet flows to a software defined network layer is avoided. The default rule handling circuitry 54 may be further configured to add the at least one default flow handling rule to an appropriate forwarding table. The apparatus may further comprise a specific rule handling circuitry 56 configured to obtain, if needed, information on at least one specific flow handling rule such that the at least one specific flow handling rule is specific to one or more of an access point name, the subscriber, a bearer of the subscriber, and a packet flow in the bearer of the subscriber. The specific rule handling circuitry 56 may be further configured to add the at least one specific flow handling rule to an appropriate forwarding table.

The processing circuitry 50 may comprise the circuitries 54, 56 as sub-circuitries, or they may be considered as computer program modules executed by the same physical processing circuitry. The memory 60 may store one or more computer program products 64 comprising program instructions that specify the operation of the circuitries 54, 56. The

apparatus may further comprise a communication interface 62 providing the apparatus with radio communication capability with base stations of one or more cellular communication networks. The communication interface 62 may comprise a radio communication circuitry enabling wireless communications and comprise a radio frequency signal processing circuitry and a baseband signal processing circuitry. The baseband signal processing circuitry may be configured to carry out the functions of a transmitter and/or a receiver. In some

embodiments, the communication interface 62 may comprise a fixed communication circuitry enabling wired communications.

As used in this application, the term ^xcircuitry' refers to all of the following: (a) hardware-only circuit

implementations such as implementations in only analog and/or digital circuitry; (b) combinations of circuits and software and/or firmware, such as (as applicable) : (i) a combination of processor (s) or processor cores; or (ii) portions of processor ( s ) /software including digital signal processor ( s ) , software, and at least one memory that work together to cause an apparatus to perform specific functions; and (c) circuits, such as a microprocessor ( s ) or a portion of a

microprocessor ( s ) , that require software or firmware for operation, even if the software or firmware is not physically present .

This definition of ^xcircuitry' applies to all uses of this term in this application. As a further example, as used in this application, the term "circuitry" would also cover an implementation of merely a processor (or multiple processors) or portion of a processor, e.g. one core of a multi-core processor, and its (or their) accompanying software and/or firmware. The term "circuitry" would also cover, for example and if applicable to the particular element, a baseband integrated circuit, an application-specific integrated circuit (ASIC), and/or a field-programmable grid array (FPGA) circuit for the apparatus according to an embodiment of the invention.

The processes or methods described above in connection with Figures 2 to 14 may also be carried out in the form of one or more computer process defined by one or more computer

programs. The computer program shall be considered to

encompass also a module of a computer programs, e.g. the above-described processes may be carried out as a program module of a larger algorithm or a computer process. The computer program (s) may be in source code form, object code form, or in some intermediate form, and it may be stored in a carrier, which may be any entity or device capable of

carrying the program. Such carriers include transitory and/or non-transitory computer media, e.g. a record medium, computer memory, read-only memory, electrical carrier signal,

telecommunications signal, and software distribution package. Depending on the processing power needed, the computer program may be executed in a single electronic digital processing unit or it may be distributed amongst a number of processing units.

The present invention is applicable to cellular or mobile communication systems defined above but also to other

suitable communication systems. The protocols used, the specifications of cellular communication systems, their network elements, and terminal devices develop rapidly. Such development may require extra changes to the described embodiments. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment.

It will be obvious to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The invention and its

embodiments are not limited to the examples described above but may vary within the scope of the claims.

List of abbreviations API application programming interface

CP control plane

CPU central processing unit

DPI deep packet inspection

SPI shallow packet inspection EPC evolved packet core

FW firewall

GGSN gateway GPRS support node

GW gateway

LTE long term evolution M2M machine-to-machine

MME mobility management entity

MT mobile terminal

NAT network address translation

NFV network function virtualization SAE system architecture evolution

SCCF service chain control function

SDN software defined network

UP user plane

VM virtual machine VNF virtual network function PGW PDN gateway

PDN packet data network

IP internet protocol

VLAN virtual local area network

TCP transmission control protocol

ID identification

MPLS multi-protocol label switching L3 layer-3

L4 layer-4

VPN virtual private network

LSP label switched paths

BGP border gateway protocol eNB enhanced node-B, base station

Claims

1. A method comprising: determining, in a network node, at least one default flow handling rule for a subscriber such that programming of subscriber-specific packet flows to a software defined network layer is avoided; and, if needed, determining, in the network node, at least one specific flow handling rule such that the at least one specific flow handling rule is specific to one or more of an access point name, the subscriber, a bearer of the subscriber, and a packet flow in the bearer of the subscriber.

2. A method of claim 1, the method comprising providing, in the network node, information on the determined at least one default flow handling rule to a software defined network switch.

3. A method of claim 1 or 2, the method comprising providing, in the network node, information on the determined at least one specific flow handling rule to a software defined network switch .

4. A method of claim 1, 2 or 3, wherein the at least one default flow handling rule is determined based on a system configuration or information received from an external system.

5. A method of any of claims 1 to 4, wherein the at least one specific flow handling rule is determined based on runtime information .

6. A method of any of claims 1 to 5, wherein the at least one default flow handling rule is to be added to an appropriate forwarding table in a software defined network switch.

7. A method of any of claims 1 to 6, wherein the at least one specific flow handling rule is to be added to an appropriate forwarding table in a software defined network switch.

8. A method of claim 7, wherein the at least one specific flow handling rule is to be removed from the forwarding table when no longer needed.

9. A method of any of claims 1 to 8, the method comprising defining, in the network node, separate default flow handling rules for different IP pools.

10. A method of any of claims 1 to 9, the method comprising identifying, in the network node, packet flows based on IP pools to provide a primary data path for selected packets in a related service chain.

11. A method of any of claims 1 to 10, the method comprising creating, in the network node, a service chain based on the flow handling rule, the service chain identifying which packet flows for which subscribers are to be conveyed via the service chain.

12. A method of claim 11, wherein the service chain comprises one or more services selected from a group consisting of a deep packet inspection service, content optimization service, parental control service, firewall service, network address translation service, and some other operator service for user plane traffic.

13. A method of any of claims 1 to 12, the method comprising determining, in the network node, an additional flow handling rule such that a packet flow is to be conveyed from a first service to a second service on a data path.

14. A method comprising: obtaining, in a network node, information on at least one default flow handling rule for a subscriber such that

programming of subscriber-specific packet flows to a software defined network layer is avoided; and adding, in the network node, the at least one default flow handling rule to an appropriate forwarding table; wherein, if needed, the method further comprises obtaining, in the network node, information on at least one specific flow handling rule such that the at least one specific flow handling rule is specific to one or more of an access point name, the subscriber, a bearer of the

subscriber, and a packet flow in the bearer of the

subscriber; and adding, in the network node, the at least one specific flow handling rule to an appropriate forwarding table.

15. A method of claim 14, the method comprising removing, in the network node, the at least one specific flow handling rule from the forwarding table when no longer needed.

16. A method of claim 14 or 15, the method comprising, in the network node, obtaining separate default flow handling rules for different IP pools.

17. A method of claim 14, 15 or 16, the method comprising obtaining, in the network node, an additional flow handling rule such that a packet flow is to be conveyed from a first service to a second service on a data path.

18. A method of any of claims 1 to 17, the method comprising prioritising, in the network node, the at least one specific flow handling rule over the at least one default flow

handling rule.

19. An apparatus comprising: at least one processor; and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to determine at least one default flow handling rule for a subscriber such that programming of subscriber-specific packet flows to a software defined network layer is avoided; and, if needed, determine at least one specific flow handling rule such that the at least one specific flow handling rule is specific to one or more of an access point name, the subscriber, a bearer of the subscriber, and a packet flow in the bearer of the subscriber .

20. An apparatus of claim 19, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to provide information on the determined at least one default flow handling rule to a software defined network switch.

21. An apparatus of claim 19 or 20, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to provide information on the determined at least one specific flow handling rule to a software defined network switch.

22. An apparatus of claim 19, 20 or 21, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to

determine the at least one default flow handling rule based on a system configuration or information received from an external system.

23. An apparatus of any of claims 19 to 22, wherein the at least one memory and the computer program code are

configured, with the at least one processor, to cause the apparatus to determine the at least one specific flow

handling rule based on runtime information.

24. An apparatus of any of claims 19 to 23, wherein the at least one memory and the computer program code are

configured, with the at least one processor, to cause the apparatus to define separate default flow handling rules for different IP pools.

25. An apparatus of any of claims 19 to 24, wherein the at least one memory and the computer program code are

configured, with the at least one processor, to cause the apparatus to identify packet flows based on IP pools to provide a primary data path for selected packets in a related service chain.

26. An apparatus of any of claims 19 to 25, wherein the at least one memory and the computer program code are

configured, with the at least one processor, to cause the apparatus to create a service chain based on the flow

handling rule, the service chain identifying which packet flows for which subscribers are to be conveyed via the service chain.

27. An apparatus of any of claims 19 to 26, wherein the service chain comprises one or more services selected from a group consisting of a deep packet inspection service, content optimization service, parental control service, firewall service, network address translation service, and some other operator service for user plane traffic.

28. An apparatus of any of claims 19 to 27, wherein the at least one memory and the computer program code are

configured, with the at least one processor, to cause the apparatus to determine an additional flow handling rule such that a packet flow is to be conveyed from a first service to a second service on a data path.

29. An apparatus comprising: at least one processor; and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to obtain information on at least one default flow handling rule for a subscriber such that programming of subscriber-specific packet flows to a software defined network layer is avoided; and add the at least one default flow handling rule to an

appropriate forwarding table; wherein, if needed, the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to obtain information on at least one specific flow handling rule such that the at least one specific flow handling rule is specific to one or more of an access point name, the subscriber, a bearer of the subscriber, and a packet flow in the bearer of the subscriber; and add the at least one specific flow handling rule to an appropriate forwarding table.

30. An apparatus of claim 29, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to remove the at least one specific flow handling rule from the forwarding table when no longer needed.

31. An apparatus of claim 29 or 30, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to obtain separate default flow handling rules for different IP pools.

32. An apparatus of claim 29, 30 or 31, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to obtain an additional flow handling rule such that a packet flow is to be conveyed from a first service to a second service on a data path.

33. An apparatus of any of claims 29 to 32, wherein the at least one memory and the computer program code are

configured, with the at least one processor, to cause the apparatus to prioritize the at least one specific flow handling rule over the at least one default flow handling rule .

34. An apparatus comprising means for carrying out the steps of the method according to any preceding claim 1 to 18.

35. A computer program product embodied on a distribution medium readable by a computer and comprising program

instructions which, when loaded into an apparatus, execute the method according to any preceding claim 1 to 18.

36. A computer program product embodied on a non-transitory distribution medium readable by a computer and comprising program instructions which, when loaded into the computer, execute a computer process comprising: determine, in a network node, at least one default flow handling rule for a subscriber such that programming of subscriber-specific packet flows to a software defined network layer is avoided; if needed, determine, in the network node, at least one specific flow handling rule such that the at least one specific flow handling rule is specific to one or more of an access point name, the subscriber, a bearer of the

subscriber, and a packet flow in the bearer of the

subscriber .

37. A computer program product embodied on a non-transitory distribution medium readable by a computer and comprising program instructions which, when loaded into the computer, execute a computer process comprising: obtain, in a network node, information on at least one default flow handling rule for a subscriber such that programming of subscriber-specific packet flows to a software defined network layer is avoided; add, in the network node, the at least one default flow handling rule to an appropriate forwarding table; wherein the program instructions, when loaded into the computer, execute, if needed, a computer process comprising: obtain, in the network node, information on at least one specific flow handling rule such that the at least one specific flow handling rule is specific to one or more of an access point name, the subscriber, a bearer of the

subscriber, and a packet flow in the bearer of the

subscriber; add, in the network node, the at least one specific flow handling rule to an appropriate forwarding table.