WO2016102516A1 - Communication system - Google Patents

Abstract

A system is described in which core network apparatus of a cellular communication system comprises means for controlling traffic steering in a local area network, 'LAN', means for generating a message including traffic steering information for controlling said traffic steering, and means for providing the generated message to a functional node arranged to apply said traffic steering in said LAN based on said traffic steering information. The traffic steering information is arranged for enabling the traffic to be steered to an appropriate LAN service function.

Description

Communication System

The present invention relates to mobile communication devices and networks, particularly but not exclusively those operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof, such as the Long Term Evolution (LTE) of the Evolved Packet Core (EPC) network. The invention has particular although not exclusive relevance to policy-based traffic steering between a core network and a local area network.

In a mobile (cellular) communications network, (user) communication devices (also known as user equipment (UE), for example mobile telephones) communicate data packets with remote servers or with other communication devices via base stations using various radio access technologies or radio access types (RATs). The various RATs are each connected to a core network (such as an EPC network), which is in turn connected to other networks for providing end-to-end connectivity for the users.

A Service Function Chain (SFC) is a set of service functions (SF), which is applied on data packets in a specific sequence. A service function (SF) is a function that is responsible for the specific treatment of received packets. Examples for SFs include: functions for security and user privacy (e.g. firewalls (FW); intrusion detection systems (I DS); en/decryption, malware detection, etc.); functions which affect the user service quality (e.g. video optimizer proxies, TCP optimizers, image compression proxies); parental control; network address translation (NAT); and/or the like. Further details of service chaining are available from the following Internet Drafts by the Internet Engineering Task Force (IETF): "Service Function Chaining Problem Statement" (August 2014) and "Service Function Chaining Use Cases in Mobile Networks" (June 2014), the entire contents of which documents are incorporated herein by reference. The functionalities relating to service chaining in the context of 3GPP networks are described in technical report (TR) 22.808 V13.0.0 titled "Study on Flexible Mobile Service Steering (FMSS)" (September 2014).

Network operators, e.g. mobile network operators (MNOs), apply SFCs depending on various parameters such as: subscription information (e.g. type/category of data plan); customer information (e.g. whether the customer has a private subscription or a company subscription); data traffic protocol being used (e.g. TCP, UDP, RTP, HTTP, etc.); service and application type (e.g. IMS, VoIP, real-time video, video streaming, web browsing, etc.); and/or other. Consequently, a multitude of different combinations of SFCs exist, which need to be managed and controlled by the MNOs.

Service function chaining, based on operator defined policies, is taking place in a local area network (LAN) portion of the operator's network (e.g. a 3GPP network) referred to as a Gi-LAN (or SGi-LAN). The Gi-LAN (or SGi-LAN) is coupled to a core network portion of the MNO's network via an appropriate Gi (or SGi) interface. In order to make it possible to apply an appropriate service chaining in the (S)Gi-LAN according to operator policies defined in the core network, associated traffic steering information is exchanged between the core network and the (S)Gi-LAN. Such traffic steering information is based on service context information used in that 3GPP network, which service context information may include: policy information; status information; traffic flow information; information relating to network status (such as radio access network and/or core network congestion information); user location; user equipment (UE) type; time; valued added service subscriptions such as parental control; malware detection; and/or the like.

However, in this context, the implementation of service function chaining may be difficult due to inconsistencies / incompatibilities arising between network entities in one or more of the following:

^• semantics of information exchanged between the 3GPP network and the (S)Gi- LAN to implement service chaining based on 3GPP operator policies;

^• interfaces used for this information exchange;

^• protocols used for this information exchange; and

^• algorithmic operations and order of the involvement of functional entities for the information exchange (message sequence charts). Moreover, currently there is no efficient mechanism in place for exchanging information and policies about which SF is to be used for which data flow (for which subscriber) on the (S)Gi-LAN in the mobile operator's network.

Accordingly, preferred embodiments of the present invention aim to provide methods and apparatus which overcome or at least partially alleviate the above issues. In one aspect the invention provides core network apparatus of a cellular communication system, the core network apparatus comprising: means for controlling traffic steering in a local area network, 'LAN': means for generating a message including traffic steering information for controlling said traffic steering; and means for providing said message to a functional node arranged to apply said traffic steering in said LAN based on said traffic steering information; wherein said traffic steering information is arranged for enabling said traffic to be steered to an appropriate LAN service function.

In another aspect the invention provides a functional node for applying traffic steering in a local area network, 'LAN', the functional node comprising: means for receiving a message including traffic steering information from core network apparatus of a cellular communication system; and means for applying traffic steering in said LAN to steer traffic to an appropriate service function of said LAN based on said traffic steering information.

In another aspect the invention provides a method performed by core network apparatus of a cellular communication system, the method comprising: generating a message including traffic steering information for controlling traffic steering in a local area network, 'LAN'; and providing said message to a functional node arranged to apply said traffic steering in said LAN based on said traffic steering information; wherein said traffic steering information is arranged for enabling said traffic to be steered to an appropriate LAN service function.

