Dimensi TutupBotol: 7. Transmission Protocols

Berikut akan diterjemahkan/diedit sebagian standard ETSI TS 102 221 v8 untuk bab 7 saja. Ummm...mungkin +Pena Hijau mau berbaik hati untuk ikut membatu menerjemahkan hehhee.... :D,

Ok....Beberapa istilah yang perlu diketahui sebelum melangkah lebih jauh :

Terminal = handphone
UICC = simcard
PPS = Protocol and Parameter Selection
ATR = Answer To Reset
IFSC = Information Field Size for the UICC
IFSD = Information Field Size for the terminal
NAD = Node ADress byte
PCB = Protocol Control Byte
INF = INFormation field
EDC = Error Detection Code byte
DAD = Destination ADdress
SAD = Source ADdress
CAT =

Bab 7 ini menjelaskan tentang transmisi protocol yang digunakan selama proses komunikasi data antara terminal dan UICC. Akan dijelaskan pula struktur dan pemrosesan perintah yang diinisialisi oleh terminal untuk transmission control dan spesific control pada transmisi protocol dengan mode asynchronous half dulplex.

Ada dua jenis protocol yang akan dijelaskan, yaitu character based protocol T = 0 dan block based protocol T = 1.

Kedua jenis protocol ini, T=0 dan T=1, sifatnya mandatory untuk terminal. UICC harus dapat mendukung salah satu atau kedua dari protocol T=0 dan T=1 tersebut.

Penggunaan protocol ini akan dimulai setelah ATR atau PSS telah sukses dilaksanakan.

Protocol ini menggunakan konsep layer OSI, setidaknya ada 4 layer yaitu:

Physical layer. Definisi yang terkandung valid untuk T=0 dan T=1
Data link layer, yang terdiri dari

komponen character
komponen block
identifikasi block
pengiriman block
deteksi transmisi dan pengecekan error
handle errors
protokol synchronize

Transport layer, yang mendefinisikan transmisi pesan application-oriented yang sifatnya spesifik untuk tiap protocol.
Application layer, yang mendefinisikan pergantian pesan yang sesuai untuk setiap protokol aplikasi

Ilustrasinya seperti terlihat di bawah :

7.1 Physical Layer

Protocol T=0 dan T=1 akan menggunakan physical layer dan character frame seperti yang akan disebutkan pada subbab 7.2.1

7.2 Data Link Layer

Subbab ini menjelaskan tentang timing, specific option dan error handling untuk protocol T=0 dan T=1.

7.2.1 Character Frame

Karakter yang dikirimkan melalui I/O line dimasukkan pada character frame. Sebelum transmisi dari suatu karakter, I/O line akan berada pada state H. Berdasarkna kesepakatan yang digunakan, logika '1' pada karakter dapat direpresentasikan oleh state H pada I/O line (direct convention) atau state L pada I/O line (inverse convention).

Setiap karakter terdiri dari 10 bit, yaitu :

1 buah start bit pada state L
8 bit yang merupakan data byte
1 bit untuk even parity checking

Parity bit diset dengan suatu cara sehingga jumlah bit 1 pada karakter frame menjadi genap. Waktu awal ditetapkan diantara akhir state H dan awal dari state L, penerima harus dapat memastikan keberadaan start bit sebelum 0,7 etu(receiver time). Kemudian bit berikutnya akan diterima pada interval (n+0,5 +-0,2)etu (n adalah nomor bit). Start bit adalah 1.

Dalam suatu karakter, waktu dari leading edge untuk start bit sampai trailing edge untuk bit yang ke-n adalah (n+-0,2)etu. Periode antara leading edge dari start bit dari 2 karakter yaitu (10+-0,2)etu, ditambah guardtime. Dalam kasus transmisi yang tidak ada error, selama guardtime, UICC dan terminal akan berada pada reception mode (baik itu I/O line pada state H), kecuali disebutkan kasus yang lain.

Data pertama yang dikirimkan melalu I/O line adalah most significant byte. Urutan bit dalam byte (apakah LSB atau MSB yang dikirimkan pertama kali) diterangkan lebih lanjut pada character TS yang dikembalikan pada ATR seperti yang terdapat pada ISO/IEC 7816-3.

7.2.1.1 Low Impedance I/O Line Behaviour

Jika low impedance pada I/O line telah dipilih, sebagai hasil dari PPS exchange yang sukses, protocol yang dijelaskan pada subbab ini akan berlaku.

State transmisi didefinisikan sebagai awal periode dari bit pertama dari karakter pertama sampai akhir pada guardtime dari karakter terakhir yang dikirim. Selama state transmisi, pengirim akan mengatur I/O line pada level yang sesuai menggunakan pengatur low impedance, kecuali periode error indication, contohnya karakter guardtime dari T = 0.

Setelah penerimaan karakter terakhir dari suatu command atau response ketika arah komunikasi berubah, pihak yang mempunyai giliran untuk transmit data (terminal atau UICC) harus dapat mengatur I/O line ke level yang lebih tinggi menggunakan low impedance driver selama periode inteface inactivity. Selama periode clock stop, terminal akan mengatur I/O line ke state yang lebih tinggi lagi.

Periode interface inacitivity berakhir ketika pengiriman command yang baru telah dimulai atau response command tersebut telah dimulai.

