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, ...
