IC卡的传输协议(1)-字符传输协议T=0【转】

简介: 转自:http://bbs.ednchina.com/BLOG_ARTICLE_172022.HTM 在异步半双工传输协议中,主要定义了终端为实现传输控制和特殊需要发出的命令及这些命令的处理过程。    在传输协议中定义了两种协议:字符传输协议(T=0)和块传输协议(T=1)。

转自:http://bbs.ednchina.com/BLOG_ARTICLE_172022.HTM

在异步半双工传输协议中,主要定义了终端为实现传输控制和特殊需要发出的命令及这些命令的处理过程。

    在传输协议中定义了两种协议:字符传输协议(T=0)和块传输协议(T=1)。IC卡可以选择支持T=0协议或者T=1协议,终端一般都支持这两种协议。在ATR中的TD1规定了后续传输中所采用的传输协议(T=0或T=1),如果TD1在ATR中不存在的话则假定采用T=0。如果在ATR之后卡片与终端之间没有参数协商的PTS过程的话(详细细节可参考ISO7816相关部分),由IC卡指定的协议将在复位应答之后立即被采用。

    传输协议按照如下的模型进行定义。

  * 物理层
    定义了位交换,是两种协议的公共部分。

  * 数据链路层
    包括如下定义:
    字符帧,定义了字符交换,是两种协议的公共部分;
    T=0时的字符交换
    对T=0的检错纠错
    T=1时的块交换
    对T=1的检错纠错

  * 传输层
    定义了针对每个协议的面向应用的报文传输。

  * 应用层
    根据相同的应用协议,定义了报文交换的内容。

1、物理层

    在T=0和T=1协议中,均使用了物理层和字符帧。

2、数据链路层

2.1 字符帧 

    详见http://www.iccos.cn/scoscn/html/dev/2007-10-25dev44.html,适用于IC卡和终端之间所有的报文交换。

2.2 字符协议T=0

  (1)特定选项--用于T=0的时段分配

    在复位应答中,ATR中的TC1值决定了终端发送到IC卡的两个连续字符起始位上升沿之间的最小时间间隔在12~266个etu之间。

    IC卡发送到终端的两个连续字符起始位上升沿之间的最小时间间隔为12etu。

    在IC卡发送的任意字符的起始位上升沿与IC卡或终端发送的前一个字符的起始位上升沿之间的最大时间间隔(工作等待时间)将不超过960×D×WI=9600个etu(设位速率转换因子D为默认值,WI为默认值10)。

    相反方向发送的两个连续字符的起始位上升沿之间的最小时间间隔不小于16etu。

    要特别注意的是,由终端向IC卡发送的两个连续字符起始位上升沿之间的最小时间间隔由TC1值控制,可以小于相对发送的两个连续字符之间所允许的最小时间间隔(16个etu)。

  (2)命令头

    命令由终端应用层(Terminal Application Layer,简称TAL)发出,它包括一个由5Byte组成的命令头。每个命令头由5个连续字节CLA、INS、P1、P2和P3组成。

   * CLA(Class Byte of the Command Message)表示命令类别。
   * INS(Instruction Byte of the Command Message)表示指令代码。
   * P1(Parameter 1)和P2(Parameter 2)表示命令的两个附加参数。
   * 根据不同的INS,P3(Parameter 3)指明了发送给IC卡的命令的字节长度或者期待IC卡回送响应的最大数据长度。

    对于T=0,这些字节和通过命令发送的数据一起构成命令传输协议数据单元(Command Transport Protocol Data Unit,简称C-TPDU),命令应用协议数据单元(Command Application Protocol Data Unit,简称C-APDU)到C-TPDU的映射将在后续文章中学习。

    终端传输层(Terminal Transport Layer,简称TTL)传送发送5Byte的命令头给IC卡并等待一个过程字节。

  (3)过程字节

    IC卡接收到命令头以后,向TTL回送一个过程字节。过程字节向TTL指明了下一步该做什么,其编码与TTL行为的对应关系如下所示:

    终端对过程字节的响应:

        过程字节值                  步骤
     1  与INS字节值相同            所有余下的数据将要由TTL传送或者准备接收所有来自IC卡的数据。
     2  与INS字节值的补码相同      下一个数据字节将由TTL传送或者准备接收来自IC卡的下一下数据字节。
     3  0x60                       TTL提供根据额外的工作等待时间。
     4  0x6X或者0x9X(除0x60以外) TTL将等待下一个过程字节或者状态码SW2。

    在情况1、2、3中,操作完成后TTL将等待另一个过程字节。

    在情况4中,第二个过程字节或状态码SW2已被收到后,TTL将要做如下事情。

   * 如果过程字节为0x61,TTL将向IC卡发送一个最大长度为0xXX的Get Response命令头,XX为SW2值。
   * 如果过程字节为0x6C,TTL将立即向IC卡重发一个命令的命令头,其长度为XX,XX是SW2的值。
   * 如果过程字节为0x6X(除0x60、0x61、0x6C以外)或者0x9X(即状态),TTL将在响应APDU中向TAL回送状态码,并等待下一个C-APDU。

    TTL与IC卡之间交换命令和数据时,TTL和IC卡必须清楚地知道数据流向和I/O的驱动者,即是终端向IC卡发送数据还是IC卡向终端发送数据。

  (4)C-APDU的传输

    采用T=0协议时,只包含送向IC卡的命令数据或只包含IC卡响应数据的C-APDU,可直接映射到C-TPDU。不包含不回送数据的C-APDU,以及要求IC卡接收数据和发送给IC卡数据的C-APDU将通过相关的传输规则进行传输。

