14.2 Overview of CMCE

14.2 Overview of CMCE
Figure 14.1 shows the position of the CMCE protocols in both the MS and in the BS protocol stack. The present
document does not define a BS protocol architecture or user application SAPs for the CMCE within the SwMI.
[code]그림 14.1 을 보면 MS 뼈내 내에 그리고 BS 프로토콜 스택내의 CMCE 프로토콜들 이다.
이 문서는 BS 프로토콜 아키텍쳐나 SwMI에 함께하는 CMCE을 위한사용자 어플 SAP 에 대해 선언되어있지 않다.[/code]

14.2.1 Communication routes of the CMCE model
[code]CMCE에 통신방법[/code]

The CMCE model defines routes used for information exchange between the sub-entities as shown in figure 14.2.
The external routes are routes between a sub-entity of the CMCE and an entity in another layer. Each external route
shall be mapped onto a SAP.
[code]그림 14.2 를 보면 sub-entitiee 에서의 정보 전환을 위해 CMCE에 사용될 노선을 정의한다. [/code]

There are four external routes.
[code]4개의 외부의 루틴이 존재한다.[/code]
• The ra route shall correspond to the TNCC-SAP. The primitives exchanged on that route are described in clause 11.
[code]ra 루트는 TNCC-SAP에 해당할 것이다. 교환되기 위한 방법은 11장에 루틴에 묘사되어 되어 있다.
[/code]
• The rb route shall correspond to the TNSS-SAP. The primitives exchanged on that route are described in clause 12.
[code]rb 루트는 TNSS-SAP에 해당할 것이다. 교환하기 위한 방법은 12장에 묘사되어 있다.
[/code]
• The rc route shall correspond to the TNSDS-SAP. The primitives exchanged on that route are described in clause 13.
[code]rc 루트는 TNSDS-SAP에 해당할 것이다. 교환하기 위한 방법은 13장에 묘사되어 있다.[/code]

• The ri route shall correspond to the LCMC-SAP. The primitives exchanged on that route are described in clause 17.
[code]ri 루트는 LCMC-SAP와 해당할 것이다. 교환하기 위한 방법은 17장에 묘사되어 있다.[/code]

The internal routes are routes between sub-entities of the CMCE.
[code]내부 루트는 루트에서 CMCE sub-endtities 사이에 존재한다.[/code]

There are five internal routes:
[code]5가지의 내부 루틴[/code]

• the rd route shall be a route between the CC sub-entity and the PC sub-entity;
[code]rd 루트는 CC sub-entity 에서 PC sub-entity 까지의 루트일 일것이다.[/code]

• the re route shall be a route between the SS sub-entity and the PC sub-entity;
[code]re 루트는 SS sub-entity 에서 PC sub-entity 까지의 루트일 것이다.[/code]

• the rg route shall be a route between the SS sub-entity and the CC sub-entity;
[code]rg 루트는 SS sub-entity 에서 CC sub-entity 까지의 루트일 것이다.[/code]

• the rf route shall be a route between the SDS sub-entity and the PC sub-entity;
[code]rf 루트는 SDS sub-entity and the PC sub-entity 까지의 루트일 것이다.[/code]

• the rh route shall be a route between the SS sub-entity and the SDS sub-entity.
[code]rh 루트는 SS sub-entity 에서 SDS sub-entity 까지의 루트일 것이다.[/code]

14.2.2 Protocol structure and protocol stack
[code]프로토콜 구조체와 프로토콜 스텍[/code]

The CMCE is the layer 3 sub-layer for circuit mode CC, SS and SDS as described in clauses 11, 12 and 13 respectively.
CMCE shall provide services to the user applications through service primitives defined for the following three SAPs:
[code]CMCE는 서킷모드 CC, SDS layer 3 sub-layer 이며 11, 12, 13장에 각각 설명이 되어 있다.
사용자 요청에 의한 CMCE에 지원 서비스들은 서비스 선언된 primitives 을 통해 지원되며 3개에 SAP를 위해서 지원된다.[/code]