In another aspect the invention provides a method performed by a functional node for applying traffic steering in a local area network, 'LAN', the method comprising: receiving a message including traffic steering information from core network apparatus of a cellular communication system; and applying traffic steering in said LAN to steer traffic to an appropriate service function of said LAN based on said traffic steering information. Aspects of the invention extend to corresponding systems, methods, and computer program products such as computer readable storage media having instructions stored thereon which are operable to program a programmable processor to carry out a method as described in the aspects and possibilities set out above or recited in the claims and/or to program a suitably adapted computer to provide the apparatus recited in any of the claims.

Each feature disclosed in this specification (which term includes the claims) and/or shown in the drawings may be incorporated in the invention independently (or in combination with) any other disclosed and/or illustrated features. In particular but without limitation the features of any of the claims dependent from a particular independent claim may be introduced into that independent claim in any combination or individually.

Exemplary embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings in which:

Figure 1 illustrates a mobile (cellular) telecommunication system of a type to which embodiments of the invention are applicable;

Figure 2 is an exemplary block diagram illustrating the main functionalities of a generic core network apparatus of the system shown in Figure 1 .

Figure 3 is an exemplary block diagram illustrating the main functionalities of a generic local area network apparatus of the system shown in Figure 1 .

Figure 4 illustrates an exemplary way of mapping service context data to a service function chain;

Figure 5 illustrates another exemplary way of mapping service context data to respective service function chains using normalised identifiers;

Figure 6 illustrates an exemplary architecture for service function chain based traffic steering in a local area network;

Figure 7 illustrates another exemplary architecture for service function chain based traffic steering in a local area network; and

Figures 8 to 1 1 are exemplary timing diagrams illustrating methods performed by components of the mobile telecommunication system of Figure 1 whilst carrying out embodiments of the invention.

Overview

Figure 1 schematically illustrates a mobile (cellular) telecommunication system 1 comprising a mobile network operator domain 2 coupled to an external network 3. The mobile network operator domain 2 may simply be referred to as a mobile network operator (MNO) network. The external network 3 typically comprises an Internet Protocol (IP) based network such as the Internet and/or the like.

In this system 1 , users of communication devices (such as mobile telephones and/or other user equipment) can communicate with each other and/or with remote servers using at least one radio access technology/type (RAT) 4. Such RATs 4 include, although not limited to, access technologies in accordance with one or more of the following standards: LTE, UMTS, GPRS, WiFi, WiMAX, and/or the like. Each RAT 4 is connected to a core network 5 (in this example, a 3GPP mobile core network, also known as an enhanced packet core (EPC) network), which is in turn coupled to a Gi-LAN 6 via a so-called Gi interface (and/or an SGi-LAN 6 via a so- called SGi interface). The core network 5 includes, amongst others, a packet data network (PDN) gateway 12, a serving gateway (S-GW) 13, a serving general packet radio service support node (SGSN) 14, and a policy control node 16. It will be appreciated that the core network 5 may also include other nodes, such as a gateway general packet radio service support node (GGSN), a mobility management entity (MME), a home subscriber server (HSS), an operation and maintenance (OAM) entity, which are omitted from Figure 1 for simplicity.

Data traffic (in either direction) traverses the mobile network operator domain 2 between the external network 3 (e.g. the Internet) and one or more radio access networks (RAN) each employing at least one associated RAT 4. The (S)Gi-LAN 6 is configured to perform service function chaining for transmitted data flows using, for example, an appropriate service function chaining (SFC) entity 7 provided at the ingress/egress of the (S)Gi-LAN 6.

Advantageously, the SFC entity 7 is configured to perform policy-based service chain traffic steering between the core network 5 and the (S)Gi-LAN 6, using a predetermined mapping between combinations of, in this example: service context data 20; service context identifier (SCI) 21 ; and (technology-specific) service function chain identifier 22.

In this example, the service context identifier 21 is beneficially normalised such that the core network 5 can interwork with different SFC technologies (e.g. Open Flow and/or the like). In other words, the normalised service context identifier 21 is independent from the underlying technology used in the (S)Gi-LAN 6 (and/or the core network 5). A mapping between service context information 20 and a corresponding normalised SCI 21 is created, for example, by the policy control node 16.

Moreover, a mapping between the normalised SCI 21 and an appropriate SFC implementation specific (S)Gi-LAN SFC identifier (SSI) 22 is also created. The SSI 22 used in this example is defined in such a way that it contains sufficient information for the (S)Gi-LAN 6 to be able to perform the necessary steps and decisions for SFC based traffic steering.

Beneficially, such mapping between service context data 20, SCI 21 , and SSI 22 allows transfer of service context from the core network 5 to the (S)Gi-LAN 6 in response to various events (e.g. inter alia modification of the service context data 20; detection of a new/updated traffic flow, and network management events) and regardless of the architecture of the network 2. Using such dynamic, policy based control of service function chains in the (S)Gi-LAN 6, it is therefore possible to improve user quality of experience (QoE), services, and operators revenue. A more detailed description of some of the novel aspects of exemplary embodiments will now be given, with reference to Figures 2 to 1 1 .

Core network apparatus

