BSC Central Services Participant Guidance Participant Communications Installation ... · 2018-04-23 · Participant Guidance - Participant Communications Installation Guide (PCIG)

IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5) Version: 12.5, Date: 24/10/17

page 1 of 45

BSC Central Services

Participant Guidance Participant Communications Installation Guide

(PCIG)

Customer : ELEXON

Contract number :

Business/project number : 4042.EC.230694

Project Manager : Mark Wood

Reporting to : Paul Buxton

Project/document reference : IF-00000018

Issue : 12.5

Issue date : 24/10/17

Status : Definitive

Distribution : As per distribution list on page 2

Prepared by : Nick Brooks Author Date:

Approved (CGI) : Date:

Approved (CGI) : Date:

Authorised (CGI) : Date:

Accepted (ELEXON) : Role Date:

Participant Guidance - Participant Communications Installation Guide (PCIG)

IF-00000018 / Definitive 12.5 24/10/17

IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)

page 2 of 45

Reviewers

Name Role

Distribution List

Name/Role Organisation

UKEST Programme Library CGI

Participant IT Support Participant Organisation


IF-00000018 / Definitive 12.5 24/10/17


page 3 of 45

Detailed contents

1 Introduction ..................................................................................................................................... 5

1.1 Purpose ................................................................................................................................ 5 1.2 Scope ................................................................................................................................... 5 1.3 Summary .............................................................................................................................. 5 1.4 Amendment history .............................................................................................................. 5 1.5 References ........................................................................................................................... 5 1.6 Abbreviations ....................................................................................................................... 7

2 BSC Central Services..................................................................................................................... 9

2.1 Energy Contract Volume Aggregation Agent (ECVAA) ....................................................... 9 2.2 Central Data Collection Agent (CDCA) ................................................................................ 9 2.3 Balancing Mechanism Reporting Agent (BMRA) ................................................................. 9 2.4 Central Registration Agent (CRA) ........................................................................................ 9 2.5 Settlement Administration Agent (SAA) .............................................................................10 2.6 Funds Administration Agent (FAA) ....................................................................................10 2.7 Technical Assurance Agent (TAA) .....................................................................................10 2.8 Supplier Volume Allocation Agent (SVAA) ........................................................................10

3 Electronic Interfaces to BSC Central Services .............................................................................11

3.1 Communications Access to BSC Central Services ............................................................11 3.2 Low Grade Interfaces .........................................................................................................11

3.2.1 BMRS Web Service (BMRA) .........................................................................11 3.2.2 BMRS API .....................................................................................................11 3.2.3 BMRS Data Push Service .............................................................................11 3.2.4 FTP Notification and reporting (ECVAA/SAA/CRA/CDCA) ...........................12 3.2.5 ELEXON Portal ..............................................................................................12 3.2.6 ECVAA Web (ECVAA) ..................................................................................13

3.3 High Grade Interfaces ........................................................................................................13 3.3.1 Tibco (BMRA) ................................................................................................13 3.3.2 FTP Notification and Reporting (ECVAA/SAA/CRA/CDCA) .........................13 3.3.3 ECVAA Web (ECVAA) ..................................................................................13

4 Participant Hardware and Software Infrastructure .......................................................................14

4.1 Hardware Requirements ....................................................................................................14 4.1.1 High Grade WAN Communications (Mandatory for High Grade) .................14 4.1.2 Low Grade Internet Communications (Mandatory for Low Grade) ...............15 4.1.3 Servers to Host Software Infrastructure (Mandatory) ....................................15

4.2 Software Requirements .....................................................................................................16 4.2.1 Trading Software (Mandatory) .......................................................................16 4.2.2 FTP Transfer Software (Mandatory)..............................................................16 4.2.3 XSec Encryption Software (Mandatory) ........................................................16 4.2.4 BMRS Web Clients (Optional) .......................................................................17 4.2.5 ECVAA Web Clients (Optional) .....................................................................17 4.2.6 Tibco Data Transmission Software (Optional – High Grade Only) ...............17 4.2.7 FTP Server Software (Optional – High Grade Only) .....................................18

5 Detailed Operation of Services ....................................................................................................19

5.1 FTP Service Usage ............................................................................................................19 5.1.1 Retrieval ........................................................................................................19 5.1.2 Submission ....................................................................................................22 5.1.3 Receiving via High Grade Push ....................................................................24 5.1.4 Shared S0142 Files .......................................................................................25

5.2 XSec Software ...................................................................................................................25 5.2.1 Application Overview .....................................................................................25 5.2.2 Integration with Other Processes ..................................................................26


IF-00000018 / Definitive 12.5 24/10/17


page 4 of 45

5.3 Tibco Rendezvous Software ..............................................................................................26 5.3.1 Approval of New RVRDs ...............................................................................26 5.3.2 RVRD Unique Naming ..................................................................................26 5.3.3 Offline/Standby Servers ................................................................................26 5.3.4 BMRS Subject Naming ..................................................................................27

6 Participant Disaster Recovery ......................................................................................................28

6.1 High Grade Push/Pull Switching ........................................................................................28 6.2 High Grade Push to a Different Server ..............................................................................28 6.3 High/Low Grade Switching .................................................................................................28 6.4 Resilient High Grade Networking .......................................................................................29

7 Overview of Manual Data Flows ..................................................................................................30

7.1 E-mail Communications .....................................................................................................30 7.2 Fax Communications .........................................................................................................30 7.3 Postal Communications .....................................................................................................31 7.4 Manual Acknowledgement Process ...................................................................................31 7.5 Security ..............................................................................................................................32 7.6 Manual Flows to Participants .............................................................................................32

8 Overview of Electronic Data Flows ..............................................................................................33

8.1 Sequence Numbering ........................................................................................................33 8.2 Sequence Handling ............................................................................................................34 8.3 Acknowledgements ............................................................................................................34 8.4 Handling Negative Acknowledgements .............................................................................35

9 Networking Information ................................................................................................................36

9.1 High Grade .........................................................................................................................36 9.1.1 Information and Site Access ..........................................................................36 9.1.2 Features and Specifications ..........................................................................36 9.1.3 Planning an IP Schema .................................................................................37 9.1.4 Firewall Configuration ....................................................................................37 9.1.5 Provision for BSC Central Services Disaster Recovery ................................38

9.2 Low Grade ..........................................................................................................................38 9.2.1 Firewall Configuration ....................................................................................38 9.2.2 Provision for BSC Central Services Disaster Recovery ................................38

10 Summary Overview – Steps in the Comms Setup Process .........................................................40

11 Service Desk ................................................................................................................................41


IF-00000018 / Definitive 12.5 24/10/17


page 5 of 45

1 Introduction

1.1 Purpose

The purpose of this document is to describe the services provided by BSC Central

Services in relation to the planning, installation and operation of communications,

hardware and software, and the interfaces with Market Participants.

1.2 Scope

Since this is an overview document, it references other more detailed procedures,

documents and instructions. Its scope is to provide a basic understanding of what is

required to interact with BSC Central Services.

1.3 Summary

Participant Communications Installation Guide

Guidance document for new BSC Central Services Participants.

1.4 Amendment history

date issue description author OR no.

29/05/08 10.1 First Draft (based upon 09-

10033301 v10.0) Nick Brooks

N/A

30/05/08 10.2 Incorporating internal review

comments Nick Brooks

N/A

12/06/08 10.3 Incorporating ELEXON

review comments Nick Brooks

N/A

20/06/08 12.0 Made definitive following approval from ELEXON

Bron Roddis N/A

11/12/08 12.1 Isis Changes Nick Brooks N/A

18/08/17 12.2 Updates Nick Brooks N/A

03/10/17 12.3 Made definitive following approval from ELEXON

Lloyd Annobil N/A

11/10/17 12.4 Additional Updates Lloyd Annobil N/A

24/10/17 12.5 Incorporating Appendix and additional ELEXON review