• TNCC-SAP for CC services;
• TNSS-SAP for SS services;
• TNSDS-SAP for SDS.
[code]CC 서비스들을 위한 TNCC-SAP (Call control)
SS 를 위한 TNSS-SAP (Supplementary Service)
SDS 를 위한 TNSDS-SAP (Short Data Service)[/code]

NOTE: Although there are separate SAPs defined for CC and SS, the protocol description is based on the CC
service primitives, which contain a mixture of CC and SS parameters.
There shall be one instance of the CMCE entity per TSI family within the MS.
The CMCE is internally subdivided into four different sub-entities:

[code]SAP들이 분리되어 선언되어 있는 것은 CC(Call Control) 그리고 SS(Suppmentary Service)를 위해서 이다.
그 프로토콜에 설명은 CC(Call Control) 서비스 Primitive 들을 기본으로 한다.
CC(Call Control) 그리고 SS(Suppmentary Service) 파라메터들의 값들이 혼합되어 실려 있으며
음성 그리고 LCMC-SAP(Link entity Circuit Mode Control entity Service Access Point) 를 통한 MLE(Mobile Link entity) 를 얻을 것이다.
MS(Mobile Station) 내부의 TS(TETRA Subscriber Identity) 에 의한 CMCE(Circuit Mode Control Entity)의 하나의 단계 일 것이다.
CMCE 는 내부적으로 4개의 다른 sub-entitiess 들로 세분화 되어 있다.[/code]

• CC; (Call control)
• SS; (Suppemntary Service)
• SDS; and (Short Data Service)
• Protocol Control (PC).

The information exchange between the CC and the SS sub-entities is defined in the supplementary service definitions.
The structure is as shown in figure 14.2.
[code]CC(Call control) 과 SS (Suppmentary Service) sub-entities 교환 정보는 보조 서비스 선언내에 선언되어 있다.[/code]

14.2.3 Addressing rules
[code]주소 규칙[/code]

In addition to the normal TSI which is used in different forms in the initial call set-up messages (ITSI, GTSI, SSI), the
CMCE entity shall also use the call identifier for call handling.
[code]TSI(TETRA Subscriber Identity) 기본에 추가 한다. 초기화 call 설명 메시지 내에 다른 형식을 선택하였다면 (ITSI, GTSI, SSI) call 를 위한 call 핸들링은 CMCE (Circult Mode Control Identity) entity 또한 선택해야 할 것이다.[/code]

ITSI (Individual TETRA Subscriber Identity)
GTSI (Group TETRA Subscriber Identity)
SSI (Short Subcriber Identity)

The call identifier shall be used as a unique reference to a call between a call participant and the SwMI. A call identifier
is allocated at call set-up time by the SwMI and the call identifier may be changed by the SwMI by allocating a new call
identifier to the MS for the call. Once allocated, the call identifier shall be used in subsequent call related CMCE
messages for that call.
[code]전화 참가자 그리고 SwMI (Swithcing Management Infrastructure) 간에 전화로 전화식별자는 유일한 참고자를(?) 선택해야할 것이다.
[/code]
The layer 3 air interface messages may contain only the SSI part of an address. The following rules define how the
receiving entity shall, if it needs to do so, derive the MNI (i.e. convert the SSI to full ITSI or GTSI) if the MNI is not
supplied over the air interface.

[code]layer 3 air interface 메시지 들은 오직 SSI 파트의 주소들을 담고 있어야 할 것이다.
MNI를 얻기를 필요로 한다면은 (MNI 에서 ITSI 나 GTSI 를 전체적으로 SSI로 컨버트 하기)[/code]

• The SwMI shall interpret the "Called party SSI" or "Other party SSI" on received uplink messages as
belonging to the SwMI (i.e. the "missing" MNI is the MNI of the current network).
[code]SwMI는 해석해야 할 것이다. SSI 에 전화를 건 파티나 SSI 에 또다른 파티들을 받았던 Uplink SwMI 속성 메시지들에서
분실한 MNI(Mobile Network Identity) 는 선택된 네크워크의 MNI 이다.[/code]

