I was reading through LTE specifications in order to understand the number of bearers that could be created per UE.
Spec 23.203 - Table 6.1.7: Standardized QCI characteristics, defines 9 values for QoS(Quality of Service) based on performance characteristics of IP packets while according to Spec 24.007 - Table 11.5: EPS bearer identity, E-RAB IDs 5-15(11 bearer IDs) are usable.
I am unable to comprehend whether the number of bearers can be 9 or 11?
Thanks!
It is possible for 2 EPS bearers to have to the same QCI. For example, they could be flowing to different PGWs, but have the same QCI. Hence based on the number of identifiers available, the answer is 11.
QCI 1 to 9 are pre-defined settings and given by 3GPP for every operator and network vendors. This allows for interoperability among vendors.
However, operators can create their own QCI from 10 to 255 with their own customized settings for a particular service (like maximum allowed delay, priority, GBR or Non-GBR, etc.
It's worth noting that is very unlikely that a mobile will use that number of bearers at the same time. Typically you have just one (QCI 9) for pretty much everything you do (including Skype, WhatsApp call or streaming).
If on the top of that you also have voice over LTE, then you get QCI 1 while you're in a call and QCI 5 for IMS signaling.
Cheers
LTE QOS de nes priorities for certain customers or services during congestion. In LTE Broadband Network QoS is implemented between CPE and PDN Gateway and is applied to a set of bearers. 'Bearer' is basically a virtual concept and is a set of network con guration to provide special treatment to set of tra c e.g. VoIP packets are prioritized by network compared to web browser tra c. In LTE, QoS is applied on Radio bearer, S1 bearer and S5/S8 bearer, collectively called as EPS bearer as shown in gure below
for more enter link description here
Related
I am new to sipp and network concepts i got a contact header
"Fin Tax" <sip:b2fdfc58-b7f2-a482-572c-8dbc1aae24#10.195.1.41:5060>;+
"ip.instance="urn:uuid:00000000-0000-0000-0000-34db8dc64>";+
u.sip!devicename="ATA34DBFD8DC64"4DBFD18DC64";+u.sip!model.cc.co.com="681"
Can you explain this contact paramerter i know the first part uri but what are next parameters
First parameter is +sip.instance (the double quote after + in the example above is a typo for sure), which is defined by IETF, it can be found in SIP Outbound (RFC5626) and GRUU (RFC5627):
https://www.rfc-editor.org/rfc/rfc5626
https://www.rfc-editor.org/rfc/rfc5627
Its purpose is to identify uniquely a device, independent of contact address (which can change in case of roaming around wifi hotspots or 4G/5G networks) or multiple connections, but contact addresses can also overlap when devices are located in private networks using same IP range.
Usually its value is build using a UUID (universally unique identifier), which should reduce the risk of duplicate values for users with multiple devices. Its uniqueness allows SIP Registrar Server to identify what contact record to update or remove when processing REGISTER requests from the same device.
The next two parameters prefixed with +u.sip! seem to be custom parameters set by the sending SIP UA. They look like specific to some CISCO equipment, probably a gateway. In general, SIP specifications tell that custom parameters can be ignored by receiving UA, if it does not know how to interpret them.
Am I able to set the maximum number of possible UberPOOL riders in a vehicle to something higher than 4 or 6? I'm working on a request-based shuttle program and would like to see if I could make use of the UberPOOL API for this project. Ideally I would like to bump up the number of riders in a vehicle to something much higher, probably around 10 - 15 per shuttle.
According to the api documentation for v1.2. The max seat allowed for a uberpool is is 2. So you will not be able to request more than that. The best alternative is use uberx and XL for your request api call. However the max for UberXL is 6 occupants and the for uberx is 4 occupants.
Can anyone let me know how to show a stream only in a specific node
i have a 2 nodes cluster.. and i would like to dedicate RIM01 specific to Stream1. RIM02 to Steam2. Meaning any request to that streams or apps in that stream should go to there nodes
So, if a go to RIM01 the Stream2 should be hidden etc...
Central node
RIM02 -- Repository + Engine
RIM03 -- Repository + Engine + Scheduler
i tried lot of security rules like
Filter : ServerNodeConfiguration_,Stream_
(node.#NodeUse="dev") and (node.#NodeType=stream.#StreamType and !resource.stream.Empty())
or
Filter : ServerNodeConfiguration_,Stream_
((resource.resourcetype = "Nodes" and resource.name="RIM01")) and ((resource.name="test"))
but none of them work :/
Thanks
So, at present, load balancing in Qlik Sense applies to Apps, not Streams. Load Balancing routes apps to servers, whereas security rules govern stream visibility. And, unfortunately, there is not a clean mechanism to use node meta-data in security rules. All in all, there isn't a solution for hiding a stream on a given server.
I have the same issue, you can designate the apps are only readable on single node, so depending on how your user stream rights are configured some users may see an empty stream on the node where the app cannot be accessed.
There's some interesting stuff happening with the multi cloud capability where the concept of streams is now collections, which gives lots more flexibility around this type of thing. Alas QEFE capability is only just come with June 2018, and access is limited to certain use cases / customers.
I'm contemplating creating a RESTful API to monitor a remote instrument - for purposes of discussion, assume the remote instrument is a voltmeter.
One important function of the API is to read the voltage as measured by the instrument at any time.
My question: what, if any, is the appropriate HTTP verb for reading a value that can change from one reading to the next?
As I understand it, GET would be wrong, since servers may assume the value is idempotent and thus cache the returned value.
But the other usual choices -- PUT and POST -- appear to be used to create and update values and not return values.
I can think of a few approaches:
Use GET with a Cache-Control: no-cache in the header
Use (or abuse) POST and have it return a value
Don't use RESTful design for this kind of application
What is considered the correct approach?
My question: what, if any, is the appropriate HTTP verb for reading a value that can change from one reading to the next?
GET
The GET method requests transfer of a current selected representation for the target resource.
The semantics of caching are described in RFC 7234; in particular, you can use the Cache-Control header to provide to intermediary components the metadata they need to cache the responses correctly. The list of cache control directives includes no-cache, if you always want the intermediary components to check with the origin before reusing a value.
This is the main point of the uniform interface - because resources uniformly implement a consistent set of semantics, clients and intermediaries can rely upon those semantics to contribute without needing to know the specific details of the resource, it's implementation, or it's representation.
The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components (Figure 5-6). By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. Implementations are decoupled from the services they provide, which encourages independent evolvability. The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs. The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.
Use GET as thats implicit meaning when you want to only fetch some data from a server.
As you said correctly you need to have right cache mechanism (i said it purposefully as you may just set cache max age 0 but you might also need cache at any later point) implimented to make sure you get fresh data in the response.
I have a custom profile for a proprietary device (my smartphone app will be the only thing communicating with my peripheral) that includes two simple services. Each service allows the client to read and write a single byte of data on the peripheral. I would like to add the ability to read and write both bytes in a single transaction.
I tried adding a third service that simply included the two existing single byte services but all that appears to do is assign a UUID that combines the UUIDs for the existing services and I don't see how to use the combined UUID since it doesn't have any Characteristic Values.
The alternatives I'm considering are to make a separate service for the two bytes and combine their effects on my server, or I could replace all of this with a single service that includes the two bytes along with a boolean flag for each byte that indicates whether or not the associated byte should be written.
The first alternative seems overly complicated and the second would preclude individual control of notifications and indications for the separate bytes.
Is there a way to use included services to accomplish my goals?
It's quite an old question, but in case anyone else comes across it I leave a comment here.
Here are two parts. One is a late answer for Lance F: You had a wrong understanding of the BLE design principles. Services are defined on the host level of the BLE stack. And you considered your problem from the application level point view, wanting an atomic transaction to provide you with a compound object of two distinct entities. Otherwise why would you have defined two services?
The second part is an answer to the actual question taken as quote from "Getting Started with Bluetooth Low Energy" by Kevin Townsend et al., O'Reilly, 2014, p.58:
Included services can help avoid duplicating data in a GATT server. If a service will be referenced by other services, you can use this mechanism to save memory and simplify the layout of the GATT server. In the previous analogy with classes and objects, you could see include definitions as pointers or references to an existing object instance.
It's an update of my answer to clarify why there is no need for the included services in a problem stated by Lance F.
I am mostly familiar with BLE use in medical devices, so I briefly sketch the SIG defined Glucose Profile as an example to draw some analogies with your problem.
Let's imagine a server device which has the Glucose Service with 2 defined characteristics: Glucose Measurement and Glucose Measurement Context. A client can subscribe for notifications of either or both of these characteristics. In some time later the client device can change its subscriptions by simply writing to the Client Configuration Characteristic Descriptor of the corresponding characteristic.
Server also has a special mandatory characteristic - Record Access Control Point (RACP), which is used by a client to retrieve or update glucose measurement history.
If a client wants to get a number of stored history records it writes to the RACP { OpCode: 4 (Report number of stored records), Operator: 1 (All records) }. Then a server sends an indication from the RACP { OpCode: 5 (Number of stored records response), Operator: 0 (Null), Operand: 17 (some number) }.
If a client wants to get any specific records it writes to the RACP { OpCode: 1 (Report stored records), Operator: 4 (Within range of, inclusive), Operand: [13, 14] (for example the records 13 and 14) }. In response a server sends requested records one by one as notifications of the Glucose Measurement and Glucose Measurement Context characteristics, and then sends an indication from the RACP characteristic to report a status of the operation.
So Glucose Measurement and Glucose Measurement Context are your Mode and Rate characteristics, then you also need one more control characteristic - an analog of the RACP. Now you need to define a number of codes, operators, and operands. Create a structure whichever suits you best, for example, Code: 1 - update, Operator: 1 - Mode only, Operand: actual number. A client writes it to the control point characteristic. A server gets notified on write, interprets it, and acts in a way defined by your custom profile.