7.2.2 Transmission protocol T=0

T=0 adalah karakter half-duplex asynchronous yang berdasarkan transmission procotol. Semua commands yang menggunakan protocol T=0 diawali dari terminal yang mengirimkan 5 byte header, yang menginformasikan UICC apa yang harus dilakukan. Terminal akan selalu bertindak sebagai master dan UICC akan selalu bertindak sebagai slave. Arah transmisi data dianggap telah diketahui oleh masing-masing UICC dan terminal.

7.2.2.1 Timing and Specific Options for Characters in T = 0

Interval minimum antara leading edge dari start bit dari dua karakter yang berurutan paling tidak adalah 12 etu. Interval maksimum antara start leading edge dari suatu karakter yang dikirim oleh UICC dan start leading edge dari karakter sebelumnya yang dikirim baik oleh UICC ataupun terminal adalah WWT. Nilai dari WWT tidak boleh melebihi 960xWIxFi/f. WI adalah bilangan yang diterima pada specific interface byte pada TC2. Jika tidak ada TC2, nilai default dari WI adalah 10. Faktor konversi clock rate, Fi, dan faktor konversi baud rate, Di, dapat/mungkin ditunjukkan pada TA1. Jika TA1 tidak ada maka nilai default yang digunakan adalah 372 dan 1 masing-masing digunakan. Jika nilai WWT telah dilewati, terminal harus mengawali proses deaktivasi dalam 960 etu.

7.2.2.2 Command Header

Command akan selalu diawali oleh terminal yang mengirimkan suatu instruksi ke UICC dalam bentuk 5 byte header yang disebut command header. Command header terdiri dari 5 byte, CLA, INS, P1, P2, dan P3. Byte-byte tersebut dengan datanya dikirimkan dalam bentuk Command-Transport Protocol Data Unit (C-TPDU) untuk T=0. Pemetaan C-APDU ke C-TPDU akan dijelaskan pada sub 7.3. Jika terminal mengirimkan header ke UICC, maka dia akan menunggu procedure byte atau status byte.

7.2.2.3 Command Processing

Ketika UICC telah menerima command header, respond yang berisi procedure byte atau status byte akan dikirimkan ke terminal. Terminal dan UICC dapat menjaga track dari data flow dan siapa yang dapat mengakses I/O-line.

7.2.2.3.1 Procedure Bytes

Procedure byte menunjukkan aksi apa berikutnya yang akan dilakukan oleh terminal. Procedure bytes digunakan untuk menjaga komunikasi antara terminal dan UICC. Procedure bytes ini tidak boleh dikirimkan ke application layer. Koding dari procedure byte dan aksi yang dilakukan oleh terminal ditunjukkan pada tabel 7.1 di bawah :

Setelah aksi tersebut dilakukan, terminal akan menunggu procedure byte atau status word berikutnya.

7.2.2.3.2 Statys Bytes

Status bytes, SW1 SW2, membentuk suatu end sequence yang menunjukkan kondisi dari UICC pada state akhir dari suatu command. Secara normal, akhir dari suatu command ditunjukkan dengan SW1 SW2 = '90 00' (bilangan hex).

7.2.2.4 Error Detection and Correction

Prosedur error detection and correction sifatnya mandatory untuk protocol T=0 kecuali jika terminal berada pada proses ATR. Suatu error, dilihat dari sisi penerima, didefinisikan sebagai parity yang salah. Error ditunjukkan pada I/O line, yang di set ke state L pada (10,5+-0,2)etu setelah leading edge dari start bit untuk setiap karakter. I/O line akan berada pada state L dengan durasi maksimum 2 etu dan minimum 1 etu. Pengirim akan mengecek I/O line untuk indikasi parity error pada (11+-0,2)etu yang berawal dari leading edge dari bit pertama pada karakter yang sedang dikirimkan.

Jika UICC atau terminal yang bertindak sebagai penerima mendeteksi adanya parity error pada karakter yang diterima, maka dia akan mengeset I/O line ke state L pada (10,5+-0,2)etu setelah leading edge dari bit pertama pada suatu karakter selama maksimum 2 etu untuk menunjukkan adanya error ke pengirim data (lihat gambar 7.2). Jika pengirim mendeteksi suatu error yang ditunjukkan pada (11+-0,2)etu yang berawal dari leading edge di bit pertama pada suatu karakter yang sedang dikirim, maka karakter tersebut harus dikirimkan kembali setelah minium delay 2 etu.

7.2.3 Transmission Protocol T = 1

Protocol T=1 adalah protocol transmisi dengan sifat half-duplex asynchronous block. Protocol tersebut dapat diawali dengan kondisi sebagai berikut :

Setelah proses ATR karena cold reset
Setelah proses ATR karena warm reset
Setelah berhasil melakukan proses PSS

Komunikasi akan dimulai ketika suatu block yang dikirimkan oleh terminal ke UICC. Pihak yang mengirimkan data berselang-seling antara terminal dan UICC. Block adalah unit data terkecil yang dapat dikirim dan dapat berisi data aplikasi atau transmission control. Pengecekan terhadapat data yang diterima dapat dilakukan sebelum data berikutnya diterima.
7.2.3.1 Timing and Specific Options for Blocks Sent with T = 1

