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:

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.

6. WSDL and XSDs


  • No labels