====== Resource Layer 분석 ======
모듈과 호스트 사이에 주고 받는 데이터를 분석하는 데 꼭 필요한 사항들을 정리했다. 리소스 계층은 가장 복잡한(?) 계층 중 하나다.
여기서 리소스란, 유사한 목적을 위한 object 의 집합이며 또 그 사용법에 대한 프로토콜을 말한다. 각 리소스는 리소스 ID 로 구분된다.
세션 계층으로 부터 받은 data 는 byte 단위의 array 이다. 이 array byte 데이터를 규격에서 제시한 리소스 object 의 데이터 구조를 바꿔서 application layer 로 보내는 역할을 한다. 

잠깐, 프로그램 레벨에서 보면, 이제까지 설명했던 순서대로 각각이 task 로 분류되어 있다. 그 중에서 가장 마지막에 수행되는 것이 바로 resource layer 이다. 스펙상으로 본다면, 이 위에 application layer 가 있겠지만, 프로그램 상에서는 따로 task 로 분리하지 않았다. 이 계층 역시, APDU 를 만드는 부분과 파싱하는 부분으로 나뉘어 있다. 
====== APDU 의 기본 스펙 ======
| apdu_tag | length_field | data field |

위의 표에서 apdu_tag, length_field 부분이 헤더부분이다. 그리고 나머지가 body 부분이다. 

| syntax | no.of bits | Mnemonic |
| apdu_tag | 24 | uimsbf |
| length_field() |  |  |
| data_byte | 8 | uimsbf |

두개의 부분으로 나눌 수 있다. 명령헤더 부분은 apdu_tag, length_field 이 포함된다. body 부분의 변수 길이는 length_field 의 값과 같다.
====== Resource Manager ======
리소스 매니저는 host 가 제공하는 resource 이며, class 에 하나의 type 만이 있고 수의 제한 없이 session 을 지원한다. 또한 리소스 매니저는 모든 리소스를 관리한다. 대칭된 통신 프로토콜은 호스트와 모듈사이의 각각이 지원 가능한 리소스를 규정한다.
===== RM(Resource Manager)의 수행 =====
| 순서 | 
| 모듈을 넣고 전원을 넣는다. 모듈에서 전송계층을 만든다. application 또는 resource 제공자에게 공급한다. |
===== profile inquiry =====
이것은 Profile Reply object를 제공하는 리소스의 리스트와 함께 응답한다. 어떤 기능을 하는 리소스인지 물어본다.

| syntax | no. of bits | Mnemonic |
| profile_inq_tag | 24 | uimsbf |
| length_field()=0 |  |  |
===== profile reply =====
이 것은 보내는 쪽이 제공할 수 있는 리소스의 리스트와 profile inquiry 의 응답을 보낸다. resource identifiers 는 제공되어질 리소스의 minimum set 을 위한 것이다. 더 나가서, optional resource 는 이 스펙에 추가되어 리스트 되어 정의될 것이다.

| syntax | no.of bits | Mnemonic |
| profile_reply_tag | 24 | uimsbf |
| length_field()=N*4 |  |  |
| resource_identifier() |  |  |
===== profile changed =====
리소스가 바뀌는 것을 통지하는 역할을 한다. 모듈은 전형적으로 사용한다. 

| syntax | no.of bits | Mnemonic |
| profile_changed_tag | 24 | uimsbf |
| length_field()=0 |  |  |
====== Man Machine Interface ======
호스트 쪽에 있는 리소스이다. 하나 또는 이상의 MMI dialogs 가 초기화될 때, 이 리소스는 오직 하나의 세션을 연다. 이 세션은 normal operation 을 open 하는 동안에 남아있어야 한다.
  - POD 가 MMI dialog 를 열도록 한다.
  - HOST 는 MMI dialog 가 open 되었었는지 확인한다.
  - POD가 MMI dialog 가 close 시킨다.
  - HOST 는 MMI dialog 가 close되도록 POD 또는 HOST 가 요청하다.

| Open_mmi_req() | POD 는 MMI dialog 가 초기화 될때 Open_mmi_req 를 호스트에 보낸다. |
| Open_mmi_cnf() | HOST 는 이러한 요청에 대해 Open_mmi_cnf 로 응답한다. |
| Close_mmi_req() | POD 는 Open_mmi_req 가 open 되기 이전에 MMI dialog 를 close_mmi_req 신호에 보내 close 한다. |
| Close_mmi_cnf() | HOST 는 close_mmi_req 를 POD 에 보내지 않고, Close_mmi_cnf 를 보낸다. |
====== Application Information ======
이 것은 호스트 쪽에서 제공한다. resource manager 리소스가 성공적으로 profile 을 inqury 한 후에, 오직 하나의 세션을 open 한다. 
  - HOST가 POD 에 문자들을 보이게 한다.
  - POD 가 application 을을 호스트에서 보이게 한다.
  - POD 가 HTML 페이지를 HOST 로 보낸다. 