comments

Nick Brooks N/A

1.5 References

tag title doc reference version

[XUG] XSec User Guide 25-17010301 TBC

[TUG] Tibco User Guide 01-100308 TBC


IF-00000018 / Definitive 12.5 24/10/17


page 6 of 45

tag title doc reference version

[CRD] Communications Requirements Document* N/A N/A

[IDD] NETA Interface Definition and Design (IDD) Pt 1 07-550201 latest

*The CRD is an ELEXON document, available via the ELEXON website


IF-00000018 / Definitive 12.5 24/10/17


page 7 of 45

1.6 Abbreviations

ARP Address Resolution Protocol

BGP Border Gateway Protocol

BM Balancing Mechanism

BMRA Balancing Mechanism Reporting Agent

BMRS Balancing Mechanism Reporting Service

BP BSC Party (Participant role code)

BRI Basic Rate Interface (ISDN with two data channels)

BSC Balancing and Settlement Code

CDCA Central Data Collection Agent

CIR Committed Information Rate

CRA Central Registration Agent

CSV Comma Separated Values

DNS Domain Naming System

DPP Daily Profile Production

DR Disaster Recovery

DTI Department of Trade and Industry

ECVAA Energy Contract Volume Aggregation Agent

ECVNA Energy Contract Volume Notification Agent

FAA Funds Administration Agent

FQDN Fully Qualified Domain Name

FTP File Transfer Protocol

HHDA Half Hourly Data Aggregator

HSRP Hot Standby Routing Protocol

IDD Interface Definition and Design

IP Internet Protocol


IF-00000018 / Definitive 12.5 24/10/17


page 8 of 45

ISDN Integrated Services Digital Network

ISP Internet Service Provider

JVM Java Virtual Machine

LAN Local Area Network

NAT Network Address Translation

MDD Market Domain Data

MPLS Multi Protocol Label Switching

NHHDA Non-Half Hourly Data Aggregator

NTP Network Time Protocol

PVC Permanent Virtual Circuit

RSA Rivest Shamir Adleman (algorithms/creators of)

RVD Rendezvous Daemon

RVRD Rendezvous Routing Daemon

SAA Settlement Administration Agent

SO System Operator

SLA Service Level Agreement

SVAA Supplier Volume Aggregation Agent

TAA Technical Assurance Agent

TCP Transmission Control Protocol

UDP User Datagram Protocol

WAN Wide Area Network


IF-00000018 / Definitive 12.5 24/10/17


page 9 of 45

2 BSC Central Services

The services provided by CGI (“the Service Provider”) to support the operation of

the Balancing and Settlement Code (BSC), require market Participants to

communicate electronically with CGI’s systems.

Network communications access to the BSC Central Services is provided through

three networks, the CVA WAN (or “CVA High Grade Service”) and the internet (or

“CVA Low Grade Service”) for CVA Services, and the Electralink DTS network (or

“SVA Network”) for SVA Services.

It should be noted that the focus of this document is on BMRA, ECVAA, CRA, CDCA

and SAA. The FAA and TAA (not shown) involve only manual communications as

specified by the Communications Requirements Document [CRD]. The System

Operator is not addressed here.

2.1 Energy Contract Volume Aggregation Agent (ECVAA)

The role of the ECVAA is to collate and provide to the Settlement Administration

Agent (SAA) all energy contract volume and metered volume reallocation data.

2.2 Central Data Collection Agent (CDCA)

The Central Data Collection Agent (CDCA) collects, validates, processes and

aggregates metered data associated with Metering Systems registered with the

Central Registration Agent (CRA). It does this within the timescales required to

enable settlement to meet the Payment Calendar.

2.3 Balancing Mechanism Reporting Agent (BMRA)

The role of the BMRA is to provide near to real-time reporting of all market

information disseminated by the System Operator (SO) and submitted to the

Balancing Mechanism (BM) from market Participants.

2.4 Central Registration Agent (CRA)

The role of the CRA is to maintain a master register of information relating to the

registration of Participants, trading units and physical plant such as Boundary Points

and interconnectors.


IF-00000018 / Definitive 12.5 24/10/17


page 10 of 45

2.5 Settlement Administration Agent (SAA)

The role of the SAA is to calculate the credit and debit payments resulting both from

trades made in the Balancing Mechanism (BM) and from imbalances between

contracted and actual generation or consumption.

The SAA creates and publishes a Settlement Calendar on an annual basis to ensure

that all Settlement calculations and Settlement Runs are performed in a timely

manner so that payments are made on the intended dates.

2.6 Funds Administration Agent (FAA)

The FAA is responsible for transacting the payments and charges applicable as

determined by the SAA.

2.7 Technical Assurance Agent (TAA)

The TAA is concerned with the technical assurance of all Metering Systems

registered with the CRA. The overriding aim of this service is to support the quality

of meter data that is used in the settlement process. The TAA provides a vital link in

the end to end assurance of settlement data by reviewing the very source of the data,

the Metering System and its associated equipment.

2.8 Supplier Volume Allocation Agent (SVAA)

The SVAA is responsible for producing MDD, DPP and calculating Supplier BM

Units meter volumes using data provided by the Suppliers’ HHDAs and NHHDAs.


IF-00000018 / Definitive 12.5 24/10/17


page 11 of 45

3 Electronic Interfaces to BSC Central Services

3.1 Communications Access to BSC Central Services

The interface with the SVA element of BSC Central Services is via the DTS

network. This is a service provided by Electralink.

There are two methods of electronic communication with the CVA elements of BSC

Central Services, referred to as the High Grade and Low Grade services.

The High Grade service is provided using dedicated communications lines installed

and managed by BSC Central Services. These lines connect the Participant to BSC

Central Services over an MPLS based private WAN.

The Low Grade service is provided via the public internet using connectivity

provided and managed by individual Participants.

Although the primary distinction between the two grades of service is the ability of

the Service Provider to commit to specific levels of performance and reliability, the

guaranteed bandwidth of the High Grade service allows an enhanced method of

BMRS data retrieval to be available.

3.2 Low Grade Interfaces

The interfaces available using the Low Grade Service over the public internet are:

3.2.1 BMRS Web Service (BMRA)

Available at http://www.bmreports.com, the BMRS website allows querying of

current and historic Balancing Mechanism data, which is presented in tables, graphs

and downloadable as CSV files. The data provided is a static snapshot as the data

exists at the time that the query is made.

This is presented over the internet, and no authentication is required to view data, it

is publicly available.

3.2.2 BMRS API

Available at api.bmreports.com, the BMRS API provides a machine to machine

interface allowing XML web service calls to be made to retrieve BMRS data over the

internet.

This service requires authentication using an API key obtained from the ELEXON

Portal.

3.2.3 BMRS Data Push Service

This is an ActiveMQ based data push facility presented over the internet allowing

real-time BMRS events to be subscribed to and received using a variety of protocols


IF-00000018 / Definitive 12.5 24/10/17


page 12 of 45

including STOMP, MQTT ,Openwire and AMQP, offering both durable and non-

durable connection options.

3.2.4 FTP Notification and reporting (ECVAA/SAA/CRA/CDCA)

Available at ftp.bmreports.com, the BSC Central Services FTP service allows

submission of files containing BSC IDD formatted data flows to Central Services.

Files placed on this server are picked up and processed, and responses and reports are

placed on the server for the Participant to periodically poll for and collect.

This service requires login credentials which are supplied during the registration

process.

3.2.5 ELEXON Portal

The ELEXON Portal, accessible over the internet at https://www.elexonportal.co.uk

provides a wide variety of data to the industry including news, documentation, online

forms and utilities as well as access to real-time data from the BSC systems and

archived historic data.

Users self-register for ELEXON Portal accounts, with further privileges for some

functionality requested by the user and granted by ELEXON.

https://www.elexonportal.co.uk/


