Service Description

asrv.aero

Inbound Passenger Information Service - IPI

Until this note is removed the documentation is a work in progress, and revisions to the documentation will not be tracked.

Namespace: http://www.asrv.aero/webservices/1.0/InboundPassengerInformationService

Document revisions

Date	Description	Author
yyyy-mm-dd	First complete version of the documentation	Ole Nymoen

1. Introduction

Inbound Passenger Information Service is a service offered by an airport to an airline. The service makes it possible for airlines to give airports information about the passengers on an incoming flight. This in turn makes it possible for the airport to offer a better passenger experience, for example by simplifying the transfer process.
The passenger related information that shall be submitted for all incoming flights consists mainly of:

- Passenger names
- Travel documentation
- Baggage information

1.1. Abbriviations used

Abbriviation	Description
DCS	Departure Control System
FOID	Form of Identification
IG	Implementation Guide
IPI	Inbound Passenger Information
PCI DSS	Payment Card Industry, Data Security Standard
PRL	Passenger Reconcile List

1.2. Overview

The service consist of two different operations:

- - SetIPI - which is the preferred operation that should be used, as it forms a well defined and structured interface.
  - SetIIPIFromPRL - which is an alternative operation than can be used by the airline. This operation allows the airline to submit the "PRL-string(s)" to the airport. However, this requires that the airline adheres to any implementaion guide for the PRL format used by the airport. Any implementation guide should clarify elements in RP1719b, restrict which options that may be used and define any optional elements in RP1719b as mandatory.

1.3. Design guidelines and requirements

1.3.1. PCI DSS must be fulfilled

Description:
It is a requirement that the interface makes it possible to fulfill the PCI DSS. Basically this means that masked credit card numbers must be used.

Considerd
Yes. The interface has support for masked credit card numbers.

1.3.2. Support for all relevant travel documentation

Description:
The interface must have support for validation of all relevant travel documentation. The following is used and must be supported:

- - - 2D bar code.
    - Credit card (number)
    - Other cards (feequent flier, co-branded, military)
    - NFC

Considerd
Yes. All these types of travel documentation have been considered. Currently NFC can't be validated using this interface.

1.3.3. Interface must be general and support all airlines and all airports

Description:
The interface must be generic in a way so it can be used by any airline and be used to support all Avinor airports, and not only OSL.

Considerd

Yes. The SetIPI operation is generic and are not relying on any specific ailrine booking- or DCS-system. However, the operation SetIPIFromPRL and the reated Implementation Guide, has only been verified towards the Amadeus Altea DCS-system.

1.3.4. Interface should be simple to understand and use

Description:

The interface should be defined and documented in a way that as much as possible uses current airline nomenclature.

Considered:

Yes. The main elements and naming is taken from the set og IATA recommendation and recommended practices. However, when naming has been found unambigious, calrification have been introduced.

1.4. Implementation considerations

Any implementation of this service MUST use the WSDL and XSD files provided here: WSDL and XSDs

It is however up to the service provider to decide which data elements to actually update. As clients vary wildly in their capabilities most elements are optional

Any service provider should make available documentation about the actual implementation, including:

- - the address of the service.
  - any limitations in the implementation.
  - any limitations on how often a client can use the service.

1.5. Purpose of this service description

This service description has the following purpose:

- - Describe of service in enough detail for a service provider to implement it.
  - Describe the service so that a client (of this service) developer can use it.
  - Make available the WSDL and XSD files necessary to implement and use the service.
  - Make it possible for relevant people at airports, airlines, handlers and other aviation partners to understand the available functionality and then to decide if to implement/use it or not.

1.6. Intended readership

- IT architects
- Developers
- Business architects
- Interested parties in the aviation community

2. Service overview

The figure below shows the available operations on the Inbound Passenger Information Service. The operations are described in detail in Service operations.

3. Service operations

The figure below shows the service interface.

3.1.1. SetIPI (TransData, InboundPassengerInformation): ResponseStatus

Sets information about inbound passengers on the arriving flight.

Parameters:

TransData: Metadata about the transaction (this operation).
InboundPassengerInformation: Contains:
- FlightLegIdentifier: Identifies the arriving flight
- InboundPassengerData [1..*]: Information about at least one passengers on the arriving flight and any checked baggage. All boarded passengers should be included.

Returns: ResponseStatus - See definition under "Data entities".

3.1.2. SetIPIFromPRL (TransData, prlData: String): ResponseStatus

Sets information about inbound passengers on the arriving flight.

Parameters:

TransData: Metadata about the transaction (this operation).
prlData: String
XML string containing the PRL (Passenger Reconciliation List) data. The exact format of this string must be defined as part of the contract between the airport (server side) and the airline (client side), typically in a separate document.

Returns: ResponseStatus - See definition under "Data entities".

4. Data entities

4.1. BaggagePoolData

