OSI model real use in Embedded System Development - Page 1
Forum section: electronics / general

author: BlogRahul
author_rank: Regular Contributor
timestamp: December 26, 2021, 09:00:29 am
content: I have read the OSI model in the book but I really don't understand what's the real use of OSI modelLet take one example of my understanding, I had one 32 microcontroller, Then I connected one WiFi and Bluetooth chip with a microcontroller. after that I programmed a microcontroller. Now the whole system can communicate with other WiFi and Bluetooth devicesLet say I have connected the temperature sensor to my system and programmed the system in such a way that temperature data is being sent to my personal computer wirelesslyCan anyone explain how OSI layers use in my example?

author: ataradov
author_rank: Super Contributor
timestamp: December 26, 2021, 09:16:37 am
content: All the networking protocols that make Wi-Fi and BT works are layered, just as described in the books. That being said, the value of having "a model" is questionable. Everything over transport layer does not matter, and transport layer and below are just an obvious way to implement things. So there is no real value to having a model. This is just giving it more attention than it deserves.

author: BlogRahul
author_rank: Regular Contributor
timestamp: December 26, 2021, 10:20:19 am
content: Quote from: ataradov on December 26, 2021, 09:16:37 amPlease take my exampleQuoteTemperature Data is being transmitted to my PC over which protocol TCP/IP or WiFi?

author: PKTKS
author_rank: Super Contributor
timestamp: December 26, 2021, 11:57:49 am
content: Quote from: BlogRahul on December 26, 2021, 10:20:19 amYou are really confused...Climb the necessary steps to gather your answer...- WiFi is a group of 802.11 protocolshttps://en.wikipedia.org/wiki/WiFi- Specifically ( IEEE 802.11 )https://en.wikipedia.org/wiki/IEEE_802- This protocol belongs to OSI layer 2https://en.wikipedia.org/wiki/Data_link_layerso WiFiregardless any considerationis INSIDE OSI LAYER 2 implementing 802 protocolside to side of the communication networkOSI works node to node - layer to layerlike it or not you are necessary inside OSI layer 2Paul

author: tggzzz
author_rank: Super Contributor
timestamp: December 26, 2021, 12:52:34 pm
content: WiFi specifies more than that; seehttps://en.wikipedia.org/wiki/Wi-Fi#Versions_and_generationsYou will note that it includes several PHY layers.The way to understand layering is to start at the bottom and see what a layer allows. Crudely, PHY allows one node to send bits to other nodes, MAC control the sending of frames, then higher layers allow packets, routed packets, reliably received packets, series of packets necessary for a session, etc.Sometimes negligible functionality is required in a layer.The common TCP/IP comms do not fit neatly into the OSI model, rendering OSI theoretical model rather than on that is directly seen in the wild.

author: BlogRahul
author_rank: Regular Contributor
timestamp: December 27, 2021, 12:45:43 pm
content: The problem with me is that I don't understand the difference between Wifi and TCP/IP. Both are network protocols. Both share data between two deviceWhen the TCP/IP protocol will be used in any project?When the Wifi protocol will be used in any project?Which protocol is being used in my temperature example TCP/IP or Wifi protocol?

