BOB – S2S Overview May 25, 2004 Gaming Technology Summit.

BOB – S2S OverviewBOB – S2S Overview

May 25, 2004May 25, 2004

Gaming Technology Summit


What is BOB?

What is S2S?

BOB & S2S Message Handling

BOB Command Set – Version 1

S2S Command Set – Version 1

Questions and Answers

What Is BOB?What Is BOB?

BOB = Best Of Breed

Communications between EGMs and back-end servers

Designed to replace existing protocols

Based on current, proven technology standards; XML, TCP/IP, HTTP, etc

Supports high-speed communications by multiple back-end servers

Consists of three components: BOB Message Standards – version 1 complete BOB Transport Standards – HTTPS/SOAP complete BOB Configuration Standards – in process

What Is S2S?What Is S2S?

S2S – System To System

Communications between back-end servers

Based on current, proven technology standards; XML, TCP/IP, HTTP, etc

Supports high-speed communications amongst back-end servers

Designed to complement and support BOB

S2S and BOB use common message handling methodologies

Consists of two components: S2S Message Standards – version 1 complete S2S Transport Standards – in process

What Is BOB? What Is S2S?What Is BOB? What Is S2S?

EGM

Progressive

Accounting

Player Tracking

Tickets

BOB

BOB

BOB

BOB

Kiosk

Coin/Bill

CountersS2S

S2S

S2S

S2S

S2S

BOB & S2S Message HandlingBOB & S2S Message Handling

Messages are used to deliver one or more commands

Commands can be requests and/or responses

Many commands are organized into request-response pairs; two-way

Other commands do not require responses; one-way

Multiple unrelated commands can be bundled into a single message

BOB & S2S Message HandlingBOB & S2S Message Handling

Outbound

Command

Queue

Inbound

Command

Queue

Command

Processor

Inbound

Command

Queue

Outbound

Command

Queue

Command

Processor

2. bobMessage

3. bobAck

1. Request 4. Request

5. Response

6. bobMessage

7. bobAck

8. Response

BOB Command Set – Version 1BOB Command Set – Version 1

device Class – used to identify the logical and physical devices contained in an EGM and to subscribe to the commands generated by a device.

communications Class – used to establish and maintain communications between an EGM and a back-end server.

cabinet Class – used to report the state of the cabinet and EGM access doors.

processor Class – used to report the state of the central processor and to set the themes, paytables and denominations offered by the EGM.

meters Class – used to subscribe to and report performance, transfer, note and cabinet meters using onDemand, onPeriodic, onEvent, onChange, onAudit methods.


coinAcceptor Class – used to configure and report the state of coin acceptors.

noteAcceptor Class – used to configure and report the state of note acceptors.

hopper Class – used to configure and report the state of hoppers.

printer Class – used to configure and report the state of printers and to print customized receipts.

handpay Class – used to process jackpots and cancelled credit including remote jackpot key-offs.


progressive Class – used to report and process progressive jackpot hits.

bonus Class – used to configure, report and process bonus awards.

player Class – used to configure and report player tracking events including countdowns, point awards, hot players, abandoned cards and direct messages.

voucher class – used to process and report payment voucher (ticket) issuance and redemption.

WAT Class – used to process and report wagering account transfers.

GAT Class – used to process and report game authentication commands.

Messages SAS vs. XML BOBMessages SAS vs. XML BOB

Example of XML for metersExample of XML for meters

Client request and server response in XMLClient request and server response in XML

<bobBody>

<getMeters>

<getPerformanceMeter denom="*"

name="coinIn"

payTable="" theme=""/>

</getMeters>

</bobBody>

<bobBody>

<meters cabinet="4321" currency="001">

<performanceMeter name="coinIn" denom="01>

500000

</performanceMeter>

<performanceMeter name="coinIn" denom="02" >

400000

</performanceMeter>

<performanceMeter name="coinIn" denom="03">

300000

</performanceMeter>

<performanceMeter name="coinIn" denom="04">

200000

</performanceMeter>

</meters>

</bobBody>

BOB in the future: A Phased ApproachBOB in the future: A Phased Approach

BOB – Phase 1 (XML Core) Compatible with current protocol solutions Includes basic player tracking functions

BOB – Phase 2 (Transport and Tools) Toolkit for developers Tools for compliance/approval testing Physical layer (Ethernet), IP transport, addressing Serial BOB

BOB – Phase 3 (Download) Automated configuration Download Games and Peripherals Class II, Lottery and central determination message sets

S2S Command Set – Version 1S2S Command Set – Version 1

communications Class – used to establish and maintain communications between back-end servers.

configuration Class – used to transmit application configuration data; employees, junkets, groups, clubs, chip sets, gaming tables, EGMs, comp items, etc.

patron Class – used to transmit patron registration and demographic data; mailing addresses, phone numbers, e-mail addresses, identification, images, comments, account balances, stop codes, etc.

openClose Class – used to process table game openers and closers and to record periodic headcount and win/loss estimates.

fillCredit Class – used to process table game fills and credits.

S2S Command Set – Version 1S2S Command Set – Version 1

marker Class – used to process patron markers, redemptions, chip purchase vouchers and document transfers.

playerRating Class – used to process player rating information for table games, EGMs, poker, bingo, keno, sports book and race book.

jackpot Class – used to process table games progressive jackpots.

