The packet transfer is secured in this way; the receiving station checks the packet and sends an acknowledgement (ACK) about the error-free receiving of each packet. The transmitting station after obtaining this report regards the transfer to be completed. If it obtains the no-acknowledge (NAK) report about wrong packet receiving or if it does not obtain ACK for the designated time (timeout), then it sends the packet again and this transmission is repeated pertinently until the number of repetitions is exhausted (repeat).
The security of transmission (to safeguard the packet) is pursued separately on every section of the route. The packet transmission between the user device and the SCC port is secured separately (according to attributes of protocol used) and the transmission on the individual sections of the MORSE route is also secured separately (according to the packet type setting).
The error free checking of packet transmitted is done in a way that the sending device does the given mathematical operation with the packet. The result, called checksum, is appended to the end of packet and then dispatch. The receiving device does the same operations with the packet and compares the result with the received checksum. If the checksums agree, then there is a high probability that an error didn’t occur in the transmission and the message ACK is sent.
Security in the user channel
The transmission between the user device and the SCC channel is secured according to protocol used. Some protocols (e.g. async.link) do not secure transmission, for this reason they are suitable only for lines which are very reliable. Some protocols allow the security to be switched on/off in their parameters (RDS), and others have the security always on (MARS-A). For a successful transmission, the link must have on both ends the same protocol with the same parameters set.
Security in the net and link MORSE channel
When the SCC channel receives the packet from external device, it
adjustes it in the unified format for the MORSE network. This format
contains among others the byte packet type with bit
security . The security system is activated according to this
bit, which secures the transmitting in each step through the MORSE
network.
The SCC channel behaves according to parameter sec in
the menu SIe , which can get the values
ON, OFF, user . These are set in
the menu SIe1u by combination of parameters
user se(c) and (s)ecurity.
Channel to Node Interface:
retranslation | user+service lim
id N A t m | N A t Base m sec brc S e
(0) 0 NO AR | 1 NO AR usr OFF NONE
(1) 0 NO AR | 2 MASK 00000000/08 ON OFF NONE
(2) 0 NO AR | 1 MASK 00000000/08 OFF OFF NONE
(3) 0 NO AR | 0 MASK 00000000/08 usr OFF NONEInfluence of sec parameter to the packet type
setting:
parametr security bit security
SIe1uc SIe1us SIe in packet type
user se(c): (s)ecurity: sec
OFF ON ON active ON
OFF OFF OFF no active OFF
ON OFF/ON usr according to packet type
in incoming packetIn the last case when usr is set in the SIe column,
the security bit of resulting packet is set according to the incoming
packet type. The parameter SIe1us has not meaning
here.
security bit: incoming packet resulting packet ON ON OFF OFF not included ON
![[Important]](/images/radost/images/icons/important.png){kind=icon} | Important |
|---|---|
Change in the default setting: up to version fw 721 the parameter SIe sec = ON from version fw 723 the parameter SIe sec = usr |
The security bit in the packet type (visible in the monitoring iMS, iMF ) then switches on/off the security at the radio transmission. The repeat parameters for it are prepared in the menu FPe in paragraph ACK.
RF channels:
Access |ACK |coding |Mobile
id a del l num TO|fix var rep P hT|mod typ|base mask center per
(0) NORMAL 16 16 4 10| 600 400 5 30|REP DBL|OFF
(1) NORMAL 16 16 4 10| 600 400 5 30|REP DBL|OFF
(2) NORMAL 16 16 4 10| 600 400 5 30|REP DBL|OFF
(3) NORMAL 16 16 4 10| 600 400 5 30|REP DBL|OFF
(4) NORMAL 16 16 4 10| 600 400 5 30|REP DBL|OFFThe timeout is set by the sum fix+(0to3)var [ms],
where (0to3) is the random number protecting against
blocking, when two CUs are sending concurrently. The max. number or
repeats is set by parameter rep.
Next configuration is used for the illustration:
The node 690F1240 simulates the user equipment called here terminal, which sends the packets to the node 690F1241 belonging to MORSE network.
Terminal
From the menu its there is send to the node 40,
the command which makes the node generate the packet and send it to the
destination address 40. The node fulfills it and sends it at the next
routing to it’s user output, because the destination
address is equal to it’s own address.
The packet is given to the port SCC2, where is set the address changing by table Art1, which changes the destination address from 40 to 45. In the menu SPe there is set the protocol RDS, which parameters allows to check out several versions of security.
CU – Communication Unit
The packet addressed now to the destination 45 is given, by the crossed link, to the port SCC1. We follow the incoming packet in the point A by monitoring of SCC1. The packet MORSE is completed here and it is supplemented by packet type according to the parameter SIe1u sec. The resultant packet given to the node 690F1241 in the point B we can see by the iMSI monitoring.
The packet is sent from the node by channel RFC to the address 45. However it is out of reach and the ACK doesn’t come. So we can see in the point C the work of repeated sending using the monitoring RFC.
In the terminal and in the CU is the protocol RDS used, in which parameters is set:
(a):1000ms – timeout
(r):1 – number of repeats
(m) – form of check sum
(c) – switching ACK on/off
Using the parameters (m) and (c) we can simulate various situation:
Terminal generates the packets with different check sum, that is expected at CU, the ACK is off.
Terminal: Communication unit: Parameters SCC2 Parameters SCC1 RDS parameters: RDS parameters: (a):1000 (r):1 (m):0000 (a):1000 (r):1 (m):FFFF (c) :OFF (c) :OFF
Monitoring in point A:
>> 13:55:08.222 rx;i 7 | S01 4445 0200 AAAA 00
SCC1 in CU accepted the packet, checked it according to check sum as wrong and so SCC1 didn’t create the MORSE packet and didn’t send it next in the node.
The terminal generates again the packets with wrong crc but in this case expects the ACK.
Terminal: Communication unit: Parameters SCC2 Parameters SCC1 RDS parameters: RDS parameters: (a):1000 (r):1 (m):0000 (a):1000 (r):1 (m):FFFF (c) :ON (c) :OFF
Monitoring:
>> 14:02:58.074 rx;i 7 | S01 4445 0200 AAAA 00 14:02:59.078 rx;i 7 | S01 4445 0200 AAAA 00
SCC1 in CU evaluated the packet as wrong, but it has not
permitted the ack sending, so it sends to the terminal no ACK nor
refusing NAK. This is why the terminal after passing timeout 1000 ms
once repeats the sending (it is set (r):1 ).
The terminal generates packet having the same crc as expects the
CU. The parameter in CU in menu SIe
sec OFF.
Terminál: Communication unit: Parameters SCC2 Parameters SCC1 RDS parameters: RDS parameters: (a):1000 (r):1 (m):FFFF (a):1000 (r):1 (m):FFFF (c) :ON (c) :ON
Setting SIe sec for SCC1 is OFF:
Channel to Node Interface:
retranslation | user+service lim
id N A t m | N A t Base m sec brc S e
(0) 0 NO AR | 1 NO AR usr OFF NONE
(1) 0 NO AR | 1 NO AR OFF OFF NONE
(2) 0 NO AR | 1 MASK 00000000/08 usr OFF NONE
(3) 0 NO AR | 0 MASK 00000000/08 usr OFF NONEMonitoring:
>> 15:13:24.257 rx;i 7 | S01 4445 0200 AAAA 21 15:13:24.257 tx 1 | S01 06 15:13:24.257| |690F1245 690F1241|S01I OUT 2||09 0user AAAA 15:13:24.257|690F1245 690F1241|690F1245 690F1241|01D RFTX 2 09 4dat AAAA
After receiving the packet, the SCC1 send back the ACK = 06, so
the terminal doesn’t repeat the sending. SCC1 created the MORSE packet
from succesfuly checked packet received from wire link. According to
the parameter sec=OFF in menu SIe the
packet got the type 09 as we can see in CNI monitoring of port S01.
The packet type 09 contains the information, that the packet will go
through the MORSE network unsecured. This is why the RF channel
transmitted the packet to the address 690F1245 and in spite of it
didn’t become any ACK, the repeated transmission was not done.
We can see in the monitoring, that at creating the MORSE packet
in the SCC1 channel was the data AAAA adopted from the
original packet and the MORSE address 690F1245 was formulated from the
short address 45. The others parts of original packet will be recreate
in the SCC at the leaving the MORSE network and they are not
transfered through the MORSE network.
The parameters of link connection between the terminal and the
CU remain the same as previously. In this case is in the SCC1 in menu
SIe set the parameter sec=ON.
In the menu FPe there are set the parameters
for repeating on RF channel fix=600,
var=400, rep=2:
RF channels:
Access |ACK |coding |Mobile
id a del l num TO|fix var rep P hT|mod typ|base mask center per
(0) NORMAL 16 16 4 10| 600 400 5 30|REP DBL|OFF
(1) NORMAL 16 16 4 10| 600 400 2 30|REP DBL|OFF
(2) NORMAL 16 16 4 10| 600 400 5 30|REP DBL|OFF
(3) NORMAL 16 16 4 10| 600 400 5 30|REP DBL|OFF
(4) NORMAL 16 16 4 10| 600 400 5 30|REP DBL|OFFMonitoring:
>> 15:34:26.742 rx;i 7 | S01 4445 0200 AAAA 21 15:34:26.742| |690F1245 690F1241|S01I OUT 2||89 0user AAAA 15:34:26.742 tx 1 | S01 06 15:34:26.742|690F1245 690F1241|690F1245 690F1241|020 RFTX 2 89 7dat AAAA 15:34:28.563|690F1245 690F1241|690F1245 690F1241|020 RFTX d 2 C9r7dat AAAA 15:34:29.993|690F1245 690F1241|690F1245 690F1241|020 RFTX d 2 C9r7dat AAAA
From the error free packet incommed through the link into SCC1
was the MORSE packet created. According to the parameter
sec=ON it was defined as type 89 (secured) and in this state it
was send to the node 690F1241. The node transmitted it through the RF
channel. The ACK doesn’t come, so the transmitting was repeated twice
more according to the parameter rep.
The same effect would have the parameter sec=usr in
the menu SIe, because the packet incomming through
the protocol having no security information, is in SCC defined as
secured. In other case, if in SCC would be used the MARS-A protocol
carying the packet type information through the serial link, then the
packet type defined in SCC1 would be done according to it.
The CU 690F1245 was added. It receives the packet on RFC and sends the ACK.
>> 09:24:49.702 rx;i 7 | S01 4445 0200 AAAA 21 09:24:49.702| |690F1245 690F1241|S01I OUT 2||89 0user AAAA 09:24:49.703 tx 1 | S01 06 09:24:49.703|690F1245 690F1241|690F1245 690F1241|022 RFTX 2 89 1dat AAAA 09:24:49.743|690F1241 690F1245| |022*31~ 96 0*06 ack
We can see in the monitoring, that the packet 4445 0200
AAAA 21 obtained from the terminal was acknowledged by sending
06. The packet was modified to the MORSE form having the
packet type 89 and sent into node. From the node was the
packet sent through RF channel to the address 690F1245 and the ACK was
received. By this actions was fulfilled the task of node 690F1241 and
the next secured transmission of this packet is work for the next
nodes.