• The MS shall interpret the "Calling party address SSI" or "Transmitting party address SSI" on received
downlink messages as belonging to the current SwMI (i.e. the "missing" MNI is the MNI of the current
network).
[code]MS(Mobile Station)은 해석해야 할 것이다. 전화를 거는 파티의 주소 SSI(Short Subscriber Indentity) 나 전송하고 있는 파티의 주소에 SSI(Short Subscriber Identity) 를 다운 받은 메시지들의 속성을 선택한 SwMI(Switching Management Infrastructure) 으로
[/code]
NOTE 1: The MNI of the SwMI (MCC and MNC) is sent in the broadcast D-MLE-SYNC PDU, refer to clause 18.4.2.1.
[code]SwMI의 MNI(Mobile Network Identity) (MCC [Mobile Contury Code] 그리고 MNC [Mobile Network Code]) 는 D-MLE-SYNC PDU 속에 브로드캐스팅하여 전달된다, 18.4.2.1장을 참고한다.[/code]

NOTE 2: The first rule forces the MS to send the MNI over the air interface also when the called user address belongs to the home network of the MS and MS has migrated to a foreign network - edition 1 of the Dialling and Addressing Designer's Guide, TR 102 300-5 [42], describes a different approach which is no longer valid.
[code]첫번째 룰은 MS(Mobile Station) 를 MNI(Mobile Network Indentity)를 위에 air interfarce 로 전송한다.
전화건 사용자의 주소가 home network의 MS(Mobile station) 그리고 MS 가 다른 네트워크로 이주했을 때 소속된다.[/code]

NOTE 3: The second rule allows to use only SSI addressing so that all MSs in the same SwMI, independently of
whether they are in their home or in a visited SwMI, will understand it in the same manner (for example
group calls having participants belonging to different networks).
[code]2번째 룰은 주소를 쓰는 동안 동일한 SwMI 안에 하나의 SSI를 하기위해 모든 MS들을 사용할 수 있게 허용한다.
그들이 그들의 HOME 또는 방문한 SwMI 내에 독립적으로 존재한는 걸 알 수 있다.
그것은 동일 방식이다.[/code]

NOTE 4: The supplementary service related information in U/D-FACILITY PDU or in facility information element
may use SSI differently, refer to supplementary service definitions.
[code]보조 서비스는 U/D-FACILITY PDU 안에 정보가 관련 되어 있다. 혹은 시설 안의 정보 요소는 보조 서비스 정의를 가르켜 SSI를 다르게 사용할 수도 있다.[/code]

NOTE 5: The visiting GSSI (V-GSSI) is used only as a layer 2 address in reception and also by MM in layer 3
PDUs in the group attachment/detachment procedures. V-GSSI s/87hall not be used as "Called party SSI" or
"Other party SSI" in CMCE PDUs.
[code]그룹 추가/분리 규칙내에 layer 3 PDU 들 내 MM(Mobile Management) 에 의하거나 수신할 layer 2 주소에 선택한 것이 방문하는 GSSI(Group Short Service Identity) 이다.
V-GSSI s/87hall 은 CMCE(Circuit Mode Control Entity) PDU(Protocol Data Unit) 에 전화를 했던 SSI(Short Service Identity) 나 또 다른 SSI 에게 선택되지 않았다.[/code]

NOTE 6: If a SwMI allocates a temporary address the MS will consider that the MNI of it is the one of the current SwMI.
[code]만약 SwMI(Swithcing Management Infrastructure) 가 임시주소에 할당했다면 MS(Mobile Station) 은 선택된 SwMI 의 MNI(Mobile Network Identity)를 검토할 것이다.[/code]

14.2.4 CC, SS and SDS sub-entities
The CMCE model describes the protocol behaviour of CC, SS and SDS functional entities.
[code]CMCE(Circuit Model Control Entity)에 대해 묘사할 것이다.
CC(Call Control), SS(Sub Subscriber) 그리고 SDS(Short Data Service) 기능 엔티티들의 프로토콜의 행동에 대해서[/code]

