BOB – S2S OverviewBOB – S2S Overview
May 25, 2004May 25, 2004
Gaming Technology Summit
BOB – S2S OverviewBOB – S2S Overview
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.
BOB Command Set – Version 1BOB Command Set – Version 1
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.
BOB Command Set – Version 1BOB Command Set – Version 1
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
BOB – S2S OverviewBOB – S2S Overview
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.
RAC CommitteeRAC Committee
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
RAC CommitteeRAC Committee
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