Can someone tell me about the difference between GY and RO interfaces used by diameter protocol ???
As per my understanding both of this interfaces looks pretty similar and the AVP's used too.
But still i understand that there is a difference..
Ro is a 3GPP reference point that describes the connection to the OCS from another functional component. It is a general term that covers multiple connecting components such as GGSN, P-GW, WLAN, IMS AS, MBMS server, etc.
Gy is an specific instance of the Ro reference point that connects a charging component from the packet-switched domain (PS domain) i.e. PCEF within a GGSN or P-GW to the OCS
For more details
There are different 3GPP specification for each of the interfaces.
You can read the differences and see the specifications here:
http://www.ietf.org/mail-archive/web/dime/current/msg05723.html
Related
In bits/socket.h of Linux systems, the address families macros are defined in terms of protocol families macros. there is a one-to-one correspondence among them with the form of
#define AF_something PF_something
Since the one-to-to mapping between the AF macros and the PF macros, they seem like unnecessary duplications.
My question is: is there a reason for this?
The original idea was to have address and protocol families independent. An address can potentially be used in various protocols. Authors expected that for example IPv4 address can be used by another hypothetical protocol different than IP. And vice versa - independent families are prepared to use a new kind of addresses in IP protocol.
So the only reason is that author of the socket API wanted to be future proof. As far as I know there is still one to one mapping between PF and AF.
It is a good habit to follow the original idea. That means have independent constant and use PF constants when working with protocol for example creating socket: s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) and use AF constant when working with addresses for example sa.sin_family = AF_INET.
Is there a way to use hirarchical blocks in redhawk?
For example, say I want to make a digital modulator that is a composition of filters, upsamplers, etc, and I want to use it as a single block in a waveform project, that has other hierarchical components as well. How would I combine the already made filter and upsampler blocks into the digital modulator block using redhawk?
You currently cannot create waveforms of waveforms. A waveform can however have external ports, and external properties allowing you to chain waveforms together dynamically and treat it similar to a component from a programmatic perspective. For example in the example below I launch two waveforms on the domain and connect the two, these waveforms are the examples that come bundled with REDHAWK and have external ports and properties.
>>> from ossie.utils import redhawk
>>> dom = redhawk.attach()
>>> wf1 = dom.createApplication('/waveforms/rh/FM_mono_demo/FM_mono_demo.sad.xml')
>>> wf2 = dom.createApplication('/waveforms/rh/FM_mono_demo/FM_mono_demo.sad.xml')
>>> wf1.connect(wf2)
There isn't a construct for a component of components (other than a waveform). As of the REDHAWK 2.1 beta release there is a 'shared address' construct that allows you to do something similar to what you seem to be asking for. The 'shared address' BULKIO pattern was specifically developed to create high-speed connections between components and reduce the processing load caused by IO. Take a look at https://github.com/RedhawkSDR/core-framework/tree/develop-2.1/docs/shared-address and see if this is what you are looking for. It will allow you to launch 'N' components built according to the shared address pattern into a single component host and still retain each individual components property interfaces etc.
If you are more specific about why you want to use a hierarchical block, a more targeted answer may be possible.
Is it possible to search for all iBeacons which are nearby? I know it's possible to search iBeacons by UUID. But i want to find all iBeacons nearby.
An iBeacon is a region, and has as defining property the UUID. Therefore, you can only search for the ones matching a UUID.
After you find one or more with a specific UUID, you can figure out which is closest using the delegate callbacks, where the beacons are stored in an array ordered by distance.
There is great sample code on this and also a pretty detailed WWDC video session: "What's new in Core Location"
iBeacons are higher-level constructs than regular BLE peripherals. From what can be determined from the Apple docs, beacons are tied to their service UUID. i.e., a family of beacons is a "region" and a you go into and out of a region based on the range and visibility of a beacon to YOU, not the other way around. Unfortunately Apple has used the term region, which most of us probably associate with MapKit, so this is adding to the general confusion
Here's the bad news: You can only scan for ProximityUUIDs that you know, there is no "wildcard" proximityUUID. Additionally, CLBeacons don't expose the much in the way of lower level CoreBluetooth guts so if you want to find all beacons that happen to be near you, you'll have to use CoreBluetooth, scan for peripherals, then look though the returned peripheries and query each one them to find beacons. Of course Apple has neither registered (with the Bluetooth SIG) or (yet) published the iBeacon characteristics so, you'll need a BT sniffer to reverse engineer what constitutes an iBeacon from any other BLE device.
each APP would use it's own specific UUID, using the "major" and "minor" integer values to differentiate between beacons.
for example, the UUID would be associated with a chain of shops, major would identify the shop, and minor the aisle, or even a group of products.
scanning for unknown UUID's would not be very useful, as your app would not know what to do with the information.
the UUID is generated once and for all, using the "uuidgen" command in the terminal.
sadly there is no protocol to actually communicate with beacons, hence there is no standard to get the location of a beacon, or any other useful info.
it would have been so much better if we could open a connection to a beacon, usually the closest one, and obtain additional data from it, without having to be on the same WIFI network.
you either have to use bonjour to communicate with the device over WIFI, or use the major and minor id to obtain data from a webservice of some kind.
Unfortunately you cannot at this time search for an arbitrary iBeacon without first knowing the proximityUUID value. I've tried writing directly to COREBluetooth and, although you can discover and connect to transmitting beacons in your area, what you get back is jibberish with no relation to the BLE UUID. So you can't even confirm that the peripheral you have connected to is in fact an iBeacon.
This does not appear to be a limitation of the BLE spec, rather it is a limitation that has been imposed by Apple. It also appears that this limitation does not exist for the Android platform.
Until this gap is closed, Android will have a significant advantage over iOS in this area.
I disagree with previous comments that scanning for UUIDs would be useless. On the contrary, if you knew the beacon UUID, you could create a map of beacon/location/subject in the cloud and use it to navigate (assuming the beacon was fixed) using a web service. You could crowd-source the data so that eventually a very rich database of beacon UUID/location pairs would be available to all who wanted to write location apps. Perhaps this is why Apple is hiding the info; they may be holding this back for their own purposes.
According to Radius Networks (authors of the AltBeacon spec and the android-beacon-library it's not possible to identify a beacon using CoreBluetooth
I need to find out information that should be kept in the TCP transmission control block (TCB), specifically I need to find out what sequence numbers are used for any particular session.
I have posted to other forums, looked through the procfs, searched Google, sent myself links from lmgtfy (dot) com :) No luck.
If there is no tool or hints in the procfs, would it be possible to somehow find out where this sort of information exists in memory and gather it from there such as using to dd to copy /dev/mem?
Thanks for any help on this in advance!!!!!
Well, I guess you first need to know what sequence number is and why it's been used, then you can look at particular implementation of sequence number generation.
Sequence numbers are 32 bit field and it's been used to mark every packet uniquely as if they can be acknowledged. And, being acknowledged
is important and it's an important feature of tcp for maintaining connection reliability. A full details could be found at the TCP rfc (http://www.ietf.org/rfc/rfc793.txt - section 3.3).
Now if you need to find out how Linux does it, you need to look at net/ipv4/tcp_ipv4.c::tcp_v4_init_sequence() this is used for generating ISN (Initial Sequence Number) whenever a new connection to be established and how latter sequence numbers are generated that's explained at rfc. So, look at the implementation of tcp_v4_init_sequence() and rfc, that will help you to understand uses and implemetation of sequence number usefully. Hope this will help!
I have some questions regarding IP verification.
Suppose if a particular design/functionality from an IP specification is missed both in the RTL and the verification plan (Coverage points), how would you identify this bug?
Since it hasn't been implemented in RTL(missed from SPEC), we cannot identify from code coverage.
Please throw some light on this.
Thanks
Someone should be comparing the verification plan against the top-level IP specification. For each point in the spec, the question "how do we show we met this requirement?" needs a good answer.
(If the feature in question is not in there, then the top-level spec needs fixing!)
You could create a feature list and write your tests against that.
The design and testplan reviews generally involve the comparison of the IP specification to said designs and testplans. The IP spec writer is usually present, as well, and can identify points in the spec that are not covered.