14.2.4.1 CC sub-entity
The CC process is a functional sub-entity which provides a set of procedures for the establishment, maintenance and
release of circuit switched services. It provides support for the TETRA basic call signalling. The CC shall manage
invocation of the SS-Access Priority.
[code]CC(Call control) 은 sub-entity 의 기능이다.
시설을 위해 설정한 유지관리나 서킷 스위치를 했던 것들에 릴리즈 작업들을 지원한다.
만약 TETRA 의 기본 CALL 시그널링을 위해 지원을 제공한다면 CC는 SS(Supplementary Service) 접근 우선권을 관리해야할 것이다.[/code]

The CC process shall use the ra signalling route for communication with the user application (see clause 11) and the rd
signalling route for communication with the protocol control process. The information exchange of SS related
parameters needed for SS information exchange is not defined.
[code]CC(Call Control) 은 사용자 요청간에 통신을 위해서 ra 시그널링 라이터를 해야 할 것이다.(11장 보기) 그리고 프로토콜 제거 프로세스와 함께하는 통신을 위해 rd 시그널링 라우트해야할 것이다.
SS(Supplementary Service) 에 등록되지 않은 정보교환 때문에 SS에 관련 있는 파라메터의 정보 교환이 필요하다.[/code]

There can be multiple instances of CC per CMCE entity. Depending on its physical capabilities an MS may be able to
support up to four active concurrent circuit mode calls at the same time.
[code]CMCE(Circuit Mode Control Entity) 에 의한 CC(Call control) 의 다중 인스턴스는 그곳에 존재할 것이다.
MS(Mobile Station) 은 4개가 동시간대에 활성화되어 순환모드로 작동하는 것을 지원할 것이다.[/code]

The SS process is a functional sub-entity which provides procedures for transfer of information related to SSs. The
transfer of SS information is either call related or call unrelated.
[code]SS 프로세스는 관련된 정보를 SS(Supplementary Service)로 전송하기 위한 절차를 제공하는 기능을 한다. SS정보 전송은 관련된 어느 call 이거나 관련없는 call 이다.[/code]

The SS processes shall use the rb signalling route for communication with the user application over the TNSS-SAP (see
clause 12) and the re signalling route for communication with the protocol control process. Internal communication
between the CC process and the SS process is outside the scope of the present document.
[code]SS(Supplementary Service) 프로세스 TNSS-SAP(TETRA Network Supplementary Services - Service Access Point) 위의 사용자 요청과 함께 rb 시그널링 루트 통신을 위해서 그리고 프로토콜 컨트롤 프로세스와 re 시그널링 루트간에 통신을 위해 선택하여야 한다.
CC(Call control) 프로세스 와 SS(Supplementary Service) 프로세스 사이 내부통신은 현재 문서 내용에 벗어 난다.[/code]

SSs related to a call in progress shall have a fixed relationship with the corresponding CC entity instance
and these SS instances shall cease to exist after the CC instance ceases to exist.
[code]관련되어 있는 SS(Supplementrary Service) 에서 대응되는 CC Entity 인스턴스와 함께 관계가 고정되었을 것이다. (call 작업내에)
그리고 CC인스턴스를 중단하려한 이후에 SS인스턴스도 중단할 것이다.[/code]

There shall be also a SS entity, which is not related to any calls in progress. That entity may use either a
U/D-FACILITY PDU or any CC PDU, when appropriate, to exchange SS information between a MS and a SwMI.
[code]SS(Supplementary Service) 또한 그걸 해야할 것이다.
또한 SS(Supplement Service) 에 entity 가 관련되지 않은 어느 call 작업중에 존재할 것이다.
entity는 WD-FACILITY PDU(Protocol Data Unit) 이나 CC(Call Control) PDU 가 MS(Mobile Station) 과 SwMI(Switching Manage Infrastructure) 사이에 SS 정보가 변경될 적절한 시간에 어느 한쪽을 선택할 것이다.[/code]

The facility field of the CC PDUs shall only be used to exchange SS information between a MS and the SwMI.
[code]CC PDU(Protocol Data Unit) 들의 facility SS(Supplementary Service) MS 와 SwMI 간 정보 교환으로 영역이 선택되었을 것이다.[/code]


