While reading an article on LTE, I came across a term "LTE Stack Protocol Development". Sadly, there was no further explanation on the term and when I looked it up on google, it turned up all job openings in LTE protocol development.
So here is the question, what exactly is "LTE stack protocol development" and if possible I would like to learn more about it, could some one point me to some good reading material, it could be a book or website.
Basically, I would like to know "what and how" part for this. By "what" I mean, what all would be required to learn this development and by "how" I would like to know how it can be done/learnt or how it defers from product/application development in industry.
Thanks for your time to go through my question and I apologize if I sound too demanding in the question :).
Look up Protocol Stack on Wikipedia for a discussion of the basic concepts of a protocol stack. Also see the OSI model, which is a standard example.
LTE is a system defined by 3GPP, which is an international partnership of interested companies. There are diagrams of the LTE protocol stack here.
LTE protocols are divided into two sets: the Control Plane, which deals with what you can call "administrative tasks" like registering a phone on the network, tracking its location and setting up a data session. The User Plane contains the protocols that actually carry user data.
The website to which I linked is particularly useful because you can click on the names of each protocol to get links to its formal specification document on the 3GPP website.
To relate the LTE protocol stack roughly to the simple model given on the Wikipedia protocol stack page, look for IP, which corresponds to the Internet layer. Everything below IP corresponds to the LTE protocols for the data link and physical layers.
On Google, you can find books about LTE, which will give you a summary of the 3GPP specifications. These are useful for gaining an overall understanding. Protocol stack development is the process of creating these protocols in code. To do this, you must study the official 3GPP specifications themselves, which you can download from the website.
Not necessarily C, depends where you are going to use this. If it is terminal testing / simulator likes the ones of rhode and schwarz, qualcomm, better off with C++. You need to implement the specs on system level, then it is harware teams job to do the RTL syntehsis and bring it at the hardware level.
As a stack level implementation, is more like software development, if you go below the stack at physical layer, then comes more of an engineering perspective, dealing most things at hardware level.
So be good with C++, a degree in communication systems, electrical engineering, CS focus in Communications etc should be the preferable choice and go through some book related to LTE
Check if you are looking for this
http://www.queryhome.com/27610/protocol-architecture-of-lte-network
Telecom protocols are usually designed using SDL translated from specifications approved by specification committees. The SDL is converted to ASN.1 scripts and loaded in to case tools. The tools generate c code for a specific platform and compiler. A protocol design house usually have a asn.1 stack of the technology that acts as simulator and asn.1 for new protocol stacks.
By "what" I mean, what all would be required to learn this development
Its a big thing to learn the whole LTE protocol stack development and companies have big teams dedicated for this. I will suggest to pick a layer/module and then study the specific of that layer to be able to do anything meaningful.
www.3GPP.org is the site that everyone refers but its very cumbersome.
You can try www.sharedtechnote.com which is written by an engineer and is a good source for Access Stratum aspect of protocol stack.
by "how" I would like to know how it can be done/learnt or how it defers from product/application development in industry.
If you want to see an open source implementation you can goto https://github.com/srsLTE/srsLTE to get an idea about protocol stack development.
As others have mentioned its a big topic to go after "LTE Stack Protocol Development". I will suggest to go and compare the LTE protocol stack with OSI model and then pick and choose one layer e.g. Radio Resource Control(RRC),Radio Link Control(RLC) or MAC layer and then study more about it. Look for 3GPP specification for the same e.g. I will google "3GPP spec RLC" and then go and download relevant spec. Complex to begin but after getting basics right you will be able to develop something meaningful.
Related
I'm wondering if there is a good resource for FORTH implementations on recent SOCs.
I'm mostly interested in bare metal versions, something that can sit net to RTOS on an ESP32 or RISC-V for instance (so gforth might not be ideal).
And particularly, I'm looking at least at a version that can do networking (e.g. via WIFI, ideally via a source network stack implementation, which in RTOS might not be too hard)
Sadly, it seems pretty hard to tickle useful info out of Google – it mostly seems to think I can't spell fourth. Many results I do find seem outdated, and or seem very commercial; and it feels wrong to pay licensing fees for a network stack in the age of micropython.
This Raspberry Pi JonesFORTH O/S looks pretty promising.
I wouldn't mind doing a bit of porting.
Even if your question could be interpreted as opinion-based and might be looking for resources only, I am going to provide two links to living and active maintained projects which might fit your requirements.
I'm wondering if there is a good resource for FORTH implementations on recent SOCs. I'm mostly interested in bare metal versions
You may have a look into
AmForth
... for the Atmel AVR8 Atmega micro controller family and some variants of the TI MSP430. The RISC-V CPU (32bit) is currently beeing worked on.
and
Mecrisp, Stellaris
an implementation of a standalone native code Forth for MSP430 microcontrollers
or Quintus
a rewrite of classic Mecrisp-Stellaris with almost the same look-and-feel for RISC-V architecture, RV32I, RV32IM or RV32IMC flavour, and it includes support for MIPS M4K cores. FPGAs are conquered by using FemtoRV32 softcores.
With both projects it is possible to achieve progress quite fast and easy depending what you try to achieve.
... can do networking (e.g. via WIFI, ideally via a source network stack implementation ... I wouldn't mind doing a bit of porting.
For a more detailed answer and more guidance this part would need more information and some clearance.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Can any one help me out to clear my doubts i am trying to implement an SIP application, I already have sip server setup and i have the username and password of my sip account.
Now I tried using PJSIP & SIPHON but somehow failed with lots of errors.
Then I tried with LinPhone and it worked fine.
Then copied the files from LinPhone project into my project and still working on it. (What else should I copy in my project to get going - i have copied the apple-darwin include & lib folder in my application)
I want to use G711(Both A and u) codec in the application and I can't find any header file's for that, please can any one suggest me how should I use G711 codec with the LinPhone Library in my Application?
Also can any one tell me that how many days it takes to cover up the SIP application without video functionality in it? (Audio Calls with GSM,Speex,G711 Codec's - only)
How many days will and Expert & Medium Level Developer will take to make app like this without any prior knowledge of any SIP app? (Any Rough idea according to you.)
Is there any other good open source library available to use easily to make an app like this?
Or any kind of a tutorial available? (Documentation of LinPhone is not upto the mark).
Am i going in the right direction?
Word of warning
This may sound like I'm trying to disuade you from persuing this endevor. Far from it, SIP is a fun protocol to work with (eventually) and it's very rewarding to see it all come together. You will enjoy a great deal of satisfaction at having gotten such a beast to work, and I wish you the best of luck in shaping it to your will! However, be prepared: SIP is a frustrating beast to work with.
The following timeline is based on my own experience, though I've shortened timelines somewhat due to there being two of you. Our dev cycle lasted nearly a year, but I was both the lead, and only programmer on the project, and that time includes all the work done on the UI, requirements coordination, planning, documentation, etc.
Week 1 & 2
SIP is a complex specification, with many extensions and peculiarities, especially relating to firewalls, forwarding, branching and joining. I would recommend you start looking up RFCs, and simply devote a good amount of time to reading the signalling specs, and any extensions you will need for your application, including at a minimum, the base specification, the SDP specification, and the ICE protocol specification.
That should occupy about a week if you're doing it right, and full time. For week 2, consider which extension specifications you'll need (presence indications, preconditions, conferencing, GRUU, etc) and spend the time to read those as well. Drill each other on them, it's a lot of information, and it's relatively complex in terms of how they all inter-relate to each other.
Break out the protocol analysers (Wireshark, etc) and see what the apps you have are doing on the wire. Having read the specs, you'll now be in a good position to understand why various SIP products have difficulty playing nice with each other, and, an idea of how to start working on your own app.
Week 3-6
Even with a decent toolkit, you will spend the better part of a month getting SIP to reliably do what you want it to in communicating signalling information, and writing the required infrastructure to respond to SIP signals. There are a crazy number of edge cases, and every pitfall you can imagine in concurrent processing is now magnified by the fact that you have three independent agents, some of whom will have very high latency, unreliable network connections, all trying to co-ordinate regarding the same transaction.
Don't take shortcuts, code, test, code more, look for faults and edge cases, and keep going. The RFCs help A LOT in understanding the problems you will run into, but some of it just has to be trudged through.
Week 7 & 8
Depending on the requirements for your application, just establishing the underlying connection between end-user agents will rightly occupy most of your effort to create a reliable product. You will, between the two of you, likely spend the next couple of weeks getting this part to work for the first time, and likely uncountable hours diagnosing edge conditions throughout the rest of the dev cycle of the app. Remember that there are edge cases here which require a media proxy, and a no-win edge case where the user is so badly firewalled that nothing can be done. Don't forget to handle them.
Week 9-11
At this point, your phones should (fairly) reliably connect to each other, depending on your experience and network knowledge, over fairly strict firewalls as well. The preconditions spec is very useful for decreasing perceived delay here, as you can hold off on ringing until the network layer has already connected. My experience will not inform the next layer (protocol) very well, as with Java, the media encoding and decoding was handed to me on a silver platter, aside from quicktime, which I had to do myself. I would chalk up a week or two for getting the protocols working nicely, and communicating protocol information reliably via SDP, but this may be a very optimistic estimate on my part.
Add another week if you've never worked with RTP/RTCP before, as while they're not complex per-say, properly responding to the feedback you get from RTCP can be challenging, and is somewhat of a dark art, though quite critical to ensuring optimal network utilisation and media quality.
Week 12+
Likely, at this point, you'll realise that one or another SIP product you want to be able to connect with, doesn't like your implementation, sometimes for reasons utterly inexplicable. If you need to support finicky products, you will spend the next few weeks to a month diagnosing why. If your product is proprietary, you probably don't care about this step, but it's also a way of double checking how badly you're mangling the spec. (We all do, so don't assume the test product you're using is correct either! Always double check!)
Additional
Bear in mind, the above is mainly intended as an estimate of how long it will take to get a well-written SIP/SDP/ICE based solution functioning, not the app using such infrastructure. UX is king in the iOS world, so make sure your app is compelling, and spend a LOT of time getting it right.
Even if
you use a library to make the coding easier, learn the underlying protocol! It will benefit you tremendously to understand why things work the way they do, and why the SIP universe is full of so many broken products.
I'm figuring that CORBA is considered a legacy technology that just refuses to die. That being said, I'm curious if there are any known standards out there that are preferred (and are also as platform independent.)
Thoughts? TIA!
Many organization are moving to WebServices and the open standards relating to them (HTTP, WS-*) as alternatives to Corba.
This article provides a comparison of the two technologies and offers some recommendations on when to use which.
If you really care about platform independence and protocol standardization - then the WS-* standards are something to look into.
There is now a state of the art modern CORBA implementation using C++11, TAOX11. This uses the new IDL to C++11 language mapping. For TAOX11 see the TAOX11 website. TAOX11 is supported on a wide range of platforms and compilers.
I have recently tried Google Protocol buffers, they seem rather similar to CORBA by design (some kind of IDL with compiler, binary compact messages, etc). It is probably one of the many possible successors.
Web services are good for the right tasks but creating and parsing messages needs more time and text based messages are more bulky than binary ones. REST API with JSON looks like a good solution where binary protocols do not fit well.
ICE from ZeroC aims to be a "better CORBA".
Unfortunately their licensing terms are crap (at least last time I checked with them), as they do not sell developer licenses but only (roughly) per-installation terms.
It is offered via GPL license too, if you can live with this.
I have some data that I need to share between multiple services on multiple machines. Stuffing the data into a database or shuffling it over http won't work in this situation and ideally the different pieces of software will need to communicate with each other directly (or through one central coordinator that can send and receive).
Is it recommended to create and implement a network protocol or use some tool to do the communication?
If I did go the route of creating a protocol myself, it wouldn't have to be very complex. Under 10 different message types, but it would have to be re-implemented in a few different languages for this project, and support unicode. I have read plenty (and done some) with handling sockets, but don't have much knowledge in handling a protocol I create. Are there any good resources on this?
There are also things like ICE and RPC that look intresting. The limit of my experience is using ICE and XMLRPC for a few days each. Is this the better route to go? If so what tools are out there?
Recently I've been using Google Protocol Buffers for encoding and shipping data between different machines running software written in different languages. It is quite easy to do, and takes away a lot of the hassle of designing a custom protocol.
Without knowing what technologies and platforms you are dealing with, it's difficult to give you a very specific answer - so I'll try to give you some general feedback.
If the system(s) you are wishing to connect span more than a single platform and/or technology you are probably better using an existing transport mechanism and protocol to maximize the chance your base platform will already have a library (or multiple) to interact over it. Also, integrating security and other features in a stack with known behaviors is more likely to be documented (with examples floating around). RPC (and ICE, though I've less familiarity with it) has some useful capabilities, but it also requires a lot of control over the environment and security can be convoluted (particularly if you are passing objects between different languages).
With regards to avoiding polling, this is a performance related issue; there are design patterns which can help you to handle such things - if you understand how you need the system to work (e.g. the observer pattern - kind of a dont-call-us-we'll-call-you approach). The network environment you are playing in will dictate which options are actually viable (e.g. a local LAN will have different considerations from something which runs over a WAN or the internet). Factors like firewall tunneling, VPN traversal, etc. should play part in your final selected technology profile.
The only other major consideration (that I can think of just now... ;-)) would be to consider the type of data you need to pass about. Is it just text, or do you need to stream binary objects? Would an encoding format (like XML or JSON or bJSON) do the trick? You mention "less than ten message types" as part of the question, but is that the only information which would ever need to be communicated by the system?
Either way, unless the overhead of existing protocols is unacceptable you're better of leveraging established work 99% of the time. Creativity is great - but commercial projects usually benefit from well-known behaviors, even if not the coolest or slickest (kind of the "as long as it works..." approach).
hth!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Do you find that corporate buzzwords or heavy management jargon gets in the way of software project communication? for example using words such as
Mainstreaming
Holistic
Contestability
Synergies
etc.
Would you rather see a initiative within the industry to put a stop to jargon such as this to help people communicate better and keep project communication in plain English? Is it even a problem? What are your thoughts/anecdotes?
I actually like buzzwords, when they are used in moderation.
They became buzzwords for a practical reason: Even though the concepts may be very complex and/or abstract, there is a consensus on the meaning. So with only one word, you can convey a whole lot of information to a large group of people. I see it as a form of encapsulation of information.
(Notice the use of the slightly outdated buzzword encapsulation?)
Of course, that is exactly the reason why many people start to abuse them: They only convey the general concept (i.e. why it's great to do FizzBuzz), and avoid discussing the messy details (i.e. why it won't work).
And since using a buzzword gives the impression that you are deeply familiar with the subject at hand, it can be used to silence others in the discussion.
Conclusion:
Buzzwords are ok - if they are used in the right way. If you want to improve your team communication, train them in the proper use of buzzwords.
I think some kind of industry-wide initiative would be impractical as jargon is in the eye of the beholder.
I think all you can do is make sure that you don't use buzzwords yourself even when communicating with people who do. For example, use the word "people" when talking to a Project Manager who refers to you and your colleagues as "resources".
The use of technical language can both help and hinder project team's progress, depending on appropriateness.
First it's necessary to point out that what is considered "too technical" depends purely on perspective. "Mainstreaming" is as much of a technical term, as SSD, CORBA and SOAP. Something that sounds as jargon nonsense to one person is actually a shortcut to communicate a complex concept for another.
Software development as a rule is cross-domain activity involving in addition to the software knowledge one or more technical user domains. It is a big mistake to assume that sales, marketing, management and banking (just to name a few fields often incorrectly considered "non-technical") haven’t developed and advanced their own complex body of knowledge, in other word — technology: sales technology, marketing technology, management technology and banking technology.
And it’s project manager’s responsibility to facilitate productive communication between representatives of different technical domains. Some suggestions:
Make handy a project dictionary that can be accessed and updated by everyone involved.
Ensure that common denominator language used for cross-domain documentation (i.e. functional specs).
Introduce domain specific terms only when necessary, but then always provide a brief explanation of the meaning (don’t “build from scratch” —leverage the wealth of online encyclopaedias by linking where possible).
Make sure that there is common understanding amongst the project team of the key terms.
Remember that what is considered “technical” depends purely on perspective and you need to facilitate communication in all directions, not just one-way (which is often from software developers to business users).
At the end the software will have to work in the realm of users and you have to make a judgement on how much the UI will rely on specific domain language (this is going to be a trade off between easiness-to-learn and usage-efficiency).
Technical jargon (ORM, TDD etc.) makes one's speech more precise. Corporate buzzwords (aka management jargon), on the other hand, are designed to be able to express vague ideas when full information is not available.
As such, management jargon serves its purpose pretty well, in the sense that it does allow managers to effectively communicate about thins they have very limited understanding of. That said, good manager knows when NOT use the jargon, such as when talking with developers, or with executives, both of whom hate bullshit.
Based on the above, the (Anti-)Buzzword Movement, should rather increase awareness of the proper usage and application of management jargon, and encourage proper information encapsulation only with appropriate auditory.
Personally, I think that the jargon should be used more. I see this occurring more and more and IT people want to simply hide behind the technical elements of the world and act like it is completely the business folks responsibility to speak more geeky.
I'll be honest, speaking more GEEK is not something that the business people can do and you should not want that to occur. Learn the jargon. Become one with the jargon. Own the jargon. Then the next time you are discussing things, you'll not be back pedaling.
Take ownership of the business terms and apply them to the technical side of things...
What's wrong with "holistic" or "synergy"? These are normal plain English words.
Every field has it's own jargon, and that must tell us something - people like having special words, phrases or assigning special meanings to existing words that are only relevant within their own field. I suspect if we went back to the pyramids, there'd be a full set of architectural and building phrases that your average Egyptian just wouldn't understand. So banning jargon just wont work, creating an FAQ and glossary normally do the trick.
BTW This must be a case of pots and kettles. Does anyone outside IT think phrases like - "...We'll use an ORM, and then WCF will talk over HTTPS, throw in a bit of AJAX and some clever CSS on the client and we're laughing ..."
Absolutely. Since managers only talk in general, and we as developers want to understand the precise meaning. I personally fall asleep trying to read abstract writing filled with buzzwords.
The worst being SOA. Neither academic folks nor managers understand it though both use it extensively.
I can't stand buzzwords. One person's "encapsulation" is another's Orwellian destruction of language. Buzwords appeal to the same people who like "decks" rather than memos. For something to act as a representation of many possible things [e.g. "leveraging resources" can mean pretty well anything from using double-sided printing options to drafting people for the Army] there is necessarily going to be a dilution of meaning. If a senior lawyer in my firm were to ask me to "leverage the resources, then run it up the flagpole to get the ducks in line", I'd know that he was tossing back the Johnny Walker at lunch.
Conversely, if I were to respond to a senior partner's memo request with emtpy catch phrases such as those above, I'd be fired on the spot for being an idiot - and rightly so. Too bad the rest of the white collar world isn't like that.
Grouchy Old-fashioned Gen X'r
I'm OK with buzzwords so long as all the stakeholders (see what I did there?) are clear on the shared meaning of each word/phrase.
In general I think that buzzwords are good when used for encapsulating ideas and concepts. it simplifies communication between people who understand the words. However, I draw the line when people use a buzzword when a perfectly normal word would do. I know someone that will say they were "On an Audio" when they mean phone calls or say "dialogging" instead of talking. It makes me want to hit them. Hard!