Pada sub bab ini akan dijelaskan pilihan yang berhubungan dengan waktu, ukuran field informasi dan parameter deteksi error untuk suatu blok yang dikirimkan dengan protocol T = 1.
7.2.3.1.1 Information Field Size

IFSC mendefinisikan panjang maksimum field informasi yang terdapat dalam suatu block yang dapat diterima oleh UICC. Nilai default dari IFSC adalah 32 bytes, nilai yang lain dapat ditunjukkan pada TA3 dari ATR. IFSC juga mendefinisikan panjang maksimum field informasi dalam suatu block yang dapat diterima oleh terminal. IFSD mempunyai nilai default 32 bytes juga untuk terminal dan dapat diubah selama suatu sesi card masih berlangsung. Nilai maksimumnya adalah 254 bytes.
7.2.3.1.2 Character Waiting Integer

Character Waiting Integer (CWI) digunakan untuk menghitung Character Waiting Time (CWT). CWI berkisar antara 0 sampai 5. Nilainya diset pada bit ke b4 sampai b1 pada TB3.
7.2.3.1.3 Character Waiting Time

CWT menunjukkan maksimum delay pada leading edges di 2 karakter berurutan dalam suatu block seperti ditunjukkan pada gambar 7.3 di bawah :

Nilai dari CWT dapat dihitung dari persamaan: CWT = (11+2^CWI)etu.

7.2.3.1.4 Block Waiting Time

BWT didefinisikan sebagai maksimum delay antara leading edge dari karakter terakhir pada suatu block yang diterima oleh card dengan leading edge karakter pertama pada block berikutnya yang dikirim oleh card. Ilustrasi seperti terlihat :

BTW ini juga digunakan untuk mendeteksi card yang tidak responsive.
7.2.3.1.5 Block Guard Time

BGT didefinisikan sebagai delay minimum antara leading edge dari 2 karakter berurutan yang dikirim dengan arah yang berlawanan. Nilai BGT harus 22 etu.

Delay antara karakter terakhir dari suatu block yang diterima UICC dengan karakter pertama pada block berikutnya yang dikirim oleh UICC harus berada dalam interval :

BGT < delay < BWT

7.2.3.1.6 Waiting Time Extension

WTX adalah parameter yang digunakan untuk meminta tambahan waktu untuk memproses suatu command.
7.2.3.1.7 Error Detection Code
Parameter TCi pada ATR digunakan untuk mendefinisikan error deteksi yang mana yang akan digunakan. LRC harus digunakan (b1 = 0). Semua bit pada TCi adalah RFU dan akan diset ke 0.
7.2.3.2 Block Frame Structure
Suatu protocol terdiri dari beberapa block, yang dikirimkan antara terminal dan UICC. Setiap block mempunyai struktur seperti yang terlihat di bawah :

Prologue field dan epilogue field sifatnya mandatory, sedangkan information field optional.

7.2.3.2.1 Prologue Field
Prologue field dibagi menjadi 3 bagian mandatory yaitu :

Node ADress byte (NAD), 1 byte;
Protocol Control Byte (PCB), 1 byte;
Length (LEN), 1 byte;

7.2.3.2.1.1 Node Address Byte

NAD menunjukkan sumber dan tujuan dari suatu block. NAD dapat pula digunakan untuk membedakan beberapa logical connection jika memang terdapat beberapa logical channel. NAD juga dapat digunakan untuk menyediakan Vpp control state (bit b8 dan b4). Karena b8 dan b4 tidak digunakan, maka kedua bit tersebut harus diset ke 0. Struktur NAD seperti terlihat pada gambar di bawah :

Pada block pertama yang dikirim terminal, logical connection dibuat berdasarkan pengalamatan di SAD dan DAD. Block berikutnya dalam NAD yang berisi pasangan address yang sama mempunyai logical connection yang sama pula. Hanya nilai default SAD = DAD = 0 yang disupport. Kombinasi yang lain adalah RFU.
7.2.3.2.1.2 Protocol Control Byte
Semua informasi yang dibutuhkan mengontrol transmisi dikirimkan pada Protocol Control Byte (PCB). Koding dari PCB menspesifikasikan type dari setiap block. Pada protocol T=1, terdapat 2 jenis block yang disupport, yaitu :

Information block (I-block): digunakan untuk mengirimkan command dan respon APDU;
Receive-ready block(R-block): digunakan untuk mengirimkan ACK
Supervisory block(S-block): digunakan untuk mengirimkan control information

Tabel 7.4 sampai 7.9 dibawah memperlihatkan format dari PCB untuk setiap tipe-tipe block yang dimulai dari I-block.

Bit b6 menunjukkan apakah block ini berupa request (b6=0) atau response (b6=1).

7.2.3.2.1.3 Length

Byte length menunjukkan jumlah byte pada field information dari suatu block. Jumlah byte dapat berkisar antara 0 byte sampai 254 byte, tergantung dari type blocknya. Nilai LEN = '00' menunjukkan bahwa field information tidak ada dan nilai 'FF' adalah RFU.
7.2.3.2.1.4 Information Field
Information field, INF, sifatnya optional dan tergantung pada type block dimana field akan digunakan.

