1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
|
== Network Service (NS)
=== List of Messages
The following tables list the NS messages used by OsmoPCU, grouped by their
level of compliance with 3GPP TS 08.16.
==== Messages Compliant With 3GPP TS 08.16
The NS protocol is implemented inside libosmocore so none of the messages below are sent by OsmoPCU explicitly.
Instead corresponding functions from libosmocore are called which send and receive messages as necessary. See <<ns_init>> for details
on establishing NS connection.
.Messages compliant with 3GPP TS 08.16
[options="header",cols="10%,10%,20%,35%,5%,20%"]
|===
| TS 08.16 § | type code (hex) | This document § | Message | <-/-> | Received/Sent by OsmoPCU
| 9.2.10 | 0x00 | <<ns_unit_data>> | NS-UNITDATA | <-/-> | Received/Sent
| 9.2.5 | 0x02 | <<ns_reset>> | NS-RESET | <-/-> | Received/Sent
| 9.2.6 | 0x03 | <<ns_reset_ack>> | NS-RESET-ACK | <-/-> | Received/Sent
| 9.2.3 | 0x04 | <<ns_block>> | NS-BLOCK | <-/-> | Received/Sent
| 9.2.4 | 0x05 | <<ns_block_ack>> | NS-BLOCK-ACK | <-/-> | Received/Sent
| 9.2.8 | 0x06 | <<ns_unblock>> | NS-UNBLOCK | <-/-> | Received/Sent
| 9.2.9 | 0x07 | <<ns_unblock_ack>> | NS-UNBLOCK-ACK | <-/-> | Received/Sent
| 9.2.7 | 0x08 | <<ns_status>> | NS-STATUS | <-/-> | Received/Sent
| 9.2.1 | 0x0a | <<ns_alive>> | NS-ALIVE | <-/-> | Received/Sent
| 9.2.2 | 0x0b | <<ns_alive_ack>> | NS-ALIVE-ACK | <-/-> | Received/Sent
|===
==== Messages Specific to OsmoPCU
There are no OsmoPCU specific NS messages.
==== Messages Not Implemented by OsmoPCU
All the NS protocol messages from 3GPP TS 08.16 are implemented in OsmoPCU.
=== Details on Compliant NS Messages
[[ns_unit_data]]
==== NS-UNITDATA
This PDU transfers one NS SDU (specified in 3GPP TS 08.18) between
OsmoPCU and SGSN. Upon receiving it OsmoPCU passes it to BSSGP
implementation to handle. It is also sent by BSSGP as necessary - see
<<bssgp>> for details.
It contains BVCI (<<ie_bvci>>) and NS SDU (<<ie_nssdu>>) IEs.
[[ns_reset]]
==== NS-RESET
This message is send by OsmoPCU in order to initiate reset procedure
described in 3GPP TS 08.16 § 7.3. The expected reply is NS-RESET-ACK
(<<ns_reset_ack>>) message. If no expected reply is received in 3
seconds than the sending is retried up to 3 times. When this message
is received it is replied with NS-RESET-ACK (<<ns_reset_ack>>).
It might be ignored under conditions described in 3GPP TS 08.16 § 7.3.1.
The message conforms to 3GPP TS 08.16 § 9.2.5 specification.
It contains Cause (<<ie_cause>>), NSVCI (<<ie_nsvci>>) and NSEI (<<ie_nsei>>) IEs.
[[ns_reset_ack]]
==== NS-RESET-ACK
This message is sent as a response to proper NS-RESET (<<ns_reset>>)
message initiating reset procedure.
The message conforms to 3GPP TS 08.16 § 9.2.6 specification.
It contains NSVCI (<<ie_nsvci>>) and NSEI (<<ie_nsei>>) IEs.
[[ns_block]]
==== NS-BLOCK
Upon receiving this message corresponding NS-VC is marked as blocked
by OsmoPCU and NS-BLOCK-ACK (<<ns_block_ack>>) reply is transmitted.
When this message is sent by OsmoPCU corresponding NS-BLOCK-ACK
(<<ns_block_ack>>) reply is expected before NS-VC is actually marked
as blocked. This behavior follows the blocking procedure described in
3GPP TS 08.16 § 7.2.
The message conforms to 3GPP TS 08.16 § 9.2.3 specification.
It contains Cause (<<ie_cause>>) and NSVCI (<<ie_nsvci>>) IEs.
[[ns_block_ack]]
==== NS-BLOCK-ACK
This message is sent by OsmoPCU automatically upon reception of
correct NS-BLOCK (<<ns_block>>) message. It is expected as a reply
for NS-BLOCK (<<ns_block>>) message sent by OsmoPCU.
The message conforms to 3GPP TS 08.16 § 9.2.4 specification.
It contains NSVCI (<<ie_nsvci>>) IE.
[[ns_unblock]]
==== NS-UNBLOCK
Upon receiving this message corresponding NS-VC is unblocked by
OsmoPCU and NS-UNBLOCK-ACK (<<ns_unblock_ack>>) reply is sent. When
this message is sent by OsmoPCU corresponding NS-UNBLOCK-ACK
(<<ns_unblock_ack>>) reply is expected before NS-VC is actually marked
as unblocked. This behavior follows the blocking procedure described
in 3GPP TS 08.16 § 7.2.
The message conforms to 3GPP TS 08.16 § 9.2.8 specification.
[[ns_unblock_ack]]
==== NS-UNBLOCK-ACK
Receiving this message notifies OsmoPCU that NS-VC unblocking request
is confirmed and thus NS-VC is marked as unblocked. This message is
also sent as a reply to NS-UNBLOCK (<<ns_unblock>>) message.
The message conforms to 3GPP TS 08.16 § 9.2.9 specification.
[[ns_status]]
==== NS-STATUS
This message is sent to inform other party about error conditions as a
response to various unexpected PDUs or PDUs with unexpected/missing
data. If this message is received for unknown NS-VC it is ignored in
accordance with 3GPP TS 08.16 § 7.5.1, otherwise the error cause is
logged if present in NS-STATUS.
The message conforms to 3GPP TS 08.16 § 9.2.7 specification.
It contains Cause (<<ie_cause>>) and might (depending on actual error)
contain NSVCI (<<ie_nsvci>>), NS PDU (<<ie_nspdu>>) and BVCI
(<<ie_bvci>>) IEs.
[[ns_alive]]
==== NS-ALIVE
This message is sent periodically to test connectivity according to
3GPP TS 08.16 § 4.5.3. The expected response is NS-ALIVE-ACK
(<<ns_alive_ack>>). If no such response arrives within given amount of
time (3 seconds) than another NS-ALIVE message is sent and failed test
attempt is recorded. After 10 failed attempts NS connection is
considered dead and OsmoPCU tries to reconnect.
The message conforms to 3GPP TS 08.16 § 9.2.1 specification.
[[ns_alive_ack]]
==== NS-ALIVE-ACK
This message is sent automatically in reply to NS-ALIVE (<<ns_alive>>)
message.
The message conforms to 3GPP TS 08.16 § 9.2.2 specification.
=== Information Elements Overview
All of the IEs handled by OsmoPCU are listed below, with limitations and
additions to 3GPP TS 08.16 specified in more detail.
==== IEs Conforming to 3GPP TS 08.16
The following Information Elements are accepted by OsmoPCU.
.IEs conforming to 3GPP TS 08.16
[options="header",cols="5%,10%,40%,5%,40%"]
|===
| tag (hex) | TS 08.16 § | IE name | <-/-> | Received/Sent by OsmoPCU
| 0x00 | 10.3.2 | Cause | <-/-> | Received/Sent
| 0x01 | 10.3.5 | NSVCI | <-/-> | Received/Sent
| 0x02 | 10.3.3 | NS PDU | <-/-> | Received/Sent
| 0x03 | 10.3.1 | BVCI | <-/-> | Received/Sent
| 0x04 | 10.3.6 | NSEI | <-/-> | Received/Sent
|===
==== IEs Not Conforming to 3GPP TS 08.16
All IEs defined in 3GPP TS 08.16 § 10.3 are supported by OsmoPCU.
==== Additional Attributes and Parameters
There are no OsmoPCU specific additional Attributes and Parameters.
=== Details on IEs
[[ie_cause]]
==== Cause
This IE contains reason for a procedure or error as described in 3GPP TS 08.16 § 10.3.2.
[[ie_nsvci]]
==== NSVCI
This IE represents NSVCI identity described in <<ident>> and 3GPP TS 08.16 § 10.3.5.
[[ie_nspdu]]
==== NS PDU
This IE contains PDU (possibly truncated) which cause error described
in NS-STATUS message (<<ns_status>>) as described in 3GPP TS 08.16 §
10.3.3.
[[ie_nssdu]]
==== NS SDU
This IE contains BSSGP data - see <<bssgp>> for details.
[[ie_bvci]]
==== BVCI
This IE represents BSSGP identity described in <<ident>> and 3GPP TS 08.16
§ 10.3.1.
[[ie_nsei]]
==== NSEI
This IE represents NSEI identity described in <<ident>> and 3GPP TS 08.16 §
10.3.6.
[[ns_init]]
=== Gb NS Initialization / PCU bring-up
OsmoPCU binds and connects an UDP socket for NS using port numbers and IP
information given by OsmoBTS via the PCU socket. OsmoBTS in turn
receives this information from the BSC vi A-bis OML.
Following successful initialization of the UDP socket, the reset
procedure is initiated as described in <<ns_reset>>.
|
