6.2.1 Procedures for call set-up without presence check
group call은 이 설정을 사용하고 individual call 은 이 설정을 사용할지도 모른다.
6.2.1.1 Outgoing call
user application 이 콜을 초기화 하거나 ongoing call 을 DMCC-SETUP request primitive 에 의해(DMCC-SAP 에서 DMCC 엔티티로)
계속해서 진행하려고할때 다음에 절차를 허용한다. DMCC-SETUP request indicates 는 presence check 가 꼭 필요하진 않는다.
DMCC-SETUP request 는 required service 에 지시하는 파라메터를 포함한다. 이 케이스에서는 협상하지 않는다. 그 콜에 priority 또한 말이다.
DMCC 는 다음에 절차를 사용한다.
● ongoing call을 계속해서 진행하려고 요청한다면 DMCC 는 6.2.4 나 6.2.5 에 절차를 행할 것이다.
● 예외 (새로운 콜과 관련된 요청을 할때)
- DM 채널이 현재 바뿔때 예) occupied or reserved ( or 채널 a 그리고 채널b 가 frequency efficient mode 모드상태일때 ), pre-emption 이 유효하면 DMCC 는 6.2.6 장에 절차를 선택할 것이다.
- DM 채널이 현재 자유롭다면 DMCC 는 콜설정 절차를 즉시 시도할 것이다.
- 채널 상태를 알수 없으면, DMCC 는 즉시 콜 설정을 시도하거나 DMCC-RELEASE indication 을 user application 에게 이슈화 한다.
NOTE
채널 상태를 알수 없는것은 DM-MS 가 빠르게 콜 설정을 시도하지 않았기 때문이거나. (8.4.2.2.2)
DM-MS 가 잠시 채널의 상태를 알수 없는 것이다. 이전 케이스에서
사용자가 원하는 콜을 만들때, DMCC 는 다음에 콜 설정 절차를 시도했었을 것이다.
DM-SETUP PDU를 전송하는데 - 레이어 2에서 DM 채널의 상태의 초기화 결정 절차를 위해 할것이다. 그리고 메시지를 전송한다
만약 지휘 DM 채널이 자유롭게 지시한다면 (8.4.2.2.3), 다음의 경우 MS 디자이너 는 선택해야할 것이다. DMCC 가 콜 설정 절
차를 하던지 DMCC-RELEASE indication 을 user application 에 보낼지를...
DMCC 는 DMCC-SETUP request 를 DM-SETUP PDU 에 대응하게 convert 한뒤 전송해야한다. 그리고 CALL SETUP NORMAL ORIGINATING 상태로 진입한다. DM-SETUP PDU 를 전송한 뒤에, DMCC 는 레이어2에서 보내는 DMA-REPORT indication을 기다린다.
NOTE 2
싱글 DM-SETUP PDU 를 DMCC 가 전송한다, 이 것은 DMA-UNITDATA request primitive 내에 레이어2가 준다.
그렇다면 PDU 는 시간에 전유한 번호를 전송한다.전유한 전송 메소드를 사용해서 말이다. (clause 8를 보라)
비슷한 원칙을 허락하는데 언제나 DMCC 는 PDU를 전송한다. (clause 6.4 를 보라)
만약 DMCC 가 DMA-REPORT indication 받는걸 실패하면 DM-SETUP PDU를 전송한다. 그 이유는 채널이 BUSY 하기 때문이다. (채널 상태를 모른다.) 그것은 a) 나 b)를 해야할 것이다.
a) user applicaiton 은 DMCC-RELEASE indication 을 제공한뒤 IDLE 상태로 들어간다.
b) 충분한 높은 우선순위 요청은 pre-emption 절차를 기원한다; (clauses 6.2.6 이나 6.2.4 를 보라)
예외적으로, DMCC 가 DMA-REPORT indication 를 받으면 DM-SETUP PDU로 보고한뒤 CALL ACTIVE TX OCCUPATION 상태로 들어간다. (다음에 절차는 마스터 DM-MS 가 occupation 를 하는 동안을 위한 것이다.), user application 은 DMCC-SETUP confirm 을 제공하고 DMC-CONFIGURE request 를 issue 화 한다. 그리고 DT311 타이머를 시작한다.
NOTE3
첫번째 두번째의 절은 프로토콜 모델을 참조한다. 그것은 DMCC 의 의무이다. DMCC-SETUP request primitive 가 new call 과 관련있던지 on going call 을 계속해서 진행하는 것... 만약 DM-MS 가 콜과 관련되어 있다면 (마스터나 슬레이브에) 프리미티브를 요청한다. 그것은 "called party TSI" 파라메터를 담고있진 않는다.
- ongoing group call 을 위해, "called party TSI" 에 그룹주소를 지시한다.
- ongoing individual call 을 위해 "called party TSI" 에 다른 참여하는 파티를 지시한다.
DM-MS 는 DMCC-SETUP request prmitive 를 다음으로 취급한다.
● 만약 DM 채널이 occupation 이면, DM-MS는 늦게 ongoing call로 들어간다. DM-MS 는 선택한 정보를 허락한다. 마지막에 받은 DM-SETUP 이나 DM-OCCUPIED PDU에 의해서 또는 다음에 받았던 DM-OCCUPIED PDU 의 명령으로 콜로 진입한다.
DM-MS 는 어쩌면 ongoing call 을 계속해서 진행하기위한 요청을 보냈을 것이다,
다음에 절차는 slave DM-MS 가 occupation 동안을 위해 (6.2.4.2 를 보라) 결정한다, 예로 DM-PREEMPT PDU 를 전송하거나 멈춘다면 그 요청은 현재의 전송이 멈춘뒤에 DM-TX REQUEST PDU를 전송할 것이다.
● DM 채널이 reservation 되어 있다면 DM-MS 는 DM-SETUP/DM-OCCPIED PDU 를 마지막으로 받은것에 정보를 선택해서 허락했었을 것이다.
만약 call 이 occupation 하기이전에 접근해버렸다면, DM-MS 는 ongoing call 을 계속하기 위해 관련 요청을 보냈을 것이다. 다음에 절차는 slave DM-MS 가 reservation 하기 위한 것이고 (6.2.5.2 를 보라) 그리고 DM-TX REQUEST PDU 를 마스터에게 보낸다.
대신에 DM-MS 는 새로운 콜과 관련된 DMCC-SETUP request primitive 를 다룰수도있다.
그것은 frequency efficient mode, 일때이고 DM-MS 가 다른 DM 채널이 콜을 위해 선택하지 않을 것을 추천한다.
이것은 다른 DM채널이 FREE 일때에도 적용된다.
이와같이 DM-MS는 ongoing call 을 선점을 기획하거나 ongoing call 이 끝나기를 기다리거나 요청을 버리게된다.
NOTE 5
또다른 특별 케이스가 나타나는데 이것은 ongoing call이 individual call 을 포함하지 않을 때 DM-MS 그리고 user application 은 요청할 것이다. frequency efficent mode 를 위해서, 그것은 DM-MS 가 콜을 위해서 다른 DM 채널을 선택하지 않았을 때이고, 이것은 다른 DM 채널이 FREE 할때도 적용한다.
6.2.1.2 Incoming call
DMCC 로incomming call의 도착을 통지한다. DM-SETUP PDU 을 받아들여 엔트리를 만드는것을
만약 DM-SETUP PDU 내에 'call type flag' 이 점유하지 않으면 destination address 로..(예, DM-MS 가 DM-SETUP PDU를받았다면 그것은 individual call 이다. 하지만 "call type flag" 과 함께 "group call" 이 설정되거나 group address 가 하나일때 'call type flag' 는 'individual call' 로 설정한다. 그렇다면 DMCC 는 DM-SETUP PDU를 무시한뒤 IDLE 상태로 진입한다.
예외로 DMCC 는DM-SETUP PDU를 DMCC-SAP 을 통해 DMCC-SETUP indication 을 user application 으로 배달한 뒤 CALL SETUP NORMAL TERMINATING 으로 진입한다.
만약 user application 이 incoming call 을 accept 할수 없다면 (예, circuit mode call 을 요청했지만 터미널이 지원하지 못하는 데이터일때.) call 은 DMCC-SAP 을 통해 DMCC 에게 DMCC-RELEASE request 로 issue 화해 내부적으로 reject 한다.
DMCC 는 IDLE 상태로 들어가고 calling DM-MS와 협상이 가능한 상태로 된다.
예외적으로 user application 은 call 을 지원할 수 있다. 그리고 허락을 바란다. 그것은 DMCC-SETUP response를 즉시 보내야한다.
DMCC-SETUP response 응답을 받으면, DMCC 는 CALL ACTIVE RX OCCUPATION 상태로 진입하고 DMC-CONFIGURE request 를 lower layer에 전송한다. (다음에 절차는 slave DM-MS 가 occupation 동안을 위한 것이다.)
NOTE 1 :
그 기준들은 아마도 "lower layer quality information" 파라메터를 사용해 포함했을 것이다. 만약 DMCC-SETUP indication 을 제공한다면 이 파라메터는 받았던 signal strength 에 대한 정보를 준다, 아날로그 레디오 유닛내에 컨트롤을 진압해 기능을 동등하게 만든다.
NOTE 2 :
만약 DM-SETUP PDU 가 콜을 계속하기를 바란다면 DM-MS 가 이미 파티되었을 때 DMCC 는 DMCC-SETUP indication 내에 user application 로 정보를 배달하는데, 이것은 MS 디자이너가 선택한다. user application 가 DMCC-SETUP response 나 DMCC-RELEASE request (as above)을 리턴할지 또는 DMCC 가 콜을 계속하기를 결정할 수도있다. (이 선택은 신뢰할지도 모른다. MS는 하위레이어에 성능 정보를 결정하기 위해서 콜 진행을 허락해 선택하는 것을..)
group call은 이 설정을 사용하고 individual call 은 이 설정을 사용할지도 모른다.
6.2.1.1 Outgoing call
user application 이 콜을 초기화 하거나 ongoing call 을 DMCC-SETUP request primitive 에 의해(DMCC-SAP 에서 DMCC 엔티티로)
계속해서 진행하려고할때 다음에 절차를 허용한다. DMCC-SETUP request indicates 는 presence check 가 꼭 필요하진 않는다.
DMCC-SETUP request 는 required service 에 지시하는 파라메터를 포함한다. 이 케이스에서는 협상하지 않는다. 그 콜에 priority 또한 말이다.
DMCC 는 다음에 절차를 사용한다.
● ongoing call을 계속해서 진행하려고 요청한다면 DMCC 는 6.2.4 나 6.2.5 에 절차를 행할 것이다.
● 예외 (새로운 콜과 관련된 요청을 할때)
- DM 채널이 현재 바뿔때 예) occupied or reserved ( or 채널 a 그리고 채널b 가 frequency efficient mode 모드상태일때 ), pre-emption 이 유효하면 DMCC 는 6.2.6 장에 절차를 선택할 것이다.
- DM 채널이 현재 자유롭다면 DMCC 는 콜설정 절차를 즉시 시도할 것이다.
- 채널 상태를 알수 없으면, DMCC 는 즉시 콜 설정을 시도하거나 DMCC-RELEASE indication 을 user application 에게 이슈화 한다.
NOTE
채널 상태를 알수 없는것은 DM-MS 가 빠르게 콜 설정을 시도하지 않았기 때문이거나. (8.4.2.2.2)
DM-MS 가 잠시 채널의 상태를 알수 없는 것이다. 이전 케이스에서
사용자가 원하는 콜을 만들때, DMCC 는 다음에 콜 설정 절차를 시도했었을 것이다.
DM-SETUP PDU를 전송하는데 - 레이어 2에서 DM 채널의 상태의 초기화 결정 절차를 위해 할것이다. 그리고 메시지를 전송한다
만약 지휘 DM 채널이 자유롭게 지시한다면 (8.4.2.2.3), 다음의 경우 MS 디자이너 는 선택해야할 것이다. DMCC 가 콜 설정 절
차를 하던지 DMCC-RELEASE indication 을 user application 에 보낼지를...
DMCC 는 DMCC-SETUP request 를 DM-SETUP PDU 에 대응하게 convert 한뒤 전송해야한다. 그리고 CALL SETUP NORMAL ORIGINATING 상태로 진입한다. DM-SETUP PDU 를 전송한 뒤에, DMCC 는 레이어2에서 보내는 DMA-REPORT indication을 기다린다.
NOTE 2
싱글 DM-SETUP PDU 를 DMCC 가 전송한다, 이 것은 DMA-UNITDATA request primitive 내에 레이어2가 준다.
그렇다면 PDU 는 시간에 전유한 번호를 전송한다.전유한 전송 메소드를 사용해서 말이다. (clause 8를 보라)
비슷한 원칙을 허락하는데 언제나 DMCC 는 PDU를 전송한다. (clause 6.4 를 보라)
만약 DMCC 가 DMA-REPORT indication 받는걸 실패하면 DM-SETUP PDU를 전송한다. 그 이유는 채널이 BUSY 하기 때문이다. (채널 상태를 모른다.) 그것은 a) 나 b)를 해야할 것이다.
a) user applicaiton 은 DMCC-RELEASE indication 을 제공한뒤 IDLE 상태로 들어간다.
b) 충분한 높은 우선순위 요청은 pre-emption 절차를 기원한다; (clauses 6.2.6 이나 6.2.4 를 보라)
예외적으로, DMCC 가 DMA-REPORT indication 를 받으면 DM-SETUP PDU로 보고한뒤 CALL ACTIVE TX OCCUPATION 상태로 들어간다. (다음에 절차는 마스터 DM-MS 가 occupation 를 하는 동안을 위한 것이다.), user application 은 DMCC-SETUP confirm 을 제공하고 DMC-CONFIGURE request 를 issue 화 한다. 그리고 DT311 타이머를 시작한다.
NOTE3
첫번째 두번째의 절은 프로토콜 모델을 참조한다. 그것은 DMCC 의 의무이다. DMCC-SETUP request primitive 가 new call 과 관련있던지 on going call 을 계속해서 진행하는 것... 만약 DM-MS 가 콜과 관련되어 있다면 (마스터나 슬레이브에) 프리미티브를 요청한다. 그것은 "called party TSI" 파라메터를 담고있진 않는다.
- ongoing group call 을 위해, "called party TSI" 에 그룹주소를 지시한다.
- ongoing individual call 을 위해 "called party TSI" 에 다른 참여하는 파티를 지시한다.
DM-MS 는 DMCC-SETUP request prmitive 를 다음으로 취급한다.
● 만약 DM 채널이 occupation 이면, DM-MS는 늦게 ongoing call로 들어간다. DM-MS 는 선택한 정보를 허락한다. 마지막에 받은 DM-SETUP 이나 DM-OCCUPIED PDU에 의해서 또는 다음에 받았던 DM-OCCUPIED PDU 의 명령으로 콜로 진입한다.
DM-MS 는 어쩌면 ongoing call 을 계속해서 진행하기위한 요청을 보냈을 것이다,
다음에 절차는 slave DM-MS 가 occupation 동안을 위해 (6.2.4.2 를 보라) 결정한다, 예로 DM-PREEMPT PDU 를 전송하거나 멈춘다면 그 요청은 현재의 전송이 멈춘뒤에 DM-TX REQUEST PDU를 전송할 것이다.
● DM 채널이 reservation 되어 있다면 DM-MS 는 DM-SETUP/DM-OCCPIED PDU 를 마지막으로 받은것에 정보를 선택해서 허락했었을 것이다.
만약 call 이 occupation 하기이전에 접근해버렸다면, DM-MS 는 ongoing call 을 계속하기 위해 관련 요청을 보냈을 것이다. 다음에 절차는 slave DM-MS 가 reservation 하기 위한 것이고 (6.2.5.2 를 보라) 그리고 DM-TX REQUEST PDU 를 마스터에게 보낸다.
대신에 DM-MS 는 새로운 콜과 관련된 DMCC-SETUP request primitive 를 다룰수도있다.
그것은 frequency efficient mode, 일때이고 DM-MS 가 다른 DM 채널이 콜을 위해 선택하지 않을 것을 추천한다.
이것은 다른 DM채널이 FREE 일때에도 적용된다.
이와같이 DM-MS는 ongoing call 을 선점을 기획하거나 ongoing call 이 끝나기를 기다리거나 요청을 버리게된다.
NOTE 5
또다른 특별 케이스가 나타나는데 이것은 ongoing call이 individual call 을 포함하지 않을 때 DM-MS 그리고 user application 은 요청할 것이다. frequency efficent mode 를 위해서, 그것은 DM-MS 가 콜을 위해서 다른 DM 채널을 선택하지 않았을 때이고, 이것은 다른 DM 채널이 FREE 할때도 적용한다.
6.2.1.2 Incoming call
DMCC 로incomming call의 도착을 통지한다. DM-SETUP PDU 을 받아들여 엔트리를 만드는것을
만약 DM-SETUP PDU 내에 'call type flag' 이 점유하지 않으면 destination address 로..(예, DM-MS 가 DM-SETUP PDU를받았다면 그것은 individual call 이다. 하지만 "call type flag" 과 함께 "group call" 이 설정되거나 group address 가 하나일때 'call type flag' 는 'individual call' 로 설정한다. 그렇다면 DMCC 는 DM-SETUP PDU를 무시한뒤 IDLE 상태로 진입한다.
예외로 DMCC 는DM-SETUP PDU를 DMCC-SAP 을 통해 DMCC-SETUP indication 을 user application 으로 배달한 뒤 CALL SETUP NORMAL TERMINATING 으로 진입한다.
만약 user application 이 incoming call 을 accept 할수 없다면 (예, circuit mode call 을 요청했지만 터미널이 지원하지 못하는 데이터일때.) call 은 DMCC-SAP 을 통해 DMCC 에게 DMCC-RELEASE request 로 issue 화해 내부적으로 reject 한다.
DMCC 는 IDLE 상태로 들어가고 calling DM-MS와 협상이 가능한 상태로 된다.
예외적으로 user application 은 call 을 지원할 수 있다. 그리고 허락을 바란다. 그것은 DMCC-SETUP response를 즉시 보내야한다.
DMCC-SETUP response 응답을 받으면, DMCC 는 CALL ACTIVE RX OCCUPATION 상태로 진입하고 DMC-CONFIGURE request 를 lower layer에 전송한다. (다음에 절차는 slave DM-MS 가 occupation 동안을 위한 것이다.)
NOTE 1 :
그 기준들은 아마도 "lower layer quality information" 파라메터를 사용해 포함했을 것이다. 만약 DMCC-SETUP indication 을 제공한다면 이 파라메터는 받았던 signal strength 에 대한 정보를 준다, 아날로그 레디오 유닛내에 컨트롤을 진압해 기능을 동등하게 만든다.
NOTE 2 :
만약 DM-SETUP PDU 가 콜을 계속하기를 바란다면 DM-MS 가 이미 파티되었을 때 DMCC 는 DMCC-SETUP indication 내에 user application 로 정보를 배달하는데, 이것은 MS 디자이너가 선택한다. user application 가 DMCC-SETUP response 나 DMCC-RELEASE request (as above)을 리턴할지 또는 DMCC 가 콜을 계속하기를 결정할 수도있다. (이 선택은 신뢰할지도 모른다. MS는 하위레이어에 성능 정보를 결정하기 위해서 콜 진행을 허락해 선택하는 것을..)
'Protocol > TETRA' 카테고리의 다른 글
DMCC 6.2 Circuit mode calls (0) | 2013.09.25 |
---|---|
4.3.2.1.2 Procedure in frequency efficient mode (0) | 2013.09.25 |
4.3.2.1.1 Basic procedure (0) | 2013.09.25 |
4.3.2 Setting up a call (0) | 2013.09.25 |
4.3.1 Constraints on the frame structure (0) | 2013.09.25 |