Hello everybody,
I was trying to setup an OSMO-MSC with an Open5Gs-Corenetwork, so I can send SMS to different UEs. Unfortunately the OSMO-MSC does not connect to the MME of the Open5Gs-Core and I do not find any installation guide for this specific setup.
For your information: The Open5Gs-Core runs on a Laptop and I build the Software from source (4G and 5G components). The MSC should run on the same Laptop.
Therefore I would like to ask you, if you can tell me, which other components besides of the OSMO-MSC I possibly have to install and how I should configure this components and the components of the core.
Many thanks in advance!
Best regards
Lilly Hennig
So, we've been discussing IRL about the osmo-hnbgw implementation of
interacting with nftables from a separate thread.
The idea now is that a separate thread gets the results from nftables, caches
them and enqueues them, so that the main thread can update the hnbgw counters
in-sync. A second separate thread does nft add/del rule maintenance.
There is another complication, and I want to make sure we agree on the solution:
Problem: to delete a rule, I need to retrieve its 'handle' first.
With the amount of threading we want, this becomes a bit complex.
So. We 'add rule' and 'delete rule', as hNodeB attach and detach.
But, to be able to 'delete rule', we need to retrieve an id that nftables
assigned to this rule when it was added, the 'handle':
add rule inet osmo-hnbgw gtpu-ul ip saddr 1.2.3.4 counter comment "ul:1-2-3-4";
...
list table inet osmo-hnbgw
-->
table inet osmo-hnbgw {
chain gtpu-ul {
ip saddr 1.2.3.4 counter packets 5 bytes 100 comment "ul:1-2-3-4" # handle 23;
} ^^^^^^^^^
}
...
delete rule inet osmo-hnbgw gtpu-ul handle 23;
^^^^^^^^^
AFAICT I cannot set a handle right from the start. I can also not delete a rule
by just stating it again as it is, nor by using the 'comment' as a handle. nft
wants a 'handle', period. Does anyone know better?
Every time we read counters, osmo-hnbgw also retrieves the handles for each
rule, and correlates via the 'comment'. Similarly to counters, we can only get
all handles at once, via a complete table dump (possibly inefficient).
It works out fine in most practical cases. But the complex corner case is when
an hNodeB detaches quickly, before the counters had a chance to run and update
the hNodeB's state, including the handle.
In the current agreement on our implementation with two threads for nft, with
queues back to the main thread, it would go something like this, to avoid
races:
main() nft_maintenance_thread() nft_read_counters_thread()
| | |
|---add hNodeB-------->| |
|<--ok-----------------| |
X | |
|---del hNodeB-------->| |
| [rule handle unknown!] |
..|<--EAGAIN-------------| |
. | | |
. |---do counters--------------------------------->|
. | | [work]
. | | [work]
. | | [work]
. |<--update-counters-and-handles------------------|
. | | |
..|---del hNodeB-------->| |
| [delete rule] |
|<--done---------------| |
Simplifying a bit...
main() nft_maintenance_thread() nft_read_counters_thread()
| | |
|---add hNodeB-------->| |
|<--ok-----------------| |
X | |
[want: del hNodeB] | |
[rule handle unknown!] | |
[set some "del" flag] | |
. | | |
. |---do counters--------------------------------->|
. | | [work]
. | | [work]
. | | [work]
. |<--update-counters-and-handles------------------|
. | | |
[del flag!] | |
|---del hNodeB-------->| |
| [delete rule] |
|<--done---------------| |
I'm not liking very much the amount of complexity spawning here, but
this last approach is ok I guess, do you agree?
i.e. when the handle is not set yet, set a flag on the hNodeB,
and trigger the 'delete' the next time the counter thread reports back a handle
for the hNodeB.
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Siemensstr. 26a
* 10551 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hi all,
After the OsmoDevCon 2024, I have set up a repository containing the GSMTAPv3
WIP version: https://gitea.osmocom.org/peremen/gsmtapv3
There is a Redmine ticket for GSMTAPv3: https://osmocom.org/issues/6445
Currently only the global header structure and types/subtypes are defined, and
detailed explanation of what each data type stands for is still WIP. Also,
GSMTAPv3 will use T16L16V dynamic metadata instead of fixed metadata structure,
and the metadata definition is still in early stage.
Having a structure definition is the very begging, which will be followed by
additional works to actually use the new GSMTAPv3 format (APIs, Wireshark
dissector, ...). Any form of help will be much appreciated.
Best,
Shinjo
Dear mailing list,
as announced in https://osmocom.org/news/246, the rpm packages for
CentOS 8 / AlmaLinux 8 are unmaintained.
sysmocom is currently still ensuring that the rpm binary packages build
from the rpm spec files we have in our git repositories. But this is
also significant effort that we would rather spend elsewhere, and so we
are considering to stop providing rpm builds altogether and possibly
removing these spec files from our git repositories.
This affects the official Osmocom binary package repositories (nightly
and latest) for CentOS 8/AlmaLinux 8 and openSUSE Tumbleweed.
Stable versions of Osmocom programs are also in openSUSE's official
repositories and can be installed from there.
So, is anyone using the official Osmocom rpm repositories?
As OsmoDevCon is coming up this weekend, we can also discuss it there,
feel free to talk to me about it.
Best regards,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Siemensstr. 26a
* 10551 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Dear Osmocom developers,
In our project we have been using the gsmtap pseudo-header to store UMTS and LTE signalling traces in pcapng format. This is very efficient compared to our previous implementation based on DLT_USER, and thanks to the gsmtap dissector, it allows any *shark app to read our output file.
When looking for the proper type and sub_type for NR signalling traces, I discovered they are not yet part of the standard. I found several threads of discussion about this, from about 2017 onwards, and I understand it is a matter of time and resources if the version 3 of GSMTAP has not been released.
The most interesting feature I have read about is the ability to extend the header with a TLV approach. EARFCN, eNodeB-ID, PCI, are useful metadata we would like to add to our traces.
In an ideal world, I would like things to be put in motion so that a new version of GSMTAP could see the light. More humbly, I ask you what kind of help is needed. Are you waiting for a draft specification? Are all requirements well known?
I suppose that LTE and NR are not the main focus today for liboscmocore development, but there are many projects out there waiting for the GSMTAP format to be updated.
Thanks!
Mauro
Hi all,
we are currently having lots of discussions on (non-)blocking I/O. I'd like to
put these thoughts out there for that discussion, because there seems to be a
misunderstanding in terms.
Blocking never goes away, it is just reduced to other orders of magnitude.
Types of "blocking":
- blocking or non-blocking pipes: will writing to a file or socket stop the
program until the pipe is ready for writing? (basic "OS level" I/O)
- synchronous or asynchronous event handling: will the program stop until a
remote side has responded, or can the program handle other events in the
meantime? (one job queue, one worker == osmo_select_main())
- sequential or parallelized event handling: can events be handled
concurrently, or just one after the other?
(one or more job queues, more than one worker)
- concurrent access of resources: a given resource is not thread-safe, hence
one thread needs to wait for the other to release a resource lock.
(This is always present, the aim is to hit a sweet spot of least locking.)
In osmo programs I have worked on, we do the first two, but not the other two.
Asynchronous event handling is the bare minimum for a server program to be
functional. Non-blocking pipes is a common addition that is easy to do.
From then on we enter the world of parallelization, and things get very complex
very quickly. It is possible to cause more blocking than before. It is possible
to significantly increase the load, instead of improving.
I am familiar with parallelized non-blocking event handling and I/O, from
realtime audio+video+control hacking. We do not use any of these techniques in
osmo programs I have worked on -- for good reasons, I thought.
The spectrum, from most blocking to most non-blocking:
- single-threaded, single queue with async defer;
- task queue with multiple worker threads;
- scheduling based on fairness or urgency;
- map/reduce across a cloud, in a functional language.
We're almost all the way to the blocking end of the parallelization spectrum.
So far I thought that this was a conscious choice. Async-but-blocking is low
complexity, with large benefits in maintainability and stability.
Example:
If we have pending, say, 10 incoming packets on three different links, we
handle each packet one by one when it is its turn. If one subscriber's incoming
measurement report triggers longish handover calculations, any events like an
MGCP ACK or SCCP CC for some other subscribers will have to wait in line, even
though they might take a thousand fold less time to complete.
OsmoBSC works well in that fashion, even for hundreds of cells and multiple
MSC: compared to audio+video+control, CNI signalling has huge tolerances on
timing. This is why 3GPP separates control-plane from user-plane.
It is important to balance all of these aspects!
---
It was mentioned somewhere that our VTY is both asynchronous and non-blocking.
I do not agree at all and would like to explain, as an example of the above.
Our vty server is NOT asynchronous. When a VTY request comes in, the vty
function must directly vty_out() the response. We cannot defer the VTY response
asynchronously like any other protocol can (see example below).
Our VTY structures, and the program-specific internal state that VTY
manipulates and queries, are not thread-safe. The VTY server cannot be
parallelized as it is now.
A contrived example:
Let's say we wanted to query nft counters from a VTY command:
* read VTY command from user,
* do some nft command asynchronously,
* and print back the result when nft is done.
Naively, we could store the struct vty * somewhere, and exit the vty handling
function. When nft is done some time later, just vty_out() the result to that
struct vty * that we still have from earlier. But there are problems:
If the user closed the telnet session in the meantime, this struct vty * is
stale and the program will crash. We need a cancel mechanism to avoid that.
Also when a VTY command function is done, we directly transmit the next VTY
prompt. vty-test scripts (`expect`) won't function properly when more response
data arrives after the prompt is received; human users may be confused.
So our VTY server is *both* Synchronous and Blocking. It is not trivial to make
it async (like all of our other protocols are) and non-blocking (which we have
nowhere in osmo-cni yet).
---
These are the kinds of mechanisms I care about in our discussions:
- "blocking" on what time scale?
- tradeoff with code complexity and maintainability.
- tradeoff with code stability and determinism.
- tradeoff with system performance load due to additional management and caching.
One does not simply put things in threads.
There are very non-trivial aspects that *always* come with it,
one of them is super good, most of them are pretty bad.
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Siemensstr. 26a
* 10551 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Dera Team,
I am facing this error.
[root@ip-172-31-27-63 libosmo-sccp]# ./configure.ac
./configure.ac: line 1: dnl: command not found
./configure.ac: line 2: syntax error near unexpected token `[libosmo-sccp],'
./configure.ac: line 2: `AC_INIT([libosmo-sccp],'
[root@ip-172-31-27-63 libosmo-sccp]#
Kindly help here . Thanks .
Regards,
Sandeep Malik
Dear Osmocom community,
About a year ago I published this specification:
https://www.freecalypso.org/specs/tw-ts-001-v010001.txt
TW-TS-001 is a spec, written in 3GPP language style, for enhanced RTP
transport of FR and EFR codec frames in an IP-based GSM RAN. I got
OsmoBTS support for this RTP extension on branch falconia/rtp_traulike,
but I never submitted it to Gerrit for mainlining: when I mentioned it
in OsmoDevCall in 2023-06, the feedback from Harald was that the
extension would need to be somehow requested from the CN via signaling,
rather than manually switched on via OsmoBTS local vty. Since then I
have familiarized myself with 3GPP specs for AoIP user place (TS 48.103
and TS 26.102 it refers to), and I see the problem with my initial
"brute force" method: when 3GPP specs explicitly call for standard RTP
formats at the AoIP interface, intentional deviations from that standard
need to be negotiated/signaled in some clean manner.
So here is my new solution:
https://www.freecalypso.org/specs/tw-ts-001-v010100.txthttps://www.freecalypso.org/specs/tw-ts-002-v010100.txthttps://www.freecalypso.org/specs/tw-ts-003-v010001.txt
There are 3 new specs in the above set:
* The new version of TW-TS-001 clarifies some deficiencies in the
original, and refers to TW-TS-003 for how the enhanced RTP format is
to be invoked at the AoIP interface.
* TW-TS-002 is a new spec that does for HRv1 codec what TW-TS-001 does
for FRv1 and EFR. The enhanced RTP payload format here is an
extension of RFC 5993, which I named super-5993.
* TW-TS-003 is an extension to BSSMAP for communicating the use of
enhanced RTP payload formats between MSC and BSS.
I will now be preparing some patches for TW-TS-003 support - see you
in Gerrit code review soon. :-)
With love and greetings from Themyscira,
Mother Mychaela
Hello Osmocom community,
Would anyone here happen to have a capture of a TRAU-UL frame stream
from some historical E1 (or T1) BTS? And if no already existing UL
capture is available, if I found someone with access to such equipment
who would be willing to do a few tests for me, what would be the way
to make such capture? I mean raw Abis UL capture, *not* converted to
RTP or anything else, and because I don't have any T1/E1 hardware
currently, I am not really familiar with Osmocom tools for working with
such hw and what tap/trace/capture mechanisms are available.
And yes, I see on the wiki page for OsmoDevCon that some E1 BTS hw
will be present at the event - but my lack of an updated travel
document from USCIS still precludes me from traveling anywhere outside
of USA+Canada+Mexico territory. :(
M~
Hi all,
I'm making a talk about tips and tools for doing more effective Osmocom
related development.
Some ideas I have for it currently:
* how to build your own (deb, rpm) packages with OBS
* how to run CI stuff (like the checkpatch linter) locally
* running tcpdump over SSH and piping it into wireshark
* finding what regression caused a ttcn-3 failure systematically
Is there anything (within this list or other ideas) you would find
particularly interesting, or boring?
If you have a couple of tips or tools to share, and would like to
present them yourself: let me know as well, then we could turn this into
a quick lightning talk series with multiple presenters.
Best,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Siemensstr. 26a
* 10551 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Dear experts
We try to configure osmo-bsc / osmo-mgw to be able to communicate with ERICSSON MSC/MGW.
The UE is well registered but we don't know how to well configure bsc.
We have this config file osmo-bsc.cfg:
- 172.20.10.10 is a local BSC address to communicate to STP, MSC, MGW
osmo-bsc
mgw 0
local-ip 172.20.10.10
local-port 2427
remote-ip 172.20.10.10
remote-port 2727
reset-endpoint rtpbridge/*
We have on the BSC a local mgw, and here is the osmo-mgw.cfg file:
172.20.10.19 is another address on the BSC towards the osmo-bts-trx.
osmo-mgw
mgcp
domain mgw
bind ip 172.20.10.10
bind port 2727
rtp port-range 4002 16001
rtp bind-ip 172.20.10.19
rtp ip-probing
rtp ip-dscp 0
rtp keep-alive once
rtcp-omit
rtp-patch ssrc
rtp-patch timestamp
no rtp-patch rfc5993hr
sdp audio-payload send-ptime
sdp audio-payload send-name
number endpoints 512
osmux off
Sure we made errors and misunderstood.
During test call, we can see in the trace, a Call proceeding, then a BSSMAP Assignment Request followed by a BSSMAP Assignment Complete.
The problem is that the IP choosen as AoIP Transport Layer Address is the OAM address of the BSC (seen in In GSM A-I/F BSSMAP Assignment Complete trace section - UDP port 4004).
How to change this in order to set 172.20.10.10 as the AoIP Transport Layer Address ?
Many thanks in advance,
best regards
Jean-Marc
Hello,
How can I utilize the iCE40 E1 USB adapter to transition from E1 to IP in a
GSM network, connecting a physical Siemens BSC (which has a BTS
connected) to OsmoMSC?
Only the BTS and BSC are physical. I already have osmo-e1d installed.
Should I use osmo-e1d or dahdi version for this transition?
What would be the best approach to begin the process?
Regards,
Alina
Hi,
I am trying to setup a simple Network In The Box 2G network. I am only interested in CS capabilities (voice calls, SMS, USSD). I am currently running the following elements with the default configurations:
- osmo-bts-trx (connecting to osmo-trx-uhd driving a USRP B205mini-i)
- osmo-bsc
- osmo-msc
- osmo-hlr
- osmo-mgw
- osmo-stp
I built all the programs from source on Ubuntu 22.04. Everything is running locally on one machine.
Everything seems to function correctly at first, but I noticed that sometimes when I try to execute an USSD code or make a call, my Channel Requests are not being responded. I noticed when this happens, osmo-bts shows the following notice:
DPCU notice PCU socket not connected, dropping message (pcu_sock.c:1018)
As I understand from the documentation (https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_I…), this component is not required for circuit switched services as the ones I am requesting, so I do not understand why this is happening. I assume something in the configuration files is telling the BTS or some network element that the PS side of the network is active, but I haven't found anything related to PCU in any of configuration files.
While I'm here looking at the mailing list, I have been thinking about
asking about the following, and no need to delay it, I suppose -
Upcoming OsmoDevCon attendees may have noticed the proposed and
scheduled session on CSFB testing.
Well, since - and sort of because that session was accepted, (and also
an iPhone 6 that supports the band of an eNB I have at home dropped into
my possession) - I've been prompted to advance my knowledge and
understanding of issues, and the iPhone (6 at least) is now doing MO
CSFB perfectly, and I think I see what some other observed issues are about.
I'm still happy if there's interest to do the session of course,
although maybe some might question whether it is more productive to just
file tickets/issues and work them out the usual way.
This email is not to suggest in any way to cancel the session, but
rather to ask if maybe we might expand the scope.
I'm thinking for example also testing 2G data. The older basic 2G + GPRS
"chocolate bar" type phones I have don't work anymore, they used to.
(not sure what one might actually do with such a device and GPRS these
days, but that's not the point, right?)
Someone (vadim?) brought a 2G (was it a credit card?) terminal once to
devcon. Does it work? that kind of thing. So thinking about all this,
I'm asking the question of whether there is interest to have a kind of
events style setup during the conference. lynxis I think has a server
for that, or maybe it's only a VM?
I don't mean a distracting always-on setup, and I don't mean to put
emphasis on cellular projects. But if we did want to have something
multi RAT, available for anybody who might want to glance in that
direction (during a USSE for example), then some (small) amount of
logistics preparation is necessary, no?
Thanks.
k.
Hi all,
While working with open5gs + kamailio, one traditionally always needed two HSS:
* the open5gs one with its mongodb and nodejs hell
* the FHoSS one for the kamailio IMS core
For some time there's now PyHSS, which supports both EPS and IMS subscriptions, which
is of course nice. docker_open5gs meanwhile also has switched to using it as default.
The big problem is that it doesn't actually state which license it is
under, which makes it legally impossible to [re]distribute it, or to even make a fork
of the repository, as that would be a violation of copyright. At least German users
are abel to legally use it, as under German copyright law you don't need
a license from the copyright holder to use a program that you have obtained legally.
In order to automatize the steps described in the open5gs_docker to create
subscribers, I've just hacked up a small tool, see
https://gitea.osmocom.org/laforge/pyhss-tool/src/branch/master/pyhss-tool.py
Using that tool, it's as easy as
pyhss-tool.py subscriber-create --imsi 001011111111111 --msisdn 1111 --k 000102030405060708090a0b0c0d0e0f --opc 00000000000000000000000000000000
or
pyhss-tool.py subscriber-delete --imsi 001011111111111
to add/remove subscribers. You will still need to manually create the
internet and ims APNs via the REST interface; I'll probably also add
that capability to the tool.
Once it's a bit more tested, I also would like to contribute it
upstream, at least once that is possible. To do that I'd have to make a
pull request, and making that pull request requires me to create a fork,
which is a copyright violation. wtf.
If that legal situation has cleared up, it might be worth considering either adding
native GSUP support to PyHSS (so it can be used by osmo-{msc,sgsn}, or to have
a converter like osmo_gsup2dia (the inverse of the existing osmo_dia2gsup).
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Ace your NURS FPX 4000 assessments with our expert tutors! Get personalized, online assessment help for NURS FPX 4000 Assessment 1 to 4 and complete your BSN and MSN in one billing cycle. High-quality tutoring designed for success.
Introduction to NURS FPX 4000 Series Assessments
Embarking on the NURS FPX 4000 series can be a pivotal step in your nursing career. These assessments are crucial for understanding complex healthcare concepts, developing critical thinking, and applying knowledge practically. Whether you're tackling NURS FPX 4000 Assessment 1 or moving forward to NURS FPX 4000 Assessment 4, each step is an opportunity to excel and prove your competency in the nursing field.
Why Choose Our Services for Your Nursing Assessments?
Our online tutoring platform specializes in guiding nursing students through their BSN and MSN programs with ease and efficiency. If you aim to complete your nursing program within one billing cycle, our expert tutors are here to provide you with the support and resources you need. From NURS FPX 4000 Assessment 2 to the comprehensive NURS FPX 4000 Assessment 3, we cover all bases.
Personalized Tutoring Approach
We understand that each student has unique learning needs. That's why our tutoring service is personalized, focusing on the specific requirements of assessments like NURS FPX 4000 Assessment 4. Our approach ensures that you not only meet but exceed the expectations set by these rigorous assessments.
Expert Tutors at Your Service
Our team consists of experienced tutors who are not just experts in their field but are also intimately familiar with the structure and demands of the NURS FPX series. Whether you're looking for "Hire assessment help writer" or need someone to "Take my Assessment," our professionals are equipped to assist you in navigating through NURS FPX 4000 Assessment 1 and beyond.
Achieve Your Goals in One Billing Cycle
The journey to completing your BSN and MSN program is challenging but rewarding. With our focused tutoring for the NURS FPX 4000 series, including targeted help for NURS FPX 4000 Assessment 2 and NURS FPX 4000 Assessment 3, we make it possible to achieve your academic goals swiftly. Our strategy includes intensive review sessions, practical application exercises, and comprehensive support materials that prepare you for success.
Comprehensive Support for All Assessments
Understanding the depth of knowledge required for assessments like NURS FPX 4000 Assessment 4 is crucial. Our services offer detailed guidance for each assessment in the series, ensuring you're well-prepared for every challenge. From "Online assessment help" to "Write my assessment," we provide a range of services designed to support your academic journey.
Your Pathway to Success in Nursing
Choosing our tutoring services for your NURS FPX 4000 series assessments is more than just academic support; it's an investment in your future. With our expert guidance, personalized tutoring, and comprehensive resources, completing your BSN and MSN program in one billing cycle is within reach. Start your journey toward nursing excellence today and take the first step towards a successful career with confidence.
Don't let the challenges of NURS FPX 4000 assessments hold you back. Hire an assessment help writer today and unlock your potential in the nursing field. Contact us to learn more about how we can help you achieve your goals.
Excel in NURS FPX 4010 Assessments with Our Expert Online Tutoring
Dominate your NURS FPX 4010 assessments with our specialized tutoring services. From Assessment 1 to 4, we provide comprehensive support to complete your nursing program with top grades. Start your success story today!
Introduction to NURS FPX 4010 Series Assessments
The NURS FPX 4010 series represents a significant milestone in the journey of nursing students. It challenges students to apply their knowledge in real-world scenarios, enhancing their clinical reasoning and decision-making skills. Whether you're just starting with NURS FPX 4010 Assessment 1 or gearing up for NURS FPX 4010 Assessment 4, each assessment is a step closer to achieving your academic and professional goals in nursing.
Why Our Tutoring Services Are Essential for Your Success
Navigating through the NURS FPX 4010 series requires more than just hard work; it demands strategic study plans and insights from experienced professionals. Our tutoring services are designed to guide you through each assessment, including NURS FPX 4010 Assessment 2 and NURS FPX 4010 Assessment 3, ensuring you grasp the core concepts and apply them effectively.
Customized Learning for Maximum Impact
We believe in a personalized approach to learning, recognizing that each student has unique strengths and challenges. Our tutors tailor their teaching methods to suit your individual needs, focusing on areas that require additional attention, such as NURS FPX 4010 Assessment 4, to maximize your learning outcome.
Expert Tutors Ready to Assist You
Our team comprises seasoned nursing educators who excel in their respective fields. They bring a wealth of knowledge and practical experience, providing invaluable insights into successfully completing assessments like NURS FPX 4010 Assessment 1. With our experts, you're not just preparing for an exam; you're gearing up for a successful career in nursing.
Achieve Excellence in One Billing Cycle
Our goal is to help you complete your BSN and MSN programs efficiently, without compromising the depth of learning. By focusing on crucial assessments, including NURS FPX 4010 Assessment 2 and NURS FPX 4010 Assessment 3, we streamline your study process to ensure you're exam-ready in the shortest possible time.
Comprehensive Support Tailored to Your Needs
From "Write my assessment" to "Online assessment help," we offer a range of services to support your academic journey. Our comprehensive tutoring package includes review sessions, practice questions, and personalized feedback, covering every aspect of the NURS FPX 4010 Assessment 4 and beyond.
Your Partner in Nursing Education
Choosing our tutoring services for the NURS FPX 4010 series is a step towards academic excellence and professional mastery. With our personalized support, expert guidance, and comprehensive resources, you'll be well-equipped to tackle each assessment with confidence and achieve your goals in the competitive field of nursing.
Elevate your nursing education with our expert tutors. Contact us now to learn how we can help you excel in the NURS FPX 4010 series and advance your career with confidence.
Excel in NURS FPX 4010 Assessments with Our Expert Online Tutoring
Dominate your NURS FPX 4010 assessments with our specialized tutoring services. From Assessment 1 to 4, we provide comprehensive support to complete your nursing program with top grades. Start your success story today!
Introduction to NURS FPX 4010 Series Assessments
The NURS FPX 4010 series represents a significant milestone in the journey of nursing students. It challenges students to apply their knowledge in real-world scenarios, enhancing their clinical reasoning and decision-making skills. Whether you're just starting with NURS FPX 4010 Assessment 1 or gearing up for <a href=https://www.etutors.us/assessment-4-stakeholder-presentation/> NURS FPX 4010 Assessment 4</a>. , each assessment is a step closer to achieving your academic and professional goals in nursing.
Why Our Tutoring Services Are Essential for Your Success
Navigating through the NURS FPX 4010 series requires more than just hard work; it demands strategic study plans and insights from experienced professionals. Our tutoring services are designed to guide you through each assessment, including NURS FPX 4010 Assessment 2 and for <a href=https://www.etutors.us/nurs-fpx4010-assessment-3/>NURS FPX 4010 Assessment 3</a>. , ensuring you grasp the core concepts and apply them effectively.
Customized Learning for Maximum Impact
We believe in a personalized approach to learning, recognizing that each student has unique strengths and challenges. Our tutors tailor their teaching methods to suit your individual needs, focusing on areas that require additional attention, such as NURS FPX 4010 Assessment 4, to maximize your learning outcome.
Expert Tutors Ready to Assist You
Our team comprises seasoned nursing educators who excel in their respective fields. They bring a wealth of knowledge and practical experience, providing invaluable insights into successfully completing assessments like <a href=https://www.etutors.us/nurs-fpx4010-assessment-1-collaboration/>NURS FPX 4010</a>. . With our experts, you're not just preparing for an exam; you're gearing up for a successful career in nursing.
Achieve Excellence in One Billing Cycle
Our goal is to help you complete your BSN and MSN programs efficiently, without compromising the depth of learning. By focusing on crucial assessments, including <a href=https://www.etutors.us/nurs-fpx-4010-assessment-2//>NURS FPX 4010 Assessment 2</a>. and NURS FPX 4010 Assessment 3, we streamline your study process to ensure you're exam-ready in the shortest possible time.
Comprehensive Support Tailored to Your Needs
From "Write my assessment" to "Online assessment help," we offer a range of services to support your academic journey. Our comprehensive tutoring package includes review sessions, practice questions, and personalized feedback, covering every aspect of the NURS FPX 4010 Assessment 4 and beyond.
<a href=https://www.etutors.us/nurs-fpx-4010/>Partner in Nursing Education</a>.
Choosing our tutoring services for the NURS FPX 4010 series is a step towards academic excellence and professional mastery. With our personalized support, expert guidance, and comprehensive resources, you'll be well-equipped to tackle each assessment with confidence and achieve your goals in the competitive field of nursing.
Elevate your nursing education with our expert tutors. Contact us now to learn how we can help you excel in the NURS FPX 4010 series and advance your career with confidence.
Excel in NURS FPX 4010 Assessments with Our Expert Online Tutoring
Dominate your NURS FPX 4010 assessments with our specialized tutoring services. From Assessment 1 to 4, we provide comprehensive support to complete your nursing program with top grades. Start your success story today!
Introduction to NURS FPX 4010 Series Assessments
The NURS FPX 4010 series represents a significant milestone in the journey of nursing students. It challenges students to apply their knowledge in real-world scenarios, enhancing their clinical reasoning and decision-making skills. Whether you're just starting with NURS FPX 4010 Assessment 1 or gearing up for <a href=https://www.etutors.us/assessment-4-stakeholder-presentation/> NURS FPX 4010 Assessment 4</a>. , each assessment is a step closer to achieving your academic and professional goals in nursing.
Why Our Tutoring Services Are Essential for Your Success
Navigating through the NURS FPX 4010 series requires more than just hard work; it demands strategic study plans and insights from experienced professionals. Our tutoring services are designed to guide you through each assessment, including NURS FPX 4010 Assessment 2 and for <a href=https://www.etutors.us/nurs-fpx4010-assessment-3/>NURS FPX 4010 Assessment 3</a>. , ensuring you grasp the core concepts and apply them effectively.
Customized Learning for Maximum Impact
We believe in a personalized approach to learning, recognizing that each student has unique strengths and challenges. Our tutors tailor their teaching methods to suit your individual needs, focusing on areas that require additional attention, such as NURS FPX 4010 Assessment 4, to maximize your learning outcome.
Expert Tutors Ready to Assist You
Our team comprises seasoned nursing educators who excel in their respective fields. They bring a wealth of knowledge and practical experience, providing invaluable insights into successfully completing assessments like <a href=https://www.etutors.us/nurs-fpx4010-assessment-1-collaboration/>NURS FPX 4010</a>. . With our experts, you're not just preparing for an exam; you're gearing up for a successful career in nursing.
Achieve Excellence in One Billing Cycle
Our goal is to help you complete your BSN and MSN programs efficiently, without compromising the depth of learning. By focusing on crucial assessments, including <a href=https://www.etutors.us/nurs-fpx-4010-assessment-2//>NURS FPX 4010 Assessment 2</a>. and NURS FPX 4010 Assessment 3, we streamline your study process to ensure you're exam-ready in the shortest possible time.
Comprehensive Support Tailored to Your Needs
From "Write my assessment" to "Online assessment help," we offer a range of services to support your academic journey. Our comprehensive tutoring package includes review sessions, practice questions, and personalized feedback, covering every aspect of the NURS FPX 4010 Assessment 4 and beyond.
<a href=https://www.etutors.us/nurs-fpx-4010/>Partner in Nursing Education</a>.
Choosing our tutoring services for the NURS FPX 4010 series is a step towards academic excellence and professional mastery. With our personalized support, expert guidance, and comprehensive resources, you'll be well-equipped to tackle each assessment with confidence and achieve your goals in the competitive field of nursing.
Elevate your nursing education with our expert tutors. Contact us now to learn how we can help you excel in the NURS FPX 4010 series and advance your career with confidence.
Hi
Many thanks Harald for you answer
Yes, Ericsson SGSN MKX uses Classic mode (not ip-sns), and the osmo-pcu is configured with this line: gb-dialect classic.
We took the time to check the SGSN, BSC & network configuration and all seems well configured.
We continue to check and test but no way for now to correct this NS initialization step, and this error: NS_STATUS, Cause PROTOCOL ERROR - unspecified.
So, if you have other ideas of what could be the problem, you're welcome.
In addition, if you know someone who had set up this configuration, we would be very interested by he way of BSC and BTS, SGSN were configured.
Best regards
Jean-Marc
Orange Restricted
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
Dear experts,
We are trying to connect an osmocom platform to an Ericsson platform, and are trying to make funtional 2G.
We use a VM for OSMO-BSC, a VM for OSMO-BTS-TRX + OSMO-PCU, and a Raspberry PI (trx-lms)
Concerning the Gb, we connected the OSMO-PCU to an MKX Ericsson, and we have an error at the NS setup step.
The communication between the SGSN Ericsson and the OSMO-PCU seems ok (IP / routing OK)
We hope that the Ericsson MKX SGSN is well configured.
We can see some packets: OSMO-PCU ---> SGSN : NS_RESET, Cause: P&M intervention, NS VCI: 0x1388, NSEI: 5000
and a response from the SGSN: NS_STATUS, Cause PROTOCOL ERROR - unspecified.
What could be the problem ? timers ? ns-vci, nsvc 1, encapsulation,...
Did someone test this: OSMOCOM with an ERICSSON SGSN ?
One point is that the nsvci is only defined on the BSC (not on the SGSN)
Many thanks in advance,
Best regards
Hoping that you could help us
Jean-Marc
-----------------------
BSC CONFIGURATION
-----------------------
bts 0
type osmo-bts
description LimeSDR Based BTS
band GSM900
cell_identity 41023
location_area_code 390
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
radio-link-timeout 32
channel allocator mode chan-req ascending
channel allocator mode assignment ascending
channel allocator mode handover ascending
channel allocator mode vgcs-vbs ascending
rach tx integer 9
rach max transmission 7
rach max-delay 63
channel-description attach 1
channel-description bs-pa-mfrms 5
channel-description bs-ag-blks-res 1
no nch-position
no access-control-class-ramping
early-classmark-sending forbidden
early-classmark-sending-3g allowed
ipa unit-id 901 0
oml ipa stream-id 255 line 0
neighbor-list mode automatic
codec-support fr
gprs ns timer tns-block 3
gprs ns timer tns-block-retries 3
gprs ns timer tns-reset 3
gprs ns timer tns-reset-retries 3
gprs ns timer tns-test 30
gprs ns timer tns-alive 3
gprs ns timer tns-alive-retries 10
gprs nsei 5000
gprs nsvc 0 nsvci 5000
gprs nsvc 0 local udp port 23001
gprs nsvc 0 remote ip 172.20.168.220
gprs nsvc 0 remote udp port 2157
...
-----------------------
PCU CONFIGURATION
-----------------------
ns
timer tns-block 3
timer tns-block-retries 3
timer tns-reset 3
timer tns-reset-retries 3
timer tns-test 30
timer tns-alive 3
timer tns-alive-retries 10
timer tsns-prov 3
timer tsns-size-retries 3
timer tsns-config-retries 3
timer tsns-procedures-retries 3
pcu
flow-control-interval 10
cs 2
cs max 4
cs threshold 10 33
cs downgrade-threshold 200
cs link-quality-ranges cs1 6 cs2 5 8 cs3 7 13 cs4 12
mcs link-quality-ranges mcs1 6 mcs2 5 8 mcs3 7 13 mcs4 12 15 mcs5 14 17 mcs6 16 18 mcs7 17 20 mcs8 19 24 mcs9 23
mcs max 9
window-size 64 0
queue idle-ack-delay 10
queue codel
Hi all,
Just wanted to share an issue and a quick workaround I found for it in case
anyone else has the same problem. I believe a cmd2 update is causing
pySim-shell to fail. After installing it on a fresh install of Ubuntu
Server 20.04 and getting the following error when I run "python3
pySim-shell -p0":
>Using PC/SC reader interface
>Autodetected card type: sysmoUSIM-SJS1
>AIDs on card:
> USIM: a0000000871002ffffffff8907090000
>Traceback (most recent call last):
> File "pySim-shell.py", line 512, in <module>
> app = PysimApp(card, rs, opts.script)
> File "pySim-shell.py", line 59, in __init__
> super().__init__(persistent_history_file='~/.pysim_shell_history',
allow_cli_args=False, use_ipython=True, auto_load_commands=False,
command_sets=basic_commands, >startup_script=script)
>TypeError: __init__() got an unexpected keyword argument 'use_ipython'
If you run into this you can fix it by uninstalling cmd2 and reinstalling
cmd2 with "pip3 install cmd2==1.5".
Best,
Bryan
Hello everyone,
Could any of you please review the merge request "GSMTAP: check version field" [1]?
The purpose is to check the content of the 'version' field in gsmtap header and act in case of unknown versions.
Cheers,
Mauro
[1] https://gitlab.com/wireshark/wireshark/-/merge_requests/14623
Dear osmocom developpers,
This is just to let you know that the Python library pycrate has a new home
: https://github.com/pycrate-org/pycrate. The packages on Pypi are now
feeded from there. This library can be used in many cases dealing with
mobile signalling.
I wanted to let you know, as even if I am not aware of any osmocom projects
depending on it, some of you may use the library from time to time, or
could have local applications depending on it.
Best Regards
Benoit
Hi all,
I'm currently working on 2G to 3G TrFO voice negotiation. In practice, that
means, to be able to negotiate a set of AMR rates via SDP. And that, in turn,
means that we handle fmtp properly in SDP strings.
SDP is not only used in SIP to the other call leg, but also in the MGCP to the
media gateway.
- So we have a bunch of SDP and fmtp related code in osmo-mgw.git.
- Separately, we have an SDP implementation in osmo-msc.git, because the SDP
code in osmo-mgw.git was too tightly coupled with other code to be able to
reuse it for MNCC->SIP.
For fmtp negotiation, I now want similar things in both mgw and msc.
What I want to do now, is move the SDP implementation from osmo-msc.git to
osmo-mgw.git/libosmo-mgcp-client and make it public API: a common place that
will also enable all other MGCP clients to work with AMR fmtp.
All of this was just the intro =) the question I would like to put out there is
about API design: static or dynamic, and opaque or transparent.
Am I overthinking this? Or would you like to overthink it with me?
== static or dynamic ==
In osmo-msc.git, the SDP structs so far are fully static and self-contained.
The cool thing is that they can be copied around quite easily and there is no
need for passing talloc ctx pointers, no need to worry about ownership,
memleaks and double frees. But it also means that it uses fixed sizes:
- char encoding_name[16],
- char fmtp[256],
- struct sdp_audio_codec codecs[32]
and so on.
Unfortunately, RFC-8866 does not define any limits whatsoever on number of
characters or number of codecs in an SDP message. Quoting:
"although no length limit is given, it is recommended that they be short"
Thanks for nothing! >:(
So for static API design, we need to now pick a good size for every single item
in advance.
When fmtp has max 256 bytes and codec lists have max 32 entries, even an empty
list will use 32 * 256+ bytes: lots of heap allocations.
And the limits are hard: anyone wanting to correctly express more than 32
different codec variants can simply not use this library.
Dynamic seems a much better fit for RFC-8866.
There is practically no limit at all on string length / list length.
Also the caller allocates not one byte more memory than is actually needed.
The argument has been going back and forth in my head for weeks. Static makes
things so much simpler. But what sizes should we dictate. Ok then dynamic. But
these days we have "infinite" memory, the bottleneck is CPU time, so if we can
be static, we are gracious on very cheap real estate (memory) while saving a
lot of the precious stuff (cycles). Ok then static. But with all those AMR
variants that are coming up, I want to at least be able to represent all of
them in one list, so I need at least 64 entries. And let's allow long fmtp
strings, who knows. Then we'll end up with ~20kb of data that every codec list
out there will use up, even if it is empty. Even if it is just a temporary
local variable. Even if it is just dragged along for a rare use case and never
actually needed. Is it really faster to allocate 100 times more memory
statically versus allocating just enough but dynamically?
In the end I decided for dynamic allocation.
When I started adding talloc ctx args, I wanted the API to be simple, so every
single part of the puzzle is now its own dynamic allocation:
struct osmo_sdp_msg {
char *username; // talloc_strdup()
char *session_name; // talloc_strdup()
[...]
struct osmo_sdp_codec_list *codecs; // osmo_sdp_codec_list_alloc()
// llist_head
// -> osmo_sdp_codec_alloc()
// \___ char *encoding_name -> talloc_strdup()
// _ char *fmtp -> talloc_strdup()
// -next-> osmo_sdp_codec_alloc()
// \___ ...
// -next-> osmo_sdp_codec_alloc()
// \___ ...
};
All of this used to be just a single self-contained struct.
You might ask, why is 'codecs', which is just the llist_head, a separate
allocation? Because I want the API to trivially figure out the talloc parent
context to allocate items from:
osmo_codec_list_add(my_list, my_codec);
and not have to worry about the individual code paths' parent context to
allocate new entries from:
osmo_codec_list_add(&my_obj->my_list, my_obj->backpointer.backpointer.ctx, my_codec);
So the only functions with a talloc ctx argument are
osmo_codec_alloc(ctx) and
osmo_codec_list_alloc(ctx)
This style has a tendency to spread:
Now I want to also make osmo-msc's struct codec_filter a dynamic allocation,
because the codec_filter_foo() currently have no ctx argument; they still use
the static SDP structs. When the codec_filter pointer itself is the neat
logical talloc parent of the codec lists it uses, then I don't need to add a
separate ctx arg everywhere now.
Am I taking this too far now?
Am I overthinking it and either way is fine?
== opaque vs transparent ==
I can either have the full struct definition in the .h file = transparent, or I
can hide the struct in the .c file and provide lots of getter and setter
functions = opaque.
Both ways have a major advantage over the other:
- opaque means that we can freely extend the API without any ABI breakage,
ever.
- transparent means that callers can easily define const arrays of data
structures. In my case, I want to keep const lists of const codecs for e.g.
test data in unit tests, for listing known codecs in codec_mapping.c, for
defining default codec configuration.
transparent allows:
const struct osmo_sdp_codec ran_defaults = {
{ .encoding_name = "AMR", .rate = 8000, .fmtp = "octet-align=1;mode-set=0,2,4,7", .payload_type = 112, },
{ .encoding_name = "AMR", .rate = 8000, .fmtp = "octet-align=1;mode-set=0,2,4", .payload_type = 112, },
{ .encoding_name = "AMR", .rate = 8000, .fmtp = "mode-set=0,2,4,7", .payload_type = 112, },
{ .encoding_name = "AMR", .rate = 8000, .fmtp = "mode-set=0,2,4", .payload_type = 112, },
{ .encoding_name = "GSM-EFR", .rate = 8000, .payload_type = 110, },
{ .encoding_name = "GSM", .rate = 8000, .payload_type = 3, },
{ .encoding_name = "GSM-HR-08", .rate = 8000, .payload_type = 111, },
};
int i;
for (i = 0; i < ARRAY_SIZE(ran_defaults); i++)
osmo_sdp_codec_list_add(g_ran_codecs_cfg, &defaults[i])
printf("%s", codec->encoding_name);
if (!strcmp(codec->encoding_name, "AMR"))
printf(":%s", codec->fmtp);
same in opaque:
osmo_sdp_codec_list_add(g_ran_codecs_cfg, "AMR", 8000, "octet-align=1;mode-set=0,2,4,7", 112);
osmo_sdp_codec_list_add(g_ran_codecs_cfg, "AMR", 8000, "octet-align=1;mode-set=0,2,4", 112);
osmo_sdp_codec_list_add(g_ran_codecs_cfg, "AMR", 8000, "mode-set=0,2,4,7", 112);
osmo_sdp_codec_list_add(g_ran_codecs_cfg, "AMR", 8000, "mode-set=0,2,4", 112);
osmo_sdp_codec_list_add(g_ran_codecs_cfg, "GSM-EFR", 8000, NULL, 110);
osmo_sdp_codec_list_add(g_ran_codecs_cfg, "GSM", 8000, NULL, 3);
osmo_sdp_codec_list_add(g_ran_codecs_cfg, "GSM-HR-08", 8000, NULL, 111);
printf("%s", osmo_sdp_codec_get_encoding_name(codec));
if (!strcmp(osmo_sdp_codec_get_encoding_name(codec), "AMR"))
printf(":%s", osmo_sdp_codec_get_ftmp(codec));
The opaque looks alright in comparison, but
- being able to enlist a struct osmo_sdp_codec in a const array is powerful,
allowing the paradigm to replace code complexity by good data structures.
So used in codec_mapping.c in osmo-msc.
- requiring getters and setters for each end every member creates a long list
of API functions: 'get' and 'set' for each orthogonal member; we might be
tempted to "dupe" many llist_*() functions for osmo_sdp_codec_list.
- having to call functions for each end every member makes the code a lot more
noisy.
- it forces all allocation decisions down onto the caller = only using the API
author's favorite dynamic allocation, hello memleaks etc.
IMHO, opaque APIs are often lots of code with very low density of actually
important stuff.
/* This function gets foo. */
struct foo *get_foo(x)
{
return x->foo;
}
This is so plump and boring!!
Currently I am following the transparent way,
and putting 'bool v2;' extension flags for a distant future in the structs'
ends.
But there has been a discussion here that the truly good APIs are opaque.
talloc, libSDL, libsndfile come to mind.
== both ==
Finally, these two aspects are interdependent:
An opaque API *has* to be dynamic.
So far, I am moving from the transparent+static implementation to
transparent+dynamic.
Should I also go the "next" step to opaque+dynamic? I don't really want to...
I've had these considerations many times in my life, and there never seems to
be the one best way.
Thanks for your thoughts!
If you need more code reference for what I am talking about:
old static:
https://cgit.osmocom.org/osmo-msc/tree/include/osmocom/msc/sdp_msg.h?id=1b1…https://cgit.osmocom.org/osmo-msc/tree/src/libmsc/sdp_msg.c?id=1b1a39bea1c5…
new dynamic+transparent:
https://cgit.osmocom.org/osmo-mgw/tree/include/osmocom/sdp?h=neels/sdp&id=2…https://cgit.osmocom.org/osmo-mgw/tree/src/libosmo-sdp?h=neels/sdp&id=24c09…
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hi,
I hope this is the place to ask this, if not I will delete this post. I am trying to run my own 2G network for researching purposes. I am running the following elements:
- osmo-bts-trx (connecting to osmo-trx-uhd driving a USRP B205mini-i)
- osmo-bsc
- osmo-msc
- osmo-hlr
- osmo-mgw
I built all the programs from source on Ubuntu 22.04. Everything is running locally on one machine.
Everything seems to be running OK. I was able to register two different subscribers by IMSI (without providing K and OPc) and assign MSISDN tothem. They can use the default USSD codes for seeing their IMSI and their MSISDN and I can make voice calls between both subscribers. I am mostly using the default config files provided with the installation, the only changes I made to them was to point IPs to 127.0.0.1 to run everything on the same machine.
But when starting osmo-bsc and osmo-msc I get the same error on both:
jonathan@em680:~/tfg/osmo/config$ osmo-msc -c osmo-msc.cfg
DLGLOBAL NOTICE Available via telnet 127.0.0.1 4254 (telnet_interface.c:88)
DLCTRL NOTICE CTRL at 127.0.0.1 4255 (control_if.c:1014)
DLGSUP NOTICE GSUP connecting to 127.0.0.1:4222 (gsup_client.c:74)
DDB NOTICE Init database connection to 'sms.db' using SQLite3 lib version 3.37.2 (db.c:521)
DLMGCP NOTICE MGW(mgw) MGCP client: using endpoint domain '@mgw' (mgcp_client.c:933)
DMSC NOTICE MGW pool with 1 pool members configured, (ignoring MGW configuration in VTY node 'msc'). (msc_main.c:596)
DLSCCP NOTICE OsmoMSC-A: Creating SS7 instance (sccp_user.c:536)
DLSCCP NOTICE OsmoMSC-A: Using SS7 instance 0, pc:0.23.1 (sccp_user.c:563)
DLSCCP NOTICE OsmoMSC-A: Creating AS instance (sccp_user.c:570)
DLSCCP NOTICE OsmoMSC-A: Using AS instance as-clnt-OsmoMSC-A (sccp_user.c:581)
DLSCCP NOTICE OsmoMSC-A: Creating default route (sccp_user.c:587)
DLSCCP NOTICE OsmoMSC-A: No unassociated ASP for m3ua, creating new ASP asp-clnt-OsmoMSC-A (sccp_user.c:626)
DLGLOBAL ERROR Trying to dispatch event 17 to non-existent FSM instance! (osmo_ss7_as.c:118)
DLGLOBAL ERROR backtrace() returned 11 addresses (backtrace.c:42)
DLGLOBAL ERROR /usr/local/lib/libosmocore.so.21(osmo_log_backtrace+0x24) [0x7fc1ddd9fdcc] (backtrace.c:53)
DLGLOBAL ERROR /usr/local/lib/libosmocore.so.21(_osmo_fsm_inst_dispatch+0x144) [0x7fc1dddaade7] (backtrace.c:53)
DLGLOBAL ERROR /usr/local/lib/libosmo-sigtran.so.9(osmo_ss7_as_add_asp+0x1f9) [0x7fc1ddcfb80c] (backtrace.c:53)
DLGLOBAL ERROR /usr/local/lib/libosmo-sigtran.so.9(osmo_sccp_simple_client_on_ss7_id+0xa48) [0x7fc1ddd1dd5e] (backtrace.c:53)
DLGLOBAL ERROR osmo-msc(+0x26fd8) [0x55fa5388bfd8] (backtrace.c:53)
DLGLOBAL ERROR osmo-msc(+0x27043) [0x55fa5388c043] (backtrace.c:53)
DLGLOBAL ERROR osmo-msc(+0x27bed) [0x55fa5388cbed] (backtrace.c:53)
DLGLOBAL ERROR /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7fc1dd95fd90] (backtrace.c:53)
DLGLOBAL ERROR /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7fc1dd95fe40] (backtrace.c:53)
DLGLOBAL ERROR osmo-msc(+0x26565) [0x55fa5388b565] (backtrace.c:53)
DLSCCP NOTICE OsmoMSC-A: Using ASP instance asp-clnt-OsmoMSC-A (sccp_user.c:695)
DLSS7 NOTICE 0: Creating SCCP instance (osmo_ss7.c:408)
DSGS NOTICE SGs socket bound to r=NULL<->l=0.0.0.0:29118 (sgs_server.c:186)
DMSC NOTICE A-interface: SCCP user OsmoMSC-A:RI=SSN_PC,PC=(no PC),SSN=BSSAP, cs7-instance 0 ((null)) (msc_main.c:806)
DLINP NOTICE 127.0.0.1:4222 connection done (ipa.c:141)
DLINP NOTICE received ID_GET for unit ID 0/0/0 (ipaccess.c:919)
DLM3UA NOTICE 0: asp-asp-clnt-OsmoMSC-A: Received NOTIFY Type State Change:AS Inactive () (m3ua.c:625)
DLSS7 NOTICE xua_default_lm(asp-clnt-OsmoMSC-A)[0x55fa542bb080]{ACTIVE}: Ignoring primitive M-ASP_ACTIVE.confirm (xua_default_lm_fsm.c:400)
DLM3UA NOTICE 0: asp-asp-clnt-OsmoMSC-A: Received NOTIFY Type State Change:AS Active () (m3ua.c:625)
DLM3UA NOTICE 0: asp-asp-clnt-OsmoMSC-A: Rx DAVA() for 0.23.3/0, (xua_snm.c:403)
...
jonathan@em680:~/tfg/osmo/config$ osmo-bsc -c osmo-bsc.cfg
DLGLOBAL NOTICE Available via telnet 127.0.0.1 4242 (telnet_interface.c:88)
DLINP NOTICE enabling ipaccess BSC mode on 0.0.0.0 with OML 3002 and RSL 3003 TCP ports (ipaccess.c:1055)
DLCTRL NOTICE CTRL at 127.0.0.1 4249 (control_if.c:1014)
DLMGCP NOTICE MGW(mgw) MGCP client: using endpoint domain '@mgw' (mgcp_client.c:933)
DNM NOTICE MGW pool with 1 pool members configured, (ignoring MGW configuration in VTY node 'msc'). (osmo_bsc_main.c:889)
DMSC NOTICE To auto-configure msc 0, creating cs7 instance 0 implicitly (osmo_bsc_sigtran.c:600)
DMSC NOTICE Initializing SCCP connection for A/m3ua on cs7 instance 0 (osmo_bsc_sigtran.c:647)
DLSCCP ERROR SS7 instance 0: no primary point-code set, using default point-code (sccp_user.c:557)
DLSCCP NOTICE A-0-m3ua: Using SS7 instance 0, pc:0.23.3 (sccp_user.c:563)
DLSCCP NOTICE A-0-m3ua: Creating AS instance (sccp_user.c:570)
DLSCCP NOTICE A-0-m3ua: Using AS instance as-clnt-A-0-m3ua (sccp_user.c:581)
DLSCCP NOTICE A-0-m3ua: Creating default route (sccp_user.c:587)
DLSCCP NOTICE A-0-m3ua: No unassociated ASP for m3ua, creating new ASP asp-clnt-A-0-m3ua (sccp_user.c:626)
DLGLOBAL ERROR Trying to dispatch event 17 to non-existent FSM instance! (osmo_ss7_as.c:118)
DLGLOBAL ERROR backtrace() returned 10 addresses (backtrace.c:42)
DLGLOBAL ERROR /usr/local/lib/libosmocore.so.21(osmo_log_backtrace+0x24) [0x7f990ff0ddcc] (backtrace.c:53)
DLGLOBAL ERROR /usr/local/lib/libosmocore.so.21(_osmo_fsm_inst_dispatch+0x144) [0x7f990ff18de7] (backtrace.c:53)
DLGLOBAL ERROR /usr/local/lib/libosmo-sigtran.so.9(osmo_ss7_as_add_asp+0x1f9) [0x7f990fe9380c] (backtrace.c:53)
DLGLOBAL ERROR /usr/local/lib/libosmo-sigtran.so.9(osmo_sccp_simple_client_on_ss7_id+0xa48) [0x7f990feb5d5e] (backtrace.c:53)
DLGLOBAL ERROR osmo-bsc(+0x144035) [0x556b310d7035] (backtrace.c:53)
DLGLOBAL ERROR osmo-bsc(+0x2aef0) [0x556b30fbdef0] (backtrace.c:53)
DLGLOBAL ERROR /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7f990fc55d90] (backtrace.c:53)
DLGLOBAL ERROR /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7f990fc55e40] (backtrace.c:53)
DLGLOBAL ERROR osmo-bsc(+0x28265) [0x556b30fbb265] (backtrace.c:53)
DLSCCP NOTICE A-0-m3ua: Using ASP instance asp-clnt-A-0-m3ua (sccp_user.c:695)
DLSS7 NOTICE 0: Creating SCCP instance (osmo_ss7.c:408)
DMSC NOTICE A-0-m3ua msc-0: local (BSC) SCCP address: RI=SSN_PC,PC=0.23.3,SSN=BSSAP (osmo_bsc_sigtran.c:703)
DMSC NOTICE A-0-m3ua msc-0: remote (MSC) SCCP address: RI=SSN_PC,PC=0.23.1,SSN=BSSAP (osmo_bsc_sigtran.c:705)
DMSC NOTICE A-0-m3ua msc-0: binding SCCP user (osmo_bsc_sigtran.c:710)
DLSS7 ERROR XUA_AS(as-clnt-A-0-m3ua)[0x556b31b42cc0]{AS_INACTIVE}: Event AS-TRANSFER.req not permitted (m3ua.c:510)
DLM3UA NOTICE 0: asp-asp-clnt-A-0-m3ua: Received NOTIFY Type State Change:AS Inactive () (m3ua.c:625)
DLSS7 NOTICE xua_default_lm(asp-clnt-A-0-m3ua)[0x556b31b445c0]{ACTIVE}: Ignoring primitive M-ASP_ACTIVE.confirm (xua_default_lm_fsm.c:400)
DLM3UA NOTICE 0: asp-asp-clnt-A-0-m3ua: Received NOTIFY Type State Change:AS Active () (m3ua.c:625)
DMSC NOTICE RESET ACK from MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP (osmo_bsc_bssap.c:84)
DRESET NOTICE bssmap_reset(msc-0)[0x556b31b45790]{CONNECTED}: link up (bssmap_reset.c:83)
DMSC NOTICE (msc0) BSSMAP association is up (a_reset.c:45)
DLINP NOTICE 0.0.0.0:3002 accept()ed new link from 127.0.0.1:38477 (ipa.c:318)
DLINP NOTICE Keepalive is set: 0 (ipaccess.c:612)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'GPRS' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'EGPRS' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'HOPPING' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'MULTI_TSC' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'OML_ALERTS' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'CBCH' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'SPEECH_F_V1' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'SPEECH_H_V1' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'SPEECH_F_EFR' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'SPEECH_F_AMR' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'SPEECH_H_AMR' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'ETWS_PN' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'PAGING_COORDINATION' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'IPV6_NSVC' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'ACCH_REP' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'CCN' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'VAMOS' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'ABIS_OSMO_PCU' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'BCCH_PWR_RED' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'DYN_TS_SDCCH8' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'ACCH_TEMP_OVP' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'VBS' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'VGCS' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): ARI reported sw[0/2]: osmobts is 1.7.0.54-82a2 (abis_nm.c:652)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Reported variant: osmo-bts-trx (abis_nm.c:534)
DNM ERROR OC=RADIO-CARRIER(02) INST=(00,00,ff): Attribute SW Configuration is unreported (abis_nm.c:557)
DNM ERROR OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): Attribute Manufacturer Dependent State is unreported (abis_nm.c:557)
DNM NOTICE OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown (abis_nm.c:652)
DLINP NOTICE 0.0.0.0:3003 accept()ed new link from 127.0.0.1:37491 (ipa.c:318)
DLINP NOTICE Keepalive is set: 0 (ipaccess.c:612)
...
Is it something I should worry about?
Thanks
Empower your journey in customer relationship management (CRM) with our comprehensive support services. Our team specializes in providing expert guidance and assistance tailored to your CRM assignment needs. From analyzing customer data to implementing effective strategies, our CRM Assignment Help ensures you're equipped with the knowledge and skills to excel. Trust us to be your partner in success as you navigate the complexities. Let our expertise be at your fingertips, guiding you toward academic achievement and more visit our website Now.https://reportwritinghelp.com/assignment/consumer-behavior-assignment-h…
Hi,
I had a problem placing MO GSM calls from a Siemens S11E: The calls
were dropped immediately; Osmo-MSC reports "Cannot compose Channel
Type from bearer capabilities"
After investigating the SETUP request from the S11E, the phone does
not use octet 3a (no extension bit set in IE 3). Wireshark decodes the
radio channel requirement as "Full rate support only MS/fullrate
speech version 1 supported", so I added a condition to the gsm48_ie.c
function of libosmocore to include at least GSM FR in the list of
available speech_ver in case octet 3 has no extension.
Attached to this message are the Abis-IP PCAP traces of MO calls, and
the patch for gsm48_ie.c.
Regards,
Lennart
Hi,
My name is Brackley Cassinga Form DRC, we run a community network called
pamoja net where we offer gsm services using osmocom open source software
and OC Base station.
Recently I have tried to install another base station as the same installed
but I could not find any resource guiding through all the steps to take to
run NIB on a base station.
I'm currently running Ubuntu and I will appreciate if you could guide me on
the installation of BSC,hlr,MSC , in order to run a basic gsm network.
Thank you. Regards
--
*Ir Brackley heshima Casinga **Pacifique*
*CEO and Founder of kwanzatechnologie*
KwanzaTechnologies ,GlobalElectronics
+243977265291 | +243977265291 | Pcassinga(a)gmail.com/
brackley(a)ensemblepourladifference.org
www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> |
Skype: Brackley cassinga <https://webapp.wisestamp.com/#>
Av Semliki N 43
Hello Osmocom community,
I have a contact in Australia who reached out to me with a desire to
set up his own personal GSM/2G network. Australia is a nasty anti-
retrotechnology country, even worse than USA, where all official 2G
networks were shut down back in 2018. As most of you know, I run my
own pirate-radio GSM cell in USA, and I tried reaching out to other
Vintage Mobile Phone communities, promoting the idea that people can
run their own networks using Osmocom CNI plus suitable hw plus my
ThemWi add-ons for outside PSTN interconnection, and offering to teach
others how to copy what I am doing. When I made the latter offer to
the community, I was expecting people from other parts of USA - but
right now the only person with an active interest is in Australia.
I am currently teaching my Australian contact the "pure physics"
aspects of running your own GSM network: what frequencies are usable
for GSM, dB and dBm units of measurements, how to use a handheld
spectrum analyzer etc. These are all "physics" topics that are
independent of where one happens to be geopolitically. But there is
another key aspect which I feel he needs to know, but which I won't be
able to teach him: country-specific spectrum-political aspects.
I know the spectrum-political landscape in USA: how FCC has divvied up
PCS1900 and GSM850 bands (or B2 & B5 in modern parlance) between
carriers, which spots in these bands are completely unused and thus
reasonably safe to squat in, and how one can exploit the overlap
between EGSM900 DL and USA ISM band to run a BTS with low probability
of getting into trouble. But I have absolutely no such knowledge for
any other country in the world, let alone one as remote and foreign to
me as Australia.
Is there anyone in this community who is based in Australia and knows
this topic? I would greatly appreciate any advice from an AU-knowing
person that I could pass to my GSM-enthusiast contact: out of the 4
frequency bands that are in-principle suitable for GSM, which is the
safest one to squat in for a pirate operator, and which ARFCN range(s)?
Obviously I will teach my contact that he needs to pick a spot where
the spectrum analyzer shows nothing but noise floor, but just because
a spot "looks blank" on an SA doesn't mean that the spot is safe to
squat on, without knowing anything at all about the country's
spectrum-political landscape...
TIA,
Mychaela
Dear all
We have a questions for you, experts.
Has anyone managed to get Osmocom with limesdr Mini 2.0 ? (USB)
We have stability issues, so if someone has tried and can share configuration for osmocom-bsc and osmocom-trx-lms, it woud be great !
Many thanks in advance,
Best regards
Good Morning,
My name is Tanya and was referred to this email regarding open source
involvement. I am genuinely interested in sysmocom and am open to exploring
various ways I can support your team. If there are any upcoming
opportunities or specific areas where my skills could be of value in a
volunteer capacity, I would be grateful for the chance to discuss them
further.
Please take a look at my GitHub profile: https://github.com/wonntann
Thank you again for your consideration. I look forward to the possibility
of contributing to sysmocom and will continue to follow your updates.
Best,
Tanya
Hello Osmocom community,
I have a question about TCP port number assignment for programs using
libosmovty. Every Osmo-official server program gets official port
number assignments listed in the wiki, in PDF manuals etc - so far, so
good. But what about non-Osmo-official 3rd-party programs that wish
to use common Osmocom libraries, including the vty facility? Suppose
that an operator of an Osmocom-based cellular network needs to develop
some additional programs to satisfy some operational need, and some of
these additional programs are long-lived server processes for which an
Osmocom-style vty interface would be very useful. But implementing
such a telnet vty i/f requires a TCP port number...
Has anyone thought about designating an official range of TCP port
numbers which would be recommended for vty/ctrl/etc ports of processes
that use Osmocom libraries and extend Osmocom CNI in various ways, but
aren't official Osmocom projects?
M~
Hi all!
[cross-post to make sure everyone knows about it, please follow-up-to
the osmodevcon(a)lists.osmocom.org mailing list for further discussion]
As I mentioned several times at different occasions, I really think we
should put together a OsmoDevCon again. In case you don't know what that
is, please see https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon
We should have restarted already in 2023, but I really was too busy and
it was a somewhat difficult year for me at times, sorry.
Date
----
In terms of timing, I am thinking about "after April but before the main
summer holiday season (June-August)". That leaves May.
Given that May has the whitsunday weekend as well as GPN
(Gulaschprogrammiernacht, a CCC event that will likely conflict
of interest with some people interested at attending OsmoDevCon), I'm
currently considering the following candidate dates:
* May 3 to 6
* May 24 to 27
This is as usual a friday-to-monday timeframe, allowing people who don't
work professionally on osmocom to attend just the two weekendd days,
while others can attend the full 4 days.
Venue
-----
In terms of venue, I'm hoping we can move to a slightly different
arrangement where the whole group stays together for the whole duration
of the event - as opposed to everyone staying at different hotels and
having to commute from hotel to venue and back every day. So something
like a hotel with a sufficiently large meeting room, hotels and catering
all day. And all of that ideally at a nice venue with some kind of park /
outdoor area, not downtown at the city center. Yes, that will obviously
come at a higher price tag than we're used to - but I'm confident we can
get that covered between sponsors and sysmocom.
Do you guys think this is a good idea? Or would you prefer the
traditional ad-hoc approach at IN-Berlin?
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all,
does anyone have feedback on this dubious libosmo-mgcp-devel we publish in our
osmo-mgw.spec?
More detail in https://osmocom.org/issues/6300
Thanks!
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hi all,
I'd like to drop the 'sdp audio fmtp-extra ...' cfg option from osmo-mgw.
If this option needs to stay, I'd like to hear about that.
There is more context in https://osmocom.org/issues/6313
Thanks!
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Dear mailing list,
I'm looking into releasing a new osmo-pcu version to finish up OS#6198,
and to have a release with the fix for OS#6191. Apparently that fix
requires a new PCUIF version. And osmo-pcu master now has a check that
requires the *exact* PCUIF version:
https://cgit.osmocom.org/osmo-pcu/commit/?id=46140948d9800bca6a7b4299f08b25…
pcu_i1_if.cpp:
} else if (info_ind->version != PCU_IF_VERSION) {
fprintf(stderr, "PCU interface version number of BTS/BSC (%u) is
different (%u).\nPlease use a BTS/BSC with a compatble interface!\n",
info_ind->version, PCU_IF_VERSION);
exit(-1);
}
So we will need to create releases of osmo-bts and osmo-bsc with the new
PCUIF version as well. As this is a breaking change, I think we should
bump the major version, and that in turn makes more sense with tagging
current master instead of cherry picking a few patches.
So I propose to do the following:
* tag a new libosmocore patch release with the few patches required for
osmo-pcu, osmo-bts and osmo-bsc master (see their TODO-RELEASE).
* tag major releases of osmo-pcu, osmo-bts and osmo-bsc from their
current master
Does that make sense?
Best regards,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hi Nick,
I just read your post
https://nickvsnetworking.com/tales-from-the-trenches-mode-set-in-amr/
and just when it really gets interesting, the article ends =)
I'm working at osmocom.org and am currently figuring out how TH we are supposed
to communicate the AMR mode sets across 2G + 3G mobile networking on the one
side and SDP/SIP+RTP on the other side.
My plan was to do it like choosing codecs: One side sends all its capabilities,
the other responds with the own capabilites removing unsupported entries.
Now I read in your post that mode-set is take-it-or-leave-it.
The interesting part is the practical problem that arises from it: e.g. on a 2G
mobile network, i'm allowed to choose up to four AMR rates, no more. When on a
half-rate channel, then specific rates (12k2, 10k2) are not supported.
Otherwise I can tell the 2G BTS and the phone to pick various mode-set
combinations. So why not send a full mode-set of 0,1,2,3,4,5,6,7 and the other
call leg can then say "i'll pick these four", or something like that.
With your spec references, it means that now I need to pick specific mode-set
combinations in advance, and assign a different payload type number to each of
them.
The extreme example would be:
a rtpmap:110 AMR/8000/1
a fmtp:110 mode-set=0
a rtpmap:111 AMR/8000/1
a fmtp:111 mode-set=1
a rtpmap:112 AMR/8000/1
a fmtp:112 mode-set=2
...
a fmtp:117 mode-set=7
a fmtp:118 mode-set=0,1
a fmtp:119 mode-set=0,2
a fmtp:120 mode-set=0,3
a fmtp:121 mode-set=0,4
...
a fmtp:99999998 mode-set=0,1,2,3,4,5,6
a fmtp:99999999 mode-set=0,1,2,3,4,5,6,7
Obviously nonsense, but you catch my drift.
So what is the solution then?
In 2G GSM I have half-rate and full-rate channels; AMR-FR and AMR-HR should be
able to interop. So if one FR side offers mode-set=0,2,4,7 then the HR side may
return mode-set=0,2,4 to leave only HR compatible rates. Well, no.
If not that, then:
I probably need to create one RTPMAP entry for full-rate compatible operation
and another entry for half-rate compatible operation.
111:mode-set=0,2,4,7 112:mode-set=0,2,4
Also some hardware supports only 12k2, so then I need to add an extra entry for
only 12k2. But I have to so not only on the side that has the 12k2 limit, but
on the side that wants to interop with it! Because if the peer doesn't offer a
single "mode-set=7", then the only-12k2 supporting side must reject the entire
call.
111:mode-set=0,2,4,7 112:mode-set=0,2,4 113:mode-set=7
The question is, were the specs in good intentions, but in practicality it is
mayhem of exploding nr of permutations, and maybe your MGW made a sane choice
of not diving into this madness?
Thanks for your feedback on this!
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hi all,
I have a request for comments regarding osmo-mgw,
particularly the fmtp for AMR octet-align mode and the two GSM-HR variants.
We are currently reviewing/writing patches to allow flexible use of fmtp in
libosmo-mgcp-client. The plan is to be able to indicate which GSM-HR variant
(RFC5993 or 3GPP TS 101.318) is in use.
Also we are fixing the ability to indicate AMR mode (octet-align=1 vs 0)
properly, per payload type nr instead of once per SDP body.
Example of MGCP with SDP, showing two codecs, AMR as 112 and GSM-HR as 111,
each with a fmtp as I'm discussing now:
CRCX 2 7@mgw MGCP 1.0
C: 2
v=0
c=IN IP4 123.12.12.123
m=audio 5904 RTP/AVP 112 111
a=rtpmap:112 AMR/8000/1
a=fmtp:112 octet-align=1
a=rtpmap:111 GSM-HR-08/8000/1
a=fmtp:111 gsm-hr-format=3gpp-ts-101.318
a=ptime:20
That means that each MGW client tells osmo-mgw exactly what AMR and HR formats
to send to the RTP peer, and also restricts exactly which format to expect from
that RTP peer. So BSC and MSC need to know things about BTS and BSS, in advance:
- the BSC needs configured knowledge of each BTS's octet-align and gsm-hr-format.
- the MSC needs configured knowledge of what the BSC will do.
- what if there are divergent formats in different BTS of a BSS, does MSC need to know that too?
There is certainly no way to indicate octet-align nor HR variant in standard A interface proto.
So far so complex, BUT:
In practical testing, I see from logging that osmo-mgw is already quite capable
of detecting which AMR octet-align mode and which HR format is actually
arriving from the RTP peer (from the BTS...).
I see this log line:
DRTP NOTICE (rtpbridge/1@bsc0 I:FA1F785D) rx_rtp(44 bytes): Expected RTP AMR octet-aligned=1 but got octet-aligned=0. check the config of your call-agent! (mgcp_network.c:1525)
And I'm thinking, where is the problem, just do what you need to do; all the
information it needs to do the right thing is already available to osmo-mgw.
So why even the need to configure {AMR octet-align|GSM-HR mode} in SDP?
Idea:
- the first RTP packet arriving is examined, and from then on the peer is
known to use that format.
- when later, an RTP needs to be forwarded back to that peer, we convert to the
format that the peer uses, iff it is necessary.
- for sanity we could hold back forwarding RTP before the details of the
recipient are known, i.e. wait for each peer to send the first RTP to MGW.
Example for an RTP stream in GSM-HR format:
A MGW B
|--HR(3gpp)-->|--x drop | (don't know B's preference yet, cannot send)
| [3gpp]| | (now know A uses the 3gpp format)
| |<--HR(rfc)--|
| |[rfc] | (now know B uses the RFC format)
| [convert] |
|<--HR(3gpp)--| |
|--HR(3gpp)-->|--HR(rfc)-->|
|<--HR(3gpp)--|<--HR(rfc)--|
There is an important difference between AMR octet-align and GSM-HR:
- 'octet-align=(0|1)' is a defined standard fmtp that already exists, and it
may be necessary to forward this accurately to PBX. We may not get around
having to explicitly set this.
- GSM-HR format is a new fmtp we are inventing now. So the idea is most
relevant here: if we can always just autodetect the right thing to do, then
why introduce a non-standard fmtp? (plus all the MGW client vty cfg needed)
What do you think?
Thanks!
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hello various Osmocom mailing lists,
the official Osmocom binary packages will not be built anymore for the
following distributions starting at 2024-02:
* Raspberry Pi OS 64-bit (use Debian_12 etc. instead)
* Ubuntu 23.04 (Ubuntu 23.10 and LTS 20.04/22.04 feeds are available)
* openSUSE 15.4 (openSUSE Tumbleweed feed is available)
* Debian Testing (Debian Unstable and 12-10 feeds are available)
For Raspberry Pi OS 64-bit users, make sure to adjust your
/etc/apt/sources.list.d as described here to switch to a Debian
aarch64 feed:
https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds
See the new linux distributions article for information on how long we
plan to keep building packages for each distribution:
https://osmocom.org/projects/cellular-infrastructure/wiki/Linux_distributio…
Let me know if you have questions.
Best regards,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hi
We set up a full Osmocom platform, with an Ettus USRP for SDR. All works
well. Congratulations to Osmocom developers !
But now we want to use "real" nodes concerning MSC, MGW, HLR, SGSN & GGSN.
Do you think it is possible ?
Concerning the BSC-MSC association, do we need to use an SG (osmo-stp) ? or
could we establish a Point To Point BSC-MSC ? SUA ?
Concerning MGW, is there a way to use our MGW ? At this time, with Osmocom
corposants, we can see RTP traffic between BTS-TRX and MGW, and some MGCP
traffic between (BSC - local MGW) and MGW, and some MGCP traffic between
osmo-MGW and osmo-MSC. Is there a way to have a "more standard"
architecture: no traffic between BTS and MGW, and MGW controlled by MSC ? Do
we have to more study TRAU, AoIP ?
Concerning the Gb, do you think that it 'll work if we configure the Gb on a
real SGSN connected to the osmo-pcu, hosted on the osmo-bts-trx?
Many thanks in advance,
Best regards
Jean-Marc
Orange Restricted
It is my pleasure to inform that I have a WIP patch for OsmoMSC that allows,
for the first time, full MO<->MT codecs negotiation to flexibly achieve TFO
(Transcoding-Free Operation).
It would be great if OsmoMSC users could give the patch a spin (in a setup that
is allowed to fail because of the patch) and see if 2G calls now adjust the MO
call leg to MT's codecs limitations for you. Looking forward to feedback!
This task was idling on my list because I assumed it would be a big effort, but
now I realized that it is actually simple, not even a new FSM state required.
So I could no longer resist to finally complete this long long quest.
The result is this WIP patch:
https://gerrit.osmocom.org/c/osmo-msc/+/35051
Related patch series, uncluding ttcn3 test:
https://gerrit.osmocom.org/q/topic:reass
This patch requires full SDP on MNCC, so if using osmo-sip-connector, it should
be current master -- the relevant patch was merged but is not released yet:
https://gerrit.osmocom.org/c/osmo-sip-connector/+/16222
Before this patch, MO was eternally stuck on the initially assigned codec. Now
we adjust MO's codec if MT needs it. (MT already intelligently chooses codecs
before this patch.)
For example, if MO is AMR capable and MT is not,
- the MO side will start out with assigning an AMR codec (not matching).
- Once MT responds (MNCC_ALERT_REQ), the MO side notices that MT does not
support the assigned codec. It sends another Assignment Command to the BSC,
offering only the codecs that MT supports.
- If MO has at least one matching codec (say GSM-FR), the result is a TFO call
using a matching codec.
We still need to check:
- does OsmoBSC play along nicely with the re-assignment (it should AFAICT).
- effects on MGCP: there may now be more codecs than just the assigned one in
the MGCP towards the MGW. See if that checks out.
- effects on 3G: make sure the feature doesn't confuse IuUP handling.
The patch passes all MSC_Tests.ttcn for me (but that doesn't necessarily imply
proper codecs choices, the tests are not very strict there it seems).
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Dear Osmocom community,
we're happy to announce the next incarnation of OsmoDevCall.
when:
(today) November 15, 2023 at 20:00 CET
where:
https://osmocom.org/OsmoDevCall (Big Blue Button)
This time, @falconia will be presenting on
Calypso chipset history and development boards, from TI to FreeCalypso
This meeting will have the following schedule:
20:00 meet + greet
20:10 topic as outlined above
21:00 unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom or open source cellular technologies.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you soon!
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear List,
I tried to set up Osmo-CBC with a Nokia MetroSite BTS according to the
wiki. But every time the CBSP clinet of the BSC connects to the CBC
server, the BSC log indicates:
DCBS cbsp_link.c:150 CBSP Client connected to CBC:
(r=127.0.0.1:48049<->l=127.0.0.1:46133)
DCBS smscb.c:805 (bts=0) Rx CBSP RESET: clearing all state; disabling broadcast
Same time on the CBC:
<0002> cbsp_link.c:265 New CBSP link connection from 127.0.0.1:46133
<0002> cbsp_link_fsm.c:181 local-bsc: RESTART (CBS) but re-sending not
implemented yet
The BTS is configured with CCCH+SDCCH4+CBCH, and these are the
relevant sections:
osmo-cbc.cfg:
cbc
unknown-peers reject
ecbe
local-ip 127.0.0.1
local-port 12345
cbsp
local-ip 127.0.0.1
local-port 48049
sbcap
local-ip 127.0.0.1
local-port 29168
peer cbsp local-bsc
mode server
remote-port 46133
remote-ip 127.0.0.1
osmo-bsc.cfg:
cbc
mode client
client
remote-ip 127.0.0.1
local-ip 127.0.0.1
local-port 46133
Every other CS service is working fine on the BTS.
Is there anything else I might have missed?
Regards,
Csaba
Dear Osmocom community,
we're happy to announce the next incarnation of OsmoDevCall.
when:
September 20, 2023 at 20:00 CEST
where:
https://osmocom.org/OsmoDevCall (Big Blue Button)
This time, @falconia will be presenting on
Themyscira Wireless: a case study in interconnecting an Osmocom GSM network to USA PSTN
This meeting will have the following schedule:
20:00 meet + greet
20:10 topic as outlined above
21:00 unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom or open source cellular technologies.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you soon!
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
I just noticed that a release was made,
ignoring this remark in osmo-msc's TODO-RELEASE:
MNCC osmo-sip-connector should do full SDP via MNCC and be released at the same time as the next osmo-msc, ask neels, thanks
https://gerrit.osmocom.org/c/osmo-msc/+/34386
There is no full SDP support in current osmo-sip-connector.
In fact the patch for that is just now becoming ready for merge:
https://gerrit.osmocom.org/c/osmo-sip-connector/+/16222
I guess we should get the sipcon patch merged, and follow up with another
sipcon release.
~N
Dear list,
I built an icE1USB device so I can provide stable clock to my legacy Nokia BTS.
I have not found any information about how to bring up a completely
empty device, so I just took the icE1usb-202210-5890f3e4.bin file and
flashed it to the SPI flash, yet the device is not booting. Maybe
something else is missing (like a boot block), or the binary has to be
flashed with an offset? The device takes 80mA in this state, USB
device is not recognized on the host.
Thanks!