Figure 2 is a block diagram illustrating the main functionalities performed by a generic core network apparatus forming part of the core network 5 shown in Figure 1 . It will be appreciated that the generic core network apparatus may be adapted to operate as a specific core network node (e.g. as a traffic detection function 7 and/or a service function chaining interworking function 17) by enabling/disabling one or more of its functionalities accordingly.

The core network apparatus comprises a transceiver circuit 31 which is operable to transmit signals to, and to receive signals from, other network nodes/functions via a network interface 33. The operation of the transceiver circuit 31 is controlled by a controller 35 in accordance with software stored in memory 37. The software may be pre-installed in the memory 37 and/or may be downloaded via the telecommunications network or from a removable data storage device (RMD), for example. The software includes, among other things, an operating system 39, a communication control function 41 , a traffic detection function (TDF) 7, a mapping function 45, a subscription profile repository / user data repository (SPR/UDR) function 24, a policy and charging rules function (PCRF) 16, and a service function chaining interworking (SFC-IW) function 17. It will be appreciated that one or more of these functions may be optional (and hence they are shown in Figure 2 using dotted lines). The communication control function 41 manages communication between the various functions and also between the core network apparatus and other nodes located in the core network 5 and in the (S)Gi-LAN 6.

The TDF 7 acts as traffic classifier (e.g. when a separate traffic classifier function is not provided or not enabled in the (S)Gi-LAN 6) and monitors traffic flows at the ingress/egress of the (S)Gi-LAN 6. The TDF 7 is also responsible for informing the PCRF 16 about start and stop of traffic flows.

The mapping function 45 performs appropriate mapping between service context data 20 and corresponding normalised service context identifiers 21 , and between normalised service context identifiers 21 and corresponding technology-specific service function chain IDs 22 (e.g. in co-operation with other functions, such as the PCRF 16 and/or the SFC-IW function 17)

The SPR/UDR function 24 is responsible for storing subscription and/or service profile data associated with a particular subscriber/user. The SPR/UDR function 24 is also responsible for providing, to other functions/nodes, information identifying services enabled for a particular traffic flow (based on an associated subscription and/or service profile).

The PCRF 16 is responsible for storing and enforcing policy and charging rules for each subscriber (and associated data packets). The PCRF 16 is also responsible for maintaining an appropriate mapping between service context data 20 and corresponding normalised service context identifiers 21 (via the mapping function 45), and providing this mapping to other functions (e.g. the SFC-IW function 17).

The SFC-IW function 17 is responsible for interworking with the (S)Gi-LAN nodes (such as the SFC controller 18 and/or the service function chaining node 7). The SFC- IW function 17 is also responsible for maintaining an appropriate mapping between normalised service context identifiers 21 and corresponding technology-specific service function chain IDs 22 (via the mapping function 45), and providing this mapping to the SFC controller 18 (e.g. upon request by the SFC controller 18 and/or another node). LAN apparatus

Figure 3 is a block diagram illustrating the main functionalities performed by a generic network apparatus forming part of the (S)Gi-LAN 6 shown in Figure 1 . It will be appreciated that the generic LAN apparatus may be adapted to operate as a specific node of the (S)Gi-LAN 6 (e.g. as a traffic classifier T or an SFC controller 18) by enabling/disabling one or more of its functionalities accordingly.

The LAN apparatus comprises a transceiver circuit 51 which is operable to transmit signals to, and to receive signals from, other network nodes/functions via a network interface 53. The operation of the transceiver circuit 51 is controlled by a controller 55 in accordance with software stored in memory 57. The software may be pre-installed in the memory 57 and/or may be downloaded via the telecommunications network or from a removable data storage device (RMD), for example. The software includes, among other things, an operating system 59, a communication control function 61 , a traffic classifier function 7', an SFC controller function 18, and one or more service functions SF-1 to SF-n. It will be appreciated that one or more of these functions may be optional (and hence they are shown in Figure 3 using dotted lines).

The communication control function 61 manages communication between the various functions and also between the LAN apparatus and other nodes located in the core network 5 and in the (S)Gi-LAN 6.

The traffic classifier function T is responsible for monitoring traffic flows at the ingress/egress of the (S)Gi-LAN 6. The traffic classifier function T is also responsible for informing the PCRF 16 about start and stop of traffic flows, and for informing the SFC controller function 18 when a new traffic flow is detected for which no traffic steering information is available.

The SFC controller function 18 is responsible for controlling policy-based traffic steering for traffic flows traversing the (S)Gi-LAN 6, such as routing each data packet of a particular traffic flow to the appropriate service functions in a prescribed order (for that traffic flow). In doing so, the SFC controller function 18 uses appropriate policy- based traffic steering information (obtained from the core network 5), such as an SSI 22 associated with a particular traffic flow. If there is no information for policy-based traffic steering for a particular traffic flow, then the SFC controller function 18 is configured to request a corresponding rule (SSI 22) from the core network 5 (e.g. from the PCRF 16 or the SFC-IW 17).

Each service function 66 is responsible for a specific treatment of data packets. Service functions 66 may include: functions for security and user privacy; functions that affect the user service quality; functions for parental control; functions for network address translation; and/or the like.

