osmo-ttcn3-hacks/deca656c1c36f179a0ad8c20a90...

313 lines
11 KiB
Plaintext

{
"comments": [
{
"key": {
"uuid": "351ac1cd_90c4eb88",
"filename": "bts/BTS_Tests.ttcn",
"patchSetId": 2
},
"lineNbr": 58,
"author": {
"id": 1000004
},
"writtenOn": "2018-09-26T17:42:13Z",
"side": 1,
"message": "tolerance doesn\u0027t make sense here. the MS power level is instructed by the BTS to the MS, and the MS must transmit at the ordered power level back in uplink. There is no measurement involved. It is a digital value that must match.",
"range": {
"startLine": 58,
"startChar": 9,
"endLine": 58,
"endChar": 36
},
"revId": "deca656c1c36f179a0ad8c20a900cd3981f20306",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326",
"unresolved": false
},
{
"key": {
"uuid": "f09443e4_7eef16f2",
"filename": "bts/BTS_Tests.ttcn",
"patchSetId": 2
},
"lineNbr": 58,
"author": {
"id": 1000074
},
"writtenOn": "2018-09-26T18:01:39Z",
"side": 1,
"message": "If I recall correctly, what I read is that the value should match only if the MS supports it, and if the MS doesn\u0027t support it, then it should take a lower one the closest to the announced max value. I\u0027ll cross-check that.\n\nI think I also saw at least once that the motorola phone announced a different power level (0?). I\u0027ll do some more tests and see how it behaves more in detail.",
"parentUuid": "351ac1cd_90c4eb88",
"range": {
"startLine": 58,
"startChar": 9,
"endLine": 58,
"endChar": 36
},
"revId": "deca656c1c36f179a0ad8c20a900cd3981f20306",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326",
"unresolved": false
},
{
"key": {
"uuid": "86d00269_0c12ca88",
"filename": "bts/BTS_Tests.ttcn",
"patchSetId": 2
},
"lineNbr": 58,
"author": {
"id": 1000074
},
"writtenOn": "2018-09-26T18:55:27Z",
"side": 1,
"message": "Yes, I get power level 0 sometimes (using mp_ms_power_level_exp\u003d7 and mp_tolerance_ms_power_level\u003d0):\n\n\"BTS_Tests.ttcn:1299 Matching on port RSL .ies[4].body.l1_info.ms_power_lvl :\u003d 0 with (7 .. 7) unmatched: First message in the queue does not match the template:\"",
"parentUuid": "f09443e4_7eef16f2",
"range": {
"startLine": 58,
"startChar": 9,
"endLine": 58,
"endChar": 36
},
"revId": "deca656c1c36f179a0ad8c20a900cd3981f20306",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326",
"unresolved": false
},
{
"key": {
"uuid": "5a1bd418_2c013764",
"filename": "bts/BTS_Tests.ttcn",
"patchSetId": 2
},
"lineNbr": 58,
"author": {
"id": 1000074
},
"writtenOn": "2018-09-26T18:58:29Z",
"side": 1,
"message": "And then later on (I check by running test with mp_ms_power_level_exp\u003d0 and mp_tolerance_ms_power_level\u003d0), it starts sending with power_lvl 7:\n\n\".ies[4].body.l1_info.ms_power_lvl :\u003d 7\"",
"parentUuid": "86d00269_0c12ca88",
"range": {
"startLine": 58,
"startChar": 9,
"endLine": 58,
"endChar": 36
},
"revId": "deca656c1c36f179a0ad8c20a900cd3981f20306",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326",
"unresolved": false
},
{
"key": {
"uuid": "24cf7d14_5aad1beb",
"filename": "bts/BTS_Tests.ttcn",
"patchSetId": 2
},
"lineNbr": 58,
"author": {
"id": 1000004
},
"writtenOn": "2018-09-26T19:59:14Z",
"side": 1,
"message": "Yes, it is correct that a MS that doesn\u0027t support the given power level will return a different (supported) one. However, the BTS/BSC will know the power capabilities of the phone, and we are testing with a known phone. So I\u0027m saying we know the setup well enough to not ever ask for a power level not supported by the device.",
"parentUuid": "f09443e4_7eef16f2",
"range": {
"startLine": 58,
"startChar": 9,
"endLine": 58,
"endChar": 36
},
"revId": "deca656c1c36f179a0ad8c20a900cd3981f20306",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326",
"unresolved": false
},
{
"key": {
"uuid": "baae8740_2f4b0bc4",
"filename": "bts/BTS_Tests.ttcn",
"patchSetId": 2
},
"lineNbr": 58,
"author": {
"id": 1000004
},
"writtenOn": "2018-09-26T19:59:14Z",
"side": 1,
"message": "is that sometimes in between, or is that only the first message ever sent by the phone? Maybe it\u0027s just the initial state that\u0027s somehow broken? Or the power control loop needs a few iterations until it arrives at the intended value? In this case we could simply exclude the first N messages from matching.",
"parentUuid": "86d00269_0c12ca88",
"range": {
"startLine": 58,
"startChar": 9,
"endLine": 58,
"endChar": 36
},
"revId": "deca656c1c36f179a0ad8c20a900cd3981f20306",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326",
"unresolved": false
},
{
"key": {
"uuid": "c9787d81_5cf10251",
"filename": "bts/BTS_Tests.ttcn",
"patchSetId": 2
},
"lineNbr": 60,
"author": {
"id": 1000004
},
"writtenOn": "2018-09-26T17:42:13Z",
"side": 1,
"message": "those two can be merged. As both the TA as well as the TOA256 are derived from the same timing measurement, there is only one source of determining timing distortion/error in the path. The 256syms value is of course 256 times the tolerance on the TA scale, which counts (if i remember correctly) in full symbols.",
"range": {
"startLine": 59,
"startChar": 9,
"endLine": 60,
"endChar": 43
},
"revId": "deca656c1c36f179a0ad8c20a900cd3981f20306",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326",
"unresolved": false
},
{
"key": {
"uuid": "702b59c1_376c31fd",
"filename": "bts/BTS_Tests.ttcn",
"patchSetId": 2
},
"lineNbr": 60,
"author": {
"id": 1000074
},
"writtenOn": "2018-09-26T18:01:39Z",
"side": 1,
"message": "From what I understand from your comment, then it doesn\u0027t matter which of the 2 values/variables we use since they have the same precision (despite one being in jumps of 256?). Or did I understand it incorrectly and the 256syms one has more precision?",
"parentUuid": "c9787d81_5cf10251",
"range": {
"startLine": 59,
"startChar": 9,
"endLine": 60,
"endChar": 43
},
"revId": "deca656c1c36f179a0ad8c20a900cd3981f20306",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326",
"unresolved": false
},
{
"key": {
"uuid": "860beeff_a0e5d3ea",
"filename": "bts/BTS_Tests.ttcn",
"patchSetId": 2
},
"lineNbr": 60,
"author": {
"id": 1000074
},
"writtenOn": "2018-09-26T19:13:22Z",
"side": 1,
"message": "Regarding this comment, now I understood that only the 2 tolerance ones are to be merged, not the expected values. However, my previous question still applies somehow: can the 256syms be non multiple of 256, ie. is it more precise? Then I should use that one and the ms_actual_ta is clamped from the 256syms one.",
"parentUuid": "702b59c1_376c31fd",
"range": {
"startLine": 59,
"startChar": 9,
"endLine": 60,
"endChar": 43
},
"revId": "deca656c1c36f179a0ad8c20a900cd3981f20306",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326",
"unresolved": false
},
{
"key": {
"uuid": "13893f5d_1f0c83da",
"filename": "bts/BTS_Tests.ttcn",
"patchSetId": 2
},
"lineNbr": 60,
"author": {
"id": 1000004
},
"writtenOn": "2018-09-26T19:59:14Z",
"side": 1,
"message": "the 256syms can of course be non-multiple of 256. But you can specify the tolerance in units of 1/256th (e.g. 512 for two symbols), and then you can compute the TA tolerance as 512/256\u003d2 and the toa256 tolerance is 512.",
"parentUuid": "860beeff_a0e5d3ea",
"range": {
"startLine": 59,
"startChar": 9,
"endLine": 60,
"endChar": 43
},
"revId": "deca656c1c36f179a0ad8c20a900cd3981f20306",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326",
"unresolved": false
},
{
"key": {
"uuid": "34ced462_4e2f0ed8",
"filename": "bts/BTS_Tests.ttcn",
"patchSetId": 2
},
"lineNbr": 62,
"author": {
"id": 1000004
},
"writtenOn": "2018-09-26T17:42:13Z",
"side": 1,
"message": "the expected power level must always match the instructed power level, otherwise the BTS or MS are broken in some way. Making this value configurable doesn\u0027t appear to make much sense, IMHO.",
"range": {
"startLine": 62,
"startChar": 9,
"endLine": 62,
"endChar": 30
},
"revId": "deca656c1c36f179a0ad8c20a900cd3981f20306",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326",
"unresolved": false
},
{
"key": {
"uuid": "90f437d2_fd3dbc38",
"filename": "bts/BTS_Tests.ttcn",
"patchSetId": 2
},
"lineNbr": 62,
"author": {
"id": 1000074
},
"writtenOn": "2018-09-26T18:01:39Z",
"side": 1,
"message": "As I said, I\u0027ll test it a bit more and come back with some descirption or change.",
"parentUuid": "34ced462_4e2f0ed8",
"range": {
"startLine": 62,
"startChar": 9,
"endLine": 62,
"endChar": 30
},
"revId": "deca656c1c36f179a0ad8c20a900cd3981f20306",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326",
"unresolved": false
},
{
"key": {
"uuid": "a5cf6890_85ea28e4",
"filename": "bts/BTS_Tests.ttcn",
"patchSetId": 2
},
"lineNbr": 62,
"author": {
"id": 1000004
},
"writtenOn": "2018-09-26T19:59:14Z",
"side": 1,
"message": "there is of course the power control loop, and we may have bugs in the power control loop implementation. Also, there are differences in how the different BTS models / PHY implementations handle this. The BSC may also instruct the BTS to bypass BTS-side power control loop, whihc AFAIK is broken / not implemented.\n\nI\u0027m not arguing that your observations / results are wrong. I\u0027m just arguing that somehow our code is broken / incomplete and we shouldn\u0027t adjust this by increasing the test tolerance, but by looking for the actual issue.",
"parentUuid": "90f437d2_fd3dbc38",
"range": {
"startLine": 62,
"startChar": 9,
"endLine": 62,
"endChar": 30
},
"revId": "deca656c1c36f179a0ad8c20a900cd3981f20306",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326",
"unresolved": false
}
]
}