I am planning to design a simulator which mimics complete UE attachments and registration in 5G core network. Since N1 is a logical interface, how the NAS message is transmitted from the UE to RAN to AMF (At its core transfer protocol SCTP is used between RAN and AMF)? Any sample packet capture would also help.
Yes, you are right, SCTP protocol is used between AMF and gNB (RAN) just like in lte.
There is RRC protocol between UE and gNB.I do not have much knowledge in this area. But for registration this part is not important, and I think you can just send NAS as raw package to gNB.
After that, gNB put NAS-5G message (registration request in your case) from UE, to NGAP (N2) transport message, and sends it via SCTP.
Related
I'm working on a project that requires BLE Serial Profile.
I have successfully implemented it, but now I'm wondering what happens when server is sending data to the client, and client wants to send data back (while server is still sending). Is this handled on the low level with a queue or something similar?
Is there any risk that messages will get lost?
Thanks for any help.
Bluetooth provides the effect of full duplex transmission through the use of time division duplex (TDD). In principle transmission and reception do not happen at the same time. So in your case there is no risk of collision (loss) of data packets.
As you can see "Central" and "Peripheral" have a window of 625us during which they transmit.
For further details you can read "Timeslot" chapter of the base band specification in Core Bluetooth specification.
https://www.bluetooth.com/specifications/specs/core-specification-5-3/
I'm implementing a bacnet library to read and write some object instances.
But I don't understand, why with a PC and with an application like Yabe if I ask to a common controller to read more than 300 objects, the segmentation is supported, instead with a mobile phone and on the same request to the same controller the segmentation is not supported.
Both the PC and the smartphone are in the same network on Wifi.
So what is the problem/difference?
It is nothing to take with a PC or a mobile phone. Any IP compatible devices mobile phone, desktop, laptop, Arduino chips will work with BACnet.
Your problem is segmentation. You will have to handle the segmented messages coming from the Controller.
Every BACnet controller vendor specifies the MaxApduLength (i.e max length of data to be transferred within one UDP packet). The standard APDU length is 1476 bytes. So a BACnet controller cannot send the data more than the length of APDU specified within it.
Requesting 300 objects from a controller results definitely in a large APDU than the controller's limit. In this case Controller will send you segmented messages each with sequence number. You will have to handle this all segmented messages and combine them in one message then only you will get exact response. This is same with Yabe and other BACnet clients.
I have also written BACnet libraries for our mobile applications in Java and Swift 4.0 and both can read any number of objects from controller with segmentation support added. I have tested these with controllers having more than 400 objects.
Segmentation is used for APDUs (responses) that are too large to fit in one frame on the datalink. If both devices support segmentation, then great. If one of the device does not support segmentation, and the APDU does not fit, then "Segmentation not supported" error is issued. (and you have to then retry a smaller request).
I'm in somewhat of an odd situation here. I'm looking to send SMTP e-mails from a remote embedded system which is directly connected to an iridium modem into a local server. The current system sends files in chunks of data and I don't know exactly how this would work with e-mail. I was thinking of using mutt to send attachments (.wav or .jpeg files), but again I don't know if this works without direct internet access. If anyone has any idea if this is possible, please let me know.
Edit: I'm using RUDICS communication, not a SBD modem
Thanks
The Iridium Short Burst Data (SBD) service sends burst of less that 2Kb at a time and the revenue model for Iridium service might make sending audio and image data very expensive.
Nonetheless messages are converted by the Iridium network to be delivered in email format or over HTTP to a pre-configured address. The address to which data is sent is assigned to your Iridium service subscription, not stored or configurable by the sender. You can of course forward the received data to any desired destination.
You can get a direct Internet connection using an Iridium phone (https://www.iridium.com/services/details/iridium-direct-internet); but that is an expensive and bulky solution.
It's possible but somewhat complex. You would need to setup a PPP connection with the modem and then email would be able to flow across the serial line to the other server.
I'm new for this technology, can somebody help me to know about some doubt?
Q-1. What is the size of CoAP packet?
(I know there is 4 byte fixed header, but what is the maximum size limit including header, option and payload?)
Q-2. Is there any concept for Keep Alive like MQTT?
(It works on UDP for how much time it keeps open the connection, is there any default time or it keeps open every time when we send packet?)
Q-3. Can we use CoAP with TCP?
(Main problem with it CoAP is it works on UDP, is there any concept like MQTT QoS? Let's say a sensor publishes some data every one second, if subscriber goes offline, is there any surety in CoAP that subscriber will get all the data when it come online?)
Q-4. What is the duration of connection?
(CoAP supports publish/subscribe architecture, may be it needs connection open all the time, is it possible with CoAP whether it is based on UDP.)
Q-5. How does it discover the resources?
(I have one gateway and 5 sensors, how will these sensors connect to the gateway? Will the gateway find these sensors? Or will sensors find the gateway?)
Q-5. How does sensor register with gateway?
Please help me, I really need answer. I'm all new for these kind of things and suggest me something for implementation point of view.
Thanks.
It Depends:
Core CoAP messages must be small enough to fit into their link-layer packets (~ 64 KiB for UDP) but, in any case the RFC states that:
it SHOULD fit within a single IP packet to avoid IP fragmentation (MTU of 1280 for IPv6). If nothing is known about the size of the headers, good upper bounds are 1152 bytes for the message size and 1024 bytes for the payload size;
or less to avoid adaptation layer fragmentation (60-80 bytes for 6LoWPAN networks);
if you need to transfer larger payloads, this IETF draft extends core CoAP with new options for transferring multiple blocks of information from a resource representation in multiple request-response pair (so you can transfer more than 64KiB per message).
I never used MQTT, in any case CoAP is connectionless, requests and responses are exchanged asynchronously over UDP or DTLS. I suppose that you are looking for the observe functionality: it enables CoAP clients to "subscribe" to resources and servers to send updates to subscribed clients over a period of time.
There is an IETF draft describing CoAP over TCP, but I don't know how it interacts with the observe functionality: usually It follows a best-effort approach, it just happens that the client is considered no longer interested in the resource and is removed by the server from the list of observers.
The observe stops when the server thinks that the client is no longer interested in the resource or when the client ask to unsubscribe from the resource.
There is a well-known relative URI "/.well-known/core". It is defined as a default entry point for requesting the list of links about resources hosted by a server. Here for more infos.
Look at 5.
I am analyzing the traffic beacons generate using tshark and iptraf. I know they are mainly used to determine the proximity of a device and like any other network device the traffic generated by them must be having a header and payload information in it.
What is best way to find out the payload information though header info can be identified as to where packet is being sent etc , but how we can classify the payload and what information it contains in a beacon signal , is it the same like any other web traffic sent and receive on a network or is it different since they make use of Bluetooth ?
Any pointers regarding would be useful .
Bluetooth LE beacon transmissions are much simpler than the HTTP protocol. They are transmit only and have no real headers, although there are short segments within the transmissions called PDUs that have a similar purpose.
To see an example of a beacon transmission, see my answer here:
What is the iBeacon Bluetooth Profile