Decentralized fiber network access system

Abstract

There is disclosed a new approach to providing fibre network access by introducing a decentralized platform within premises. At its core, the system accommodates applications from multiple vendors, providing customers with a seamless interface to access bespoke speed and bandwidth options directly from the vendors via dynamically implemented Ethernet Virtual Private Line (EVPL) connections. Key features include: Premises-Based Platform: establishing a premises-based platform where vendors can host their applications, ensuring proximity and performance for end-users. Dedicated Fiber Interface: Each application hosted on the system is allocated a dedicated fiber interface at defined speed, reliability, and security. API-Driven Connectivity: EVPL connections are facilitated by an API-driven software system, enabling seamless communication between customers and vendors without reliance on intermediaries. Bespoke Speed and Bandwidth: vendors can offer tailored speed and bandwidth options for their applications through the system, accommodating diverse user requirements and applications such as gaming, video conferencing, streaming, and more. Direct Connection: By bypassing the traditional ISP model, the system facilitates direct connections between customers and vendors, eliminating bottlenecks and enhancing overall network performance. Revenue Model: a novel revenue model by charging vendors for access to the platform, incentivizing competition, innovation, and service quality improvements. Network Optimization: The underlying fiber network infrastructure is designed to accommodate varying bandwidth requirements. An API-driven system allocats network bandwidth, ensuring efficient utilization and maintaining backhaul below 70% of the total bandwidth requirement.

Description

[0001] Decentralized Fiber Network Access

[0002] The present invention concerns novel methods and systems for delivering services to users over a fiber infrastructure network.

[0003] Network vendors own and operate the network infrastructure and assets that define a fiber network with internet connectivity at a location known as the Internet Xchange Point (IXP). In the current landscape of fiber network infrastructure, the prevailing model entails a single fiber connection to premises at which users are located, e.g. homes, offices, etc. Access to the network is made available by an Internet Service Provider (ISP) designated by the network provider, providing the system by which users and vendors pay for their respective connection. It is conventional for a single payment or subscription to confer a guaranteed minimum bandwidth of the connection such that any services can be accessed by users over the network, provided the bandwidth is available.

[0004] This conventional arrangement effectively confers control over internet access to the ISP. In the event that only a single ISP existed, the conventional arrangement would lead to monopolistic control over user access to the internet. Even in the event that multiple ISPs are available, the conventional arrangement often leads to limited choice, constrained bandwidth availability, and pricing inflexibility for both end-users and vendors.

[0005] Furthermore, users typically pay for access regardless of the extent to which they actually use the bandwidth available to them, or what they use it for. Access to the internet via the ISP infers that it is a shared service. Many users experience bottlenecks, where more- important services are inaccessible or unusable because the bandwidth available to the user is insufficient or because another service (e.g. download or upload of data) being accessed concurrently by the user is reducing the bandwidth available to the more- important service.

[0006] Access to online content or other services over the internet is paid for separately from the arrangement between the user and ISP, i.e. with those services being layered on top of the basic cost of accessing the internet. Content vendors may offer a variety of different payment models for access to their service by end users over the internet, including advertising models whereby advertising revenues paid to the service provider may negate or reduce the need for direct payment by the end user. However, the experience of the service by the end users remains constrained by the end users’ access to the internet via the ISP due to network architecture models where multiple ISPs often share backhaul from the wholesaler causing additional latency and network contention. This can be frustrating to both the service provider and end user, whereby two different users can have very different experiences of a service according to their respective connections to the internet.

[0007] This mismatch between the intentions of user or service provider and the service actually provided (based on the internet connection made available to them) has become stark over recent years given the ubiquity of SaaS and streaming models for accessing content online, which typically require consistent bandwidth for an adequate user experience. Current examples include streaming of television or video games, where a user can be paying for a premium experience from both an ISP and service provider and yet still experience inadequate or inconsistent access to the streamed content.

[0008] It is an aim of the present invention to resolve or mitigate one or more of the aboveidentified problems. It may be considered an additional or alternative aim to remove or mitigate constraints on content / service delivery caused by ISPs.

[0009] Statements of Invention

[0010] According to an aspect of the present invention, there is provided a method of facilitating online services between a user and vendors over an optical fiber network, the method comprising: providing a portal having a connection to said network over which the portal may communicate with a plurality of vendors, said connection having a network capacity; establishing an Ethernet Virtual Private Line (EVPL) connection over said network between the portal and each service provider, wherein each said EVPL connection is assigned a defined bandwidth and / or speed; partitioning the network capacity such that separate channels are defined for connection with each of the plurality of vendors via the EVPL connections; delivering the service by each respective service provider over each said channel by data transmission in accordance with the assigned bandwidth and / or speed.

[0011] The EVPL connection may be defined within the optical fiber network at the data-link layer and / or network layer. The defined bandwidth and / or speed may be a bandwidth and / or speed threshold, capacity or limit. The separate channels typically each account for a portion or minor portion of the network capacity of the portal connection, i.e. the Ethernet network capacity being subdivided logically as a plurality of EVPL connections. The console may monitor the currently established EVPL channels with the plurality of vendors and may permit or deny establishing one or more further direct EVPL connection. The console may permit or deny establishing further direct EVPL connections according to the network capacity or another limit.

[0012] The establishing of an EVPL connection / service may be performed in response to a user request for a service from one or more of the vendors. The establishing of the EVPL may be performed dynamically. The initiation of a new channel may be restricted by the overall capacity of the backhaul link, e.g. which is known as a point to point (P2P) Ethernet Virtual Connection (EVC)

[0013] The establishing of an EVC or EVPL may be performed by a management system, which may be a cloud-based system. The management system may comprise a software defined network (SDN) controller.