IF-00000018 / Definitive 12.5 24/10/17


page 13 of 45

3.2.6 ECVAA Web (ECVAA)

Available at https://www.ecvaa.com, the ECVAA web service allows an alternative

method for Participants to view their positions and notify to the ECVAA service in a

more interactive way than the standard FTP notification method.

The Sun Java virtual machine is required to use the functionality of this site.

This service has a login authentication process controlled by the Participant

organisation and based on the security architecture used by the main BSC Central

Services FTP service. It requires users to provide a username, password and a

“credentials file” provided by their security administrator permitting them access to

the service.

3.3 High Grade Interfaces

The interfaces available using the High Grade service over the BSC Central Services

private WAN are:

3.3.1 Tibco (BMRA)

This service is only available using the High Grade service, and uses industry

standard Tibco data transmission software to stream a subscription customised feed

of Balancing Mechanism data to the Participant’s site. The Participant can then use

Tibco connectors to pass this data into their own applications.

3.3.2 FTP Notification and Reporting (ECVAA/SAA/CRA/CDCA)

This is the same FTP service as described for the Low Grade service in section 3.2.4,

except that it is accessed via the High Grade network.

3.3.3 ECVAA Web (ECVAA)

This is the same secure web service as described for the Low Grade service in

section 3.2.6, except that it is accessed via the High Grade network.


IF-00000018 / Definitive 12.5 24/10/17


page 14 of 45

4 Participant Hardware and Software Infrastructure

This section outlines the hardware and software requirements for a BSC Central

Services Participant and which parties are responsible for provision and support of

both hardware and software.

4.1 Hardware Requirements

4.1.1 High Grade WAN Communications (Mandatory for High Grade)

If a Participant chooses to use the High Grade service, they place an order for this

service through ELEXON. Before this order is accepted, the Participant then engages

in a technical prevalidation process with the Service Provider. The Service Provider

liaises with the Participant to arrange installation of dedicated communications lines

and a router to connect to the Participant’s network.

The Participant will be responsible for providing technical details related to the

installation throughout the order process, and must allow for reasonable and timely

site access for the Service Provider’s supplier during installation and in the event of

any fault.

The Service Provider is responsible for operation and support of the communications

up to the ethernet port on the provided router. The Participant is responsible for the

network that they connect to the router.

The typical High Grade Service will comprise the following hardware:

A 2Mb MPLS Leased Line

A 20:1 contended, 2Mbps ADSL backup line

A Cisco rack mountable router with a 10/100/1000Mbps ethernet port for

connection to the Participant’s network.

Several other communications options are available, including for ADSL as a

primary line to reduce cost (with compromises in SLA support and contention).

Communications lines options and pricing are available upon request from

ELEXON’s market entry team. CGI can provide advice to participants as to the best

option for a new communications requirement.

The lead-time for installation of these communications lines is 55 working days from

the date that the order is placed following technical prevalidation.

The High Grade communications service is provided using Vodafone infrastructure

and is completely managed through CGI as the Service Provider.


IF-00000018 / Definitive 12.5 24/10/17


page 15 of 45

The Service Provider will discuss networking requirements with the Participant and

will use reasonable endeavours to accommodate any special requirements that the

Participant has, for example:

Custom IP addressing

Network Address Translation

Upgraded communications for bandwidth and/or resilience

Automatic failover if more than one service is ordered.

It is highly recommended that in addition to the inherent security of the network

managed by the Service Provider, the Participant provides a firewall for their High

Grade network connection.

The standard communications described above are suitable for a Participant

registering and using up to three Participant IDs, using one instance of a Tibco server

to retrieve real-time BMRS data and with up to five workstations accessing the

BMRS web service. If a Participant’s needs are higher than this they should consult

the Service Provider to establish whether a more highly specified communications

option is prudent.

4.1.2 Low Grade Internet Communications (Mandatory for Low Grade)

The Participant is responsible for sourcing, ordering and maintaining their own

internet connectivity.

When the Participant provides their internet connectivity, they should consider the

following points:

They should synchronise their systems using a suitable time synchronisation

protocol, and NTP is recommended. The choice of NTP server will depend

upon the requirements and size of the environment to be synchronised. A

recommended server list can be found at

http://ntp.isc.org/bin/view/Servers/WebHome.

They should ensure that they are able to access ftp.bmreports.com using an

FTP client (standard port 21).

They should be able to access http://www.bmreports.com and

https://www.ecvaa.com through a web browser.

It is strongly recommended that the Participant provides a dedicated firewall

platform for their internet connection.


IF-00000018 / Definitive 12.5 24/10/17


page 16 of 45

4.1.3 Servers to Host Software Infrastructure (Mandatory)

All hardware on the Participant site (with the exception of the High Grade router and

associated networking equipment) is provided and maintained by the Participant. The

Service Provider does not provide hardware or support hardware on which the

Service Provider supplied software is installed.

4.2 Software Requirements

4.2.1 Trading Software (Mandatory)

The Participant is responsible for providing software which is able to conform to the

BSC IDD for the generation of, recognition of and response to BSC data flows.

The Service Provider cannot provide recommendations for this software, but is aware

of several vendors who are able to provide suitable software and can provide a list on

request.

4.2.2 FTP Transfer Software (Mandatory)

The Participant is responsible for providing software for the transfer of files via FTP

between themselves and BSC Central Services. Although use of a manual FTP client

is acceptable, it is recommended that an automated solution is employed. Most of the

commercially available trading software incorporates this functionality.

4.2.3 XSec Encryption Software (Mandatory)

All files transferred to and from Central Services by FTP are encrypted/decrypted

using a piece of proprietary software called XSec. It runs on all variants of Windows

supporting the .NET 4.0 framework (including Windows 7, 2008 and 2012). It runs

as a Windows service and has a file based interface - files are placed into input

directories where they are picked up by XSec, processed and placed into output

directories.

XSec provides encryption and signing functionality for all files to be sent to or

received from BSC Central Services and is entirely automated, such that the

successful receipt of a plaintext file from XSec implies that a secure, complete and

validated transfer of data from BSC Central Services has occurred.

The XSec software uses public key encryption/signing technology which requires the

Participant to create private and public keys. The public keys must then be sent to the

Service Provider to be verified and applied to the Central Services encryption

subsystem The Service Provider will provide advice and assistance for this. (see

helpdesk contact information in section 11).

XSec does not provide FTP or trading software functionality.

The Participant is responsible for providing the hardware and software environment

for this software and operating it, but the Service Provider provides support and

assistance in configuring and troubleshooting.


IF-00000018 / Definitive 12.5 24/10/17


page 17 of 45

The XSec software is highly customisable in order to be able to be tailored to the

requirements of each Participant, and the Service Provider will provide advice and

assistance for installation and configuration.

XSec is ordered via ELEXON during registration, and a separate user guide is

supplied with the software.

4.2.4 BMRS Web Clients (Optional)

If the Participant wishes to use the BMRS web service, they are responsible for

providing their own web clients.

4.2.5 ECVAA Web Clients (Optional)

In addition to the technologies required for use of the BMRS web services (Sun

JVM, Internet Explorer 6), to use the ECVAA Web service a user requires a

username, password and a credentials file supplied by their security administrator

(within the Participant organisation). The user connects to the ECVAA Web server

using an SSL enabled Internet Explorer browser and provides their username and

credentials file, followed by randomly selected letters from their password.

The key component here is the credentials file. The Participant security administrator

creates credentials files (using tools available from the Service Provider or by

creating the files manually from specifications available from the Service Provider),

specifying details such as username, password, file validity periods and user rights.

The administrator encrypts these files using the XSec software discussed in section

5.2 (using the same keys employed for encryption of BSC FTP file flows) and

provides the encrypted files to the user.

When the user performs a login, the ECVAA web service confirms that the

credentials file supplied is from a verified source (established by means of

decryption with the Participant’s public keys) and that the credentials being supplied