14.2.4.3 SDS sub-entity
The SDS process shall be a functional sub-entity which provides procedures for transfer of short data and status
messages.
[code]SDS 프로세스는 보조 entity 가 short data 그리고 상태 메시지를 전송하기 위해 제공되는 절차를 작동 할 것이다.[/code]

The SDS entity shall also manage invocation of the SS- Access Priority for the short data PDU exchange.
[code]또한 SDS 엔티티는 short data PDU 변경을 위해서 SS(Supplementary Service) 접근 권한을 manage invocation 할 것이다. [/code]

The SDS process shall use the rc signalling route for communication with the user application over the TNSDS-SAP
(see clause 13) and the rf signalling route for communication with the protocol control process.
[code]SDS 프로세스는 TNSDS-SAP 위의 사용자 신청과 함께 rc 시그널링 루트의 통신을 위해 선택해야할 것이다. (13장 보라)
그리고 프로토콜 컨트롤 프로세싱과 함께 rf 시그널링 루트 와 통신하기 위해서 선택해야할 것이다.[/code]

The SDS entity shall not be related to any call and it shall provide SDS services independently of whether the SDS
message is directed to a user application involved in an active CC call, or not.
[code]SDS 메시지가 활동적인 CC(Call control) call 내의 관련된 사용자 신청에 지시되거나 그것은 SDS 서비스를 독립적으로 제공하거나 제공하지 않을 것이다.[/code]

There shall only be one instance of SDS entity per CMCE entity.
[code]그곳에 CMCE(Circuit Management Control Entity)에 엔티티에 의한 하나의 SDS 엔티티 인스턴스이다. [/code]

14.2.5 PC sub-entity

The PC sub-entity shall provide the following functionality:
[code]PC(Protocol control) 보조 엔티티는 다은 기능을 지원할것이다 [/code]

• PC shall act as an upwards/downwards router by discriminating the upper sub-entities within CMCE. The
analysis of the content of the various information elements in the PDUs shall be done by the sub-entity which
is responsible for and owns the individual elements. Outgoing PDUs shall be routed to the MLE in primitives;
[code]PC(Protocol control) 는 CMCE 안에 보조 엔티티들을 식별력하여 상향/하향 라우터한다.
컨텐츠의 분석은 PDU들의 여러 정보 요소들로 완료된다. 소유권에 대한 책임을 개개의 요소 서브 엔티티에 의한다.
PDU들에 나가는 루트에서 MLE(Mobile Link Entity) 내 primitives 로[/code]

• PC shall ensure that there is only one mobile originated call set-up in progress at any one time by only
allowing one CC sub-entity at a time to be actively setting up a call until SwMI allocates a call identifier to
that call or the call set-up is discarded;
[code]그 calll의PC(Protocol control) 은 어떤 시간에 오직 하나의 모바일을 설정하는 작업을 확실히 할 거나 call 설정을 폐기할 것이다.[/code]

• MLE shall give indications of the progress of the PDU transmission to PC by MLE-REPORT indication
primitives. PC shall be responsible for handling of general error procedures for the CMCE protocol;
[code]MLE(Mobile Link Entity) 는 PDU를 MLE-REPORT indication primitive 에 의해서 전송작업의 표시를 줄것이다. 신뢰할 수 있을 것이다.[/code]

• PC shall use the signalling routes rd, re, rf for communication with the CC, SS and SDS sub-entities, and the ri
signalling route for communication with the MLE over the LCMC-SAP;
[code]PC(Protocol control)은 선택할 것이다 시그널링 루트 rd, re, rf를 CC(Call control), SS(Supplementary, Service), 그리고 SDS(Short Data Service) 보조 엔티티들과 통신을하기 위해서 그리고 LCMC-SAP(Link entity Circuit Mode Control entity - Service Access Point)위의 MLE(Mobile Link Entity) 와 함께 시그널링 루트를 통신을 위해서[/code]

• there shall only be one instance of PC per CMCE entity.
[code]CMCE(Circuit Management Control Entity) 엔티티에 의한 PC(Protocol Control)의 1개의 인스턴스가 있을 것이다.[/code]