[0014] The management system may comprise an API-based controller to communicate with the underlying hardware infrastructure to be able to direct network traffic on the network. The management system may control / automate network configuration for routing of direct EVPL connection(s) over said network.

[0015] The (management) system may comprise an optical distribution node / core. The (management) system may comprise a datacentre in communication with the optical distribution node.

[0016] The (management) system may comprise a datacentre in communication with an internet exchange point with one or more service provider.

[0017] Establishing the EVPL connection may comprise provisioning the EVPL connection. Provisioning / establishing the EVPL connection may be performed automatically in response to, or based upon, a request from the portal. The request from the portal may initiate provisioning of the EVPL connection. The request from the user may be sent to the management system. The request from the portal may comprise data link (layer 2) and / or network / internet layer (layer 3) specifications. The request from the portal may comprise scripts, e.g. for layer 2 and / or layer 3 specifications.

[0018] The portal may comprise a user device or console, e.g. running software for implementation of a user interface for access to the portal.

[0019] Establishing or provisioning of the EVPL connection may be implemented by an edge-to- core provisioning process. The EVPL connection may comprise a direct channel connection or tunnel between the user device or network connection and the vendor.

[0020] The portal may comprise a user switch or be in communication with a core router, e.g. a small switch at the user premises to initiate the layer 2 EVPL service. The core router enables network layer routing protocols such as Border Gateway Protocol (BGP) to ensure connectivity to vendors on the portal. The portal may contain the necessary API packages to build EVPL and network layer protocol services.

[0021] The portal may comprise software applications (apps) for accessing each service provided by each of the plurality of vendors. Initiating the app for a service may initiate a user request to establish the EVPL connection with said vendor (service provider) and / or partitioning of the network capacity.

[0022] The user may be presented with a simple interface or operating system for selecting / opening apps in a conventional manner. Selecting / opening the app may thereby initiate the EVPL connection, e.g. without requiring separate user actions.

[0023] The EVPL connection between the user and service provider may be implemented by a network layer routing protocol such as BGP supported by Internet Protocol Security (IPsec)

[0024] Different bandwidth and / or speed may be assigned to different apps. This is may be achieved according to the service or app type assigned to the vendor application. Historical app usage information and / or information made available by the service provider. Using the invention, each app hosted in the system can be allocated a dedicated EVPL service across the fiber, ensuring optimal performance and reliability. Additionally or alternatively, access to services over the internet can become decentralized in that the ISP can be bypassed entirely by the bespoke EVPL and network layer BGP connections, providing a dedicated connection with the vendor content.

[0025] The novel approach to delivery of services over the internet allows for an associated novel payment system. The novel revenue model may be enacting by charging vendors for access to the platform, e.g. rather than paying separately for internet connection through an ISP. Vendors may be charged for delivery of services over the optical fibre infrastructure based on usage or subscription fees. The cost charged to vendors may be tied to the bandwidth and / or speed needed for adequate delivery of the associated service.

[0026] The user may ultimately pay for the connection to the vendor (content service provider) as part of the cost of the service itself (e.g. as a subscription fee to the service provider or a fee associated with individual purchases, other transactions, downloads, uploads or the like).

[0027] Accordingly, users need pay only for the connection needs associated with the apps they actually use, rather than paying for an ISP service that may not suit their specific needs.

[0028] The EVPL connection between the portal (s) and vendors may be established through core routers and customer switches of the fibre optical infrastructure network . This may be provisioned, controlled or established by the management system.

[0029] The EVPL connection may be facilitated through use of an API software system to allocate network bandwidth between the user and vendors

[0030] EVPL connections between the portal(s) and vendors may be facilitated using a software defined network controller, e.g. according to network platform API’s. The network controller may perform any, any combination or all of the following in relation to routes for the EVPL (e.g. and BGP) connection between the portal and service provider: requesting routes; updating routes; provisioning routes; committing routes; validating routes; deploying routes. The EVPL connection may be provisioned / established using an edge-to-core or inverse direct connection process. An initial step of said process (e.g. in response to a user request) may comprise generation of Layer 2 and / or Layer 3 scripts for the direct connection, which may be generated by the portal.

[0031] The invention may establish a premises-based software platform for accommodating apps from multiple vendors, e.g. based at the user premises, such as within the home or business.

[0032] According to a second aspect of the invention, there is provided a system for facilitating online services between a user and vendors over an optical fiber network, the system comprising: a portal having a connection to said network over which the portal may communicate with a plurality of vendors, said EVPL connection having a network capacity; a management system arranged to receive an initiation request from the portal for access to an online service from one of said vendors; the management system arranged automatically to establish a EVPL connection over said network between the portal and the vendor service provider, wherein said EVPL connection is assigned a defined bandwidth and / or speed; the portal partitioning the network capacity in accordance with the established EVPL connection for delivery of the online service to the user.

[0033] According to a third aspect of the invention, there is provided a management system for establishing / provisioning EVPL connections between portals and vendors over a fiber network, the management system being arranged to receive an initiation request from one or more of the portals for access to an online service from one or more of said vendors, the management system arranged automatically to establish an EVPL connection over said fiber network between the portal and the service provider, wherein said EVPL connection is routed through the fiber network and assigned a defined bandwidth and / or speed for delivery of the online service to the user.

[0034] According to a fourth aspect of the invention, there is provided a portal for use in any preceding aspect.

[0035] According to a fifth aspect, there is provided a portal for use in facilitating delivery of online services over an optical fiber network between a user network connection and vendors, the portal having: a user interface by which a user can select a service from a vendor; wherein the portal outputs an initiation request to a management system to establish an EVPL connection over said network between the user network connection and the service, wherein the initiation request comprises data link (layer 2) and network / internet layer (layer 3) specifications for the EVPL connection, such that the EVPL connection can be established automatically in response thereto, e.g. according to an edge-to-core provisioning process.

