This section presents access service creation systems based on the split architecture proposed in the project SPARC-FP7. It makes use of the SDN architecture combined with communications protocol OpenFlow. The project involved different research institutes, vendors, providers, and universities and therefore, there are numerous approaches that arise at the beginning of the project as well as ongoing research after its conclusion. It is not only restricted to BRAS system implementation but also other network technologies based on SDN/OpenFlow. Figure
ef{fig:SchematicSplitArchitectureOverview} shows a synthesized block diagram of the split architecture. It can be noticed three general functional blocks: the network management system, the hierarchical controller, and the forwarding/processing elements (data path elements). The split architecture accelerates a disjoint evolution of data plane and control plane mechanisms. The SPARC-FP7 project aims to increase the dynamic control of services and connectivity for carried networks citep{SPARCweb}. The first model presented in this section refers to a BRAS system implementation citep{kind2012splitarchitecture}. It presents a solution in which, through the application of the split architecture, an improved model for customer tunneling terminations at the BRAS system is obtained. It endeavors to remove the dependency of a single dedicated BRAS appliance. This approach proposes a separation between the data and control sessions of the customer tunneling protocol. It suggests shifting the control termination services of the BRAS system to an independent and specialized customer termination application, which can be able to handle the control sessions. The receiver application is in charge of the session management and the administrative information exchange with the BSS/OSS system (part of the network management system). In order to achieve this, when the flow creation process is triggered, the controller has to establish flows in the intermediate platforms to handle discovery encapsulated packets as well as session packets. This principle is shown in figure
ef{fig:Customer_tunneling_SplitArchitecture}. However, the author points out the necessity of an expanded OpenFlow protocol, in order to support specific processing functions in the data path elements that enable forwarding of control information towards the OpenFlow controller. Regarding the forwarding capabilities of the data path platforms involved, it states that each of them should enable identification of encapsulation tags on the packet’s header in order to allow the traffic to reach the core network. Although it gives an interesting outline on the topic, the absence of deeper technical implementation insights is evident. It argues that it is an early approach and there is ongoing research regarding the SPARC-FP7 project.The evaluation of SDN evolution and the implementation of technologies for distribution of the systems that target the creation of access services towards the subscribers are presented in citep{woesner2013sdn}. This paper evaluates the distribution of access services in three steps namely, OpenFlow BRAS prototype, OpenFlow in the Access Aggregation and passive optical network (PON) and OpenFlow in the home router. Concerning to our topic, the BRAS system prototype, named in this approach as OpenBNG, consists of an OpenFlow implementation based on the Revised OpenFlow Library (ROFL). Just as the previous approach, it intends to separate the discovery packets from the session packets. The first ones are forwarded to the BRAS control plane which is in charge of providing the session configuration negotiation, ending with the customer session establishment. Onwards, the second packets are handled by the data plane. There are a number of issues revealed by this paper such as the per-session state, which is handled as stateful action in OpenFlow. As an improvement solution, the use of virtual ports for the state encapsulation is proposed. Another problem exposed is lack of device management by the current versions of OpenFlow. It is evidenced that the paper does not include information about the complete operation of the session creation, modification and termination.  Continuing with its research in citep{woesner2015sdn}, the author presents a demo that shows the migration from two types of access protocol technologies. It argues that providers are looking forward to increasing the use of pure layer 3 encapsulation solutions in order to slim down the protocol stack used for access service creation. Thus, using the architecture resulting from the project UNIFY-FP7, the decoupling of the service session control and the infrastructure is done. Between the “control function” and an external orchestrator, the creation and removal of services are enabled. To test the environment, it runs first a Network Function-Forwarding Graph (NF-FG) in the local orchestrator which initiates the DPDK functions, the docker containers, and the controller application. The system runs a relay DHCP function and according to new client requests (named first sign of life), either are attended by the DHCP module (layer 3 encapsulation) or a new virtual layer 2 encapsulation instance. Doing so, BRAS services are spawned on demand only to certain legacy customer premise equipment (CPEs). Figure
ef{fig:Demo_BRAS_DCHP} shows an overview of the demo setup.The approach in citep{john2014splitarchitecture} applies a combination of the Split-Architecture and layer 3 classical network protocol services. It attempts to solve the problem of residential internet access service, which employs specific session control protocols, through the use of split architecture. It uses two controllers, one internal and one external (centralized). The external controller contains a module steering function, which belongs to the BRAS system, whose function is to react to client requests. When the customer premise initiates a negotiation request (discovery packet), it is intercepted by the access platform (part of the BRAS data plane), which forwards the packet to the centralized controller in order to be processed by the steering functional block. As a result, a decision is taken over which previously-enabled BRAS control and data path platform will handle the request. Notice that, the chosen element deploys both functions the data path forwarding capabilities and the internal BRAS controller. To achieve communication between the selected platform and the end user, a pseudowire is created between the chosen platform and the access node that face to the client. After the negotiation is performed the central BRAS controller relays the discovery packet to the chosen local BRAS platform. When the packet arrives, the access service negotiation phase is resumed between BRAS data path platform and customer premise carried out through the established tunnels. Thus, the enabled BRAS data path element provides session control, management of customer IP addresses, and routing of customer packets. This process is observed in figure
ef{fig:IP_MPLS_approach}. The external BRAS control plane realizes three major functions: establish and maintain tunneling transport services between any two nodes of the network; control the provided residential IP service; and optimize service creation and transport services. The local BRAS controller appended to the respective data path is conceived as a cascade of two controllers: one for the layer 3 and one for the layer 2 control processing. Both implement internal and external functions to provide the label switched paths (LSPs) and the pseudowire endpoint (PWE) based on the network transport protocol. Figure
ef{fig:BRAS_hierarchical_control} shows the functional modules for a local appended BRAS controller.Regarding the scalability issues for the BRAS control plane and data plane implementation in the approaches considered in this section, the last suggest a solution towards the mapping of BRAS control plane functionalities to a defined number of data path elements in such a way that scalability can be achieved in the same way as elements in the customers data path are added. The rest of the approaches do not consider scalability as the main issue and therefore no further information is provided. Thus, no approach presents a solution on how to scale the number of sessions that are handled in each one of the BRAS data path elements.