Denis Kenzior
2018-09-27 15:46:37 UTC
Hi Giacinto,
is only used for packet domain registrations in 2G/3G. +CREG is still
the definitive source of information, and in fact the registration state
is generally ignored by src/gprs.c if technology is set to E-UTRAN.
network-registration state overrides whatever status the gprs atom
thinks it is in.
Also, the driver is the wrong place for all this logic anyway. CEREG
and C5REG status reporting is standardized, so we can easily add this to
the oFono core (gprs) API. E.g. ofono_gprs_status_notify was for 2G/3G
PS domain registration state reporting (CGREG). We should now introduce
ofono_gprs_eutran_status_notify for reporting CEREG status and
ofono_gprs_5g_status_notify for C5REG. The core then can collate this
information and act accordingly. Having each driver doing all this
logic is wasteful and error prone.
to packet domain is separate in that case. It still applies to EUTRAN:
"an unsolicited result code +CREG: <stat> when <n>=1 and there is a
change in the MT’s circuit mode network registration status in
GERAN/UTRAN/E-UTRAN, or unsolicited result code
+CREG: <stat>[,[<lac>],[<ci>],[<AcT>]] when <n>=2 and there is a change
of the network cell in GERAN/UTRAN/E-UTRAN."
GPRS registration status is only important for one case, and that is
control of packet domain registration while roaming on 2G/3G networks.
On EUTRAN networks that is not possible anyway, so we're essentially
always Powered & Attached regardless of the RoamingAllowed setting.
-Denis
According to the 27.007 CGREG (both as URC and command) is no longer
sufficient to determine the registration state.
What does CGREG have to do with the overall registration state? CGREGsufficient to determine the registration state.
is only used for packet domain registrations in 2G/3G. +CREG is still
the definitive source of information, and in fact the registration state
is generally ignored by src/gprs.c if technology is set to E-UTRAN.
New indicators: CEREG for LTE, C5GREG for NR/5G are introduced.
In practice, legacy modems have CGREG, LTE-only modems have CEREG, and
several others have both.
With NR the picture will become even larger.
The handling of these indicators is not straighforward, because each
will report the status in its own access technology. So we might have
CGREG=4 but CEREG=1. Therefore they must be checked together.
Particularly troublesome is the case of the URC. In case of hand-over,
for example for a CSFB call, a common case is to have '+CEREG: 4'
followed by '+CGREG: 1'. The first URC must be discarded, and this is
done checking the technology reported by 'AT+COPS?' after the URC is
Err, why? We should get a proper status from +CREG. And theIn practice, legacy modems have CGREG, LTE-only modems have CEREG, and
several others have both.
With NR the picture will become even larger.
The handling of these indicators is not straighforward, because each
will report the status in its own access technology. So we might have
CGREG=4 but CEREG=1. Therefore they must be checked together.
Particularly troublesome is the case of the URC. In case of hand-over,
for example for a CSFB call, a common case is to have '+CEREG: 4'
followed by '+CGREG: 1'. The first URC must be discarded, and this is
done checking the technology reported by 'AT+COPS?' after the URC is
network-registration state overrides whatever status the gprs atom
thinks it is in.
Also, the driver is the wrong place for all this logic anyway. CEREG
and C5REG status reporting is standardized, so we can easily add this to
the oFono core (gprs) API. E.g. ofono_gprs_status_notify was for 2G/3G
PS domain registration state reporting (CGREG). We should now introduce
ofono_gprs_eutran_status_notify for reporting CEREG status and
ofono_gprs_5g_status_notify for C5REG. The core then can collate this
information and act accordingly. Having each driver doing all this
logic is wasteful and error prone.
add the check for other roaming states for NR once the first modems are
available). Note that according to the 27.007 CREG does not apply to PS
networks, so it cannot be reliably used.
It does not apply to Packet Switched 2G/3G networks. The registrationavailable). Note that according to the 27.007 CREG does not apply to PS
networks, so it cannot be reliably used.
to packet domain is separate in that case. It still applies to EUTRAN:
"an unsolicited result code +CREG: <stat> when <n>=1 and there is a
change in the MT’s circuit mode network registration status in
GERAN/UTRAN/E-UTRAN, or unsolicited result code
+CREG: <stat>[,[<lac>],[<ci>],[<AcT>]] when <n>=2 and there is a change
of the network cell in GERAN/UTRAN/E-UTRAN."
If COPS does not report a technology or reports the same technology,
we take the indicator.
This sounds unnecessary to me...we take the indicator.
Similar handling for AT+CGREG?, AT+CEREG?, AT+C5GREG? : we take the
best result.
An initial verification for the presence of any of these indicators is
required. Also how many of them are available is needed information.
So the real question is, why do you think you need all this anyway? Thebest result.
An initial verification for the presence of any of these indicators is
required. Also how many of them are available is needed information.
GPRS registration status is only important for one case, and that is
control of packet domain registration while roaming on 2G/3G networks.
On EUTRAN networks that is not possible anyway, so we're essentially
always Powered & Attached regardless of the RoamingAllowed setting.
---
drivers/atmodem/gprs.c | 420 +++++++++++++++++++++++++++++++++++------
1 file changed, 364 insertions(+), 56 deletions(-)
Regards,drivers/atmodem/gprs.c | 420 +++++++++++++++++++++++++++++++++++------
1 file changed, 364 insertions(+), 56 deletions(-)
-Denis