author: Siwastaja
author_rank: Super Contributor
timestamp: December 27, 2021, 01:03:20 pm
content: Quote from: BlogRahul on December 26, 2021, 09:00:29 amThis is easy to answer - there is none.Remember that the "OSI model" talk is made up bullshit. I was taught about this in university classes as well. Luckily I knew some people who were actually running the Internet, so had a few pretty helpful discussions.OSI is not a generic model or way of thinking, OSI model is the name of anactualprotocol stack that failed to succeed because TCP/IP stack won, and is not used. It's a failed standardization attempt from early 1980's, which academics love.It's used in academic teaching world as a reference example, pretty much like MIPS CPU architecture is used in computer engineering classes. Sadly, lecturers "forget" to mention it's anexampleprotocol stack, not name of a generic concept, resulting in a lot of misunderstanding.Youcan'tmap current real-world protocols into the 7 layers 1:1.On the other hand, understanding that protocols "add up", forming layers, is highly beneficial. But this is just almost too simple to be true. It's like once you open up the wrapping of your christmas presents, you find another package inside. After a few unboxings, you finally have your gadget or whatever.Similarly, layering protocols just means that inside thepayloadfield of a lower level packet, say Ethernet frame, there is content that can be again parsed as the next higher-up protocol in the stack.Now as OSI from 1984 in itself is totally meaningless and does not exist in real life, it makes no sense to dedicate any time for technical details. Actual TCP/IP stacks are very similar though, so the concept is fine. But why not teach the actual internet protocol suite in university classes instead, is beyond me.WiFi is just a marketing name, and not a name of any protocol. In any case, it describeslowerlevel than TCP/IP - in "OSI" terms, Physical layer + Data link layer. All in all, this means that IP packets ride on the top of whatever WiFi protocol. Then inside the IP packets, there is a TCP packet. Inside that TCP packet, there might be data formed in HTTP standard. And so you have your web page.Now trying to follow "OSI model" strictly has the problem that sometimes, a single protocol spans across many layers, because layer divisions are arbitrarily made up, which maybe made sense in committee coffee room in early 1980's, but doesn't match with how it actually ended up. For example, division between Physical and Data link layers is pretty iffy. In a similar way, all three top layers are quite muddy.In real world, it's easy to understand how HTTP data rides inside TCP packets, that go inside IP packets, which are inside Ethernet frames, transmitted using Ethernet electrical specifications. But if you have to assign all 7 layers of OSI there exactly, it's not helpful. For example, when you actually learn to use TCP/IP, you'll notice how the TCP protocol basically defines asession. Yet TCP isn't in "Session layer". And indeed, if you dig deep enough, you can see small remarks like herehttps://en.wikipedia.org/wiki/Session_layer#Comparison_with_TCP/IP_model: good point, Session layerdoes not exist at all in reality!Finally, if you want to learn what's really going on, instead of a failed project of 1980's, look at this:https://en.wikipedia.org/wiki/Internet_protocol_suite

author: rstofer
author_rank: Super Contributor
timestamp: December 27, 2021, 03:20:49 pm
content: This page may helphttps://www.linkedin.com/pulse/what-tcpip-stack-phillip-zitoYou can't really discuss similarities between WiFi and TCP/IP because TCP/IP lives on top of WiFi or Ethernet. In fact, there is a serial (as in USART) IP protocol named SLIP. It was fairly common in the early days and could still be useful for small uCs.https://en.wikipedia.org/wiki/Serial_Line_Internet_ProtocolThere is layer information all over the Internet. Here's a page by Lantronix:https://www.lantronix.com/resources/networking-tutorials/ethernet-tutorial-networking-basics/

author: T3sl4co1l
author_rank: Super Contributor
timestamp: December 27, 2021, 05:14:54 pm
content: It makes sense in historical context, where protocols included all kinds: serial ports between terminals, coax cables, twisted pairs, big parallel buses, even early fiber optics (which did a whopping like ~10Mbps back in the day?). And not only that, but integration was rare; many of these interfaces were built from whole cloth, entire panels of logic chips, perhaps! Ethernet wasn't even a well defined standard at first; it could go on coax ("vampire" tap!), twisted pair(s), parallel (AUI), etc. Eventually, industry filtered out the most promising standards, which crystallized into the common set we use today (e.g. 10/100/etc. BASE-T on 2 or 4 twisted pairs, and so on; and everything that makes up WiFi, BT, etc. respectively). We still use Ethernet's MII today (the interface upstream of the PHY, which could be used with any of these physical media, given a suitable PHY to drive them), but it's as often internal to the chip (integrated MAC + PHY) as it is just some forgotten logic signals that, you wire them up, do the magic incantation, and it Just Works(TM), and is never connectorized these days.These days, you almost always want just some plain stock TCP/IP interface, and its stackiness isn't really visible; it might still be constructed that way internally, or it might be tightly integrated. There might be varying degrees of hardware implementation (e.g. W5500), or supplementary CPU cores (which may or may not be user-accessible!) driving it. The trick then is, if you find you do need something other than TCP, you'll need access to the one level down (or deeper!), and then you can implement whatever UDP/FTP/etc. you're looking for; some of these may be too tightly integrated to provide that. (So, check the datasheet carefully, see that it provides the feature set you need.)Tim

