Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-03-26T11:40:28ZOpen Source Mobile Communications
Redmine OsmoGGSN (former OpenGGSN) - Bug #6420 (New): osmo-ggsn + pre-configured tun device seems to be b...https://projects.osmocom.org/issues/64202024-03-26T11:40:28Zosmith
<p>When using a pre-configured tun device with OsmoGGSN as described in the user manual, in combination with <code>gtpu-mode kernel-gtp</code>, osmo-ggsn fails to configure the kernel GTP device:</p>
<pre>
<0002> ggsn.c:210 APN(internet): Skipping APN start
<000d> gsn.c:465 GTP: gtp_newgsn() started at 10.23.24.2
<000d> gsn.c:386 State information file (/tmp/gsn_restart) not found. Creating new file.
<0002> ggsn.c:854 GGSN(ggsn0): Successfully started
<0002> gtp-kernel.c:79 Initialized GTP kernel mode (genl ID is 34)
<0001> tun.c:213 cannot create GTP tunnel device: File exists
<0002> ggsn.c:215 APN(internet): Failed to configure Kernel GTP device
</pre> OsmoGGSN (former OpenGGSN) - Bug #6419 (New): osmo-ggsn removes tun devices it did not createhttps://projects.osmocom.org/issues/64192024-03-26T11:26:04Zosmith
<p>From the <a href="https://ftp.osmocom.org/docs/osmo-ggsn/master/osmoggsn-usermanual.pdf" class="external">user manual</a>:</p>
<blockquote>
<p>It’s possible to run OsmoGGSN without root privileges if the tun devices are already configured.<br />The interface creation + configuration must then happen before osmo-ggsn starting up.<br />[...]<br />With the tun device pre-configured in one of the ways outlined above, the main changes in your osmo-ggsn.cfg file are:<br />• remove ip ifconfig directive,<br />• make sure that no shutdown is present in the apn section as well as no shutdown ggsn in the ggsn section.</p>
</blockquote>
<p>With this configuration, a tun device created by <code>/etc/network/interfaces</code> will be removed when osmo-ggsn shuts down and <code>ifup -f apn0</code> must be used to recreate it, before starting osmo-ggsn again.</p> libosmocore - Feature #6402 (New): consider using IORING_RECVSEND_POLL_FIRST for our socket-readshttps://projects.osmocom.org/issues/64022024-03-14T08:21:57Zlaforge
<p>io_uring has an IORING_RECVSEND_POLL_FIRST which will increase the performance of read/recv/recvmsg/recvfrom calls if no data is present in the socket at the time we submit a read.</p>
<p>This works by going directly into poll, bypassing the initial attempt to recv/recvmsg.</p>
<p>Given that our sockets are often very low traffic and work in a request/response fashion, this might be worth a shot.</p> libosmocore - Feature #6401 (New): benchmark batching io_uring operationshttps://projects.osmocom.org/issues/64012024-03-14T08:10:59Zlaforge
<p>right now we <code>io_uring_submit()</code> reads/writes right when they are added. This triggers the kernel processing on those without the benefit of batching multiple operations.</p>
<p>We might want to try to benefit from batching by waiting until we enter osmo_select_main().</p> OsmoHNBGW - Feature #6395 (New): PFCP URR support in osmo-hnbgwhttps://projects.osmocom.org/issues/63952024-03-08T13:38:17Zlaforge
<p>Implement basic support for URR (Usage Reporting Rule).</p>
The goal here is to use PFCP URR to instruct the UPF to:
<ul>
<li>count the number of packets and bytes within each TEID (ul/dl separately)</li>
<li>periodically report those counters via PFCP to the control plane</li>
<li>report the final counters when the tunnel is closed</li>
</ul>
<p>The osmo-hnbgw side then will have to report those packet/byte counters [at the very least] as per-hnb aggregate figures.</p>
<p>Until osmo-upf has the related features (<a class="issue tracker-2 status-7 priority-1 priority-lowest" title="Feature: Basic URR (Usage Reporting Rule) support for tunnel mapping (Stalled)" href="https://projects.osmocom.org/issues/6394">#6394</a>), testing of the osmo-hnbgw side can be done against open5gs-upf, which should already suport it since <a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> taught it URR support in April 2022.</p> OsmoUPF - Feature #6394 (Stalled): Basic URR (Usage Reporting Rule) support for tunnel mappinghttps://projects.osmocom.org/issues/63942024-03-08T13:33:39Zlaforge
<p>Implement basic support for URR (Usage Reporting Rule).</p>
The goal here is to
<ul>
<li>count the number of packets and bytes within each TEID (ul/dl separately)</li>
<li>periodically report those counters via PFCP to the control plane</li>
<li>report the final counters when the tunnel is closed</li>
</ul>
<p><a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> had implemented something like this for open5gs-upf in<br /><pre>commit fb8ebcdbeae0648e30d04fd016a956642131dddd
Author: Pau Espin Pedrol <pespin@sysmocom.de>
Date: Fri Apr 8 16:10:42 2022 +0200
[UPF] Add initial support for URR Usage Report (#1476)
</pre><br />and following commits.</p>
<p>Now sadly, open5gs-upf is more like a lab-grade upf and nothing that scales at all, and we hence have users of osmo-upf that use it for its fast kernel path.</p>
<p>The primary goal for this feature is the <em>tunnel mapping</em> case in a osmo-hnbgw co-located osmo-upf. The packet and byte counters hence will have to be added to the nftables rules.</p> libosmocore - Feature #6390 (New): port CTRL over to osmo_io / io_uringhttps://projects.osmocom.org/issues/63902024-03-02T18:45:00Zlaforge
<p>In theory this should be fairly trivial to mogirate over. It uses a tx_queue anyway for writes today, so handing those msgb's over to osmo_io should be easy.</p>
<p>However, the user API of ctrl is a nightmare and it exposes a lot of internal details - among them are the use of ctrl_connection by a ctrl <strong>CLIENT</strong> from sysmobts_mgr.</p>
<p>Let's not do this now, the performance of CTRL is not that significant.</p> libosmocore - Feature #6389 (New): port VTY over to osmo_io / io_uringhttps://projects.osmocom.org/issues/63892024-03-02T16:55:56Zlaforge
<p>The VTY uses its 'buffer' layer between writes by the software and writing to the acutal socket file descriptor. buffer_flush_all is currently used whenever the socket is write-able. So it's a pull model.</p>
<p>We'd probably have to change that logic to work the other way around: Once a buffer has a certain fill-level (or age?), proactively push it via osmo_io.</p>
<p>Unless somebody uses a lot of scripts acccessing the VTY, it's also unlikely that the syscall load of a human VTY user would place significant I/O load on an osmocom program. So it's not super criticial.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6354 (New): investigate UE behavior in ...https://projects.osmocom.org/issues/63542024-02-07T16:10:55Zlaforge
<p>As we've seen in <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: connect a real phone to the epdg to test strongswan ipsec configuration (Closed)" href="https://projects.osmocom.org/issues/6114">#6114</a> it might be interesting to control the eDPG hostname so we can generate a certificate for it (signed by letsencrypt which presumably is trusted by default in unmodified android). It's not critical as EAP-only authentication appeared to be working in the test case there.</p>
<p>It would be good to find some time to test with a couple of different UE whether they actually respect the ePDG related files / configs that can be stored in the USIM/ISIM.</p>
<p>A quick look in TS 31.102 revaled:</p>
<ul>
<li><code>EF.ePDGId</code>
<ul>
<li>contains a TLV-wrapped IPv4, IPv6 or hostname of the ePDG</li>
</ul>
</li>
<li><code>EF.ePDGSelection</code>
<ul>
<li>control the <em>Selection of the ePDG</em> proceduer in the UE (3GPP TS 24.302)</li>
<li>contais a number of (plmn, epdg_priority, epdg_fqdn_indicator)
<ul>
<li>the epdg_fqdn_indicator state whether the <em>Operator Identifier FQDN</em>, or a <em>location based FQDN</em> format shall be used</li>
</ul></li>
</ul></li>
</ul>
<ul>
<li><code>EF.ePDGIdEm</code>
<ul>
<li>same as above, but for emergency calls</li>
</ul>
</li>
<li><code>EF.ePDGSelectionEm</code>
<ul>
<li>same as above, but for emergency calls.</li>
</ul></li>
</ul>
<p>So <code>EF.ePDGId</code> is really the most interesting one.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6345 (New): osmo-epdg: Implement SWm in...https://projects.osmocom.org/issues/63452024-01-25T16:32:08Zpespin
<p>In current architecture of osmo-epdg, the process contains both the ePDG and the AAA Server nodes.</p>
<p>These 2 nodes speak Diameter SWm interface between them.</p>
<p>We may want to split the 2 nodes into 2 processes and properly implement SWm at some point, or use another AAA server implementation.</p>
<p>Anyway, creating the ticket as a reference point to look up/comment on related communication between ePDG and AAA nodes.</p>
Spec references:
<ul>
<li>TS 29.273 section 7</li>
<li>TS 23.402 (grep for "SWm")</li>
</ul> pySim - Bug #6322 (New): ATR type annotationhttps://projects.osmocom.org/issues/63222024-01-03T21:55:30Zmerlinchlosta
<p>There's a small mixup in the ATR type annotations (<code>Hexstr</code> vs. <code>List[int]</code>) in <code>PcscSimLink</code>:</p>
<pre>
def get_atr(self) -> Hexstr:
return self._con.getATR()
</pre>
<p><code>pyscard</code> actually returns <code>List[int]</code> for an ATR. Depending code seems to convert using <code>i2h</code>.<br /><code>SerialSimLink</code> mimics the behavior (writing <code>self._atr</code> as <code>List[int]</code> in <code>_reset_card</code>).</p> OsmoMSC - Bug #6321 (New): SMS not delivered from corrupted SMS databasehttps://projects.osmocom.org/issues/63212024-01-02T13:07:31Zjolly
<p>When osmo-msc is started with corrupted "sms.db", no SMS is delivered.</p>
<p>Only the earliest SMS is delivered on a location update. All other SMS are not delivered until the next location update triggers the next earliest SMS delivery.</p>
<p>The problem was solved by removing the "sms.db" file and restarting osmo-msc. All queued SMS were delivered instantly. A newly queued SMS was delivered instantly.</p>
<p>To reproduce and debug the problem, I keept the corrupt database file. It is not included with this issue, because it may contain private information. Ask me for it. (/files/auftraege/sysmocom-MSC_SMS_BUG/sms.db_buggy)</p> pySim - Feature #6315 (New): have test data for all supported fileshttps://projects.osmocom.org/issues/63152023-12-23T09:33:25Zlaforge
<p>We long have the support for <code>_test_de_encode</code> and related class attributes specifiying per-file test data. This is still lacking for a number of files.</p>
<p>For some files it is easy to get real-world data, but for other files (specifically ADF.ISIM related, or mdoern DF.5GS) there simply are no real-world SIMs of production operators that would provide us with test data.</p>
<p>It might be worth looking at the UE/SIM conformance test specs, maybe those can help</p> pySim - Bug #6314 (New): pySim-trace doesn't support ARA-Mhttps://projects.osmocom.org/issues/63142023-12-23T09:31:02Zlaforge
<p>during execution of our pySim-shell test, even with the included pcap we're getting:</p>
<pre>
WARNING pySim.apdu.ts_102_221: SELECT UNKNOWN AID a00000015141434c00
</pre>
<p>the AID is that of the ARA-M applet. We do support ARA-M in pySim-shell. However, we do not appear to use that code from pySim-shell, probably related to the AID auto-detection missing.</p> OsmoPCU - Feature #6303 (New): Convert pcuif to TLV to make backwards compatibility more feasiblehttps://projects.osmocom.org/issues/63032023-12-12T16:07:01Zosmith
<p>In a meeting today with <a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> and <a class="user active" href="https://projects.osmocom.org/users/67">fixeria</a>, we figured it would be useful to have a TLV based PCUIF protocol so we could extend it in the future without always breaking backwards compatibility. If it was backwards compatible, we would not need to have osmo-pcu, osmo-bts and osmo-bsc all speak the exact same PCUIF version as it is currently the case.</p> OsmoHNBGW - Feature #6285 (New): IUFP needs not CRCX in loopback modehttps://projects.osmocom.org/issues/62852023-12-04T03:58:47Zneelsnhofmeyr@sysmocom.de
<p>doing CRCX in loopback mode was necessary for early 3G support in osmo-mgw.<br />We faked an IuUP Initialization ACK message using loopback and some header patching -- ugly.</p>
<p>osmo-mgw supports IuUP Initialization to work in any mode since I6c365559a7bd197349f0ea99f7a13b56a4bb580b.</p>
<p>osmo-msc has removed the loopback hack from its CRCX for IUFP in march 2023, and creates the initial IUFP conn in recvonly.<br />osmo-hnbgw should do the same.</p>
<p>Using loopback or not should be completely orthogonal to using IUFP or not.<br />So techincally, osmo-hnbgw is free to use loopback if it wants to.<br />But currently the only reason to use loopback was the IuUP hack -- with that gone, let's not keep a confusing RTP mode.</p> Cellular Network Infrastructure - Feature #6243 (New): vty cfg: make changing startup defaults of...https://projects.osmocom.org/issues/62432023-11-01T00:56:38Zneelsnhofmeyr@sysmocom.de
<p>Sometimes our recommendation of what the usual/good setting should be for a given vty config item changes.<br />Then we have the problem that we cannot change it without endangering running installations,<br />and/or creating hassle for admins.</p>
<p>So how about a general mechanism in all of our config files in form of a vty command, maybe like this:</p>
<p>osmo-foo.cfg:<br /><pre>
defaults (v0|v1.5|v1.6)
</pre></p>
<p>so a user can decide when to make the cfg upgrade, independently from binary upgrades.</p>
<p>When 'defaults' is not specified, we would have to assume like 'defaults v0'.<br />(A bit more convenient for new users would be to add the newest available 'defaults' setting automatically somehow,<br />but I guess that also breaks the entire feature then, unless someone can think of an elegant way.)</p> libosmo-sccp + libosmo-sigtran - Feature #6241 (New): M3UA "Network Appearance" supporthttps://projects.osmocom.org/issues/62412023-10-31T15:00:11Zlaforge
<p>M3UA has the notion of an (entirely optional) "Network Appearance" IE. We don't support it at all</p>
<p>The spec says:</p>
<blockquote>
<p><strong>Network Appearance</strong> - The Network Appearance is a M3UA local reference shared by SG and AS (typically an integer) that, together with an Signaling Point Code, uniquely identifies an SS7 node by indicating the specific SS7 network to which it belongs. It can be used to distinguish between signalling traffic associated with different networks being sent between the SG and the ASP over a common SCTP association. An example scenario is where an SG appears as an element in multiple separate national SS7 networks and the same Signaling Point Code value may be reused in different networks.</p>
</blockquote>
<p>Supporting this properly in libosmo-sigtran is likely non-trivial, as it means that everywhere where right now only the point code is considered, we need to consider point code + network appearance. This affects not only routing decisions, but it also affects things like peer addresses of SCCP connections.</p> OsmoSGSN - Bug #6176 (New): build failure (dependency / concurrency issue)https://projects.osmocom.org/issues/61762023-09-13T15:02:17Zlaforge
<p>when trying <code>make -j8 check</code> in current master (which is also 1.11.0):</p>
<pre>
...
Making check in src
make[4]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[2]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[5]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[5]: Nothing to be done for 'install-exec-am'.
make[5]: Nothing to be done for 'install-data-am'.
make[5]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[4]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
Making check in gprs
make[3]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[4]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[2]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include'
Making install in src
make[2]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[3]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
CC crc24.lo
CC gprs_llc_parse.lo
CC gprs_utils.lo
Making install in gprs
CC sgsn_ares.lo
make[3]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
CC gprs_llc_parse.lo
CC crc24.lo
CC gprs_utils.lo
CC sgsn_ares.lo
mv: cannot stat '.deps/crc24.Tpo': No such file or directory
make[3]: *** [Makefile:454: crc24.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
mv: cannot stat 'gprs_utils.loT': No such file or directory
mv: cannot stat '.deps/gprs_utils.Tpo': No such file or directory
make[3]: *** [Makefile:454: gprs_utils.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
make[2]: *** [Makefile:393: install-recursive] Error 1
make[2]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[1]: *** [Makefile:461: install-recursive] Error 1
make[1]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn'
make: *** [Makefile:765: install] Error 2
make: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
make[2]: *** [Makefile:393: check-recursive] Error 1
make[2]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[1]: *** [Makefile:461: check-recursive] Error 1
make[1]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn'
make: *** [Makefile:760: check] Error 2
</pre>
<p>doing that with <code>-j1</code> works, though.</p> OsmoBTS - Bug #5995 (New): osmo-bts printing log line 'OC=GPRS-NSE(f0) INST=(00,ff,ff): Tx unkno...https://projects.osmocom.org/issues/59952023-04-04T18:16:58Zpespin
<p>osmo-bts fails to log properly name string of NM_MT_IPACC_SET_ATTR_ACK in oml_mo_send_msg():</p>
<pre>
DEBUGPFOH(DOML, foh, "Tx %s\n", get_value_string(abis_nm_msgtype_names, foh->msg_type));
</pre>
<p>This is because IPACCESS specific messages (enum abis_nm_msgtype_ipacc) are not included in "abis_nm_msgtype_names".</p>
<p>We need to discuss whether we want them added to "abis_nm_msgtype_names" or have some way to also translate those.<br />The problem is that there can be other vendors providing other extensions which may reuse same enum values, such as enum abis_nm_msgtype_bs11.<br />So ideally we should add a function to first check abis_nm_msgtype_names() and if it fails (or within expected range for vendor-implementation) then translte from "enum abis_nm_msgtype_ipacc".</p> OsmoHNBGW - Feature #5816 (New): Picocells availiable in R.Uhttps://projects.osmocom.org/issues/58162022-12-07T03:42:28Zcopslock
<p>This topic is describing the info of femtocells in russia,as the local operaters seem started to retire these devices<br />For example,the MTS ePico3801<br /><img src="https://osmocom.org/attachments/download/5719/2650013279-1.png" alt="" /><br /><img src="https://osmocom.org/attachments/download/5720/2650013279-2.png" alt="" /><br /><img src="https://osmocom.org/attachments/download/5721/2650013279-3.png" alt="" /><br /><img src="https://osmocom.org/attachments/download/5722/2650013279-4.png" alt="" /></p> OsmoHNBGW - Feature #5813 (New): Alcatel-Lucent femtocells availiable in Europehttps://projects.osmocom.org/issues/58132022-12-06T18:21:43Zcopslock
<p>This is the topic that collecting the info and availability of the diverse Alcatel-Lucent femtocells<br /><img src="https://osmocom.org/attachments/download/5708/picture227-1.png" alt="" /><br /><img src="https://osmocom.org/attachments/download/5707/picture807-2.png" alt="" /></p>
<pre><code class="html syntaxhl">The Alcatel-Lucent 9362 Enterprise Cell (EC) V2.2 cost-effectively extends Wideband Code
Division Multiple Access (W-CDMA) coverage and high-speed packet access (HSPA) capacity
to businesses, delivering fast, responsive data service and crystal-clear voice. With scalable
capacity, the Alcatel-Lucent 9362 EC is just the right size for enterprises, whether they have
16, 24 or 32 users. Additionally, the Alcatel-Lucent 9362 EC has a unique capability to form
autonomous self-organizing groups of coverage, so medium to large enterprises, requiring many
access points, are as easy to cover as offices needing only a single 9362 Enterprise Cell.
FEATURES
• Small, lightweight device that may be
installed in a free-standing position or
mounted on a wall or ceiling
• Flexible coverage, supporting a maximum
transmit power of 100 mW or 250 mW
• Scalable capacity, which supports 16 users
with options to upgrade to 24 and 32 users
• Comes with Two integrated
omnidirectional antennas
• Receive (Rx) space diversity for improved
signal quality and greater capacity
• 64 QAM for higher throughput
• SON capabilities
• Secure outer casing – forced opening may
optionally disable the unit permanently
• Support for shared secret and certificatebased authentication
• Access control with support for open,
prioritized open, and closed modes
• Small cell net capability to form autonomous self-organizing groups of
extended coverage
• Handovers to and from the macro network
• Applications enablement with presence
API, network local routing and Internet
traffic breakout
• Complete status reporting with user
enabled/disabled bi-color LEDs
Protocols and interfaces
• Radio Access Network Application
Protocol (RANAP) on Iuh
• RANAP on Iu Prime
• Transmission and PoE+: Gigabit Ethernet
(GigE) connection (1000Base-T RJ45
connector)
• Local GigE connection to any other
device: 1000Base-T RJ45
Radio characteristics
• Operating band: 2100 MHz
• Listening bands
¬ 2100 MHz UMTS
¬ 900/1800 MHz GSM
• Rx diversity
• Capacity
¬ 16 active users
¬ Option to increase capacity in steps of
8 users, up to a maximum of 32 active
users, with the purchase of additional
licensing keys (with SW release BCR 3.0)
• Maximum bearers
¬ BCR 2.4.1
– 14.4 Mb/s HSDPA
– 2 Mb/s HSUPA
¬ BCR 3.0
– 21 Mb/s HSDPA (with 64 QAM
optional feature)
– 5.7 Mb/s HSUPA
• Maximum transmission power
¬ BCR 2.4.1
– Two orderable versions:
100 mW or 250 mW
¬ BCR 3.0
– 100 mW
– Option to increase transmission
power to 250 mW with the purchase
of additional licensing key
• Sensitivity: -107 dBm
</code></pre> OCTOI - Osmocom Community TDM over IP - Feature #5519 (New): reimplement overlapped.php based on ...https://projects.osmocom.org/issues/55192022-04-09T17:36:33Zlaforge
<p>I really don't like PHP and would like to replace the overlap dialling php script with something I can read, understand and maintain.</p>
<p>There are several python libraries implementing the yate messaging protocol for external modules around.</p> OsmoHNBGW - Bug #5304 (New): Verizon CDMA femtocellhttps://projects.osmocom.org/issues/53042021-11-10T15:32:33Zcopslock
<p>Verizon Samsung SCS-2U01 is a very famous target for many hackers,while as Harald said in 32C3,none of them even thought about running a local network upon it.Verizon is phasing out its CDMA network,it's time to play with these valuable blackbox<br /><img src="https://scache.vzw.com/content/dam/support/images/network_extender.png" alt="" /><br />It looks like the IS95 core network is a bit simpler than 3GPP network,however,there is no project about IS95 at all,Neither the data PDSN nor the IS95 MSC.</p> OsmoHNBGW - Bug #4933 (New): Femtocell choice in U.K 2021/01https://projects.osmocom.org/issues/49332021-01-03T13:55:43ZcopslockOsmoHNBGW - Feature #4882 (New): HSPA+ Picocell availiable in U.Shttps://projects.osmocom.org/issues/48822020-12-01T06:24:17Zcopslock
<p>The Ericsson RBS6402 WCDMA Picocell can be obtained from ebay recently at a very good price.It runs on Texas Instrument Keystone SoC,and have a good capacity compared to other femtocells<br /><img src="https://osmocom.org/attachments/download/4435/6402_page-0001.jpg" alt="" /><br /><img src="https://osmocom.org/attachments/download/4436/6402_page-0002.jpg" alt="" /><br /><pre>
Multi standard: WCDMA, LTE and Wi-Fi (optional)
● Up to 10 bands in three modules available:2-4 LTE/WCDMA bands per module
● 2 3GPP bands operate simultaneously and 1 Wi-Fi module operates in 2 bands
● LTE 2 Carrier Aggregation up to 300/50 Mbps DL/UL
● LTE 2 Carrier and LAA/LTE-U 5GHz unlicensed band
LTE: Carrier bandwidth 5,10 and 20 MHz
2x2 MIMO
WCDMA: 21/5.76 Mbps DL/UL, HW prepared for Dual Carrier 42 Mbps DL
RNC connected, Full mobility
Wi-Fi 2.4 GHz 802.11 b/g/n, 3x3 MIMO, 23 dBm (EIRP, 18 dBm per chain)
Wi-Fi 5 GHz: 802.11 a/n/ac, 3x3 MIMO, 23 dBm (EIRP, 18 dBm per chain)
RF Power 3GPP: Up to 2x250 mW per module (total 4x250 mW)
Antenna: Integrated omni-directional antennas for LTE/WCDMA and Wi-Fi
Support for external antennas for LTE/WCDMA
Typical coverage: 800 - 2 500 m² depending on building type
Active users: Up to 64 for WCDMA and up to 128 for LTE
TRANSMISSION^
Interfaces: 1 Gbps Electrical Ethernet, Optical as an option
SFP and transmission module options
Features Internet-grade Backhaul support, TWAMP
Security: IPsec for untrusted networks
Signed SW and secure O&M access for untrusted locations
Synchronization: GPS, NTP, IEEE 1588v
MECHANICAL SPECIFICATIONS
HxW xD: 280x167x62mm (excluding connector field)
Volume: 2.8 liters
Weight: 2.5 kg
Mounting: Flexible mounting on walls and ceilings
INTERFACE SPECIFICATIONS^
Power supply: Power over Ethernet line, Power over Ethernet injector or External AC/DC adapter
LED indication: Total 8 LED for 3GPP, Backhaul & Wi-Fi
GPS: Support for external GPS (optional)
ENVIRONMENTAL SPECIFICATIONS
Environment: ETSI 3.1, IP
Normal operating temp.: 0 - +50º C with fan, 0 - +40º C with passive cooling
OSS support: Integrated to OSS-RC/Ericsson Network Manager
</pre></p> OsmoHNBGW - Feature #4790 (New): Vodafone HSPA+ femtocell availiable in Deutschlandhttps://projects.osmocom.org/issues/47902020-10-09T08:35:38Zcopslock
<p>Seems like the Vodafone femtocell 3802V widely availiable on ebay sites recently,it's based on broadcom solution and runs on the Standard Iuh interface,better alternative choice than expensive Erricson smallcells<br /><img src="https://i.ebayimg.com/images/g/VVsAAOSwk25cfrfc/s-l1600.jpg" alt="" /><br /><img src="https://i.ebayimg.com/images/g/wskAAOSwpCFcfrfd/s-l1600.jpg" alt="" /></p> OsmoHNBGW - Feature #4574 (New): Femtocell choice in 2020/06https://projects.osmocom.org/issues/45742020-06-01T09:18:46Zcopslock
<p>Recently the AT&T had shutdown its UMTS femto system,thus,result in the Cisco femtocells that operated in their network are widely available on eBay or Amazon platform,it turned out to be the DPH-151/153/154 microcell,But as the Harald noticed,these units are communicated through the Cisco URSL protocal,which is the evolution of the current 2G RSL signaling,and possible someone can add UMTS patch to it.So far it's the best available femtocell rather than the ip.access one.<br /><img src="https://cdn.embedded.com/contenteetimes/images/edn/Teardowns/3GMicroCell/3G-MicroCell-PC-board_resized.jpg" alt="" /></p> libosmo-sccp + libosmo-sigtran - Feature #2006 (New): Implement M2PA supporthttps://projects.osmocom.org/issues/20062017-04-10T12:04:13Zlaforge
<p>M2PA is what is used e.g. by Cisco ITP, and I believe also by yate. So we could test SS7 routing/interop with those implementations if we had M2PA support.</p> OsmoSGSN - Feature #1585 (New): Gn interface for inter-SGSN MM Context transferhttps://projects.osmocom.org/issues/15852016-02-23T15:44:50Zlaforge
<p>Currently, we support mobility between multiple PCUs attached to one SGSN, but we don't support transfer of the MM context from one SGSN to another SGSN. The latter would require an implementation of the GTP-C based Gn interface.</p>