7.2.3.2.2 Epilogue Field
Epilogue field berisi byte Error Detection Code (EDC). EDC ini digunakan untuk mengirimkan deteksi error dari block yang telah dikirimkan. LRC yang didefinisikan pada ISO/IEC 7816 harus digunakan.
7.2.3.2.3 Block Notations
7.2.3.2.3.1 I-block
I-blocks dinyatakan sebagai : I(N(S),M) dimana :

N(S) adalah nomor send-sequence dari block
M adalah mode-data yang digunakan pada chaining function

7.2.3.2.3.2 R-block

R-block dinyatakan sebagai : R(N(R)), dimana :

N(R) adalah jumlah I-block yang harapkan

7.2.3.2.3.3 S-block

S-block selalu digunakan secara berpasangan. S(request) selalu diikuti oleh S(response) block. S-block dinyatakan sebagai berikut:

S(RESYNCH request), digunakan untuk permintaan resynchronization
S(RESYNCH response), digunakan untuk memberikan ACK resynchronization
S(IFS request), digunakan untuk menawarkan ukuran maksimum dari information field
S(IFS response), digunakan untuk memberikan ACK pada information field
S(ABORT request), digunakan untuk permintaan pembatalan dari chain function
S(ABORT response), sebagai ACK dari S(ABORT request)
S(WTX request), digunakan untuk permintaan penambahan waktu dari waiting time
S(WTX response), digunakan sebagai ACK untuk S(WTX request)

7.2.3.3 Error Free Operation

Aturan dibawah menjelaskan tentang operasi error free dengan T = 1.

Block pertama yang dikirim ke UICC harus merupaka I-block dengan N(S)=0 atau S-block.
Jika pengirim S mengirimkan I(Ns(S),0), block tersebut diberikan ACK oleh receiver R dengan I(Nr(S),M). Isi dari I(Nr(S)) menunjukkan transfer data dan penerima telah siap untuk menerima block selanjutnya dari pengirim.
Jika pengirim S mengirim I(Ns(S),1), block tersebut harus diberikan ACK oleh penerima dengan R(Nr(R)), dimana Ns(S) != Nr(R), untuk menunjukkan bahwa block yang diterima telah benar dan penerima telah siap untuk menerima block berikutnya.
UICC dapat menggunakan lebih dari BWT untuk memproses block sebelumnya yang diterima, yaitu dengan mengirimkan S(WTX request). Kemudian terminal memberikan ACK dengan S(WTX response). Periode waktu yang baru ini dimulai dari leading edge dari karakter terakhir pada S(WTX response).
Untuk mengganti nilai IFSD, terminal mengirimkan S(IFS request). Request tersebut akan di ACK oleh UICC dengan S(IFS response) dengan INF yang sama. IFSD yang baru ini dianggap valid selama tidak ada S(IFS request) yang diterima oleh UICC.
Ketika penerima telah menerima sejumlah karakter seperti ditunjukkan pada LEN dan EDC, maka kini giliran penerima untuk mengirimkan block data selanjutnya.

7.2.3.4 Error Handling untuk T = 1

Komponen block dari data link layer dapat mengatasi error seperti :

BWT time-out;
Menerima block data yang tidak valid, contohnya block dengan parity errors, EDC errors, invalid PCB, invalid length, kehilangan sinkronisasi atau gagal menerima S(... response) setelah mengirimkan S(... request).

Resinkronisasi dari protocol dapat dilakukan dengan 3 level. Jika satu level tidak berhasil, maka dapat digunakan level berikutnya.

Untuk terminal, 3 level tersebut adalah :

Retransmisi blocks
Penggunaan S(RESYNCH request)
Card reset atau deactivation

Untuk UICC, 3 level tersebut adalah

Retransmisi blocks
Penggunaan S(RESYNCH response)
Tanpa aktivitas/aksi dari terminal, UICC menjadi tidak responsif

7.2.3.4.1 Protocol Initialization

Setelah proses ATR karena warm reset atau prosedur PPS yang berhasil, komunikasi antara terminal dan UICC dapat dilakukan kembali. Tetapi jika terminal gagal menerima block yang error-free, pada permulaan prosedur protokol, maka boleh dilakukan 2 kali usaha berikutnya dalam menerima block yang error-free sebelum UICC tersebut direset kembali atau dideactive.
Jika respond block pertama yang dikirim terminal tidak dikirim dalam BTW, terminal harus mengirim sebuah R(0).
Ketika protokol telah diinisialisasi dan block pertama yang diterima oleh UICC tidak valid, UICC memberikan respond dengan R(0).
Jika terminal gagal untuk menerima block yang error-free selama card-session, maka boleh melakukan 2 usaha lagi dalam hal penerimaan block error-free sebelum S(RESYNCH request) dikirim.
7.2.3.4.2 Block Dependent Errors
Ketika sebuah I-block telah dikirim dan terjadi BWT time-out atau invalid block telah diterima (oleh terminal), sebuah R-block dikirim, dengan meminta N(R)nya untuk I-block yang diharapkan dengan N(S)=N(R).
Ketika R-block telah dikirim dan invalid block diterima atau BWT time-out, maka R-block harus dikirimkan kembali.
Ketika sebuah S(... request) telah dikirim dan terjadi BWT time-out atau response yang diterima bukan S(... response), maka S(... request) tadi harus dikirimkan kembali. Tetapi jika S(... response) telah dikirim dan terjadi BWT time-out atau invalid block diterima oleh terminal, maka R-block yang dikirim. Terminal tidak boleh mengirim S(IFS request) sebelum R-block meng-ACK penerimaan I-block sebelumnya dikirim oleh card.
Ketika UICC mengirimkan S(IFS request) dan menerima block yang invalid, S(IFS request) harus dikirim kembali (sekali saja dalam extra time) untuk menerima S(IFS response). Setelah gagal dua kali untuk menerima S(IFS response), UICC harus tetap berada dalam reception mode.
7.2.3.5 Chaining
Chaining memungkinkan terminal atau UICC untuk mengirimkan data/informasi yang lebih besar dari IFSC atau IFSD. Jika informasi yang lebih besar dari IFSC atau IFSD dikirimkan, maka informasi tersebut harus dibagi dalam beberapa bagian, setiap bagian mempunyai panjang <= IFSC atau IFSD. Setiap bagian harus dikirim dalam I-block menggunakan chaining function.
Nilai M-bit pada PCB di I-block mengontrol chaining function sesuai dengan :

