在OTA及民航预订系统（GDS，如Amadeus, Sabre, Travelsky等）的语境下，SSR 是 Special Service Request 的缩写，中文通常称为**“特殊服务需求”**。

在解析 ADTK（航协运价及订座指令）或与 GDS 系统交互时，SSR 是用于向航空公司传达旅客特殊要求或办理相关手续的标准指令代码。

以下是关于 SSR 的详细解析：

1. SSR 的核心作用

SSR 的主要目的是在旅客订座记录（PNR）中，向航空公司（Operating Carrier）申请除标准航空运输服务之外的特殊待遇、声明特殊身份或完成必要的业务操作。如果没有正确输入 SSR 指令，航司可能无法准备相关服务，甚至会导致旅客无法乘机。

2. SSR 的标准结构

虽然不同系统的指令细节略有差异，但 SSR 指令通常遵循标准的 IATA（国际航空运输协会）格式：

SSR [代码] [航司二字码] [适用航段] [备注信息]

• SSR 代码（4位）： 必须是 4 位字母。例如 WCHR 代表轮椅，MEAL 代表特殊餐饮。
• 航司代码： 明确该需求是针对哪家航空公司的。
• 适用航段： 明确该需求适用于行程中的哪一段或哪几段。
• 备注信息： 根据需求类型的不同，后面可能紧跟具体的说明（如餐饮偏好、轮椅类型等）。

3. 常见的 SSR 类型

在 OTA 的后台业务中，常见的 SSR 需求通常分为几大类：

A. 特殊餐食 (Special Meals)

• 代码示例： VGML（纯素食）、CHML（儿童餐）、KSML（犹太餐）、HNML（印度教餐）。
• 作用： 提前通知航司配餐部门准备特定饮食。

B. 特殊旅客/健康类 (Special Passengers/Health)

• 代码示例：
  • WCHR：轮椅（需协助登机）。
  • WCHS：轮椅（需协助至座位，需抱上飞机）。
  • BLND：视觉障碍旅客。
  • DEAF：听觉障碍旅客。
  • UMNR：无人陪伴儿童。
  • STCR：担架旅客。

C. 旅客身份与数据类 (API/Security)

• 代码示例：
  • DOCS：旅客证件信息（护照、签证等），这是国际机票中最常见的“特殊”需求，用于安保预审。
  • DOCA：旅客地址信息（部分国家入境要求提供在目的地居住地址）。
  • DOCO：其他证件信息。

D. 行李与额外物品 (Baggage/Equipment)

• 代码示例：
  • CBBG：占座行李（如大提琴）。
  • AVIH：客舱内宠物（或托运宠物）。
  • SPEQ：体育运动器材。

4. 在 OTA 开发与解析中的注意事项

如果你在进行 OTA 系统的 ADTK 指令解析或接口集成，需要注意以下几点：

1. 状态反馈（Status Code）：
   SSR 指令发送后，航司返回的状态非常重要。常见的有：
   • NN (Need)： 正在申请中。
   • HK (Hold Confirmed)： 申请已获确认。
   • UC (Unable to Confirm)： 航司无法提供该服务（例如飞机餐已售罄或机型不支持）。
   • NO (No Action)： 航司未处理。
2. 强制性： 在国际预订中，DOCS 等安全类信息属于强制性 SSR，如果不录入，航司系统会在值机时拦截，导致旅客无法换取登机牌。
3. 时间限制： 许多 SSR（如特殊餐食、轮椅）有截止申请时间（通常为起飞前 24-72 小时），OTA 系统需要根据此规则动态展示前端预订选项。

总结

SSR 是旅客需求与航空公司服务能力之间的“数字桥梁”。在 OTA 领域，解析 ADTK 指令时，SSR 是除航程（Segments）和旅客信息（Name）外，最重要的数据结构之一，直接决定了旅客乘机体验的质量和航程的合规性。