2.3 T="0时的错误检测与纠错"

    若字符没有正确地接收到或者接收正确但校验不正确,接收方应在字符起始位的上升沿脉冲之后的(10.5±0.2)个etu内,向I/O端口发送持续时间为1~2个etu的低电平信号,表示前面的传输中有错误发生。

    相应的,发送方应该在字符起始位上升沿脉冲发出后的(11±0.2)个etu内,检测I/O端口的电平状态,此时若I/O端口为高电平状态,则表明字符已经被正确接收。

    若发送方检测到错误,就应在检测出错误以后至少延迟2个etu,并重复发送一次有错误嫌疑的字符,最多只发送3次。

【作者】 张昺华
【新浪微博】 张昺华--sky
【twitter】 @sky2030_
【facebook】 张昺华 zhangbinghua
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利.
目录
相关文章
|
7月前
|
开发工具 Android开发
Android平台GB28181设备接入端语音广播支持PS格式
对接Android平台GB28181设备接入端语音广播的时候,我们有遇到过INVITE SDP需要PCMA格式的audio,对方同时回了PS和PCMA两种,然后,发数据的时候,直接发了PS的。
128 0
|
缓存 Linux
PCIe地址转换服务(ATS)详解2
PCIe地址转换服务(ATS)详解
1546 0
PCIe地址转换服务(ATS)详解2
|
7月前
|
网络协议 前端开发 开发工具
GB28181基于TCP协议的视音频媒体传输探究及实现
我们先看看官方规范针对TCP协议的视音频传输描述: 实时视频点播、历史视频回放与下载的 TCP媒体传输应支持基于RTP封装的视音频PS流,封装格式参照IETFRFC4571。
|
7月前
|
网络协议 前端开发 开发工具
GB/T28181-2022相对2016版“基于TCP协议的视音频媒体传输要求“规范解读和技术实现
GB/T28181-2022和GB/T28181-2016规范,有这么一条“更改了附录 D 基于 TCP 协议的视音频媒体传输要求(见附录 D,2016 年版的附录 L)。”。
195 0
|
7月前
|
网络协议 前端开发 开发工具
GB28181-2022相对2016版“基于TCP协议的视音频媒体传输要求“调整
GB28181-2022针对“基于TCP协议的视音频媒体传输”实时点播、历史视频回放与下载中,TCP媒体传输重连机制,做了说明。
|
网络性能优化
【数字IC】深入浅出理解AXI协议
【数字IC】深入浅出理解AXI协议
【数字IC】深入浅出理解AXI协议
|
开发者 SoC
【数字IC】深入浅出理解UART协议
【数字IC】深入浅出理解UART协议
【数字IC】深入浅出理解UART协议
|
芯片 索引
【数字IC】深入浅出理解I2C协议
【数字IC】深入浅出理解I2C协议
【数字IC】深入浅出理解I2C协议
|
网络协议 算法 网络性能优化
字节一面:如何用 UDP 实现可靠传输?
我记得之前在群里看到,有位读者字节一面的时候被问到:「如何基于 UDP 协议实现可靠传输?」 很多同学第一反应就会说把 TCP 可靠传输的特性(序列号、确认应答、超时重传、流量控制、拥塞控制)在应用层实现一遍。 实现的思路确实这样没错,但是有没有想过,既然 TCP 天然支持可靠传输,为什么还需要基于 UDP 实现可靠传输呢?这不是重复造轮子吗?