M = 0, block yang sekarang tidak terhubung(chained) dengan block berikutnya
M = 1, block yang sekarang terhubung dengan block berikutnya

Ketika penerima menrima lebih banyak I-block, R(N(R)) harus dikirim. N(R) = N(S) dari I-block yang diharapkan. Paling tidak ada satu block berantai yang mengikuti.

Suatu physical error, contonya kelebihan buffer, pada UICC dapat menyebabkan error pada proses chaining ini. Untuk membatalkan proses chaining, S(ABORT request) dapat dikirim oleh transmitter atau receiver. Request tersebut harus dijawab dengan S(ABORT response). ketika S(ABORT response) telah diterima, R-block dapat dikirim oleh terminal ataupun UICC untuk memberikan giliran siapa berikutnya yang akan mengirim data.

7.2.3.5.1 Aturan Chaining

Ketika terminal bertindak sebagai penerima, terminal akan menerima rangkaian I-block yang dikirim dari UICC. Panjang setiap block tersebut adalah <= IFSD.
Ketika UICC bertindak sebagai penerima, UICC akan menerima rangkain I-block yang dikirim dari terminal. Panjang tiap block harus sama dengan IFSC kecuali block terakhir yang mempunyai panjang antara 0 sampai IFSC.
Ketika terminal bertindak sebagai pengirim, semua I-block yang sifatnya chained harus mempunya panjang LEN=IFSC bytes kecuali I-block yang terakhir yang dapat mempunyai panjang antara 0 sampai IFSC.
Ketika UICC bertindak sebagai pengirim, semua chained I-block harus mempunyai panjang LEN <= IFSD byte untuk setiap block.
Ketika UICC yang bertindak sebagai penerima dan menerima block dengan LEN > IFSC, maka block tersebut harus dibuang dan di-ACK dengan R-blcok dengan bit b1 sampai b4 yang mempunyai nilai 2 pada PCB.

Untuk alasan efisiensi, tidak dianjurkan untuk mengirim I-block yang kosong.

7.3 Transport Layer

Pada bagian ini akan dijelaskan tentang bagaimana APDu dikirimkan antara terminal dan UICC.
7.3.1 Transport of an APDU using T = 0
Berikut akan dijelaskan tentang mapping C-APDU ke R-APDU untuk protokol T = 0, pertukaran APDU dan penggunaan dari GET RESPONSE command untuk kasus 2 dan kasus 4.
7.3.1.1 Mapping of APDUs to TPDUs
Mapping C-APDU ke header command T=0 bergantung kepada kasus command tersebut. Mapping data (jika ada) dan status yang dikembalikan oleh UICC atas R-APDU juga tergantung pada panjang data yang dikembalikan.
Procedure bytes '61XX' dan '6CXX' dikembalikan oleh UICC untuk mengontrol pertukaran data antara transport layer pada terminal dan UICC dan sebaiknya tidak pernah dikirimkan ke application layer dari terminal. Pemroresan command pada UICC tidak sempurna jika dia telah mengembalikan procedure bytes '61XX' atau '6CXX'.
Status normal pada penyelesaian suatu command ditandai dengan UICC yang mengembalikan status words '9000' ke transport layer terminal. Transport layer terminal tidak akan melanjutkan suatu command (sebagai contoh melewatkan R-APDU ke application layer dan menunggu C-APDU dari application layer) pada penerimaan suatu status words (tetapi tidak pada penerimaan procedure bytes '61XX' atau '6CXX') dari UICC. Dalam kasus 4 command, segera setelah diikuti transmisi command data yang sukses ke UICC, transport layer dari terminal akan melanjutkan pemroresan command jika warning status bytes ('62XX' atau '63XX') atau status byte yang berhubungan dengan applikasi ('9XXX' kecuali '9000') diterima.
Mapping data di bawah dan status yang dikembalikan UICC atas R-APDU adalah untuk informasi dan hanya berlaku setelah UICC menyelesaikan pemroresan dari command, sukses atau tidak, dan semua data (jika ada) telah dikembalikan oleh UICC dalam kontrol procedure bytes '61XX' dan '6CXX'. Informasi lebih detail untuk penggunaan procedure bytes INS, __INS, dan '60' tidak dijelaskan.
Status yang dikembalikan oleh UICC harus berhubungan dengan command yang terbaru yang diterima saat ini. Dalam hal GET RESPONSE yang digunakan untuk menyelesaikan pemroresan command untuk kasus 2 atau kasus 4, status yang dikembalikan oleh UICC setelah menerima GET RESPONSE harus berhubungan dengan perintah GET RESPONSE, bukan dalam kasus 2 atau 4 dimana dia diselesaikan.
7.3.1.1.1 Case 1
C-APDU dimapping ke C-TPDU dengan memasukkan nilai '00' ke bagian body (P3='00').

