Project

General

Profile

Feature #2840

HLR should allow 2g-only or 3g-only subscribers

Added by laforge 4 months ago. Updated 3 months ago.

Status:
New
Priority:
Normal
Assignee:
Start date:
01/18/2018
Due date:
% Done:

0%


Description

right now, any subscriber known to the HLR can use both 2G and 3G services. It would be useful to restrict this to either one of the two technologies for each subscriber individually, similar to the nam_cs / nam_ps that we already have.

History

#1 Updated by laforge 3 months ago

  • Assignee set to neels

#2 Updated by neels 3 months ago

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?

#3 Updated by laforge 3 months ago

On Mon, Feb 26, 2018 at 12:46:08AM +0000, neels [REDMINE] wrote:

IIRC it's not sufficient to supply auth vectors with the 2G or 3G auth tuples unpopulated,

No, clearly not. The authentication method has no say over the RAN technology.

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?

I would always look how MAP (TS 29.002) solves the problem and stay as close as possible to it.

Looking at TS 29.002 InsertSubscriberData, it seems that the AccessRestrictionData
is used for this purpose:

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.

So IMHO, GSUP should be extended to carry a variable-length bitmask (for future
extensions) containing access restriction data. We can use the same bit definitions
like MAP, for simplicity. This means the first bit (0x80) is utranNotAllowed,
0x40=geranNotAllowed, ...

Also available in: Atom PDF