In the above description, the core network apparatus and the local area network apparatus are described for ease of understanding as having a number of discrete functions (such as the mapping function, the service functions, and the communication control functions). Whilst these functions may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these functions may be built into the overall operating system or code and so these functions may not be discernible as discrete entities.

Mapping for service function chaining

Figure 4 illustrates the concept of mapping between service context data 20, service context identifier 21 , and corresponding technology-specific service function chain ID 22. Figure 4 also illustrates respective exemplary functional network entities (such as the Policy and Charging Rules Function (PCRF) 16, service function chain interworking function (SFC-IW) 17, and service function chain (SCF) controller 18) that are associated with each information container.

Service context data 20 may comprise any static and/or dynamic attribute, including on or more of:

• subscription data, such as:

- subscriber category (e.g. gold, silver, bronze);

- subscribed value-added services (e.g. parental control, malware detection);

- tariff and charging information (e.g. data plan, credits); and/or

- quality of service (QoS) information;

^• terminal-specific information, such as:

- UE (user equipment) class;

- technical capabilities (e.g. display capabilities such as size, resolution, battery status); and/or

- terminal category (e.g. machine-type communication device, stationary device, device with high speed mobility profile, etc.);

^• network-specific information, such as: - network status, such as RAN/CN congestion or load status, C-plane overload status, etc.;

- Radio Access Technology (RAT) type (e.g. GPRS, EGPRS, UTRAN, EUTRAN, WiFi, 3GPP-access, non-3GPP-access);

- related network identifiers (e.g. UE I P addresses, gateway addresses, tunnel addresses, tunnel endpoint I Ds (TEIDs), International Mobile Subscriber Identity (IMSI), etc.); and/or

- target network information (e.g. Access Point Name (APN));

^• user-specific information, such as:

- user location (coordinates, indoor/outdoor, cell-id);

- user profile information (e.g. preferred over-the-top services, mobility profile); and/or

- user time of day;

• application specific information, such as:

- application type (web, video, instant messaging, etc.);

- application protocol (e.g. Hypertext Transfer Protocol (HTTP), Real-time Transport Protocol (RTP));

- application provider; and/or

- application meta information (e.g. Uniform Resource Locator (URL) suffixes, HTTP POST header information, etc.).

As can be seen, the network operator may create (e.g. using the mapping function 45) a mapping between a particular service context data 20 (used in its core network 5) and a specific normalised service context identifier SCI) 21 . It will be appreciated that more than one service context data 20 may be mapped to a single normalised SCI 21 , if appropriate.

Service context identifiers 21 are normalised in the sense that in the mobile network domain 2 each service context identifier 21 uniquely identifies a set of service context attributes (service context data 20), which can be mapped to a set of corresponding service functions. For example, a user's subscription profile (in the core network 5) may contain an entry for "parental control", which corresponds to a specific service function in the (S)Gi-LAN 6.

As also shown in Figure 4, each normalised SCI 21 is in turn mapped to an implementation specific SFC identifier (SSI) 22 (in this example, an SSI 22 that is specific to the SGi-LAN 6). Each SSI 22 contains sufficient information for the (S)Gi- LAN 6 (e.g. the SFC controller function 18) to be able to perform necessary steps and decisions for SFC based traffic steering, i.e. invoking the corresponding SFs in a desired order. Such information includes, for example, appropriate data plane configurations (e.g. forwarding rules in switches) and/or instantiation or configuration of corresponding service functions.

Accordingly, the SSI 22 depends on the actual implementation and deployment of service function chaining in the given (S)GI-LAN 6 (and hence it may be different from one (S)GI-LAN to another and/or from one network operator to another). For example, the (S)Gi-LAN 6 may implement service function chaining according to the Network Functions Virtualisation (NFV) framework by the European Telecommunications Standards Institute (ETSI). In this case, the SSI 22 may correspond to a Virtual Network Function (VNF) forwarding graph identifier (vnffgd-id). For Open Flow-based implementations, a virtual tenant network id (VTN-ID) may be used as the SSI 22. This principle is further illustrated in Figure 5, where multiple SFC technologies (denoted 'SGi-LAN 1 ', 'SGi-LAN 2', and 'SGi-LAN 3') are addressed by using the same normalised SCI 21 associated with a particular service context data 20 (or a set of service context data 20). However, in each SGi-LAN 6-1 to 6-3 a different respective SSI 22-1 to 22-3 is mapped to the same SCI 21 (although it will be appreciated that some or all of the SSIs 22-1 to 22-3 may be the same, if appropriate) and hence each SSI 22-1 to 22-3 effectively identifies the same SFC (albeit in a different SGi-LAN).

Table 1 gives an example of combined mapping between service context information 20, SCI 21 , and technology-specific SSI 22.

SCI SSI Subscriber Value- RAT Network Location Time category added load/status information

services

profile

1 0xAC6 Silver Parental WLAN N.A. "indoor" 9pm control, to firewall 9am

2 0XFB4 Silver None UTRAN Medium All All loaded

3

Table 1 : mapping of service context data to SCI and SSI

