Can Diameter Final unit indication avp be used over Gx interface? - diameter-protocol

Can the Diameter Final unit indication avp be used over Gx interface?
I know its available over Gy, but can I use it between pcrf and pcef?

YES
Take a look in the GX specification 29212-b70.
If you look at the CCR you can find Charging-Rule-Report AVP. This is a grouped AVP that includes Final-Unit-Indication AVP.

Yes, As per Gx reference point (3GPP specs 29212 v13.5). Charging-Rule-Report AVP contains the Final-Unit-Indication AVP. It indicates the termination action the PCEF applies to the PCC rules.

Related

In a UML state machine, can an initial pseudostate have incoming transitions?

In UML 2.5.1, the initial pseudostate of a state machine is defined as follows:
An initial Pseudostate represents a starting point for a Region; that
is, it is the point from which execution of its contained behavior
commences when the Region is entered via default activation. It is the
source for at most one Transition, which may have an associated effect
Behavior, but not an associated trigger or guard. There can be at
most one initial Vertex in a Region.
In other words, a UML state machine should almost always contain exactly one initial pseudostate, which should have exactly one outgoing transition.
However, can an initial pseudostate have incoming transitions as well? For example:
I cannot find anything forbidding it in the UML specification, yet I cannot find any example online where this case happen, therefore I was wondering whether or not I overlooked anything.
EDIT: To go into more detail, if we look into the OCL constraints stated in the specification, we can only find the following one that affects outgoing transitions (section 14.5.6.7):
inv: (kind = PseudostateKind::initial) implies (outgoing->size() <= 1)
but I cannot find any constraint regarding incoming transitions
EDIT2: I have just realized that my model is wrong! Considering this sentence of the specification (cited above): "It is the source for at most one Transition, which may have an associated effect Behavior, but not an associated trigger or guard."
Therefore the transition between init and s1 should actually have zero triggers, instead of having e1 as a trigger.
Note that while this does not invalidate the initial question.
I see nothing in the UML 2.5.1 Specification that prohibits a transition whose target is the initial pseudostate.
Such a transition would be meaningless at best and confusing at worst, which is likely why no examples are found.
Edit: see the comments!
On p. 423 UML 2.5:
15.7.18 InitialNode [Class]
15.7.18.4 Constraints
• no_incoming_edges
An InitialNode has no incoming ActivityEdges.
inv: incoming->isEmpty()
N.B. If you intend to have a self-transition for e1 then why not just using that? The Initial can anyway have only on singular outgoing edge, namely to the first state (here s1).
No this is not allowed. And why would one Do that? As you already stated in the cited text,it can only have one outgoing edge without any guard. So what is the added value, as you cannot reuse anything.
I think the text is pretty clear as-is: "[An initial Pseudostate] is the point from which execution of its contained behavior commences when the Region is entered via default activation." If you connect a transition back around to the initial psuedostate, the initial psuedostate is no longer "the point from which execution of its contained behavior commences," it is something else, and is therefore undefined.

When should I use circle notation for interfaces

According to UML Superstructure Specification, v2.4 there are two different notations for interfaces in UML class diagrams. One of them is usual box with "interface" word and name above and another one is a cirle with name above (uncle Bob calls it lollipop).
The question is - when should I use circle notation? Is it suitable for situations when class implimenting this interface has only public methods defined in interface? So if it used only througt interface - method set in interface is obvious and maybe I could use this circle notation.
Help me with this, please. Specification is quite clear about semi-circle notation but not about circle.
It's just a matter of taste. Both notations (lollipop and rectangular with stereotype) are interchangeable and have the same semantics.
However, since the rectangular notation allows for showing operations it is preferred if you need to show them. Otherwise the lollipops use up less space which is preferred in other cases.

Use a Map data structure in OCL

how can i use a Map in OCL. For example i want to get all bills for user c1 and my Map 'purchases' looks like Map <Date, Bill>.
c1.purchases.Bill? Is this possible?
regards
The ability to synthesize a map in OCL from a Set(Tuple(K,V)) is something that I and others have been guilty of advocating. A Map(K,V) maintains a single unique V entry per K, whereas a Set(Tuple(K,V)) may have many V's for the same K; not the same at all.
Eclipse OCL therefore has a Map(K,V) as part of its modeled standard library that might eventually make it into the standard.
Regards
Ed Willink

Can association lines be merged in one line in UML?

Is it in accordance with the UML standard to merge a few association lines into one line, like on the attached diagram?
Yes, I think this is allowed as a notational variant, which implies that all association ends that participate in the merger, have the same properties (e.g. the same multiplicity, navigability, visibility, etc.).
Figure 11.34 in the UML 2.5 spec shows an example of such a merged association end sharing the same source segment of the association line.
(Edited answer.) In the UML specification a "shared target style" is defined in Figure 9.23 - Examples of generalizations between classes, see http://www.omg.org/spec/UML/2.4.1/ on page 52.
Edit: In the spec, however, this refers only to generalizations, which are not a subtype of associations but of relationships (thanks to #xmojmr for the pointer to the UML superstructure).
In addition to the notation mentioned by #gwag, here is the original caption for that figure:
Figure 11.34 shows a (...) model using the notational option of sharing the same source segment between multiple compositions. The multiplicity and name adornments on the shared end apply to all of the compositions. The model values for absent adornments on the merged segment, such as property modifiers or visibility, may differ.
Found on page 214.
So called "tree style" is allowed in generalization and composition (aggregation) at the aggregation end.
But you probably see, that it is unclear to understand which classes are associated from your diagram. Is there association between Client -> Address, and Address <-> Contact details, Or Client -> Contact details and Client -> Address ???
Or all of it ?
Shared lines can add ambiguity to your model.

Transparency in Progressive Photon Mapping in cuda

I am working on a project, which is based on optix. I need to use progressive photon mapping, hence I am trying to use the Progressive Photon Mapping from the samples, but the transparency material is not implemented.
I've googled a lot and also tried to understand other samples that contains transparency material (e.g. Glass, Tutorial, whitted). At last, I got the solution as follows;
Find the hit point (intersection point) (h below)
Generate another ray from that point
use the color of the new generated points
By following you can also find the code of that part, by I do not understand why I get black color(.0f, .0f, 0.f) for the new generated ray (part 3 above).
optix::Ray ray( h, t, rtpass_ray_type, scene_epsilon );
HitPRD refr_prd;
refr_prd.ray_depth = hit_prd.ray_depth+1;
refr_prd.importance = importance;
rtTrace( top_object, ray, refr_prd );
result += (1.0f - reflection) * refraction_color * refr_prd.attenuation;
Any idea will be appreciated.
Please note that refr_prd.attenuation should contains some colors, after using function rtTrace(). I've mentioned reflection and reflaction_color to help you better understand the procedure. You can simply ignore them.
There are a number of methods to diagnose your problem.
Isolate the contribution of the refracted ray, by removing any contribution of the reflection ray.
Make sure you have a miss program. HitPRD::attenuation needs to be written to by all of your closest hit programs and your miss programs. If you suspect the miss program is being called set your miss color to something obviously bad ([1,0,1] is my favorite).
Use rtPrintf in combination with rtContextSetPrintLaunchIndex or setPrintLaunchIndex to print out the individual values of the product to see which term is zero from a given pixel. If you don't restrict the output to a given launch index you will get too much output. You probably also want to print out the depth as well.

Resources