Alurnya sebagai berikut :

Transport layer terminal mengirimkan T = 0 command header ke UICC.
Pada penerimaan command header tersebut pada UICC, dalam kasus pemroresasn normal atau abnormal, UICC akan mengembalikan status ke transport layer terminal. UICC akan menganilisa T = 0 command header untuk menentukan apakah pemroresannya termasuk dalam kasus 1 atau kasus 2 yang meminta semua data sampai panjang maksimum yang tersedia.
Pada penerimaan status dari UICC, transport layer terminal tidak akan melanjutkan pemroresan dari command tersebut.

Lihat lampiran C untuk informasi lebih detail pada pertukaran data antara transport layer pada terminal dan UICC.

Status word yang dikembalikan ke transport layer terminal dari UICC setelah penyelsaian dari suatu command dipetakan ke mandatory trailoer R-APDU tanpa perubahan apapun.

7.3.1.1.2 Case 2

C-APDU dipetakan ke C-TPDU tanpa perubahan apapun.

Alurnya sebagai berikut :

Transport layer terminal akan mengirim T = 0 command header ke UICC.
Pada penerimaan command header di UICC:

Pada pemroresan normal akan mengembalikan data dan satus ke transport layer termianl. UICC akan menggunakan procedure bytes '6CXX' (dan jika dibutuhkan, procedure bytes '61XX') untuk mengontrol data yang dikembalikan (lihat di bawah); atau
Pada pemroresan abnormal, UICC hanya akan mengembalikan status saja ke transport layer terminal

Pada penerimaan data (jika ada) dan status dari UICC, transport layer terminal akan menghentikan pemroresan dari command tersebut.

Lihat lampiran C untuk informasi lebih detail tentang pertukaran data antara transport layer terminal dan UICC, termasuk penggunaan procedure bytes '61XX' dan '6CXX'.

R-TPDU dipetakan pada R-APDU tanpa perubahan apapun.

Data (jika ada) dan status yang dikembalikan ke transport layer terminal dari UICC setelah selesainya pemroresan suatu command dipetakan ke R-APDU dengan cara sebagai berikut :

Data yang dikembalikan (jika ada) dipetakan ke conditional body dari R-APDU. Jika tidak ada yang dikembalikan, conditional body dari R-APDU dibiarkan kosong saja.
Status yang dikembalikan dipetakan ke mandatory trailer pada R-APDU tanpa perubahan apapun.

7.3.1.1.3 Case 3

C-APDU dipetakan ke C-TPDU tanpa perubahan apapun. Lc adalah suatu nilai antara 1 sampai 255.

Alurnya sebagai berikut :

Transport layer terminal akan mengirimkan T = 0 command header ke UICC.
Pada penerimaan command header tersebut, jika UICC :

Mengembalikan procedure byte, transport layer dari terminal akan mengirimkan porsi data dari conditional body C-APDU ke UICC dengan aturan dari procedure byte yang dikembalikan UICC
Mengembalikan status, transport layer dari terminal akan menghentikan pemroresan dari command tersebut.

Jika pemroresan tidak dilanjutkan/dihentikan pada step 2.b, UICC akan mengembalikan status yang diterima dari conditional body C-APDU dan penyelesaian dari pemroresan command.
Pada penerimaan status dari UICC, transport layer terminal akan menghentikan pemroresan dari command tersebut.

Lihat lampiran C untuk informasi lebih detail mengenai pertukaran data antara UICC dan terminal.

Status word yang diterima oleh transport layer terminal setelah menyelesaikan pemroresan dari suatu command, atau status word yang dikembalikan UICC yang menyebabkan transport layer menghetikan pemroresan command tersebut dipetakan ke R-APDU tanpa perubahan apapun.

7.3.1.1.4 Case 4

C-APDU dipetakan ke C-TPDU dengan menghilangkan byte terakhir (Le).

Alur pertukaran datanya sebagai berikut :

Transport layer terminal akan mengirimkan T=0 command header ke UICC.
Pada penerimaan command header tersebut, jika UICC :

Mengembalikan procedure byte, transport layer terminal akan mengirimkan porsi data pada conditional body C-APDU ke UICC dengan kontrol dari procedure byte yang dikirimkan UICC sebelumnya.
Mengembalikan status, transport layer terminal akan menghentikan pemroresan command tersebut.

Jika pemroresan tidak dihentikan pada step 2.b, conditional body C-APDU yang diterima, UICC akan :