author: nctnico
author_rank: Super Contributor
timestamp: December 27, 2021, 05:30:06 pm
content: Quote from: BlogRahul on December 26, 2021, 09:00:29 amThe OSI model is a good reference model to categorise & label layers in a protocol stack so everybody speaks the same language / knows what you mean if you talk about 'layer 2'.But it only applies to situations where a protocol uses hardware directly (like IP over ethernet or ISDN). With Wifi and Bluetooth things are a bit more complex because the latter allow to encapsulate the data. In case of ethernet, Wifi is used as a transmission layer but Wifi is an entire protocol in itself.Another thing to keep in mind is that the OSI model lacks a vertical layer along all layer which deals with error handling & recovery. If you implement a communication system using the pure OSI model, you'll find out soon enough.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 27, 2021, 05:37:59 pm
content: And with that said (yes the model itself is questionable these days, yes it's not perfect, yes it doesn't cover all cases...), sure it's still a plus to know what the basics are. Just for your culture and if you ever read about that somewhere, or has to attend a discussion with that being mentioned. Just as part of your tech culture.But as your very question showed - if you're basically only going to use ready-made components for accessing standard communication devices and protocols - you certainly don't need to bother, as everything is already implemented for you. You will, in most cases, only be in the "application" layer.And if you're going lower-level (which, from your question, was likely not the case at all), then knowing the OSI model will not necessarily bring much to the table. Again, it's nice to know it mostly for when others are talking about it, so you approximately know what they're talking about.

author: TomS_
author_rank: Frequent Contributor
timestamp: December 29, 2021, 10:01:21 am
content: In your simple example application, you are utilising everything from layer 1 through to layer 7, just that the lines may be slightly blurred in places, and most of it you don't need to think about or don't have a choice about.Starting from the bottom up (simplified).Layer 1 is the physical layer, it's mostly what it sounds like. In your example this is the air and the radio waves that travel through them. In other scenarios it may be fibre or copper cables.Layer 2 is the data link layer. This is where things like Ethernet and MAC addresses come into play to move frames between devices. This can be end-device to end-device if they are directly connected, or via one or more switches. WiFi also lives here as a means of moving data between devices, such as via a base station to another WiFi device, or onto a wired Ethernet network. At layer 2, devices must be on the same network segment to communicate!Layer 3 is the network layer. This is where IP lives as a protocol. IP allows you to logically address a packet to a remote device which may or may not be on the same network segment. When the two devices are not on the same network segment, the packet will be moved via layer 2 to a router which will then transmit the packet onto another layer 2 segment to get it closer to it's destination. Lather, rinse, repeat until it gets to where it's going.Layer 4 is the transport layer. Protocols like TCP and UDP live here, and are simply different ways of encapsulating some data for either reliable or unreliable data transfer. If encapsulated in TCP, additional controls come into play to ensure that the data arrived at its destination (acks and retransmits). UDP just sends the data out and hopes for the best. TCP/IP is just a way of describing those two protocols being used together to achieve end to end communication.Layer 5 is the session layer, and is where you are opening your connection to the remote device and piping your transmitted data into, and receiving data from. You're specifying (typically these days) the protocol type (TCP or UDP), port numbers (HTTP etc), and IP address of the remote device you want to communicate with.Layers 6 (presentation layer) and 7 (application layer) are where things may become a bit blurred in the embedded world IMO.The presentation layer is typically what you would associate with stuff like JPEG images, or HTML for webpages, or JSON/XML/etc for APIs - it describes the data that is being transmitted.The application layer is things like a web browser that understand those data formats and can translate and combine them to show a web page for example.In embedded, 6 and 7 could appear to become merged somewhat, e.g. by having a task that reads an ADC and then prepares those readings to be sent off to the PC via layer 5 (maybe just transmitting raw binary data for example). But they are both fundamentally there, just that your task and the receiving app on the PC are now the application layer, and custom data format has essentially become it's own new presentation layer.tldrSo I guess in summary, you're using TCP/IP to encapsulate your data and address it to another device, and that is being transmitted over WiFi to physically get it there. But you only get to choose TCP/IP as the means to transmit your data when you open your connection at layer 5, and lower layers in the stack then choose WiFi. If you had multiple interfaces like WiFi and wired Ethernet, something like layer 3 would choose which of those interfaces to send the packet out of based on the routing table for example.That is basically the premise of the OSI model - break the process of moving data into layers that can theoretically be swapped and changed, e.g. (in a purely IP networking sense) Ethernet at layer 2 can be swapped out for something like token ring without layer 3 or above needing to care. Layer 1 can be any medium that can then transmit/receive what ever data layer 2 requires, including printed sheets of paper that get scanned in at the other side. I'm pretty sure someone even implemented layer 2 over email and a mailing list at one point... And all the while, your browser keeps on displaying web pages.tldrSo you dont "use the OSI model" per se, you implement a layer (or layers) of it and interact with the adjacent layers to complete the picture. If your microcontroller has WiFi built in, then it and its libraries are taking care of everything up to and including layer 5, leaving you to worry about the data, and what uses the data.