BaggagePoolId	A number identifying a group of persons which have their baggage pooled. The number is unique within the flight. (I.e. all persons belonging to this group have the same BaggagePoolId). Note! BaggagePoolId should not be confused with the term "PassengerGroupId" which is used to group passengers for seating purposes.
HeadOfBaggagePool	Must be set to true for the passenger that is head of the baggage pool (i.e. the passenger than has all the pooled baggage connected to him or her).
MemberOfBaggagePool	Must be set to true for all other passengers in a baggage group which is not the HeadOfBaggagePool.

4.2. Bagtag

BagTagNumber	The 10 digit bag tag (licence plate) number as defined by IATA. The BagTagNumber is a concatenation of BagTagLeadingDigit, BagTagIssuerCode and BagTagSerialNumber.
BagTagIssuerCode	The 3-digit IATA allocated code identifying the airline that has issued the bag tag. See BagTagNumber for information about the other parts, and AirlineIATAThreeNumeric for more information about the 3-digit IATA code.
BagSequenceCount	The number of bags that has been checked in at the same time. The number of bags that has been checked in sequence at the same time. In the context of this service it is for information purposes only. NOTE! In the PRL (RP 1719b) one BagTag can represent more than one bag. In the PRL the sequenceCount thus indicate the number of bags represented by one element in the interface. This is NOT allowed in the setIPI operation. All bags shall have its own bagtag element.
BagFinalAirportIATA	The AirportIATA code for the final airport the bag should be sent to.

4.3. CardInfo

CardIssuerCode	A code identifying the card issuing company. What this code actually is depends on the type of card. In the issuer's domain the cart itself is identified by the CardNumber.
CardNumber	A unique card number within the Issuers domain. What the card number actually is depends on the type of card. The issuer is identified by the CardIssuerCode.

4.4. CheckedBaggageData

Bagtag	Refer to "Bagtag" for description.
BagWeight	The weight (in kilos) of one bag.
BagTypeIndicator	Indication if baggage contains special goods.
BagSizeIndicator	Indication if baggage is unconventional size or weight.

4.5. FlightLegIdentifier

IFPLID	Typically not used in Inbound Passenger Information Service.
Callsign	Typically not used in Inbound Passenger Information Service.
AircraftRegistration	Typically not used in Inbound Passenger Information Service.
SSRCode	Typically not used in Inbound Passenger Information Service.
FlightId	Mandatory in Inbound Passenger Information Service IATA based identifier for this flight, usually issued long before the flight actually takes place. FlightId is normally the concatenation of OperatingAirlineIATA, FlightNumber and OperationalSuffix. FlightId typically identifies a flight to the majority of systems, but it is not unique across time. It's unique only in conjunction with FlightDepartureDate. Exception: Some airlines use their ICAO code (OperatingAirlineICAO) instead of OperatingAirlineIATA. This might be because they aren't an IATA member or because they just prefer the ICAO code. Regardless, this means that it is allowed to use OperatingAirlineICAO as part of FlightId. FlightId is then defined as the concatenation of AirlineIATAorICAO, FlightNumber and OperationalSuffix.
FlightDepartureDate	Mandatory in Inbound Passenger Information Service The scheduled date (based on UTC) of departure of flight. For flights with multiple legs this is the departure of the first leg. This date must not change once set as it is used to make the FlightIds unique.
DepartureAirportIATA	Mandatory in Inbound Passenger Information Service Departure airport IATA code (see AirportIATA for description of term).
ArrivalAirportIATA	Mandatory in Inbound Passenger Information Service Arrival airport IATA code (see AirportIATA for description of term).
DepartureAirportICAO	Typically not used in Inbound Passenger Information Service.
ArrivalAirportICAO	Typically not used in Inbound Passenger Information Service.

4.6. InboundPassengerData

PassengerData	Data defining the person which the InboundPassengerData belongs to.
BaggagePoolData	Tells if passenger is part of a baggage pool and if so which baggage group.
UnconformingBaggageIndicator	If the passenger is bring animals or weapons, this must be indicated here.
CheckedBaggageData	One element for each of the passengers checked baggage. Note! if passenger is part of a baggage pool, the CheckedBaggageData elements will only be present for the "head of pool".
inboundTravelDoc : TravelDocIdentifier	Information about travel documents belonging to this passenger for the incoming flight this InboundPassengerData is related to.
outboundTravelDoc : TravelDocIdentifier	Travel documents for the outbound flight the passenger will depart on. (Only relevant for transfer passengers.)
outboundFlightIdentifier : FlightLegIdentifier	Identifies the outbound flight the passenger will depart on. (Only relevant for transfer passengers.) The inbound FlightLegIdentifier is given separately and is of course common for all inbound passengers on the same flight.
additionalOutboundFlightIdentifier : FlightLegIdentifier	If the passengers continues his travel for more than one leg, information about any additional legs are given here. (One element for each leg).
previousInboundFlightIdentifier : FlightLegIdentifier	If the passenger started his travel before the flight this InboundPassengerData is for, information about any additional previous flight legs may be given here. (One element for each leg).

4.7. InboundPassengerInformation

FlightLegIdentifier	Identifies the incoming/arriving flight. All InboundPassengerData are for this flight.
InboundPassengerData	Information about one or more passengers on the incoming/arriving flight.