[0036] The request from the portal may comprise scripts, e.g. for layer 2 and / or layer 3 specifications. The initiation request may allow a defined bandwidth and / or speed of the EVPL connection to be established.

[0037] The user may select the service as an app presented in the interface. The user interface may comprise a browser.

[0038] The portal may partition the network capacity at the user network connection based upon the established EVPL connection, e.g. such that separate channels can be defined for connection with each of a plurality of vendors.

[0039] According to a sixth aspect, there is provided a decentralized fiber network access platform, comprising: a premises-based platform, configured to accommodate applications for online services from multiple vendors; a single dedicated fiber interface comprising of multiple logical EVPL interfaces for each application hosted on the premises-based platform; a user interface console allowing customers to select vendors directly; a management system comprising an API-driven software system facilitating direct connections between customers and vendors.

[0040] An associated revenue model may charge vendors for access to the platform. The revenue model charges vendors based on usage or subscription fees.

[0041] The single dedicated fibre interface may allocate varying speeds and bandwidth options by way of logical EVPL services for each application.

[0042] The API-driven software system may optimize network bandwidth allocation to maintain backhaul levels at variable total bandwidth requirement.

[0043] The direct connections or EVPL connections between users and vendors may bypass an Internet Service Provider. There may be provided an interface connection which does not rely on router connectivity but instead provides direct connected connection through fiber for that service provider. Instead of a conventional router installation, there may be user device installation such as a small switch that allows data-link paths to be initiated. In the case of network routing, additional API requests for the network layer routing may be deployed by the SDN controller of the management system triggered by requests from the portal

[0044] Optional features defined above or hereinbelow in relation to any one aspect of the invention may be applied to any further aspect, where practicable.

[0045] Overview of the Drawings

[0046] The invention may allow a platform for decentralised connectivity between users and vendors (service providers) through a novel interface portal, referred to herein generally as HYPERPORTAL™. Practicable embodiments of the invention are described in further detail below by way of example only with reference to the accompanying drawings, of which:

[0047] Figure 1 shows an overview of the seven layers of the Open System Interconnection (OSI) Model and corresponding layers of the TCP / IP Model according to the prior art;

[0048] Figure 2 shows an overview of a system according to an example of the present invention for establishing connection between a single user and service provider;

[0049] Figure 3 shows a schematic overview of the process between the user and connection management system for establishing direct connection between the user and service provider;

[0050] Figure 4A shows a schematic the service provider side of a network;

[0051] Figure 4B shows a user side (edge) of the network example of Figure 4A;

[0052] Figure 5A shows a certain hardware features for the cloud hosting system;.

[0053] Figure 5B shows a certain hardware features for the user system;

[0054] Figure 6 shows a schematic arrangement of multiple core sites within a single SDN domain belonging to a single provider’s fibre infrastructure network;

[0055] Figure 7 shows an example set of specifications including Yang model;

[0056] Figure 8 shows the OSI model levels in the context of the present invention. All OSI layers are used from L1 Physical to L7 Application, however in the context of initiating network service intents, the illustration shows L2 and L3 only;

[0057] Figure 9 shows a schematic of a user interface for the portal. Detailed Description

[0058] Turning to figure 1 , there is shown a conventional explanation of the different levels associated with the OSI model, which can be explained as follows: The layers of Figure 1 are represented alongside the corresponding layers of the TCP / IP Model to show equivalency. The models are well known in the art to explain the layers of technology needed for delivery of application layer services over the internet, i.e. via data packets. Various protocols are associated with different layers and standard terminology relating to components being used herein, such as: routers in the network / internet layer for verifying IP header information and making forwarding decisions based thereon; and switches or bridges in the data link layer for receiving a stream of bits from the physical layer and checking the entire frame has been received before forwarding to the appropriate destination based on the available address.

[0059] The above table outlining the logical order of implementation for services starting at Layer 1 (physical) L2 data link, L3 routing etc. Layer 4 defines e2e transport comms, layer 5 to 7 establishing a session via API etc.

[0060] The concept for HYPERPORTAL described herein is based at least in part upon the concept of automating the establishment of Layer 2 for an EVPL service and layer 3 BGP connection reaching the vendors, e.g. in reverse of a conventional sequence. For example, its critical User Acceptance Testing (UAT) may be prioritised before integrating the application. Additionally or alternatively, infrastructure may be validated and optimised before the application, save on rework, integration or stability issues. Further explanation will be provided below.

[0061] Turning now to Figure 1 , there is shown a basic process overview for an example implementation in which HYPERPORTAL is implemented as a cloud service 10 for managing connections between parties providing / receiving EVPL services via over a fibre infrastructure network, also known as an optical transport network. The network diagram 12 illustrates a series of routers which demonstrable in part to how layer 3 BGP routes will traverse a wider area network to reach the target server i.e. vendor 18.

[0062] End users of the system are represented in this example by user 14, having a user device or application portal 16 through which they can initiate a connection required for accessing an online service. The user device 16 may be referred to as a software application portal. The service, software application or vendor in this example is represented by a target server 18, i.e. a server or server system through which the service is provided by communication with user devices.

[0063] The user device 16 runs software enabling communication with the HYPERPORTAL cloud service 10 such that it can serve as a connection management system or portal for establishing a EVPL connection between the user device 16 and any target servers 18 when the user desires to access the relevant service online.

