Question about establishing stable internet link between UE and HNB connected to our developed network core.
Hi, osmocom team members. In order to have an internet connection in UE, we have run OsmoGGSN project to set up GGSN. Also, SGSN is developed in our system. At this step, UE connects to our network core and we can query to an arbitrary site in the UE browser and we see the answer of the query without any problem and everything is OK. But after about 30 or 40 seconds, UE sends "Deactivate PDP Context Request" with SM Cause "SM Cause: Protocol error, unspecified (111)" and the connection is reset and a new "Activate PDP Context Request" is required. What is the reason and how can we solve it? -- *When there is much light, The shadow is deep...*
Hi, On Fri, Mar 26, 2021 at 07:49:37PM +0430, morteza ali Ahmadi wrote:
In order to have an internet connection in UE, we have run OsmoGGSN project to set up GGSN. Also, SGSN is developed in our system.
So you are seeing a problem between your custom, non open source SGSN and the UE, but you ask here on the Osmocom list for assistance? If I'm correct, then the following holds true: As we don't have access to your custom SGSN, only you can investigate and resolve that ;) -- - Harald Welte <laforge@osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Thanks, so can you tell us about the reason of this error? Is this error is related to "Activate PDP Context Accept" and its parameters or something else? On Friday, March 26, 2021, Harald Welte <laforge@osmocom.org> wrote:
Hi,
On Fri, Mar 26, 2021 at 07:49:37PM +0430, morteza ali Ahmadi wrote:
In order to have an internet connection in UE, we have run OsmoGGSN project to set up GGSN. Also, SGSN is developed in our system.
So you are seeing a problem between your custom, non open source SGSN and the UE, but you ask here on the Osmocom list for assistance? If I'm correct, then the following holds true: As we don't have access to your custom SGSN, only you can investigate and resolve that ;)
-- - Harald Welte <laforge@osmocom.org> http://laforge.gnumonks.org/ ============================================================ ================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
-- *When there is much light, The shadow is deep...*
Hi again, On Fri, Mar 26, 2021 at 11:31:31PM +0430, morteza ali Ahmadi wrote:
Thanks, so can you tell us about the reason of this error? Is this error is related to "Activate PDP Context Accept" and its parameters or something else?
how will the discussion of fixing problems that appear to happen between the UE and your proprietary SGSN be of benefit to the Osmocom developers and/or users? This list is about open source mobile communications. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
We asked this question here, because we set the content of "Create PDP Context Request" (from SGSN to GGSN) and "Activate PDP Context Accept" (from SGSN to HNB to UE) and "RAB-Assignment Request" (from SGSN to HNB) based on the generated packets in osmocom logs and the occured problem may be related to the parameters in these packets, specially "Activate PDP Context Accept". On Saturday, March 27, 2021, Harald Welte <laforge@gnumonks.org> wrote:
Hi again,
On Fri, Mar 26, 2021 at 11:31:31PM +0430, morteza ali Ahmadi wrote:
Thanks, so can you tell us about the reason of this error? Is this error is related to "Activate PDP Context Accept" and its parameters or something else?
how will the discussion of fixing problems that appear to happen between the UE and your proprietary SGSN be of benefit to the Osmocom developers and/or users? This list is about open source mobile communications.
-- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================ ================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
-- *When there is much light, The shadow is deep...*
Hi Morteza, This may be a silly question, but my most immediate and most natural reaction to your inquiry is a little different from Harald's. Harald's response focuses on the notion that FLOSS communities like Osmocom should not be helping proprietary software developers/users, but I see an even more fundamental question in need of answering: just *why* are you implementing your own SGSN, as opposed to using already existing OsmoSGSN+OsmoHNBGW? If you consider the existing Osmocom implementation to be poor and prefer to write your own alternative mostly from scratch (I am often guilty of the exact same behaviour: I just wrote from scratch my own suite of tools for programming SIM cards instead of improving Osmocom community's existing pySim tools), then why are you not releasing your own alternative version as Published Source Software? Perhaps I missed it, but I never saw you post a link to the source for your alternative SGSN. Just trying to understand, Mother Mychaela P.S. Published Source Software (PSS) is my preferred term for ALL software whose source code is freely published on the Internet by the authors or maintainers of the sw in question, regardless of whether it is under a free license or not - thus it is a more expansive category than FLOSS. FLOSS is a proper subset of PSS.
participants (4)
-
Harald Welte -
Harald Welte -
morteza ali Ahmadi -
Mychaela Falconia