G2S Committee - Gaming Standards Association
Download
Report
Transcript G2S Committee - Gaming Standards Association
Committee Updates
Committee Updates
G2S – Dan Milligan
S2S – Kevin Higgins
Transport – Erik Petersen
GDS – Pat Gustafson
CIC – Dennis Kleppen
OAC – Kerry Wolfe
2
G2S COMMITTEE
G2S Committee
Purpose
The purpose of the G2S committee is to define a standard protocol
which various manufacturers can utilize to communicate between host
systems and the electronic gaming machines (EGM’s) on the casino
floor.
G2S’s Role within the GSA Protocol Suite
Defines the command language between EGMs and host systems.
Supports GDS (Gaming Device Standard) to interact with peripheral
devices such as ticket printers and bill acceptors.
Uses the GSA Transport protocol to communicate between EGM’s and
host systems.
Compatible with S2S for communications amongst gaming system.
G2S Committee
Versions
v1.1 – The first widely adopted version of G2S (March 2011).
v2.1 – Contains various extensions, clarifications, and corrections to
v1.1 (April 2012).
Media Display (PUI)
Smart Cards
Tournaments
Employee Tracking
Informed Player
Direct Funds Transfer
G2S Committee
Public Extensions to v2.1
2a – Game audit, logic seal, and illegal door open features.
2b – Extended play (free spin) meter.
2c – Host-controlled clearance meters.
2d – Excessive note reject event.
2e – Additional paytable information.
2f – Additional informed player controls.
2g – Additional wager match and jackpot multiplier meters.
2h – Standalone progressive class.
2i – EMDI communications via WebSockets.
2j – Host to PUI content messaging via G2S
2k – Host to PUI content messaging via EMDI.
2l – Additional game play events via EMDI.
G2S Committee
Public Extensions to v2.1 (continued)
2m – Provide current language selection via EMDI.
2n – Option to require an EMDI connection for PUI content.
2o – PUI content to PUI content messaging via EMDI.
2p – Option to enable PUI content to PUI content messaging via G2S.
2q – Clear player card via EMDI.
G2S Committee
Planned Extensions to v2.1
Support for multiple ID readers in player tracking.
Event to report when a new game has been selected, but not played.
Event to report when an ID reader cannot read a card.
Additional events to report installation script states.
Display formats for option configuration parameters.
Voucher format specifications.
Format for constructing firmware identifiers for peripheral devices.
G2S Committee
Current Issues
WebSockets and More Efficient Message Handling
Currently being evaluated by the Transport and G2S committees.
The objective is to reduce network bandwidth requirements and
command latency.
Relax Command Time-Out Requirements
Precise time synchronization has been difficult to achieve on
gaming networks.
Without precise time synchronization, command time-outs across
are impractical.
S2S COMMITTEE
S2S Committee
Purpose
The purpose of the S2S committee is to define a standard protocol
which various manufacturers can utilize to communicate amongst host
systems as well as other devices, such as kiosks.
S2S’s Role within the GSA Protocol Suite
Defines the command language between systems.
Uses the GSA Transport protocol to communicate between systems.
Supports edge systems that communicate with EGMs using G2S.
Or other protocol.
It doesn’t matter to
S2S
G
2
S
S2S
Back End System
Edge System
S2S Committee
Versions
S2S 1.2 – July 2006
First widely adopted version.
S2S 1.6 – March 2012
Download – allows for downloading of content to a site controller, or
sddp. Also lets you control an edge server or site controller to
download/install packages onto an EGM, or end-client.
SDDP – Creates a normalized language to integrate vendor specific
download servers with a centralized download management server.
playerTracking – Alignment of the existing S2S playerRating and
player classes with G2S.
S2S Committee
General Direction
Cleanup existing classes where appropriate.
Finish aligning existing classes with G2S where it makes sense.
Current Work
Wrap up G2S class alignment and publish v1.7.
Created a standard manifest file format which allows an EGM
manufacturer to include an XML file with their software packages that
can be loaded by a 3rd party Download server.
The file describes the properties of the software, its dependencies,
and how to download/install or uninstall the software.
Investigating other future topics, such as XBRL for financial reporting,
REST-based APIs, etc.
TRANSPORT COMMITTEE
Transport Committee
Purpose
The purpose of the Transport committee is to define standards for pointto-point and multicast communications that can be used to transport
G2S and S2S messages in a secure manner.
Transport’s role within the GSA Protocol Suite
Defines mechanisms for transporting G2S and S2S messages.
Defines standards for using DHCP, DNS, and NTP to configure network
devices.
Defines standards for using network security protocols, TLS, SCEP, and
OCSP to secure communications between end-points.
Transport Committee
Point-to-Point Versions
v1.0.3 – First widely adopted version (June 2007).
v1.1.x – Clarifications to Security and Authentication requirements (Aug
2009).
v1.2 – Clarifications regarding certificates and certificate management
(Aug 2012).
Multicast Versions
v1.0.7 – First widely adopted version (Sep 2006).
v1.1.x – Clarifications (Aug 2009).
v1.2 – Format Changes Only (Aug 2012)
Transport Committee
Accomplishments
Published Point-to-Point Transport v1.2 (Aug 2012)
Published Multicast Transport v1.2 (Aug 2012)
Planned
Publish Point-to-Point Transport v1.3
Add SHA2 w/256 bits as minimum requirement for certificate signing
Added references to structured cabling standards EIA/TIA 568 and
ISO 11801
Added references to IEEE 802.3 (wired, 100 Mbps min.) and 802.11
(wireless, 54 Mbps min.) standards
Transport Committee
Current Issues
Upgrade to the latest security standard (TLS 1.2)
Keep pace with the industry be upgrading to the latest network
security standards
Adopt Lightweight Transport
Full-duplex, WebSocket-based transport optimized for wide-area
networks
Publish certification profiles
Provide standard configurations for which implementations will be
certified: DHCP, NTP, DNS, CA, SCEP, and OCSP
GDS COMMITTEE
GDS Committee
Purpose
The purpose of the GDS committee is to define USB-based serial
protocols used to connect gaming devices with peripheral devices such
as printers, note acceptors and card readers. This should allow true
plug ‘n’ play peripherals for the gaming environment.
GDS’s Role within the GSA Protocol Suite
Defines the command language between peripheral devices and EGMs.
Enable/Disable
Equipment status
CRC32 verification (GAT)
GDS also allows remote firmware upgrades using the USB Device
Firmware Upgrade (DFU) protocol
Compatible with G2S so that peripheral device information can be
relayed to/from the EGM.
GDS Committee
Protocols Included in GDS
GDS Note Acceptor v1.2 (April 2012)
GDS Printer v1.2 (April 2012)
GDS Page Description Language v1.2 (April 2012)
GDS Card Reader v1.2 (April 2012)
GDS Coin Hopper v1.2 (April 2012)
GDS Touch Screen v1.2 (April 2012)
GDS Coin Acceptor v1.2 (April 2012)
GDS Bar Coded Ticket Specification v1.2 (August 2005)
GDS Connector Standard v1.2 (April 2007)
Extensions
GDS Media Window Communication Protocol v1a2
GDS Toolkit – Allows testing of the GDS protocol with various
peripheral devices.
GDS Committee
Current Issues
New GDS Toolkit
Update to latest version of the standard
Used to verify peripheral firmware download
Continuous improvement of current standards
Supporting wider use of protocols in the field
CIC COMMITTEE
CIC Committee
Purpose
The primary objective of this committee is to drive a set of guidelines
and recommendations that enables the industry to provide
interoperable, business solutions to the operator community. The
intention is that this group acts as a higher-level framework around
other GSA committees to drive a consistent interoperability approach.
CIC’s role within GSA
Define and manage the GSA certification policies
Facilitate a forum by which vendors, operators, regulators and labs can
collaborate to validate interoperable solutions
CIC Committee
Existing Information (available on GSA website)
GSA Certification Program
Certified product registry
Certification program guide
Certification process and requirements information
G2S Compliance Verification Tool (CVT) information
CIC Committee
Work In Progress
G2S Compliance Verification Tool (CVT)
Automated product testing tool for protocol compliance
Applicable to the GSA Transport and G2S protocols
Development being done by RadBlue
CIC members review/approve RadBlue deliverables
Tests both EGM and host systems
Core G2S classes available late 2013
All protocol classes scheduled for delivery by mid-2015
CIC Committee
Future Work
Interoperability testing information for end-to-end solutions
Builds on GSA certified product foundation
Define process and requirements for interoperability test results
Establish process for manufacturers/operators/labs performing
interoperability tests to engage with GSA
Define final test report information and format for consistency across
different test efforts
Establish repository for completed test reports
Identify manufacturers/operators participating in each test
Describe overall solution tested with products, configuration, etc.
Provide manufacturer contact information for solution support
Share lessons learned
OAC COMMITTEE
Operator Advisory Committee
Charter
The Operator Advisory Committee facilitates the collaboration between
(GSA member) operators and manufacturers, system providers. The
committee focuses on the functional requirements to ensure that GSA
standards are meeting market demands.
The committee shall:
1. Effectively create and communicate the business value of GSA standards to the
gaming community.
2. Solicit business requirement input from operator members.
3. Prioritize business requirement requests submitted by operator members.
4. Submit priorities to the BOD for review and approval.
5. Ensure alignment between the operator and manufacturer communities.
6. Operate in a manner that benefits the general gaming industry.
7. Educate and encourage non-member operators to join GSA.
8. Advocate GSA standards within the operator’s community.
9. Effectively communicate the business value of GSA standards to the gaming
community created by newly adopted requirements.
Process
How do we do this?
3 – 4 face-to-face meetings every year
3 – 4 conference calls every year
Representatives from:
A cross section of Operators
GSA Technical Committees
Suppliers/Vendors
Regulators
Operator Advisory Committee
Current Focus
Player User Interface (PUI) Standardization Initiative
Update the current PUI Standards to address future Operator
envisioned PUI usage
Creating PUI environment which allows for regulated and nonregulated content to co-exist and provide:
A consistent player experience
Interoperability
PUI functionality works across all vendor EGM’s
Security
Protecting the regulated EGM environment from unregulated and
potentially insecure content
Ability to keep the Regulator happy
Need to demonstrate that the EGM environment is secure and
integrity is assured
Operator Advisory Committee
Regulated Content
Tested by independent lab; approved by Regulator
Slower time to market
Doesn’t change very often
Content’s source is “trusted” or known
For example,
RNG based-side games
Patron management
Un-Regulated Content
Content from 3rd party sources
Not tested by lab or approved by Regulator
Content changes very quickly – lots of operator flexibility
Shorter time to market
For exampe,
Advertising
Twitter feeds
Operator Advisory Committee
Current Focus
Proving feedback and lessons learned on actual implementations of the
GSA protocols
Operators
Regulators
GSA Technical Committees
Future Focus
eGaming
Determining what role the OAC can play in the eGaming space
Operator requirements
Continue to look for ways to add value to current Operator members and
those Operators who are not members yet
In early stages of planning a survey
Determine how the OAC can add value to the operator community
Increase participation in the OAC
Establish priorities for the OAC for the coming year
THANK YOU