author: hans
author_rank: Super Contributor
timestamp: December 29, 2021, 10:41:47 pm
content: Personally I think the lines become blurred for any layer in embedded because of optimisations and low-overhead implementations, especially beyond layer 4. For example, "Remote DMA" on desktop PCs is a completely new feature, as it allows for zero-copy networking for 100Gbps network cards. However, in an embedded system, it is completely trivial to do this.. and I wouldn't be amazed if tons of devices were made like this to achieve high throughput data rates from a relatively slow CPU. For example, an application may stream ADC data with DMA straight into an ethernet frame buffer with prepared UDP headers, and when the DMA transfer is done, the application only needs to press the send button of the IP stack.Doing this for TCP is, obviously, a bit more complex.. On a side note to TCP and low-level performance hacks.. , that is (or was) heavily exploited in high speed stock trading. For example, a purchase order may be sent to the broker.. but it just so happens that a particular TCP data packet was lost (it was dropped on purpose). By making use of TCP retransmission windows, it is possible to send the final bit of information (e.g. which share and quantity to purchase) to complete the transaction. This eliminates the TCP SYN/ACK handshake (=3 frames) and transmission of other data (more bits on the wire), and so reduced latency, so you're certain to be the first to trade.. Now for the financial system, I think these tricks were banned... but purely from an engineering perspective, it's bloody ridiculous and brilliant at the same time.Back to OSI: I think the model is also flawed / outdated for any modern networking applications (note: not in "Ethernet" per se).For example, the model has many parallels to the classical waterfall V model, which we know is rarely practiced perfectly.How would the OSI model represent handshakes and feedback between layers and/or clients? E.g. many networking devices do some kind of handshake on the modulation standard, OFDM, subcarriers, etc. Some devices may also perform transmit a short PRBS pattern/pilot tone for BER measurements, which the "receiver" communicates back to establish optimal transmission parameters for the node-to-node link. These kind of algorithms really blur the lines between layers 1 and 3, in my opinion. E.g. in a mesh network where layer 3 may hold neighbor node data, it must also be able to interceptbadframe data on layer 1 and 2, to then decide on new feedback packets to send.And then like nctnico said.. error handling, timeouts, etc.Basically the OSI model is only as good as seeing how data is packaged in a happy path engineering mindset, but in no way how the protocols and systems actually run.