| Application_info_req | 호스트는 application information 리소스가 open 되어 보내어지면, APDU 는 POD 에 광고를 뿌린다. |
| Application_info_cnf | POD 는 이에 대한 응답으로 이 신호를 보낸다. |
| Server_Query | 호스트는 특별한 URL을 가리키는 POD 파일의 정보를 요청하는 POD 에게 Server_query() 를 보내다. |
| Server_Reply | URL 을 받을 때, POD 의 위치나, 요구하는 데이터, server_reply() 안에 들어있다. |
====== Low Speed Communication ======
이 리소스는 Forward Data Channel, Reverse Data Channel 그리고, 호스트 모뎀의 동작의 속성을 지원하기 위해 사용된다.
또한 이 것은 OOB 나 POD-HOST 의 up/down stream 을 의미하지 않는다. 
====== Conditional Access ======
POD 는 CA_UPDATE 를 통해서 CA states 가 바뀌었음을 호스트에 알린다. 새로운 버전의 CA 리소스는 CA_UPDATE APDU 에 process 된다. 
또한 이 리소스는  object 세트를 conditional access application 에 제공한다. 이 것은 리소스 매니저와 같이 세션의 제한이 없고, 오직 host 에 의해서 제공된다. 
모든 ca application 들은 그들의 application 들이 초기화가 완료되자마자, 세션을 만든다. 호스트는 ca info inquiry 를 ca info 와 함께 적합한 정보가 오면, application 으로 보낸다. 

  - CA_update : POD 모듈은 현재의 프로그램의 tune 의 바뀜을 CA Information 으로 CA_update 를 이용해서 HOST 로 보낸다. 
  - CA_info_inquiry : POD 쪽에서 올바른 정보(ca_info)가 오면, 호스트가 이신호를 보낸다.
  - CA_info : POD 가 보내는 ca 관련한 정보
  - Select of services to be descrambled : CA_PMT 는 호스트에 의해 하나 또는 여러개의 CA applications 차례로 기본적인 스트림의 
====== Copy Protection ======
이것은 
====== Host Control ======
이 것은 host rf receiver 와 rf transmitter setup 을 POD 모듈에 보낸다. 부가적으로 이 버전은 OOB 와 inband 를 포함하고 있다. host control 의 open 세션의 요청없이 내부의 튜닝이 수행됨이 예상된다. 
====== Extend Channel ======
이는 extend channel 을 목적으로 하는 것으로서, POD 또는 HOST 가 physical 통신을 headend 로 보내는 'link device' 이다. POD 모듈은 QPSK 모뎀을 위한 link device 이다. host 는 high speed host modem 을 위한 link device 이다. extend channel resource 는 extended channel 로 부터 데이터를 주고 받는 application 을 등록하고 만든다.
====== Generic IPPV ======
이 것은 conditional access information 이 호스트에 있는 navigation application 이 제공한다. 이 것은 구독한  pay per view 기능에 접근을 허용한다. 예를 들면, 구문이나. 삭제되고, history view..
이것은 좀더 구독자들의 승인과 IPPV 사용량의 증가를 원한다. 
====== Specific Application ======
이 것은 POD 또는 호스트가 인터페이스에 접근하는 오브젝트들의 private set 과의 통신이 필요하거나, vendor-specific application 의 사용을 위한 리소스이다. 이 리소스를 지원하기 위해 호스트와 POD 가 요청한다.
====== Homing Resource ======
이 것은 POD 모듈이 호스트가 standby 상태로 있을 때, 호스트로 부터 specific 서비스를 요청하는 것을 허용한다. 호스트가 standby 상태이면, 오직 'immediate' 모드를 지원할 것이다 .
====== Generic Diagnostic ======
진단 리소스는 호스트가 POD 가 요청하면, 상태와 결과를 진단해서 알려준다.
====== System Time ======
이것은 호스트에 의해 제공되며, 세션의 수에 제한이 없다. application 가 리소스에게 세션을 만들고, system time inquiry 오브젝트와 함께 현재 시간을 묻는다. 만일 response_interval 의 값이 0 이면, 응답은 single system_time object 가 곧바로 올것이다. 만일 값이 0 이 아니면, 매번 response_interval 시간 만큼 더 느려질 것이다.