Pada normal processing, akan mengembalikan procedure bytes '61XX' ke transport layer terminal yang meminta untuk memberikan GET RESPONSE command agar dapat menerima data dari UICC; atau
Pada abnormal processing, hanya mengembalikan status saja ke transport layer terminal.

Pada penerimaan procedure bytes atau status pada step 3, jika UICC :

Mengembalikan procedure bytes '61XX' seperti pada 3.a, maka transport layer terminal akan mengirimkan GET RESPONSE command header ke UICC dengan P3 yang nilainya diset ke nilai yang kurang dari atau sama dnegan nilai yang terdapat pada byte 'xx' di '61XX' tersebut; atau
Mengembalikan status seperti pada 3.b yang menunjukkan warning ('62XX' atau '63XX'), atau status yang berhubungan dengan applikasi ('9XXX' tetapi bukan '9000'), maka transport layer dari terminal akan mengirimkan perintah GET RESPONSE dengan Le = '00'; atau
Mengembalikan status seperti pada step 3.b yang tidak termasuk dalam step 4.b, maka transport layer terminal akan menghentikan pemroresan dari command tersebut.

Jika pemroresan command tersebut tidak dihentikan pada 4.c, GET RESPONSE command akan diproses sesuai dengan aturan pada command case 2.

R-TPDU dari UICC yang menunjukkan bahwa UICC telah melakukan perintah yang betul dan yang menunjukkan bawah UICC mempunyai data lebih untuk dikirimkan dengan panjang Luicc bytes. R-TPDU ini dipetakan ke R-APDU tanpa perubahan apapun.

Lihat lampiran C untuk informasi lebih detail tentang pertukaran data antara terminal dan UICC, termasuk penggunaan dari procedure bytes '61XX' dan '6CXX'.

7.3.1.1.5 Penggunaan Procedure bytes '61XX' dan '6CXX'

UICC mengembalikan procedure bytes '61XX' dan '6CXX' ke transport layer terminal untuk menunjukkan cara yang digunakan untuk memperoleh data yang diminta oleh command yang sedang diproses. Procedure tersebut hanya digunakan ketika melakukan pemroresan command pada kasus 2 atau 4 menggunakan T = 0.
Procedure '61XX' memerintahkan transport layer terminal untuk mengeluarkan GET RESPONSE command ke UICC. P3 dari GET RESPONSE tersebut di set ke 'XX'.
Procedure '6CXX' memerintahkan transport layer terminal untuk segera mengirimkan command header sebelumnya dengan P3 = 'XX'.
Penggunaan procedure byte tersebut selama pemroresan error free pada kasus 2 dan 4 dijelaskan di bawah. Dalam kasus terdapat error, UICC dapat mengembalikan status yang menunjukkan error atau warning selain mengembalikan response '61XX' atau '6CXX'.
7.3.1.1.5.1 Case 2 Commands

Jika UICC menerima command header untuk case 2 dan Le='00' (dengan Luicc < 256 bytes) atau Le > Luicc, maka UICC akan mengembalikan :

Procedure bytes '6C Luicc' yang memerintahkan transport layer terminal untuk segera mengirimkan kembali command header dengan P3 = Luicc; atau
Status yang menunjukkan warning atau kondisi error (tetapi bukan SW1 SW2 = '90 00')

Jika UICC menerima command header untuk case 2 dan Le='00' (dengan Luicc=256 bytes) atau Le=Luicc, maka UICC akan mengembalikan :

Data dengan panjang Le (=Luicc) dengan kontrol dari procedure bytes INS, __INS, atau '60' yang diikuti oleh yang status yang berhubugan; atau
Procedure bytes '61XX' yang memerintahkan transport layer terminal untuk segera mengirimkan GET RESPONSE command dengan panjang maksimum 'xx', dimana 'xx' lebih kecil dari Luicc (hal ini dapat terjadi jika buffer data dari card lebih kecil dari Luicc); atau
Status yang menunjukkan warning atau kondisi error (tetapi bukan SW1 SW2 = '90 00').

Jika UICC menerima command header untuk case 2 dan Le < Luicc, UICC akan mengembalikan :

Data yang panjangnya Le dengan kontrol dari procedure bytes INS, __INS, atau '60' yang diikuti oleh procedure bytes '61XX' yang memerintahkan transport layer terminal untuk mengirimkan GET RESPONSE command degan panjang maksimum 'xx'; atau
Status yang menunjukkan warning atau kondisi error (tetapi bukan SW1 SW2 = '90 00').

7.3.1.1.5.2 Case 4 commands

Jika UICC menerima command case 4, setelah pemroresan data yang dikirim dengan C-APDU, UICC akan mengembalikan :

Procedure bytes '61XX' yang memerintahkan transport layer terminal untuk mengirimkan GET RESPONSE command dengan panjang maksimum 'xx'; atau
Status yang menunjukkan warning atau kondisi error (tetapi bukan SW1 SW2 = '90 00').

GET RESPONSE command yang kirimkan akan diperlakukan seperti yang disebukan pada kasus 2 di atas.

7.3.2 Transporation of a APDU using T = 1

C-APDU dikirim dari application layer dari terminal ke transport layer terminal yang sama. Transport layer memetakan C-APDU pada INF I-block tanpa perubahan apapun. I-block selanjutnya dikirim ke UICC. Respond data (jika ada) dan status selanjutnya dikembalikan oleh UICC ke transport layer terminal pada INF I-block. Jika UICC mengembalikan status yang menunjukkan :