author: westfw
author_rank: Super Contributor
timestamp: December 30, 2021, 06:10:50 am
content: QuoteProbably the important part of the OSI Layering Model WRT your example is that in theory, your "temperature reporting" application should be able to have protocols other than BT or WiFi "substituted" underneath without you noticing. "BT or WiFi" is perhaps interesting as an example, because they are quite different protocols. WiFi is just another IP network, so all the IP/TCP protocols would be usable, and you could put in Ethernet or ISDN or CATV instead of WiFi and never notice. Bluetooth decided to do their own thing, for reasons I don't fully understand (and find annoying), so ... it's not as interchangeable with other things as might be desirable. (Ultra-low power might have had something to do with it. NIH Syndrome perhaps more.) (And OMG - you should have seen the early stuff that Cellular companies were proposing for data networking. They "didn't get it." (I don't know whether they got better; I stopped paying attention.))QuoteMeh. The "OSI Model" is NOT the same as the deservedly ill-fated OSI protocol stack.Layers 1-4 cover 10base2, Ethernet, IP and TCP/UDP.Layer 7 is the application doing whatever it had in mind to do with the data.Layers 5 and 6 are fuzzier, because they tend to more application-dependent. I think at the time that the model was first proposed, they envisioned fewer types of applications.Layer 5 (Session) handles data differences. Endianness of multi-byte numbers, maybe standards for floating point formats. If you have something a Remote Procedure Call protocol, or Network File System, this is obviously important. ASN.1 and (Sun?) XDR are probably reasonable examples of session layers.Layer 6 (Presentation) is higher-level data differences, I guess. EBCDIC vs ASCII, line-ending conventions, stuff like that. Maybe it includes things like HTML, JSON, and XML.A lot of the protocols used on the Internet essentially finesse layer 5 an 6 by communicating in what is essentially human-readable ascii text. SMTP, FTP, HTTP, POP, IMAP... all based on text commands. Maybe the "data" transmitted is some higher-level representation (MIME, HTML) but ... text. Numbers left to right decimal digits, etc.(FTP MIGHT be a good example of a protocol with some of the extra layers. There were commands to transmit text files (possibly with translation), paged files (with holes), and presumably other formats as well.)And of course in practice it is not very good for performance to have strictly distinct layers, so "violations" of layering happen all the time (IP Header compression is probably a good example.)On the third hand, "based on the OSI 7-layer networking model" has also become essentially a meaningless marketing term, sort of like "inspired by the PDP11 instruction set", or "RISC."Everyone knows that those are "good things", and will grasp at any straws they think they see to fit their product into the "good thing" category. (Sigh.)

author: bson
author_rank: Unknown
timestamp: January 03, 2022, 02:19:36 pm
content: OSI refers to protocols and communications, not APIs or implementation layers.Consider a web app.Layer 6 is the application layer. This is things like REST endpoints, JSON payloads, static asset URLs, and so on. It's application-specific.Layer 5 is the session layer. In a web app, it's HTTP. (In VXI-11 it's SunRPC.) This is not application-specific, but it sits on top of the transport layer.In other uses, HTTP might be layer 6 and there is no layer 5.

author: Siwastaja
author_rank: Super Contributor
timestamp: January 03, 2022, 06:42:43 pm
content: Quote from: bson on January 03, 2022, 02:19:36 pmSorry but nothing in this reply is true at all. Maybe do even a quick check on Wikipedia what OSI is and how the layers are defined.https://en.wikipedia.org/wiki/OSI_modelAnd yes, it'san actual standard, you can't just redefine it on a whim.But such reply is very typical. Because OSI model doesn't exist in reality and is useless, everybody uses the name of the model, name of the layers and name of the protocols completely arbitrarily based on how they happen to feel. But it isn't OSI model then. This is some bson model. Which isn't wrong, just don't call it OSI model. (In general, it would be more fruitful to use actual Internet protocol stack as an example, than using made-up arbitrary examples, but this is just my opinion. Made-up examples sometimes work, when you remember to tell everybody they are made-up examples.)The idea that HTTP would be "session layer" just shows you have no idea what session layer in OSI means. I don't blame you, because in the actual internet stack, session layer doesn't exist separately. But it's far from HTTP; it's actually within TCP - completely different level.

author: nctnico
author_rank: Super Contributor
timestamp: January 03, 2022, 08:01:38 pm
content: No. You can stack several communication systems on top of eachother where a whole communication system can become a layer (or a few layers) for the stack that is higher up in the hierarchy.For a browser HTTP is the application layer but for a REST or JSON API it becomes the session layer.

author: tggzzz
author_rank: Super Contributor
timestamp: January 03, 2022, 08:09:18 pm
content: Quote from: nctnico on January 03, 2022, 08:01:38 pmIf you look at a lot of modern server-side software, there are layers upon layers - sometimes even alternating synchronous an asynchronous!

author: westfw
author_rank: Super Contributor
timestamp: January 03, 2022, 11:37:44 pm
content: QuoteIt's a standardmodel.You can get pretty creative describing how something "conforms" to a standard model. (and people have.)And let's be honest here. At the time it was first mentioned (~1977, according to the WP article) the popular layers in existence were rs232, hdlc, lapb, and x.25, and they were trying to figure out how to implement services other than x.3/x.28 (PAD remote terminal access.) In the 7 years (!!) that they dicked around refining the basic model idea into something publishable as astandard, the neworking world sort-of passed them by (TCP/IP transition occurred, and LANs came into existence. Of the dozen or so LAN-oriented protocols of the era, none of them used X.25, and performance became more of an issue that strict conformance to a model. So the somewhat useful basic concept gets a nod, but the details are fuzzy. (I think I lied. I think there was a spec for X.25 over ethernet...)You can read the actual standard here:https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.200-199407-I!!PDF-E&type=itemsLike many CCITT specs, it is ... obtuse.