[0064] The cloud-based management system 10 runs on a core optical transport network within a fibre infrastructure domain, providing necessary layer 2 EVPL services. To reach vendor services beyond the optical transport network, the SDN domain controller uses BGP routing by way of peering agreements with additional cloud providers to traverse other Autonomous Systems (AS) and may use Multi-Hop BGP (MH-BGP) to help facilitate connectivity with the vendors target servers 18. The cloud based system 10 comprises Business Support System 20, which encompass software systems arranged to handle customer / user facing services, including any or any combination of: user account / profile management (e.g. whereby a user can input / update ID and other account details); order management; billing; revenue management; and / or, user relationship management, using API plugins with the HYPERPORTAL software application.

[0065] User profile data may be communicated with Operational Support Systems 22 of the HYPERPORTAL cloud service, which may monitor, control and manage the relevant communication network. This may include ordering / tracking addresses, analyzing network traffic and / or handling service quality, fault management and reporting. There may be a connection with the existing infrastructure providers network to integrate and manage the OSS depending on the size of the customer network. This way the core domain, with plugins to BSS and OSS can be managed in terms of capacity management without overloading or straining the HYPERPORTAL software application.

[0066] The OSS 22 communicates with a Software-Defined Networking (SDN) controller 24, e.g. using application programming interface (API) commands. The SDN controller 24 uses Southbound Interfaces (SBIs) APIs to communicate with the underlying hardware infrastructure to be able to direct network traffic on the network. This enables dynamic, responsive and efficient network configuration. SDN enables the cloud service 10 to program and automate network functions, making it easier to manage the network. When a user 14 requires a connection to a service provider 18, the HYPERPORTAL service 10 can thus process the request and establish the dedicated routing of the channel between the user and service provider over the fibre infrastructure network and wide area network handling network routing via protocols such as MH-BGP. In Figure 2, this is shown simply by controlling layer 2 and layer 3 packets forwarding back / forth between the user and service provider 18 over the routers 26 that exist in the wide area network.. P4 is used to define custom behaviour for control plane routing undertaken by the SDN controller. Since the SDN controller only exists within the realms of a fibre infrastructure network, P4 is not generically used to define layer 3 routes. Setting up routing between the SDN and peering partners facilitate service routing.

[0067] Once the EVPL connection has been established in this manner by the HYPERPORTAL service 10, the user console 16 and target server 18 can communicate over a dedicated bandwidth / speed connection for unimpeded service delivery. It is important to note that this automated process for provisioning orders / requests for connections over fiber-based networks by the HYPERPORTAL service using API-based software processes differs significantly from conventional processes for provisioning internet service products both in terms of time, efficiency and automation.

[0068] Turning now to Figure 3, further details of the user device 16 and cloud system 10 are shown in order to describe the process by which direct connections can be established in response to user-initiated requests. The user in this example is represented as a premises / building 28 at which the user is located, e.g. which my itself have a local network and multiple devices connected thereto, of which the device 16 user console is one. The user may comprise an individual or organisation, e.g. being a user / customer or service provider itself.

[0069] The application running on the user device 16 presents a user console interface through which the user can select a service provider. This may be achieved through the selection of icons 30 or the like in a conventional manner, akin to opening an app. Indeed, the app selected may be the application the user desires to use, but which action may initiate the process of establishing the connection required for use of the app. The available options (vendors) may thus be presented to the user in a simple graphical interface so that the user only needs to select the relevant option to initiate the connection provisioning service. It is useful now to define what would be a conventional process for provisioning a fiber based network connection for a user / business which would typically involve the following:

[0070] 1 . Sales Consultant raise order request to Solutions & Feasibility team.

[0071] 2. Solutions & Feasibility team raise new order request with Order Management & billing.

[0072] 3. Order Management raise new order and assigned Project Manager.

[0073] 4. Project Manager manages deployment with Architecture Design and Network Operations team(s)

[0074] 5. Feasibility team send indicative high level view of delivery to Architecture & Design team.

[0075] 6. Architecture team validates the service and provides a design to Project Manager

[0076] 7. Network Operations team / s provision new Layer 2 Ethernet Service and Layer 3 IP service from internet router.

[0077] The core-to-edge lead time for this process is typically approximately 30-90 days and involves a highly manual process to the extent that it is unworkable in the dynamic / reactive context of the present invention.

[0078] Now, turning to Figure 3, the network provisioning process for establishing the direct connection from the user premises / device 16 to a service provider over the network can be defined as follows:

[0079] STEP 1 : User or Business requests new service which facilitates the Inverted Direct Connection (IDC) process

[0080] STEP 2:

[0081] (a) Layer 2 and Layer 3 scripts 32, 34 are sent via a plurality / series of API's; each request is sent into the network, checked, configured and deployed.

[0082] The following jobs roles are there to monitor the network and support workflow operations. The APIs and service turn-up process is automated:

[0083] (b) SE - Software Engineer - Monitors how the APIs interact with the HP application

[0084] (c) OE- Optical Engineer - Monitors and checks the capacity of physical fibre layer and Layer 2 ethernet services.

[0085] (d) Network utilization & service planning also implemented via the APIs (e) NE- Network Engineer - Monitors L3 IP services and BGP routing via platform and cloud provider.

[0086] (f) NO - Network Operations - Review service build statuses, provide fault analysis, mitigation and resolution from NOC Network Operations Control.

[0087] All the above steps can be implemented automatically and / or dynamically by software processes without human intervention, or with minimal human intervention. This leads to a novel edge-to core process (i.e. the inverse of a conventional core-to-edge process that would terminate in Layer 2 and 3 outputs at step 7 at the end of the process). The SE, OE, NE and / or NO steps can be agent / software-based, e.g. with the necessary auditing / logging of actions taken and / or reports / resolutions generated.

[0088] Further details of this process can be defined in an example sequence of operation as follows:

[0089] - User selects content or service to access on HYPERPORTAL app User secure authentication API communication to SDN controller Using network platform APIs at the SDN controller: o Level 2 and level 3 ethernet path computation and validation o Request routes o Update routes o Provision routes o Commit routes o Validate routes o Deploy routes

[0090] - Content / service provider connected at internet exchange point to routes

[0091] - ‘Chanellized’ layer 2 ethernet service committed at defined bandwidth / speed (e.g. according to service / content provider agreement)

[0092] Layer 3 defined QoS policies provisioned over Layer 3 using core dedicated internet access link to service / content provider

[0093] User device receives content or service over dedicated connection.

[0094] In various aspects of the invention the relative sequence of any two or more of the above steps may be used to define the connection provisioning sequence in accordance with the invention. The deployment lead time for provisioning of the connection in accordance with examples of the present invention can be almost instantaneous, e.g. in the order of seconds as compared to the manual conventional process. When it is considered that each service provider and each user would need to go through a conventional provisioning process, the extent to which the present invention allows an entirely different method providing services over the internet is clear. By implementing an edge-to-core provisioning process, starting with definition of layer 2 and / or layer 3 specifications using scripts and / or an APIbased system, the process can be automated and reactive to individual user requests.

[0095] Turning now to Figure 4A, there is shown a plurality of vendors A-K arranged to provide services using the system / process described herein. Connections by the vendors may be defined according to Border Gateway Protocol (BGP), i.e. to exchange routing and reachability information between autonomous systems. The Level 3 BGP routes are thus supported by the cloud connection management service provider 10.

[0096] It can be seen that only certain vendors A, G and J are actively connected to provide services concurrently. For each connected service, a dedicated Autonomous System (AS) is provided, i.e. a network or group of networks having a unified routing policy. For service provider A, this is denoted as using AS1 ; for service provider J, this is denoted as using AS2; and, for service provider G, this is denoted as using AS3. Each AS may be defined / established in terms of its interior Border Gateway Protocol (iBGP) in contrast to the internet application of the protocol, Exterior Border Gateway Protocol (EBGP).

[0097] The establishment / management of the connections is defined in Figure 4A with respect to an infrastructure provider distribution node. This refers to the core or network provision / management service in the cloud, which encompasses the aforementioned software defined network (SDN) platform labelled 36.

[0098] Turning now to Figure 4B, the premises 28, representing the user(s) of the online services, are at the edge. In this example, different user devices 16A, 16G and 16J are accessing the services of vendors A, G and J respectively. As such each device has its own EVPL and BGP route to each respective service provider, labelled 38A, 38G and 38J respectively. As such it can be seen that the user device 16 may be an individual device, intended to receive the online service itself, and / or a managing device arranged to serve as a local router or console for devices on a local network, e.g. managing requests for connections for other devices. The user device or user console 16 may be referred to as a software application portal.

[0099] The user device 16 has embedded scripts for the physical, datalink and / or network layers to initiate the inverse ‘edge-to-core’ provisioning of ethernet and IP service. The resulting direct communication channels may each comprise an Ethernet Private Line (EPL) or Ethernet Virtual Private Line (EVPL). Each EVPL connection is scalable individually in terms of bandwidth / speed as well as being secure and reliable. Where EPL may provide point-to-point connectivity between two locations, e.g. connecting a pair of dedicate user network interfaces, EVPL can enable multiple Ethernet Virtual Connections (EVCs) per user network interface to support point-to-multipoint (P2MP) connectivity.

[0100] In this manner EVPL uses a combination of service multiplexing and bundling, effectively bundling multiple services (vendor connectivity sessions). They are transported via the same Ethernet backhaul through an Ethernet Virtual Connection (EVC) e.g. a 10G customer to core. However each session in mb or gb works independently of each other and can be configured as required.

[0101] As can be seen in Figures 3 and 4B, the system allows different devices 16A, 16G and 16J at a premises and / or sharing the same network connection point (according to the user console 16) to have different, dedicated connections established with the same or different vendors A, G and J, so that each device has the guaranteed bandwidth and speed it needs for the online application being used. In this manner, different user devices could be running different sessions concurrently with the same vendor or could each be running one or more sessions concurrently with different vendors.

[0102] In contrast to conventional internet service delivery in which the vendors would transparently use the provisioned Layer 2 ethernet connection to reach applications running at the edge, the invention as exemplified in Figures 4A and 4B means that vendors do not transparently use the layer 2 ethernet connection made available. As depicted in Figure 4A, the Layer 2 connection effectively seen by or ‘terminates at’ the core SDN platform 36 of the cloud service 10.

[0103] Figure 5A shows further details of the centralised cloud hosting system 10 in terms of infrastructure. The system 10 having a datacentre 40 connected to Internet Exchange Point (IXP) 42, defining a physical location at which the content / service provider(s) 44 and cloud system 10 can exchange internet traffic directly. The datacentre 40 is connected to the core optical fiber distribution node 46 and allows multiple signals (data streams) to undergo multiplexing, i.e. at a multiplexer, so as to be combined into a single signal for transmission over a single fibre line 48. Optical signaling and encoding is provided, e.g. for channel rate of 100Gb / s.

[0104] In this example, there are multiplexed fibre connections where each could represent 100G Wavelength (or more) per fibre pair, with the 100G link into an IXP to facilitate network vendor peering.

[0105] Fiberoptic lines of multiple wavelengths, X, may be used e.g. between 100G-400G per X.

[0106] Turning to Figure 5B, there are shown further details at the user / receiver end, for example comprising an access node or street cabinet, whereby fiberoptic signals are received and distributed to end uses, e.g. premises. The single fibre line 48 signal undergoes demultiplexing, i.e. at a demultiplexer, and are separated and routed to the relevant receivers for processing. A suitable router 50 of the core optical platform may provide Level 1 , 2 and 3 low latency switching. In this example there is WiFi (RTM) uplink using a WiFi Layer 2 switch 52, e.g. for separate hotspot zones. End users may thus send / receive over wired / ethernet or wireless connections.