by the user match those in the credentials file.

It is recommended that a separate installation of XSec on a standalone machine is

used for credentials file encryption, and the Service Provider supplies a targeted

software installation pack for this purpose.

Note: The Service Provider’s staff will never ask the Participant for their ECVAA

web username or password, and users of the system should be advised that they

should not provide these details under any circumstances.

4.2.6 Tibco Data Transmission Software (Optional – High Grade Only)

If the Participant has a High Grade Service and wishes to utilise the BSC Central

Services BMRS Tibco data stream, they are responsible for providing a Tibco RVRD

(server) and as many RVDs (clients) as they require.


IF-00000018 / Definitive 12.5 24/10/17


page 18 of 45

The Tibco software can be sourced through ELEXON (Windows only), purchased

directly from Tibco or the Participant can use any Tibco architecture they may

already have within their organisation, subject to licence agreements

A separate Tibco user guide detailing Tibco setup specific to BSC Central Services is

provided on request by the Service Provider.

The Tibco software has two components known as the RendezVous Daemon (RVD)

and the RendezVous Routing Daemon (RVRD). The server (RVRD) is used to

transfer data between sites, and then redistribute this data to local clients (RVDs).

The Service Provider operates a central RVRD which publishes real-time BMRS

data. The Participant configures their own RVRD which connects to the BSC Central

Services central RVRD and receives this data. The Participant RVRD then relays this

data to local RVDs

RVRD is a cross platform product, but is most commonly run on Windows. The

Service Provider distributes, supports and tests only Windows environments. If the

Participant wishes to use a non Windows Tibco configuration they should therefore

ensure that they provide adequate platform support, and should source their Tibco

software independently of ELEXON.

The Participant must contact the Service Provider before configuring an RVRD to

ensure that the correct configuration is being used to avoid conflicts with other parts

of the Tibco network.

In its default configuration, the RVRD server communicates with its RVD clients by

using a local subnet broadcast, requiring the clients to reside on the same local

network as the server. This is explained more in the networking section 9.

The Service Provider supports the specific application and configuration for Tibco

that is being used for BMRS, and is also able to provide limited support and

assistance for the Tibco product itself, with the ability to refer product defect queries

directly to Tibco. The Service Provider will supply upon request their Tibco User

Guide [TUG].

Note: The Tibco BMRS service only publishes current data. It is not able to be used

for supply of historical data.

Note: Tibco data is also provided as day-behind flat files through the Low Grade

BMRS Web Service. This is known as the Tibco Relay service.

4.2.7 FTP Server Software (Optional – High Grade Only)

When a Participant sends files to BSC Central Services, they place the files on the

BSC Central Services FTP server. When BSC Central Services respond, the default

behaviour is that response files are placed on the BSC Central Services FTP server

for the Participant to periodically poll and collect.


IF-00000018 / Definitive 12.5 24/10/17


page 19 of 45

However, if a Participant is using the High Grade service, they may elect to provide

an FTP server on their own site which BSC Central Services can push files out to

directly as soon as they are generated. This is entirely optional.


IF-00000018 / Definitive 12.5 24/10/17


page 20 of 45

5 Detailed Operation of Services

5.1 FTP Service Usage

As discussed in previous sections, a core part of the services provided by BSC

Central Services involves transfer of files to and from Participants using FTP. The

BSC Central Services FTP service is available both via the High Grade network and

the public internet. Both routes reach the same server, and the same procedure should

be used for both methods of access.

The BSC Central Services FTP servers use standard FTP on port 21, and accept both

active and passive data transfers (passive is recommended to increase the

Participant’s own security, since all network connections are then outbound from the

Participant’s network).

The Participant is provided with an FTP account on the BSC Central Services server

for each BSC Central Services Participant ID that they register. This Participant ID is

the username for the Live FTP service. Passwords are provided by the Service

Provider during the registration process. The examples below use the fictional

account name “user1234”.

When the Participant logs into the BSC Central Services FTP server, they are placed

in a directory off the FTP server root corresponding to their account name which

contains three subdirectories – inbox, outbox and temp. Participants must not create

their own subdirectories or content on the BSC Central Services FTP server and are

not permitted to store files on the server for any purpose other than that described

below.

5.1.1 Retrieval

When BSC Central Services creates files for the Participant, they are placed in the

Participant’s outbox directory on the BSC Central Services FTP server. The

Participant should periodically poll for these files at a rate of no more than once per

60 seconds. The Participant is responsible for retrieving the file in binary mode,

confirming that the transfer was successful and then deleting the file.


IF-00000018 / Definitive 12.5 24/10/17


page 21 of 45

The Participant should pick up their files in a timely manner and not leave files on

the server after collecting them. In reality uncollected files are purged after 12 days,

but the Participant must not rely on files older than 5 days being present on the server

(5 days being the period of time that files are defined to be available. Under some

Disaster Recovery scenarios the full 12 days of backlog may not be populated).

When logging in, the Participant FTP software should make no assumptions about

the content of the FTP login banner, since this may be changed from time to time, or

in response to a disaster.

Once logged in, the user is placed in the /username/ directory directly beneath the

FTP server root. Files generated for the Participant by BSC Central Services will be

placed in the /username/outbox/ directory.

The Participant should carry out the following actions:

Switch to binary data transfer mode using the TYPE I command (usually

implemented in command line clients as bin).

List the files in the outbox directory using the LIST command (usually

implemented in command line clients as ls or dir).

Parse the resulting listing to obtain filenames.

For each file, retrieve using the RETR command (usually implemented in

clients as get), then upon successful validation that the file has been received

delete the file using the DELE command.

If a Participant wishes to use a different method than this, they should contact the

Service Provider who can advise of any potential problems. In particular it is

strongly recommended that the Participant considers the following:

While automated scripting of the FTP process is encouraged, individual file

retrieves/deletes should be carried out on a per file basis, rather than using

batch commands such as mget.

The Participant should carry out some form of basic validation on the

retrieved file before deleting from the server. This may be as simple as

confirming that a 226 code has been received for the transfer, or that the file

retrieved is the same size as the directory listing indicated.

There follows an example FTP transcript of a successful retrieval of two files. In this

example a Unix command line FTP client is being used. Red lines indicate

commands sent from the Participant, and green lines those returned from the server:

ftp> open ftp.bmreports.com

Connected to ftp.bmreports.com.

220 Microsoft FTP Service


IF-00000018 / Definitive 12.5 24/10/17


page 22 of 45

220 ELX-LVW-FTP

ftp> user username password

331 Password required for username.

230 User username logged in.

ftp> bin

200 Type set to I.

ftp> ls outbox

200 PORT command successful.

150 Opening ASCII mode data connection for file list.

file1

file2

226 Transfer complete.

ftp> get outbox/file1


150 Opening BINARY mode data connection for outbox/file1 (29 bytes).


29 bytes received in 0.00 secs (0.00 secs, 56.64 Kbytes/s)

ftp> dele outbox/file1

250 DELE command successful.

ftp> get outbox/file2


150 Opening BINARY mode data connection for outbox/file2 (29 bytes).


29 bytes received in 0.00 secs (0.00 secs, 56.18 Kbytes/s)

ftp> dele outbox/file2

250 DELE command successful.

ftp> bye

221 Goodbye.


IF-00000018 / Definitive 12.5 24/10/17


page 23 of 45

5.1.2 Submission

When a Participant wishes to submit a file, they must push the file in binary mode to

their temp directory, and then move the file to their inbox directory using a rename

operation. This ensures that there is no possibility of BSC Central Services collecting

a file for processing which has not fully finished file transfer. It is required that

Participants transfer files using this method.

When logging in, the Participant FTP software should make no assumptions about

the content of the FTP login banner, since this may be changed from time to time, or

in response to a disaster.

Once logged in, the user is placed in the /username/ directory directly beneath the