As can be seen in Table 1 , each SCI 21 points to a corresponding service context 20 and an SSI 22 for the service chain required for that service context 20. It will be appreciated that whilst each service context 20 may be specific to a particular core network 5 and each SSI 22 may be specific to a particular (S)Gi-LAN 6, the use of a corresponding 'normalised' SCI 21 ensures that each SFC (identified by its associated SSI 22) can be mapped to the correct service context 20. This in turn results in the appropriate service function(s) being applied for each data packet traversing the (S)Gi-LAN 6. The traffic steering information is then conveyed into the appropriate (S)Gi-LAN 6 (e.g. from the SFC-IW function 17 to the SFC controller function 18). Depending on the implementation model used for the (S)Gi-LAN 6, the traffic steering information includes information for identifying a traffic flow (for example, an 'I P 5-Tuple': source address, destination address, source port, destination port, protocol) and an application identifier, or packet markings attached to the traffic flow for which the traffic steering information applies, and the SSI 22 and/or the SCI 21 associated with a particular service function chain applicable for that traffic flow.

The transfer of traffic steering information between the core network 5 and the (S)Gi- LAN 6 may be triggered by at least one of the following events: a modification of the service context data 20; a data plane action (e.g. flow arrival); and a network management event.

For example, if the service context data 20 and/or the mapping between the service context data 20 and the corresponding SCI 21 changes, a new SCI 21 is calculated and mapped (by the mapping function 45) to an appropriate SSI 22 (per (S)Gi-LAN). In this case, the corresponding SFC controlling function 18 in the (S)Gi-LAN 6 is informed (e.g. by the SFC-IW function 17) about the change in order to update its configuration accordingly.

If a traffic flow arrives at the (S)Gi-LAN 6, a function (e.g. a traffic detection function 7 or a traffic classifier function 7) of the (S)Gi-LAN 6 is configured to check (e.g. by looking up in Table 1 ) whether any information (e.g. SSI 22) for policy-based traffic steering exists for that particular traffic flow. If there is no information for policy-based traffic steering for that particular traffic flow, then the function of the (S)Gi-LAN 6 may be configured to request a corresponding rule from the core network 5 (and add it to Table 1 ). If information for policy-based traffic steering is available for that particular traffic flow (i.e. an SSI 22 is found / added to Table 1 ), then it is applied for that traffic flow in the (S)Gi-LAN 6.

It will be appreciated that traffic steering information may be conveyed either explicitly or implicitly (or both) from the core network 5 to the (S)Gi-LAN 6. In this case, explicit information transfer means that at least one dedicated message is communicated between the core network 5 and the (S)Gi-LAN 6. Such a dedicated message may include a dedicated control message (control-plane approach) and/or it can be attached to data plane packets (user-plane approach). Implicit information transfer means that a-priori information is used (i.e. information that is known to the relevant functions of both the core network 5 and the (S)Gi-LAN 6). For example, the core network 5 may be configured to use a certain I P address prefix for all UEs which are subscribed to a certain set of services (identified by corresponding service context data 20). The (S)Gi-LAN 6 then forwards all traffic with this specific I P address prefix to a dedicated SFC (e.g. an SFC identified by a particular SSI 22 mapped to the service context data 20 via an appropriate normalised SCI 21 ).

The (S)Gi-LAN 6 (e.g. using its SFC controller function 18) may give feedback on the availability or the status of SFCs to the mobile network 2. For example, in case of resource overload in the (S)Gi-LAN 6, certain service functions and correspondingly service function chains may not be available any more. This information may be conveyed to the mobile network 2, which then prioritizes the assignment of SFCs to traffic flows according to subscriber priority. Logical architecture

Figure 6 illustrates an exemplary architecture for service function chain based traffic steering in a local area network, such as an (S)Gi-LAN 6. Specifically, Figure 6 illustrates an architecture option where a respective TDF 7 is placed on the ingress and egress of the (S)Gi-LAN 6. In this case, the TDF 7 acts as traffic classifier and informs the PCRF 16 about start and stop of certain traffic flows.

Figure 7 illustrates an exemplary architecture for service function chain based traffic steering in another local area network, such as another (S)Gi-LAN 6. Specifically, Figure 7 illustrates an architecture option where the traffic classifier function is not part of the 3GPP mobile core network domain 5 (i.e. not part of a TDF 7). Accordingly, Figure 7 illustrates respective traffic classifier nodes T on the ingress and egress of the (S)Gi-LAN 6. In this example, a new interface (denoted 'Sg' in Figure 7) is introduced between the SFC-IW 17 and the PCRF 16. The Sg interface is used for exchanging policies between the networks, e.g. by providing an SCI from the PCRF 16 to the SFC-IW 17, where it is translated into an appropriate SSI 22 for further usage by the SFC controller 18 (and traffic classifier nodes T connected to the SFC controller 18).

As can be seen in the examples shown in Figures 6 and 7, the logical architecture for SFC based traffic steering is not restricted to a specific architecture. However, it will be appreciated that the logical architecture comprises, amongst others, one or more of the following functional entities:

^• a Policy Control and Rule Function (PCRF) 16;

^• a Packet Data Network Gateway (P-GW) 12;

• a Traffic Detection Function (TDF) 7 and/or a traffic classifier 7';

· a Service Function Chaining Interworking Function (SFC-IW) 17;