[0107] The router 50 is associated with an Optical Line Terminal (OLT) converting electrical signals to optical signals for downstream transmission and vice versa for upstream transmission, thereby managing traffic between the service provider and end users.

[0108] As shown in Figure 5B, any conventional fiber connection at the user end may be accommodated, including Fiber to the Cabinet, Fiber to the Home, Fiber to the Premises, Fiber to the Building, etc. A suitable Optical Network Unit (ONU) 54 converts optical signals from fiber optic cables into electrical signals, allowing users to access the services provided.

[0109] The main / user device in Figure 5B shows the multiple fibre connections at 10G towards different fibre deployment applications, any of which are able to use HYPERPORTAL.

[0110] It is to be noted that the arrangement of an infrastructure providers core SDN platform 36 or cloud entity 10 as shown in Figures 3, 4 and 5 is a single example for simplicity of explanation. In working systems, a core network 10 may span a plurality of locations nationally or internationally, e.g. as shown in Figure 6, in which the core network comprises a plurality of platform locations 36A-D residing within an SDN, which are connected at a L1 and L2 infrastructure and data link level. This illustration demonstrates Layer 1 (fibre) and Layer 2 (Ethernet-EVPL) connectivity.

[0111] In the arrangement of Figure 6, the layer 2 ethernet EVPL can be transported across the Layer 1 optical infrastructure. Any L3 beyond the optical domains can use BGP towards the vendors (service providers).

[0112] A HYPERPORTAL zone architecture and topology can easily change from zone to zone and scaled from the Core Distribution Node (datacentre) depending on network analytics.

[0113] The fibre optical network underlying HYPERPORTAL is meticulously designed and built to accommodate varying bandwidth requirements from the portal. API-driven software ensures efficient management of total bandwidth, with backhaul always maintained below 70% of the total bandwidth requirement to guarantee optimal network performance.

[0114] Using the example systems described above it is possible to build Layer 2 Ethernet and Layer 3 QoS services using a combination of API calls from a Network Management System. For API's to interact with the HYPERPORTAL application, in this example they conform to a data structure used in API packaged formats understood by the fibre infrastructure providers network. This may be Yang models that describe the schema. Yang - is represented in a data tree structure with nested data. It provides definitions and constraints for network configurations.

[0115] As Yang models are readily available across Layer 2 and Layer 3, whether an ‘openconfig’ (vendor neutral) model or a vendor specific model, the structure of the data models can be quickly deployed.

[0116] There are different ways network configurations can be implemented that can change across vendors. The common encoding types are XML and JSON data formats. An example is shown in Figure 7.

[0117] The Yang model is a data modelling schema, whereas different configuration protocols can be used such as Netconf for defining network configurations with XML data formats, or Restconf which uses a RESTful API using a JSON data format. Configurations can change across fibre network infrastructure domains, however using open language models allows HYPERPORAL to communicate with any such format.

[0118] Ultimately, Yang models are an open standard, similar to other organisations like IETF, TeleManagement Forum (TM Forum), Metro Ethernet Forum (MEF), OpenConfig and Open Network Foundation (ONF) The term “open” in this context means the models are freely available, vendor neutral and machine readable. Some organisations utilise open standards, others create proprietary models and some take a hybrid approach. Hyperportal integrates the user console software with said organization's specific protocols according to their API architecture topology.

[0119] Returning now to the OSI Model levels as discussed herein, Figure 8 shows the context of the HYPERPORTAL application and the overall system in relation to the OSI levels. The fibre network architecture represents the physical, Layer 1 infrastructure, capable of reaching terabit data rates depending on the optical core transport that powers the network.

[0120] Layer 2 encapsulates Ethernet payloads, while Layer 3 handles IP protocols, enabling Virtual Private Network routing (VPN), Quality Of Service (QoS), and traffic shaping across the connected network.

[0121] Moving up the layers, after successful transmission at Layer 4, and establishing a connectivity session at Layer 5, the presentation layer (Layer 6) defines the data format that interacts with the application layer (Layer 7).

[0122] The HYPERPORTAL application is accessible to customers via WiFi or a desktop application, providing access to enterprise customers and ISP vendors. HYPERPORTAL facilitates these services by building bespoke, EVPL services at Layer 2 across the optical network, and by encoding Layer 3 bandwidth services accessible to the client, using open, standardised APIs and data formats where applicable and / or available.

[0123] Discussion of Benefits, Developments and Implementations

[0124] The HYPERPORTAL system emerges as a groundbreaking solution to the problems associated with ISP-based service delivery, introducing a novel interface for a user portal that revolutionizes fiber network access. Unlike conventional setups where all requirements must pass through the contracted ISP, HYPERPORTAL empowers vendors with direct access to end-users, unrestricted by ISP constraints. Through the HYPERPORTAL interface portal, vendors can offer bespoke speed and bandwidth options tailored to individual customer needs.

[0125] HYPERPORTAL leverages network layer automation and user authentication to integrate content providers with the application, enabling on-demand activation of content services. This represents a breakthrough in combining multiple technologies to deliver a wide range of content services.

[0126] Businesses can gain exclusive access to FTTx with dedicated bandwidth for themselves and their customers, a concept that was previously unavailable. Moreover, alternative networks and providers can utilise the HYPERPORT application as a service, leveraging its custom application and Open network automation scripts for API integrations.