FTP server root. The Participant must submit files to the /username/temp directory,

then rename them to the /username/inbox directory. This is to ensure that files

retrieved from the inbox by BSC Central Services are complete and not still being

transferred.

The Participant should carry out the following actions:

Switch to binary data transfer mode using the TYPE I command (usually

implemented in command line clients as bin)

For each file, upload to the temp directory using the STOR command

(usually implemented in command line clients as put), then move the file to

the inbox directory using the RNFR and RNTO commands (usually

simplified in command line clients using the rename command).

If a Participant wishes to use a different method than this, they should contact the

Service Provider who can advise of any potential problems. In particular it is

strongly recommended that the Participant considers the following:

The Participant should check return codes to confirm that operations have

been successful.

The Participant must transfer and rename files individually. Usage of batch

commands or manipulation of directories to achieve the same effect is not

accepted and Participants using such methods will be asked to stop, since it

can disrupt the automated process used by the Service Provider in processing

files.


IF-00000018 / Definitive 12.5 24/10/17


page 24 of 45

There follows an example FTP transcript of a successful submission of two files. In

this example a Unix command line FTP client is being used. Red lines indicate

commands sent from the Participant, and green lines those returned from the server:

ftp> open ftp.bmreports.com

Connected to ftp.bmreports.com.

220 Microsoft FTP Service

220 ELX-LVW-FTP

ftp> user username password

331 Password required for username.

230 User username logged in.

ftp> bin

200 Type set to I.

ftp> put file1 temp/file1


150 Opening BINARY mode data connection for temp/file1.


1 byte sent in 0.00 secs (0.00 secs, 1.95 Kbytes/s)

ftp> rename temp/file1 inbox/file1

350 File exists, ready for destination name

250 RNTO command successful.

ftp> put file2 temp/file2


150 Opening BINARY mode data connection for temp/file2.


1 byte sent in 0.00 secs (0.00 secs, 1.76 Kbytes/s)

ftp> rename temp/file2 inbox/file2

350 File exists, ready for destination name

250 RNTO command successful.

ftp> bye

221 Goodbye.


IF-00000018 / Definitive 12.5 24/10/17


page 25 of 45

5.1.3 Receiving via High Grade Push

Participants with a High Grade service may elect to have response and report files

pushed directly to an FTP server on their own site. If this is required the Participant

must provide the Service Provider with the following information during the

registration process:

The IP address of the FTP server which BSC Central Services should push to

The username and password that BSC Central Services should use to login to

the server

The relative or absolute path to the directory which files should be initially

pushed to (the equivalent of the temp directory used on the BSC Central

Services server for file submission)

The relative or absolute path to the directory which files should be renamed

to after initial transfer (the equivalent of the inbox directory used on the BSC

Central Services server for file submission).

If these details are to be changed during operational use, the new details should be

provided to BSC Central Services with at least 48 hours notice.

The method used by Central Services to push files is as follows:

Place the file in the Participant’s outbox on the BSC Central Services FTP

server

Deliver the file directly to the Participant FTP server using the same

push/rename technique required for Participant file transfers.

Delete the file from the BSC Central Services FTP server if the push was

successful.

This allows flexibility for the Participant in the event that their FTP server becomes

unavailable, in which case the files remain on the BSC Central Services server ready

to be collected manually.

Although the FTP push process is convenient, many Participants prefer to poll the

BSC Central Services FTP server themselves since this allows them greater

flexibility to move operations between their own production and disaster recovery

environments without reconfiguration from the Service Provider. If the High Grade

Push process is used it should be noted that the delivery of a file is considered

complete under BSC Central Services’ SLAs at the point that it is placed on the BSC

Central Services FTP server (i.e. if the Participant server is unable to accept the

pushed file, this does not constitute a failure of deemed receipt under the BSC).


IF-00000018 / Definitive 12.5 24/10/17


page 26 of 45

5.1.4 Shared S0142 Files

S0142 data is available to all BSC Parties (i.e. Participants with Participant IDs

holding a BP role). Since this data is not required by all Participants, coupled with

the large size of S0142 data, it is delivered differently than other files. Parties may

access the S0142 area of the BSC Central Services FTP server, which contains a

rolling 7 days worth of compressed data. It is not available via the FTP push method.

The S0142 data is stored in the /S0142/outbox directory on the server, which can be

accessed after initial login using the command cd ../S0142/outbox.

The S0142 files do not have normal recipient details in the header (AAA) record.

Instead, the To Participant ID is set to DOWNLOAD and the To Role Code is set to

PB. The files are read only, so cannot be deleted once copied - they’re needed for

other users. All users see the same directory and the same files. Participants must

keep track of which files they have already downloaded to avoid repeated retrieval of

the same file on successive days.

These files have meaningful names to assist in the identification of required files -

the file name will take the form “YYYYMMDD_RR_YYYYMMDDHHMISS.gz”

where YYYYMMDD is the settlement date, RR is the settlement run type (e.g. II, SF

etc) and YYYYMMDDHHMISS represents the file creation datetime. The file

extension “.gz” indicates the use of the “gzip” compression utility.

The S0142 files stored on the BSC Central Services FTP service are not encrypted.

5.2 XSec Software

The XSec software distributed by the Service Provider is required for all incoming

and outgoing files. Operation and configuration of this software are covered by its

own documentation, but this section provides a brief overview of its features and

usage.

5.2.1 Application Overview

The XSec application uses PGP based public key encryption and signing to secure

the contents of files transferred between Participants and BSC Central Services. It

operates as a Windows service and is compatible and tested with Windows 7 as well

as Windows 2008 and Windows 2012. It uses the .NET framework 4.0.

It uses a file based interface, polling input directories to look for files to

encrypt/decrypt, and placing the processed files into output directories where it is

assumed that other processes will pick them up.

For reliability, processes delivering files to XSec should always place files using

instantaneous move operations to avoid the possibility of part written files being


IF-00000018 / Definitive 12.5 24/10/17


page 27 of 45

processed. XSec contains some protection against this, but in general it should be

ensured that XSec’s input directories are not written into directly.

BSC Central Services allows for this in the FTP push process described above by

initially transferring the file to a temporary directory before renaming to a final

destination. This final destination directory can be an XSec input directory.

5.2.2 Integration with Other Processes

XSec sits between the Participant’s business software and the process which transfers

files to and from BSC Central Services Central Services as per the diagram below:

5.3 Tibco Rendezvous Software

The High Grade Participant’s Tibco RVRD server connects to the BSC Central

Services Central RVRD to send subscriptions and receive real-time BMRS data. This

software is covered by its own documentation which is provided to Participants on

request, but this section covers some high level technical considerations for the

Participant to be aware of in usage of the RVRD.

5.3.1 Approval of New RVRDs

Before configuring or connecting a new Tibco RVRD, the Participant must contact

the Service Provider through the BSC Central Services helpdesk. The Service

Provider will work with the Participant to ensure that this new RVRD will not cause

any problems or conflicts to Participant or BSC Central Services infrastructure, and

will configure access to the BSC Central Services RVRD.

5.3.2 RVRD Unique Naming

If the Participant chooses to use more than one Tibco RVRD, they must ensure that

these RVRDs are configured with unique names on the BSC Central Services Tibco

network. Presence of multiple RVRDs with the same name leads to conflicts which

can cause loss of data and disruption of the RVRD network.

5.3.3 Offline/Standby Servers

The Participant should consult the Service Provider and the Tibco User Guide [TUG]

about offline or standby servers installed with the Tibco software. This is to ensure

that licensing rules are being correctly interpreted and to ensure that no situation can

occur where the standby server might become active at the same time as another

server with the same RVRD name.


IF-00000018 / Definitive 12.5 24/10/17


page 28 of 45

5.3.4 BMRS Subject Naming

The messages distributed via the Tibco application are divided into logical segments