comp Class – used to issue, redeem and void patron comps

Regulatory Advisory Regulatory Advisory Committee Committee

Mark Pace – RAC Chairman

RAC CommitteeRAC Committee

Charter

The GSA Regulatory Advisory Committee’s purpose is to ensure that all

standards adopted by the Association are compliant with known

jurisdictional requirements. In addition the committee will provide

regulators access to GSA technology education and establish a forum in

which regulators, manufacturers, systems providers and operators can

collaborate to address industry issues.


Mechanism for open dialogue between Regulators and GSA

Regulators are unwilling to formally participate in GSA due to impartiality concerns

Regulators are eager to learn about what GSA is working on and to provide input

RAC chair has been positioned as the Regulator’s point of contact within GSA

Routine one-on-one calls to each Regulatory body has been effective in identifying their concerns, creating demand for detailed information on BOB, and making headway in having regulators seek the Association’s input.

RAC CommitteeRAC CommitteeFeature/Functionality BOB SAS BESS

Open Standard Protocol Yes No No Additional messages can be added without requiring Protocol modification

Yes No No

Data is received as soon as transaction occurs (Transaction based)

Yes No

Polled No

Polled Serial Serial Serial Electronic Gaming Machine data can be transmitted over:

(See Notes - # 1) Ethernet

<= 0.0096Mbps >= 0.0096 Mbps <= 0.0096 Mbps <= 0.0192Mbps <= 0.0192 Mbps

Communication speed supported (See Notes - #2)

>=100.0000Mbps RS232 RS232 RS232

RS422/485 RS422/485 TTL TTL

Communications network types supported (See Notes - #3)

TCP/IP Messages are human readable (See Notes - #4) (See Appendix A)

Yes Standard XML

No Must decode

No Must decode

Can request and accept EGM meter information Yes Yes Yes Can request and accept EGM configuration and identification information

Yes Yes Yes

Supports EGM control functions (See Appendix B) Yes Limited Limited Can request and accept EGM peripheral device information

Yes No No

Supports EGM Peripheral Device Control (See Appendix C) (See Notes - #5)

Yes Limited Limited

Supports at machine and remote authentication of single game, and each game in a multi-game, firmware (G.A.T.)

Yes No No

Cashless/Progressive/Bonusing support (See Appendix D) Yes Limited Limited

Protocol Comparison Document


Requirement Pass Fail Electrical Interference

Must withstand electrostatic discharges of <= 20,000 volts DC discharged through a network with a series resistance of 150 - 1500 ohms shunted by a capacitance of 100 to 150 picofarads, repeated at 1 second intervals.

May exhibit temporary disruption at electrostatic discharges of 20,000 - 27,000 volts DC discharged through a network with a series resistance of 150 - 1500 ohms shunted by a capacitance of 100 to 150 picofarads, repeated at 1 second intervals. EGD must recover and complete play without loss or corruption of any stored or displayed information and without component failure.

Power supply filtering must prevent disruption of the device by repeated AC power being switched on and off. No disruption when a 1 microfarad capacitor, charged to +/- 680 volts DC is discharged between the hot and neutral AC supply lines, at any phase from zero - 360 degrees, with a repetition rate of 30 times per second.

The RNG and random selection process must be impervious to influences from outside the device, including, but not limited to, electro-magnetic, electro-static, and radio frequency interference. The RNG and random selection process must be protected from influence by associated equipment communicating with the EGD.

Coin/Token Acceptors Must accept designated coins/tokens and reject others, and minimize the potential for use of cheating methods such as slugging, stringing or spooning.

Must accept or reject coins/tokens on the basis of metal composition, unless .05 or less, if the EGD is configured to accept more than 20 coins/tokens for a single play.

May not accept more than $3,000 in coins/tokens before a wager must be made or play initiated. Gaming Vouchers

If a wagering instrument is less in amount than that EGD’s smallest denomination then the EGD shall: (a) Immediately reject the wagering instrument if that EGD does not have an odd cents meter; or (b) Allow for the additional accumulation of wagering credits if the EGD has an odd cents meter.

If a wagering instrument is greater in amount than the EGD’s smallest denomination and not evenly divisible by any of the EGD’s denominations then the EGD shall:

(a) Immediately issue a change voucher or coupon if that EGD does not have an odd cents meter and is equipped with a printer mechanism;

(b) Allow for the additional accumulation of wagering credits; (c) Immediately reject the wagering instrument; or (d) Immediately reject the wagering instrument if that EGD is not equipped with a printer mechanism or if the printer mechanism is not functioning for any reason.

Sample Page from US Technical Requirements Document

RAC Committee 2004 ObjectivesRAC Committee 2004 Objectives

Objectives Timeline

Establish a mechanism to ensure a dialogue between GSA and regulators both audit and technical division

Q1/2004

Write a white paper on GSA that speaks to the regulators Q1/2004

Create a protocol comparison document that conveys to regulators ‘at a glance’ the functionality each protocol has.

Q1/2004

Design a document that lists all the US jurisdictional requirements. (GSA to support developing web interface to allow for on-line search for specific regulatory requirements etc.)

Q1/2004

Obtain input into standards GDS, BOB and possibly S2S Q2/2004

BOB – S2S Overview May 25, 2004 Gaming Technology Summit.

Documents

Transcript of BOB – S2S Overview May 25, 2004 Gaming Technology Summit.