• an SFC controller 18, which is an entity in the (S)Gi-LAN 6 for controlling SFCs (e.g. service function instantiation, forwarding plane setup, etc.); and

^• a Service Function (denoted 'SF1 ' to 'SF4' in Figure 6) in the (S)Gi-LAN 6.

Further details of these functional entities are given in 3GPP technical specification (TS) 23.401 V13.0.0 titled "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access" (September 2014) and 3GPP TS 23.203 V13.1 .0 titled "Policy and charging control architecture" (September 2014), and the "Service Function Chaining Problem Statement" Internet Draft, the contents of which documents are incorporated herein by reference.

Although shown separately, it will be appreciated that some of these functions, especially the SFC-IW 17, may be co-located with other functions in order to simplify the logical architecture. For example, the SFC-IW 17 may be co-located with a TDF 7 (or the SFC-IW 17 may be shared between a plurality of TDFs 7) or the PCRF 16.

Accordingly, using an appropriate logical architecture comprising the above functional entities (and a mapping between service context data 20, SCI 21 , and SSI 22), traffic arriving from the external network 3 and/or from (the P-GW 12 in) the core network 5 can be beneficially steered into one or more service functions, which together form a service function chain.

Operation - TDF on ingress/egress of (S)Gi-LAN

Figure 8 illustrates an exemplary procedure for creating and conveying traffic steering information into the (S)Gi-LAN 6. In this case, the procedure is triggered by the arrival of a packet at the ingress TDF 7 of the (S)Gi-LAN 6 (when using, for example, the architecture illustrated in Figure 6).

As can be seen, in step 1 , the ingress TDF 7 is buffering incoming data packets (if appropriate), for example in the associated memory 37. Upon detecting a traffic flow, the ingress TFD 7 generates and sends a report to the PCRF 16 about the detected flow (step 2). In response to this, the PCRF 16 contacts (in step 3) the subscription profile repository / user data repository (SPR/UDR) function 24 for checking the subscription and/or service profile associated with the detected flow. For example, the PCRF 16 may obtain, from the SPR/UDR 24, information identifying services enabled for the detected flow (i.e. for an associated subscription). In the following steps 4 to 14, an exemplary traffic steering update procedure is shown, including a control-plane based option (steps 8 to 10) and a user-plane based option (steps 13 and 14).

4. The PCRF 16 is configured to collect and correlate required information of the service context data 20, as described above. 5. The PCRF 16 performs (using the mapping function 45) mapping the service context data 20 to a corresponding normalised SCI 21 . 6. The PCRF 16 conveys the normalised SCI 21 and an appropriate service data flow descriptor (e.g. an IP 5-tuple and/or an application identifier) to the SFC-IW function 17 associated with the (S)Gi-LAN 6.

7. The SFC-IW 17 performs (using the mapping function 45) mapping of the normalised SCI to the appropriate technology-specific SSI 22 used in that (S)Gi-

LAN 6, and proceeds to step 8 or 13, depending on which option is used.