Warning ('62XX' atau '63XX');
Application condition ('9XXX'); atau
Kondisi berhasil dari command yang bersangkutan ('9000');

Maka UICC juga harus mengembalikan data (jika memang ada) yang berhubungan dengan command tersebut. Tidak ada data yang harus oleh UICC jika UICC mengembalikan status.

Isi dari INF pada I-block dipetakan ke R-APDu tanpa perubahan apapun dan dikirimkan ke application layer dari terminal. Pengiriman pesan APDU dengan T = 1 dipetakan ke I-block sesuai dengan 4 kasus yang dijelaskan sebagai berikut.

7.3.2.1 Case 1

C-APDU dipetakan ke INF pada I-block tanpa perubahan apapun.

Response yang diterima dari INF pada I-block ini dipetakan ke R-APDU tanpa perubahan apapun.
7.3.2.2 Case 2
C-APDU dipetakan ke INF pada I-block tanpa perubahan apapun.

R-APDU terdiri dari INF I-block atau rankaian INF dari I-block yang diterima pada respon yang sama yang di-chained.
7.3.2.3 Case 3
C-APDU dipetakan tanpa perubahan apapun ke INF atau rangkain dari beberapa I-block yang di-chained.

INF dari I-block dipetakan ke R-APDU tanpa perubahan apapun.
7.3.2.4 Case 4
C-APDU dipetakan tanpa perubahan apapun ke INF atau rangkain beberapa I-block yang berantai.

Response terdiri dari INF I-block atau rangkaian INF I-block yang berantai.

7.4 Application Layer
Protocol application terdiri dari kumpulan pertukaran data antara application layer dan transport layer dari terminal.
Setiap langkah pada pertukaran data application layer terdiri dari pasangan command-response, dimana application layer terminal mengirim perintah ke UICC melalui transport layer terminal, dan UICC memproses command tersebut dan mengirimkan respon ke application layer terminal menggunakan application layer UICC dan transport layer terminal. Setiap command yang spesifik (C-APDU) mempunyai respon yang spesifik pula (R-APDU). Command dan respon disebut sebagai command message dan responsed message. Struktur dari C-APDU dan R-APDU dapat dilihat pada sub bab 10.2.
Command dan response message dapat berisi data. Oleh sebab itu, terdapat 4 kasus yang harus diatur dengan protocol transmisi melalui transport layer, seperti terlihat pada tabel di bawah :

7.4.1 Exchange of APDUs
Gambar 7.14 menunjukkan prinsip dalam pertukaran command dan responsenya

7.4.2 CAT Layer
Layer CAT menggunakan status word dari application untuk menunjukkan :

Keberadaan proactive command ke terminal ('91XX');
Kegunaan dari respon data ke envelope command oleh terminal (normal '9000', warning '62XX', atau '63XX', pengecekan error '6FXX');
Tidak adanya CAT secara sementara untuk menghandle envelope command ('9300'), lihat sub bab 14.6.6.

7.4.2.1 Proactive Command

Dalam kasus status word SW1-SW2 sama dengan '9000', card dapat menjawab dengan '91XX' untuk menunjukkan bahwa proactive command sedang pending. Terminal menggunakan FETCH-APDU untuk mendapatkan pending proactive command tersebut. Terminal mengirimkan respon dari proactive command ke UICC dengan TERMINAL RESPONSE C-APDU.
Jika command dimana card menjawab dengan '91XX' dikirim pada logical channel yang berbeda dengan basic channel, maka terminal akan mengirim FETCH dan TERMINAL RESPONSE commands ke basic channel.
Mekanisme, yang dijelaskan kemudian untuk kasus 4 C-APDU, yang digunakan bersifat independent dari transport protocol.

7.4.2.2 ENVELOPE Commands
ENVELOPE C-APDU digunakan untuk mengirimkan data ke CAT. Untuk beberapa BER-TLV (contohnya SMS-PP Data Download) yang terletak pada body dari command ini, card dapat mengirim data ke terminal pada ACK channel (e.g RP-ACK) atau pada error channel (RP-ERROR). BER-TLV didefinisikan pada TS 102 223 dan pada access technology dependent specifications.
Command ini termasuk dalam kasus 3 atau 4 dan dijelaskan sebagai berikut.
Case 3 : Negative Acknowledgement

Terminal akan mengangap status word yang diterima sebagai negatif ACK dan menggunakan error ACK channel (e.g RP-ERROR), ketika terdapat status word '6FXX' di R-APDU.
Case 4 : Positive Acknowledgement

Terminal akan menganggap data yang diterima sebagai positive ACK and menggunakan normal ACK channel (RP-ACK), ketika terdapat status word '9000' di R-APDU.
Case 4 : Negative Acknowledgement

Terminal akan menganggap data yang diterima sebagai negative ACK and menggunakan error ACK channel (e.g RP-ERROR), ketika terdapat status word '62XX' atau '63XX' pada R-APDU.

Dimensi TutupBotol

Wednesday, February 11, 2015

7. Transmission Protocols - 102 221 v8

No comments:

Post a Comment

me....!