4.8. PassengerData

PassengerName	Name of passenger. See PassengerName for details.
OperatingCarrierPnrCode	The PNR code for the operating carrier, independent of code-share, lease or other issues.
PassengerGroupId	An alphanumeric group ID which can be used to group some passengers for seating purposes. PassengerGroupId must not be confused with "BaggagePoolId". The ID is unique within the flight the InboundPassengerData is related to. NOTE! The PRL (RP1719b) defines that several information elements shall not be repeated for passengers belonging to the same passenger group, even though they applies to all passengers in the group. In the Inbound Passenger Information Service all these information elements MUST be repeated for all passengers in the passenger group.
PassengerCellularPhoneNo	The cellular/mobile phone number for one passenger.
PassengerDescriptionCode	A code describing the passenger to some extent.
PassengerBoardingStatus	The boarding status of the passenger. Indicates where in the boarding process the passenger is.

4.9. PassengerName

PassengerFirstName	The first (and middle) name of a passenger
PassengerLastName	The last name of a passenger
PassengerInitialsAndOrTitle	Normally the passengers title (e.g MR, MRS....)

4.10. ResponseStatus

statusCode : ResponseStatusCode

ResponseStatusCode indicates if the operation succeeded or failed, and if it failed - why. ResponseStatusText is a textual description of ResponseStatusCode. For all operations the set of response codes must be defined. The actual set is dependent upon the context.

"OK": Operation succeded.
"ERR01":
"ERR02":
"":
"":
"ERR99": Other error. "statusText" should describe the error.

Must be defined!

statusText : ResponseStatusText

A textual description of ResponseStatusCode.

4.11. TransData

CorrelationId	Identifier that can be used to correlate messages, transactions, log entries etc. The identifier should be unique across all relevant systems. It is the responsibility of the creator of the message/transaction/log entry/... to guarantee uniqueness. The CorrelationId can for instance be a GUID, or something shorter based on site specific rules.
SourceOrganization	Name of the organization/company that created the original data. This will typically be an airline company or an handler. The value set are site specific.
SourceTimestamp	UTC timestamp for when the source was updated. If unknown, use current (UTC) time.

4.12. TravelDocIdentifier

BoardingPassSeqNumber	The sequence number of the passengers boarding pass. However, identification of a passenger based on his boarding pass may alternatively be done by comparing PassengerName, FlightLegIdentifier and OperatingCarrierPnrCode with the information read from the boarding pass 2D barcode.
MaskedCreditCard : CardInfo	The issuer code and masked credit card number. Can be used to identify a passenger by his credit card. A masked credit card number is not unique in the world, but is highly likely to be unique in any relevant setting. Must be given if passenger should be identified by his credit card.
FrequentFlyerCard : CardInfo	The issuer code and card number of a frequent flyer card. Can be used to identify a passenger by his frequent flyer card. Must be given if passenger should be identified by his frequent flyer card.
TicketNumber	Ticket number, with issuer number prefix. Should be present. However, identification of a passenger based on his "ticket document" may alternatively be done by comparing PassengerName, FlightLegIdentifier and OperatingCarrierPnrCode with the information read from the ticket 2D barcode.

4.13. UnconformingBaggageIndicator

PassengerHasWeaponsInBaggage	Indicator set to true if the passenger has weapons, ammunition or explosives in checked baggage.
PassengerHasAnimalsInBaggage	Indicator set to true if the passenger has animals in checked baggage.
PassengerHasPetsInCabin	Indicator set to true if the passenger has pets in the cabin.

5. XML Usage

5.1. Nil Values in Schema

For any particular data element, there is an important distinction between the following cases:

(a) the element is missing
(b) the element is present but has a 'nil' attribute assigned to it

In the first case, this means that the sender is supplying no information about the element. This would typically be because no information is available, or because there has been no change in the value of the element. A recipient would not be expected to take any action as a result of this. In particular, it would not be expected to clear any existing value.

In the second case, this means that the sender has explicitly cleared the element. As a result of this, a recipient would typically clear any value that it had previously stored for this element.

The following table shows an example sequence of messages, and the expected actions taken by the data recipient. It should be noted, however, that the action is up to the recipient. The message from the sender is a notification, and not a command for the recipient to take action.

Message contents	Expected action by recipient
aircraftRegistration element missing	Does not set or change aircraft registration value
<aircraftRegistration>ABC123</aircraftRegistration>	Sets the value to ABC123
aircraftRegistration element missing	Does not change the value
<aircraftRegistration xs:nil=’true’>	Clears the aircraftRegistration value

Note that the sender should not use blank data elements such as <aircraftRegistration/> or <aircraftRegistration></aircraftRegistration> as these may cause validation errors. For example, if the schema specifies a format or a minimum length for an element, then a zero-length element will be invalid. This problem does not occur if using the nil attribute.

Note - Where a field is defined as mandatory in the schema, it must not contain a nil value.

Space shortcuts

Page tree