C-plane based option (Option A'):

8. In case a control-plane (C-plane) based option is followed, then the SFC-IW 17 is configured to convey (via the transceiver circuit 31 ) the information received in step 7 to an SFC controlling entity (in this example, the SFC controller 18) in the

(S)Gi-LAN 6.

9. The SFC controller 18 is configured to perform any necessary action(s) for instantiating and configuring the appropriate SFC for that particular flow.

10. The SFC controller 18 is also configured to generate and send (via the transceiver circuit 51 ) an appropriately formatted response to the SFC-IW 17 in order to indicate whether the SFC is ready or not (e.g. ACK/NACK) for that particular flow.

1 1 . Upon receiving the SFC controller's 18 indication to this effect (e.g. an 'ACK'), the SFC-IW 17 is configured to send (either directly or via the PCRF 16) an appropriate indication to the ingress TDF 7 that the SFC is ready. This indication also includes information for identifying the SFC, such as the associated SSI 22 and/or SCI 21 .

12. If any data packet for this flow has been buffered (in step 1 ), then it is retrieved (de-buffered) and forwarded by the ingress TDF 7 to the appropriate SFC, then towards the egress TDF 7. U-plane based option (Option B'):

13. In case a user-plane (U-plane) based option is followed, then the ingress TDF 7 may be configured to add (e.g. using the communication control function 41 ) traffic steering information (e.g. an associated SCI 21 and/or SSI 22) into the header of each packet passing through the TDF 7. 14. Based on the traffic steering information included in their headers, data packets are routed from the ingress TDF 7 towards the first hop of the appropriate SFC (and to each remaining hop of that SFC, in the required order), then towards the egress TDF 7. Operation - TDF and SFC-IW co-located

In the architectural option illustrated in Figure 9, the SFC-IW 17 is co-located with the TDF 7. The traffic steering information update procedure in this case is substantially identical to the example shown in Figure 8. However, in Figure 9, step 6 of Figure 8 is replaced by the following step: 5. The PCRF 16 generates and sends (via the transceiver circuit 31 ) an appropriately formatted application detection and control (ADC) rule to the ingress TDF 7 which ADC rule includes appropriate traffic steering information (e.g. an associated SCI 21 and/or SSI 22) for that particular flow.

Furthermore, in this example, the (ingress) TDF 7 and PCRF 16 are configured to include traffic steering information (at least one of: traffic flow identification, SCI 21 , and SSI 22) in signalling messages communicated over the Sd interface between them. This can be achieved, for example, by adding one or more specific fields to the ADC rule format, and corresponding reports on start/stop of application flows.

Operation - traffic classifier on ingress/egress of (S)Gi-LAN

Figure 10 illustrates an exemplary procedure for requesting traffic steering information from the core network 5 in response to a new traffic flow arriving at the (S)Gi-LAN 6. However, in this example, the traffic classifier function does not form part of the core network 5 and hence no TDF 7 is used (although a TDF 7 may still be provided for other purposes). Thus, in this case, generic (or non-3GPP specific) traffic classifiers T are provided at the ingress and egress of the (S)Gi-LAN 6, as illustrated in Figure 7. It will be appreciated that such 'non-3GPP' traffic classifiers T are not controlled by the 3GPP core network 5.

In this example, the ingress traffic classifier T is configured to inform (in step 1 ) the SFC controller 18 in the (S)Gi-LAN 6 when a new traffic flow is detected for which no traffic steering information is available.

As generally shown in step 2, after being informed that a new traffic flow arrived at the ingress traffic classifier 7', the SFC controller 18 is configured to generate and send, to the SFC-IW 17, an appropriately formatted signalling message for requesting SFC steering information. The SFC controller's 18 request includes information using which the SFC-IW 17 (and/or another node) is able to identify the service context data (for example, an I P address associated with the traffic flow, such as an IP address of a UE for which the traffic flow is intended).

Next, the SFC-IW 17 is configured to generate and send (in step 3) an appropriately formatted steering information request to the PCRF 16, which request includes the information for identifying the service context data (obtained from the SFC controller 18 in step 2). In step 4, the PCRF 16, together with SPR/UDR 24 (and/or other functions, if appropriate) performs a subscription check, using the information for identifying the service context data received in step 3. It will be appreciated that this step effectively corresponds to step 3 of Figure 8.

In step 5 (which effectively corresponds to step 4 of Figure 8), the PCRF 16 collects and correlates required information of the service context data. In step 6, the PCRF 16 performs (using the mapping function 45) mapping of the service context data 20 to a corresponding normalised SCI 21 , then conveys (in step 7) the normalised SCI 21 and an appropriate service data flow descriptor (e.g. an IP 5-tuple and/or application identifier) to the SFC-IW 17.

In step 8, the SFC-IW 17 performs (using the mapping function 45) mapping of the normalised SCI 21 to the appropriate technology-specific SSI 22 used in that (S)Gi- LAN 6. Once the mapping is complete, the SFC-IW 17 is configured to send (in step 9) the traffic steering information to the SFC controller 18. As generally shown in step 10, the functions of the (S)Gi-LAN 6 are configured to perform any necessary action(s) for instantiating and configuring the appropriate SFC for the given traffic flow. After step 10, any buffered data packet is retrieved (de-buffered) and forwarded by the ingress traffic classifier T to the appropriate SFC, then towards the egress traffic classifier T (through each appropriate service function for that traffic flow).

Operation - PCRF and SFC-IW co-located

Figure 1 1 illustrates another exemplary procedure using which the (S)Gi-LAN 6 can obtain traffic steering information from the core network 5. The procedure in this case is substantially identical to the example shown in Figure 10. Accordingly, the description of the steps of Figure 1 1 is omitted for simplicity. In this case, however, the SFC-IW 17 is co-located with the PCRF 16. Therefore, it will be appreciated that the PCRF/SFC-IW and SFC controller 18 may be configured to use (in steps 2 and 7), for example, a suitable DIAMETER-based interface, such as the so-called 'Rx' interface defined in 3GPP TS 23.203 V13.1 .0 (or a similar one). Modifications and Alternatives

Detailed embodiments have been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above embodiments whilst still benefiting from the inventions embodied therein. By way of illustration only a number of these alternatives and modifications will now be described.

The example illustrated in Table 1 shows each SCI as an index number. It will be appreciated that an SCI may comprise a "service number" (e.g. service#1 , service#2, service#N) and/or a "context number" (e.g. context-1 , context-2, context-N) and/or the like. Moreover, it will also be appreciated that an SCI may comprise other information than a numerical (e.g. binary) value. For example, an SCI may comprise a text value, such as a tag, a label, a service description, and/or the like. An SCI may also comprise a combination of a numerical value and other information.

In the description of Figure 9, the PCRF is described to send, to the TDF/SFC-IW, an appropriately formatted ADC rule (for detecting a particular flow) and associated traffic steering information (in step 5). However, it will be appreciated that the ADC rule and associated traffic steering information for a particular flow may be provided separately (in different steps). For example, the PCRF may send an ADC rule to the TDF/SFC- IW prior to arrival of a particular traffic flow (i.e. prior to the flow detection in step 1 ), in which case the PCRF may be configured to send in step 5 only the traffic steering information for any traffic flow detected based on that ADC rule.

In the above embodiments, a mobile telephone based telecommunications system was described. As those skilled in the art will appreciate, the signaling techniques described in the present application can be employed in other communications system. Other communications nodes or devices may include user devices such as, for example, personal digital assistants, laptop computers, booklet computers, wireless routers, web browsers, etc. As those skilled in the art will appreciate, it is not essential that the above described system be used for mobile communications devices. The system can be used to improve a network having one or more fixed communication devices as well as or instead of the mobile communicating devices.

In the above embodiments, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the node as a signal over a computer network, or on a recording medium. Further, the functionality performed by part or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the node in order to update its functionality. Similarly, although the above embodiments employed transceiver circuitry, at least some of the functionality of the transceiver circuitry can be performed by software.

The traffic steering information may be arranged for enabling said traffic to be steered to an appropriate LAN service function based on service data flow. The LAN service function may be an (S)Gi-LAN service function. The core network apparatus may comprise a policy and charging rules function, 'PCRF'. The means for generating may be operable to generate the message including traffic steering information based on at least one of: user subscription data; a radio access technology, 'RAT'; a network load status; an application identifier; a time of day; a user location; and an access point name, ΆΡΝ'. The means for generating may be operable to generate said message including traffic steering information based on at least one of: subscription data, terminal-specific information, network-specific information, user-specific information, and application specific information. The message including traffic steering information may be arranged for enabling said traffic to be steered using non-3GPP (e.g. ETSI NFV, OpenFlow, etc.) traffic steering function. The means for generating may be operable to generate said message including traffic steering information based on an application detection and control, 'ADC, rule (e.g. an ADC rule for detecting arrival of a traffic flow associated with an application). The means for generating may be operable to generate said message including traffic steering information following receipt of an indication that traffic has started or stopped (e.g. from a traffic detection function, 'TDF'). The means for generating a message including traffic steering information may be operable to map service context data to a service function chain in order to generate said traffic steering information that is arranged for enabling said traffic to be steered to an appropriate LAN service function. Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

Claims

Core network apparatus of a cellular communication system, the core network apparatus comprising: means for controlling traffic steering in a local area network, 'LAN': means for generating a message including traffic steering information for controlling said traffic steering; and means for providing said message to a functional node arranged to apply said traffic steering in said LAN based on said traffic steering information; wherein said traffic steering information is arranged for enabling said traffic to be steered to an appropriate LAN service function.

The core network apparatus according to claim 1 , wherein said traffic steering information is arranged for enabling said traffic to be steered to an appropriate LAN service function based on service data flow.

The core network apparatus according to claim 1 or 2, said LAN service function is an (S)Gi-LAN service function.

The core network apparatus according to any of claims 1 to 3, wherein said core network apparatus comprises a policy and charging rules function, 'PCRF'.

The core network apparatus according to any of claims 1 to 4, wherein said means for generating is operable to generate said message including traffic steering information based on at least one of: user subscription data; a radio access technology, 'RAT'; a network load status; an application identifier; a time of day; a user location; and an access point name, 'ΑΡΝ'.

The core network apparatus according to any of claims 1 to 5, wherein said means for generating is operable to generate said message including traffic steering information based on at least one of: subscription data, terminal-specific information, network-specific information, user-specific information, and application specific information.

7. The core network apparatus according to any of claims 1 to 6, wherein said message including traffic steering information is arranged for enabling said traffic to be steered using non-3GPP (e.g. ETSI NFV, OpenFlow, etc.) traffic steering function. 8. The core network apparatus according to any of claims 1 to 7, wherein said means for generating is operable to generate said message including traffic steering information based on an application detection and control, 'ADC, rule (e.g. an ADC rule for detecting arrival of a traffic flow associated with an application). 9. The core network apparatus according to any of claims 1 to 8, wherein said means for generating is operable to generate said message including traffic steering information following receipt of an indication that traffic has started or stopped (e.g. from a traffic detection function, 'TDF').

10. The core network apparatus according to any of claims 1 to 9, wherein said means for generating a message including traffic steering information is operable to map service context data to a service function chain in order to generate said traffic steering information that is arranged for enabling said traffic to be steered to an appropriate LAN service function.

1 1 . A functional node for applying traffic steering in a local area network, 'LAN', the functional node comprising: means for receiving a message including traffic steering information from core network apparatus of a cellular communication system; and means for applying traffic steering in said LAN to steer traffic to an appropriate service function of said LAN based on said traffic steering information. 12. A method performed by core network apparatus of a cellular communication system, the method comprising: generating a message including traffic steering information for controlling traffic steering in a local area network, 'LAN'; and providing said message to a functional node arranged to apply said traffic steering in said LAN based on said traffic steering information; wherein said traffic steering information is arranged for enabling said traffic to be steered to an appropriate LAN service function.

13. A method performed by a functional node for applying traffic steering in a local area network, 'LAN', the method comprising: receiving a message including traffic steering information from core network apparatus of a cellular communication system; and applying traffic steering in said LAN to steer traffic to an appropriate service function of said LAN based on said traffic steering information.

14. A computer implementable instructions product comprising computer implementable instructions for causing a programmable communications device to perform the method of claim 12 or 13.