https://osmocom.org/https://osmocom.org/favicon.ico?16647414092017-10-11T01:08:02ZOpen Source Mobile CommunicationsOsmoPCU - Bug #2404: PAGING-PS doesn't use QoS parameters from BSSGPhttps://osmocom.org/issues/2404?journal_id=56762017-10-11T01:08:02Zlaforge
<ul><li><strong>Assignee</strong> set to <i>msuraev</i></li></ul> OsmoPCU - Bug #2404: PAGING-PS doesn't use QoS parameters from BSSGPhttps://osmocom.org/issues/2404?journal_id=79652018-03-01T23:16:04Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>msuraev</i> to <i>stsp</i></li></ul> OsmoPCU - Bug #2404: PAGING-PS doesn't use QoS parameters from BSSGPhttps://osmocom.org/issues/2404?journal_id=91932018-05-07T11:12:13Zstsp
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul> OsmoPCU - Bug #2404: PAGING-PS doesn't use QoS parameters from BSSGPhttps://osmocom.org/issues/2404?journal_id=91942018-05-07T11:14:11Zstsp
<ul></ul><p>I have started to work on this.<br />Currently trying to get a related ttcn3 test case working: <a class="external" href="https://gerrit.osmocom.org/#/c/8020/">https://gerrit.osmocom.org/#/c/8020/</a></p> OsmoPCU - Bug #2404: PAGING-PS doesn't use QoS parameters from BSSGPhttps://osmocom.org/issues/2404?journal_id=99522018-06-18T13:38:49Zstsp
<ul></ul><p>I am still trying to get the PCU paging test to work.</p>
<p>Currently I am stuck trying to decode messages received on the L1 port in PCU_Tests.ttcn.<br />My modified test is expecting an RR message of type PAGING REQUEST 1.</p>
<p>The following is received on the pcu_sock by osmo-bts-virtual:<br /><pre>
DPCU <0009> pcu_sock.c:480 Data request received: sapi=PCH arfcn=0 block=0 data=37 38 39 15 06 21 00 01 f4 27 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
</pre> <br />This is a PCU_IF_MSG_DATA_REQ message with SAPI PCU_IF_SAPI_PCH.<br />The first few bytes are partly based on the IMSI used by the test ("01234567"H) and identify the paging group.</p>
<p>This packet gets added to the paging queue:</p>
<pre>
DPAG <0005> paging.c:266 Add IMM.ASS to queue (group=9)
</pre>
<p>The corresponding message received by TTCN3 is:</p>
<pre>
14:30:04.172259 5 L1CTL_PortType.ttcn:212 dec_L1ctlDlMessageLV(): Decoded @L1CTL_Types.L1ctlDlMessageLV: {
len := 39,
msg := {
header := {
msg_type := L1CTL_DATA_IND (3),
flags := {
padding := '0000000'B,
f_done := false
},
padding := '0000'O
},
dl_info := {
chan_nr := {
u := {
ch0 := RSL_CHAN_NR_PCH_AGCH (18)
},
tn := 0
},
link_id := {
c := FACCH_SDCCH (0),
na := false,
prio := SAPI0_PRIO_NORMAL (0),
sapi := 0
},
arfcn := {
pcs := false,
arfcn := 871
},
frame_nr := 179740,
rx_level := 63,
snr := 63,
num_biterr := 0,
fire_crc := 0
},
payload := {
data_ind := {
payload := '1506210001F4272B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B'O
}
}
}
}
</pre>
<p>It looks as if the message received on TTCN3's L1 port is in fact a copy of the pcu-sock message, doesn't it?<br />The first 3 bytes (37 38 39) of the pcu-sock message are now represented as a header part, and the remainder is in the payload.</p>
<p>Is this expected? I would say it is it not, since pcu-sock messages are certainly not valid L1 messages.</p>
<p>At which step in the chain should the PCU socket message be translated into RR?</p> OsmoPCU - Bug #2404: PAGING-PS doesn't use QoS parameters from BSSGPhttps://osmocom.org/issues/2404?journal_id=99692018-06-21T10:43:12Zstsp
<ul></ul><p>Further investigation suggests that the payload is indeed correct (0x06 is the RR discriminator, 0x21 is the code for RR message PAGING TYPE1).</p>
<p>I have spotted one obvious problem in Titan's decoder: <a class="external" href="https://git.eclipse.org/r/#/c/124834/">https://git.eclipse.org/r/#/c/124834/</a></p>
<p>Without the above patch, the decoder will decode the payload 1506210001F4272B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B<br />if I strip the leading '15'. However, it decodes it to an RR message of type interSystemToUTRAN_HandoverCommand which is not what is expected.</p>
<p>With the above patch applied, the decoder won't decode the payload anymore either in full or with leading '15' stripped. I am still unsure why. Could there be a problem with assumptions about byte order?</p> OsmoPCU - Bug #2404: PAGING-PS doesn't use QoS parameters from BSSGPhttps://osmocom.org/issues/2404?journal_id=99702018-06-21T12:56:24Zstsp
<ul></ul><p>I have figured out the reason for the decoder problem. I am still unsure how to best fix it.</p>
<p>There is some disagreement about how the mobile identity in a type1 paging request should be coded.</p>
<p>3GPP TS 44.060 version 9.3.0 Release 9 page 334 says:</p>
<blockquote>
<p>Mobile Identity (variable length octet string) <br />This octet string is the representation of the Mobile Identity.<br />It shall provide the international mobile subscriber identity, IMSI.<br />The encoding of this octet string is the value part (starting with octet 3)<br />of the type 4 information element Mobile Identity defined in 3GPP TS 44.018.</p>
</blockquote>
<p>We are also told that the length of the octet string is given in a 4-bit field.</p>
<p>In our TTCN3 test suite, we have 3(!) distinct definitions for this structure:<br /><pre>
GSM_RR_Types.ttcn: type record MobileIdentityLV {
MobileL3_CommonIE_Types.ttcn:type record MobileIdentityLV
RLCMAC_CSN1_Types.ttcn: type record MobileIdentityLV {
</pre></p>
<p>GSM_RR_types:<br /><pre>
type record MobileIdentityLV {
uint8_t len,
MobileIdentity mi
} with { variant (len) "LENGTHTO(mi)" };
</pre></p>
<p>RLCMAC_CSN1_Types:<br /><pre>
type record MobileIdentityLV {
uint4_t len,
octetstring mobile_id
} with { variant (len) "LENGTHTO(mobile_id)" };
</pre></p>
<p>MobileL3_CommonIE_Types:<br /><pre>
type record MobileIdentityLV
{
LIN1 lengthIndicator,
MobileIdentityV mobileIdentityV
} with { variant (lengthIndicator) "LENGTHTO (mobileIdentityV)"};
</pre></p>
<p>The PCU_Tests.ttcn file imports two of these definitions (from GSM_RR_Types and RLCMAC_CSN1_Types).<br />It is unclear to me how the encoder/decoder will behave for this type.</p>
<p>However, even if this ambiguity was resolved, the PCU paging test still wouldn't work.<br />This is because paging requests sent by osmo-pcu use a TLV IE data type for coding the P-TIMSI.<br />The coding used conforms to "10.5.1.4 Mobile Identity" in 3GPP TS 24.008 version 8.6.0 Release 8.<br />(My impression is that this contradicts "9.1.22 Paging request type 1" in 3GPP TS 44.018 version 10.3.0 Release 10, which explicitly states that MobileIndentify1 was an LV, not a TLV.)</p>
<p>The information element written by osmo-pcu matches the MobileIdentityTLV data structure of our TTCN3 tests. Two such type definitions exist:<br /><pre>
GSM_RR_Types.ttcn: type record MobileIdentityTLV {
MobileL3_CommonIE_Types.ttcn:type record MobileIdentityTLV
</pre></p>
<p>GSM_RR_Types:<br /><pre>
type record MobileIdentityTLV {
uint8_t tag,
uint8_t len,
MobileIdentity mi
} with { variant (len) "LENGTHTO(mi)" };
</pre></p>
<p>MobileL3_CommonIE_Types:<br /><pre>
type record MobileIdentityTLV
{
BIT7 elementIdentifier,
BIT1 spare1,
MobileIdentityLV mobileIdentityLV
};
</pre></p>
<p>One way of getting the decoder to work is to change the type of the mobileIdentity1 field in the definition of PDU_RRM_PagingReq_Type1_NW_MS:</p>
<pre>
type record PDU_RRM_PagingReq_Type1_NW_MS
{
// L2 pseudo length is handled automatically by encoder/decoder
BIT8 messageType, // '00100001'B;
PageMode_V pageMode,
ChannelNeeded_V channelNeeded,
MobileIdentityLV mobileIdentity1,
MobileIdentityTLV mobileIdentity2 optional,
P1RestOctets p1RestOctets
} with { variant "TAG ( mobileIdentity2, elementIdentifier = '0010111'B )" }; //'17'O
</pre>
<p>With mobileIdentity1 changed to MobileIdentityTLV (and a similar change to a template which uses this type), the paging request is properly decoded:<br />(EDIT: Well, not entirely: The values shown in mobileIdentity1 still don't look right).</p>
<pre>
14:19:49.063407 mtc PCU_Tests.ttcn:215 dec_PDU_ML3_NW_MS_backtrack(): Stream before decoding: '06210001F02B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B'O
14:19:49.063476 mtc PCU_Tests.ttcn:215 dec_PDU_ML3_NW_MS_backtrack(): Decoded @MobileL3_Types.PDU_ML3_NW_MS: {
discriminator := '0110'B,
tiOrSkip := {
skipIndicator := '0000'B
},
msgs := {
rrm := {
pagingReq_Type1 := {
messageType := '00100001'B,
pageMode := {
pM := '00'B,
spare1_2 := '00'B
},
channelNeeded := {
channel1 := '00'B,
channel2 := '00'B
},
mobileIdentity1 := {
elementIdentifier := '0000001'B,
spare1 := '0'B,
mobileIdentityLV := {
lengthIndicator := 240,
mobileIdentityV := {
typeOfIdentity := '011'B,
oddEvenInd_identity := {
imei_sv := {
oddevenIndicator := '1'B,
digits := '2B2B2B2B2B2B2B2B'H,
fillerDigit := '0010'B
}
}
}
}
},
mobileIdentity2 := omit,
p1RestOctets := '2B2B2B2B2B2B2B2B'O ("++++++++")
}
}
}
}
</pre> OsmoPCU - Bug #2404: PAGING-PS doesn't use QoS parameters from BSSGPhttps://osmocom.org/issues/2404?journal_id=106282018-08-07T10:15:59Zstsp
<ul></ul><p>I still need to build a physical test setup for this issue.<br />I've been waiting for Neels to find time to help (since he has already built a similar setup) but he has been busy with more important tasks and is now on vacation.<br />Will poke again when he gets back.</p> OsmoPCU - Bug #2404: PAGING-PS doesn't use QoS parameters from BSSGPhttps://osmocom.org/issues/2404?journal_id=121032018-10-09T06:48:59Zstsp
<ul></ul><p>I have a suitable test setup now. I've been distracted by other work during the past few weeks, but will eventually get back to this.</p> OsmoPCU - Bug #2404: PAGING-PS doesn't use QoS parameters from BSSGPhttps://osmocom.org/issues/2404?journal_id=121252018-10-10T09:28:13Zstsp
<ul></ul><p>As a first step towards tearing this ball of hair apart, I suggest we rename one of the three definitions of MobileIdentityLV: <a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/11292">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/11292</a></p> OsmoPCU - Bug #2404: PAGING-PS doesn't use QoS parameters from BSSGPhttps://osmocom.org/issues/2404?journal_id=121782018-10-12T14:01:34Zstsp
<ul></ul><p>Having spent some more time working on this issue, I've got my paging test into a state where it passes. However, having done some further reading I am now quite sure that the test I am writing doesn't match the behaviour of actual networks.</p>
<p>Many details of how paging procedures work in circuit vs. packet switched situations still elude me.<br />It is hard for me to write a useful TTCN3 test which matches realistic expectations without investing a significant amount of time researching the specs.</p>
<p>Could someone help me with this?</p>
<p>Otherwise, I feel that I should punt on this task and leave it to someone else who can write basic but meaningful PCU paging tests first. Then I could go back to the original problem which this issue is actually about (encoding QoS parameters in PCU paging requests).</p> OsmoPCU - Bug #2404: PAGING-PS doesn't use QoS parameters from BSSGPhttps://osmocom.org/issues/2404?journal_id=121892018-10-15T11:31:39Zstsp
<ul></ul><p>There is now a basic paging test which is passing with osmo-pcu from current master: <a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/9374">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/9374</a></p> OsmoPCU - Bug #2404: PAGING-PS doesn't use QoS parameters from BSSGPhttps://osmocom.org/issues/2404?journal_id=125572018-11-12T11:48:27Zstsp
<ul></ul><p>This issue is waiting for the above paging test to be merged.</p> OsmoPCU - Bug #2404: PAGING-PS doesn't use QoS parameters from BSSGPhttps://osmocom.org/issues/2404?journal_id=149802019-06-25T23:35:15Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Feedback</i></li><li><strong>Assignee</strong> changed from <i>stsp</i> to <i>laforge</i></li></ul><p>above mentioned issue has been merged: adding a TC_paging test.<br />However, I cannot see any QoS being part of that test.<br />Setting to feedback to re-assign / reschedule urgency...</p> OsmoPCU - Bug #2404: PAGING-PS doesn't use QoS parameters from BSSGPhttps://osmocom.org/issues/2404?journal_id=159012019-09-10T11:54:21Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>osmith</i></li></ul>