[0127] HYPERPORT introduces a unique model that transforms traditional connectivity. By enabling premises connected to the network to deliver dedicated, high-quality bandwidth services directly to users at the edge, HYPERPORTAL allows businesses to monetise their content through direct access to their specific EVPL channel, rather than relying on a single ISP connection.

[0128] HYPERPORTAL disrupts the traditional payment model by enabling any business to deliver content or services over EVPLs with dedicated Layer 3 Quality of Service (QoS) to maintain priority traffic and peering. Now, users at the edge connect directly to a business’s service, paying only for the bandwidth allocated specifically for that experience, free from the extra layers and limitations of traditional internet service.

[0129] This approach opens unprecedented flexibility in vendor direct access (VDA). Content providers, social media platforms, gaming services, security and educational services can all deliver a more reliable, high-performance experience over dedicated bandwidth, bypassing the limitations and costs associated with shared internet services. End users benefit by paying solely for the content or services they value, enjoying a faster, higher- quality, and more tailored experience free from ISP backhaul contention. HYPERPORTAL’s framework further enhances this innovation by supporting both private and shared fibre options. Layer 1 security is through Optical Transport Network Security (OTNsec) if the network contains an optical footprint and the management vendor supports it. Additionally, MAC Address Security (MACsec) encrypts frames at layer 2 along with enhanced QoS at Layer 3 offers comprehensive integration of fibre infrastructure with application-level services, combined with scalable options, enables multi level dedicated bandwidth separately delivered to the premise businesses to reach consumers directly, creating secure, committed connections and opening new revenue pathways.

[0130] Setting up HYPERPORTAL

[0131] 1. At the House / Premises Level

[0132] • Hyperportal Gateway Installation:

[0133] The user receives a dedicated hardware, packet ethernet device to facilitate the EVPL service (similar in size to a modern router). This device is installed in the premises and connects directly to the fiber network provided by the network operator. It acts as a single entry and exit point for all internet traffic, e.g. bypassing a traditional ISP’s “black box.”.

[0134] • Premises Network Setup:

[0135] Once connected, the portal device creates a local / premises Wi-Fi network (or can also provide wired Ethernet ports). All user devices (games consoles, smartphones, laptop, smart TV, etc.) can connect to this network as they normally would. No special cables or rewiring is needed; the user sees a standard home network, to which devices can connect like a conventional router.

[0136] 2. At the Device Level

[0137] • Device-Specific Apps or Interfaces:

[0138] Some devices (such as a smartphone or smart TV) might offer a HYPERPORTAL app or built-in interface. This app allows a user to browse available “service connections” (akin to an app store for internet-enabled services from vendors) and choose the connection quality the user needs for each activity. An example interface is shown in Figure 9.

[0139] Seamless Experience:

[0140] For example, when a user launches a video game or streams a movie / music / game on a smart TV, the device can prompt the user to use a dedicated connection profile through the app (or automatically select one). This profile is optimized for that service’s needs - e.g. like low latency for gaming or high bandwidth for streaming - without the user knowing any technical details. t the App Level I Service Selection

[0141] • Accessing the HYPERPORTAL Interface:

[0142] The user opens the Hyperport portal (via a web interface or dedicated app on the user device). This interface displays various “apps” or service connections, such as TV, videoconferencing, gaming servers, or shopping portals. In the example of Figure 9, it can be seen that a graphical user interface is provided with tabs or windows for different service types. Examples of different service types include internet access / browsers, videoconferencing, shopping, gaming, local services, social, artificial intelligence, etc. Under each tab, a list or display of the available apps in that category are presented, e.g. as icons, buttons or other suitable graphical indicia. A search facility is also available to the user wishing to find a specific service.

[0143] • Choosing Your Service:

[0144] Through the Hyperportal app / platform, when the user wants to access a desired service, the user selects the service or a “connect option” within the service app, e.g. as one of the icons / buttons shown in Figure 9.. o The system then dynamically sets up a dedicated “tunnel” or EVPL connection between the premises and the service provider’s servers, ensuring the necessary bandwidth and quality. o The user might be presented options to choose different streaming speeds or quality levels, and time e.g. on a pay-as-you-go basis or under subscription plan.

[0145] • Dynamic and Flexible Connections:

[0146] If, concurrently with other online activities, the user needs to join a video call or download a large file, e.g. using the same or different devices on the local network, the Hyperportal manages these connections individually. Each device’s service can get its own dedicated, optimised pathway so that one heavy download doesn’t slow down another concurrent service.

[0147] • Billing and Management:

[0148] Everything is managed through the Hyperportal interface. A user can monitor usage, adjust service levels, and view billing — all centrally from the portal app.

[0149] Payment might be based on how much bandwidth is used or the duration of each dedicated connection, giving the user ultimate flexibility to review and change plans compared to fixed monthly ISP plans.

[0150] • Dynamic Management: The system dynamically sets up and / or tears down the dedicated EVPL connections or “tunnels” based on the user’s actions or needs, all of which can be managed through a simple user interface.

[0151] The HYPERLOOP “Portal” or “App Store” o Much like conventional app stores but for direct connectivity apps / services. o A framework that lets third-party providers “plug in” their service so users can browse or install “connections” (apps) to existing vendors. o Each “app” effectively denotes a dedicated, secure link from the user to that provider, possibly with flexible bandwidth and pay-as-you-go billing. o The III may comprise icons for different categories (Gaming, Video Conferencing, Shopping, Healthcare, Online workouts, TV, Music streaming, etc.). o The interface may have sub-screens for details, billing, user account, etc.