using Tibco subject names. These are dot (.) delimited text strings which split BMRS

data into hierarchical structures.

This can be useful for data analysis if the Participant is using the data for an

application such as a Tibco connector into their own application or database. This

subject naming is covered in detail in the Tibco documentation supplied by the

Service Provider during registration and in the BSC Interface Definition Documents

(IDD) available from ELEXON’s website.


IF-00000018 / Definitive 12.5 24/10/17


page 29 of 45

6 Participant Disaster Recovery

The architecture used by BSC Central Services allows for Participants to provide

resilience to disaster in their own systems. This section explains options that the

Participant may wish to consider when designing their BSC Central Services

infrastructure.

6.1 High Grade Push/Pull Switching

High Grade Participants are permitted at any time to switch between the push and

pull modes of BSC Central Services file delivery by contacting the BSC Central

Services helpdesk and requesting the change. This must be authorised by a BSCP38

Category A authorised signatory for the Participant ID/s in question. In emergencies

this change can be carried out quickly, but Participants should ideally try to provide

at least 48 hours notice.

Requesting a switch from push to pull is not necessary in some DR scenarios such as

a loss or failure of the Participant’s FTP server (since in the event of failure to push

files, these files will be left on the BSC Central Services FTP server ready for pull),

but it is realised that a Participant may wish to carry out a more controlled cutover

under some circumstances, for example where their live FTP server is still active, but

they wish to use their DR site.

Similar authorisation and notice should be provided when the Participant wishes to

resume their original configuration.

6.2 High Grade Push to a Different Server

If a Participant has two sites on the BSC Central Services High Grade network and

uses the FTP push option to have files delivered to their main server, then a move to

their DR site will require the Participant to inform the Service Provider of the

alternate IP address, login and directory structure details of the DR server if they

wish files to be pushed to their DR site.

This is achieved by calling the BSC Central Services helpdesk, and in emergencies

can be carried out at short notice. Authorisation from a BSCP38 Category A

authorised signatory for the Participant ID in question is required.

It is highly recommended if a Participant wishes to use a DR facility that they do not

use FTP push mode. Using pull mode instead provides greater flexibility for moving

to DR without dependence on the Service Provider.

6.3 High/Low Grade Switching

All High Grade Participants are also automatically configured to be able to use the

Low Grade internet based service, and in the event of a complete failure of access to

the High Grade service the Participant may use the Low Grade FTP and web services

as a disaster recovery strategy.


IF-00000018 / Definitive 12.5 24/10/17


page 30 of 45

If the Participant wishes to use this as a disaster recovery strategy, they should ensure

that their networks and firewalls are configured to allow their systems to access both

networks. In most cases all that is required to switch to using the Low Grade service

is a change of target from the High Grade IP addresses to the Low Grade IP Address

(or preferably the Fully Qualified Domain Name for the Low Grade service). No

involvement is required from the Service Provider for this type of switch.

The change from high grade to low grade, or vice versa, does not affect the file

sequence numbers used for file transmissions. If there is any doubt as to which files

have been transferred then the Participant operations staff will need to liaise with the

Service Provider’s staff, via the BSC Central Services helpdesk, to establish the most

recent file received of each type.

6.4 Resilient High Grade Networking

If a Participant wishes to use more than one connection to the High Grade network in

order to provide a disaster recovery position or improve their resilience, the Service

Provider can work with them to find a suitable option.

The BSC Central Services networks team, contactable through the BSC Central

Services helpdesk, can advise on these and other advanced network configurations.


IF-00000018 / Definitive 12.5 24/10/17


page 31 of 45

7 Overview of Manual Data Flows

At times it will be necessary to perform manual communications between the

Participants and BSC Central Services. The following are the types of manual

interface that can be used:

E-mail

Fax

Post.

All manual data flows sent by Participants to the BSC Central Services must have a

unique reference number provided, in an alphanumeric format with a maximum of

ten characters.

Some manual data flows may be sent electronically. However, only those listed in

the flow role tab of the Interface Definition and Design (IDD) spreadsheet are

supported.

7.1 E-mail Communications

Upon receipt of an e-mail, the sender’s details will be checked against the

authorisation register within CRA. If the sender is an authorised party, then the e-

mail will be positively acknowledged. If the authorisation check fails, a negative

acknowledgement will be sent.

Please note, e-mails must contain the manual flow as an attachment and not inputted

as text into the body of the e-mail.

E-mails will be acknowledged using the standard manual acknowledgement process.

See section 7.4.

Following acknowledgement, the e-mail will be forwarded to the relevant team for

processing.

The BSC Central Services e-mail address that Participants must use for BSC Central

Services related manual flows is [email protected]

Note: E-mail is not secure so authentication is limited. For some flows this is not an

appropriate method of communication. Email may only be used for defined manual

flows and ad-hoc communications.

7.2 Fax Communications

Faxed flows must be sent to a dedicated BSC Central Services fax number. This will

interface with the CGI Consortium e-mail system such that the fax is presented as an

attachment to an e-mail.

From this point onwards the process is the same as for the e-mail medium.


IF-00000018 / Definitive 12.5 24/10/17


page 32 of 45

The BSC Central Services fax number that Participants must use for BSC Central

Services related manual flows is 0870 8335601.

7.3 Postal Communications

All post must be addressed to specific BSC Central Services addresses.

Manual communication flows which involve BSCP form submission (with the

exception of forms submitted through the Online Forms service) should be addressed

to:

Central Registration Agent (or CDCA as appropriate)

The BSC Central Services

IMServ Europe Ltd

Scorpio

Rockingham Drive

Linford Wood

Milton Keynes

MK14 6LY

United Kingdom

All manual communications flows not resulting in a BSCP Form submission should

be addressed to the BSC Central Services Help Desk at:

BSC Central Services Helpdesk

CGI

Moor Road

Waterton Industrial Estate

Bridgend

CF31 3LQ

From the point of receipt, the process is the same as for the e-mail media.

7.4 Manual Acknowledgement Process

Each Participant/role combination will have one manual acknowledgement route,

which will be fax or e-mail. When Participant’s initially register with CRA they will

be required to provide an e-mail address and fax number, which will be used for

manual acknowledgements. E-mail will be the preferred method for communicating

manual acknowledgements. However, if an e-mail address is not provided then

acknowledgements will be sent via fax.

All manual acknowledgements, irrespective of the input media sent will be sent to

the address using the standard acknowledgement media (fax or e-mail).

The acknowledgement will be a standard format Word document containing the

following information:


IF-00000018 / Definitive 12.5 24/10/17


page 33 of 45

Flow type

Participant’s sending reference ( as detailed above)

Acknowledgement reference (unique reference generated by BSC Central

Services)

Date/time received.

The date and time of sending of the manual acknowledgement will be recorded.

7.5 Security

The management and handling of all incoming manual information is covered by the

ISO27001 and ISO17799 security accreditation of the organisations processing this

information.

Security is built into this process through:

Restriction of e-mail access to authorised users only for both incoming and

outgoing media

Secure routing of faxes directly to e-mail

Routing of incoming post to authorised users only

Secure routing of acknowledged data to authorised users only

Storage of paper communications in a fire safe.

7.6 Manual Flows to Participants

Each Participant/role combination will have one manual message route, which will

be fax or e-mail. All manual messages will be sent to the address using the standard

message media (fax or e-mail).

The method for communicating manual flows to Participants, is detailed in section

7.4.


IF-00000018 / Definitive 12.5 24/10/17


page 34 of 45

8 Overview of Electronic Data Flows

A common format is used for data files transferred electronically between the BSC

Central Services and the BSC Parties and their Agents. These files use the ASCII

character set. They consist of:

A standard header

A collection of data records using standard format

A standard footer.

The format of these files and individual record arguments are specified in the

Interface Definition and Design (IDD). The IDD is listed in the references section of

this document, and is available at:

http://www.elexon.co.uk/bscrelateddocs/URSIDD/

This section details some of the core information from these documents, along with

important considerations in the generation and processing of the data flows.

8.1 Sequence Numbering

Since the order in which flows are processed can have an important effect on

processing, BSC Central Services uses file sequencing to ensure that all files are

processed in the intended order. All flows to and from BSC Central Services contain

a sequence number in the header record of the file, which wraps around to zero when

it reaches its maximum limit.

A separate sequence series is used for each combination of source Participant ID,

source role code, destination Participant ID and destination role code. So, for

example flows in different directions between a specific BSC Central Services role

code and a specific Participant role code would operate using different sequence

series.

The exception is the case of receipt acknowledgement files, which carry the sequence

number of the file being acknowledged.

Sequence numbering is independent of the method of delivery, so Participants

switching between the High and Low Grade services do not need to reset their

sequence numbers.

There is no automatic process by which the BSC Central Services will alter the value

of any next expected sequence number which it holds (either up or down), apart from

the normal increment when a file is received with a valid header. The only method

by which a BSC Party or Agent can achieve a change in the value of the next

expected sequence number held by a BSC Central Services will be by manual

agreement, via the BSC Central Services Help Desk.


IF-00000018 / Definitive 12.5 24/10/17


page 35 of 45

8.2 Sequence Handling

It is accepted that in some circumstances it may be possible for files generated by

BSC Central Services or by the Participant to be received by the other party out of

sequence order. In this circumstance the receiving party should negatively

acknowledge the file as being out of sequence, but to improve the resilience and

automation of the sequencing system BSC Central Services has a sequence handling

procedure to allow some flexibility for flows submitted in an incorrect order.

The system described is that used by BSC Central Services. It is highly

recommended that Participant software incorporate a similar system.

If a file is received by BSC Central Services with a sequence number greater than

that expected for the given sequence series, it is not automatically negatively

acknowledged. Instead, it is put in a holding queue to wait for the next expected

sequence numbered file to arrive.

If after a specified number of out of sequence files are received, or after a specified

period of time has elapsed (whichever occurs sooner), the next expected sequence

number has not been received then any out of sequence files which have been in the

holding queue are negatively acknowledged as being out of sequence.

The values used by BSC Central Services for this purpose are 99 files (variable upon

request per Participant) or 13 minutes. These values are chosen by BSC Central

Services to comply with the service levels required for acknowledgement of files

submitted by Participants, but are a good suggested starting point for Participants

implementing a similar system.

Factors which would affect the choice of values for a Participant would be the

volume of files transferred during a typical delivery and criticality of alerting their

users should a problem occur.

8.3 Acknowledgements

As discussed above, each flow (other than an acknowledgement itself) sent to or

from BSC Central Services expects a response file to be generated to acknowledge

successful or unsuccessful receipt. The scope of this acknowledgement is to indicate

that the file is in the correct format, that its sequence number is that expected and that

its data integrity can be verified (by means of a checksum in the footer record). An

acknowledgement, sometimes referred to as a “Comms Ack” from BSC Central

Services does not signify that the data within the flow has been accepted. This is

notified via other flows such as ECVAA acceptance feedback reports.

The acknowledgement file format is specified in detail in the BSC Central Services

Interface Definition and Design (IDD) documents. Each file consists of:

A header (AAA) record which among other information contains the name

and sequence of the flow being acknowledged


IF-00000018 / Definitive 12.5 24/10/17


page 36 of 45

An acknowledgement (ADT) record which specifies the type of

acknowledgement being provided, response codes indicating positive or

negative receipt and optional description of errors

A standard footer record containing a checksum for the flow.

8.4 Handling Negative Acknowledgements

The progression of sequence numbers following a negative acknowledgement from

BSC Central Services depends on the nature of the error in the original file (which is

specified in the acknowledgement code of the ADT record).

If a file is rejected because of problems with the HEADER, the sequence

number is not "used" and so the next expected sequence number remains

unchanged. [NACK codes 1,2,3]. A corrected file (with the same sequence

number) should be submitted next.

If a file is rejected because of problems with the BODY or TRAILER (record

count, checksum), the sequence number is used and the next expected

sequence number is incremented. [NACK codes 4,5,6,7] A corrected file

(with a new sequence number) should be submitted next.


IF-00000018 / Definitive 12.5 24/10/17


page 37 of 45

9 Networking Information

This section provides more detailed information to assist network administrators in

the ordering, configuration and usage of the BSC Central Services electronic

interfaces.

9.1 High Grade

After registering interest for a High Grade service with ELEXON, but before placing

an order, the Participant will be contacted by the Service Provider to arrange for

installation of communications lines to the Participant’s site.

9.1.1 Information and Site Access

The information initially required by the Service Provider will include:

The exact termination point (specified down to the room) where the

communications lines and router are to be installed

Site contact details

Site access details, including timescales and any special requirements for

engineers accessing the Participant site

Specification of the lines and router required.

As described earlier in this document, the standard communications product supplied

to the Participant is a 2Mbps Leased Line with a 2Mbps 20:1 contended ADSL

backup, presented through a Cisco 2801 router.

The lead time for installation of this standard circuit is 55 working days, and the

order can only be placed with the communications supplier after technical details

have been confirmed. It is not necessary at this early stage for an IP schema to be

agreed, this can be planned during the order process.

Access to the BSC Central Services High Grade network can only be achieved

through the Service Provider, and the sole supplier used is Vodafone. Tails are

provided primarily by Vodafone and BT, but other tail providers may be used if the

need arises.

9.1.2 Features and Specifications

The standard Cisco 2801 router provided to the Participant is completely managed

through the Service Provider. The Participant cannot manage, login or configure the

router.

The Cisco 2801 router is rack mountable and only has provision for one power

supply (a dual powered router requires an upgrade to a much more costly model).


IF-00000018 / Definitive 12.5 24/10/17


page 38 of 45

The Service Provider supports delivery of service to the Ethernet port on the router

provided, but the Participant is responsible for keeping the router constantly powered

and in an appropriate environmental setting.

The network termination equipment provided for Frame Relay and ISDN lines varies

dependant upon line access speed and site requirements.

9.1.3 Planning an IP Schema

The BSC Central Services High Grade WAN primarily uses the 10.x.x.x RFC1918

private address space, and by default the LAN side of the router provided to the

Participant will be assigned a 24 bit masked (254 usable address) subnet on this

network, the first address of which will be reserved for the Ethernet port of the BSC

Central Services router.

The Service Provider is flexible to the needs of the Participant’s existing

network, and anticipates that it may need to conform to the Participant’s

existing IP schema. In this case a Participant defined IP schema will be used,

and the Service Provider will use Network Address Translation (NAT) on the

router that they provide.

The Service Provider will discuss IP schema selection and design with the

Participant when the High Grade order is placed, or may be contacted before this

point through the BSC Central Services helpdesk.

9.1.4 Firewall Configuration

The High Grade Participant should use the table below when planning the rulebase

for the firewall interfacing with the BSC Central Services router (Note that this is a

complete list of services. Network administrators should consult with those planning

to use the services, which of these are required):

Service Direction BSC Central Services IP Port

FTP Pull Outbound 10.1.1.20 TCP/21

FTP Push Inbound 10.1.1.21 & 10.1.1.22 TCP/21

FTP (Testing) Outbound 10.2.1.21 TCP/21

Tibco BMRS Outbound 10.1.1.31 TCP/7590

Time Sync Outbound 10.1.1.51/10.1.1.52 UDP/123

ECVAA Web Outbound 10.1.1.45 TCP/443

Note: Additional rulebase configuration may be required if the Participant intends to

access the Participant Test Service.


IF-00000018 / Definitive 12.5 24/10/17


page 39 of 45

9.1.5 Provision for BSC Central Services Disaster Recovery

If BSC Central Services invokes their Disaster Recovery plan, no action is required

