https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092018-02-19T09:24:05ZOpen Source Mobile CommunicationsOsmoHLR - Feature #2840: HLR should allow 2g-only or 3g-only subscribershttps://projects.osmocom.org/issues/2840?journal_id=76812018-02-19T09:24:05Zlaforge
<ul><li><strong>Assignee</strong> set to <i>neels</i></li></ul> OsmoHLR - Feature #2840: HLR should allow 2g-only or 3g-only subscribershttps://projects.osmocom.org/issues/2840?journal_id=78422018-02-26T00:46:08Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>IIRC it's not sufficient to supply auth vectors with the 2G or 3G auth tuples unpopulated, since we might use the 3G-tuples on a UMTS capable 2G network. Does this issue hence call for extending the GSUP protocol to tell the HLR clients precisely whether attaching on a GERAN and UTRAN is allowed, respectively?</p> OsmoHLR - Feature #2840: HLR should allow 2g-only or 3g-only subscribershttps://projects.osmocom.org/issues/2840?journal_id=78482018-02-26T10:04:25Zlaforge
<ul></ul><p>On Mon, Feb 26, 2018 at 12:46:08AM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<p>IIRC it's not sufficient to supply auth vectors with the 2G or 3G auth tuples unpopulated,</p>
</blockquote>
<p>No, clearly not. The authentication method has no say over the RAN technology.</p>
<blockquote>
<p>Does this issue hence call for extending the GSUP protocol to tell the HLR clients precisely whether<br />attaching on a GERAN and UTRAN is allowed, respectively?</p>
</blockquote>
<p>I would always look how MAP (TS 29.002) solves the problem and stay as close as possible to it.</p>
<p>Looking at TS 29.002 InsertSubscriberData, it seems that the AccessRestrictionData<br />is used for this purpose:</p>
<pre>
AccessRestrictionData ::= BIT STRING {
utranNotAllowed (0),
geranNotAllowed (1),
ganNotAllowed (2),
i-hspa-evolutionNotAllowed (3),
wb-e-utranNotAllowed (4),
ho-toNon3GPP-AccessNotAllowed (5),
nb-iotNotAllowed (6),
enhancedCoverageNotAllowed (7) } (SIZE (2..8))
-- exception handling:
-- The VLR shall ignore the access restriction data related to an access type not
-- supported by the node.
-- The handling of the access restriction data by the SGSN is described in subclause
-- 5.3.19 of TS 23.060, in subclause 7.5.3 of TS 29.060 and subclause 7.3.6 of TS 29.274.
</pre>
<p>So IMHO, GSUP should be extended to carry a variable-length bitmask (for future<br />extensions) containing access restriction data. We can use the same bit definitions<br />like MAP, for simplicity. This means the first bit (0x80) is utranNotAllowed,<br />0x40=geranNotAllowed, ...</p> OsmoHLR - Feature #2840: HLR should allow 2g-only or 3g-only subscribershttps://projects.osmocom.org/issues/2840?journal_id=96572018-05-30T14:59:14Zlaforge
<ul><li><strong>Tags</strong> set to <i>3G</i></li></ul> OsmoHLR - Feature #2840: HLR should allow 2g-only or 3g-only subscribershttps://projects.osmocom.org/issues/2840?journal_id=100312018-06-23T18:59:51Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Low</i></li></ul> OsmoHLR - Feature #2840: HLR should allow 2g-only or 3g-only subscribershttps://projects.osmocom.org/issues/2840?journal_id=201872020-10-28T21:22:02Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>related: our ad-hoc patches used on 36c3 to switch off individual RAT types<br /><a class="external" href="https://git.osmocom.org/osmo-hlr/log/?h=36c3">https://git.osmocom.org/osmo-hlr/log/?h=36c3</a><br />in particular<br /><a class="external" href="https://git.osmocom.org/osmo-hlr/commit/?h=36c3&id=ce172efc0bfe25f6e0d473100bc8d4f68de6db42">https://git.osmocom.org/osmo-hlr/commit/?h=36c3&id=ce172efc0bfe25f6e0d473100bc8d4f68de6db42</a><br /><a class="external" href="https://git.osmocom.org/osmo-hlr/commit/?h=36c3&id=e6751dd207889e48f8a2608fe9064094d2928454">https://git.osmocom.org/osmo-hlr/commit/?h=36c3&id=e6751dd207889e48f8a2608fe9064094d2928454</a></p>