[0152] Back-End & Integration o API Integrations with fibre hardware (eg via APIs from different optical transport equipment vendors.) o A path computation engine to dynamically set up these dedicated tunnels (at the chosen speeds) on the network. o API logical parameters to apply specific traffic profiles to allow users to turn usage on / off o Utilisation reporting embedded within the HYPERPORTAL to ensure capacity monitoring is constantly synchronised. o Tracking usage, handling on-demand bandwidth requests, and hooking into a billing mechanism so users can pay per service or usage level. o Potential integration of Al-based search / browsers in the portal (e.g. anticipate the “merging” of Al, search, and browsers). o Some usage logging and billing (could be as simple as storing usage details, or as complex as pay-as-you-go micro-transactions).

[0153] Based on the above description, it will be appreciated that a myriad of services that can be selected and connected with a dynamically applied dedicated fiber capacity service by use of the portal or user console 16, or other devices on the user’s local network connected thereto. The user can thus select the service and the ensure that it has the bandwidth / speed needed for delivery, e.g. being anywhere form 50Mb to 1 Gigabit or even 5 or 10 Gigabit speed or higher, if needed for the task at hand.

[0154] Certain benefits of the services and systems described herein include:

[0155] • EVPL service builds can be instantly provisioned, and thereafter service routing connections to target servers 18. This omits significant operational demands of the fibre infrastructure network providers.

[0156] • Users have access to the content they require on-demand directly with service vendors.

[0157] • It opens possibilities globally within loT and sensitive applications demand lightning speeds and low latency e.g. Al and machine learning at the edge, VR and AR experiences, High Frequency Trading (HFT), remote surgery, scientific modelling simulations; city or grid modelling, etc.

Claims

Claims:1 . A system for facilitating online services between a user and vendors over an optical fiber network, the system comprising: a portal having a connection to said network over which the portal may communicate with a plurality of vendors, said connection having a network capacity, wherein the portal is arranged to output an initiation request for access to an online service from one of said vendors; a management system arranged to receive the initiation request from the portal, the management system arranged automatically to provision or establish an Ethernet Virtual Private Line (EVPL) connection over said optical fiber network between the portal connection and the service provider, wherein said EVPL connection is assigned a defined bandwidth and / or speed; the portal partitioning the network capacity in accordance with the established EVPL connection for delivery of the online service to the user.

2. The system of claim 1 , wherein the EVPL connection is defined at least in the data-link layer and network layer.

3. The system of claim 2, wherein the initiation request from the portal comprises data link and / or network layer specifications for the EVPL connection.

4. The system of claim 3, wherein the initiation request from the portal comprises scripts for the data link and / or network layer specifications.

5. The system of any preceding claim, wherein the management system automates network configuration for routing of the EVPL connection over said optical fiber network based on the received initiation request.

6. The system of any preceding claim, wherein the management system comprises a software defined network (SDN) controller.

7. The system of any preceding claim, wherein the management system comprises an API-based controller for directing network traffic on the optical fiber network.

8. The system of any preceding claim, wherein the management system comprises an optical distribution node / core and a datacentre in communication therewith.

9. The system of any preceding claim, wherein the establishing or provisioning of the EVPL connection is implemented by an edge-to-core provisioning process.

10. The system of any preceding claim, wherein the portal comprises a switch or software application portal for the user premises.11 . The system of any preceding claim, wherein the portal comprises software applications presented in a user interface for accessing each service provided by the plurality of vendors, wherein the selection of each of said software applications through the user interface initiates the establishing of the EVPL connection by outputting the initiation request.

12. The system of any preceding claim, wherein the establishing of the EVPL connection is performed dynamically and / or in real time, e.g. within a few seconds or less than one minute of the output of the initiation request.

13. The system of any preceding claim, wherein the defined bandwidth and / or speed comprises a bandwidth and / or speed threshold, capacity or limit.

14. The system of any preceding claim, wherein a plurality of the EVPL connections are established with a plurality of the vendors and maintained concurrently by the portal for accessing the online services from the vendors through the portal.

15. The system of claim 14, wherein the plurality of the EVPL connections have a different assigned bandwidth and / or speed.

16. The system of claim 14 or 15, wherein the bandwidth or speed of the EVPL connections is adjustable / selectable via the portal.

17. The system of any preceding claim, wherein the EVPL connection is implemented by a securely combined Iayer2 ethernet, IP QoS service to retain the service over a wide area network facilitated by BGP protocols.

18. The system of any preceding claim, wherein the management system charges the vendors for the established EVPL connections associated with their online service.

19. The system of any preceding claim, wherein the EVPL connection between the portal connection and service provider is established through switching and routing across the optical fiber network with a SDN management system20. A method of facilitating online services between a user and vendors over a fiber infrastructure and optical fiber network, the method comprising: providing a portal having a connection to said network over which the portal may communicate with a plurality of vendors, said network connection having a network capacity; establishing a EVPL connection over said network between the portal and each vendor, wherein each said EVPL connection is assigned a defined bandwidth and / or speed; partitioning the network capacity at the portal such that separate channels are defined for connection with each of the plurality of vendors; delivering the service by each respective vendor over each said channel connection by data transmission in accordance with the assigned bandwidth and / or speed.21 . A management system for establishing / provisioning direct connections between portal s and vendors over a fiber network, the management system being arranged to receive an initiation request from the portal for access to an online service from one of said vendors, the management system arranged automatically to establish an EVPL connection over said fiber network between the portal and the service provider, wherein said EVPL connection is routed through the fiber network and assigned a defined bandwidth and / or speed for delivery of the online service to the user.

22. A portal for use in facilitating delivery of online services over an optical fiber network between a user network connection and vendors, the portal having: a user interface by which a user can select a service provider or service from a service provider; wherein the portal outputs an initiation request to a management system to establish an EVPL connection over said network between the user network connection and the vendor, wherein the initiation request comprises data link layer and / or network / internet layer specifications for the EVPL connection, such that the EVPL connection can be established automatically in response thereto.

Images