by the High Grade Participant. If employed, the BSC Central Services Disaster

Recovery site will be address translated and presented to the Participant as if it were

the Live service site. No IP configuration or firewall rulebase changes are required

by the Participant.

9.2 Low Grade

Low Grade Participants provide their own internet connectivity in order to be able to

use the internet based Low Grade service. The following provisions should be made.

9.2.1 Firewall Configuration

The Low Grade Participant should use the table below when planning the rulebase

for the firewall interfacing with the internet (Note that this is a complete list of

services. Network administrators should consult with those planning to use the

services, which of these are required):

Service Direction BSC Central Services

Address

Port

FTP Pull Outbound ftp.bmreports.com TCP/21

FTP (Testing) Outbound ptsftp.bmreports.com TCP/21

Time Sync Outbound Participant’s Discretion UDP/123

BMRS Web Outbound http://www.bmreports.com TCP/80

ECVAA Web Outbound https://www.ecvaa.com TCP/443

ELEXON

Portal

Outbound https://www.elexonportal.co.uk TCP/443

BMRS API Outbound https://api.bmreports.com TCP/443

Note: Additional rulebase configuration may be required if the Participant intends to

access the Participant Test Service.

9.2.2 Provision for BSC Central Services Disaster Recovery

Wherever possible the Low Grade Participant should use the Fully Qualified Domain

Names (FQDNs) in the table above when configuring their software and connecting

to BSC Central Services.


IF-00000018 / Definitive 12.5 24/10/17


page 40 of 45

If BSC Central Services invoke their Disaster Recovery plan, the IP addresses of

these services will change, but the fully qualified names will map to the new IP

addresses.

The table below shows the normal IP address mappings for the fully qualified

domain names above, however the most reliable way of obtaining the correct IP

addresses is performing DNS queries on the FQDNs:

FQDN IP Address

www.bmreports.com 163.164.233.155

ftp.bmreports.com 163.164.233.162

www.ecvaa.com 163.164.233.168

www.elexonportal.co.uk 163.164.233.163

api.bmreports.com 163.164.233.156

http://www.elexonportal.co.uk/


IF-00000018 / Definitive 12.5 24/10/17


page 41 of 45

10 Summary Overview – Steps in the Comms Setup Process

This section briefly shows the steps that a Participant should plan for during the

comms setup process. They assume entry of a completely new Participant and do not

directly apply to other circumstances, such as addition of Participant IDs for existing

users.


IF-00000018 / Definitive 12.5 24/10/17


page 42 of 45

11 Service Desk

For further information relating to communications with the BSC Central Systems

please contact the BSC Service Desk on 0870 010 6950 or by email at

[email protected].


IF-00000018 / Definitive 12.5 24/10/17


page 43 of 45

Appendix A - Schedule of Specified Communication Charges

This schedule sets out the rates of the High Grade Line Monthly Charges, TIBCO Set-up Charge and TIBCO Software Support Charge from 1 April 2017 until 31 March 2018 as determined by the Panel in

accordance with Sections 3.1(d), 3.1(e), 3.3 and 3.4 of Annex D-3 of the Code.

1 High Grade Line charges from 1 April 2017 until 31 March 2018

BSC Parties and non-BSC Parties (“Participants”) may choose from the following High Grade Service i

lines set out in the following table:

Technical Specification HG10 DR10

Primary Line Rental:

10Mb leased Line

2Mb ADSL

Backup Line Rental:

2Mb ADSL Backup

Support:

5 Hour Fix on Primary Line

24 Hour Fix on Primary Line

Primary Line Uncontended

Primary Line is Contended

One-off Costs:

Installation £4,208 £776

Ongoing Annual Costs:

Annual Rental (2017/18): £5,882 £2,440

Annual Support: (2017/18) £1,000 £1,000

Total Rental + Support

(2017/18) £6,882 £3,440

Table 1 – High Grade Line Monthly Charges (2017/18)

1.1 Disaster Recovery (“DR”) options set out in Table 1.1 above indicate that these

configurations shall usually be installed at DR sites and may not be installed without a High

Grade Service line.

1.2 The Code requires Participants to pay the Dataline Monthly Charge for a minimum of 12

months in accordance with Section 3.3(a) (ii) of Annex D-3 of the Code.

1.3 The Dataline Monthly Charge consists of:

i High Grade Service – means the provision of a communications capability between a BSC Service User and the BSC Central Systems using dedicated lines over a private WAN network.


IF-00000018 / Definitive 12.5 24/10/17


page 44 of 45

An Installation charge (which is charged as a one-off lump sum);

An Annual Rental charge (which is charged on an ongoing monthly basis); and

An Annual Support charge (which is also charged on an ongoing monthly basis).

1.4 If requested, ELEXON shall provide users with “non-standard‟ line configurations. These are not included in the standard menu of options shown in Table 1.1 above. Section 6 of Annex

D-3 of the Code allows ELEXON to charge Participants for the exact additional costs incurred from the BSC Central Services Agent to reflect the Installation charges, Annual Rental

charges and Annual Support charges for the non-standard configuration. The Installation charge is charged as a one-off lump sum. Any ongoing rental and support charges shall be

charged monthly whilst the service is used.

1.5 Please note that the standard menu of options in Table 1 does not cover the older suite of standard High Grade Line options which existing Participants may have previously opted for.

From 1 April 2017 only these two standard High Grade Line options can be selected by Participants.

1.1 Application of Indexation from 1 April 2018 until 31 March 2019 onwards

1.2.1 Installation charges and Annual Rental charges are fixed until 31 March 2018.

1.2.2 These charges shall be adjusted for indexation, using the Computer Economics Limited

Index (“CEL”) and the Retail Price Index (“RPI”) measures from 1 April of each year.


IF-00000018 / Definitive 12.5 24/10/17


page 45 of 45

2 TIBCO Charges

2.1 Options for Participants

2.1.1 Participants may obtain a High Grade Service line and support service from ELEXON without acquiring TIBCO Software Inc (“TIBCO”) Rendezvous software.

2.1.2 If Participants do require a licence to use the TIBCO Rendezvous software, it can be purchased from TIBCO through ELEXON (via the BSC Central Services Agent), however there

is no requirement to procure a licence to use the TIBCO Rendezvous software from ELEXON.

2.2 TIBCO Charging Methodology – TIBCO Set-up Charge

2.2.1 If Participants procure a licence to use the TIBCO Rendezvous software through ELEXON

they shall be charged at the prevailing TIBCO list price for the licence at the time the licence is procured. This will be levied as a one-off charge.

2.3 TIBCO Charging Methodology - TIBCO Software Support Charge

2.3.1 The TIBCO Software Support Charge for each TIBCO Rendezvous software licence procured by a Participant through ELEXON (via the BSC Central Services Agent) is subject to an

annual increase in line with the applicable TIBCO Indexation measure for the 12 month period immediately preceding the anniversary date of the maintenance and shall be charged

monthly.

Need more information?

For more information please contact the BSC Service Desk at [email protected] or call 0870

010 6950.

Intellectual Property Rights, Copyright and Disclaimer

The copyright and other intellectual property rights in this document are vested in ELEXON or appear with the consent of the copyright owner. These materials are made available for you for the purposes of your participation in the electricity industry. If you have an interest in the electricity industry, you may view, download, copy, distribute, modify, transmit, publish, sell or create derivative works (in whatever format) from this document or in other cases use for personal academic or other non-commercial purposes. All copyright and other proprietary notices contained in the document must be retained on any copy you make.

All other rights of the copyright owner not expressly dealt with above are reserved.

No representation, warranty or guarantee is made that the information in this document is accurate or complete. While care is taken in the collection and provision of this information, ELEXON Limited shall not be liable for any errors, omissions, misstatements or mistakes in any information or damages resulting from the use of this information or action taken in reliance on it.

mailto:[email protected]